<keysemble[m]>lfam: Question, how can I reference the wip-gnome3.36 branch for bumping/testing/fixing with the guix package manager? I suppose though the use of a guix channel?
<lfam>You could use channels, but you can also do it in an ad-hoc style with `guix pull --branch=wip-gnome3.36`. That command also takes an --url argument, but the correct repo for this is the default argument
<keysemble[m]>I used to use Gentoo a lot and like doing custom configurations with use flags, but I started getting tired of always compiling over time. I appreciate the Guix offers both binary installing and source building.
<lfam>I think it's a useful middle-ground between binary and source distros
<lfam>There is a discussion ongoing about how to offer something like the use flags in Guix
<lfam>Like, customization is already possible and used often, but Gentoo people have a nicer abstraction for that exact ghing
<pkill9>lfam: if you could build webengine on the build farm that would be great, all i've done is run: guix build -e '(begin (use-modules (guix packages) (gnu packages qt)) (package (inherit qtwebengine) (arguments `(,@(package-arguments qtwebengine) #:configure-flags (list "-webengine-proprietary-codecs")))))'
<lfam>Can you send a patch to <firstname.lastname@example.org>?
<pkill9>I believe there are no configure-flags in qtwebengine
<keysemble[m]>lfam: so, assuming I have the default guix.git channel and a wip-gnome channel from wip-gnome3.36 branch of the same guix.git repository, shouldn't I have 2 directories in the ~/.cache/guix/checkouts directory?
<keysemble[m]>I only see one directory that has the guix repo under the master branch
<lfam>I'm not sure. The directory contains a git repo that is used to build from, and that wip-gnome3.36 branch is of the default repository
<keysemble[m]>It does, but the thing is, that directory already has the remotes to both 3.34 and 3.36 wip versions, so it seems I don't really need to use a channel for the wip 3.36 version, but I'm confused how isolate the gnome3.36 stuff for testing from the default guix repo
<keysemble[m]>because I don't want to mess with the main checkout directory for the `guix` tool
<lfam>`guix pull` is used to update or change the available packages and Guix tools. Each time you run it, a new "generation" of Guix is created, and the effective generation is then referred to by the other Guix tools, such as `guix install`
<lfam>It's kind of like `apt-get update` but you can switch to previous generations, rollback, things like that
<lfam>This directory's name "checkout" is misleading. It would be more accurate to call it "git-repository"
<lfam>It will introduce the concepts with some practical examples
<lfam>It helps to know what a "profile" is with Guix, then it's easier to talk about
<keysemble[m]>I was looking through manual, but since I'm a newb here, it's a lot of information to take in at once, so it helped me to see some workflow examples which will help understand the manual better
<apteryx>raghavgururajan: :-) I just packaged it in Guix.
<timmydo>i'm trying to package a new service in guix and i'd like to add a new system service-type so i can put it in my config.scm. is there a good guide on authoring services? the manual sort of tells me all the options but i'm curious how i should test and iterate on the code. probably not repeatedly running guix system reconfigure?
<wleslie>turns out `guix gc` while I have `guix environment` open in another shell is not a good idea
<dummyuser>Hi, is there a boot setting for shepherd to boot only to TTY and not start the X-Server similar to systemd's target= and classic runlevel? After first install my system freezes when trying to start the login manager at which point "C-M-F2" don't let me change to other TTYs any more.
<cbaines>woo, guix.cbaines.net has finally caught up now after the staging merge, at least with x86_64-linux
*terpri idly muses about getting guix to run on the librem5 or the pinephone-whatever
<terpri>probably best to wait for signal's desktop support to improve a bit, but my lineageos phone is getting long in the tooth
<leoprikler>dummyuser: you can probably prepare something along those lines by using the barebones template instead of the desktop one
<leoprikler>however, I don't think that's something you can do from grub
<dummyuser>Too bad, then I'll have to fire up the installer again. Thanks though :)
<hapster>I had a problem with my main user (regarding environment variables), and creating a new user did show that the problem was specific not general. Now I am thinking about how to best move my data from a to b.
<hapster>or, to be more specific: I would generally like to keep the user. Thus, my idea would be to re-create the user after securing the data on a test user. Is there anything specific that I would have to keep in mind?
<fnstudio>civodul: cool, yes i understand there's some risk but good to know there shouldn't be anything immediately serious, thanks v much
<dummyuser>leoprikler: The startup messages disappear, the screen turns black with just a cursor blinking and the laptop is stuck there and then. Hitting Ctrl - Alt - F2 and the like don't take me to the console at that point
<leoprikler>fnstudio: as an alternative, you might control over who gets to spawn containers through acls
<dummyuser>Hmm, good idea. I selected it in the installer.
<leoprikler>In that case ssh into your machine and reconfigure it with something lighter. In particular, you might just want to drop gdm so you can get terminal access
<leoprikler>on the other hand, you might also want to investigate what stops gdm from spawning
<leoprikler>/var/log should have some pointers in that regard
<dummyuser>SSH works like a charm, thanks for the help. Should be able to get on from there :)
***modula2 is now known as defaultxr
<Rovanion>I got Geiser running in emacs, but whenever I run `(use-modules (gnu packages x))` the guile process locks up one thread at 100% and seemingly does nothing for a really long while. Is there a way to figure out why?
<ioa>Good morning Guixers! Looking forward to Guix Days on Monday. :)
<fnstudio>leoprikler: oh interesting, thanks for mentioning acls - although the idea is to finally move to guix system so i think i'm happy with a quick workaround now (i.e. echo 1 > ...)
<nckx>sneek: later tell daphnis: Guix doesn't have any relevant Ada compilers, and I'm not aware of any that could be packaged (GNU GNAT isn't currently an option as it needs another GNAT to compile itself). The only Ada compiler in Guix is Ada/Ed, which is too old to be useful in practice. It could be useful to bootstrap an ancient -- and very hypothetical -- Ada '83 version of GNU GNAT, if any exist.
<zimoun>the bar means what is already done based on previous build for the same package, right?
<roptat>mh... if the guix daemon is offloading two builds to the same machine, I see it exports some dependencies (sources, inputs), twice if there is an overlap. Is that only duplicated in messages, or does it use twice as much bandwidth?
<leoprikler>I don't think you can completely exclude that case, but there might be cases, in which only the message is printed before Guix notices, that it's already present.
<leoprikler>That being said, I'm not quite sure how the exact same input would be sent twice in parallel – I haven't read that far into Guix' source.
<PotentialUser-62>If I want to install tor through guix on top of my existing ubuntu, is it sufficient to run `guix install tor` as root? And will it pick up the existing torrc?
<roptat>I don't think so, on the guix system we need to use a service for that
<roptat>on a foreign distro, it's not possible, so I don't know what tor would do in your case
<roptat>maybe with simple-service, that allows you to extend the pam-root-service-type
<roptat>does vsftpd package provide that file? it would be the easiest I think
<davidl>roptat: Yes, there is such a file in the unpacked tarball.
<pinoaffe>hi guix! `guix deploy' keeps failing, with guix deploy: "error: program `/gnu/store/ni87ig3m875yy6qh00n65xyg6p724gz5-guix-1.1.0-10.141b5c1/bin/guix' failed with exit code 1", where can I find logs?
<pinoaffe>sure, iirc I did that ~2 days ago but my memory may be failing me
<roptat>davidl, nevermind, it doesn't take a file, but a more structured thing in guile; you can find an example of the value in some services, like lsh (gnu/services/ssh.scm) that extends the pam-root-service-type
<roptat>for the simple-service, you can do something like that: (simple-service pam-root-service-type <associated-value-for-vsftd>)
<roptat>sorry, I got it wrong: (simple-service 'vsftpd-pam-service pam-root-service-type <associated-value-for-vsftd>)
<davidl>roptat: thanks! Ill see what I can come up with.
<joshuaBP`>Hey guix, I'm trying to get my sway service running. I'm essentially trying to debug "sway-service-type", "sway-shepherd-service", "sway-activation", and "default-sway-config". I can run each of these functions. eg: (gexp->derivation "build-sway-config" (sway-activation (sway-configuration))), which returns a procedure. How can I execute that procedure to make sure it's "working"?
<sneek>marusich, dftxbs3e says: about libstdc++, I remember that nckx told me everything had to go in /lib so we should rather patch gcc to lookup libstdc++ in /lib instead of /lib64, I remember starting to patch that but never committed anything.
<marusich>dftxbs3e, nckx, so lots of other packages will break if we don't do that? I haven't built much else but have not encountered a problem so far. If you saw problems in the past, then it's something we should change, yeah.
<marusich>Hm OK. Regarding https://paste.debian.net/plain/1184292, it's in core-updates... I did try merging core-updates into wip-ppc64le the other day, but I didn't push that to Savannah because (1) cbaines said core-updates isn't at a stable point (guix pull apparently doesn't work due to build failures) and (2) other stuff failed after I merged it.
<marusich>Since there's no guarantee that everything is working anyway right now, perhaps we should just merge core-updates now and deal with whatever breaks.
<dftxbs3e>marusich, I wouldnt do this, it will increase our trouble.
<marusich>We can just wait until core-updates is at a stable point.
<dftxbs3e>Better cherry-pick individual patches so things work and merge in master, also because this bootstrapping works with Glibc 2.31 but core-updates has 2.32 and soon 2.33 if not already and I don't want the ground the move again I've been going through this several times already it's annoying
<marusich>In the meantime, I think we should probably cherry pick the individual commits we need.
<marusich>My understanding is that cherry picking will not make it difficult to merge things later, although it will "uglify" the history a little bit (but Git can actually do quite a good job of filtering out changes that introduce the same thing, in "git log" etc.)
<marusich>I already did it with one of efraim's commits from wip-ppc anyway
<dftxbs3e>I remember it causing breakage in my tests. Don't want to risk it anymore.
<dftxbs3e>This is also why we should not merge core-updates in wip-ppc64le branch for now.
<marusich>OK. Do you think we should introduce logic to keep using glibc-2.31 for bootstrapping? Currently the bootstrap code uses whatever glibc version is current, and it happens to be glibc 2.31 on the wip-ppc64le branch and master
<dftxbs3e>marusich, yes well it would be nice but everything is so interdependent I'm really not confident with doing that either.
<dftxbs3e>I like when it works like now, I'm almost terrorized to touch it again now.
<marusich>I guess what I mean is, suppose we do what you suggest. The people working on core-updates will want to upgrade glibc anyway - so what is the path forward for them/us to upgrade glibc?
<marusich>Right. I hear you. It's exhausting when nothing seems to work.
<marusich>It seems to me like retaining glibc-2.31 for bootstrap on all arches seems like the right approach.
<marusich>I mean, we could selectively do it just for ppc64le, but why not just do it for all arches?
<dftxbs3e>marusich, powerpc64le bootstrapping will work at a particular commit with glibc 2.31 and then it wont. It wont be a big deal (it's already that way for other arches, if you try bootstrapping from latest commit it doesnt work).
<marusich>when you say bootstrapping, do you mean "building up all the packages from the bootstrap binaries" or "building the bootstrap binaries"?
<dftxbs3e>Once you bootstrapped a guix package then all future commit revisions will build fine (even glibc 2.32+)
<dftxbs3e>marusich, building from the bootstrap binaries
<marusich>oh. ok. I guess I misunderstood what you meant.
<marusich>Huh. I don't really understand why that is true, but I believe you and I see what you mean.
<marusich>But to build Guix, we can do that without merging to master, right?
<marusich>We could build Guix from the wip-ppc64le branch and then use it, right?
<dftxbs3e>marusich, yes we can do it without merging to master but then the bootstrap path is unclear and not very well documented
<marusich>I mean we would merge the branch eventually.
<dftxbs3e>And as soon as "guix" package builds with it, that's what I want to do to set it in stone!
<marusich>I'm thinking we would build guix from wip-ppc64le, use it, eventually merge core-updates into wip-ppc64le, and then merge wip-ppc64le into core-updates, and then merge core-updates into master.
<dftxbs3e>valerii_leontiev, Run $ bzip2 -cd <log_file_path.bz2> | less
<dftxbs3e>valerii_leontiev, You will find more clues as to why
<valerii_leontiev><dftxbs3e "valerii_leontiev, You will find "> What means <log_file_path> ? What do I need to put there?
<gnutec>Sad! So guix can't fix a profile, restore or create a new. That is bad! Back to Ubuntu. Hope he create a boot recover and show a way to conect to a wifi in a manual instalation, because what is write in Guix.pdf, doesn't work. 😥
<dftxbs3e>valerii_leontiev, in the screenshot you sent there's a log file path that ends with .bz2
<dftxbs3e>gnutec, How exactly is GNU Guix broken in the way you describe "can't fix a profile, restore or create a new"? Do you have any logs?
<dftxbs3e>gnutec, and if you do not feel comfortable using GNU Guix System as your system you can always use GNU Guix on top of Ubuntu!
<valerii_leontiev><dftxbs3e "valerii_leontiev, in the screens"> Are you kidding me? Look at this log
<cbaines>that package materialdecordation looks to fail to build
<dftxbs3e>valerii_leontiev, GNU Guix is a rolling release distro so it's normal some packages do not work some times, it just needs to be fixed. The best is you send over that log file by uploading it somewhere. Like on https://drop.infini.fr/ for example
<gnutec>dftxbs3e: I use a Guix System for a long time. When I upgrade to 5.10.11, the boot system broke. When I finally access the system, I use "sudo guix system init config.scm /" to recover the boot, but fail and broke my profile. All my app is there, but I only can access using "find /gnu/store -name *-abiword*". So why is there not a command to restore/fix/create a new profile?
<cbaines>gnutec, profiles are very different things from system generations
<marusich>Maybe it "just works" most of the time, I guess.
<marusich>I can definitely add logic to the package definition of libstdc++ to tell it to install libs to /lib, but I'm wondering why the gnu-build-system doesn't do that already.
<gnutec>dftxbs3e: it's crasy! For so long I try to follow guix.pdf to get in the wifi with wpa_suplicant.conf, but always fail.
<dftxbs3e>valerii_leontiev, I could try building the same package and get the same error so no need to upload the log, I've got it too now. Will try fixing when I have some time, until then you'll have to wait!
<gnutec>cbaines: No! I just need to fix it. Simple like that. I don't care if I have to create all file guix to my user.
<dftxbs3e>marusich, not sure how that works, but I've seen packages being patched when they install elsewhere than /lib
<cbaines>gnutec, that's great, it's always helpful to have people like yourself working on finding simple solutions to complex problems, like recovering a system that won't boot. I think there's plenty of room for improvement.
<marusich>regarding lib64 and gnu-build-system, I suspect that perhaps gnu-build-system should be changed to always set --libdir to /lib, but there might be existing package definitions that would be broken by that "correct" change because they fixed the problem by e.g. telling a package to look in /lib64
<marusich>so i think for now i will just make a change specifically to set --libdir in libstdc++
<gnutec>dftxbs3e: I access the system using my Guix System pendrive, press c on grub. I try everything. Create a link by my self of .guix-profile but nothing work.
<gnutec>I only need a command to fix/recover/create my profile. Is there possible? No? Simple.
<dftxbs3e>gnutec, hmm if you can access a grub instance from a usb pendrive I think you can boot using parts of the (broken?) config already present in your system. It will contain lines to boot into previous system generations that still should work, or the store is completely broken? There's no such command I am afraid, but if you still have your config.scm file just backup your home directory and reinstall, should get you up and running again quite
<dftxbs3e>I think it's a lost cause trying to fix the GNU Guix System installation as-is, better to reinstall and restore home directory backup.
<gnutec>dftxbs3e: yeh! I did "guix pull" then "sudo guix system reconfigure /etc/config.scm". But spend to much of my mobile data. So there is not a profile recover command. Ok!
<apteryx>civodul: random thought; about setuid programs: if someone was to give a symbolic link instead of real target as part of setuid-programs list, the chmod 0 0 would attempt to change the mod of the owner file; no?
<dftxbs3e>gnutec, GNU Guix is not a product with a warranty so we first and foremost all use what we build. You have the experience of a broken system so maybe you could document something to help create such a feature.
<nckx>apteryx: If this is about security, what's the threat model? How does an unprivileged user abuse this?
<dftxbs3e>gnutec, it's unclear in what way your system was broken, so without a record of this information it will be hard to do anything.
<nckx>gnutec: It's not possible to create that because the problem is too vague. So the only way it will exist is if you create it, as dftxbs3e says. ☺
<gnutec>nckx: that is what I want. Create a new profile.
<pkill9>i like guix cos i can leave it for a while and work with it some other time
<nckx>gnutec: It will re-use anything that's still in the store, so if you use the same version of Guix that was used to create the profile you've lost, and haven't GC'd in the meantime, it shouldn't download much.
<nckx>But again, far too many unknowns to say anything particularly useful to you.
***[ is now known as ]]
***]] is now known as [[
<fnstudio>what's the recommended approach to deploy guix onto a VPS provider? i'd be looking for something that can automate the largest possible part of the process. i see guix deploy offers something for digital ocean
<fnstudio>on some blog posts, however, i see a different approach: create an image locally and upload it to a VPS provider for then creating machines out of it
***[[ is now known as Noisytoot
<fnstudio>(relatively recent blog posts, i mean - post guix deploy and the digital ocean backend were introduced)
<fnstudio>i'd also be interested to know of any guix-friendly VPS provider (i found one already)
<gnutec>nckx: No. Now the system stop in "scheme@(guile-user)>". This is new. hahahahahaha
<sneek>daphnis, nckx says: Guix doesn't have any relevant Ada compilers, and I'm not aware of any that could be packaged (GNU GNAT isn't currently an option as it needs another GNAT to compile itself). The only Ada compiler in Guix is Ada/Ed, which is too old to be useful in practice. It could be useful to bootstrap an ancient -- and very hypothetical -- Ada '83 version of GNU GNAT, if any exist.
<dftxbs3e>gnutec, nobody here owns you any help and if you are not being nice about it I do not think I am willing to help you in any way and that could be the same for everyone else.
<gnutec>dftxbs3e: I don't speak english very well.
<dftxbs3e>gnutec, I think that does not prevent you from being nice with people here. "So for the good of the guix system, do what I ask. Please" - Since when explicitly giving orders to volunteers is an acceptable behavior.
<dftxbs3e>Things happen at their own pace, there's so many things to do, and each has its own varying priority.
<civodul>mothacehe: hey! you gonna be around on Monday?
<nckx>gnutec: Sorry, I was away (as mentioned). I'm not telling you to reinstall, just that the shell that you'll get from the installer (used as a ‘Guix live CD’) will be miles better than the initrd REPL and actually give you a fighting chance of getting your system to work. The actual work of doing so, however, is entirely yours.
<gnutec>Add a boot-repair on guix instalation. Create a command about profiles, "guix package -m manifest -p profile" doesn't work. The guix.pdf instrution to "wpa_suplicant.conf" doesn't work, so try more. And in the guix blog, there is a instruction to create extra profiles, try hard about there too. Looks like GNU project has serious problem to write instruction.
<gnutec>So for the good of the guix system, do what I ask. Please!*
<nckx>Believe it or not, we've all been where you are, most of us many times. Asking for a rescue wizard to be written for you by volunteers instead... well, it tends to elicit a poor reaction in free software/hacker communities.
<dftxbs3e>gnutec, if the manual isnt good enough, help make it better, we can't tell how bad it is because we don't need it like you now and don't have time to test things.
<nckx>And you're not motivating them any other way, so...
<marusich>gnutec, for what it's worth, I don't think anybody is denying your frustration. It is frustrating when things don't just work. I find it helpful in times like that to take a break, or ask for help if you're just really stuck on something. You're not alone, and many people (like those interacting with you now) are willing to help, especially if you explain the details of what you tried and why it did not work. We're all trying to make things
<marusich>better. But like nckx is saying, you are uniquely positioned and motivated to solve the problems that you face.
<marusich>I often get stuck on things I cannot solve, so I understand.
<gnutec>But now my system stop work anyway. Any help is unseless now.
<nckx>It's not that we don't care about you, or about increasing the number of Guix users (although we care a lot less about that than you seem to think).
<nckx>But nobody is going to put hours of work into something they don't need based on a vague ‘it broke’ spec...
<dftxbs3e>gnutec, Quit GNU Guix System and use it on top of Ubuntu for the time being, maybe in few years GNU Guix will have a stable channel where this will not happen. For now, it's work in progress.
<cbaines>vagrantc, haha, well, even I don't think listing problems on a page is an effective strategy for reducing the number of problems, I'd really like to see more done before changing things on the master branch to stop problems appearing there
<vagrantc>cbaines: being able to find issues is, though :)
<dftxbs3e>gnutec, But I am also certain you can just reinstall GNU Guix then restore a backup of your home directory and that particular issue probably wont happen for a while, never happened to me ever.
<vagrantc>cbaines: i guess i use the tests.reproducible-builds.org infrastructure to look for things to work on, so various angles on broken things is really useful
<cbaines>vagrantc, well, if someone wants to fix things, then maybe they'll be helped/motivated by having a clear list of problems
<dftxbs3e>cbaines, this would be really helpful for me, I've been poking around with "$ guix refresh" to try and update some packages at random. Would be easier with all the data sorted and ordered nicely.
<dftxbs3e>Automated "issues" on outdated packages (that you can filter if they go to core-updates or not, or if a patch is already available..)
<cbaines>dftxbs3e, right, that's a bit of a more complicated problem, but I'd also really like to see more automation around that
<dftxbs3e>cbaines, ultimately I would like to trust the data service to tell me what I can work on without duplicating anything (if a patch is already available..)
<cbaines>I think it would be great to have some tool that pushes branches with package updates, so that people can come along and "adopt" upgrades that they can see don't cause anything to fail to build
<gnutec>dftxbs3e: No. I will use Ubuntu with snap.
<cbaines>dftxbs3e, on the trust issue, maybe there needs to be a list of people who are "reviewers", who have a history of properly reviewing changes
<nckx>Nobody cares about your commit bit if your review is good. If you raise good points, you raise good points, the end.
<dftxbs3e>marusich, yes.. that doesnt surprise me. "$ grep -R /lib64 ." in the rs6000 folder of gcc
<dftxbs3e>Substitute that with /lib, and be done with it
<nckx>Committers won't blindly accept your LGTM but you're significantly lightening their load.
<cbaines>dftxbs3e, it's more an issue of trying to really scale the rate of change, the rate at which patches are reviewed, without having to have it linearly correlate with the number of people with commit access
<cbaines>(I also think less changes should be pushed without review, so having some separation would help there too)
<nckx>gnutec: The first one sounds like a great first contribution (assuming it's your first); the second is too vague and probably not something actually useful and the third can only be done by the person having the boot problem -- i.e., you.
<dftxbs3e>I feel like reviewing as a non-committer means duplicating work with the committer (compiling, running tests, ..) in case the non-committer missed something the committer will check.
<marusich>I would personally prefer it if dftxbs3e had commit access to make it easier to collaborate for the power9 port, since honestly he is more knowledgeable about the domain than I am. I don't mind committing on their behalf, but I imagine it's probably discouraging for them and increases friction. As long as dftxbs3e is following the guidelines that we all follow about what branches to commit, the format of commit messages, and seeking review of
<marusich>non-trivial changes before putting stuff into master/core-updates/staging, I think it's good.
<cbaines>I think there's a precedent been set with the recent Outreacy round for having commit access, but for branches other than master right?
<cbaines>I wasn't really paying attention, but I think that's the changes I saw
<dftxbs3e>I think I have numerous patches that I submitted where I learned a lot about how to contribute to GNU Guix and I feel like I am ready now.
<cbaines>dftxbs3e, don't let the discussion of reviewing without commit access put you off going through the process to get commit access
<nckx>dftxbs3e: I definitely trust you enough to grant you commit access to a ppc64 branch with no access control but your word ☺
<dftxbs3e>From the manual it says that I must find 3 people to vouch before even sending any email, so here I am :-)
<nckx>dftxbs3e: How did https://issues.guix.gnu.org/46139#5 (gnu packages tls) happen, by the way? Just want to make sure you've adjusted your workflow to reduce the chance of ‘guix pull’ breakage before I vouch for you.
<pkill9>would it be a bad idea to have a --roll-forward flag to complement --roll-back?
<dftxbs3e>nckx, when you sent that I had already sent another patch with a fix. I initially contributed this to a third party channel and copied the definition without the imports, then committed that, then figured out I forgot the imports, made the modification then committed again but without "git add", so it went out by email by mistake.
<rekado_>nckx: we missed you at Au Bon Vieux Temps!
<dftxbs3e>nckx, I had already tested the package definition with the third party channel and neglected re-testing when integrated within GNU Guix. But I'll admit I just wanted to get it over with and sent it over to come back to it later. Just in case some other people wants to do the work.
<nckx>rekado_: I really wish I could have made it.
<bqv>So I really like the fact that boot is interactive, in the initrd. It was annoying at first, cause I'm not used to it, but then it became insanely useful in working out the issue
<bqv>That and the lack of systemd, I've got high hopes for this OS...
<nckx>[nervously] bqv: What's wrong with systemd these days?
<bqv>nckx: same qualms as ever. It's poorly written, obscenely bloated in code and scope, seems to be growing like a virus, and at this point functionally removes the element of choice w.r.t init system
<dftxbs3e>I happen to care less about security than I care about GNU Guix philosophy and values this time. But I can't wait for GCC to grow a Rust frontend and for GNU Guile to be rewritten in Rust so memory-safety yay!
<OriansJ>I mean you have got Gash (bash replacement) Gash-utils (coreutils replacement), MesCC (GCC replacement) a bunch more all running on Guile
<dftxbs3e>I am more concerned about the security of the GNU Guile's code in terms of memory safety, even more with the JIT.
<OriansJ>nckx: well didn't we already have a bootstrap for rust? (It is kinda long but not unexpected)
<nckx>Guile's primary aim (besides ‘do the scheme good’) is to integrate deeply with C programmes, so a Rust rewrite is not happening soon.
<nckx>OriansJ: It's not quite n → n+1 → n+2 … but still too close (and long), maybe a GCC front-end would help. I'm just happy GCC will do the Rust and remain relevant beyond free software nuts.
<dftxbs3e>Writing anything in C today for me as person who works in IT security professionally usually is creating inevitable new memory-safety bugs and therefore security issues. All that when there is a solution available that works well for most of it: Rust.
<dftxbs3e>There's still a cultural issue in Rust when it comes to licensing so I hope GCC Rust will help that.
<dftxbs3e>(Lots of misinformation about copyleft licenses, most people choose MIT/Apache2 by social conformism when it's not even in their interest)
<bqv>dftxbs3e: no doubt, but it not being systemd is still a plus in my books
<nckx>That's true for most trendlangs/‘open source’ in general though.
<dftxbs3e>nckx, This time that comes from the core team itself.
<OriansJ>dftxbs3e: working as a security professional myself; I can say even Haskell and Rust have memory-safety bugs because they were written by humans. Programs with formal proofs of correctness also have later been found to have bugs too.
<pkill9>i thought formal proofs of correctness would prevent bugs
<dftxbs3e>It is better to minimize locations where memory-safety bugs can happen than to not even try to do that (like with C).
<OriansJ>dftxbs3e: well dat-to-day code writing isn't concerned about security either generally.
<dftxbs3e>OriansJ, software in the GNOME eco-system is commonly written in C for example. It is day-to-day for them.
<OriansJ>pkill9: proofs only work if the assumptions hold and humans are bad at making assumptions.
*OriansJ doesn't mention all of the Node.js brogrammers
<pkill9>here's an assumption: I am right, therefore, I am right
<OriansJ>one needs to accept that the world doesn't care about security, only those of us who do care about security are able to improve the security problem.
<dftxbs3e>Proofs quite expensive to obtain, Rust gives memory-safety on the code you write by default with little effort and top performance so that's why it gets vote. Other languages with memory-safety are slower in general. (e.g. NodeJS)
<dftxbs3e>OriansJ, I don't think it's possible without everyone's cooperation unfortunately, either by choosing a safe language or learning more rigorous programming/testing techniques..
<OriansJ>how many security people even care about Trusting Trust attacks in their software stack to actually do something about it? Answer currently 1.