Earlier quoted context omitted.
packages are namespaced in a directory for each package/version, like this: /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/ if a package is "installed" in an environment (it could be global, user local or temporary), its files are sym-linked in the "original" position (e.g. /usr/bin/firefox etc etc)
Small nitpick, they aren't symlinked to their original position, but instead to a "profile" (global for instance is in /run/current-system/sw, your local profile is $HOME/.nix-profile). This has several consequences. It means binaries distributed with the expectation of libraries being in their original position (e.g. /usr/lib/libc.so) don't work as is. It also means scripts depending on the presence of /usr/bin/bash…
Apricity OS: A Beautiful Arch Linux Distro
71–80 of 123 posts
Re: Apricity OS: A Beautiful Arch Linux Distro
#72This is a project developed by a high school senior. Yes he made rookie choices as have been pointed out here. If you like the direction of the project, contribute! It will help him learn.
I'm really sorry for being overly snarky, but where should one start contributing to this giant mess? It's basically a few packages packaged up in a questionable manner (with license violations[1] in the past), none of which are actually written by the developer himself. He is styling himself and the OS as a professional project (at least that's the vibe I get from the website[2]) and he is actually asking for money[…
(Plus when someone posts your GitHub repo to HN for some random reason, that disclaimer can save you a lot of hassle.)
Re: Apricity OS: A Beautiful Arch Linux Distro
#73Earlier quoted context omitted.
packages are namespaced in a directory for each package/version, like this: /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/ if a package is "installed" in an environment (it could be global, user local or temporary), its files are sym-linked in the "original" position (e.g. /usr/bin/firefox etc etc)
So basically, one could make this compatible with current Arch packages by making packages install into /nix/store/ instead?
nix packages are not exactly packages, as in rpm or deb files, they are expressions in a functional language (think build recipes). there is a central repository of recipes on github: https://github.com/NixOS/nixpkgs/tree/master/pkgs
but you can make your own, and eventually make a pull request. They are more similar to Arch's PKGBUILDs. Packages in the central repository are constantly built by a continuos built process (http://nixos.org/hydra/), that works both as a binary cache and as a testing system. This is an expression I wrote to install SuperCollider plugins https://gist.github.com/gosub/a42e265ec38d9df203d6 using the Arch PKGBUILD as a reference https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=sc3-p...
Re: Apricity OS: A Beautiful Arch Linux Distro
#74Earlier quoted context omitted.
I'm really sorry for being overly snarky, but where should one start contributing to this giant mess? It's basically a few packages packaged up in a questionable manner (with license violations[1] in the past), none of which are actually written by the developer himself. He is styling himself and the OS as a professional project (at least that's the vibe I get from the website[2]) and he is actually asking for money[…
I suggest the disclaimer route. Everything on GitHub really ought to have an indication in the README.md about why it is there. A single line saying "I'm just hosting it here and you've got no reason to ever use this" can be very helpful. (Plus when someone posts your GitHub repo to HN for some random reason, that disclaimer can save you a lot of hassle.)
> We are a Chicago based team of developers, dedicated to creating useful, intuitive software that helps people better integrate digital computing into their daily lives
The GitHub repository also proves it's not "we": https://github.com/agajews/ApricityOS/graphs/contributors
Re: Apricity OS: A Beautiful Arch Linux Distro
#75Things just break or otherwise don't work far too often.
So, kudos to the guy who put this distro together but without addressing this issue I don't think we're going to see an "easy to use" Arch-based distro any time soon.
I'm definitely speaking just as an onlooker and a novice here as I'm not involved in any open source development, but it feels like the whole Linux community would benefit from more rigorous API versioning and better documentation of interfaces between components. Even with distros that presumably do a lot of QA on their core packages like Fedora or Ubuntu, it feels like stuff breaks a LOT in Linux because of dependencies on the wrong versions of components. It must be a really tough problem.
Re: Apricity OS: A Beautiful Arch Linux Distro
#76Earlier quoted context omitted.
I suggest the disclaimer route. Everything on GitHub really ought to have an indication in the README.md about why it is there. A single line saying "I'm just hosting it here and you've got no reason to ever use this" can be very helpful. (Plus when someone posts your GitHub repo to HN for some random reason, that disclaimer can save you a lot of hassle.)
To be fair, he not only put up his code on GitHub, he also created a semi-professional looking and analogously worded website. That's not something that is posted to HN by "mistake". It sounds more like a startup than a hobby project: > We are a Chicago based team of developers, dedicated to creating useful, intuitive software that helps people better integrate digital computing into their daily lives The GitHub repo…
Re: Apricity OS: A Beautiful Arch Linux Distro
#77Eh, new defaults configurations do NOT merit a new distro. I've long believed this, and since I discovered NixOS it is now clear that there is away to avoid it.
Re: Apricity OS: A Beautiful Arch Linux Distro
#78[apricity-core] SigLevel = Never Server = http://apricityos.com/apricity-core/ This instructs the package manager (pacman) to load system packages over an unencrypted connection and disables all signature checks. Source: https://github.com/agajews/ApricityOS/blob/master/build/pacm... https://wiki.archlinux.org/index.php/Pacman/Package_signing#...
"This is what everyone throughout the world is attempting to do. Truth is narrowed down and made a plaything for those who are weak, for those who are only momentarily discontented. Truth cannot be brought down, rather the individual must make the effort to ascend to it. You cannot bring the mountain-top to the valley. If you would attain to the mountain-top you must pass through the valley, climb the steeps, unafrai…
Re: Apricity OS: A Beautiful Arch Linux Distro
#79Re: Apricity OS: A Beautiful Arch Linux Distro
#80Earlier quoted context omitted.
To be fair, he not only put up his code on GitHub, he also created a semi-professional looking and analogously worded website. That's not something that is posted to HN by "mistake". It sounds more like a startup than a hobby project: > We are a Chicago based team of developers, dedicated to creating useful, intuitive software that helps people better integrate digital computing into their daily lives The GitHub repo…
I was replying directly to embik (edit: which is, err, you, which I did not notice at first). I acknowledge and apologize that my parenthetical could look like I was talking about apricity, but I was not. I'm not taking the defense for apricity. Indeed I have a track record of recommending against young people doing things that will make people who trust them very, very angry when they can't follow through properly:…