Back in the Knoppix days it was first a novelty, and then a blessing that you had to boot from a CD-ROM, because it led to one amazing outcome:
Less tinkering.
Or rather - it split use from tinkering.
Systems today are designed around the principles of deferral and volatility. You can add or change anything at any time. The user has absolute freedom to tinker, but also the vendor of always-connected products has endless possibilities to update. The result is a mess of dissatisfaction and half-bakery. Nothing is ever finished or fully right. It also, maybe paradoxically, leads to systems that feel less under your control.
Systems like TinyCore and Live CD distros take a different approach that the OS is finished. You have two choices, take it or leave it.
Unless you are prepared to cross a non-trivial barrier to remix and update the non-volatile image, you are forced to just use what you have. That leads to more productivity because you adapt to the tool rather than constantly adapting the tool to you.
I like TinyCore because it's looking to a middle ground of baking immutable systems at key stage points and keeping changes separate from the immutable core. I can change the core if I want to, but rarely.
I see that as a separate prospect than "appliance platforms" like Android and a PhoneOS onto which you can only load "apps".
What ideas and favourite solutions do other's have for using immutability, or not liking it?
Then the next semester I am denied the ability to take a parallel computing class because it was for graduate students only and the prof. would not accept a waiver even though the class was being taught on the cluster me and a buddy built.
That I still had root on.
So I added a script that would renice the prof.'s jobs to be as slow as possible.
BOFH moment :)
They once were, before the internet made software updates "easy". There was a time when software was released (and often embedded without any option for upgrade/modification).
But immutable (mostly correct and reliable) software is more expensive and takes longer to develop, so it is out of fashion. Instead we now push out alpha quality MVPs and depend on updates to resolve known and unknown unaddressed issues as well as promised by not delivered features.
To be a little fair to developers, the user expectations these days are 10x or more greater than they were pre-internet-update days. After all, we now carry "supercomputer" devices in our pockets which also make phone calls, and we expect features and integrations which previously were not even imagined.
Even cars are now becoming update dependent for features and bug fixes. This is approaching a breaking point, I think. It will likely happen; there will be regulation and/or revolt; there will be a return to write-once approaches.
Many of the thousands of dependencies in a given distro could file a new vulnerability overnight. Your immutable distro will need updating pronto.
I certainly hope so. I dread the day it becomes impractical to drive older, pre-bullshit cars.
- https://github.com/koekeishiya/yabai/wiki/Installing-yabai-(... - https://github.com/koekeishiya/yabai/wiki/Disabling-System-I...
If part of your program's installation process is "reboot into recovery mode", I feel like you're working with an OS that isn't quite as malleable as we sometimes are led to believe it is. :D
(btw I use `yabai` and it is totally worth doing all these things...I wouldn't set it to auto-update, and I review every release carefully, but so far so good. It's a great WM for macOS!)
Well technically near every router and embedded device is "immutable", with usually only config partition being changed, and firmware update being just re-loading whole image.
Sadly, because they inherently make it so hard to keep up to date with the latest version of proprietary software like nVidia. Or they don't provide support over a wide range of (desktop and embedded) architectures.
Often the best choice you can make is the distro that has most users, so you are sure that it will get the attention and support from third parties.
For my own files I have a partition which I use exclusively for data. When I want to make changes to the system I have a boot option to disable overlayfs which I use once every few months for updates.
All I want is a Live CD like OS for safe browsing that has an actually usable firefox - i.e. has ad block and vertical tab extensions installed.
Verticals like Senior Care I think would go for this over the current MSP managed systems.
They have high turn over and low tech investment, I've met ones that still use workgroups and shared workstations (single username/pass).
There is a market there potentially for the management companies that run the facilities
It killed our USB stick in just days, though
Two words. Unpatched vulnerabilities.
It’s a bit like iOS and android, the system is the same on all devices of the same model, there are just different configurations and different apps.
Funny because now, that's how both Android and iOS behave, with the difference that OS updates only come every other month and AB partitions making the installation process perceived as fast as only rebooting.
This is just vastly untrue.
A bespoke tool will always be more productive than a one-size-fits-most tool, and thankfully with development tools the work/time of fitting your tool is marginal to the hours you work with it, and the effort is heavily front-loaded. After a few years you have a solid setup that only requires tiny amounts of polishing every few hundred hours.
So the real correct answer to whether bespoke or pre-configured tools are more efficient is “it depends”.
Others have noted the FOMO/paradox of choice issue, so I’ll list another: multi-context environments. I work in a highly collaborative environment where I need to share tools and sometimes whole machines. I rarely get to use the same configuration for any particular task. So bespoke, to me and many of my colleagues, means more stuff to learn. Standard options and configurations mean much higher levels of productivity.
In the security world, an immutable system is an unpatchable system. If a 0-day is found in the system image, you can't fix it, you have to get a new image going. This causes wasted personnel-hours, wasted money, and some times wasted hardware if the image happens to be on a ROM-type of data storage. I've seen immutable systems on WORM HDDs. The people running those types of systems quickly got tired of having to do hardware replacements for every patch.
ESXi on SD-Card's with the physical write-lock is pretty popular ;)
* The installer lags unless you temporarily disable 3D acceleration until open-vm-tools are installed
* The Norwegian keyboard layout defaults to Dvorak, which I suspect isn't the most common one ;)
* The default installer resolution was a tiny 800x600. Click Activities and type Displays to get to the relevant settings.
Now for the more exciting stuff, like testing if Tailscale works out of the box.
I'm really looking for a dependable pseudo-desktop/server OS for the monolithic legacy box at home. In terms of immutable, NixOS is it right now, but tbh it's had enough random uptime issues as of late, I'm starting to doubt my decision. Though I still haven't narrowed it down to this machine as opposed to some network/routing/storage problem
I've been on it exclusively on my desktop and laptop for the past couple of months and have grown to like it a lot.
OpenVMS for x86_64 should come out for the community in May ;)
However in the meantime, try FreeBSD.
Sorry, our mistake. Several focus groups with Norwegians, left us assuming they thought in dvorak.
Will revert to qwerty.
I'm curious because I (an American) have been using Dvorak for longer than I'd ever used qwerty, so I would find this pretty interesting.
https://github.com/Vanilla-OS/ABRoot/ https://coreos.github.io/rpm-ostree/ https://github.com/ostreedev/ostree
My impression from the splash page is you're more encouraged to install packages to the base system. Silverblue only has that as the last resort (after flatpak, toolbox and podman).
From documentation, I'm not even sure how this is done. The only options for packages documented are platform-independent packages (Flatpak, etc) and apx (distrobox-based toolbox alternative).
It boots from a USB stick, loads system to a RAM disk, mounts configuration from a directory, and then hosts VM zones from ZFS datasets. The “root” system remains immutable.
To patch or upgrade, you just write a new system image to the USB stick and reboot. It’s great.
To skip the USB stick, you can do the whole thing over PXE.
After running a cluster on SmartOS for many years, moving back to Linux and installing the OS feels fragile, dirty, and weird.
PXE is its own hell, having local storage for the OS avoids some horror stories like "my whole cluster booted after a power outage and now PXE fails for everything".
Actually, as a natural tinkerer, what I call the "NixOS seatbelts" (being able to pick any of the last N updates via GRUB to boot into) have saved me numerous times already. I no longer feel comfortable using any other Linux distro. The declarative config and per-project dev environments are cake as well (once you get past the Nix language, which is basically just "JSON-like, plus pure functions")
I would much rather just version my nginx config written in nginx config, and let Nix pull that up, or something like that. Then you get all the benefits of Nix (I think?) but my configuration is also readable for someone who doesn't know Nix. Plus I can use my existing knowledge (as well as the wealth of online available docs), instead of something obscure.
(It also is where CoreOS got it from, before Red Hat bought them and the product largely disappeared, AFAICS.)
As such, I'd say it's an extensively field-tested and well-proven disk structure. :-)
Can't imagine the HN responses if this was Windows marketing text :)
I wasn't able to find any information on VanillaOS's support roadmap. Since the project's goal is to have stability of the underlying OS, it would be great if VanillaOS had an LTS-like support plan in mind.
What I do want to know is what package format is best for my use case: I want latest version of Python and other packages, and I am on Ubuntu, I dont want a new OS or docker. No idea which would be ideal or the pros and cons of each.
From a whole filesystem perspective I think it's not accurate to call this immutable though, as you can presumably work around this with bind mounts that can be used to mutate (but not persist) any part of the read-only filesystem while the system is still running.
If you like VanillaOS, you’d like https://docs.freebsd.org/en/articles/nanobsd/
In practice it never works well though: first immutable means far longer to update and these days updates are a continuous stream, secondly even if the system is really immutable the complete infra tend to be not, making the immutable part next to useless in reproducibility terms.
In modern terms a new concept born "idempotent" witch FORMALLY means "you can run it countless of time, it will works the same and do not even re-do already done steps, it ensure consistency of a system final state no matter the initial one". Such concept have more more practical applications, again in theory, but in practice it fail to be really idempotent beside trivial use cases. From mere Ansible Playbooks for an infra to NixOS idempotence is partially there but results tend to be not.
Long story short: IMVHO the road have a name DAMN SIMPLER DESIGN, simpler infra, as the sole way to keep anything working and easy to restore when it does not.
A bottomline: reproducibility for a server infra have some reasons, for desktops... Well... IMO it's a bit overrated in the era of "endpoint".
Correct me if I'm wrong, but don't they just mean they mount the root filesystem as read-only, and have a separate partition for /var and /tmp ?
That's a reasonable idea, although I'm not sure it merits an entire distribution. Is there anything else to Vanilla or is it just this?
> The GNOME Desktop is the perfect environment for your daily tasks
Maybe if you're a GNOME developer, and even then I kind of doubt it.
> designed to be a reliable
But it's based on ubuntu, which uses systemd, which is something not to be relied on, in many respects; see: https://www.without-systemd.org/wiki/index_php/Arguments_aga...
