I'm not sure how easy it is to maintain a system with extra packages like this, but it'd be nice to be able to use an "overlay" repo as you can in Gentoo for personal/custom packages.
Would love to ping davexunit to see if he can elaborate, because I don't see any specific way to add repositories from the documentation.
Ahh, well, then it appears I have to manage a directory of packages myself, as well as any dependencies outside of the Guix store, right? Would be nice to just have a secondary source, as I do with MELPA for Emacs, or overlays for Gentoo.
Is something similar/comparable planned to be added?
Orrr should someone step forward and volunteer to add it as a feature...?
Clojure worked for me until I started to do parallel programming. I tried to use core.async but immediately found that I'm using two distinct style of programming, and code reuse became a serious problem.
I didn't find any resources on how other Clojure programmers deal with this problem, but this eventually lead me to drop Clojure and Clojurescript, and use Elixir and Elm instead.
If we were going to completely rely on flatpak to solve our problems, we would be able to break ABI every 6 months w/ each GTK release. But that is not a tennable solution today (or likely ever). Distributions ship desktops which will have applications that naturally live outside the flatpak runtimes.
Just so I understand, would the ideal goal in that scenario be fat app packages or maybe even statically linked apps? If the API/ABI support scheme as blogged about is adopted, maybe that's the practical solution.
Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full. If that's true, it certainly doesn't sit well with me, if I consider how and why I've been using Linux for 19 years. I've never been able to use a desktop environment because they're always limited and do not allow me to express my way of working like my old FVWM config or current XMonad config do. It's like the difference between SublimeText and Emacs users. Different needs mean different types of users and Gtk and Qt must stay GUI toolkits, two among many.
> Am I wrong, or does this sound like GNOME's trying to be a more central runtime and subsume parts of a linux distro in full.
I don't think so, but GNOME does have a long history of diving down the stack and fixing problems when we run into them in lower levels. Of course, fixing long standing bugs that are often depended on corner-cases is certainly going to require additional engineering (the current tmux/screen situation comes to mind).
These things are largely a thankless task, and often a hostile process. Everyone seems to want their bug fixed, and nobody elses.
We very much need everyone interested in our shared commons to come to the table and discusses their needs. Otherwise it's not a commons.
Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
The good news is that with V8 and ES2015, we now have a formalized, (fairly) fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and it runs natively on devices owned by literally billions of people.
He is the author of one of the popular Erlang books and here talks about using Nix in production instead of just pure langauge specific package managers (or OS package managers).
Some really good insights on immutability, reproduceability, and of course real production use examples.
Yes Nix, but Nix that uses IPFS (https://ipfs.io) as a distribution medium for packages. This was a package will stay published as long as someone is using it.
Yeah, they're getting there. The binary package cache is a start. If it cached upstream tarballs and git revs as well as builds, it would mitigate the sort of thing the OP talks about.
Nix still needs some sort of distributed trust model, though. Without that, nixos.org is a single point of failure.
The thread mentioned that leaving Github would mean losing visibility / discoverability. Just wonder why people rely so much on Github for that. Maybe all we need is a a search engine / directory for open source projects?
See Wikipedia [1]. Movable type was first invented in China around A.D 1040, about four hundred years earlier than in the western world.
In Qing Dynasty, the government used it to print 64 sets of the encyclopedic Gujin Tushu Jicheng. Each set consisted of 5040 volumes, making a total of 322,560 volumes printed using movable type.
It should be noted that this Qing Dynasty encyclopedy was printed in 1726, seven centuries after the invention of movable type and more than 270 years after Gutenberg's Bible. It is also a Government sponsored project and probably wasn't cheap. The point still stands that compositing a book was far more labor intensive with chinese characters than with any alphabet. You need a few dozen types for an alphabet and at least 100 times more fore Chinese. An alphabet makes it considerably cheaper and not reserved to a tiny elite with 64 copies. That's the main point. Common people couldn't afford it.
There is no doubt possible that using an alphabet greatly helped the dissemination of knowledge. Between 1455 and 1500 there were over 30,000 distinct incunables edited in europe. Not 30,000 copies. More than 30,000 different books. [1]
Gutenberg's press went viral [2] and vastly more widespread than what was seen in Asia.
In the 15th century Korea adopted Hangul, the Korean alphabet.
"A potential solution to the linguistic and cultural bottleneck that held back movable type in Korea for 200 years appeared in the early 15th century—a generation before Gutenberg would begin working on his own movable-type invention in Europe—when Sejong the Great devised a simplified alphabet of 24 characters (hangul) for use by the common people, which could have made the typecasting and compositing process more feasible. Adoption of the new alphabet was stifled by Korea's cultural elite, who were "appalled at the idea of losing hanja, the badge of their elitism."
"It was effective enough at disseminating information among the uneducated that Yeonsangun, the paranoid tenth king, forbade the study or use of Hangul and banned Hangul documents in 1504,and King Jungjong abolished the Ministry of Eonmun (governmental institution related to Hangul research) in 1506.
The late 16th century, however, saw a revival of Hangul" [3]
