IRC channel logs

<axioms>Hello, I am a Gnu Guix System user and I'm curious about the state of GNU Hurd. As far as I am aware there is a new project going on called ngHurd which is intended to replace hurd as the new hurd project?

<axioms>I like to keep tabs on the state of hurd. I wish I could contribute, but I really don't think I have any expertise to contribute anythign meaningful

<anatoly>axioms: what ever was next regarding hurd or mach is simply dead

<anatoly>"original" mach and hurd is what's being developed

<Gooberpatrol66>hurd-ng is kind of theoretical afaik

<axioms>Ah okay

<Gooberpatrol66>"what would we do if we redesigned hurd"

<axioms>What is the state of hurd currently?

<youpi>there's a faq entry about it

<anatoly>axioms: it's too general question

<axioms>Yeah sorry, I hate being the person asking vague questions

<anatoly> https://www.gnu.org/software/hurd/faq.html

<axioms>Are any of you working on hurd?

<anatoly>I'm just a poser :-D

<Gooberpatrol66>axioms: you can work on documentation if you want to help but don't know coding

<axioms>Yeah documentation could certainly be something I could try doing

<axioms>I have found very few open source operating systems besides BSD and Gnu/Linux. RedoxOS and Hurd seem to be the only two that have any level of recognition, am I correct with that assumption? I know there is open indiana too, but I hear about that very little.

<anatoly>from https://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Installing: "If you have unsupported hardware or a different microkernel" - I don't get this reference to some other microkernel. It's basically misleading the reader

<anatoly>feels like "open" solaris distributions passed their top moment, it was like 15 years or slightly less

<axioms>I personally disagree with the BSD license, so I don't use or contribute to the BSD operating systems. I am very much a GPL supporter so I like that the hurd is completely GNU and GPL

<axioms>Linux is also GPL v2 which is good at least

<Gooberpatrol66>axioms: there's also redox, genode, plan 9, inferno, haiku, minix

<Gooberpatrol66>no open source os has significant userbase besides gnu/linux & bsd though

<axioms>Yeah I mentioned redox, it's interesting. It is MIT licensed however, which isn't as good as the GPL as far as Free Software is concerned

<axioms>yeah bsd and gnu/linux are basically 99% of users

<anatoly>youpi: what do you think about that sentence from hurd's user guide I posted few messages above?

<Gooberpatrol66>i think genode is agpl3? everything else is probably permissive

<axioms>Do you care much about licensing? I know some people don't care, but I think it matters a lot. I am not going to open source my work for someone else to profit off. If I am not willing to profit from it, it's not fair for someone else to.

<Gooberpatrol66>i'm kind of a copyleft extremist

<anatoly>jesus!

<axioms>Haha, that's good at least you are on the GNU side

<anatoly>you should call yourself then acopyleft :-)

<Gooberpatrol66>you can go more copyleft than GNU's idea of it

<axioms>How is it that unraid is Proprietary and charges for their software if you cannot close source the linux kernel? Are they only adding their code to userspace so that it can be closed?

<anatoly>Am I right that the only way/the easiest way to isntall hurd on a machine without a CD drive is to use debian's crosshurd package?

<axioms>"Unraid is a proprietary Linux-based operating system designed to run on home servers in order to operate as a network-attached storage device, application server, media server and a virtualization host. Unraid is proprietary software developed and maintained by Lime Technology, Inc"

<axioms>anatoly: I think so

<axioms>anatoly: there is a video on youtube of someone running the debian hurd on bare metal

<anatoly>and I guess I can do it from the live debian system

<Gooberpatrol66> https://en.wikipedia.org/wiki/Unraid says here their kernel source is provided, maybe some userspace program is proprietary

<axioms>Yeah that's what I thought they might be doing

<axioms>I guess it's technically legal, but I'm not a fan of things like that

<Gooberpatrol66>anatoly: you can build hurd with guix, but someone once tried to argue with me about whether that counts as "easiest"

