vilunov

Linux is a kernel, it doesn't have a stable and rich enough set of userspace services to be considered an operating system on its own.

Scala 2 is a dying language, and Scala 3 is an immature one. The ecosystem and community are also very messy, with fragmentation and witch hunts running rampant. OCaml provides same advantages, but without all the drama.

I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed.

It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of `Debug` effect is already a compilation parameter, it could be generalized to support any sets of implicit effects. Thus you might design a module that has implicit Logger and Database effects in all its functions.

Real life software is much more than just downloading a game and running it.

Real life software outside of Linux is pretty much just downloading and running it. Only in Linux we don't have a single stable OS ABI, forcing us to find the correct package for our specific distro, or to package the software ourselves.

A properly secured Linux machine is a unicorn. The Linux desktop ecosystem is struggling a lot with putting software in namespaces. People still install software with their package managers outside Flatpak, there is no isolation of data, not to say many workflows depend on the whole user directory being available to access.

Usually FE and BE are developed by different people or even teams. It's helpful to decouple release cycles of both components, or else a bug on one component could block deployment of a different component. It's important not to decouple deployments of two components when doing so would save up significant resources, but here decoupling could be achieved by deploying a separate nginx server with static files – this is incredibly cheap, as there is very little static overhead, and performance is comparable.

Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA. Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.

Just serving static files from Rust is not that interesting. It definitely does not sound easier to me, since you are coupling deployment of both BE and FE with no resource optimization to get. Also, since built SPAs are essentially static files, their deployment could be just uploading these files to your CDN.

This is beautiful. Deterministic, bootstrapped, and doesn't break the established Linux conventions! Shame it's musl-only, I would love to use something like that to build glibc-based apps for future redistribution as proper Linux binaries.

how awful of a language Dutch is to learn

Curious, why do you think so? As a Russian I found Dutch to be much easier to learn than Japanese, and English knowledge helps. The largest problem by far is Dutch speakers falling back to English almost always.

Kubernetes is absolutely not an accidental complexity. Microservices are not an accidental complexity, and they are not a replacement for a proper repository.

Kubernetes solves administration of a cluster of Linux machines, as opposed to administering a single Linux machine. It abstracts away the concept of a machine, because it automates application scheduling, scaling across different machines, rolling updates of applications, adding/removing machines to the cluster all at the same time. There are no instruments like that for applications, the closest to them are something like Spark and Hadoop for data engineering tasks (not general applications).

Microservices are also used to solve a very specific problem – independent deployments of parts of the system. You can dance with your repository and your code directories as much as you want, if you're not in a very specific runtime (e.g. BEAM VM), you will not achieve independent deployments of parts of your service. The ability to "scale independently" (which tbh is mostly bullshit) is an accidental consequence of using HTTP RPC for microservice communication, which is also not the only way, but it allows reuse of the HTTP ecosystem.

Is it possible to specify locked glibc and cc/linking toolchain in your Bazel project?

That's not usually the issue. Glibc is used by 90% of main distros, notable exception is alpine used in docker images.

The problem is Linux ecosystem's fixation on "build environment = runtime environment" idea, making it incredibly difficult to build against older versions of glibc (e.g. Ubuntu 22.04) if you're using something new such as latest Arch. This is not a problem on macOS, you can use an SDK for a particular OS version on any other recent version.

Unfortunately, my predecessors had plenty of time. Now I'm left with a burning project and half my time spent on clicking "go to implementation" of the next interface and hoping the first one will be the real one (actually full-text searching for it because Scala has no working IDEs).

I'm sorry, but depending on abstract classes does not "free the domain model of an application of low level details". The details are always there, but they could be tucked away inside other classes (structs/types) that higher ones depend on. These low level classes need not to be abstract, it will just make discovering code harder and provides nothing to improve separation of concerns.

Updating the minimum supported Rust version is a breaking change that should not be done lightly.

Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.

Async-await in Rust isn't a Monad.

For-comprehensions are actually not functional programming, their raison d'etre is to embed traditional imperative programs in expression-based referenetially transparent FP programs.

