Wait, so is the browser running a JavaScript build of Qemu? /

Hacker News still has a feed (that's the only reason why I saw this thread). And Reddit gives you a feed for your subscribed subreddits.

That's a weird way to put it.

The commit activity looks unusual because it's a completed project whose files were individually committed in alphabetical order. There's no development history.

What have been the most helpful reference materials so far?

What's the most memorable challenge you overcame?

What's the coolest or most surprising thing you learned?

Any links?

> Maybe this is also why Smalltalk fiends are such fans.

I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.

(I'm not the author) The easiest way to charge for this kind of software is to make it SaaS, and I think that's pretty gross, especially for a CLI tool.

> I'm skeptical and I may just release it all as OSS

It doesn't have to be one or the other: you could sell the software under libre[1] terms, for example.

[1]: https://en.wikipedia.org/wiki/Free_software

I created a little GTK program to help: https://github.com/LightAndLight/gen-alias

A possible piece of the puzzle: I originally read the article on mobile, no issues. Then I opened it on my desktop, and found the design quite jarring. The margins are much too large for my taste, forcing the text into a single narrow column, and the header animations were distracting and disorienting (fortunately the page works perfectly with JavaScript disabled). Perhaps this triggered people?

I run Syncthing to keep my KeepassXC in sync across devices. At the same time I have `syncthing-merge`[1] running to handle any conflicts due to concurrent database edits. It calls `keepassxc-cli merge` to merge conflicting databases, which requires my database password. `syncthing-merge` runs as a system service under its own user, so I wasn't able to use a graphical dialog program like GNOME's `zenity` to ask for the password. My solution is to run a user service that can create graphical dialogs in response to requests from system daemons, while enforcing minimal access to the data that the user enters.

With the required NixOS config[2] in place, a system service calls `asker KEY` to issue a request. If that service is a member of the `asker-keys-{KEY}` group, then the request proceeds, is handled by a user service (`asker-prompt`), and then printed to stdout (i.e. to be piped into another program). I took care to ensure that only authorised services could read the user's input.

I looked into using existing keyring programs via the D-Bus Secret Service API, but I couldn't figure out how to control access to individual secrets. I know exactly which services should be allowed to access particular secrets, and I want to enforce that. In particular, I don't want my logged-in user to have universal access to these secrets, because then any program I run can read them (see also: recent discussion of this issue[3]). I also found that these keyring programs aren't suited for ephemeral data; they store secrets for a while.

It might be possible to achieve this using pure D-Bus with access control policies. I haven't looked into this because after I decided that the Secret Service API was insufficient, I figured that rolling my own protocol would be easier than learning D-Bus.

Questions for you:

* Which wheels could I have avoided reinventing?

* Is there anything I could simplify?

* Have I failed at my security goals due to mistakes or oversights?

[1]: https://github.com/LightAndLight/syncthing-merge [2]: https://github.com/LightAndLight/asker?tab=readme-ov-file#us... [3]: https://news.ycombinator.com/item?id=46278857

Comments URL: https://news.ycombinator.com/item?id=46439560

Points: 2

# Comments: 0

Next up I'm moving my TODOs off Todoist to something local-first, and plugging that into my Syncthing setup.

> If you have a feed reader system there is no need to subscribe [via YouTube] in the first place. You’ve obviated that system.

This approach works, and it's a great way to subscribe to public channels without a YouTube account. The main reason I'm not doing it is that I want to subscribe via YouTube.

> It would be great if it was more discoverable

Oh, hopefully there's a browser extension that detects feeds on a page and lights up and provides a menu. Shame that the YouTube mobile app isn't similarly extensible.

It's not a "Show HN" because there's no way for others to try it (yet).

Some things I'm curious about:

* Is anyone else here doing something similar?

* Would anyone like to use this service?

* Are there other YouTube-meets-news-feed features that you'd love to see?

Comments URL: https://news.ycombinator.com/item?id=44412109

Points: 17

# Comments: 14

My main concern is that it will be hard for you to find people who could give you excellent feedback on this, because they probably have epistemic shields up around this topic due to all the surrounding crankery. I don't know how to solve this, but I wish you luck.

From "How is your data used?":

> Firefox also shows its own search suggestions based on information stored on your local device (including recent search terms, open tabs, and previously visited URLs). These suggestions may include sponsored suggestions from Mozilla’s partners

> Mozilla's partners receive de-identified information about interactions with the suggestions they've served.

> Depending on your location, Mozilla derives the high level category (e.g., travel, shopping) of your search from keywords in that query, in order to understand the types and number of searches being made. We utilize privacy preserving technologies such that Mozilla only learns that someone, somewhere, performed a search relating to a particular category, without knowing who.

> Mozilla may also receive location-related keywords from your search (such as when you search for “Boston”) and share this with our partners to provide recommended and sponsored content. Where this occurs, Mozilla cannot associate the keyword search with an individual user once the search suggestion has been served and partners are never able to associate search suggestions with an individual user.

> You may be able to opt into an enhanced search experience, which will result in Mozilla processing additional personal data, including your technical data, location and search data. Some of that information may be shared with our partners on a de-identified and/or aggregated basis.

> We use technical data, language preference, and location to serve content and advertising on the Firefox New Tab page in the correct format (i.e. for mobile vs desktop), language, and relevant location. Mozilla collects technical and interaction data, such as the position, size, views and clicks on New Tab content or ads, to understand how people are interacting with our content and to personalize future content, including sponsored content. This data may be shared with our advertising partners on a de-identified or aggregated basis.

> In some instances, when ads are enabled on New Tab, additional browsing data may also be processed locally on your device to measure the effectiveness of those ads; such data will only be shared with Mozilla and/or our advertising partners via our privacy-preserving technologies on an aggregated and/or de-identified basis.

> When you allow us to do so, Firefox sends Mozilla data about the website domain or specific advertising campaign (if any) that referred you to our download page to help us understand and improve our marketing efforts. Firefox also shares information with our marketing partners to measure and improve these campaigns; what information is specifically shared varies (depending on how you discovered Firefox and your operating system) but generally includes how you were referred to our download page and whether you actively use Firefox. Where Firefox is pre-installed on your device, technical and interaction data (your device type and whether Firefox is used) will be sent to our marketing partners, and shared with Mozilla.

* Figuring out where to start when learning new things (see also <https://news.ycombinator.com/item?id=43087685>)

  One way I treat LLMs is as a "semantic search engine". I find that LLMs get
  too many things wrong when I'm being specific, but they're pretty good at
  pointing me in a general direction.

  For example, I started learning about OS development and wanted to use Rust. I
  used ChatGPT to generate a basic Rust UEFI project with some simple
  bootloading code. It was broken, but it now gave me a foothold and I was able
  to use other resources (e.g. OSDev wiki) to learn how to fix the broken bits.

  It feels like a lot of software documentation isn't actually written for real
  readers; instead being a somewhat arbitrary listing of a program's features.
  When programs have this style of documentation, the worst case for figuring
  out how to do a simple thing is reading the entire manual. (There are better
  ways to write documentation, see e.g. )

  One example is [gnuplot](http://www.gnuplot.info/). I wanted to learn how to
  plot from the command line. I could have pieced together how to do it by
  zipping around the
  [gnuplot manual](http://www.gnuplot.info/docs_5.4/Gnuplot_5_4.pdf) and building
  something up piecewise, but it was faster to instruct Claude directly. Once
  Claude showed me how to do a particular thing (e.g. draw a scatter plot with
  dots intstead of crosses) I then used the manual to find other similar
  options.

  Similar to the previous point. If I ask Claude to write a simple program using
  a complex publicly-available API, it will probably write a broken program, but
  it won't be *completely* bogus because it will be in the right "genre". It
  will probably use some real modules, datatypes and functions in a realistic
  way. These are often good leads for which code/documentation I should read.

  I used this approach to write some programs that use the
  [GHC API](https://hackage.haskell.org/package/ghc). There are hundreds of
  modules, and when I asked Claude how to do something with the GHC API it wrote
  relevant (if incorrect) code, which helped me teach myself.

  My partner is Chinese and sometimes we talk about Chinese poetry. I'm not very
  fluent in Chinese so it's hard for me the grasp the beauty in these poems.
  Unfortunately literal English translations aren't very good. We've had some
  success with asking LLMs to translate Chinese poems in the style of various
  famous English poets. The translation is generally semantically correct, while
  having a more pleasing use of the English language than a direct translation.

Yeah, I'd be more comfortable if it could say "I don't know" instead of generating bullshit.

Simon Willison's article Think of language models like ChatGPT as a “calculator for words”[1] helped me think about this topic better:

> If you ask an LLM a question, it will answer it—no matter what the question! Using them as an alternative to a search engine such as Google is one of the most obvious applications—and for a lot of queries this works just fine. It’s also going to quickly get you into trouble.

All of this is why I only every use LLMs for things that I can verify.

[1]: https://simonwillison.net/2023/Apr/2/calculator-for-words/

> There must be some named law that states that the set of people you listen determine most of your thoughts. But it's something way wider in scope than Conway's Law.

A related term is "audience capture". When you do things based on the approval of your followers, you can end up catering to some weird niches.