Hacker News: usrbinenv

New comment by usrbinenv in "The foundations of a provably secure operating system (PSOS) (1979) [pdf]"

usrbinenv — Mon, 18 May 2026 11:36:48 +0000

I know about it, but I'm not interested in QubeOS approach. It's VMs all the way down, while what I'm talking about is no VMs and capabilities as first class citizens and no vurtualization.

New comment by usrbinenv in "The foundations of a provably secure operating system (PSOS) (1979) [pdf]"

usrbinenv — Mon, 18 May 2026 11:34:58 +0000

In case of updating the binary, yes, you generally want to make sure it comes from the same source and therefore cannot do damage to things it already has access to. But when you install a new program, it shouldn't have access to any resources other than the ones it creates itself, so there's no need to sign it. Further more, when installing a new program, you still have to download/import the pubkey to verify the signature from somewhere, so it's almost meaningless on the first installation. Signatures wouldn't be obsolete, but they also wouldn't be the only line of defense. Furthermore, updating can now be performed by the program itself and the program might already contain the pubkey needed to check the validity of updates.

New comment by usrbinenv in "The foundations of a provably secure operating system (PSOS) (1979) [pdf]"

usrbinenv — Mon, 18 May 2026 10:51:23 +0000

I didn't mean it in the Java way. I meant that whatever operating system you're on, you can download random programs from the internet (compiled specifically for your OS or portable) and run it on your machine. It doesn't matter what they're written in or how they're run, it's possible on any OS connected to the internet and an OS with capabilities as first class citizens would isolate any program by default, denying it access to anything by default and severely limiting program's ability to cause harm, intentionally or unintentionally.

New comment by usrbinenv in "The foundations of a provably secure operating system (PSOS) (1979) [pdf]"

usrbinenv — Mon, 18 May 2026 10:36:47 +0000

I understand why in 1979 and perhaps until mid 1990s capability OS architecture might have been irrelevant and excessive. But after that, it sounds like the only architecture suitable for the internet age, where you can download and run anything from anywhere. Instead, we're stuck with legacy systems, which now contain layers of layers of abstractions and security measures. User rights, anti-virus software, vetting (signatures, hashes, app-store verification) - all become obsolete or near-obsolete in a capability-based system where a program simply doesn't have access to anything by default. Part of the appeal of virtualization is also due to the fact that it isolates programs (for instance, I only run npm inside Docker container these days, because chances are some package will contain malware at some point).

Part of it is inertia, but part of it is ignorance. Enthusiasts spend tons of money and effort building another GPU enabled terminal or safe programming languages - and maybe that's fine, but I wonder what we could've accomplished if people were simply aware what a well-designed capability OS could be like, because this is literally the only OS paradigm in existence (that I know of) that's even worth any serious effort.

New comment by usrbinenv in "Microsoft hasn't had a coherent GUI strategy since Petzold"

usrbinenv — Mon, 06 Apr 2026 05:04:15 +0000

I was recently exploring "an OS from scratch" architecture with ChatGPT. Apart from the central idea that I wanted it to be a capability OS, I also started thinking about how I'd make GUI apps and what layers would naturally make sense.

The cleanest design I came up with works like this:

1. At Layer_1 OS provides panes or windows to which apps can render whatever graphics using OS gpu lib (think Raylib, but maybe a bit simpler). This is good for apps that want performance, games, text editors, things like that - so this is maximum control.

2. Next Layer_2 would be based on the browser engine (which, to some degree, would have to be developer - not a full browser, but just enough to render more or less modern html/css with a DOM-aware JS engine). Then provide some XML schema that would automatically translate into HTML/CSS to render various UI-widgets (defined by XML/HTML elements). This would eventually suggest a JavaScript UI framework on top, but no a requirement. This layer is flexible enough that it uses widgets defined by the system, but allows custom CSS and JavaScript.

3. Layer_3, or more like Layer_2.5 would basically allow custom HTML/CSS without relying on system widgets and XML schema.

Obviously you can mix all three layers into one GUI too. Finally layers (2) and (3) would require some client/server architecture, but instead of shipping it like a webapp, I'd probably provide some JavaScript API to talk to the backend (which in this case is accessible via a socket of some sorts). Apps themselves could still be single binaries that include html/css/js assets which are provided at launch time to the system UI renderer, which then uses them to render the UI via a webview in said pane or window.

I think it's pretty slick and it only gets complicated gradually, but it also requires solid OS plumbing and machinery to make this process smooth. None of the modern systems are capable of it in the way I described it, so people end up shipping nodejs/react apps with webview inside gigabyte-binaries.

New comment by usrbinenv in "Age verification on Systemd and Flatpak"

