invalidator

It depends on what you care about. The Kino Lorber has good color choices, but far too much contrast: dark areas (including the characters) are pitch black; and you can't see the clouds in the skies.

They're meant to show what is possible. The presets on my synth are split evenly between:

- recreation of a classic patch used in a well known song

- showing off some new-for-its-era feature

- Wow, how did they do that? I'm going to reverse engineer this patch and learn some things

Front loaders clean better, with less wear and tear on your clothes, using less water.

I think the best answer lies somewhere in compartmentalization and fine-grained permissions. In this case: run it in some kind of secure container which has access to read browser history, and write to its database, but definitely does not have network access.

Unfortunately there's no one-size-fits-all solution for this yet, but there are a lot of groups attacking it from different angles: Qubes, GrapheneOS, Firejail, Bubblewrap, Android/iOS app permissions, Landlock, App Sandbox, etc.

Google/Forrest rushed to embrace AI/Dan, and completely forgot about News/boat, which kept chugging along with no one at the controls until it degraded/crashed.

It's a leaky metaphor.

TDD is done in a tight loop (minutes) while coding. For every little micro-feature/fix, you write a test for the new behavior you want, implement the minimal ugly fix to get the test to pass, then rely on the tests so you don't regress as you clean up.

LLMs struggle with TDD. They want to generate a bunch of code and tests in large passes. You can instruct them to do red/green TDD, but the results aren't great.

SDD starts before implementation, and formalizes intent and high-level design. LLMs eat it up. The humans can easily reinvent the worst parts of waterfall if they're not careful.

They're not mutually exclusive.

You can do better: cut to 0%, let the needle fall, go back to 100% for a moment to catch the needle as it approaches the bottom of the scale. If you want to be fancy, add some quick sinusoidal ramps to smooth out the derivative.

The interest is BECAUSE it's well explored territory. The concept is proven and works fine.

On the low end where RISC-V currently lives, simplicity is a virtue.

On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.

As a kid I took a lot of classes at the Lawrence Hall of Science in Berkeley, which was paradise for fledgling nerds. On the last day they would have a little closing ceremony with some cute little science experiment. One of my favorites was "Going Out With A Bang".

The instructors would bring out a helium balloon and a candle on a meter stick. The balloon goes pop, huzzah.

Then the twist. "Hey, wanna do it again?" All the kids would be like "meh, I guess?" They would then bring out a balloon full of hydrogen (maybe some oxygen too?). It would look identical to the first one, floating there tethered to the lab bench.

When the candle hit the second one, it made a white flash and a really sharp BANG. It was an order of magnitude louder, and you could hear the transient bouncing off the walls and echoing in the halls. It made an impression.

Yes. Details here:

https://github.com/resumex/doom-over-dns/tree/main/TXTRecord...

If you need a specific version of one package: apt-get install hello=2.10-3

If you want to lock down versions on a system, Apt Pinning: https://wiki.debian.org/AptConfiguration#Using_pinning

If you have a herd of systems - prod environments, VMs for CI, lots of dev workstations, and especially if your product is an appliance VM: you might want to run your own apt mirror, creating known-good snapshots of your packages. I use https://www.aptly.info/

Containers can also be a great solution though.

Yes, it's due to internal resistance.

> The voltages of batteries, in the first place, is function of state of charge.

It's also a function of the rate of discharge. Have a look at this:

https://marsen.com.au/wp-content/uploads/2021/08/Panasonic-N...

All that space between the black and green curves is energy being lost to internal resistance.

There's a technical reason for it: the voltage sags when the battery is discharged quickly. Ah is relatively constant, but Wh decreases significantly with faster discharge rates, so it can't specified as a single figure.

> Almost right - the trim has more authority than the elevators.

Thank you, I'll update my brain and future explanations. :)

They are simple toggle switches without actuators. The switches are Honeywell P/N 4TL837-3D. Source[1]. Data sheet[2].

[1] https://ad.easa.europa.eu/blob/NM-18-33.pdf

[2] https://www.mouser.com/datasheet/2/187/honeywell_hwscs06627_...

MCAS autonomously adjusts trim downward. The trim switches override MCAS, but when released, MCAS can resume trimming down again. The trim adjustments don't "override" the pilot's elevator inputs (MCAS has no direct control over the elevators), but they can make the controls so heavy that it's impossible to pull up.

That's a pretty big yak to shave! Building a 5 axis that gives good results a big task. How long did it take you to get that working?

Why do you need to make so many molds?

The BIOS was an abstraction layer. In the old days, not everything was 100% IBM PC compatible. There were lots of weird graphics cards. Some systems had incompatible disk and keyboard controllers.

There was no memory protection in Real Mode, so you could always poke the hardware yourself, but something written on a Tandy wasn't going to work on a Zenith unless you supported both, or ran everything through the BIOS.

Over time, the OS took over the HAL role, with the BIOS only being used until the OS could load native drivers. Now it's UEFI... same idea with a higher greater level of abstraction and modularity.

It's not the same.

For a simple example, let's say you are simply driving in a circle. The car wants to lean toward the outside. The linear motors can provide a countering force, lifting the outside, lowering the inside, so the car stays level. Variable damping can only control the rate that it rolls. It will still roll in sub-second timescales, unless it completely locks down the suspension, which is terrible for both handling and comfort.

For another simple example: going over a speed bump. Linear motors can lift the front wheels over the bump, and then the rear wheels, so the body stays level the whole time. An active damper can go full-soft the moment the wheel hits the bump, but the compressed spring will still start lifting the front of the car. An active damper can do a better job managing the rebound on the far side so it doesn't oscillate, but it can't entirely prevent the bump from pitching the body up and down in the first place.

