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

Carefully but Purposefully Oxidising Ubuntu

jnsgr.uk

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Carefully but Purposefully Oxidising Ubuntu

#31

Post by rednafi »

As long as the tools work the same way as GNU coreutils, I mostly don’t care which language they’re written in.

One reason I never adopted tools like exa or bat is that the first deviates from ls flags, and the second changes cat’s buffering behavior. The yield from changing the behavior of these fundamental tools isn’t worth the cost.

Also, if memory safety and security—not just performance—are the reasons to rewrite them in Rust, we could just as well write them in Go and get better community engagement. These are mostly CLI tools, so Go’s performance would be more than sufficient. I don’t really buy the Rust evangelism here.

Re: Carefully but Purposefully Oxidising Ubuntu

#32

Post by gaganyaan »

geokon wrote: 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.

Re: Carefully but Purposefully Oxidising Ubuntu

#33

Post by Cyph0n »

dbghaj wrote: 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.

> no pictures

Damn, never heard of someone passing on a language because of pictures. First time for everything I suppose.

Re: Carefully but Purposefully Oxidising Ubuntu

#34

Post by Cyph0n »

dmitrygr wrote: post #29
TheCoreh wrote: post #26

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 (…

You can start a project just fine? Cargo does not require a connection to function - you only need one when it’s time to pull in external dependencies.

And if you really dislike Cargo, nothing is stopping you from using rustc + make directly.

Re: Carefully but Purposefully Oxidising Ubuntu

#35

Post by yjftsjthsd-h »

andrewshadura wrote: post #14
mappu wrote: post #10

Ubuntu (via Debian) already had a system for this in `update-alternatives`, which is almost certainly already installed on this person's system. Would it be possible to toggle coreutils/uutils via that instead of reinventing it? They're both effectively symlinks-managers.

The alternatives system requires both packages to participate. In this case, a better alternative would be the diversions.

Unfortunately,

https://www.debian.org/doc/debian-policy/ap-pkg-diversions.h...

> Do not attempt to divert a file which is vitally important for the system’s operation - when using dpkg-divert there is a time, after it has been diverted but before dpkg has installed the new version, when the file does not exist.

I doubt that diversions are safe for coreutils. Now personally I'd like to know if that could be fixed instead of making a new tool, but /shrug

Re: Carefully but Purposefully Oxidising Ubuntu

#36

Post by nenaoki »

dmitrygr wrote: post #29
TheCoreh wrote: post #26

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 (…

Pretty absurd conflation you've got there.

The package manager just offers a common interface for interop, you can still build without dependencies.

Re: Carefully but Purposefully Oxidising Ubuntu

#37

Post by yazantapuz »

loloquwowndueo wrote: post #17
guptadagger wrote: post #11

Earlier quoted context omitted.

Its always surprising to hear that people use this tool

Nah nobody outside Canonical uses it. Just sarcastically wondering why they don’t just abandon the thing.

When I read Juju I think you were talking about JuJu Densetsu xd.

Re: Carefully but Purposefully Oxidising Ubuntu

#38

Post by AlotOfReading »

rednafi wrote: post #31

As long as the tools work the same way as GNU coreutils, I mostly don’t care which language they’re written in. One reason I never adopted tools like exa or bat is that the first deviates from ls flags, and the second changes cat’s buffering behavior. The yield from changing the behavior of these fundamental tools isn’t worth the cost. Also, if memory safety and security—not just performance—are the reasons to rewrit…

Go's insistence on not using libc unless you have cgo enabled seems somewhat problematic from a distro maintainer perspective.

Re: Carefully but Purposefully Oxidising Ubuntu

#39

Post by N2yhWNXQN3k9 »

dbmikus wrote: 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.

True, but there is no reason that those battle-tested cases cannot be migrated into other projects by a mindful maintainer / author (not to say that language-specific issues cannot arise, yet rust vs C seems like a pond vs ocean scenario).

Re: Carefully but Purposefully Oxidising Ubuntu

#40

Post by N2yhWNXQN3k9 »

accelbred wrote: post #22

I don't buy that uutils will be a meaningful improvement for security. Though replacing GPL licensed coreutils with a MIT licensed alternative is not a good look for Ubuntu's support of free software.

> I don't buy that uutils will be a meaningful improvement for security

Why? Because it hasn't been a consistent major vector for attack in the last couple of decades?

Post reply on HN