I hacked up a (not SMP-safe!) compressed loopback driver for a now-forgotten startup's "bootable business card" rescue disk. Over a year later I received an email from someone wanting to use it who was trying to port it forward.
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!
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
---
Klaus Knopper LinuxTag 2000 - Europes largest Linux Expo
It seems that wasn't the Claude part, though I haven't seen a full analysis of exactly what broke. I also only saw one report: are there multiple, or do you just perceive that?
Rsync has many options: I can totally believe that fixing a bug in one place broke someone's usage, to be fair.
(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)
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.
As with many comments here: use a build-time assertion that the system is little-endian, and ignore it. Untested code is broken code.
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).
In the small, it's still a meritocracy. A patch like this is obviously correct and I expect to get in first try (maybe with a formatting fix by the maintainer).
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.
I want signal to act as a transport bus. In particular, I want to give certain contacts permission to ask my phone for its location, so I can give my wife that ability without sharing it with Google.
Signal has solved the identity part, now encourage others to build apps on it.
(2fa via Signal would be better than SMS, too, though I know this may be controversial!)
Frankly, the C standards ctte went off the deep end when they effectively banned NULL to memset etc (obv with zero length).
Not because these functions couldn't handle it, but because this assertion simplifies optimizations elsewhere.
This has required adding extra checks in my code, found mainly by trial and error, and has made it less readable and less optimal.
Finally, the checked arithmetic operations returning false on success is a horror show. Fortunately it will be found on the first time the code is run, but that's a damnably low bar :(