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

261–270 of 318 posts

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

#261

Post by medo-bear »

marcan_42 wrote: post #256
medo-bear wrote: post #136

Earlier quoted context omitted.

why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers

There is no way to verify silicon. This applies to every single chip. If you are using off the shelf hard cores in silicon, you need to trust the vendor. That's just how it is. It's not practical for end users to take silicon chips into a SEM, delayer them, and verify that the design is what they expect. Verifiability aside, there aren't even any high performance CPUs with fully open RTL/netlists available.

> If you are using off the shelf hard cores in silicon, you need to trust the vendor

if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude

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

#262

Post by Gentil »

podiki wrote: post #162
Gentil wrote: post #32

I moved to NixOS and came back to Arch because setting up development environments for general purpose computing felt tricky. I was on a schedule so had to drop it. Is it the same for Guix? I don't know why it should be any different. But still asking. Also, am guessing people will likely have hardware compatibility issues for Guix which isn't a problem for NixOS since they bundle non-free drivers etc.

Not sure what kind of development environments you mean, but one of the great features of Guix (and Nix I think) is to easily provide isolated environments. This can help you control dependencies and other things separately from the main OS. In guix this is as easy as `guix shell some packages` or add a `-D` for development libraries needed for those packages instead. You can then easily reproduce the same environmen…

Setting web development environments and mobile dev environments or anyway in which different languages are involved. NixOS have some documentation on it. Like I said, this wasn't because they (NixOS and Guix) implement it bad, but because of my time constraints as mentioned before.

But it also felt like, apart from learning the new way of using my system which NixOS/Guix works, now I have to work with how to deal with different languages. To me this felt like a big overhead. As a n00b of NixOS (not a n00b on Linux BTW), I have questions like doesn't this mean I will have lesser support on setting up something new development when something new comes along? This honestly have made me take my time on going back to NixOS. Cos I cannot just compile the packages directly like I could in normal Linux distros. Right? Or do correct me I am wrong. Like I said, the time constraints (+ pandemic) have made it hard for me to make time. Maybe you could correct me if I am wrong somewhere and make me understand it better. :)

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

#263

Post by Qwertious »

medo-bear wrote: post #136
WastingMyTime89 wrote: post #126

Earlier quoted context omitted.

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t check the microcode anyway and I don’t really trust the people who might more than the company providing my CPU. Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers

Hardware operates differently to software - it's impossible to verify hardware after it's been manufactured+shipped to you, so you need to trust the ENTIRE manufacturing and ownership chain of EVERY SINGLE COMPONENT. This is true of both open- and closed-source hardware.

Look, don't take my word for it - take the word (and more importantly, the reasoning) of the guys behind the Novena open laptop: https://www.bunniestudios.com/blog/?p=5706

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

#264

Post by Qwertious »

pdpi wrote: post #134
marcodiego wrote: post #122

Earlier quoted context omitted.

> "removes security warnings informing users that they need to update their CPU microcode" If you update your CPU microcode to something that can't be checked, you're already sacrificing security. EDIT: But yes, I understand people complaining that FSF rejects proprietary software but is OK with some forms of ROM which in turn may be very similar to "proprietary software you can't change". Well, I never asked their r…

> If you update your CPU microcode to something that can't be checked, you're already sacrificing security. You're not sacrificing security, you're making a tradeoff. If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by a…

>You're not sacrificing security, you're making a tradeoff.

If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706

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

#265

Post by medo-bear »

Qwertious wrote: post #263
medo-bear wrote: post #136

Earlier quoted context omitted.

why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers

Hardware operates differently to software - it's impossible to verify hardware after it's been manufactured+shipped to you, so you need to trust the ENTIRE manufacturing and ownership chain of EVERY SINGLE COMPONENT. This is true of both open- and closed-source hardware. Look, don't take my word for it - take the word (and more importantly, the reasoning) of the guys behind the Novena open laptop: https://www.bunnies…

understood. but does not restricting blobs to a place where verification is impossible isolate the problem? to me this approach still seems reasonable from a free software (as per FSF) point of view

also i am confused why this issue isnt being taken with the hardware manufacturers? if i purchased their product, and if their user license did not forbid me from using linux-libre, and if this update is absolutely vital for my safety, then it makes much more sense to take issue with the manufactures. they should open source the update in this case

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

#266

Post by medo-bear »

marcan_42 wrote: post #247
onli wrote: post #219

Earlier quoted context omitted.

That's not true. If distros package closed source firmware updates the manufacturer has the ability to provide updates to people's computer via that system. I mean, that's the whole point and in a trustworthy environment that's a good thing. Maybe have a look at https://wiki.debian.org/Microcode#CPU_microcode_non-freeness (I'm not sure whether I'm just misinterpreting your comment or whether there is a knowledge gap,…

> If distros package closed source firmware updates the manufacturer has the ability to provide updates to people's computer via that system. That is not what linux-libre is doing/refusing to do. What linux-libre is doing is censoring a message to their users that their microcode is out of date and their CPU has security vulnerabilities. They could've just left that in and let users make the choice whether to manuall…