<axioms>Oh I didn't know that, Guix provides a virtual machine qcow2 image on their site, but I guess you could try build it for bare metal?

<Gooberpatrol66>it says in their commands you can build a disk image, i've never tried it though

<damo22>if someone is selling a product with linux as the kernel, you are entitled to ask for source code at least for their changes to the kernel

<damo22>you cant sell a proprietary linux os

<Gooberpatrol66>you can if you tivoize it like android

<Gooberpatrol66>but not gnu/linux

<anatoly>Gooberpatrol66: I'm having enough fun by using guix is a daily system, thanks! :-D

<damo22>how is android tivoized?

<damo22>most of the phones have open bootloaders

<damo22>or have been reverse engineered

<Gooberpatrol66>ok, most windows programs have been cracked and pirated

<Gooberpatrol66>they're still proprietary

<damo22>android isnt proprietary

<damo22>the java addons probably are

<Gooberpatrol66>i can't see half the drivers my phone is running, even though they're baked into a ROM image i built myself

<Gooberpatrol66>AOSP isn't proprietary

<damo22>right

<Gooberpatrol66>every device manufacutrer skin is

<Gooberpatrol66>which is what ships on the devices

<axioms>Samsung phones come with tiktok

<axioms>I'm using grapheneos with google pixel because modern android is so far from foss compliant nowadays it may as well be windows

<damo22>axioms: +1

<axioms>I was looking into replicant android by the GNU project, but I think it's just too outdated for me to use. So grapheneos is what I've chosen for now.

<damo22>phones are a lot of work

<damo22>i cant be bothered fiddling that much so i installed grapheneos

<Gooberpatrol66>i think phones are the future of all technology, fighting tooth and nail to control anything about it

<axioms>What do you guys think of the linux phones? I'm not really sold on them. Most people agree that linux phones are not secure at all compared to AOSP. I.e Librem 5

<Gooberpatrol66>i think without open hardware, foss is doomed in the long run

<axioms>I agree

<axioms>Open Source Hardware is essential

<anatoly>For about 2 years or more I used replicant before I switched to a pinephone few years ago

<Gooberpatrol66>linux is as secure as you bother to make it, i.e. NSA-tier selinux setups

<solid_black>hi!

<anatoly>yo!

<Gooberpatrol66>out of the box security could be improved though

<Gooberpatrol66>hi

<axioms>I've been considering buying the pinephone, how is the experience anatoly?

<anatoly>what's new? how many more arm boards are working like a clock now under mach?

<solid_black>no new boards

<Gooberpatrol66>i have a pinephone pro, and was going to install mobian on it maybe

<solid_black>not until someone (you!) grabs a nearby board and makes it work :)

<anatoly>axioms: works for me, but it's not super fast, probably pinephone pro but it lacks some things to be a dailydriver so far

<solid_black>but, as you must have seen, the Mach public headers are upstream now

<axioms>anatoly: what is your daily driver?

<anatoly>solid_black: I'm old and 32bit only dude :-D

<solid_black>so the next step would be for me to post v3 of the glibc patches

<solid_black>then, grab qemu and pick an emulated board

<damo22>i like old thinkpads, but newer than x200 that runs 100% without ME

<anatoly>axioms: pinephone, original, for 2+ years so far with mobiamn installed

<anatoly>axioms: pinephone, original, for 2+ years so far with mobian installed

<axioms>anatoly: what is the pinephone pro lacking?

<axioms>I have the pinebook pro currently

<axioms>Just for experimenting with

<anatoly>axioms: https://wiki.pine64.org/wiki/PinePhone_Pro see the table and cells in red

<damo22>intel's ME wouldnt be so annoying if it had a dedicated NIC

<anatoly>axioms: pinebook pro is my main laptop

<solid_black>are you talking of running GNU/Hurd on the Pinephone? :O

<axioms>anatoly: Okay thanks

<axioms>solid_black: no lol, I wish

<solid_black>"Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores"

<solid_black>sounds like AArch64 to me

<Gooberpatrol66>solid_black: if you want someone to try that, i could try it if you gave me instructions

