I love that article. There are also ones about dates and times. The more you deal with dates and times, the more you realize how messed up they are.
I love that article. There are also ones about dates and times. The more you deal with dates and times, the more you realize how messed up they are.
It was Internet Explorer. But, what was probably confusing about it was that anything that required Internet access would start up the program that dialed the modem and connected to the Internet. So, clicking on the icon would eventually launch the browser, but first it would launch the dial-up program, which would take about 30s to connect.
As an aside, it really grates to see how Microsoft called their browser “The Internet”. And that’s the least dastardly thing they did that let them use their monopoly on operating systems to destroy Netscape.
Was it Jen? She was entrusted to take care of the Internet by Roy and Moss, and she did a piss-poor job of it.
My favourite story about aircraft design about some of the design mistakes on the F-16 fighter.
The F-16 was the first fly-by-wire fighter. They didn’t have much experience with it, and tried out some new things. One was that instead of having a stick between the legs of the pilot they used a side stick. And, since everything was fly-by-wire they didn’t need the stick to mechanically move. They decided they’d just use a solid stick with pressure transducers, since it was simpler and more reliable than a stick that moved.
The trouble was that the pilots couldn’t estimate how much pressure they were using. This led to the pilots over-rotating on take-off (pulling back too hard). Even funnier was that at early airshows, when the pilots were doing a high-speed roll, you could see the control surfaces twitching with the heartbeat of the pilots as they shoved the stick as hard as they could to get maximum roll.
That led to them adding a small amount of give to the stick, essentially giving the pilots feedback on how hard they were pushing the control surfaces.
Another more subtle issue with the design was that originally the stick was set up for forward, back, left and right aligned with the axes of the plane itself. But, they discovered that when pilots pulled back on the stick, they were pulling slightly towards themselves, causing the plane to also roll. So, they realigned it so that “pulling back” is slightly pulling towards the pilot’s body, rather than directly along the forward / backward axis of the plane.
There was a listener question on a science podcast recently that asked about how the temperature changed on the moon during the recent solar eclipse.
They almost got what a solar eclipse was, but not quite. During a solar eclipse, the moon gets between the sun and the earth, blocking the light getting to the earth and casting a shadow on the earth. The side of the moon facing the earth is completely dark because the thing that normally lights it up (the sun) is completely behind it. But, the back side of the moon is getting full sun and just as hot as normal.
I think part of the problem with understanding all this is that the sun is just so insanely bright. Like, it’s a bit hard to believe that the full moon is so bright just because it’s reflecting sunlight. It’s also amazing that the “wandering stars” (planets) look like stars when they’re just blobs of rocks or gases that are reflecting the insanely bright light of the sun.
It’s amazing if you think about it. Light comes out of the sun in every possible direction. A tiny fraction of it hits the surface of Mercury, and only some of that light is reflected back out. The light reflected from Mercury goes in almost every direction. A tiny fraction of it hits the earth. But, even with that indirect bounce, it’s bright enough to see with the naked eye.
When I first code something up, I think of it as a first draft, and I expect maybe 5ish typos / brainos per 100 lines. Only a few times in my life have I finished writing a few hundred lines of code, tried to compile / run it, and not seen at least a few errors.
When I don’t see errors, it’s almost always because somehow I managed to not compile / run the code at all. Like, one of my typos / brainos managed to cause it to skip that entire new block of code. Only once or twice has it happened because I actually wrote error-free code the first time. And, let me tell you, that perfect code sucked up so much more time than the more typical bad code.
With the bad code, I see the various errors, quickly fix them, and those errors convince me that the compiler / interpreter has actually seen all the new stuff and judged it. But, with perfect-from-the-start code, I now have to go in and throw in print statements, or step through a debugger to convince myself that yes, the system actually made it into that function and actually did execute those statements.
It worries me that a programmer wouldn’t know for sure what’s happening when they hit tab, and that it’s a setting that can be changed.
That’s a setting in the editor.
The kernel definitely mixes tabs and spaces:
https://elixir.bootlin.com/linux/latest/source/block/bfq-iosched.c#L390
Why would I use spaces if I use tabs?
To comply with Python’s best practices:
https://peps.python.org/pep-0008/
Also, if you work on the Linux Kernel, you’ll see a mix of tabs and spaces:
https://elixir.bootlin.com/linux/latest/source/block/bfq-iosched.c#L390
Also, it seemd like a huge waste of time hitting the space bar so many times…
You use an editor that doesn’t auto-indent?
but you can follow any exception down to the exact line of code (or JNI call, I guess) where the problem occurs.
But, it’s not really where the problem occurred. How often do you get a stack trace and the bug fix is at the line referenced by the stack trace? Almost never. It’s more that it takes you down to the exact line of code where the effects of the problem are bad enough to affect the running of the program. But, the actual problem happened earlier, sometimes much earlier.
For example, NullPointerException isn’t actually the problem, it’s a symptom of the problem. Something didn’t get initialized properly, and nobody noticed for a while, until we tried to use it, and got a null pointer. Sometimes it’s easy to go from the effect (null pointer) to the cause (uninitialized thing). But, other times that “thing” was passed in, so you have to work backwards to try to figure out where that thing comes from, and why it’s in that broken state.
Sure, it’s better than nothing, but it’s still frustrating.
Find me anyone who claims they use tabs for indentation, and I bet I’ll find at least one case where they’re using both tabs and spaces.
The only safe way to avoid war crimes is to avoid tabs.
Yeah, who cares when someone sends the email. If your boss expects you to start responding to emails at obscene times, that’s another matter.
you can achieve a lot with a live/live system, or a 3 node system with a master election, or…
“A lot”, sure, but not say 5 nines. 99.9% (8 hours of downtime per year), is reasonable. That’s enough time to fire up an instance in another location if that turns out to be necessary.
99.99% (50 minutes of downtime per year) is harder. It means you need automatic systems doing the switchover, geographical separation, people on call 24/7 to diagnose and fix any issue in minutes.
99.999% is only 5 minutes of downtime per year. At that rate, you can’t even afford for someone on call to respond. You do still want them on call to verify the automated systems did the work, but you need to rely on automated systems fully handling any possible emergency. The system needs to fail over perfectly without any human intervention. For that, a 3 node system isn’t enough. You need geographical redundancy, as well as redundancy within each geographic region. You need to be able to do software upgrades without affecting that redundancy, so you need at least a secondary 3-node system so that you can do a blue/green deployment, testing out handing over traffic to the new system with the ability to instantly roll back if something doesn’t work.
Each “nine” you add reduces the “error budget” by a factor of 10, so as you start getting above 4/5 nines, you really do start to need specialized engineering which tends to come with high cost and complexity.
For a typical Lemmy instance, 3 nines is probably good enough. 2 nines might even be acceptable if people aren’t paying. But, for something like Netflix, 8 hours of downtime per year is far too much. For something like a high frequency trading platform, 8 nines might not even be enough. For them, the custom engineering and obscene cost of chasing 7+ nines is worth it because every second of downtime could cost millions.
where we required double digits of “nines” availability
Do you mean 99% or 99.99999999%? Because 99.99999999% is absurd. Even Google doesn’t go near that for internal targets. That’s 1/3 of a second per year of downtime. If a network hiccup causes 30s of downtime, you’ve blown through a century of error budget. If you’re talking durability, that’s another matter, but availability?
For ten-nines availability to make any sense, any dependent system would also have to have ten nines availability, and any calling system would have to have close to ten nines availability or it’s not worth ten nines on the called system.
If the traffic ever goes over TCP/IP, not even if it ever goes over the public internet, if it ever goes over Ethernet wires, ten nines sounds like overkill. Maybe if it stays within a mainframe computer, but you’d have to carefully audit that mainframe to ensure that every component involved also has approx ten nines.
If you mean 2 nines availability, that’s not high availability at all. That’s nearly 4 days of downtime a year. That’s enough that you don’t necessarily need a standby system, you just need to be able to repair the main one within a few hours if it goes down.
I’ll have to look into that, it may be more what I need.
Thanks for the info. I haven’t paid much attention to the NUCs lately, because the Raspberry Pis, despite their limitations, were closer to the specs I needed, and you can’t beat their price to performance ratio.
I didn’t realize quite how good the NUCs and the NUC-likes had become. Way overkill for what I wanted though.
I think there’s a niche for a computer slightly more powerful than a raspberry pi, with no need for active cooling, capable of running as a basic always-on server.
The Intel NUCs were always a bit too expensive for that, and the Raspberry Pis are slightly underpowered (plus the SD-card as the primary storage is limiting). But, there are increasingly ways that people who aren’t massive computer geeks would want an always-on computer. Things like a home security system, a media downloader, a home automation machine, etc. The power consumption, noise and size of a desktop computer is just overkill for that. A Raspberry Pi could be, but the default versions are not designed as servers. They’re more robotics sandboxes.
I hate these. You don’t need to program for very long before you see one of these. And, you get used to the idea that when it says there’s an error on a blank line, that it means something isn’t properly terminated on one of the previous lines. But, man, I hate these.
At the very least, you’d hope that by now compilers/interpreters would be able to say “error somewhere between line 260 and 265”. Or, more usefully “Expected a closing ‘)’ before line 265, opening ‘(’ was on line 260”.
Error on <blank line> just pisses me off because the compiler / interpreter should know that that isn’t true. Whoever wrote the compiler is a seasoned developer who has been hit by this kind of error message countless times. They must know how annoying it is, and yet…