usrbinenv

No mobile version, but I'm visiting from a tablet, should work at least if switch to "Desktop" in the browser manually. I don't care if I get horizontal scroll - not showing your visitors anything at all is an automatic "I'm out".

Second, when I browsed from an actual desktop, and clicked on links for files it was all slow as hell - specifically the part when you click on a file an expect it to just load, you instead get: 1) some layout switch which looks like page reload 2) then it says "loading..." for several seconds.

After looking at the source code, it appears to be React or similar frontend framework... Ugh. I don't know why people choose to use that stuff, just have a regular SSR which would work a hundred times faster and is more pleasant. And if you really want an SPA, don't use React, Vue or Svelte (and similar), it's horrible and always slow.

Finally, since this appears to be a YC company, it shouldn't matter what's it written in. In fact, I don't even know why Rust would be a good thing here when Go or even Rails/Django would work just fine - but again, it just reinforces the meme that if it's written in Rust, you'll surely hear about it.

Overall, the minimalism idea is welcomed, but it supposedly should appeal to people like myself and it doesn't for all the reasons I mentioned above.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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?