<axioms>I guess it would be posssible?

<solid_black>Gooberpatrol66: that'd be cool!

<solid_black>I mean, it obviously wouldn't work yet

<axioms>anatoly: thanks I looked at the list

<solid_black>so, it would make sense if you're willing to do some investigations / debugging / driver hacking, like azert

<anatoly>ah yeah, sure, fuck you cool guys!

<anatoly>:-D

<axioms>Currently I am trying to use only hardware that has ECC Ram as I cannot stand data corruption. So I am going to be buying a mobile workstation laptop with ECC ram soon. I have a Dell Precision with coreboot and ME Neutering from 3mdeb.

<damo22>laptop with ECC??

<axioms>Yeah

<damo22>which model?

<axioms>Dell Precision Laptops have ECC Ram, Lenovo workstation laptops have them too

<axioms> https://www.dell.com/en-uk/shop/laptops-2-in-1-pcs/precision-7680-workstation/spd/precision-16-7680-laptop/xctop7680emea_vp

<axioms>They are expensive

<anatoly>is it really an issue?

<axioms>So I am going to buy used on ebay

<Gooberpatrol66>solid_black: i'm not familiar with that, do i need to connect jumpers to the board or something?

<damo22>i have a w530

<damo22>thinkpad

<solid_black>I'm not familiar with that either

<axioms>Yes, I have encountered data corruption on computers many times that I have now decided to avoid non-ecc ram as much as possible

<damo22>axioms: i have never experienced that

<anatoly>what are you doing?

<damo22>i use DDR3 non-ecc ram

<Gooberpatrol66>axioms: what filesystem do you use

<axioms>Just using computers like normal. And it's not just me, I've seen my friends computer corrupted out of nowhere too.

<damo22>axioms: if you use windows then im not surprised

<axioms>I use Gnu Guix System, with EXT4

<axioms>I've never had gnu guix system corrupted

<axioms>Years ago when I used arch and other linux distros It happened

<damo22>ext4 has been solid for me forever

<anatoly>We all might experience thaT but might have never connected it to some particle flying throw dram cell at that very moment

<Gooberpatrol66>guix is kind of inherently corruption resistant

<solid_black>how so?

<Gooberpatrol66>try using btrfs, zfs, bcachefs if you're concerned about corruption

<anatoly>axioms: truth is, guix is corrupted

<axioms>I also was dual booting windows once and I lost both operating systems. I had an XPS 13 that was in cold storage for several months. When I booted up after not touching it for several months, both operating system were corrupted presumably because of bitrot on the m.2 ssd.

<damo22>axioms: windows screws with ext4

<damo22>they dont want you to run GNU

<anatoly>bcachefs is broken

<axioms>Yeah I also discovered that years ago when dual booting

<axioms>Now I use seperate drives for operating systems so they don't interact

<solid_black>I thought we were all bcachefs fans in here, after the call with Kent? :D

<anatoly>what really triggers me is guix appetite for a free sapce on /

<Gooberpatrol66>axioms: if you leave an ssd powered off for a long time it wipes your data

<anatoly>solid_black: seems like it didn't help bcachefs itself so far

<axioms>gooberpatrol66: Yeah I think that's what happened. It was off for a couple months.

<axioms>Maybe I'm not that educated in this topic, but why isn't it more common knowledge that you shouldn't keep an SSD powered off for extended periods of time? Surely this should be a major warning on all SSD products

<axioms>I had to learn the hard way

<anatoly>solid_black: did you say some time ago that you were debugign arm mach or hurd on you phone?

<solid_black>I was debugging a userland executable

<Gooberpatrol66>solid_black: the parts that guix touches are corruption resistant, at least. all the system files. it won't upgrade if there's corruption because the hashes won't match, and it can't be interrupted because it's atomic, and nothing can mess with it because it's immutable

<solid_black>on top of Linux

<solid_black>by emulating Mach ABI manually

<anatoly>solid_black: yep, but was it on a phone not computer/laptop

