Live data from Hacker News

Carefully but Purposefully Oxidising Ubuntu

jnsgr.uk

41–50 of 50 posts

Re: Carefully but Purposefully Oxidising Ubuntu

#41
post #16

"with an increase in security comes an increase in overall resilience of the system" This isn't within my realm of expertise.. but I find it a bit hard to believe that GNU Coreutils is a source of a lot of security and resilience issues with Ubuntu.. Is this true? Does anyone in the know, know if Ubuntu has any answer to the Nix explosion? I feel my Ubuntu problems are always weird package issue. The system doesn't m…

> Nix explosion

I am reasonably sure that you can, not that you need to, use nix with Ubuntu?

I use Ubuntu (and other distros) because I respect the effort behind it.

Why does one need to stop for the other to exist?

Re: Carefully but Purposefully Oxidising Ubuntu

#42
post #16

"with an increase in security comes an increase in overall resilience of the system" This isn't within my realm of expertise.. but I find it a bit hard to believe that GNU Coreutils is a source of a lot of security and resilience issues with Ubuntu.. Is this true? Does anyone in the know, know if Ubuntu has any answer to the Nix explosion? I feel my Ubuntu problems are always weird package issue. The system doesn't m…

Their answer to Nix is snaps, which will never be the right answer to anything. They're stuck in an old mode of thinking and missed the boat. NixOS or something very much like it is the future. I personally won't go back to the snarled mess of state that is traditional distros like Ubuntu.

NixOS builds on efforts of things like https://cloud-init.io/ no? Or was one before the other?

Its not a snarled mess if you understand what you are doing, imo. Though, when I first started using operating systems other than Windows (~1998), I was very confused, and made many of the same mistakes new Linux users make. Actually, way worse, as there were no resolution to my mistakes (using linux, was a big one back in the day if you were on newer hardware).

I understand where the sentiment comes from. I just don't appreciate the conclusion or the leech-like entitlement of the community. We used to fix and push.

Re: Carefully but Purposefully Oxidising Ubuntu

#43
post #16

"with an increase in security comes an increase in overall resilience of the system" This isn't within my realm of expertise.. but I find it a bit hard to believe that GNU Coreutils is a source of a lot of security and resilience issues with Ubuntu.. Is this true? Does anyone in the know, know if Ubuntu has any answer to the Nix explosion? I feel my Ubuntu problems are always weird package issue. The system doesn't m…

> Nix explosion I am reasonably sure that you can, not that you need to, use nix with Ubuntu? I use Ubuntu (and other distros) because I respect the effort behind it. Why does one need to stop for the other to exist?

Nix on Ubuntu would be using a parallel set of libraries/dependencies. They won't be linked on top of the stable versions of packages as they've been selected in the LTS

I actually don't really know how that interplays with the rest of the system. If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop

The normal Nix versions numbers aren't stable. They have a stable branch but I don't think it lasts too long. And the "pinned" versions aren't as widely supported as Ubuntu LTS versions

Re: Carefully but Purposefully Oxidising Ubuntu

#44
post #43

Earlier quoted context omitted.

> Nix explosion I am reasonably sure that you can, not that you need to, use nix with Ubuntu? I use Ubuntu (and other distros) because I respect the effort behind it. Why does one need to stop for the other to exist?

Nix on Ubuntu would be using a parallel set of libraries/dependencies. They won't be linked on top of the stable versions of packages as they've been selected in the LTS I actually don't really know how that interplays with the rest of the system. If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop The normal Nix versions numbers aren't st…

yeah, https://nixos.org/guides/how-nix-works/

> parallel set of libraries/dependencies

snaps do the same thing? kind of the whole idea?

> If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop

See previous link

Re: Carefully but Purposefully Oxidising Ubuntu

#45
post #43

Earlier quoted context omitted.

Nix on Ubuntu would be using a parallel set of libraries/dependencies. They won't be linked on top of the stable versions of packages as they've been selected in the LTS I actually don't really know how that interplays with the rest of the system. If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop The normal Nix versions numbers aren't st…

yeah, https://nixos.org/guides/how-nix-works/ > parallel set of libraries/dependencies snaps do the same thing? kind of the whole idea? > If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop See previous link

Maybe I missed it... But That doesn't explain how it integrates with the host system (other than it doesn't ?)

