IRC channel logs
2025-11-01.log
back to list of logs
<youpi>nexussfan: the kbd driver doesn't need a device specification <nexussfan>youpi: Doesn't NEED by it will find it automatically or doesn't need by it actually doesn't? <nexussfan>Because I'm currently trying to get the kbd driver for xlibre to work on hurd <nexussfan>and it gets the "wrong fd" according to the dev <p4r4D0xum>youpi: booting amd64 qemu image, console hanged. Is ssh root login permited? <youpi>usually root login with passwd is disabled by default in debian <p4r4D0xum>I think the easiest to fix that is to disable the console before the boot. <youpi>you can also easily enable root ssh with passwd in /etc/ssh/sshd_config <p4r4D0xum>one thing you can give Hurd, it gives you that edge. :D <p4r4D0xum>is it normal when default-pager translator dies during the update? :> <p4r4D0xum>youpi: what a adventure default-pager died but hurd-amd64's life go on. <p4r4D0xum>should I change something in sources.list for amd64? <youpi>p4r4D0xum: you cannot switch between i386 and amd64, you have to reinstall <p4r4D0xum>youpi: Yes, I'm aware of it. I use amd64 qemu image <youpi>I don't understand the question then <p4r4D0xum>was afraid if I specify backports without some amd64 option <p4r4D0xum>but I see it's just my ignorance made me worrying <jab>youpi: I don't know if you saw, but I made another hurd wiki: hurdos.com/wiki <jab>The search doesn't work, and it's not super easy to update yet, but I wanted you to know. <jab>p4r4D0xum: howdy partner ! <jab>I'm still struggling to get the Hurd re-installed in any laptop. :( <jab>I've got a few more thinkpads shipping my way. Hopefully I'll have something booting inside a week! <p4r4D0xum>jab: have you tried to use qemu image first? <jab>I am currently running OpenBSD. :) <jab>so qemu doesn't work sooo swell. <jab>I've got a guix system desktop, so I could play with the Hurd on their "child-hurd". <p4r4D0xum>make sure you have a raw format and dd the whole image into a disk <jab>But they don't have X working yet. <jab>And I personally prefer to run the Hurd on bare metal. It is just more reliable in my humble opinion. <p4r4D0xum>i run hurd only on hardware, cause qemu is bit slow on my old junk <jab>though I do want to try dual booting Xen (hurd + OpenBSD + linux), Hurd, OpenBSD, Guix System. And just bit at boot time. That would be pretty cool! <jab>I'm right there with you brother. :) <jab>actually now that I think about it...I might actually have gotten that keyboard replacement sitting at home for my T510... <p4r4D0xum>so I have junk at home, at least 15 different motherboards <jab>It would be pretty cool to make design a new laptop with the T400 innards. And sell a librebooted T400 laptop with a mechanical keyboard. (we'd have to get X working on libreboot). <p4r4D0xum>trying to check whole day if amd64 will work <jab>p4r4D0xum: it will. nexussfan I believe is running it on real hardware... <jab>I would love to get the Hurd ported to power 9. I'm thinking about trying to sell a Blackbird computer. Almost open hardware. Completely open firmware. No Intel managagement engine (or AMD equivalent). 256 max ram. Easily set up a RAID 10. the works. :) For the low price of $3,000 USD. <jab>grrr, I just replaced the T510 keyboard...and the new keyboard's power button doesn't turn the power on the keyboard..... <youpi>he is leveraging rust for a core Debian part <youpi>ports which don't have rust yet are really quite doomed sooner or later, for various reasons <azert>he wants to break these ports <youpi>I'm actually surprised that libxml2 has not yet been replaced with a rust implementation, it *really* should <youpi>which, indeed has the side effect of requiring rust <azert>libxml2 is really just a xml parsing library, you can substitute a c implementation with a rust implementation and vice versa. Once apt starts to use rust we are doomed. There aren’t going to be two apt versions <youpi>and then the c version will not be maintained, while the rest of the world will use the newer features of the rust version <youpi>so quite mid-term-wise, you really have to support the rust version <youpi>we have been there with librsvg <youpi>having some C equivalents of the apt pieces written in rust are exactly what was suggested on the list <youpi>you'd have a less-powerful apt, but still able to install packages <youpi>but again, on the long term you'll suffer, so yes you'd have to embrace rust <youpi>again, do not put break-intention on this, the intent is to make apt better, not make people suffer <youpi>debian does have to take such steps to go forward and not stay hindered by ports <azert>I wonder how AlmuHS project on rust on Hurd, servers side, is going.. quite extensive stuff <jab>youpi: I wonder why rust libxml2 and libsvg is being rewritten in rust instead of other languages. Rust is probably "the best" choice, but I do potentially see zig, odin, swift, hare, etc. as alternative system languages. <azeem_>of those four, I only heard of zig, and only recently <youpi>jab: the variety of languages shows itself as a problem, since you'd then have to port them all to various ports <youpi>so, yes, aligning on various project into picking up rust allows to concentrate on one language to port to various ports <jab>azeem_ swift is actually really pretty cool. It apparently just became memory safe. And the ladybird project is writing new code in it. <jab>just slightly off topic.... <azeem>uh right, swift I heard about as well <azeem>still I think rust is a reasonable choice to replace C as a system language, compared to the others