RustyRussell

Nobody who would code this up would be entirely sane. But I can't help thinking "these are my people" when I read this...

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!

Moral: publish your hacks!

Hey, I found the email:

Date: Sat, 3 Jun 2000 02:17:47 +0200 From: Klaus Knopper <knopper@linuxtag.de> 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

Um, the Linux Foundation is an industry body, not a user or community group. You seem confused?

Yeah, but there's little culture of actually taking that time.

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.

For those commenting, I suggest you read the post linked by the rsync author:

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)

I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence.

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

"where intellectual property is not respected"

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?

I agree: fork is fast, cheap and easy. If you're spawning something for significant work it tends to be in the noise.

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...

Adam is not Satoshi.

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 share this frustration, but a downvote is probably a better reaction than a reply here.

You're writing this from a dystopian future where punctuation is banned? :)

For those like me who still require parsing assistance :

- We are Bob

- Red Rising

- Murderbot

On the other hand, I once implemented something to be told later it was novel and probably the optimal solution in the space.

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

I'm thinking early April?

A goid friend of mine worked on decimal floating point for IBM Power chips (I think it was Power 7 which had hardware support).

Anyway, he insisted on calling it just "Decimal Floating". Because there was "no point".

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!)

I want to implement this. My code is in C.

How does this help me check my implementation? I guess I could ask ChatGPT to convert your tests to my code, but that seems the long way around.

Did anyone else find the use if ABNF annoying?

  unicode-assignable =
   %x9 / %xA / %xD /               ; useful controls
   %x20-7E /                       ; exclude C1 controls and DEL
   %xA0-D7FF /                     ; exclude surrogates
   %xE000-FDCF /                   ; exclude FDD0 nonchars
   %xFDF0-FFFD /                   ; exclude FFFE and FFFF nonchars
   %x10000-1FFFD / %x20000-2FFFD / ; (repeat per plane)
   %x30000-3FFFD / %x40000-4FFFD /
   %x50000-5FFFD / %x60000-6FFFD /
   %x70000-7FFFD / %x80000-8FFFD /
   %x90000-9FFFD / %xA0000-AFFFD /
   %xB0000-BFFFD / %xC0000-CFFFD /
   %xD0000-DFFFD / %xE0000-EFFFD /
   %xF0000-FFFFD / %x100000-10FFFD

Also, where are the test vectors? Because when I implement this, that's the first thing I have to write, and you could save me a lot of work here. Bonus points if it's in JSON and UTF-8 already, though the invalid UTF-8 in an RFC might really gum things up: hex encode maybe?

Andrew Tridgell's KnightCap did this differently: it's a network chess server, and it would dump its data to a file and re-exec. The trick here is that it would keep the (network) fds open for zero downtime. IIRC he used a Perl script called datadumper to gen the code marshal/demarshal the structures.

This has the advantage that reboots can be handled fairly seemlessly too (though there will be reconnections then of).

2015? Title is correct, this is a typo

Yes, it's terrible, and the fact that their list_add takes parameters backwards from what one might expect, with no types to catch mistakes!

See https://github.com/rustyrussell/ccan/blob/master/ccan/list/_...

In recent years I've come to rely on this non-initialization idiom. Both because as code paths change the compiler can warn for simple cases, and because running tests under Valgrind catches it.

ryao 7 hours ago | parent | context | flag | on: Hacktical C: practical hacker's guide to the C pro...

  cast a `struct Foo*` into a `struct Bar*` and access the Foo through it (in practice we teach this as the "strict aliasing" rules, and that's how all(?) compilers implement it, but that's not what §6.5 paragraph 7 of the standard says!)

  allow a signed integer to overflow

> pass a NULL pointer to memcpy, even if the length is zero

There is a reason for this. memcpy is allowed to start reading early as a performance optimization, before it does a branch that checks if reading is only.

Where did you get this idea from? It's not possible, since you can hand an address at the end of an array, and length 0. The array ends at the end of a page.

You can't read extra bytes in this case!

I don't care, as long as a commit which fixes a crash, compiler error or test failure quotes the errorv. This helps searching for issues, and also helps later if you find they mis-diagnosed the problem.

Other peeve: quote the core of the bug report you're closing, so when GitHub inevitably goes away/turns evil/starts charging, you don't lose half your knowledge. The git tree should always stand alone.

We use the same for Lightning: even bits for incompatible changes, odd for backwards compatible changes.

OK, the whole "I am a lawyer" was next-levelled by this closing sentence: "Not only am I unintimidated by litigation; I sometimes rather miss it."

It's a trick I stole from ext2, and simplified. In that filesystem there are three bitsets: one for reading, one for writing, one for fsck. If you don't understand a bit you can't do that action.

For most protocols there's only reading and writing, so you can use odd bits to mean "backwards compatible features, you can read even if you don't understand" and even for "stop, we broke compat".

These days I generally advise that you interpret the version number as odd and even bits: odd means it's compatible with readers, even means it isn't.