It also doesn't explain how your PATH is maintained. When you type 'pwd' into the terminal, which version from the nix store is used? There must be a master copy or master symlink. You're not typing hashes all the time

Snaps have their issues, but if you run 'firefox' there is only one snap. The versions are not guaranteed to play nice with the distro app versions though. That's kind of why they can't snap everything

PS: There are actually nuances that it seems Nix doesn't handle clearly. If libA requires libB and libC. LibB and libC both require a libD at different version numbers - then you can't safely link two libD versions(short of name mangling). You need to build libB and libC at some version of libD that will work for both. Maybe you specific a set of workable dependency versions and let the system resolve them ? Seems very messy. Ubuntu just gives you the version numbers and you need to patch the code to work with them

Re: Carefully but Purposefully Oxidising Ubuntu

#46
There are advantages of Rust over C, but I'm not convinced that they are enough to outweigh ~35 years of development, testing and production use of some of the GNU coreutils. I also do not think that there are any problems with the GNU Coreutils that the only possible solution is to rewrite them from scratch and throw away all of that hard work and lessons learned.

Re: Carefully but Purposefully Oxidising Ubuntu

#47

Earlier quoted context omitted.

Their answer to Nix is snaps, which will never be the right answer to anything. They're stuck in an old mode of thinking and missed the boat. NixOS or something very much like it is the future. I personally won't go back to the snarled mess of state that is traditional distros like Ubuntu.

NixOS builds on efforts of things like https://cloud-init.io/ no? Or was one before the other? Its not a snarled mess if you understand what you are doing, imo. Though, when I first started using operating systems other than Windows (~1998), I was very confused, and made many of the same mistakes new Linux users make. Actually, way worse, as there were no resolution to my mistakes (using linux, was a big one back in…

Nix has been around since 2003, NixOS just takes that to its logical conclusion. cloud-init may have been inspired by it (I don't know), but certainly not the other way around.

By snarled mess of state, I don't just mean the way it works on first install, I mean the bundle of mud that imperatively managing a system inevitably turns into, with bits of this and that config left behind.

Try playing around with a few different window managers to feel the pain. NixOS makes it easy to try out new config and revert to the old config without muss or fuss.

Re: Carefully but Purposefully Oxidising Ubuntu

#48

Earlier quoted context omitted.

The package manager is an integral part of how the language is intended to be used in everyday practice, so it makes sense that it would be mentioned in the book, though.

So if I am on a plane at 36,000 feet, I cannot start a new hobby project without paying for WiFi and downloading shit from people I don’t know or trust? That is just unserious , when your competition is the much more mature gcc+make+vim combo, which is 100% offline and self-contained. And yes, I’ve done this (start a new project in a plane with no internet). Many times. eg: the world’s only PalmOS 5 device emulator (…

If your hobby project consumes libraries which are not already locally available on your machine, this same restriction would also apply when using gcc/make/vim. (e.g. say you want to use zlib, you'll need the zlib-devel package)

If the packages are already available locally, cargo works offline.

Re: Carefully but Purposefully Oxidising Ubuntu

#49
post #15

If the goal is safety, rewriting ancient battle-tested software is not the way to do it. The Lindy Effect for software: the longer software appears to be bug-free, the more likely it is bug-free.

With how often severe CVEs pop up years or even decades later, that is an unwise line of thinking.

In 2020, iOS suffered a zero day exploit based on font library code from the 90s. A bug that sat dormant for 30 years.

As far as rewriting / rethinking core utilities, I'm glad that for example `doas` and `sudo-rs` exist to beef up root authentication.

https://googleprojectzero.github.io/0days-in-the-wild/0day-R...

Re: Carefully but Purposefully Oxidising Ubuntu

#50
post #3

I think more people might adopt this language if there weren't such in-group terminology like "oxidizing", "Rusteceans", pictures of rusty equipment etc. I still wish for a serious book in the style of K&R or Stroustrup with no pictures, no mentioning of the package manager at all (sometimes it is mentioned in the first chapter!) and interesting code examples.

The reason I gravitated to rust is that it wasn't c++. C++ has too many footguns and too much crap that makes it terrible... I am looking exactly at template compiler output and also cmake. So, get on board or don't but don't try to make it C++ again.

Have you seen AAA gaming industry?
Post reply on HN