Hacker News Reader

Comment by onlycommenting | Hacker News Reader

There's something interesting to be said here. "They make {{ package }} unusable by hijacking it's name space", well who gave them that name space? I understand the whole first come first serve and all but if we played that way things could get messy real fast.

There was recently an article on HN about the "Web of Hashes" and this article got me thinking about it. Why not give each application an UUID and let that be it's name space? Give the user an option to still use- they're example- xedit while having another xedit installed along side?

I can see how this could also get messy. Just spit balling here.

View on HN

> unusable by hijacking it's name space

That's not what was exactly written but is illuminating none-the-less (the original quote only says "name," which is a very different thing to "namespace"). Why do package managers have a single namespace to begin with? I should be able to install packages regardless of name conflicts, by using a namespace, e.g.

    $> apt-get install mdm
    Found org.debian.mdm and com.linuxmint.mdm.
    $> apt-get install com.linuxmint.mdm
    $> apt-get install org.debian.mdm

There's obviously the chance for a file system conflict, but the package manager should be able to keep track of that for you and abort if it would occur (or allow you to install it to a different prefix).

It's incredibly naive to believe that name conflicts would never occur, especially with the 3-letter acronyms/contractions that are so prevalent in Unix. I'd pin the blame this specific problem squarely on Debian, it shouldn't be happening in the first place.

Distributions manage the namespace of executables. Well, they're supposed to anyway... that's much of the complaint here about Linux Mint.

In Fedora (and most distros), programs with an executable name overlapping another program will be renamed to a unique name as part of the distro packaging. (Putting aside programs intentionally named the same thing because they provide the same function, which are managed differently via "alternatives".)

This puts some implicit pressure on creators of software to not reuse names that are already in use, which seems to work for the most part.

Gentoo handles this by categorizing packages into a format like app-editors/vim. This way packages in different categories can share the same name:

dev-lang/crystal (The Crystal Programming Language) games-mud/crystal (The crystal MUD client) x11-themes/crystal (Crystal decoration theme for KDE4.x)

When installing packages, if a package having a unique name across all categories, a simple "emerge vim" will install it. Otherwise, the category can be specified with "emerge dev-lang/crystal".

AppFS ( http://appfs.rkeene.org/ ) solves this (and all other packaging and distribution problems) by dividing the namespace along DNS lines.

That is you can run both:

     /opt/appfs/linuxmint.com/mdm/platform/latest/bin/mdm

and

     /opt/appfs/debian.org/mdm/platform/latest/bin/mdm

They are both always accessible (in other packaging systems you would refer to them as a "installed" since all their files may be read).

Check out NixOS

Personally I switched from Ubuntu to Fedora a couple of days ago because I've had it with Canonical. It was the first time I switched distro almost since I started using Linux (though I've admined servers with other distros and other OSes in the meantime). I am satisfied with Fedora thus far.

I absolutely love the concept of NixOS, but I haven't tried it out. Is it well-supported enough to use day-to-day as a developer? Do you often have to build things from source?

It's worth playing with to see if it could fit into your work; for instance, the Haskell ecosystem is very well supported, while Ruby seems to have issues. I am now using it for work on some of my projects. Generally you won't have to compile from source; that said I did recompile glibc when that last bug hit. (Security updates for core packages are not a great story now.) It's not perfect, but it's very hackable.

> Is it well-supported enough to use day-to-day as a developer?

Speaking as someone who knows the developer: no.

> Do you often have to build things from source?

There's ~6500 packages, so it's likely you'll be installing some stuff from source. It's really hard to predict without knowing specifics though. http://hydra.nixos.org/eval/1237359

If you track 'unstable' you generally don't need to build from source as that branch (or channel as Nix calls it) is updated only after everything has been successfully built on Hydra. There are sets of packages excluded from the build but I think those are mostly interpreted languages (emacs packages, etc).

It's generally well-supported enough so long as you don't need the latest and greatest packages within about a month of their release. They're having issues with their continuous integration system (the box it's running on isn't powerful enough and the project doesn't have money to get a new one), and there's occasionally breaking errors in important packages meaning a new version of the package repository doesn't get rolled out for a while, even if you're not using those packages.

Note that building from source is exactly the same process as building from binary - i.e. "nix-env -i firefox" will try to install from "cache" (the output of the continuous integration system's build process) and if it can't find something, build from source. Most important things are in the cache, some things aren't (mostly obscure packages and things with no-redistribution licenses), but in general it works out well.

I use it day-to-day as do some others in my company, and we also use it for all our cloud deployments. You have to relearn a number of things, like setting configs and so on, but on the other hand for nix pkgs it is nearly always a completely hands-off process regardless of whether you need to build from source or not (Nix handles that as part of the build, retrieving binaries from a remote cache is an optimization). I recommend giving it a shot!

Reply on news.ycombinator.com