Had to log in to my rarely-used HN account to mention that I had played Biolab Disaster over and over again years back but lost track of it and forgot the name. Kinda wild to find it again by sheer luck!
412 karma · joined March 9, 2015
- You can use `flatpak install --include-sdk --include-debug THE-APP` to install the SDK and debug info for an app - Then `flatpak-coredumpctl -m MATCH THE-APP` will use coredumpctl to open the matching coredump inside the corresponding SDK's gdb
- OpenGL is a much easier target to support, in terms of having a functional desktop. Remember, hardware-accelerated apps have been runnable on Asahi for months now, while Vulkan support is still a while away. - Most of the work being done is common to OpenGL and Vulkan, so it's not exactly a ton of wasted effort.
By the creators of Penpot, free plan is basically only missing premium support. Not sure about the login though...there seem to be some plugins for it, not sure how that works with the hosted version?
> the FDIC is funded by banks and receives no appropriations from Congress
So banks going down can certainly cause other banks money, too.
That being said, the "significant discount" is usually because, when you acquire the assets, you also acquire the bank's liabilities, and AIUI roughly speaking you're paying the difference between what you gain and what you lose in the process. More specifically, the FDIC helped fund JP Morgan's acquisition of First Republic because, if JP Morgan simply acquired the assets & liabilities directly, they would not be enough liquidity for it to be safe.
I.e. acquiring a smaller bank has some advantages but also some downsides, and it also destroys trust in the system which hurts the big banks too...so it's not really something that's exclusively beneficial and definitely not worth trying to trigger intentionally.
Starting without IO makes sure that you actually start to "get" how the language functions, so that once you jump into IO, the weird parts and how to mix it in with the logic written elsewhere makes a lot more sense.
- Flatpak doesn't require apps to be rebuilt when the runtime changes, whereas Nix would require a rebuild. This is, of course, an intentional selling point for Nix: you don't have to worry about keeping track of ABIs and the like. This is, however, less fun when you have to update a large amount of applications for little reason. - When using flakes, it's easy to end up with a lot of extra disk usage because of a proliferation of different nixpkgs versions. Flatpak's runtimes help avoid this, since apps target a runtime version and can run under any individual commit for that version. - Flatpak has a massive amount of internal infra for sandboxing that would take a moderate effort to reproduce elsewhere. - This also means that running Flatpaks always involves new user namespaces; this can't just use environment variables like Nix does. - Flatpak's entire setup is more tuned towards GUI applications, with support for stuff like swapping out the graphics drivers. (nixOS can ofc do this, but you need nixGL otherwise.) - Flatpak has support for downloading non-redistributable files at install time and placing them in the same location as the application's main files. - Flatpak's summaries that it downloads from the server are much smaller than nixpkgs checkouts. - Flatpak dedups individual files across apps.
Really, it's just that Flatpak prefers keeping the build process and usage simpler to focus the energy on sandboxing, leading to design decisions like the more straightforward runtime/app split (easier for a user to understand / manage) and all of the built-in extras for graphical applications. Nix has a significantly more complex UX but is infinitely more flexible and also far better suited for development environments.
If your thought is "most of this isn't structural", that wouldn't be incorrect: there is no reason that:
- building flatpaks couldn't use a more nix-like model - nix couldn't add sandboxing and summary support on top
Heck, you could probably build a Flatpak from a Nix derivation, if you figured out how to separate the "runtime" and "app" parts. But at the end of the day, every tool has some limited degree of development bandwidth, and as-is, Flatpak and Nix just optimized that bandwidth for different targets.
X runs on more platforms than Wayland because...it was ported to them. Just like things use Python 3 because they were ported to it.
This is also understating the reach of X I think: it's widely used in the embedded world, is seeing increasing support in BSDs, and has even been used on macOS (https://github.com/owl-compositor/owl). People have even used it to embed an entire compositor inside a GTK app (https://github.com/alexlarsson/wakefield).
That isn't to say that libwayland has a lot of Linux-isms in it, but afaik they're not really structural as much as there is lack of interest to generalize things more. Heck, the protocol-oriented architecture would even make it easier for anything Linux-esque to be removed in favor of alternative protocols.
RH does have an interest in Rust, used in projects such as Stratis. It's just that the Linux dev ecosystem has been very C-reliant for a long time, and a massive amount of binding and other ecosystem work is still happening to make this possible.
*EDIT:* and the reason I mention Rust specifically is that, in these types of lower-level projects, a lot of things can start to get hairy very quickly in higher level languages. Things like some namespace APIs very much wanting to be run on a single thread, or trying to maintain performance when you're intercepting and examining every D-Bus message, or even just when you want your functionality to be in a reusable core library.