> Many people are happily using it, and are quite enthusiastic about it, > so evidently it's "usable". That doesn't imply that it's good for > everyone. Perhaps you would prefer a more traditional distro, or one > that has had more time to mature. If so, that's okay. I can say that on almost any dying distro like slackware or so. But we need to overcome the issues which are leading to dead projects/distros. The above issue is one of them if left without solution. Mark H Weaver: > bo0od writes: > >> > I mean the ‘outrageously’ part. When Linux runs out of memory, it >> > freezes up. Moral judgment is futile. Better to adopt raingloom's >> > earlyoom suggestion or similar. >> >> Im using default guix system nothing special, If this package usable to >> solve these stuff i suggest then to include it by default. > > 'earlyoom' behavior is not necessarily desirable. I, for one, have a > fairly old computer by today's standards, and sometimes I ask it to do > intensive things that are at the edge of its capabilities, such as > compiling GNU IceCat. An aggressive 'earlyoom' might prematurely abort > jobs that could have completed, and thereby make it impossible for me to > continue using this old computer for development. > > With that in mind, it's far from clear that 'earlyoom' should be our > default behavior. It's good to have it as an option, though. > >> > 4 GiB is absolutely not enough to build an outrageous amount of ‘modern’ >> > software, especially in parallel (so not using --cores=1 --max-jobs=1) >> > to make use of those expensive cores. >> > >> > I'm disgusted too. >> >> Yes it is, But you know this cant be a way of life with guix for end >> user no? Something by default should solve this matter otherwise this is >> not usable distro. > > Many people are happily using it, and are quite enthusiastic about it, > so evidently it's "usable". That doesn't imply that it's good for > everyone. Perhaps you would prefer a more traditional distro, or one > that has had more time to mature. If so, that's okay. > > Regards, > Mark >