<axioms>Yeah that's a great thing about guix package management. You can't get corrupted package installs

<solid_black>Gooberpatrol66: that's all cool, but that won't protect what's actually valuable, i.e. your personal files, would it?

<solid_black>protecting system binaries from fs corruption is not really interesting, it's always easy to recreate them from packages

<axioms>Yeah afaik it doesn't protect the home directory from corruption

<axioms>that's where ECC ram comes in

<axioms>obviously ECC ram won't stop SSD bitrot, but it will stop you writing corrupted data to the SSD

<Gooberpatrol66>i feel like "it's always easy to recreate them from packages" is a bit of a reach on most distros

<anatoly>i bet fs internals come in in reality

<solid_black>basically 'apt reinstall broken-package' and you're golden

<solid_black>unless the package manager's own DB is corrupted, in which case it's a lot more fun

<solid_black>but I doubt Guix would protect against that either?

<damo22>its not guix's job to look after your personal files

<damo22>thats what the filesystem is for

<axioms>ZFS would protect against personal files, but guix doesn't have it yet officially

<axioms>I've never used ZFS but it seems to be the golden standard for data protection

<damo22>zfs comes with its own challenges, eg the pool can get corrupt and you lose EVERYTHING

<axioms>damo22: That would be suboptimal

<axioms>Any alternatives that exist?

<axioms>Or does every file system have compromises?

<anatoly>raid1 on btrfs didn't protected me from dd'ing /someos.img to /dev/sda1 in wrong tmux pane

<damo22>i have ext4 on block raid1

<solid_black>they say unix gives you enough rope to hang yourself :)

<Gooberpatrol66>solid_black: i once corrupted glibc by setting the wrong compiler flags on gentoo

<solid_black>I've done that (dd onto the wrong disk) too

<Gooberpatrol66>it made this really cool matrix effect on the tty as the computer died

<anatoly>bloody terminals all look same

<damo22>if i dd -> sda1 i would kill one disk but sdb1 would save me

<anatoly>*the same

<damo22>i never dd to md0

<axioms>I came to guix from gentoo. Guix is like gentoo with everything having source code, but better.

<solid_black>imagine there would be Rust-like safety for Unix

<solid_black>and it wouldn't let you do things that it deemed unsafe

<Gooberpatrol66>anyways, i don't even remember how i fixed it, i couldn't get btrfs rollback to work, and i don't think chroot worked, i think i had to boot a liveusb and copy a binary inplace over the top of it from the liveusb

<solid_black>and you would have to do 'unsafe { dd if=someos.img of=/dev/sda }'

<anatoly>solid_black: so you have to come with few abstraction to work around it and move some stuff from one place to another :-D

<Gooberpatrol66>axioms: same

<axioms>I am probably missing some things. But I cannot see any major things that gentoo can do that guix can't?

<Gooberpatrol66>solid_black: you should take a look at what minix3 was doing, it was kind of crazy

<anatoly>actually, sorry, I lied, after that dd in a wrong window I set up raid1 before that it was a single drive nfs server

<axioms>Most gentoo users spend 50% of their time fixing packages and dependencies

<axioms>With guix it doesn't really happen

<Gooberpatrol66>they live-upgraded all programs by converting the data structures, then testing the migrated program, and then rolling back if it failed

<solid_black>oh yeah, I read about that

<solid_black>they used a custom compiler plugin, didn't they

<damo22>you could save yourself by having a server and just use laptop for thin client

<Gooberpatrol66>something like that

<axioms>although I did have to install xdg-desktop-portal to work with some flatpak packages, but that package wasn't installed via guix

<axioms>damo22: Are you talking to me?

<damo22>sure

<damo22>as in, put most of your big files on a separate pc

<Gooberpatrol66>axioms: useflags are easier to use in gentoo, but someone did a gsoc to add useflags in guix, that hasn't been upstreamed yet afaik

<damo22>and connect to it via lan while at home

