Re: UTF-8 progress bar
Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > The characters displayed correctly in my Linux virtual console VT2 > after I ran this command in Bash: > > setfont > /gnu/store/iga6jf0krlh135zca7y6f1f7c4ar32z2-font-gnu-unifont-15.0.01-psf/share/consolefonts/Unifont-APL8x16.psf.gz Thanks, it worked! -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: UTF-8 progress bar
Julien Lepiller writes: > Hi Guix! > > I have a patch waiting (https://issues.guix.gnu.org/59975) that will > change progress bars to use some unicode characters. I think they look > better, but I'm a bit afraid they might not look right on some config, > so I'd like to know if your terminal is able to show these characters: > > "▏▎▍▌▋▊▉█▏▕" > > If you are not using a unicode locale, this change will not affect you > as guix will fallback to the ascii style. If your terminal can't show > these characters and you have a UTF-8 locale (you'd run echo $LANG to > know that), please report your config (name of terminal app, locale, > fonts, …)! > They won't work in Linux (kernel) console, despite $LANG="en_US.utf8". -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Packages grow, no longer fit on a 💾
b...@bokr.com writes: > On +2023-01-20 23:34:53 +0600, Akib Azmain Turja wrote: >> Csepp writes: >> >> I have a slow machine from about 10 years ago, and I'm really happy with >> it. (I'm writing from this machine.) I also have a slow unstable >> internet connection, so I understand the pain of download hundreds of >> MB of data without pause and resume support. (I couldn't download the >> latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying >> 8-10 times.) >> > > Could you somehow use > wget -c > to continue an interrupted download? > Or does the source not support that? Yes, the infamous https://ci.guix.gnu.org server. > > (see wget --help |less -- and scroll down to Download: section) > >> -- >> Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 >> Fediverse: akib@hostux.social >> Codeberg: akib >> emailselfdefense.fsf.org | "Nothing can be secure without encryption." > > -- > Regards, > Bengt Richter -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Packages grow, no longer fit on a 💾
Csepp writes: [...] >>> It strikes me that this is like King Canute holding back the >>> tide. Package size growth is pretty inevitable, and even if work now >>> can bring the size down to that of a CD, the same problem will occur >>> in the not too distant future. >>> >> >> But we should really try to keep them low. >> >>> Is it really a problem? >> >> YES! >> >> Big packages means, it takes more space. If a package grows by 700 MB, >> installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted. You >> could use that precious storage to save your dad's photo, your favorite >> music, your child's video calling you "daddy/mummy" for the first time, >> etc. You would need to get more storage for that storing those >> invaluable things, so you would need more storage devices. When you buy >> more storage, the demand of increases, and therefore the manufacturing >> of storage devices increase. The more devices are manufactured, the >> more carbon dioxide and other greenhouse gas emission. >> >> Again, if the packages is downloaded 100 times every day, ~70 GB (7 >> MB) of bandwidth is wasted every day. Someone on the network could use >> that to do some more important thing, like video calling a relative >> living far away. Moreover, it takes time to get the extra 700 MB for >> everyone. Assuming it takes 8 minutes on average, ~13.33 hours (800 >> minutes) of time is wasted everyday. We have limited time in our lives, >> we shouldn't waste the time. This extra ~70 GB of transmission means >> more load on the network, more load on the network devices, and >> therefore more power consumption. The more power consumption, the more >> greenhouse gas emission, since we're fossil fuel dependent. If your >> country uses nuclear power, the extra nuclear waste is a threat for the >> environment. >> >> The more greenhouse gas, the more greenhouse effect, the more global >> warming, the more climate change. You will just destroy the earth for >> future yourself and the future generation. What will you answer to >> them? >> >>> Please educate me! :) >> >> It's my pleasure to make someone aware. >> I hope this was enough. :) >> If not, just ask! >> >>> >>> -- >>> Paul >>> >>> > > Well said. Gonna add to this that developers are overwhelmingly from > privileged backgrounds. Just because we don't have a lot of users on > the mailing list who have to use satellite internet on ancient laptops > does not mean those (potential) users are not out there and wouldn't > benefit from our distro not being a bloated mess. Which sadly it kind > of is currently. I wholeheartedly recommend trying to use it on an old > netbook or an armhf device from time to time. > Like others have said: if you want to develop efficient software, use a > slow machine. :) I have a slow machine from about 10 years ago, and I'm really happy with it. (I'm writing from this machine.) I also have a slow unstable internet connection, so I understand the pain of download hundreds of MB of data without pause and resume support. (I couldn't download the latest Guix GNU/Hurd QEMU image (just around 293 MB maybe?) even trying 8-10 times.) -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Packages grow, no longer fit on a 💾
it takes more space. If a package grows by 700 MB, installed on 10,000 computers, ~70 TB (70,000,000 MB) is wasted. You could use that precious storage to save your dad's photo, your favorite music, your child's video calling you "daddy/mummy" for the first time, etc. You would need to get more storage for that storing those invaluable things, so you would need more storage devices. When you buy more storage, the demand of increases, and therefore the manufacturing of storage devices increase. The more devices are manufactured, the more carbon dioxide and other greenhouse gas emission. Again, if the packages is downloaded 100 times every day, ~70 GB (7 MB) of bandwidth is wasted every day. Someone on the network could use that to do some more important thing, like video calling a relative living far away. Moreover, it takes time to get the extra 700 MB for everyone. Assuming it takes 8 minutes on average, ~13.33 hours (800 minutes) of time is wasted everyday. We have limited time in our lives, we shouldn't waste the time. This extra ~70 GB of transmission means more load on the network, more load on the network devices, and therefore more power consumption. The more power consumption, the more greenhouse gas emission, since we're fossil fuel dependent. If your country uses nuclear power, the extra nuclear waste is a threat for the environment. The more greenhouse gas, the more greenhouse effect, the more global warming, the more climate change. You will just destroy the earth for future yourself and the future generation. What will you answer to them? > Please educate me! :) It's my pleasure to make someone aware. I hope this was enough. :) If not, just ask! > > -- > Paul > > -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Packages grow, no longer fit on a 💾
Ludovic Courtès writes: > Hello! > > Over the course of a few years, the size of our packages has apparently > kept growing. Example: Unless the right steps are taken at right time, the size of packages will reach the largest real number in near future. > > $ guix time-machine --commit=v1.2.0 -- size emacs > store item totalself > /gnu/store/118xpdazyylxa1rlc68h9lmh38vhxrb4-llvm-10.0.0210.8 > 139.3 16.2% > /gnu/store/1qmd9achfkm1njzxf8hi86q53pmy9sxk-mesa-20.0.7369.2 > 131.3 15.3% > /gnu/store/d83hc7cqgnhl1vlz1rv4ibkvaqaq2g35-emacs-27.1 859.7 > 106.2 12.4% > /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8 > 53.2 6.2% > /gnu/store/9lckq1194qcy4a7kv8bihagd58shj7yr-gtk+-3.24.20 723.7 > 49.0 5.7% > /gnu/store/qizplwwgqwyq6qmz1i6jlaib5kgzrgwq-icu4c-66.1 110.2 > 38.1 4.4% > /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 38.4 > 36.7 4.3% > […] > total: 859.7 MiB > $ guix time-machine --commit=v1.3.0 -- size emacs > store item totalself > /gnu/store/g3idjpqsp2p2d163qfzskxj4k58nrx7f-llvm-11.0.0220.0 > 148.6 16.9% > /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa-20.2.4389.1 > 141.6 16.1% > /gnu/store/7nlq2v4000pw8vgj3m4vrwz072ib58xh-emacs-27.2 880.5 > 106.4 12.1% > /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2132.8 > 53.2 6.0% > /gnu/store/czf23hay13pp25yzrb4yq3n4gcri5r70-gtk+-3.24.24 744.3 > 49.1 5.6% > /gnu/store/2wqjj3mkqdvsvksndr2hpjpi7qqwi7kr-icu4c-66.1 110.2 > 38.1 4.3% > /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31 38.4 > 36.7 4.2% > […] > total: 880.5 MiB > $ guix time-machine --commit=v1.4.0 -- size emacs > store item totalself > /gnu/store/i11jmrc90drpx9mc6cyb6s4pjny91qx6-emacs-28.21592.7 > 250.6 15.7% > /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6 > 169.6 10.6% > /gnu/store/6pdzpmxg5afzss6dlivq8z84sfa31x22-llvm-11.0.0221.5 > 149.5 9.4% > /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0 244.8 > 128.5 8.1% > /gnu/store/pfas3c4lhr1jwkj2gl0yx8dg4xjjlp4r-mozjs-91.13.0 261.2 > 65.4 4.1% > /gnu/store/hy6abswwv4d89zp464fw52z65fkzr7h5-perl-5.34.0147.7 > 58.6 3.7% > /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37 126.0 > 54.4 3.4% > /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7129.1 > 52.0 3.3% > /gnu/store/4aq7hw017s9ihpm1rxpwfz28c80569z9-gtk+-3.24.30 1002.2 > 48.6 3.1% > /gnu/store/vaxkf8cbc7slgc3ikm5qr3815wih93w8-ghostscript-with-cups-9.54.0 > 219.139.1 2.5% > /gnu/store/bjycxjjkp1da53ijsa4hfdrz9mcgg55h-icu4c-69.1 110.7 > 38.0 2.4% > /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33 76.6 > 36.6 2.3% > […] > total: 1592.7 MiB > > I think something went wrong here. :-) > > In particular with Emacs itself (due to JIT + dependency on libgccjit, > Binutils, etc.?) and with GTK+ (due to mozjs in polkit?). > > And then MESA and LLVM have always been problematically big. > > We should do better. I mean, it’s just a text editor, isn’t it? > > Ludo’. > No, Emacs is more than a text editor. If you need just a text editor, use ED. ;) But, well, I must confess, native compilation takes *A LOT* of time. -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Should a Guix package include documentation dependencies to be considered complete?
jgart writes: > Hi Guixers, > > For example, > > https://github.com/Abjad/abjad/blob/63520b2a00ef59f3302837f843d069c3946baa6c/docs/Makefile#L113 > > We have abjad packaged but we don't necessarily have all the > dependencies needed to build everything that abjad provides such as a > PDF document that it mentions in its project Makefile. > > Should we include the LaTeX dependencies in the abjad package? > > Should all Python packages include the required dependencies to build > documentation? > > We currently include all the dependencies to run the tests, why not do > the same for documentation building? > > Should we make it a requirement or goal to always package a given package's > "documentation-inputs"? > > There's another thread where I already talked on this topic with roptat > briefly. I'll find it and link it soon. > Is it just limited to the documentation files, or does it also include softwares needed to read them? -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: guix emacs package MELPA/ELPA
Arvid Krein writes: > Hello guix-devel, > > this is my first time writing to this list so I hope I am at the right > place. > I noticed that the guix package for emacs was moved from being > developed at Github/Gitlab to Savannah. There is the guix package Thanks for letting me know, I thought guix.el was just dead. > 'emacs-guix'. Some people (including me) would rather use the MELPA or > ELPA package repositories for emacs. I noticed that the guix.el > package in MELPA is still refering to the old locations on > github/gitlab which are unmaintained and do not work. > I will try to get the location fixed in MELPA. But since the package > has moved closer to the guix project (if I understood it right) would > it maybe make more sense to host it on ELPA (since it is the GNU > repository)? I do not really know anything about emacs packaging which > is why I am asking. > > Greetings > > Arvid > GNU ELPA (elpa.gnu.org) is not the correct place for guix.el. GNU ELPA is for the packages that are part of GNU Emacs but not distributed with Emacs; therefore FSF holds the copyright of those packages. NonGNU ELPA is the correct place, it is for all types of free software Emacs packages that are not part of GNU Emacs. I'm CC'ing emacs-devel list, with hopes that someone will give a better explanation, or correct me. -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Guix Ncurses Interface?
jgart writes: > Is anyone interested in having an emacs-agnostic ncurses interface for > some aspect of the Guix APIs? > > One thing I thought of just now is a nice transitive dependency explorer > ncurses interface. > > `guix install dag-tui` > > Forgive me Ambrevar, > > jgart > Nice idea. Any resources except emacs-guix source code? -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption." signature.asc Description: PGP signature
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
Joshua Branson writes: > (I mean it > works on the Hurd also, but I have never encountered a Hurd user in real > life) Really? I found tons of bugs in the Hurd port, causing it to not even boot properly. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
Ludovic Courtès writes: > Hi, > > Akib Azmain Turja skribis: > >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >>> >> >> Why "address spaces" is a revolutionary technology? All kernels (except >> the "Hello, World!" ones) use it. > > That was an ironic remark from my part. Virtual memory management and > address spaces are not revolutionary at all: that’s how we protect > processes from stomping onto each other’s toes since the 70’s. > > If the goal really is to improve OS reliability through a > multi-person-year effort, then I believe pouring that effort into a > microkernel-based design would be more fruitful. My 2¢! > > Ludo’. I agree, but it's very hard because the hardware vendors tend to keep things secret, and unfortunately there isn't enough people interested in Hurd. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
jbra...@dismail.de writes: > July 5, 2022 12:48 AM, "Akib Azmain Turja" wrote: > >> jbra...@dismail.de writes: >> >>> July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: >>> >>>> Ludovic Courtès writes: >>> >>> Hi! >>> >>> Leo Famulari skribis: >>>> The effort to use the Rust programming language within the Linux kernel >>>> is progressing and may be realized in the next few months: >>>> >>>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >>>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >>>> >>>> Within Guix, we'll need to adapt our kernel build processes in order to >>>> support this. >>>> >>>> Although I help with updating and configuring the kernel builds, I won't >>>> be able to participate in the "Rust in the kernel" effort for Guix. >>> >>> Understood… >>>> So, interested volunteers should begin organizing :) >>> >>> Yup! >>> >>> Now, concretely, how long will it take before key parts of the kernel >>> are written in Rust? Hopefully a long time, no? Per the article above, >>> it’s starting small, with Rust usage in well-defined locations. >>> >>> This is not to say that we shouldn’t start organizing, but rather that >>> we still have a bit of time ahead. >>> >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >>>> "Address spaces"! What's that? Sorry for asking without searching the >>>> internet first, but the Hurd designers are so creative that a few >>>> understand the concepts and join the community, so there is a little >>>> chance (if any) that I'll find any useful information on that. >>> >>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html >>> >>> The Hurd is built in a very modular fashion. Other Unix-like kernels >>> (Linux, for example) are also modular in that they allow loading >>> (and unloading) some components as kernel modules, but the Hurd goes >>> one step further in that most of the components that constitute the >>> whole kernel are running as separate user-space processes and are thus >>> using different address spaces that are isolated from each other. >>> This is a multi-server design based on a microkernel. It is not >>> possible that a faulty memory dereference inside the TCP/IP stack >>> can bring down the whole kernel, and thus the whole system, which >>> is a real problem in a monolithic Unix kernel architecture. >>> >>> Some visual explantions: >>> >>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg >>> >>> The Hurd is on the right in this image. >> >> Thanks, now I understand Ludo' was saying about virtual address space, >> achieved using paging. >> >>> Essentially, if your fileserver somehow gets hacked, the attacker >>> cannot magically access your TCP/IP stack, because your TCP/IP is not >>> in the some "software zone" as your fileserver. So microkernels like >>> the Hurd are usually considered more secure and better designed >>> than monolithic kernels like Linux. However, monolithic kernels >>> will usually be faster than microkernels. >> >> I know microkernels are theorically slow due to the heavy use IPC. But >> is it really impossible for well written microkernel to beat a well >> written monolithic kernel? L4 is super-fast, is it still slower than >> Linux? > > Probably a little, but I am not an expert in that area. > > GNU Mach, which is what the Hurd runs on. Is slower that Linux. > There was an attempt to port the Hurd to L4 before. It is > deemed not possible by the current hurd developers. Yes, I know that Mach is one of the slowest kernels. BTW, what's the status of Viengoos? > > >> >>>> -- >>>> Akib Azmain Turja >>>> >>>> This message is signed by me with my GnuPG key. It's fingerprint is: >>>> >>>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 >> >> -- >> Akib Azmain Turja >> >> This message is signed by me with my GnuPG key. It's fingerprint is: >> >> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
Ludovic Courtès writes: > Hi! > > Leo Famulari skribis: > >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. > > Understood… > >> So, interested volunteers should begin organizing :) > > Yup! > > Now, concretely, how long will it take before key parts of the kernel > are written in Rust? Hopefully a long time, no? Per the article above, > it’s starting small, with Rust usage in well-defined locations. > > This is not to say that we shouldn’t start organizing, but rather that > we still have a bit of time ahead. > > (During that time, interested readers can also take a stab at improving > support for the Hurd, which relies on that revolutionary technology > called “address spaces” to ensure Memory Safety™ among other things!) > > Ludo’. > Why "address spaces" is a revolutionary technology? All kernels (except the "Hello, World!" ones) use it. By the way, what basic features are lacking (read available) in the Hurd port? Last time when I checked the pre-built disk image, I found that it completely breaks after a reboot. I mailed at help-guix list[1], but got no response. [1]: https://lists.gnu.org/archive/html/help-guix/2021-09/msg00043.html -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
jbra...@dismail.de writes: > July 4, 2022 1:36 PM, "Akib Azmain Turja" wrote: > >> Ludovic Courtès writes: >> >>> Hi! >>> >>> Leo Famulari skribis: >> >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. >>> Understood… >> >> So, interested volunteers should begin organizing :) >>> Yup! >>> >>> Now, concretely, how long will it take before key parts of the kernel >>> are written in Rust? Hopefully a long time, no? Per the article above, >>> it’s starting small, with Rust usage in well-defined locations. >>> >>> This is not to say that we shouldn’t start organizing, but rather that >>> we still have a bit of time ahead. >>> >>> (During that time, interested readers can also take a stab at improving >>> support for the Hurd, which relies on that revolutionary technology >>> called “address spaces” to ensure Memory Safety™ among other things!) >>> >>> Ludo’. >> >> "Address spaces"! What's that? Sorry for asking without searching the >> internet first, but the Hurd designers are so creative that a few >> understand the concepts and join the community, so there is a little >> chance (if any) that I'll find any useful information on that. > > From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html > > The Hurd is built in a very modular fashion. Other Unix-like kernels > (Linux, for example) are also modular in that they allow loading > (and unloading) some components as kernel modules, but the Hurd goes > one step further in that most of the components that constitute the > whole kernel are running as separate user-space processes and are thus > using different address spaces that are isolated from each other. > This is a multi-server design based on a microkernel. It is not > possible that a faulty memory dereference inside the TCP/IP stack > can bring down the whole kernel, and thus the whole system, which > is a real problem in a monolithic Unix kernel architecture. > > Some visual explantions: > > https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg > > The Hurd is on the right in this image. Thanks, now I understand Ludo' was saying about virtual address space, achieved using paging. > > Essentially, if your fileserver somehow gets hacked, the attacker > cannot magically access your TCP/IP stack, because your TCP/IP is not > in the some "software zone" as your fileserver. So microkernels like > the Hurd are usually considered more secure and better designed > than monolithic kernels like Linux. However, monolithic kernels > will usually be faster than microkernels. I know microkernels are theorically slow due to the heavy use IPC. But is it really impossible for well written microkernel to beat a well written monolithic kernel? L4 is super-fast, is it still slower than Linux? > >> -- >> Akib Azmain Turja >> >> This message is signed by me with my GnuPG key. It's fingerprint is: >> >> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Rust in the kernel
Ludovic Courtès writes: > Hi! > > Leo Famulari skribis: > >> The effort to use the Rust programming language within the Linux kernel >> is progressing and may be realized in the next few months: >> >> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/ >> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/ >> >> Within Guix, we'll need to adapt our kernel build processes in order to >> support this. >> >> Although I help with updating and configuring the kernel builds, I won't >> be able to participate in the "Rust in the kernel" effort for Guix. > > Understood… > >> So, interested volunteers should begin organizing :) > > Yup! > > Now, concretely, how long will it take before key parts of the kernel > are written in Rust? Hopefully a long time, no? Per the article above, > it’s starting small, with Rust usage in well-defined locations. > > This is not to say that we shouldn’t start organizing, but rather that > we still have a bit of time ahead. > > (During that time, interested readers can also take a stab at improving > support for the Hurd, which relies on that revolutionary technology > called “address spaces” to ensure Memory Safety™ among other things!) > > Ludo’. > "Address spaces"! What's that? Sorry for asking without searching the internet first, but the Hurd designers are so creative that a few understand the concepts and join the community, so there is a little chance (if any) that I'll find any useful information on that. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Can't install wine, curl build fails at 'check' stage
Akib Azmain Turja writes:
> zimoun writes:
>
>> Hi,
>>
>> What is your arch? On x86-64, it works for me.
>
> I'm also using x86_64.
>
>>
>>
>> On ven., 01 juil. 2022 at 22:33, Akib Azmain Turja wrote:
>>
>>> TESTFAIL: These test cases failed: 3026
>>>
>>> make: *** [Makefile:809: test] Error 1
>>> make: Leaving directory
>>> '/tmp/guix-build-curl-7.84.0.drv-0/curl-7.84.0/tests'
>>> error: in phase 'check': uncaught exception:
>>> %exception #<&invoke-error program: "make" arguments: ("-C" "tests" "test")
>>> exit-status: 2 term-signal: #f stop-signal: #f>
>>> phase `check' failed after 616.0 seconds
>>> command "make" "-C" "tests" "test" failed with status 2
>>>
>>> While installing Wine, curl build fails at 'check' stage (testcase
>>> 3026):
>>>
>>> --8<---cut here---start->8---
>>> $ guix install wine wine64 --substitute-urls=https://ci.guix.gnu.org
>>
>> [...]
>>
>>> The following derivation will be built:
>>> /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv
>>>
>>> building /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv...
>>> \ 'check' phasebuilder for
>>> `/gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv' failed with
>>> exit code 1
>>> build of /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv failed
>>> View build log at
>>> '/var/log/guix/drvs/v3/kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv.gz'.
>>> guix install: error: build of
>>> `/gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv' failed
>>> --8<---cut here---end--->8---
>>
>> [...]
>>
>>> guix 81cf674
>>
>> The issue you are seeing is not wine but curl.
>
> I don't know why this is occurring. "guix install curl" installs curl
> 7.79.1, but "guix install wine" tries to install curl 7.84.0, and fails.
>
>> However, it is
>> unexpected because:
>>
>> --8<---cut here---start->8---
>> $ guix time-machine --commit=81cf674 -- weather curl
>> computing 1 package derivations for x86_64-linux...
>> looking for 2 store items on https://ci.guix.gnu.org...
>> https://ci.guix.gnu.org
>> 100.0% substitutes available (2 out of 2)
>> at least 1,0 MiB of nars (compressed)
>> 1,7 MiB on disk (uncompressed)
>> [...]
>>
>> looking for 2 store items on https://bordeaux.guix.gnu.org...
>> https://bordeaux.guix.gnu.org
>> 100.0% substitutes available (2 out of 2)
>> 0,0 MiB of nars (compressed)
>> 1,7 MiB on disk (uncompressed)
>> (continuous integration information unavailable)
>> --8<---cut here---end--->8---
>
> Yes, "guix weather curl" says me that substitutes are available.
>
>>
>>
>> And this,
>>
>> $ guix time-machine --commit=81cf674 \
>>-- build curl
>> $ guix time-machine --commit=81cf674 \
>>-- build curl --no-grafts --check
>>
>> just works for me.
>>
>>
>> Cheers,
>> simon
>
> --
> Akib Azmain Turja
>
> This message is signed by me with my GnuPG key. It's fingerprint is:
>
> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
Simon, do you have any advice to help me debug the bug myself?
--
Akib Azmain Turja
This message is signed by me with my GnuPG key. It's fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
signature.asc
Description: PGP signature
Re: Can't install wine, curl build fails at 'check' stage
zimoun writes:
> Hi,
>
> What is your arch? On x86-64, it works for me.
I'm also using x86_64.
>
>
> On ven., 01 juil. 2022 at 22:33, Akib Azmain Turja wrote:
>
>> TESTFAIL: These test cases failed: 3026
>>
>> make: *** [Makefile:809: test] Error 1
>> make: Leaving directory '/tmp/guix-build-curl-7.84.0.drv-0/curl-7.84.0/tests'
>> error: in phase 'check': uncaught exception:
>> %exception #<&invoke-error program: "make" arguments: ("-C" "tests" "test")
>> exit-status: 2 term-signal: #f stop-signal: #f>
>> phase `check' failed after 616.0 seconds
>> command "make" "-C" "tests" "test" failed with status 2
>>
>> While installing Wine, curl build fails at 'check' stage (testcase
>> 3026):
>>
>> --8<---cut here---start->8---
>> $ guix install wine wine64 --substitute-urls=https://ci.guix.gnu.org
>
> [...]
>
>> The following derivation will be built:
>> /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv
>>
>> building /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv...
>> \ 'check' phasebuilder for
>> `/gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv' failed with
>> exit code 1
>> build of /gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv failed
>> View build log at
>> '/var/log/guix/drvs/v3/kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv.gz'.
>> guix install: error: build of
>> `/gnu/store/v3kc0z1mx7zai6hky8kzlp171cxr2ccj-curl-7.84.0.drv' failed
>> --8<---cut here---end--->8---
>
> [...]
>
>> guix 81cf674
>
> The issue you are seeing is not wine but curl.
I don't know why this is occurring. "guix install curl" installs curl
7.79.1, but "guix install wine" tries to install curl 7.84.0, and fails.
> However, it is
> unexpected because:
>
> --8<---cut here---start->8---
> $ guix time-machine --commit=81cf674 -- weather curl
> computing 1 package derivations for x86_64-linux...
> looking for 2 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
> 100.0% substitutes available (2 out of 2)
> at least 1,0 MiB of nars (compressed)
> 1,7 MiB on disk (uncompressed)
> [...]
>
> looking for 2 store items on https://bordeaux.guix.gnu.org...
> https://bordeaux.guix.gnu.org
> 100.0% substitutes available (2 out of 2)
> 0,0 MiB of nars (compressed)
> 1,7 MiB on disk (uncompressed)
> (continuous integration information unavailable)
> --8<---cut here---end--->8---
Yes, "guix weather curl" says me that substitutes are available.
>
>
> And this,
>
> $ guix time-machine --commit=81cf674 \
>-- build curl
> $ guix time-machine --commit=81cf674 \
>-- build curl --no-grafts --check
>
> just works for me.
>
>
> Cheers,
> simon
--
Akib Azmain Turja
This message is signed by me with my GnuPG key. It's fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
signature.asc
Description: PGP signature
Re: How to reinstall the bootloader without guix system reconfigure?
Felix Lechner writes: > Hi Akib, > > On Fri, Jul 1, 2022 at 4:35 AM Akib Azmain Turja wrote: >> >> Fortunately, I have Ubuntu (yet another nonfree >> distribution) installed and it didn't broke, so used that to add that >> 100 GB to my Guix partition. But I found that GRUB is still broken. >> Then I appended "/boot/grub/grub.cfg" of Guix to the same file of Ubuntu >> and managed to boot into Guix > > Like Tobias, I cannot tell how Grub broke for you (although I do not > dispute that it did). > > Grub needs to find a series of secondary files that, for EFI, are > stored on the ESP. [1] For a traditional MBR/BIOS install, people use > a small (1 MB or so) "BIOS Boot Partition" [2] although you probably > aren't using that because your Windoze would not be able to use GPT > without EFI. (Without GPT, Grub finds some place outside the partition > table.) > > I think you are using EFI and an ESP. How did you know? I used to use Windows 10 even using a non-GPT (MBR maybe?) disk. And I still have that installed (though I don't use, not even once in a month), just configured to boot with EFI. > > You may be encountering the issue that both Ubuntu and Guix are trying > to manage the boot process. There is theoretically a way both Grub > installations could coexist on the ESP but I am not sure they do. I > personally would run Grub only in Ubuntu or Guix. Both distrubtions have their own dedicate directory in ESP, so IMHO that shouldn't be a problem. And I have several OS installed simultaneously for several years, without any problem. > > In your case. it may be hard to pick one over the other. > > Ubuntu scans your hard drive for other operating systems, including > Winblows, but probably misses Guix. Guix on the other hand may > miss the other two but knows the exact paths needed to boot into your > most recent "Guix System" configuration. > >> Is there any way to reinstall bootloader without the costly "guix system >> reconfigure"? > > To reinstall in Guix, you may be able to run 'grub-install /dev/sdX' > but that does not stop the competition between Ubuntu and Guix. I may > also make it harder for you to boot into Ubuntu or Winnows. > >> Another non-important question: Why did Guix's GRUB broke while >> Ubuntu's GRUB survived? > > I think they use the same folder on the ESP. No. Not at all. > > Maybe there is an expert who can chime in. > > Thanks for using Guix! I would thank the Guix developer, who have developed such a wonderful OS, which (almost) never breaks. > > Kind regards, > Felix Lechner > > P.S. You can boot many systems manually from the Grub shell, but it > would be an extraordinary burden to type the full Guix paths for your > kernel and your initrd. > > [1] https://en.wikipedia.org/wiki/EFI_system_partition > [2] https://en.wikipedia.org/wiki/BIOS_boot_partition -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: How to reinstall the bootloader without guix system reconfigure?
Akib Azmain Turja writes:
> Tobias Geerinckx-Rice writes:
>
>> Hi,
>>
>> Guix System reinstalls GRUB every time for convenience, but there's no need
>> to run 'guix' just to fix GRUB.
>>
>> You can reinstall it by hand if you know what you're doing, using GRUB's
>> grub-install command. It doesn't even matter which distribution's GRUB you
>> use, as long as it's not ancient. Guix's GRUB does not carry Guix-specific
>> patches.
>>
>> What does matter very much is whether you use the UEFI or non-UEFI version.
>> Can you share your operating-system's (bootloader ...) snippet?
>>
>> Form this distance, I can't tell you why one GRUB broke & the other one
>> didn't.
>>
>>
>> Kind regards,
>>
>> T G-R
>>
>> Sent on the go. Excuse or enjoy my brevity.
>
> Thanks, it just worked.
>
> I'm using EFI, here's the bootloader declaration:
>
> (bootloader-configuration
> (bootloader grub-efi-bootloader)
> (targets '("/boot/efi"))
> (keyboard-layout keyboard-layout))
>
> --
> Akib Azmain Turja
>
> This message is signed by me with my GnuPG key. It's fingerprint is:
>
> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
Oh yes, it installed under the name "grub", but I just renamed the
directory to Guix.
--
Akib Azmain Turja
This message is signed by me with my GnuPG key. It's fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
signature.asc
Description: PGP signature
Re: How to reinstall the bootloader without guix system reconfigure?
Tobias Geerinckx-Rice writes:
> Hi,
>
> Guix System reinstalls GRUB every time for convenience, but there's no need
> to run 'guix' just to fix GRUB.
>
> You can reinstall it by hand if you know what you're doing, using GRUB's
> grub-install command. It doesn't even matter which distribution's GRUB you
> use, as long as it's not ancient. Guix's GRUB does not carry Guix-specific
> patches.
>
> What does matter very much is whether you use the UEFI or non-UEFI version.
> Can you share your operating-system's (bootloader ...) snippet?
>
> Form this distance, I can't tell you why one GRUB broke & the other one
> didn't.
>
>
> Kind regards,
>
> T G-R
>
> Sent on the go. Excuse or enjoy my brevity.
Thanks, it just worked.
I'm using EFI, here's the bootloader declaration:
(bootloader-configuration
(bootloader grub-efi-bootloader)
(targets '("/boot/efi"))
(keyboard-layout keyboard-layout))
--
Akib Azmain Turja
This message is signed by me with my GnuPG key. It's fingerprint is:
7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
signature.asc
Description: PGP signature
How to reinstall the bootloader without guix system reconfigure?
Hello everyone, I shrunk my Losedows (Windows) partition by 100 GB. Then I tried to boot Guix, but found that GRUB is broken and the GRUB rescue prompt appeared. I thought that it's because of the 100 GB empty space in my hard disk. Fortunately, I have Ubuntu (yet another nonfree distribution) installed and it didn't broke, so used that to add that 100 GB to my Guix partition. But I found that GRUB is still broken. Then I appended "/boot/grub/grub.cfg" of Guix to the same file of Ubuntu and managed to boot into Guix and to write this mail you're reading now. Now, if I'm correct, to fix the problem, I think the bootloader needs to be reinstalled. To do that, I have to run "guix system reconfigure". But that will download too many thing, much more than it actually needs. I know that "guix system delete-generations" also reinstalls bootloader while not downloading too many things, however I don't have any previous system generation, so I can't use that trick to reinstall the GRUB. Is there any way to reinstall bootloader without the costly "guix system reconfigure"? Another non-important question: Why did Guix's GRUB broke while Ubuntu's GRUB survived? Thanks in advance. [Note: This message copied from my another message in help-guix which got no response, with some minor changes.] -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: First guix pull is too costly
zimoun writes: > Hi, > > On Tue, 28 Jun 2022 at 18:49, Akib Azmain Turja wrote: > >> Just out of curiosity, why the hash is >> pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq? Is this the hash >> of the channel declaration/definition/whatsoever? > > --8<---cut here---start->8--- > $ guix repl > GNU Guile 3.0.8 > Copyright (C) 1995-2021 Free Software Foundation, Inc. > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. > This program is free software, and you are welcome to redistribute it > under certain conditions; type `,show c' for details. > > Enter `,help' for help. > scheme@(guix-user)> ,use(rnrs bytevectors) > scheme@(guix-user)> ,use(gcrypt hash) > scheme@(guix-user)> (define url "https://git.savannah.gnu.org/git/guix.git";) > scheme@(guix-user)> (bytevector->base32-string (sha256 (string->utf8 url))) > $1 = "pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq" > --8<---cut here---end--->8--- > > From ’url-cache-directory’ in (guix git) [1]. > > > 1: <https://git.savannah.gnu.org/cgit/guix.git/tree/guix/git.scm#n125> > > Cheers, > simon Thanks! -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: First guix pull is too costly
zimoun writes: > Hi, > > On Tue, 28 Jun 2022 at 14:04, Akib Azmain Turja wrote: > >> Is possible to reuse the guix channel from any other user to do the >> first guix pull? Or maybe a shallow clone? > > Assuming alice is user already existing on the machine and bob is the > new user. Something like should do the job, > > --8<---cut here---start->8--- > ALICE=/home/alice/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq > BOB=/home/BOB/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq > mkdir -p $BOB > git clone $ALICE $BOB > --8<---cut here---end--->8--- > > then adapt the permissions. > > > Cheers, > simon > It worked! Thanks a lot. Just out of curiosity, why the hash is pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq? Is this the hash of the channel declaration/definition/whatsoever? -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
First guix pull is too costly
Hello, Yesterday, I created a new user in my system. Then I tried to install a package, but found that it's not the latest, although I did sudo guix pull before sudo guix system reconfigure. So I tried to do guix pull, but it seems to clone the whole repository from scratch. But, unfortunately, it never succeeds due to my faulty network connection. It progresses somewhat like 5%, 7%, 20%, and my connection fails, and I have to start again from the beginning. Is possible to reuse the guix channel from any other user to do the first guix pull? Or maybe a shallow clone? -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 signature.asc Description: PGP signature
Re: Regarding copyright assignment to FSF
Michael Banck writes: > Hi, > > On Sat, Aug 14, 2021 at 02:19:12PM +0200, Dr. Arne Babenhauserheide wrote: >> Michael Banck writes: >> >> > I don't mind that, but I also think the Hurd is not a tactical FSF asset >> > anymore that needs to be kept under tight control. The FSF has enough >> > copyright in the Hurd that it can enforce it whenever it likes, even if >> > other people's copyrighted code (as is already the case with the pfinet >> >> I wouldn’t be so sure about that. >> >> 1. Without copyright assignment of all code involved, enforcement >>becomes much harder. > > I don't think "much harder" can be quantified in a meaningful way, > seeing how parts of the Hurd aren't under the FSF copyright at this > point, anyway. A real life example is GNU Guix. There are (probably) more than hundred copyright holders (ain't I right, Ludo?). Is it possible enforce the copyright of that package? All copyright holders must cooperate to enforce GPL, which is probably impossible. >> 2. The Hurt still provides capabilities other OS’es don’t — while >>maintaining POSIX compatibility. We’ve seen audacity basically >>being taken over by a company in the past months, so the danger of >>losing Hurd to proprietarization rather got bigger than smaller. > > Nobody proposes that the FSF relicenses the Hurd to a non-copyleft > license before relinquishing the copyright assignment mandate, so I > don't see how the Hurd continueing to be under a GPLv2+ license will > ever be able to be taken proprietary. When copyright is not enforced, there is no difference between a GPL licensed and a public domain software. When a company sees that the copyright isn't enforced of a GPLed, it can take the program and make it proprietary. > I'm not going to respond further on this thread, this is starting to get > off-topic really quick and if there are further things to be discussed, > gnu-system-discuss or whatever other mailing list is likely the better > place. > > > Michael NOTE: I am not a lawyer. -- Akib Azmain Turja This message is signed by me with my GnuPG key. It's fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5 Get it with: gpg --recv-keys 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 See https://emailselfdefense.fsf.org/ to learn more and protect your emails and yourself from surveillance. Please send me encrypted messages whenever possible. Never send me Microsoft Office attachments, they use secret proprietary format so I'll fail to read and trash them; send them in plain text if possible or in formats like ODF and PDF if your document contains images or videos. See http://www.gnu.org/philosophy/no-word-attachments.html to learn more. Please don't send HTML emails, use plain text. HTML emails are usually vulnerable, about thousand times larger than plain text and look ugly to me. They contain trackers, so whenever someone opens a messsage he is tracked by third-party. See http://www.asciiribbon.org to learn more. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: PGP signature
