Radioscope, a device that turns Wi-Fi activity into sound.
It started as an exploration into sonifying data and finding ways to perceive invisible systems without looking at a screen. With a Raspberry Pi and headphones, you can “hear” your wireless environment in real time. Access points, clients, handshakes, data transfers all become texture and rhythm.
It’s not a surveillance tool and it doesn’t capture payloads, it just listens to signal activity patterns and maps them to audio.
One thing that interested me was the ability to passively recognise different behaviours and wifi environments by ear. For example, bursts of management frames (like deauth storms) have a very distinct “signature”. Not sure if the use case here is art, accessibility, security research or just curiosity but exploring the boundary between networks and perception is interesting.
Mostly, it was an excuse to play with Rust and Dioxus, pcap parsing, and audio design and to see what happens when you treat networks like music. I find it quite relaxing as background noise.
wow, I came here to comment that of course passengers can't hack an airplane, at least in the sense of taking control of it, because there's no way that anyone with half a brain wouldn't have an absolute air gap between the passenger facing systems and the flight control systems.
The 737 MAX was not a "crude mistake". The failure mode was a multiple independent root cause sequence of low probability events. If I remember correctly there were about 200,000 flights before it was grounded after two airframe losses which is a failure rate of 1 in 100,000 flights, 5 9s, which, when accounting for the average flight distance, is about as dangerous as driving per passenger-km.
People downplay it as a "crude mistake" to claim that the people at Boeing are idiots who could have avoided the problem if they just applied average techniques and common sense. No, preventing these types of problems requires extremely sophisticated safety engineering the likes of which no other industry even attempts. Other industries have dreams about making systems as safe as cars; in aerospace they have nightmares about making systems that are only as safe as cars.
The Boeing 737 MAX was a disaster because they made a plane around 100x-1000x more dangerous than average. It is unacceptable to have such a massive safety regression. But claiming it was a "crude" or stupid mistake is absurd. It was a extremely sophisticated mistake that demands a return to the extremely sophisticated safety engineering normally employed when designing aircraft.
The only reason for that system to exist is because the 737 MAX is effectively a flying flight simulator for earlier versions of the 737, because Boeing and particularly Southwest didn't want to spend the money to recertify pilots on a "new" type of aircraft.
So yes, it's pretty much a crude hack that wasn't needed for any objective reason other than to save some money for shareholders, and now people are dead.
> The failure mode was a multiple independent root cause sequence of low probability events. If I remember correctly there were about 200,000 flights before it was grounded after two airframe losses which is a failure rate of 1 in 100,000 flights [...]
> preventing these types of problems
"1 on 100,000" is not a "type of problem".
Just because an event is rare that doesn't mean it's some kind of niche scenario that's hard to prevent.
If you actually look at reports of what they did wrong (which you did not do at all), you see there were plenty of actions that went against safe engineering judgment. (And no, I'm not referring to mine or other randos', but those of actual engineers and pilots.) They blew past multiple safeguards in the process, which made unlucky events fatal. It didn't need to be that way, and it wasn't that way for other planes either.
First of all, I am not excusing how horrendous the 737 MAX failures were. They were a total failure of the safety regime. As I said, they were 100x-1000x worse than other planes which is a unacceptable safety regression. I am attacking the notion that the problem was "stupid" and thus easily fixed; no, the problem was very hard and thus needs a significant overhaul of their safety processes.
So, to get onto the main point, I disagree. The people who say things like "crude" or "stupid" mistakes are literally making the implication that the decision-makers were idiots.
"there's no way that anyone with half a brain wouldn't have an absolute air gap"
"After the Boing [sic] 737 Max disaster you still believe plane manufacturers don't make crude mistakes?"
That is a direct reply implying that the Boeing 737 MAX disaster is evidence that plane manufacturers do not have half a brain and make basic mistakes. That is a extremely dangerous perspective because it implies that the problem would not have occurred if they were not being stupid. I most commonly see this argument being put forward by commercial IT software developers who generally assume they have a whole brain and thus "if only the airplane people would adopt best practices" these dumb problems would be avoided.
This could not be further from the truth. The processes Boeing used when developing the worst catastrophe in a decade were still tens to thousands of times better than the moronic processes usually employed in software companies and were still likely better than the processes employed in basically every other safety-critical industry. That does not excuse their failure. They did 100x worse than everybody else and 100x worse than their past.
What it meant is that they needed to significantly overhaul the safety processes that lead to such a failure and re-adopt the old processes since their new processes were unacceptably terrible. It did not mean that any random person on the internet who, having seen the extensive post-mortem in hindsight, thinks they would not make the same mistake has even the foggiest clue about actual safety-critical development.
Downplaying how hard safety-critical development actually is does a great disservice to the amount of care actually needed to do it right. It leads people to think it is not actually that hard and then kill people in their ignorance. The message is that the amount of care Boeing spent to create a death-machine is probably 1,000x more than the amount of care you are putting in (if you are not making a safety-critical product); 1,000x more is a death machine, are you sure you are not going to kill somebody?
> The people who say things like "crude" or "stupid" mistakes are literally making the implication that the decision-makers were idiots.
No, it really is just stupid, and that's not a claim that any individual cog in the machine is stupid.
As the saying goes: "None of us are as dumb as all of us". You can have dumb outcomes even though every individual step of getting there wasn't that dumb.
I touched on this in an upthread comment, but if airplanes worked like cars then your driving license would only be valid for one model of car. Now, you're a Ford F-150 owner who got his license in the mid-80s, and you'd like to buy a new car today.
So of course you're going to be biased towards the 2024 F-150, because Ford's implemented a complex system to have the newer model pretend it's a 40-year old car. It'll handle like your 1986 F-150, even though the length, weight etc. of the car is drastically different.
This is going to work really well, right up until it doesn't, because something's going to have to give when you've got a driving simulator on wheels.
Type ratings should exist, because it makes sense to treat minor iterations in design as the same airplane, and e.g. only re-train pilots on the specific things that were changed.
But if you look at the evolution of the 737[1] there's just no way to claim with a straight face that a 2024 model of that airplane is in any meaningful way the same airplane as the original 737. It's got 109% more thrust, it's over 50% longer, almost 30% wider, and has >75% more takeoff weight.
Once you peel back the layers of obfuscation that claim is the reason for the 737 MAX disasters. The system that failed (MCAS) doesn't need to exist in the first place, it only existed to maintain this continuity of type rating.
Hey FYI when you edited your comment it was duplicated [1]. Afaik this is a rare race condition in HN. If you get to it before the two hour mark, you can delete the second comment.
> If a car can receive OTA updates it can receive OTA hacks, no passenger in car required.
True, but that seems like a different threat model—the title is "Can a Passenger Hack an Airplane?", so I was taking the analogue to be "Can a Passenger Hack a Car?" Specifically, the response
> wow, I came here to comment that of course passengers can't hack an airplane, at least in the sense of taking control of it, because there's no way that anyone with half a brain wouldn't have an absolute air gap between the passenger facing systems and the flight control systems.
I have a rust bucket, but it seems that a lot of newer models use bluetooth to pair phones with cars. I assume that car manufacturers have baked in at least some level of security to prevent every nearby rando from hijacking the car with bluetooth, but you know what they say about assumptions. And if the call is coming from inside the car (aka every passenger wants to play a different song and they all bombard the infotainment system with requests), are you just SOL?
But more prone to infotainment saturating the CAN bus. Infotainment can be hacked using the 5G connection facilities which no-one takes seriously. The CAN bus also drives the brakes.
I wouldn’t say it’s as easy as cutting the brake cables in 1950, but it’s as efficient.
Service brakes were typically hydraulic long before 1950. Only parking brakes would have been cable operated on the overwhelming majority of cars on the road in 1950 (or since).
The borrow checker is a hard hill to climb for a lot of people, to the point where many devs get to that part of the tutorial and decide to go do something else with their lives.
> Is someone out there really thinking “ah man, if only advertisements were more relevant!” ???
honestly, yes. adverts pay for most if not all of the free content on the internet. if adverts were more targeted they would become more profitable and therefore pay for better content.
very well target ads will suggest things to you that you would genuinely like or would be useful to you but have not yet heard about.
> if adverts were more targeted they would become more profitable and therefore pay for better content.
If ads were more targeted, that doesn't necessarily increase neither the ad spend of companies, and it most definitely doesn't increase the amount of money that consumers can spend on the things that are being advertised.
Most of the time, advertising is a zero-sum game. If you take ad targeting away from everyone, everyone will just do untargeted ads (i.e. ads that are only related to the context they appear in, not related to the person seeing them), and there will be no comparative disadvantage for any particular advertiser.
what fixed it for me was Yoga. a complete cure. aged 28 I was terrified I was going to lose livelihood not to mention perhaps the use of my fingers. aged 50 now, no troubles at all.
I agree with you, but on the other hand all tech jobs appear to have a hard requirement for <x> years experience in particular languages or technologies.
I have never seen a job advert that says "we don't care what skills you already have so long as you're good at learning".
Without the right keywords on your CV there's a good chance no-one will even see your CV because it gets automatically filtered.
True dat, but what does “must have 20 years’ experience with $technology” even mean? Using it day-in, day-out, for the last 20 years? Originally learning it 20 years ago, and periodically brushing up on the current release every few years when a project for which it’s actually appropriate lands on your desk? Or one year of experience, repeated 20 times?
Beyond indicating a degree of experience in the hiring company’s primary development language and perhaps a couple major libraries, it really is a worthless measure of anything, except perhaps of middle management that doesn’t understand shit about what it is it’s meant to be managing. Like I said, programmer attitudes are a part of the problem.
But I’m preaching to the choir here. If it’s any consolation, if was hiring I would rate Ability to Learn way more highly. As I observed on another thread recently:
“The key to being a competent software developer is really, really simple: Learn the Business. Because if you can’t/won’t/don’t understand the problem domain, how can you expect to solve problems in it?”
If what the company does require an “exotic” or bespoke language to beat its competitors, that’s just one more work tool to be learnt and used (and maybe learn from) for the duration, and price yourself accordingly.
Good question, and I think it reveals an embarrassing truth about common hiring practices: they’re designed to test for qualities that can be trivially tested for, rather than qualities that are actually productive down on the shop floor.
I suspect the best you can do at is read between the lines on the resume and ask searching questions at interview, searching for indicators that the candidate is an active and competent learner, not merely an effective chair warmer. Someone who shows an eagerness to step outside her comfort zone; who makes a point of talking with, and learning from, her users. Beyond that, well, that’s why new hires have probationary/trial periods, so that our initial guestimates of her abilities can be tested in battle.
Of course, all this presupposes you have a management and HR culture that expects managers and HR to know enough about computer programming and software development to be able to ask the right questions and make qualitative judgements on the responses. And, needless to say, just as there are way too many coders who don’t give a shit about anything except coding, there are way too many managers with zero clue how to do anything other than manage.
But if you don’t know jack about what it is you’re meant to be managing, how do you possibly expect to manage it effectively?
they can be super easily moved. just use the existing export feature, all a competitor needs is ability to import conversations.
reply