>Agency is more important than software freedom. The FSF's problem is precisely their blind focus on "software freedom" when the definition of "software" can't even be precisely defined any more, to the detriment of everything else that affects users

your refusal to accept FSFs right to adhere to its principles is bordering on the extreme. yet you constantly lob insults toward them as an organization. it does not help your points at all. they obviously hold different values to you. i think FSF is ok as long as they are clear about what they are doing and they are not trying to trick anyone. you have done absolutely nothing to demonstate otherwise in this whole exchange and instead you keep slinging FUD. i will repeat my question that i have asked so many times: has GNU or FSF anywhere claimed that they take a security-centric approach? as far as i know they have always taken a free-software approach. that they refuse to bend their principles to infantile screams is a big plus in my books

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

#267

Post by beermonster »

anthk wrote: post #173
kaba0 wrote: post #143

Earlier quoted context omitted.

At that point why just not power off their machines? That 3 websites that has “free js” is almost as useless as a brick. Also, free software in itself never protected against security vulnerabilities, many eyes is a fallacy.

You are really wrong, a lot of services (specially news) work either without JS or have a libre alternative, such as Twitter/Nitter, or Reddit/Teddit.

I use NoScript and I find very few sites that are really broken if I don't enable JS.

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

#268

Post by seniorivn »

grumbel wrote: post #124
earthscienceman wrote: post #13

A question that nags me every time Guix comes up, or nix, is about the benefits relative to a normal distro on something like ZFS. Are reproducible builds ever going to be all that important to a user? Rollbacks seem like the key feature here and that seems much better left up to the filesystem, not the package tools. This way your storage is also aware of what you're doing.

Rollbacks are a minor feature, I never found any use for in either Guix or Nix. The main advantage of both of them is that installation and 'making available' are decoupled. Meaning you can install five different versions of the same app and it'll be totally fine, as they don't sit around in '/usr/bin/foo' and clashing with each other. They sit conflict-free in '/nix/store/${HASH}/bin/'. For making them available for…

rollbacks are pretty useful when your are experimenting with boot process

everything else Is unlikely to break your system enough to prevent you from switching profiles

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

#269

Post by kdtsh »

marcan_42 wrote: post #258
kdtsh wrote: post #243

Earlier quoted context omitted.

This is an enormous thread now - in case it hasn’t already been mentioned, Guix neither helps nor hinders users from using any kernel they like. There is a repository called nonguix, made available by community members, which includes the upstream, non-free kernel, as well as microcode updates for Intel processors. The Guix project states clearly that it does not support these uses of the software, but that users are…

The problem is the endorsement of linux-libre, which goes beyond deblobbing into actively censoring messages. I'm sure Guix allows users to choose (it has to, thanks to Freedom 0, as you say), but by choosing a kernel by default that chooses to withhold information from its users, it is encouraging decreasing user knowledge. That is something that people should be aware of, and honestly, something that should be cons…

This is completely obtuse. Why isn’t your anger at the Guix or Linux-libre maintainers’ supposed withholding of information (‘censorship’) directed instead at publishers of closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could? How does it even make sense for Linux-libre to publish notifications about available binary blobs of any kind, including microcode? Why doesn’t Intel just release the source so this can be put to bed?

There is an ideological battle here, and despite the way you frame it, it is between people who believe that users should be empowered to know what the software they run does, and people who don’t. Linux-libre sits in the camp of the former. I don’t know into which camp you fall, but your argument suggests the latter. I personally use the upstream Linux because it works easier for me and the hardware I have, but I have no bones about the fact that I am running non-free software, that that ideally I would have hardware which supported fully free software.

Also, as I said, the Guix maintainers believe that their users are competent. Guix users know what they’re getting into when they run Guix, at least when they get to the point when they would drive it daily or run it on a system they see as critical. We know that microcode isn’t included when we use Linux-libre, because it is non-free - and that’s just the way it is. Saying that the Guix project is withholding information from us is incredibly patronising. It’s not a big conspiracy - the project, along with the rest of GNU, is openly in favour of maintaining repositories of fully and solely free software, to the exclusion of all non-free software. And it goes without saying, it is not the job of people in the GNU Project to educate people about the perks of running non-free software - there already exists a wealth of resources about how people can go about doing this, and it does not align with the clearly stated goals of the GNU Project.

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

#270

Post by kaba0 »

fsflover wrote: post #226
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 This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_... . Any links to your argument?

Your link says they are comparable, with another study claiming better quality for open source software. While I really don’t think that grouping together vastly different softwares based on this one quality is meaningful (is a proprietary CRUD app made in 5 months with an ad-hoc architecture comparable to an open source database with proper planning and domain-expert programmers working on it?), I also didn’t claim that they were worse off, just that more eyes won’t find more/all bugs, because in fact, they don’t actually look for them in the first place.

The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.

Post reply on HN