I wonder how Waymos know that the traffic lights are out.
A human can combine a ton of context clues. Like, "Well, we just had a storm, and it was really windy, and the office buildings are all dark, and that Exxon sign is normally lit up but not right now, and everything seems oddly quiet. Evidently, a power outage is the reason I don't see the traffic light lit up. Also other drivers are going through the intersection one by one, as if they think the light is not working."
It's not enough to just analyze the camera data and see neither green nor yellow nor red. Other things can cause that, like a burned out bulb, a sensor hardware problem, a visual obstruction (bird on a utility cable), or one of those louvers that makes the traffic light visible only from certain specific angles.
Since the rules are different depending on whether the light is functioning or not, you really need to know the answer, but it seems hard to be confident. And you probably want to err on the side of the most common situation, which is that the lights are working.
> An error is an event that someone should act on. Not necessarily you.
Personally, I'd further qualify that. It should be logged as an error if the person who reads the logs would be responsible for fixing it.
Suppose you run a photo gallery web site. If a user uploads a corrupt JPEG, and the server detects that it's corrupt and rejects it, then someone needs to do something, but from the point of view of the person who runs the web site, the web site behaved correctly. It can't control whether people's JPEGs are corrupt. So this shouldn't be categorized as an error in the server logs.
But if you let users upload a batch of JPEG files (say a ZIP file full of them), you might produce a log file for the user to view. And in that log file, it's appropriate to categorize it as an error.
Counter argument. How do you know the user uploaded a corrupted image and it didn't get corrupted by your internet connection, server hardware, or a bug in your software stack?
You cannot accurately assign responsibility until you understand the problem.
This is just trolling. The JPEG is corrupt if the library that reads it says it is corrupt. You log it as a warning. If you upgrade the library or change your upstream reverse proxy, and starting getting 1000x the number of warnings, you can still recognize that and take action without personally inspecting each failed upload to be sure you haven't yet stumbled on the one edge case where the JPEG library is out of spec.
4xx is for client side errors, 5xx is for server side errors.
For your situation you'd respond with an HTTP 400 "Bad Request" and not an HTTP 500 "Internal Server Error" because the problem was with the request not with the server.
I will make up some numbers for the sake of illustration. Suppose it takes you half as long to develop code if you skip the part where you make sure it works. And suppose that when you do this, 75% of the time it does work well enough to achieve its goal.
So then, in a month you can either develop 10 features that definitely work or 20 features that have a 75% chance of working. Which one of these delivers more value to your business?
That depends on a lot of things, like the severity of the consequences for incorrect software, the increased chaos of not knowing what works and what doesn't, the value of the features on the list, and the morale hit from slowly driving your software engineers insane vs. allowing them to have a modicum of pride in their work.
Because it's so complex, and because you don't even have access to all the information, it's hard to actually say which approach delivers more value to the business. But I'm sure it goes one way some of the time and the other way other times.
I definitely prefer producing software that I know works, but I don't think that it's an absurd idea the other way delivers more business value in certain cases.
Analog cable channels were on a wider range of frequencies than regular TV (radio broadcast) channels. So the VCR's tuner had to be "cable ready".
Some cable channels, especially premium channels, were "scrambled", which meant you needed a cable box to tune them. So the VCR, by itself, could only record the basic channels that came with all cable packages. To record something from a movie channel (HBO, Showtime, etc.), you needed the cable box to tune it in and provide an unscrambled signal to your VCR.
And that meant the cable box needed to be set to the correct channel at the time the VCR woke up and started recording. The simple method was to leave it on the correct channel, but that was tedious and error prone. As I recall, there were also VCRs that could send a command to the cable box to turn it on (emulating the cable box remote) and set the channel, but you had to set that up.
Later, when digital cable came along, you needed the cable box involved for every recording because the channels were no longer coming over the wire in a format that the VCR could tune in.
Basically, you have some pedals which generate a vacuum, and then everything is powered and controlled via vacuum. (The internet may not be a series of tubes, but a player piano literally is.)
Using vacuum to control things may seem very niche and exotic, but it was actually very common. Basically every car engine up through about the 1980s used vacuum to control the engine. Cars with a mechanical ignition system often used a vacuum advance to adjust the timing at higher RPMs, for example. Early cruise control systems used vacuum to adjust the throttle.
Anyway, all pianos have felt hammers which strike the string. When you're playing the piano manually, there's a mechanical linkage between the key you press and its hammer. In a player piano, there's another way to move the hammer: a vacuum controlled actuator. The piano roll has holes in it corresponding to notes. The holes allow air to pass through, and that causes the actuator to push the hammer into the string.
In that dance hall machine, which appears to be essentially a pipe organ, there are some similarities and some differences. A pipe organ works by blowing air through the pipes. There's a "wind chest" that stores pressurized air, and when you press a key on the keyboard, it opens a valve to let air into a particular pipe. In the old days, that linkage (between the key and the valve) was mechanical. These days it's electrical or electronic.
At the end of the video above, he even briefly mentions a band organ (which is similar to a dance hall machine) and how music rolls work for it, and it's a similar vacuum system to a player piano.
So I believe a dance hall machine with a music roll probably uses a combination of vacuum and positive pressure. The vacuum would allow reading the music roll (the paper with holes in it corresponding to notes), and that vacuum would actuate valves that allow positive pressure air into the pipes to make sound. In order to convert one of those to be controlled electronically, you could use a bunch of solenoid valves to either control the vacuum or directly control the air going into the pipes. I'm not sure which way they do it.
I wish Mini-TOSLINK[1] had been more successful. It's allows you to put an optical and electrical audio output on the same 3.5mm connector (i.e. headphone port), which is helpful for saving space on crowded panels.
The trick is that your 3.5mm connector only needs to connect on the sides, so the end of the jack can be open for light to be transmitted.
This was seen pretty frequently on laptops for a while, but I think two things doomed it. One, most people just don't use optical. Two, there's nothing to advertise its existence. If you do have one of these ports, you probably don't even know you could plug an optical connector in there.
> This computer stuff is amazingly complicated. I don't know how anyone gets anything done.
I wonder what could be done to make this type of problem less hidden and easier to diagnose.
The one thing that comes to mind is to have the loader fail fast. For security reasons, the loader needs to ensure TMPDIR isn't set. Right now it accomplishes this by un-setting TMPDIR, which leads to silent failures. Instead, it could check if TMPDIR is set, and if so, give a fatal error.
This would force you to unset TMPDIR yourself before you run a privileged program, which would be tedious, but at least you'd know it was happening because you'd be the one doing it.
(To be clear, I'm not proposing actually doing this. It would break compatibility. It's just interesting to think about alternative designs.)
Then you'd have to add a wrapper script to su and similar programs that unsets all relevant environment variables. That set is not necessarily fixed; a future version of glibc may well require clearing NSS_FILES_hosts as well.
(This is about UNSECURE_ENVVARS, if someone needs to find the source location.)
Making these things more transparent is a good idea, of course, but it is somewhat hard. Maybe we could add Systemtap probes when environment variables are removed or ignored.
A related issue is that people stick LD_LIBRARY_PATH and LD_PRELOAD settings into shell profiles/login scripts and forget about them, leading to hard-to-diagnose failures. More transparency there would help, but again it's hard to see how to accomplish that.
Mh, I am starting to dislike this kind of hyper-configurability.
I know when this was necessary and used it myself quite a bit. But today, couldn't we just open up a mount namespace and bind-mount something else to /tmp, like SystemDs private tempdirs? (Which broke a lot of assumptions about tmpdirs and caused a bit of ruckus, but on the other hand, I see their point by now)
I'm honestly starting to wonder about a lot of these really weird, prickly and fragile environment variables which cause security vulnerabilities, if low-overhead virtualization and namespacing/containers are available. This would also raise the security floor.
> But today, couldn't we just open up a mount namespace and bind-mount something else to /tmp, like SystemDs private tempdirs?
No, because unless you're already root (in which case you wouldn't have needed the binary with the capability in the first place), you can't make a mount namespace without also making a user namespace, and the counterproductive risk-averse craziness has led to removing unprivileged users' ability to make user namespaces.
It's probably true that there are setuid programs that can be exploited if you run them in a user namespace. You probably need to remove setuid (and setgid) as Plan9 did in order to do this.
It is complex. There was another posting on HN where commenters were musing over why software projects have a much higher failure rate than any other engineering discipline.
Are we just shittier engineers, is it more complex, or is the culture such that we output lower quality? Does building a bridge require less cognitive load then a complex software project?
I think it's a cultural acceptance of lower quality, happily traded for deft execution, over and over.
We're better at encapsulating lower-level complexities in e.g. bridge building than we are at software.
All the complexities of, say, martensite grain boundaries and what-not are implicit in how we use steel to reinforce concrete. But we've got enough of it in a given project that the statistical summaries are adequate. It's a member with thus strength in tension, and thus in compression, and we put a 200% safety factor in and soldier on.
And nobody can take over the ownership of leftpad and suddenly falsify all our assumptions about how steel is supposed to act when we next deploy ibeam.js ...
The most well understood and dependable components of our electronic infrastructure are the ones we cordially loathe because they're composed in shudder COBOL, or CICS transactions, or whatever.
Exactly. The properties rarely matter outside the item. The column is of such-and-such a strength, that's it. But when things get strange we see failures. Perfect example: Challenger. Was the motor safe sitting on the pad? Yes. Was the motor safe in flight? Yes. Was the motor safe at ignition? On the test stand, yes. Stacked for launch, ignition caused the whole stack to twang--and maybe the seals failed....
> Are we just shittier engineers, is it more complex [...]
Both IMO: first, anybody could buy a computer during the last three decades, dabble in programming without learning basic concepts of software construction and/or user-interface design and get a job.
And copying bad libraries was (and is) easy. I still get angry when software tells me "this isn't a valid phone number" when I cut/copy/paste a number with a blank or a hyphen between digits. Or worse, libraries which expect the local part of an email address to only consist of alphanumeric characters and maybe a hyphen.
Second, writing software definitely is more complex than building physical objects. Because there are "no laws" of physics which limit what can be done. In the sense that physics tell you that you need to follow certain rules to get a stable building or a bridge capable of withstanding rain, wind, etc.
Absolutely. As an Electrical Engineer turned software guy, Ohm's/Kirchhoff's laws remain as valid and significant as when I was taught them 35 years ago. For software however, growth of hardware architectures/constraints made it possible to add much more functionality. My first UNIX experience was on PDP-11/44, where every process (and kernel) had access to an impressive maximum of 128K of RAM (if you figured out the flag to split address and data segments). This meant everything was simple and easy to follow: the UNIX permission model (user/group/other+suid/sgid) fit it well. ACLs/capabilities etc were reserved for VMS/Multics, with manuals spanning shelves.
Given hardware available to an average modern Linux box, it is hardly surprising that these bells and whistles were added - someone will find them useful in some scenarios and additional resource is negligible. It does however make understanding the whole beast much, much harder...
There are no big wins left in bridge building, so there is no justification for taking big risks. Also, in most software project failures, the only cost is people's time; no animals are harmed, no irreplaceable antique guitars are smashed, no ecosystems are damaged, and no buses of schoolchildren plunge screaming into an abyss.
Your software startup didn't get funded? Well, you can go back and finish college.
That's a real issue, but this is for a district heating system which already exists and already faces this issue. And yet the district heating system is presumably practical.
Changing to a different central source of heating (i.e. storage) seems orthogonal.
After you click the "SUBMIT A PUBLIC COMMENT" button (on the page you linked), you then see a message that says, "Comments are due 12/02/2025 at 11:59 pm EST."
I think a better UI design would be to show that info before you press the button, but my main point is that they are apparently still accepting comments.
Yes. When my mom got her first Android phone, she wanted to transfer all her photos from her Motorola Razr flip phone. She said the guy at the AT&T store had a device that would plug in to the data ports of various phones and transfer stuff between them, but it wouldn't do it, so he declared it impossible.
My mom was upset that she would lose her photos, so I puzzled over it for a long time trying to figure out a way. Finally, I realized I was being stupid and missing the obvious: both phones had Bluetooth! I paired them with each other, dug through Razr menus, selected the photos, and did a Bluetooth file send. As expected, the photos went right over. Well, I shouldn't say right over because it was very slow, but it worked just as it should.
A human can combine a ton of context clues. Like, "Well, we just had a storm, and it was really windy, and the office buildings are all dark, and that Exxon sign is normally lit up but not right now, and everything seems oddly quiet. Evidently, a power outage is the reason I don't see the traffic light lit up. Also other drivers are going through the intersection one by one, as if they think the light is not working."
It's not enough to just analyze the camera data and see neither green nor yellow nor red. Other things can cause that, like a burned out bulb, a sensor hardware problem, a visual obstruction (bird on a utility cable), or one of those louvers that makes the traffic light visible only from certain specific angles.
Since the rules are different depending on whether the light is functioning or not, you really need to know the answer, but it seems hard to be confident. And you probably want to err on the side of the most common situation, which is that the lights are working.
reply