NixOS - Declarative configuration OS

The "no scripting zone" and "no more installer magic" background posts have some of the philosophy.

But really a lot of the atomic and reliable aspects are the result of integration with ZFS. When the user upgrades packages, we create a backup boot environment (clone of the root file system) and then update the packages. If anything goes wrong, the user can just reboot to the backup be.

When updating the system (that is, packages that require the kernel to be reloaded/system rebooted), we create a clone of the root file system (a boot environment) and update the clone. When the update finishes, the admin can then reboot the system at their leisure.

If you'd like to know more, I'll try to answer your questions. You can email me at $myusername at gmail dot com.

Ya I very much doubt that. It just looks more people who barely do anything productive are on the Internet just using Youtube and Netflix. While the people who are developing say something like Youtube(or god forbid something more useful and complicated) are left to fend for themselves, because hey what do they matter.

We seem to be making the same unrealistically broad generalizations over and over, never learning from our past.

We seem to be heading for a future where every website says "Don't look at this, download our app!".

There are at least three reasons that won't happen:

1. Horses for courses: Once you get past superficial similarity, the Web isn't a universal application runtime. It is more appropriate for some kinds of apps, such as publication media, form-filling, etc. than others, such as apps with fine-grained interactivity, apps with significant endpoint computation, etc.

2. Nobody has cracked the "write once, test everywhere" curse of multiple implementations of a standard, never mind a standard as complex, and with such a long legacy tail as Web browsers. Web app frameworks still devote a lot of code to compatibility. "Native" also means "a single vendor's runtime."

3. Operating systems are different, and there are varying approaches to portability. Running in a universal runtime is one approach, and it has inherent compromises. For example, Microsoft has applications for editing Office documents for Windows, Mac OS X, and for Web browsers. Which one has limitations both in terms of integrating OS features and UI conventions, and it terms of functionality?

This is all too primitive. If we're heading in the direction that the GP describes, it's probably because some people have realized a long time ago that Alan Kay was actually making sense when he was talking about the object-based computational model as being something like "small computers all the way down". If your application is a set of objects implementing the functionality by passing appropriate messages between those objects, and the OS is another set of objects, providing all the necessary interfaces to applications in form of capability-exposing objects, then everything is virtualized by definition. Or, in other words, in such a system, you can virtualize (in the classical sense) as much or as little as possible.

Need two versions of the same library for two different applications? No problem, because each app gets its own inferface.

One app needs to accesses a physical block device and another a virtual one? No problem, because each app gets its own inferface.

Is the capability required by the app deployed on another machine and you want to expose it to the application transparently? No problem, because each app gets its own inferface.

And if the current hardware isn't amenable to running such systems with ease, well, that might have something to do with the fact that everything we're running has its roots in the 1980s. The unprecedented success of the PC revolution has essentially frozen all development of substantially new systems.

Interesting. I never knew PC-BSD did this. Been probably 10 years since I gave a BSD variant a try.

In my mind, it's a much better engineered solution to have a centralized, repeatable set of configurations than to have them spread out wherever in the filesystem.

I had a hell of a time installing something in Ubuntu that required a particular glibc version that was differnt to the system--wide one. Like I said, I'm not Linux expert and I probably missed a trick. I ended up using a different distro.

Would this new distro have helped?

Installing multiple versions is not the problem. The problem is configuring packages with respect to their dependencies.

Nix enables per user installations and different users can use different versions of a package. What Nix cannot do (as far as i know), is using multiple versions as the same user. For example, Flash once broke due to change in the GNU libc. Can Nix use a different libc version for a specific browser plugin?

Solaris' SMF and fault management framework is a very good step towards what you're after, plus it's mature and suitable for use in production.

http://www.oracle.com/technetwork/articles/servers-storage-a...

Don't let the XML configuration put you off. I suspect they'd have used JSON if they were doing it again, but it's from the era when XML was the default structured text based format.

If you want to play with this (and IPS as mentioned above), try OmniOS: http://omnios.omniti.com/

You might like a programming language I make, "NCD". See: https://code.google.com/p/badvpn/wiki/NCD

It follows a similar philosophy to Nix but for runtime management of processes and events in general. It's really functional though. But it is a bit declarative, with the implicit backtracking, the unique feature of NCD.

> I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons.

I ran in to this problem quite often when trying out science or numerical libraries and is one of the reasons I run mostly on nixos now.

Case in point: I had to upgrade some Debian VM's with Postgres 9.0 to Wheezy with Postgres 9.1 a while ago. They were messy combinations of mostly Etch + parts of Lenny and Squeeze, as a legacy of rushed upgrades. And while upgrading Debian version by version mostly runs smoothly with apt-get, there are some very nasty gotchas:

- You always need to upgrade apt and dpkg step by step, as if you're careless, you'll leave your system with an apt and dpkg that can't install most of the following upgrades, including the next available version of itself due to external dependencies on packages that are only available in a format your current version of dpkg/apt does not support. You then need to downgrade. Problem is you then run into utter dependency hell. Generally the solution is to --force-all install an older version of dpkg from /var/cache/apt/archives, then update and try again.

- If you're not very careful with the apt sources when doing a Postgres upgrade, you risk having Debian install 9.1 and remove Postgres 9.0. Problem is, if it removes 9.0, you can't run pg_upgradecluster, because that requires the old Postgres to exist and be running. Now, reverting is suddenly a big problem unless you add the Postgres teams own Debian repository.

This isn't particularly a criticism of Debian (though I dislike the fact that dpkg and apt-get have external dependencies - if there's anything that should be built statically, it's a package manager) - if you do things carefully, and step by step, things will work fine and you "only" need to learn a couple of rules of thumb (First, always make sure to upgrade version by version, apt-get update, apt-get install dpkg apt). These are hairy edge cases... But they'd be so much less of a problem with easy rollback and/or ability to pull in multiple versions easily.