Conversation

Notices

1. Embed this notice
   SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:16:35 JST SuperDicq

   Cool thing that we lost due to Wayland:
   
   Desktop programs no longer put a sick looking "X" into their name like they did in the Xorg days.

   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:16:29 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Yeah but GNU is actually right when they want to do things their way, while GNOME is wrong about literally everything.

     翠星石 likes this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:16:30 JST Phantasm

     in reply to
     @SuperDicq I can still feel the smugness and "the only right way is our way" years later. Both projects share this attitude.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:16:31 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Gnome acts nothing like a GNU project whatsoever anymore.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:16:32 JST Phantasm

     in reply to
     @SuperDicq Those can fight for all I care. GNOME was a GNU project and still very much acts like a GNU project.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:16:33 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org And then there's GNU and GNOME fighting over who gets to put the G into their software names.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:16:34 JST Phantasm

     in reply to
     @SuperDicq At least KDE still usually puts a K somewhere, but that is also dying.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:19:27 JST SuperDicq

     in reply to

     Ok that one might also have been ruined by x(dot)com.

   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:19:43 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Autotools being an m4 and security nightmareDon't make it process untrusted inputglibc being statically unlinkableStatic linking bad

     翠星石 likes this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:19:44 JST Phantasm

     in reply to
     @SuperDicq Counter-argument: Autotools, glibc. Both do things in horrible ways that should have never been done, or at least changed over the years.
     
     Autotools being an m4 and security nightmare, and glibc being statically unlinkable, are just two examples.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:21:16 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org If you care about security you should also think static linking is bad.
     
     Instead of having a single glibc on your system, you would instead rather have every application ship its own different glibc version, potentially modified? That sounds like a security nightmare to me honestly.

     翠星石 likes this.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:40:15 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Serious answer though, GNU Guix fixes both problems you mentioned actually.
     
     On Guix you can have multiple versions of glibc installed if you need them. Because each version lives in its own storepath you can have each application link to the version of glibc that it wants, without static linking.
     
     Guix also fixes the potential security issues with autotools you mentioned. In Guix all build commands are done in a completely offline and isolated environment, so any potential m4 based malware can't do any damage.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:40:18 JST Phantasm

     in reply to
     @SuperDicq See? That's the typical GNU and GNOME attitude. You have it too.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 01:41:43 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Yes, GNOME 2 was good. Back then it was also still an official GNU project. GNOME started to suck as soon as they abandoned GNU.

     翠星石 likes this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 01:41:44 JST Phantasm

     in reply to

     • Phantasm
     @SuperDicq In fact I would argue that GNOME in the v2 days didn't act like that. Which was when they were still GNU I think. Ironic.
     snacks repeated this.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 02:00:30 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org But what if I need rescue binaries that I can run from a random kernel when the system borked itself and have them work.In all my years of GNU/Linux hacking I have never ever broken my system this badly.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 02:00:31 JST Phantasm

     in reply to
     @SuperDicq I never said that I want my system libc be statically linked everywhere. I agree that static linking is dumb in that case, which is why I don't particularly appreciate Rust and Golang being effectively static only.
     
     But what if I need rescue binaries that I can run from a random kernel when the system borked itself and have them work. You know, the kind that FreeBSD puts in /rescue. You know, such things like completely static Busybox that saved me numerous times. Can't do that without building a musl toolchain, because glibc maintainer decided that you shouldn't be able to do it. Same with some Autotools implementations dynamically linking libc when you specify --disable-shared --enable-static.
   • Embed this notice
     Gianmarco Gargiulo (gianmarcogg03@mastodon.uno)'s status on Tuesday, 24-Mar-2026 02:38:18 JST Gianmarco Gargiulo

     in reply to

     @SuperDicq we have a cool painted W instead.

   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 02:39:45 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org What about building a system that doesn't break unless the user does something really fucking stupid in the first place?

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 02:39:46 JST Phantasm

     in reply to
     @SuperDicq
     >In all my years of GNU/Linux hacking I have never ever broken my system this badly.
     
     Rescuing dying and corrupted systems considered harmful. Apparently.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 02:40:58 JST SuperDicq

     in reply to

     • :suya:
     • Phantasm

     @newt@stereophonic.space @phnt@fluffytail.org Less lines of code is betterToo simple of a way of looking at things.
     
     GNU Cat actually performs better than Busybox Cat because it does actual buffering and mmap trickery so it can handle large files better.
     
     Also Busybox has no handlers for special cases like multibyte strings, unicode and other obscure encodings and whatever. Many types of edge cases are just simply not handled in Busybox for the sake of minimalism.

     翠星石 likes this.
   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 02:41:00 JST :suya:

     in reply to

     • Phantasm
     @phnt @SuperDicq GNU code should be studied as an example of how not to write software.
     snacks likes this.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 02:48:38 JST SuperDicq

     in reply to

     • :suya:
     • Phantasm

     @newt@stereophonic.space @phnt@fluffytail.org That definitely doesn't meet POSIX requirements.

   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 02:48:39 JST :suya:

     in reply to

     • Phantasm

     @SuperDicq @phnt

     GNU Cat actually performs better than Busybox Cat because it does actual buffering and mmap trickery so it can handle large files better.

     Or they could just

     for(int i = 1; i < argc; i++) { struct stat st; stat(argv[i], &st); int fd = open(argv[i], O_RDONLY); sendfile(stdout, fd, NULL, st.st_size); close(fd); }

     Here. That's the entire cat for you, give or take error handling.

   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 03:00:20 JST SuperDicq

     in reply to

     • :suya:
     • Phantasm

     @newt@stereophonic.space @phnt@fluffytail.org Ripgrip is a different program for a different usecase, it is not a grep replacement.

   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 03:00:23 JST :suya:

     in reply to

     • Phantasm
     @SuperDicq @phnt and ripgrep (in Rust) is faster than GNU Grep. Maybe someone should rewrite GNU coreutils in Rust. Oh wait...
     
     Also, what does your find experience have to do with sendfile being faster than mmap?
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 03:00:24 JST SuperDicq

     in reply to

     • :suya:
     • Phantasm

     @newt@stereophonic.space @phnt@fluffytail.org That mmap() buttfuckery is totally unnecessary.Sure. Maybe you should do some benchmarks.
     
     I do know from experience that GNU find is about 10 times faster than Busybox find for example.

   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 03:00:25 JST :suya:

     in reply to

     • Phantasm
     @SuperDicq @phnt who cares? My point is, sendfile() can handle files of any size. That mmap() buttfuckery is totally unnecessary.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 03:06:47 JST SuperDicq

     in reply to

     • :suya:
     • Phantasm

     @newt@stereophonic.space @phnt@fluffytail.org Well I hope you don't have anything installed on your system that expects your grep implementation to be in any way shape or form to be POSIX compliant then...

   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 03:06:49 JST :suya:

     in reply to

     • Phantasm
     @SuperDicq @phnt yes it is. I replaced grep with it.
   • Embed this notice
     SuperDicq (superdicq@minidisc.tokyo)'s status on Tuesday, 24-Mar-2026 03:20:39 JST SuperDicq

     in reply to

     • Phantasm

     @phnt@fluffytail.org Perhaps because you can't currently build an identical system.Guix also solves this problem

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 03:20:40 JST Phantasm

     in reply to
     @SuperDicq Tell that to hardware gods when they corrupt data and rescuing it live with a replacement kernel and busybox to exfiltrate it somewhere else is the only sane option. Perhaps because you can't currently build an identical system.
   • Embed this notice
     :ihavenomouth: (inginsub@clubcyberia.co)'s status on Tuesday, 24-Mar-2026 06:34:31 JST :ihavenomouth:

     in reply to

     • :suya:
     • Phantasm
     • lolitechengineer
     @phnt @lolitechengineer @SuperDicq @newt how are you going to define macros
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 06:34:32 JST Phantasm

     in reply to

     • :suya:
     • lolitechengineer
     @lolitechengineer @newt @SuperDicq Who needs newlines. Those are bloat.
   • Embed this notice
     lolitechengineer@loli.church's status on Tuesday, 24-Mar-2026 06:34:33 JST lolitechengineer

     in reply to

     • :suya:
     • Phantasm
     @newt@stereophonic.space @phnt@fluffytail.org @SuperDicq@minidisc.tokyo yeah, its so good it even debloats the output by deleting information
     翠星石 likes this.
   • Embed this notice
     lolitechengineer@loli.church's status on Tuesday, 24-Mar-2026 06:34:35 JST lolitechengineer

     in reply to

     • :suya:
     • Phantasm
     @newt@stereophonic.space @SuperDicq@minidisc.tokyo @phnt@fluffytail.org how does that concatenate though???
   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 06:34:35 JST :suya:

     in reply to

     • Phantasm
     • lolitechengineer
     @lolitechengineer @phnt @SuperDicq it sends all files from args into stdout. That's how.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 24-Mar-2026 19:58:11 JST 翠星石

     in reply to

     • Phantasm
     @phnt @SuperDicq glibc is the best libc.
     
     autotools is the best build system.
     
     I enjoy running both.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 24-Mar-2026 19:59:52 JST 翠星石

     in reply to

     • :suya:
     • Phantasm
     @newt @phnt @SuperDicq GNU cat is one of the most awesome GNU programs - that's a great video.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 24-Mar-2026 20:02:34 JST 翠星石

     in reply to

     • :suya:
     • Phantasm
     @newt @phnt @SuperDicq That can only ever occur if you pass --version or --help and it can't output anything, which is correct behavior.
     
     GNU true always returns true if used correctly and all usages of true, use it correctly.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Tuesday, 24-Mar-2026 20:02:35 JST Phantasm

     in reply to

     • :suya:
     @newt @SuperDicq Look at GNU/Hello. 95% of it is just tens of lines of boiler plate to get gettext to work.
   • Embed this notice
     :suya: (newt@stereophonic.space)'s status on Tuesday, 24-Mar-2026 20:02:35 JST :suya:

     in reply to

     • Phantasm
     @phnt @SuperDicq ok i'll throw you a funny one. The GNU version of /bin/true can actually return false.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 24-Mar-2026 20:03:53 JST 翠星石

     in reply to

     • :suya:
     • Phantasm
     @newt @phnt @SuperDicq That is not portable - I would only expect that to work on GNU/Linux.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 24-Mar-2026 20:05:04 JST 翠星石

     in reply to

     • :suya:
     • Phantasm
     @newt @phnt @SuperDicq sendfile() is not portable - only GNU/Linux and BSD's implement sendfile() and use different function prototypes.
   • Embed this notice
     EdBoatConnoisseur (edboatconnoisseur@poa.st)'s status on Tuesday, 24-Mar-2026 20:07:38 JST EdBoatConnoisseur

     in reply to

     • :suya:
     • Loliphile
     • Phantasm

     @mikuphile @SuperDicq @phnt @newt uutils can't even meet half of the busybox tests.

     翠星石 likes this.
   • Embed this notice
     Loliphile (mikuphile@gearlandia.haus)'s status on Tuesday, 24-Mar-2026 20:07:39 JST Loliphile

     in reply to

     • :suya:
     • Phantasm
     @SuperDicq @newt @phnt That's why busybox and uutils exist. You can just use those for your troonix cruft POZZIX scripts and move on to tools actually designed for human use for everything else.