<anatoly>uff, if you don't use dektop-software meta package in guix -> you're having lot's of fun with all of that newish xdg dbus stuff

<axioms>gooberpatrol66: yeah useflags are kinda handy, but I quickly found that I had added way too many use flags and had to start removing a lot of them just so I could even install the packages

<axioms>Useflags can be handy for security in some instances. But I think it's mainly for people compiling from source to save time.

<anatoly>I'm still going through a process of setting pure sway environment and I have to dig into lots of this stuff beside "fighting" guix

<anatoly>solid_black: so what phone did you use for your debug process?

<axioms>anatoly: I tried using window managers in the past but I just went back to gnome in the end. I don't think it made me anymore productive using tiling windows etc

<solid_black>anatoly: I have a OnePlus 6T running postmarketOS

<axioms>Does hurd support risc-v now?

<Gooberpatrol66>axioms: you can also rice out the compiler flags on gentoo, though guix is trying to add something like that as well with glibc psABIs

<anatoly>axioms: in our dreams :-D

<anatoly>solid_black: ah, ok!

<anatoly>but some people (i.e. solid_black) do more and dream less

<axioms>gooberpatrol66: It will be exciting once we that. At that point there will be almost no benefits of gentoo over guix for most users. I'm happy with guix as it is now, but it will just make it even more compelling.

<Gooberpatrol66>yep

<Gooberpatrol66>anatoly: for solid_black, the dream is being awake

<solid_black>(what?)

<anatoly>axioms: it's lighter, on a work machine I used gnome

<axioms>anatoly: yeah that's true, gnome is graphically taxing.

<anatoly>the big guix problem is that free space is not enough

<axioms>anatoly: Can't you just garbage collect?

<anatoly>axioms: have you tried?

<axioms>Yeah I have

<axioms>""

<axioms>Our recommendation is to run a garbage collection periodically, or when you are short on disk space. For instance, to guarantee that at least 5 GB are available on your disk, simply run:

<axioms>guix gc -F 5G

<axioms> https://guix.gnu.org/manual/en/html_node/Invoking-guix-gc.html

<anatoly>you see 5GB is nothing

<anatoly>10GB is nothing just to upgrade

<anatoly>and I don't have that many packages installed

<axioms>How much disk capacity do you have?

<axioms>Is this on the pinebook pro?

<anatoly>axioms: 30GB now for /

<axioms>Oh that's quite small

<anatoly>axioms: I bet can predict your birthday then

<axioms>Yeah it might be an issue then. I haven't tried using guix with very little disk space

<axioms>anatoly: haha try

<anatoly>6gb was enough for the same number of software (but actually more) on my previous debian system

<anatoly>I know I know guix keep generations so I can roll back my profile, bla-bla

<anatoly>but it also keep 5 version of python, 7 of bash, few gcc, etc

<anatoly>I know why

<anatoly>But the documentation lack this sort of warning or somewhat estimation of needed space

<anatoly>damm, will I ever remember how to use tr :-)

<Gooberpatrol66>i'm intrigued by deduplication in guix

<axioms>guix uses more disk space because it's reproducible. Otherwise you could reuse dependencies if the system wasn't reproducible, but then it causes dependency hell which guix is trying to avoid

<Gooberpatrol66>because it installs 5 slightly different versions of each library

<Gooberpatrol66>maybe turning on btrfs dedup would be enough

<axioms>I don't think it is

<axioms>every package is pointing to a different symlink

<axioms>they have their own unique filename

<Gooberpatrol66>can btrfs not dedup between files?

<axioms>I don't know I haven't used btrfs, maybe it's possible

<anatoly>btrfs would probably dedup on block level

<axioms>But they aren't carbon copies

<axioms>each package is unique at least partially

<anatoly>well, that's the problem, the dependency tree is too big

<axioms>It's not really an issue nowadays, disk capacity is getting bigger every year

<Gooberpatrol66>yeah, that would make it less efficient

<axioms>I actually have trouble trying to find small enough drives nowadays as I don't need TB of storage space

