Anyone care to guesstimate how much effort there would be in creating an actually-secure curl and openssl? Using something like Common Lisp or Lean, instead of C.

I as skeptical as the next guy when it comes to the claim that ambient audio modulates the fluorescent light. But I could sure use more details on what analysis was done to the photos. Sounds like there were several photos taken, say 100ms(?) apart. Then the photos were subtracted pixel-by-pixel to look at the variations in time (between photos) or spatially (neighboring pixels)? I still think a photo-diode AC-coupled to a high gain amplifier fed into an oscilloscope would be the more conclusive test. Do a audio frequency sweep from 100-10kHz. Both with the fluorescent light on, and then again with the light off (as a control, in case something else in the setup is sensitive to the audio).

He has the integration time set to 1/8000 s.

I assume the idea is that you're effectively randomly sampling (with each shutter press) that amount of time of the sine wave. You should see a distribution of brightness if there's a signal present, unless you get unlucky and sample at the same brightness (many would be required). Capture many with and without audio signal present, compare std deviation. If they're the same, no signal.

But yes, truly terrible lab report. ;) Who knows if this data is meaningful.

I wonder if the original rumor came from a bulb with a failing ballast, with a "less stable" arc, or maybe with a mic/diaphragm integrated into it, that modulated the light by sinking some current? I always assume these more wizardly things are based in truth.

I distinctly remember paying $40 per megabyte at Costco to upgrade my Cyrix 486-40 from 4MB to 8MB (maybe 1994 or so).

I suppose I could envision a scenario like: Service A has a "reset your password" option. Someone with a "user@popular-unicode-domain.com" tries to use this option. Normally this fails when mangled-popular-unicode-domain-plus-garbage.com can't be found. Enterprising malicious actor registers mangled-popular-unicode-domain-plus-garbage.com, and now gets a hold of user password reset requests.

I don't think that is a reasonable request for a response to a comment post, but in my experience, many lisp macro advocates come from other procedural / OO languages and aren't well acquainted with other programming paradigms, so they don't generally know what the don't know about other styles, say functional programming, and how to solve problems using higher order functions, etc. instead of reaching for macros. Which is OK. Not everyone has to become a programming language dilettante.

Suppose I accede to every claim you make here. Where may I see the advantage in the long run, in any dimension? I'm willing to go with hearsay.

The word "dimension" is chosen to be so vague that you can surely do it. I would be easy to impress.

>Where may I see the advantage in the long run, in any dimension?

The advantage of what?

Or you could wrap arguments in lambdas (anonymous functions) for eagerly-evaluted languages. Lisp unfortunately has a bulky syntax for lambdas, compared to something like Smalltalk. Of course, you can fix this with reader macros in Common Lisp (but no one does). Clojure has a shorter syntax I believe as well: #().

If you want to get to the meat of the issue, without the extraneous stuff, you might also tackle: Godel's Theorem Simplified.

https://www.amazon.com/Godels-Theorem-Simplified-Harry-Gensl...

The extraneous stuff is honestly fabulous, IMO of course. Just being able to listen to a four part fugue sensibly is a rare but accessible pleasure. And amusing dialogs as an instantiated dialectic for showing the truth synthesized from apparent opposites, is a great pedagogical learning.

Extremely agree. The extraneous stuff is what makes the book magical.

I'm interested in reading more about how reader macros make `eval` better/useful.

>small enough to fit entirely in the L2 cache

Shouldn't the "hot" path fit in the L1 of a "modern" processor (100 kB+)?

Is that a bottleneck anymore? Maybe something that was appreciable in 1994 isn't a big performance hit in 2026?

Isn't it even worse now? The faster computers get, the more that software-induced bottlenecks hurt.

I could see just powering through because modern hardware is fast enough to do so being an option.

Adding 20% to a 10 second operation is a lot longer on a wall clock than adding 20% to a 1 second operation.

What even is a 20% delta in performance? Like a five year old difference in hardware design.

If I could get a micro kernel with a better security profile than Linux, that doesn’t sound so bad. I could easily be using a ten year old chip for my day to day browsing and probably wouldn’t notice.

> If I could get a micro kernel with a better security profile than Linux, that doesn’t sound so bad.

I suggest that you look at genode/sculpt:)

If anything, Mach style IPC has gotten worse because of the greater overhead if kernel/user transitions. Spectre really did a number on context switching overhead.

Hurd is like 36 years old at this point. More like adding 20% to a 10 second operation, compared to adding 20% to a 10ms operation.

People lost their shit when Spectre mitigations added 20% overhead to kernel calls though. Why wouldn't they do the same for microkernel overhead?

The same people are perfectly fine with Electron crap all over the place, they don't really care about overhead.

Not true in a data center - 20% less work for same CPU is like 25% more cores needed for any applications where the scaling is driven by CPU utilization. That is $ - and people have made things so far from efficient many medium size companies have 100k cores to pay for.

I'm having a hard time believing that data centers are chomping at the bit to use the Hurd.

If people really cared about performance, we'd be doing something other than the bloated way we have been doing things.

https://winworldpc.com/product/qnx/144mb-demo

I'm not a Hurd contributor ( or any OS kernel / library ).

I'm not sure this holds today. One example I can see is related to crypto. We used to have specific hardware for computing cryptography functions but it's now handled directly in standard hardware and the software has not evolved ( but it's been faster and faster to compute checksum functions )

I mean, every major arch has crypto specific acceleration instructions.

So for an I/O heavy program like a web browser, what percentage of CPU time is spent in syscalls? Someone must have that data for Firefox. 1%? 10%? And then that moves to 1.1% (or 11%)? And then every other program is even less affected? Curious if anyone is in the know.

Firefox isn’t io bound it is spending a ton of CPU parsing network buffers and rendering UI.

Nginx is IO bound in general - for my headless go stateful server, i could get syscall6 up to 20% of the profile time. It was a fight between GC in the gRPC code allocating for headers and the syscall6 for top single profile footprint.

Looking forward to reading the results of your benchmarking Hurd vs. Linux.

It depends on the OS, some OS have some way to do IO that gets around that. iouring or things like that. I don't know how Hurd does IO.

Most microkernals have methods to do IO in a different way. If they don't then likely they would pretty slow when doing I/O heavy operations.