That's not to say it's worthless. Very fast active dampers can improve both handling and comfort. It's just nowhere near the level which is possible with linear motors.

It depends on the language you're using.

For my Ruby example, each of those method calls will allocate an Array on the heap, where it will persist until all references are removed and the GC runs again. The extra overhead of the named reference is somewhere between Tiny and Zero, depending on your interpreter. No extra copies are made; it's just a reference.

In most compiled languages: the overhead is exactly zero. At runtime, nothing even knows it's called "data" unless you have debug symbols.

If these are going to be large arrays and you actually care about memory usage, you wouldn't write the code the way I did. You might use lazy enumerators, or just flatten it out into a simple procedure; either of those would process one line at a time, discarding all the intermediate results as it goes.

Also, "File.readlines(i).count" is an atrocity of wasted memory. If you care about efficiency at all, that's the first part to go. :)

The author keeps calling it "pipelining", but I think the right term is "method chaining".

Compare with a simple pipeline in bash:

  grep needle < haystack.txt | sed 's/foo/bar/g' | xargs wc -l

Each of those components executes in parallel, with the intermediate results streaming between them. You get a similar effect with coroutines.

Compare Ruby:

  data = File.readlines("haystack.txt")
    .map(&:strip)
    .grep(/needle/)
    .map { |i| i.gsub('foo', 'bar') }
    .map { |i| File.readlines(i).count }

In that case, each line is processed sequentially, with a complete array being created between each step. Nothing actually gets pipelined.

Despite being clean and readable, I don't tend to do it any more, because it's harder to debug. More often these days, I write things like this:

  data = File.readlines("haystack.txt")
  data = data.map(&:strip)
  data = data.grep(/needle/)
  data = data.map { |i| i.gsub('foo', 'bar') }
  data = data.map { |i| File.readlines(i).count }

It's ugly, but you know what? I can set a breakpoint anywhere and inspect the intermediate states without having to edit the script in prod. Sometimes ugly and boring is better.

> Probably not a good idea for anyone with a timeline

It's not completely crazy. Software was developed by much smaller teams and got out the door quickly in that era.

> I can't help but feel like a lighter weight VM (versus electron) is what we actually want. Or at least what _I_ want, something like UXN but just a little more fully featured.

That's basically the JVM, isn't it?

It's interesting to think how some of the reasons it sucked for desktop apps (performance, native UI) are also true of Electron. Maybe our expectations are just lower now.

"as the Universe expands, photons lose energy. But that doesn't mean energy isn't conserved; it means that the energy goes into the Universe's expansion itself, in the form of work."

-- https://www.forbes.com/sites/startswithabang/2015/12/19/ask-...

TempleOS deserves a mention here. It boots up into a simple system with a C-like language featured front and center. It makes it easy to write small programs with simple graphics.

It feels like the Apple IIe and GW-BASIC systems that I cut my teeth on, but with more features (Simple windowing TUI, good editor, extensive help system, many examples) and high performance (compiled code running on modern x86 hardware).

I don't know if I'd give to a kid as their only computer (For better or worse, there's no networking, and I wish it had high res graphics modes and a little more polish), but it's a really cool environment for a curious young mind to explore.

https://templeos.org/

In my experience, farsighted people tend to be very casual with their glasses, whereas us nearsighted folks protect them carefully.

My theory is that being nearsighted, I can see my glasses - every smudge or speck of dirt is immediately visible to me because it's not too far from my focal distance. For farsighted people, the glasses on their face are so far out of focus that those things simply disappear.

If I lay down with my glasses and they rub against my face or the pillow, I know they're going to get smudged and I'll suffer eyestrain until I find a lens cloth and carefully clean them. Any nick in the lens will drive me crazy until I can get it replaced. As such, I am very protective of them - any time I lay down I'm fold them closed and lay them face-up on the headboard so they won't need more than quickly brushing off a few specks of dust. I also buy very thin, light frames because I can see them pretty clearly in my peripheral vision.

The people I've known who are farsighted (including my husband), are oblivious to anything on the glass. He'll just roll around in bed with them, and maybe once a week ask me to clean them for him. We have to get him heavier frames because the lightweight ones would be a mangled mess in a month.

So yeah, I'm guessing you have the latter experience... Sturdy frames and you aren't too bothered by some smudges when you get up.

Are you far-sighted?

For a couple decades now, the way I have interviewed people is to ask a simple, very-high-level question, then repeatedly asking either "So how does it do that?" (drill down), or "What happens next?" (back out).

For instance: What does 'printf("hello, world\n");' do? Obviously, it prints something, but how does it do that? Pretty quickly you're talking about includes, macros, libc, linking, machine code, system calls... One question can easily fill an entire interview slot.

The fun thing is there's no "right" answer. Nobody is expected to know everything about how software works, but everyone is expected to know something. This format gives the interviewee the opportunity to show off what they know best, and the interviewer gets to pry in to see how deeply they know it.

I'm a low-level guy so that's the direction I tend to probe. Usually someone else asks a similarly abstract high-level question. One of my favorites is: "Design a parking garage". Again, there's no right answer. It's a prompt for the candidate to show what they know. Very quickly they're coming up with functions and class hierarchies and/or data structures for vehicles, spaces, turnstiles, payment kiosks, figuring out how to pass them around, etc. The interviewer has plenty of opportunities to pry into design tradeoffs, add complications, and so on.

The grand idea is to have a deep conceptual discussion instead of just seeing if they can write a few lines of code. This also demonstrates how well they can communicate. The catch is you have to be sure they give some actual concrete answers in a few places, and aren't just fast talkers.