>>16
wow, only a true moron could admit he doesn't understand something, but also present his opinions on it as objective truth in the same post
first of all, guix is not ``basically a package manager for guille''. that's like saying guix is ``basically package manager for emacs'', which would actually be closer, because people actually mention and recommend switching from package.el and friends to managing emacs packages with guix, but still fucking stupid. guix is a functional package manager that solves (at least in theory) issues such as dependency rape and inability to confirm whether binary was really generated from given source code. the main differences between it and nix, its predecessor, being that it uses dialect of scheme instead of dsl, and doesn't accept proprietary software into its main repository
second of all, why the fuck would you ``fork the project'' to ``develop your special distro with startx enabled''? are you brain damaged? do you understand the words you are using? why the hell would you fork the project, when the facilities to use startx are in it already, and the question in OP was why it's not an option in the installer, since it costs pretty much nothing to add it there, because as mentioned earlier, the facilities are there, and it's not difficult to do
i'd recommend you lurk 50 years before posting
>>17
i don't see it ever having wide, long-lasting adoption, because to be frank, the bar to get into it is pretty high for somebody with no prior knowledge of lisp or functional programming, and the problems it solves are realistically already covered by other tools in the industry. it's a neat, but ultimately hobbyist thing.
also i think the guy you linked to misses the point of reproducible builds. as long as the build is deterministic (the source doesn't have any randomness in it), it should produce the same hash every time. to verify this, you don't need to build the package yourself, you can just use guix challenge to verify. the trust of course lies somewhere, but with packages being equivalent to source code that generated it, you always have the possibility to challenge it by reading the source code, instead of putting your full trust into a vendor without being able to do any verification (as it would be with signing keys). being able to download packages over unsafe networks is a nice boon as well.
>>18
the further you go from the popular, accepted solutions, the more raped you get when things go wrong. there's no support license you can buy as far as i know, therefore if something you need to do doesn't really benefit the project in any way, you might not get the help you require to solve the problem. guix being sufficiently different from other linux distributions, and also niche, means that integration with existing tooling might range from difficult to straight up impossible, furthermore it will be harder to find employees that will be able to manage such servers, so you will need to train them. therefore i'm of opinion that no amount of knowledge on guix will fully save your ass if things go really wrong