<anatoly>I have ssd of 256GB, fast and cool samsung one

<Gooberpatrol66>if something knew the layout of the binaries it could dedup more efficiently

<anatoly>but I'm not cool for guix with it

<Gooberpatrol66>like content-address each ELF segment

<anatoly>becasue even within one profile revision I'll have copies of the samesoftware with diffrence in last digit of the vesrion

<axioms>I'm sure it's probably possible. But you will be trading off one thing for another. More disk space but consumes more compute to analyse the entire file system

<anatoly>I don't know why the distribution as whole not tries to minimise the deps tree

<axioms>It wouldn't be reproducible if it did

<Gooberpatrol66>"The core OSTree model is like git in that it checksums individual files and has a content-addressed-object store. It's unlike git in that it "checks out" the files via hardlinks, and they thus need to be immutable to prevent corruption. Therefore, another way to think of OSTree is that it's just a more polished version of Linux VServer hardlinks."

<Gooberpatrol66>sounds like file-level deduplication only

<Gooberpatrol66>i think guix already does that, it says "hardlinks save X gb of space" when you run a command

<anatoly>axioms: what do you mean by reproducible?

<anatoly>Gooberpatrol66: yep, 6GB for me

<axioms>The packages have to be entirely self contained. So no matter what system files or packages you have, anyone who installs the package will have the exact same binary code. So that it doesn't matter what other packages are installed on your system.

<axioms>If you used other package dependencies, the binary of the package would change and it would no longer be reproducible.

<Gooberpatrol66>there's the issue of reproducible and the issue of substitutes being available

<Gooberpatrol66>guix will track any flag changes you make but they can't practically compile every variant of a package

<Gooberpatrol66>well maybe they could if they had robust build artifact caching

<anatoly>axioms: I'm no talking about it. The problem is that at this very moment I have few webkitgtk-for-gtk3-2.42.4, few webkitgtk-for-gtk3-2.42.5

<anatoly>so they keep buildingg things on top of things

<anatoly>and it just multiplies

<axioms>anatoly: I see

<anatoly>although most updates are updates to dependecies not installed packages by me

<Gooberpatrol66>i think they wanted to merge the useflags patch for that so they could ship slim binaries by default with the option of users enabling bigger features self-compiled

<anatoly>so they keep rebuilding current versions of packages but it doens't reduce copies od the same versions

<anatoly>for libs, for example

<axioms>gooberpatrol66: that would certainly help disk space usage

<anatoly>And for my brain it's just ridiculous to throw in by 10s of GBs to / just to be able to have one more console utility

<anatoly>I reduce the time range for keeping generations from 4 weeks to 3 weeks

<anatoly>it freed more space

<anatoly>let's see if 11GB is enough

<anatoly>to upgrade

<anatoly>I wonder if I can take debian qemu image and dd it to a hard drive to skip crosshurd part

<solid_black>I don't think I understand what you're trying to do

<anatoly>solid_black: do you mean to use some of specific arm64 boards (whatever qemu supports) and try to run mach?

<solid_black>ah, you mean you want to try running aarch64 mach

<solid_black>then basically yes

<solid_black>well, any board really, qemu or physical

<solid_black>whatever you have / are interested in

<solid_black>try running it, see what doesn't work (something will most likely be broken), fix things, implement missing drivers, etc

<anatoly>solid_black: i've got another x86 laptop available, it has no CD drive, I want to install hurd on it. So either debian > crosshurd > hurd or debian > dd qemu-image > hurd

<anatoly>anatoly: sorry for confusing, it's two separate topics at the same

<Gooberpatrol66>pretty sure the qemu-image can't be dd'd raw

<Gooberpatrol66>you'd have to unpack it or something

<Gooberpatrol66>and as for differences between booting in a vm vs bare metal, idk

<anatoly>Gooberpatrol66: sorry, I mean .img to run under qemu or anything else

<anatoly>I think I used crosshurd in 2008 or so to install hurd on asus eeepc900

IRC channel logs

2024-04-18.log