I think if Rust had Scala's for-comprehensions, it would be a strictly worse language than it is now. FP langs' do- and for-comprehensions are highly unergonomic, not least due to all the ways it could be overloaded. Haskell has tons of extensions, Scala's is basically desugaring to flatMap calls. This has a lot of abuses in the wild, and with how it depends on implicits causes practical problems when you write that code.

Scala's new wave of direct syntax and general direction from Monads to algebraic effects is more sane in how it presents compiler messages, and opens ways to have better performance.

Show me an example of an "open source server".

XMPP and Matrix services run open source software such as ejabberd

You're basically saying web browsers and other applications (including IDEs, chat apps, etc) should remove support for tabs and rely on WMs providing tab functionality. Some of tiling managers you mentioned that I'm familiar with don't have any functionality I would be happy replacing browser tabs with.

If you have want to have 100 tabs open, you should be using bookmarks or history instead of tabs.

Bookmarks and history have very different UX from tabs, they are clunky to use and I would never prefer them to opening 100 tabs, sorry.

If you want to have different workspaces, profiles, or so on, use your window manager's workspaces

These workspaces don't enable separation of cookies and other state, they have a very different use case to browser workspaces.

Where can I read about what exactly Oxide is? The main page states "No Cables. No Assembly. Just Cloud" and not much besides that.

If they don't have a consistent UI and emulate the original awful UX, then in what aspect are they nice?

They have a ton of problems in my experience, a few off the top of my head:

- They force the specific repo url, e.g. ssh github even if you prefer to clone by http.

- Pulling from remote becomes difficult when submodules change, e.g. when a submodule is merged into main repo and becomes a proper subdir.

- git commands such as `git checkout -- .` don't work properly on them and I don't see how configs could change that.

I used to read and write a lot of Scala and a bit of Haskell code which claims to be very similar to what I think you're mentioning here. There people also start with defining the domain in interfaces (algebras, eDSLs) and data types.

In the end it's still the same indirection and abstraction as in any other Java or Go codebase, and it prevents the developer from easily accessing the actual logic of the program.

Even with Vulkan support on macOS it would be harder for Valve to make many games accessible as they do on Linux – unlike Linux, macOS does not support running 32-bit binaries anymore.

What's stopping them from violating network boundaries?

Who runs container orchestrators on phones?

Isolation mechanisms is not what makes an OS. It's the stable ABI that application developers can depend on and which provides a way to use shared resources: disk, CPU, RAM, GPU, network, screen space, push notifications, GUI integrations, your favorite LLM integration, so on, so forth... Yes, it might have an imperfect security model, but nothing's perfect under the sun.

Raw Linux without userspace could be considered an OS, but it has the ABI only in form of syscalls and the minimal standard FS. That's barely enough for anything other than, say, a statically linked Go binary, which is why it's seldom used by app developers as a target.

To most of your examples I say – yes, that's an OS, and jails or zones have nothing to do with it. Although I'm not familiar with them other than FreeBSD, so I'm relying on your short description and your implied criteria for selecting these examples.

Yeah, but that's not an incidental property of *namespaces* (of which cgroups is only one isolation axis), that was the requirement when namespaces were designed.

I guess this came to be due to the poor original security model of classic OSs, which led to prolification of viruses and complex management of shared resources. Users, groups and access flags are not enough to manage security of a system.

Linux tried to fix that with namespaces and it turned out to be more or less successful, but Linux is not an OS, it's just a kernel, and it's up to real OSs built atop Linux to use namespaces as an implementation detail for real application isolation.

One way to do that is OCI-containers, the other way is Flatpak. Neither of those is not a proper OS yet, but you could call Kubernetes an operating system which uses containers as means for application and resource isolation. Naturally that means Kubernetes is a complex beast, but that's what it takes to provide what users expect from an OS.

Android also comes to mind, they managed to isolate applications between each other quite safely.

Source about Microsoft switching to stable syscall ABI due to containers?

I don't understand the need of such a role at all. It's fine if it's the OS-level software, but for end-user applications such as KeePass I'd prefer that there would be no intermediaries between the developers of the app and the users. You don't need to repackage every piece of software that your users might want to use, let developers target your OS on their own by providing a stable set of APIs and ABIs, otherwise it's not really an OS.