usrbinenv — Sat, 04 Apr 2026 07:59:09 +0000

Of course, it's pretty easy to see through this: introduce law in a few states, but now every OS needs to comply and because it's hard to actually tell which country/state user is in, they'd just have to implement it for everyone. It will be verification through some third party. You can opt out, but then major websites will be forced to deny you access (by, for example, Cloudflare) unless your OS provides a verified and signed certificate of your age. Then it's done: nothing will be possible without an ID, which means no dissent will be tolerated.

New comment by usrbinenv in "Moving from GitHub to Codeberg, for lazy people"

usrbinenv — Thu, 26 Mar 2026 15:15:47 +0000

I don't understand the hype around CI and that it's supposedly impossible to run something like that without Git, let alone Github. Like sure, a nice interface is fine, but I can do with a simpler one. I don't need a million features, because what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here? It can probably be built internally if needed and it certainly doesn't need to depend on git so much - git can trigger it via hooks, but that's it?

I think the real problem is we were sold all these complex processes that supposedly deliver better results, while in reality for most people and orgs it's just cargo culting, like with Kubernetes, for example. We can get rid of 90% of them and be just fine. You easily get away without any kind of CI in teams of less than 5-7 people I would argue - just have some sane rules and make everyone follow them (like run unit tests before submitting a PR).

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 21:34:36 +0000

Alpine/htmx are great, but they're more "sprinkle behavior on HTML" tools. Qite is closer to a structured component system: explicit events, a state engine, and a consistent way to wire parts/fields/children together without ad-hoc glue.

You can build similar things with Alpine/htmx, but once things grow, you end up reinventing structure. Qite just bakes that in from the start.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 21:23:46 +0000

What you probably saw isn't code in quotes, but simply matchers like `price: "isPresent()"`. The () is there to signal it's a matcher, not a value. If this matcher doesn't exist, you'll get an error. The reason I chose () to signal it's a matcher is to distinguish it from values. Maybe there's a better way to do it.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 21:22:41 +0000

Yeah, I get the reaction. It's not JavaScript, it's simply a way to reference a matcher for the value, not match against literal value. You can totally use your custom matcher like this:

    total: (c,v) => v > 1000

See the docs: https://qitejs.qount25.dev/States/Field-Matchers.html

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 21:14:42 +0000

Thank you. Since you had this positive reaction to which I very much relate, may I ask you what did you personally think was confusing in the docs that may still turn people away?

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:48:05 +0000

Btw, looking back at the index page, I think I might have made the initial example a little bit too much (because realistically, you don't often get components that complex). If you guys want a simpler saner example, the one the second page looks nicer: https://qitejs.qount25.dev/Explained-by-ducks.html

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:42:57 +0000

Yeah, several apps have been built with it, but they're not public (or not public yet). Also, Qite.js has a number of prebuilt-components. I haven't gotten around documenting them, but you can find working example here:

https://code.qount25.dev/qite/qite-js/src/branch/master/src/...

https://code.qount25.dev/qite/qite-js/src/branch/master/test...

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:40:04 +0000

It's a bit more nuanced than that. State in Qite is held both in HTML and in JS Component. The html serialization is sort of consequence of changing a field (like when you want to update textarea content, for example). You can completely ignore it or you can also use it for CSS, for example. Another usecase is when user interacts with the pages, changes text in said textarea and it also automatically updates the JS Component field. Finally, there are also flags, which aren't stored in DOM. I'd like to point out this architecture isn't random, it came from building apps and realizing how everything interacts.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:34:05 +0000

It works better than "just like" in the sense that it also takes care of things like CSRF, POST/GET params, request/response types etc for basically free.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:30:47 +0000

As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:24:54 +0000

React got popular not because of its amazing time-tested ideas (everyone knows they re-engineer everything once every couple years!), but, strictly speaking, because at the time it was released there wasn't any kind of serious SPA or partially-SPA framework for the web and also because JavaScript sucked a lot more at the time (no classes!). Qite is perfectly suitable for complex UIs thanks to its state functionality, you can build pretty complex functionality and UI and not sacrifice user's CPU in the process.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:17:10 +0000

Just to clarify: Qite does both events AND state, which I find quite powerful and useful.

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:14:22 +0000

While it's definitely possible to build similar website with Turbo and Stimulus it would absolute NOT be the same thing and the mechanics of it would be radically different. I would argue using SSR at all times (and, consequently, workarounds like Hotwire, which make it look like it's not SSR) is the same kind of sin as using React for SPAs for personal blogs (i.e. things, SPAs don't belong to).

New comment by usrbinenv in "Qite.js – Frontend framework for people who hate React and love HTML"

usrbinenv — Tue, 24 Mar 2026 20:09:46 +0000

You can have