This project is a formalization of my various hacky scripts which ensure the requirements are accurately quoted, and give coverage if any are missing. Not a major Opus, but I hope someone else finds it useful!

Comments URL: https://news.ycombinator.com/item?id=49117854

Points: 5

# Comments: 0

Thanks, I will resubmit, and let's pretend this never happened? Eeek...

This project is a formalization of my various hacky scripts which ensure the requirements are accurately quoted, and give coverage if any are missing. Not a major Opus, but I hope someone else finds it useful!

Comments URL: https://news.ycombinator.com/item?id=49117345

Points: 1

# Comments: 2

When someone on my team started playing with this new Knoppix thing I was blown away: not just a rescue disk but a full-on distribution!

Moral: publish your hacks!

Hey, I found the email:

Date: Sat, 3 Jun 2000 02:17:47 +0200 From: Klaus Knopper To: Paul.Russell@linuxcare.com.au Subject: Compressed Loopback device Message-ID: <20000603021747.A17496@linuxtag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: rusty@linuxcare.com.au

Hello Mr. Russel,

I'm trying to use your compressed loopback device as found on the LinuxCare rescue CD-Rom, for my selfconfiguring Linux distribution that runs entirely from CD (including XFree and KDE).

Unfortunately, the version that I got of the cloop device seems to act quite instable (of course I recompiled it for Kernel 2.2.15, which should not differ all too much from 2.2.14). I blame it on the fact that the file handle is being read from stdin of insmod, but it could be something different.

With an SMP-Kernel, cloop.o crashes immediately on insmod when calling fget(0). With a non-SMP kernel, it kills the kernel block buffer system, shutting down all other block devices as well, when accessing certain large files on an ext2 filesystem within the compressed block device file. It seems that the ll_rw_block() routine fails in that case, and wait_for_buffer() never returns, locking up something in the kernel block buffer management.

Do you maybe have a newer version of cloop that I can start working on? Btw, I found and fixed the bug in extract_compressed_fs.c, but I think it would really be nice if the sources for the whole package could be downloaded from LinuxCare somewhere without having to get the whole CD-Rom image.

If I find the cloop lockup-bug before you have time to answer, I will send a patch.

Regards

                -Klaus Knopper

Rsync has many options: I can totally believe that fixing a bug in one place broke someone's usage, to be fair.

https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0

(Disclosure: while I haven't talked with him in years, Tridge was my colleague and mentor for many years. I feel it is worth considering his view before joining a crusade)

The actual Claude "churn" is mainly test suite enhancement.

This suggests to me the underlying concern is "but I won't get paid for my craft!".

Hell hath no fury like a vested interest masquerading as a moral principle?

Linux kernel uses 8k stacks (TBH, it's been a while), but there's also some copy-on-write overhead. Still, this is not the C10k problem...

In early days of Blockstream I remember him and Greg Maxwell spitballing ideas about Bitcoin, and he was clearly intellectually feeling out the constructions as novel concepts.

I have spent my fair time with geeks, myself included, and this "shiny new thing" geek excitement is distinctive. And Adam is a typical nerd for whom guile does not come easy, if at all.

I realize this is not a transferrable proof, but I stand by it, for what that's worth.

I was at IBM when we gave up on big endian for Power. Too much new code assumed LE, and we switched, despite the insane engineering effort (though TBH, that effort had the side effect of retaining some absolutely first-class engineers a few more years).

For large works, the burden shifts, since you are increasing the maintenance load. Now we have the question of who will do the future work, and that requires judgement of the importance of the work and/or the author, and hence is a fundamentally political question.

For those like me who still require parsing assistance :

- We are Bob

- Red Rising

- Murderbot

An AI might be more likely to find it...