Slashdot Mirror

This is somewhat unorthodox, and not a usual starter distro (so maybe a bit of a risky choice), but consider NixOS.

It is built on the Nix package manager, which has a rather unusual architecture allowing which allows multiple versions of the same package to be installed simultaneously. This means you can keep different NixOS system configurations at the same time. For a beginner the upshot of this is that NixOS can roll back updates if anything goes wrong, allowing you to experiment with more safety than with most.

At first you can use it in the imperative mode like most other distributions are used, typing commands as you go to install packages. Eventually you can switch to declarative configuration, allowing you to define a system configuration reproducibly in a set of files. This means to back up you whole system configuration, you can just backup the configuration files (this won't cover your data, but in linux this is as simple as copying your home folder).

The Nix Expression Language used to define configurations and packages is purely functional and lazy, so it may have a learning curve, but it is well made for its usecase: the Nix ecosystem allows for package and development environment configuration, deployment to the server / virtual machine / container with NixOps as well as disnix for distributed systems modeling for running clusters.

This is somewhat unorthodox, and not a usual starter distro (so maybe a bit of a risky choice), but consider NixOS.

It is built on the Nix package manager, which has a rather unusual architecture allowing which allows multiple versions of the same package to be installed simultaneously. This means you can keep different NixOS system configurations at the same time. For a beginner the upshot of this is that NixOS can roll back updates if anything goes wrong, allowing you to experiment with more safety than with most.

At first you can use it in the imperative mode like most other distributions are used, typing commands as you go to install packages. Eventually you can switch to declarative configuration, allowing you to define a system configuration reproducibly in a set of files. This means to back up you whole system configuration, you can just backup the configuration files (this won't cover your data, but in linux this is as simple as copying your home folder).

The Nix Expression Language used to define configurations and packages is purely functional and lazy, so it may have a learning curve, but it is well made for its usecase: the Nix ecosystem allows for package and development environment configuration, deployment to the server / virtual machine / container with NixOps as well as disnix for distributed systems modeling for running clusters.

This is somewhat unorthodox, and not a usual starter distro (so maybe a bit of a risky choice), but consider NixOS.

It is built on the Nix package manager, which has a rather unusual architecture allowing which allows multiple versions of the same package to be installed simultaneously. This means you can keep different NixOS system configurations at the same time. For a beginner the upshot of this is that NixOS can roll back updates if anything goes wrong, allowing you to experiment with more safety than with most.

At first you can use it in the imperative mode like most other distributions are used, typing commands as you go to install packages. Eventually you can switch to declarative configuration, allowing you to define a system configuration reproducibly in a set of files. This means to back up you whole system configuration, you can just backup the configuration files (this won't cover your data, but in linux this is as simple as copying your home folder).

The Nix Expression Language used to define configurations and packages is purely functional and lazy, so it may have a learning curve, but it is well made for its usecase: the Nix ecosystem allows for package and development environment configuration, deployment to the server / virtual machine / container with NixOps as well as disnix for distributed systems modeling for running clusters.

This is somewhat unorthodox, and not a usual starter distro (so maybe a bit of a risky choice), but consider NixOS.

It is built on the Nix package manager, which has a rather unusual architecture allowing which allows multiple versions of the same package to be installed simultaneously. This means you can keep different NixOS system configurations at the same time. For a beginner the upshot of this is that NixOS can roll back updates if anything goes wrong, allowing you to experiment with more safety than with most.

At first you can use it in the imperative mode like most other distributions are used, typing commands as you go to install packages. Eventually you can switch to declarative configuration, allowing you to define a system configuration reproducibly in a set of files. This means to back up you whole system configuration, you can just backup the configuration files (this won't cover your data, but in linux this is as simple as copying your home folder).

The Nix Expression Language used to define configurations and packages is purely functional and lazy, so it may have a learning curve, but it is well made for its usecase: the Nix ecosystem allows for package and development environment configuration, deployment to the server / virtual machine / container with NixOps as well as disnix for distributed systems modeling for running clusters.

This is somewhat unorthodox, and not a usual starter distro (so maybe a bit of a risky choice), but consider NixOS.

It is built on the Nix package manager, which has a rather unusual architecture allowing which allows multiple versions of the same package to be installed simultaneously. This means you can keep different NixOS system configurations at the same time. For a beginner the upshot of this is that NixOS can roll back updates if anything goes wrong, allowing you to experiment with more safety than with most.

At first you can use it in the imperative mode like most other distributions are used, typing commands as you go to install packages. Eventually you can switch to declarative configuration, allowing you to define a system configuration reproducibly in a set of files. This means to back up you whole system configuration, you can just backup the configuration files (this won't cover your data, but in linux this is as simple as copying your home folder).

The Nix Expression Language used to define configurations and packages is purely functional and lazy, so it may have a learning curve, but it is well made for its usecase: the Nix ecosystem allows for package and development environment configuration, deployment to the server / virtual machine / container with NixOps as well as disnix for distributed systems modeling for running clusters.

One thing I wish someone told me when I started out is that every programming language requires a specific development environment. Depending on the language this can include the compiler/interpreter, runtime environment, libraries, a language specific package manager, an IDE, various command line tools as well as plugins for other software. Hell, even the OS plays a role in this! Each of these components often have several flavors to choose from, so for any one language there can often staggeringly many possible development environments.

Personally I found that for the programming itself, there is usually ample guidance online in the form of manuals, documentation and Q&A sites like stackoverflow; my impression is that usually the development environment - being less canonical and more personal - is less documented, although usually there is some guidance about setting up a basic environment. So I would add to all the other good advice here that it is helpful to investigate the nature of the development environment in order to have it correctly set up to suit your personal preferences, much like arranging your workbench to your liking before crafting your widget.

Personally, in this context, I was recently very happy to discover the Nix package manager and NixOS, which allow you to create configuration files which define environments (for development or otherwise). This means you don't have to repeat a bunch of installation commands for every machine you want to develop or execute code in.

One thing I wish someone told me when I started out is that every programming language requires a specific development environment. Depending on the language this can include the compiler/interpreter, runtime environment, libraries, a language specific package manager, an IDE, various command line tools as well as plugins for other software. Hell, even the OS plays a role in this! Each of these components often have several flavors to choose from, so for any one language there can often staggeringly many possible development environments.

Personally I found that for the programming itself, there is usually ample guidance online in the form of manuals, documentation and Q&A sites like stackoverflow; my impression is that usually the development environment - being less canonical and more personal - is less documented, although usually there is some guidance about setting up a basic environment. So I would add to all the other good advice here that it is helpful to investigate the nature of the development environment in order to have it correctly set up to suit your personal preferences, much like arranging your workbench to your liking before crafting your widget.

Personally, in this context, I was recently very happy to discover the Nix package manager and NixOS, which allow you to create configuration files which define environments (for development or otherwise). This means you don't have to repeat a bunch of installation commands for every machine you want to develop or execute code in.

That sounds like the kind of thing Nix or its GNU sibling Guix would help fix. You can define a Nix expression that installs Eclipse and whatever else is needed, including any external software and even configuration files. The expressions are reproducible on any system with Nix (as long as the external downloads, like github commits, still exist) so once you have it defined once it's just a case of putting a Nix config file on any machines and calling nix-env -i my-dev-expression-name.

Hard part is getting it set up the first time, but even that should get easier over time by modifying an old expression with new project needs.

The news seems to be something like this:
- GNU has a package manager. Didn't know that.
- The package manager is functional in many ways.
- Because it's functional in many ways, it also sucks in some ways.
- They managed to reduce the suckage, which is good for them.

What would be news for me is something like this:
- Why do I care?

It's a relatively new thing (2012) so I'm guessing most haven't heard of it. The GNU folks took an existing package manager, Nix and modified it to use Guile Scheme instead of Nix's own language for describing functions (packages). You're right that it's functional (in the functional programming sense), which gives it its own set of pros and cons compared to traditional package managers.

As for why you might care, this comment on SN briefly covers what it means to be a functional package manager, including some of the pros and cons of it. It's about Nix, not Guix, but since Guix is based on Nix the information should apply equally to both. It's kind of long so I don't want to copy/paste the whole thing here, but it focuses heavily on the "why should I care?" aspect so it's worth a read if you're seriously curious about what's interesting about Guix or Nix.

Not mentioned in the writeup is that, because they're so new, documentation can be difficult to come by and it's all command line. Might be a mood killer for some, but I've found it worth the trouble so far.

Nothing as far as a distro (or desktop environment) with 3D VR or AI comes to mind but there is innovation in OS going on. Not many have attempted to answer the OP, so here's my list. Others mentioned Qubes, Urbit, and Mirage.io, which reminded me of Nix OS and HaLVM.

Both innovative and seems daily-driver ready:
1. Qubes OS - https://www.qubes-os.org/ - Linux distro that runs a Xen hypervisor to contain every app (including Windows ones) away from the desktop environment
2. Haiku OS - https://www.haiku-os.org/ - Tiny (under 200MB installed), Non-Linux that is binary-compatible with BeOS, nice understated GUI that is bland but usable
3. ReactOS - http://reactos.org/ - Win32 compatible open source OS, very active development scene working toward full NT kernel ABI compatibility. Seems stable enough to be a daily driver but hardware support is lacking
4. PC-BSD & freeBSD 10 - http://www.pcbsd.org/ http://www.freebsd.org/ - PC-BSD is a desktop distro of freeBSD 10 built for user-friendliness with automatic ZFS snapshoting and a nice graphical package manager, freeBSD 10 has a completely new package manager (pkg-ng replaces the 'pkg' binary)
5. Nix OS - https://nixos.org/ - Linux distro with innovative package manager promising atomic upgrades & rollback.

Innovative server-exclusive (ie no GUI):
5. SmartOS - https://smartos.org/ - Solaris + KVM + Docker w/ full Dtrace support. Claims ZFS as an innovation? Joyent is running a cloud of it
6. CoreOS - https://coreos.com/ - Linux distro exclusively for large Docker deployments. developing a suite of Go tools for datacenter management.

Innovative, but not ready for desktop use:
7. Redox OS - http://www.redox-os.org/ - OS written in Rust (rust-lang), which guarantees a lot of memory-safety, screenshots of desktop in 'News' section
8. Contiki OS - http://www.contiki-os.org/ - Linux distro for IoT embedded devices that claims an innovative network stack
9. Urbit - http://urbit.org/docs/user/int... - *nix distro with exclusively web-based userland, invite-only at the moment, doesn't seem like it will have a UI but that each user is the dev of their own interface
10. Mirage.io - http://mirage.io/ - Develop each app and compile into a single-purpose kernel to be run on some hypervisor
11. HaLVM - https://github.com/GaloisInc/H... - The Haskell Ligthweight Virtual Machine - which runs just the GHC on Xen, another 'build uni-purpose VMs' system

NixOS has a package manager that I think has a real shot at achieving scalability and repeatability in package management. Once something works in NixOS it will keep working on it's own, since specific versions of dependencies are tracked and can coexist, whereas in mainstream distros shit breaks all the time. The current model of freezing everything once in a while and patching up some of the most obviously broken stuff simply isn't keeping up with the pace of software development IMHO. http://nixos.org/ For a real moonshot OS/language/decentralize_all_the_things project, check out Urbit: http://urbit.org/

The hardest part is keeping an identical build environment. Nixos is specially designed to do so: https://nixos.org/

I really wanted something like Genode's micro-kernel and robust security and process isolation along with a pure functional package manager like Nix. Then Genode basically did that. I'm so excited. The other thing I wan't is a way to use it as my host OS and virtualize my existing windows stuff on it. That apparently working now too. I just need real VGA passthrough support (for decent windows gaming perf), then I'm buying hardware with IOMMU support and setting up my ideal frakenos. It's so close!

This approach https://nixos.org/nix/ joins the benefits of dynamic and static libraries. Applications are ELF files directly referencing the version of the library they want to use. Different versions of the same library can coexists on the same system, also of glibc in case. Containers on the same machine can too use the same repository of applications and shared libraries, with minimum overhead. I don't know how it is usable in production: I only started playing with it, but it is very sound from a theorical point of view.

I've always been curious about nixos.

Has anyone ever used it?

http://nixos.org/

https://nixos.org/nix/

Well, the three most popular package management systems for Linux, as far as I know, are .deb packages for Debian-based versions (usually managed with Advanced Package Tool -APT, or some GUI front end on APT), .rpm packages for Red Hat package-based versions (usually managed with Yellow Dog Update, Umodified - YUM, or some GUI front end on YUM), or Portage for Gentoo and Gentoo derivatives.

But while they work damn well for end users in practice, they are work intensive for package maintaners. There have been several attempts to innovate in package management for Linux by keeping the end user experience just as easy but make the developer burden lower.

I'm aware of Conary ( http://docs.rpath.com/conary/Conaryopedia/index.html ) which is used by Foresight Linux (a relatively unknown distribution) and rPath Linux, and which uses revision control system concepts like changesets to reduce upgrade download sizes just like git does, and which also tries to have better naming conventions for package sources, source build number, package build number, and branch so that the developer has less work than with .deb or .rpm building the package. I say tries to be better because I'm not familiar enough with any of the package systems to know for sure if Conary really is superior. But in any event it's seven years old or so and has relatively little public adoption.

For even more obscure package control, there's the Nix package manager and NixOS ( which as you can guess is a Linux distribution that uses Nix ). http://nixos.org/ I think Nix is a serious attempt at building a .deb and .rpm replacement, just like Conary, but as far as I can tell it's got even less adoption and interest.

In any event, the idea that we've already reached ideal package managers in maintream Linux is absurd. Obviously what we have now is better than manual dependency management with tar.gz archives of source and binary packages, but I'm sure better designs exist or could be built. The question is whether Conary or Nix or anything else really are those better designs, and whether the better designs are so much superior that it's worthwhile to switch.

This just goes to show the shocking lack of innovation and forward thinking in open source software. Some people have, in fact, put in long hours to work out the conflicting libraries problem. Some people have, in fact, come up with creative and cutting-edge solutions, such as designing a referentially transparent formal DSL precisely for that, with non-destructive updates, such as this project:

http://nixos.org/nixos/

Instead, what we see is open source once again emulating the bad parts of Windows (but, to be fair, a good amount of innovation has been coming out of Microsoft: it adopts formal methods for driver verification, PowerShell (years ahead of anything on Linux), and pushes language innovations such as F# and the newer features C# has).

Advanced projects such the Nix package management system seem simply go way over the heads of the Unix gurus, the gray neckbeards and the not-so-old, that insist very much on older programming paradigms.

That's an interesting proposition. A similar idea has been realized in the research Linux (and Hurd) distibution NixOS.

"In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this."

http://nixos.org/nixos/

I just stumbled upon it recently. I have not tried it.

Another option is using a package system that properly handles dependencies. http://www.nixos.org/, for example, allows multiple Perl versions, multiple CPAN trees - and even within CPAN different module dependencies. That makes for predictable deployment, and can help development too when testing diffferent CPAN dependencies. Interestingly Nix can be used inside Debian. I have it on all my systems to test different setups. Way to go Nix! There is also an article on linux.com.

Dependency problems will be solved RSN, probably, by Nix OS.

http://nixos.org/nixos/

"NixOS is a Linux distribution based on Nix, a purely functional package management system. NixOS is an experiment to see if we can build an operating system in which software packages, configuration files, boot scripts and the like are all managed in a purely functional way, that is, they are all built by deterministic functions and they never change after they have been built. Such an operating system should have all the nice characteristics that the Nix package manager has:
The entire system kernel, system services, configuration files, etc. is built by a Nix expression in a deterministic and repeatable way.
Since configuration changes are non-destructive (they donâ(TM)t overwrite existing files), you can easily roll back to a previous configuration. For instance, the Grub boot menu in NixOS allows the user to boot into any previous system configuration that hasnâ(TM)t been garbage collected yet. This is very nice if something goes wrong.
Upgrading a configuration is as safe as installing from scratch, since the realisation of a configuration is not stateful. This is a result of being purely functional.
Multi-user package management any user can install software through the same mechanisms that the administrator uses. This is not the case for most package managers such as RPM.

Furthermore,
NixOS allows us to verify that Nix packages are really pure. Nix prevents undeclared dependencies between packages in the Nix store, but when you run Nix on an existing OS such as SUSE Linux, Nix cannot prevent a build script from (say) calling programs in /bin. If there is no /bin, such a build script will fail."

Problem: nobody gives a shit. Because, you know, eeewwwww, they said "functional." I personally would not expect anything smart to come out Debian. Their technology stalled in the 90s.