Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Love Arch, but GNU Guix Is My New Distro

boilingsteam.com

Post reply on HN
Print view View original

151–160 of 318 posts

Re: I Love Arch, but GNU Guix Is My New Distro

#151

Post by pxc »

m1keil wrote: post #91
jordanbeiber wrote: post #22

Earlier quoted context omitted.

A couple of things - if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Then there’s the question of how exactly you reached this state. Having nixos generations is like having an event stream of all changes. Apply your backup to a new machine, what happens?…

> if the system can handle rollbacks it will be much more reliable than using the fs, as the fs knows nothing about actual state. It knows about blocks commited to disk. Usually they look the same, but not always. Could you elaborate on this? If I have state that works on v1 and after upgrade to v2 the state is now non backward compatible to v1, how nix (or guix) can help? As far as I can tell, in such case a fs roll…

Depends on how the state is stored. If it's in configuration, Nix generated it and it lives immutable in the Nix store, so Nix will just point out it to the old version on rollback.

If it's something like the content of a SQL database, which lives outside the Nix store and which Nix did not generate, you need some other tool (like a filesystem snapshot, maybe) to perform the rollback. I think CoW filesystems sometimes have performance issues with DBs, though, so I'm not sure that's always the approach you'd take.

The Nix ecosystem does have a fairly mature tool for managing stateful components that live outside the Nix store, though: https://github.com/svanderburg/dysnomia

It's been around for a long time. Idk who all is using it

Re: I Love Arch, but GNU Guix Is My New Distro

#152

Post by kaba0 »

marcodiego wrote: post #148
kaba0 wrote: post #145

Earlier quoted context omitted.

> the fact that right now that are hundreds of people/bots checking it. As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from…

> As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to mor…

It was just one example, but running everything under the user’s user is just terrible.

Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.

Re: I Love Arch, but GNU Guix Is My New Distro

#154

Post by h2odragon »

wheelerof4te wrote: post #102
wiz21c wrote: post #95

Earlier quoted context omitted.

> arbitrary religious dogma "arbitrary political view" there's a difference, it matters.

It is a religion at this point. Political views have parties and parties have supporters. FSF is more like a cult that has followers. How else do you explain their rejection to include Debian as a fully free distro?

Consistent application of principles doesn't make a "cult". Its just so rare you may be unfamiliar with the difference.

Make a fork of their code with your preferred changes. The world will be improved and people who agree with you will be happy.

Re: I Love Arch, but GNU Guix Is My New Distro

#155

Post by mindslight »

marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

It's not productive to call it "arbitrary religious dogma". The FSF chose a criteria for what binary blobs are acceptable. Your and my opinions are that they set this criteria wrong, but if we hope to change their policy, then we have to discuss it rationally.

I personally think the correct criteria is that of security boundaries and change control. If I've got a graphics card with proprietary code (regardless of whether its in ROM or loaded into RAM), with a proper IOMMU, the attacks it can perform on me are limited (eg TEMPEST). The video card itself is not Free or secure, but it's unfortunately something I have to use to interface with my Free/secure computer, just like my keyboard with its proprietary firmware. And as long as I can load any version of firmware onto that video card, then I retain administrative control where the manufacturer can't revoke functionality after I've purchased it.

Disk drives with proprietary software (which is all of them) are not an attack vector, because a drive should only ever be seeing encrypted data to begin with (eg LUKS).

A network card is a bit more worrisome with its direct network access (ie backhaul), but a Free/secure design shouldn't be trusting the network either (unless you have Free/secure switches), so this does not meaningfully change your security properties.

Obviously the above assumes Free/secure drivers, because drivers are running inside the security boundary of the OS.

CPU masks and microcode run afoul of my strict criteria, but are practically inescapable. Proprietary masks/microcode are required for every amd64 system (correct me if I am wrong), so it makes sense to say you have a Free/secure amd64 modulo those proprietary bits (as say Libreboot already does). And with so few versions of CPU microcode, the question of whether to trust a given microcode update is equivalent to whether to trust a given newly released CPU, and shouldn't be viewed as a software Freedom issue.

Re: I Love Arch, but GNU Guix Is My New Distro

#156

Post by mindslight »

jrm4 wrote: post #125
grumbel wrote: post #113

Earlier quoted context omitted.

The issue is that the FSF fine with that binary blobs as long as it's stored in ROM, but if it's in RAM, that's bad. To me that is completely backwards. If a driver loads firmware into RAM, that means I have easy access to the blob, can reverse engineer it, update it and change it. If it's ROM that's going to be a lot more difficult or impossible. Sure it would be nice to have it all Free Software, but then we should…

Your theory makes sense, but practice strikes me as the reverse: Long-term: Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes. Stuff in RAM? Always changing and "under attack" all the time.

Firmware in RAM is loaded from distribution packages, which also goes through a trackable process. There is a continuum here with frequent firmware updates being extremely dodgy (why can't they get it right and release a stable version), and infrequent updates (eg CPU microcode) being similar to shipping one image in "ROM".

Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.

Re: I Love Arch, but GNU Guix Is My New Distro

#157

Post by arpa »

kaba0 wrote: post #116
onli wrote: post #89

Earlier quoted context omitted.

There is no nuance there. Without free software there is no software freedom. If blobs are allowed at all that is already a measure to have a system that works in practice, but in no way makes it the position against closed software and blobs wrong. The people criticizing the FSF here act as if Stallman were wrong about these issues because he said it back then already. While in reality again and again he was right a…

But you already run a processor with the very real possibility of backdoors from that very same entity. And let’s be honest, a zero day due to a CPU bug is orders of magnitude more likely to cause real harm than the fantasy of state actors deploying some blobs to your computer and have a look at my meme collection. 100% is never achievable but I much prefer having 85% than nothing.

I too settle for less bad dictatorship as means of governance.

Re: I Love Arch, but GNU Guix Is My New Distro

#158

Post by mindslight »

User23 wrote: post #138
medo-bear wrote: post #96

Earlier quoted context omitted.

no. he is calling it deceptive, which is even stronger than confusing. his statement was: > They are deceiving people into believing they are not running proprietary software edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness

The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software. Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have…

No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page:

> AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)

> AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.

"Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases.

Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.

Re: I Love Arch, but GNU Guix Is My New Distro

#159

Post by arein3 »

marcan_42 wrote: post #27

> Guix System is an advanced distribution of the GNU operating system. It uses the Linux-libre kernel It's worth pointing out that the linux-libre kernel is developed under the FSF doctrine that "binary blobs are bad unless you can't see them". This has been taken to its logical extreme here, where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode , becaus…

>FSF doctrine that "binary blobs are bad unless you can't see them"

your statement is misleading

why did you add "unless you can't see them"

did FSF said binary blobs you can't see are not bad? Seems opposite from what FSF would do

Re: I Love Arch, but GNU Guix Is My New Distro

#160

Post by zelphirkalt »

pama wrote: post #150
zelphirkalt wrote: post #101

Earlier quoted context omitted.

I wrote down all I learned here: https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-pack... (or use org-mode file in same repo) I've not yet had the energy or patience to learn the TexInfo format, which is a standard for GNU projects. But if anyone wants to put what I have in the Guix docs, even as merely an example or tutorial, I wont mind.

Out of curiosity, did you try exporting from org mode? https://orgmode.org/manual/Texinfo-export-commands.html

I know that is possible, but I did not try, because I do not know, whether such an export would be a "drop-in-and-done" for the structure or nesting depth, if such things exist, in the actual documentation, or would have to be modified a lot to put in the docs.
Post reply on HN