Willing to relocate: Happy to occasionally visit an office somewhere in the world
Technologies:
Native code, on embedded systems, especially Apple platforms (C/Obj-C/Swift).
Latency-sensitive systems that exercise local inference (CoreML/MPS), including LLMs, and imaging (CoreVideo/Metal).
Less recently, device drivers (Windows & Linux) and firmware (PIC/MIPS).
I only read the paper (and the code in the paper) but not the complete source code, so maybe this would become clearer if I had, but...
Does Rust fundamentally guarantee that if you make a struct, its fields will lay out in memory in the order that you defined them? Can it be used to interact with APIs (really ABIs) who expect a C struct (or pointer to one)?
I think my main frustration with stuff like Go and Swift in this case is that their structs are not binary-compatible with C structs in this way because they rearrange things to be better aligned/packed/whatever.
Yes, Rust supports annotating your types with a `#[repr(...)]` attribute to control how it gets laid out in memory. There's a "C" repr that gives you representations interoperable with C.
> Does Rust fundamentally guarantee that if you make a struct, its fields will lay out in memory in the order that you defined them? Can it be used to interact with APIs (really ABIs) who expect a C struct (or pointer to one)?
You have to specify this behavior with #[repr(C)]. Otherwise, the compiler will rearrange fields to try to optimize packing and alignment.
Or, more precisely, reserves the right to do so in a future version. rustc does not currently do this. There are some compiler flags to randomize the struct layout just to make sure that you’re not implicitly depending on the order.
The source[0] has `repr(packed)` but they should be using `repr(C, packed)`. That'll blow up in a future rust version (possibly 1.80) since packed alone is not sufficient to guarantee ordering[1].
Go doesn't rearrange struct fields, which is also why there's a linter/analyzer which shows you whether or not you could be using less memory with better field sorting
> I think my main frustration with stuff like Go and Swift in this case is that their structs are not binary-compatible with C structs in this way because they rearrange things to be better aligned/packed/whatever.
If you need binary-compatibility with C structs in Swift, you can define them in a bridging header.
rstp-simple-server is fantastic, I use it for all kinds of stuff and appreciate how easy it is to deploy. More software should eschew having a million dependencies and focus on doing one thing WELL :)
I'm a programmer that doesn't really understand anything about media streaming. What is a good use case for this project? I can't decipher it from the description. It can read and publish media streams. What does that do?
I have used MediaMTX to proxy IP camera feeds to custom web pages.
IP cameras generally stream through the Real time Streaming Protocol (RTSP). This cannot be directly played in the web and also requires authentication in most cases.
MediaMTX acts as a proxy to convert RTSP→WebRTC and take care of the authentication.
Presumably it means no runtime dependencies? A lot of media software requires you to have a bunch of libraries installed via system package manager, so I’m guessing this is intending to contrast with that?
"Before Fariq can attempt to get back into the cockpit, Zaharie reaches up and flips the pressurization switch, cutting off bleed air to the cabin. The airplane rapidly begins to depressurize."
I really want to believe that a single switch doesn't control whether people in the back of the plane can breather or not...
It won't unless there is some sort of major hull leak. If it was off long enough it would start to be a problem. Its basically the same same as turning off recirc on your car's climate controls. (Also, the pressurization controls are almost always on the overhead panels, which contains things that are used almost always for startup/shutdown steps so it's not like the pilot is going to reach over to adjust a radio or the autopilot and hit the bleed air.
Really though there are plenty of switches in any cockpit that will result in the death of all aboard if no corrective action is taken.
Do you freak out about driving? Plenty of controls in your car you could say the same thing about. Yanking the ebrake at highway speeds in rush hour traffic isn't gonna end well.
Edit the 5th or so: There are also times when the pilot will legitimately and safely depressurize in flight, like when descending to the one of the super-high airports that are actually at higher altitude than typical cabin atmosphere, like La Paz Bolivia (over 13000ft, compared to a typical cabin altitude of 5-8000 or so. They do it gradually while descending, so they don't make everyones ears go bang all at once.
Edit the 6th: Also, there's a big difference between turning off bleed air (which is pretty benign) and actually hitting the emergency pressure dump control, which is protected by a guard that holds the switch in the normal/auto position.
I think the difference is that in a car, any action that could kill the passengers is nearly as likely to kill the driver as well. Obviously you can't stop the pilot from crashing the plane and killing everyone, but it's still pretty creepy to learn that there's a "kill all passengers but leave me alive" switch in every plane, in a locked cockpit inaccessible to the people whose lives are affected by that switch.
This is a really weird characterization of a normal airplane function.
First, you are seeming to act as if the power between passengers and pilots should be equal. Why would this ever be? The pilot has all the power and the passengers none. Thinking of past hijackings, it's obvious that it must be this way.
Second, the plane needs to be able to handle all sorts of 1 in a million events. Recall there were around 22 million flights in 2021, and of those, exactly 1 was involving a Boeing or Airbus jet (maybe that's even true for Embraer or Bombardier and that tier of airliner). This is because the pilot has a vast amount of controls that are required to handle various events. A plane is a pressurized tube flying thru the sky, of course controls for pressure in the cabin must exist to allow equalization under aberrant circumstances.
Finally, activating this "kill" switch would drop oxygen masks to every passenger in the plane automatically; the pilot does not have any say in this matter. While these masks obviously have limited duration, there isn't exactly a way the pilot could perform this mass murder without their own death or imprisonment being guaranteed too. Frankly, I find your representation of the purpose of the switch so immature as to be offensive.
I didn't say it was a bad idea with no legitimate purpose, just that it's pretty creepy. Given that it's only been used to commit mass murder ~once (at most), it's probably not worth implementing any mitigating controls.
If the pilots want to kill you, all they have to do is fly into the ground, and there's absolutely nothing you can do to stop them and nothing short of complete automation could ever remove that risk. I can't think of scenarios where the pilots would particularly want to survive after murdering all their passengers.
With https://en.wikipedia.org/wiki/Ethiopian_Airlines_Flight_702 when the co-pilot hijacked the plane to ask for political asylum in Switzerland, I remember news coverage reporting that he had threatened the passengers to cut off the air supply if they didn't remain seated.
This just reinforces the argument that the pilot is in control, and he can do as he likes. Fly normally, change course, kill everyone... When you step into a plane you put your life in the hands of a pilot.
It would be pretty easy to remove "kill everyone except me" as one of those options, if we thought it was worth it (which again, it probably isn't). Just mandate that an override switch for the life support systems be accessible in the passenger compartment.
> It would be pretty easy to remove "kill everyone except me" as one of those options, if we thought it was worth it (which again, it probably isn't).
The idea is to keep everyone except the pilot alive but unconscious until things improve. I think it's preferable to everyone unconscious and eventually dead.
Uh... what? Whose idea, exactly? Because that's an absolutely terrible idea. Altitude-induced hypoxia isn't like some kind of controlled medical anesthesia. If all the passengers fall unconscious from it then it's neigh certain that at least some of them are going to die. That's why commercial airplanes have emergency oxygen masks for passengers, not just the pilot.
If both passengers and the pilot aren't being supplied with enough oxygen to remain conscious 100% of the time, then something has gone horribly wrong. If the reason passengers aren't being supplied with enough oxygen to remain conscious is because the pilot cut off their air supply intentionally, then that's even worse. (Though again, thankfully that situation seems to be extremely rare.)
> and actually hitting the emergency pressure dump control
Wait, is there an emergency pressure dump control?
I kind of just assumed turning off bleed air would be the only option, and I would have assumed that turning off bleed air would complete depressurisation within a few min.
It's about that easy. Of course, masks are a-gonna drop, and flight attendants are going to put on portable oxygen bottles... and of course the crew should descend. But the whole plane architecture is built on the idea that you're trusting the people in the front with everyone's lives.
There was a disaster where the pressurisation switch was left in the wrong position by a maintenance crew [1], and the pilots didn't realise because they thought the alarm was for something else, and by the time they realised something was wrong they were starting to suffer from hypoxia and were no longer able to react properly. Additional warning indicator lights were added to the cockpit to make the situation much more obvious.
Now pilots would hear the warning, scan the indicators and see the indicator, and are trained to put on their oxygen masks immediately. The cabin masks would deploy automatically. Then they follow the checklist which is to descend to a safe level if the pressure is uncontrollable (which it wouldn't be if it's just switched off).
It's very unlikely the pilot would turn off cabin pressurisation, but it would be pretty gentle and warning alarms and indicators would start pretty quickly (including on EICAS on newer planes like the 777). The pilots could easily fix it well before their or the passengers' oxygen ran out.
I read a story about the "landing gear down" button being close and similar to the "shut off all engines" button in some bombers during WW2.
A few of them crashed after very long flights, on approach of the runway. Inexplicably, they suddenly felt right when they should have deployed landing gears.
So aircraft makers learned from that incident that no amount of training can mitigate a bad user interface. Especially if the user of your interface is dead tired after a 12h flight.
That was the "flaps down" switch, not "shut off engines". The key feature of fixed-wing aircraft is being able to glide unpowered; dropping the flaps however would be equivalent to yanking the yoke all the way forward.
But during a landing you would normally have the flaps down, this is exactly what they're for: to enable lower approach speeds and more visibility of the runway due to a nose down angle
After a few crashes that bad UX played a part in, I'm reasonably confident that in a modern aircraft that switch is somewhere hard to press accidentally.
(E.g., fuel selector switches that can enter an unexpected state while looking like they're in the correct state, take-off/go-around switches that could be triggered by a first officer wearing a watch reaching for the speed brake lever, attitude indicators with ambiguous backgrounds, three-pointer/drum-pointer/counter-pointer altimeters)
It's not going to be accidentally hit. And even if somehow it does get hit accidentally, there's a CABIN ALTITUDE warning that would go off before it becomes a problem.
Modern aircraft have very good warning systems that warn when configuration of the aircraft or systems necessary for life are in incorrect states, and the way they're used generally afford a decent chunk of time if something goes wrong.
What's with so many of these comments being flabbergasted that there's a switch in the cockpit that can cause harm to everyone on the plane?
Do you realize you're entrusting two people in the front of the plane with your life as soon as the plane takes off? There are probably DOZENS of switches that if they are flipped maliciously will result in everyone on the plane dying.
It also impacts the pilots (they don’t have their own pressurized area, it’s the same), but the pilots have more oxygen. Which is a really good thing 99.999% of the time.
That was a missed checklist item IIRC where the ground engineer had turned off the pressurisation while trying to debug a pressure leak (ironically), the pilot was supposed to check this in a couple of lists, they did but I think they glossed over it. Plus they might have ignored some inflight warnings. This is also the one where a learning pilot (also scuba diver, probably able to handle the lack of oxygen better) tried to save it but was too late.
Remote: Strongly preferred
Willing to relocate: Happy to occasionally visit an office somewhere in the world
Technologies: Native code, on embedded systems, especially Apple platforms (C/Obj-C/Swift). Latency-sensitive systems that exercise local inference (CoreML/MPS), including LLMs, and imaging (CoreVideo/Metal). Less recently, device drivers (Windows & Linux) and firmware (PIC/MIPS).
Résumé/CV: https://www.linkedin.com/in/bengl3rt/
Email: my first name dot my last name at gmail dot com