285 karma · joined November 3, 2022
Only the persistent numeric AoA indicator was optional. And none of this had anything to do with freight, there's no difference in capabilities between the aircraft, it's purely about pilot situational awareness.
https://boeing.mediaroom.com/news-releases-statements?item=1...
Security is about trust. If you trust Apple or Google, and don't care about their 30% tax, then you should be able to choose that. Make it the default, even. But if you don't trust them, and don't want them to control what runs, that should be your choice too. It's your device for fucks sake!
"Security" is a weak argument for unconditionally giving up all control over your own device. Especially when that control is very obviously being used against us by those very same that are claiming to protect us. The situation is reminiscent of countless dystopian novels. If we're going to accept that anyway, I think it needs to come with much stronger protections for the common good in other ways than vague and pretty bogus "security" arguments. If they want lock in, I think they should have to operate the platform on a cost basis, and with strong antitrust protection in exchange for that privilege.
Most Windows PCs allow users to enroll keys in their secure boot system. Do you hear about grandpa getting his life savings stolen by this mechanism often? I certainly haven't. Much more likely he lost it to social engineering, where no technological measure is going to help you.
Ford can't geofence my Bronco to only drive to stores that pay them off, why should Apple be allowed to enforce what I can run on my iPhone?
> Does Apple have something like a "key" that would allow you to just run arbitrary software on the device? Is it something they would have to build, support, and maintain? I'm guessing this isn't a problem on Android and you can run whatever you want.
Not sure about the specifics of Apple's architecture (as it's also undocumented), but most modern secure boot systems have a hardware public key store (TPM) that any boot binaries must be signed with. Apple would closely guard those keys, and without them (and without security flaws), it is impossible to boot other code. Once you get a bit further along into the boot process, the architecture gets much more complicated as far as actually running apps, but it's all predicated on that secure boot key. Such a key store is probably possible to change, but Apple doesn't give any access to it from the userland, so users are unable to do so. It's also possible to make such a verification completely unchangeable in hardware; not sure if Apple may do it this way.
An open system would look something like UEFI secure boot, where the owner of the system can manage the keys in that hardware key store, to the extent of removing the manufacturer's keys entirely (which I think is also an important ability - what if I don't want Apple to be trusted on my device?). From there you can patch the OS to allow other code to run, though preferably this is something that would also be opened up explicitly.
Yes, it will require intentionally designing those capabilities into the products, but most likely it's not a significant architectural change, just a matter of giving users access to change the keys in the hardware they own.
That control, over something I paid for and ostensibly 'own' will be used against me, as in the case of App Store cuts and digital payments. Why should that be allowed? If I own it, it is mine, and control over its technology should be mine as well.
Nintendo will encourage you to buy from their online store, competing with Wal-Mart selling physical media (and maybe digital codes too on their own store?).
What it boils down to in my opinion, is that you own the device, and the company that built it should be required to give you all the keys to do what you want with it. The ability for companies to technologically lock out what their customers can do with the devices is relatively new, but there are quite a few areas of law that follow this principle of "once you buy it, it's yours, full stop", and I think this is just following along from that.
So I'd like to see general legislation in that direction, that would outlaw all these companies from locking down their devices as a first step. It doesn't have to be super easy, but it absolutely should be possible to run whatever code you want on any device you own.
I think antitrust surrounding these marketplaces is also due, but is much less fundamental and a lot more situational, where it matters less what the definition of 'a computer' is and more who's getting screwed, how badly, and whether competition is possible.
Grandfathering aircraft that exist indefinitely makes sense to me, but I don't see why designs should be grandfathered indefinitely for new builds, when we have learned a lot and increased our expectations significantly in the intervening years.
However all MAXes did/do have two AoA sensors, and prior to the fixes, regardless of the AoA display option, MCAS only considered one of them.
It could also be used while other aircraft/vehicles are crossing the runway at other intersections.
Let's wait for facts (ie. the accident report) before making such statements.
> There was confusion and no evacuation was ordered by the crew over the PA.
Of course there was confusion, that is inevitable. Again, we do not have solid information on what PAs were made, but from the looks of the damage and the likely accident sequence, the main avionics bay was pretty much completely destroyed. It's fairly likely the pilots were not able to make any evacuation order by PA on account of half the plane's electronics being on fire a kilometre behind them.
> The passengers managed it themselves. If it were a crew-directed evacuation they would have blocked the door leading to the still-running engine as you pointed out.
Video clearly shows an orderly evacuation, supervised by cabin crew, who can be seen directing from the exits with flashlights and leaving last. I don't know where you got the idea it was passenger managed from. It appears that the exits facing the worst of the fire were not deployed which is additional evidence of a properly managed evacuation. I don't know their SOP wrt. running engines, or if this engine was even 'running' and not just freewheeling (it doesn't seem to be producing meaningful air movement), but it appears they made a rational decision to use the R1 exit, since everyone survived and the evacuation was pretty quick (~2 minutes).
> It took the firefighters over six minutes to respond to the site of the burning aircraft. In the US and Europe this would be unheard of, the fire brigade would be rolling as soon as the aircraft hit the ground.
I haven't found video of the very early moments after the aircraft stopped, but there appears to already be foam laid down under and on the aircraft and at least two trucks attending during the late stages of the evacuation, so I don't know where you got this 6 minutes from. Given the circumstances, the crew waiting 6 minutes to begin evacuating doesn't sound reasonable.
> The only reason hundreds of people are not dead is directly attributable to the Japanese being an overly polite and orderly culture.
Yes, the passengers are also an important part of an effective evacuation, and it is why you should not ignore the safety briefing and follow the instructions of the crew. Good on the passengers for effecting a successful evacuation in this case. You might well be right it would have gone down differently elsewhere, with the eventual report yet again espousing the importance of leaving the baggage behind and maintaining order. This is reason to praise the passengers' behaviour and learn from it, not somehow criticize it as 'overly polite and orderly'.
I am sure there were things that could have been done better, but this was a successful and quick evacuation. It's far too early to decide what went well and what could be done better, but it's pretty clear that it was a good job - everyone got out quickly and with minimal injury.
Because you designed the system in such a way that interoperability was impossible without non-customers using your servers?
The fact that either of two tech companies are able to effectively gatekeep whether a given mobile app can for all intents and purposes exist in the market is a problem.
The law and practices need to react to the state of the world, and this situation was simply not a practical concern until recent times. Hell, the courts have historically been on consumers' side in adjacent ways, such as enshrining the right to reverse engineer & various provisions explicitly permitting doing so for interoperability, the Magnuson–Moss Warranty Act, and other decisions that protect consumers from getting screwed by the company they chose to buy a product from regardless of their official status as 'monopoly'.
There are a couple other options of course, but I am not sure they are better:
* Fully federate this, a la Matrix or XMPP. I really wish this was a practical option, but without legislation I doubt any company wants to go willingly in this direction. Even if they did, it'd be difficult to contain spam at scale. It also creates 'first contact' issues; love it or hate it, the general public seem attached to the idea of phone numbers and it seems to work relatively well and unambiguously. It is also the most technically complicated and most brittle and unpredictable for users.
* Phone / OS maker operates it for their devices. You don't seem to want Google running things, so this seems markedly worse than what they have actually done which is give you options (most people can at least choose a carrier, and carriers can choose implementations). It's unclear how operating costs are recouped here, especially for low-end devices. Does this lead to feature stratification? I hope not, but probably. It's a global single point of failure, both from a technical point of view as well as a policy/jurisdiction one (can $country LE subpoena my records because the company operating the service is ${country}an - or perhaps merely operates in $country, for example?). Also unclear how users are 'found', but maybe it's a bit easier than in a fully federated system.
* Phone / OS maker partners operate the service, giving users a few choices. Not really sure why anyone would go in for this, but it's basically the same as if the phone maker operates it.
None of these are great options, but I think the carrier is probably the least-bad one. You have an agreement with them. You have the legal protections offered in your home jurisdiction, with clear jurisdiction over the whole thing. They already have a ton of data on you and access to your traffic. You have a neck to wring if the service doesn't work properly.
They really should have standardized E2EE though, not including it is ridiculous.
Given the years of engineering effort involved in getting any of these projects to release, this definitely looks like an industry shift, not something driven by Apple.
Perhaps Intel's thinking here is that competition with ARM will drive innovation and cost-downs in that space, which will bleed 'up' and make their own competition's (mostly ARM) products even more competitive.
Historical veracity aside, I've heard this before and it just doesn't make sense for me why it's always presented as if this is the real invention of 'the wheel'. A 'pottery wheel' and a 'rolling wheel/axle' are separate inventions. There are some common mechanical elements, but the invention of the wheel, as commonly discussed, implies both rolling and transportation, neither of which a pottery wheel does. There doesn't seem to be a clear lineage connecting the two, either.
Check out the iCEBreaker project for a decent board to get going with, and some educational materials: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga
> The biggest problem though: the original requirement sounded like every output needs its individual "submix", so the complexity would quickly explode. You also cannot easily add e.g. delay compensation or digital EQ / FIR filter for room compensation if you later figure out this would be useful. You don't have these problems in the digital domain.
I definitely missed this, that makes it totally untenable in analogue domain as anything other than a ridiculous art project or back when it was the only way to do it.
The digital solution is much more flexible and once you get the pipeline running and understand how it all works, much easier to modify. I mention the analogue option only to offer an alternative, possibly more intuitive / easier to get started and experiment with option. Even in the simple mixer case, it's still probably not a viable solution for a real product, the digital stuff is so cheap now.
> I don't think the analog solution is significantly easier to build.
It's not just building it, but the learning curve. OP seems to have no electronics or DSP knowledge at all. Maybe it's my own background clouding my evaluation here, but bootstrapping even a passthrough ADC -> DSP/FPGA -> DAC pipeline to the point where it works sounds like a near-herculean task for someone without experience of either domain. For practical purposes it more or less requires custom PCBs which is its own learning curve, and even a basic FPGA is going to have non-trivial power, layout, and bitstream storage requirements to get right, which requires reading layout / power / app notes & datasheets. Then you need to learn the vendor's tooling and how to set up PLLs and design a clock scheme for the system, learn an HDL - which tends to be very unintuitive for software folks, with a steep learning curve of its own. Finally, you can eventually get to fooling around with your basic noop pipeline, but that is a loooong way from the word go to thinking about the problem you came in with.
It won't be, relatively speaking, any good, but lashing up a simple additive mixer with a couple opamps on a breadboard will get you something to start iterating on. In the end it might not be any easier to get to a final solution, but personally at least I find this kind of iterative improvement much easier than brick wall after brick wall with little to show for it. Especially given they want an 8x8 matrix, frankly I think using existing OTS audio interfaces is the only practical solution unless OP is willing to dedicate a man-year of work to the project.
> Don't forget that machine assembly is also super cheap now at least if you order in Asia, which removes almost all of the "soldering challenge" since usually only a hand full of big THT components like connectors will remain for you to solder manually.
I almost mentioned this, and I've done it successfully a bunch of times, but it felt like a bit too much learning curve (lol compared to learning HDL).
There is enough bandwidth on a USB 2.0 HS port for many channels of audio, you could just buy a couple decent multichannel USB 2.0 HS audio interfaces. They are pretty readily available with 8 in / 8 out (mono) channels in one box for a few hundred bucks. You can plug these into a RPi and it probably has enough grunt to do the processing using JACK or pipewire or some similar audio router with some custom code to manage it. Full-pipeline latency could be problematic, especially if you need to stay in sync with the TV and whatnot that is pretty noticeable and often can't be compensated. This is probably the simplest way to get something that 'works-ish' though. People use similar (smaller) setups for realtime room/speaker compensation filters and it seems to work alright, and this application isn't too far off from that. In fact, you might want to do that too.
There's an analog solution too, your RPi or microcontroller can manage an array of variable gain amplifiers (using a slow / cheap multichannel DAC) or programmable gain amplifiers (directly with I2C or SPI) which form the inputs to a traditional summing mixer circuit. Then you don't need to worry about processing some dozens of megabits of audio data with low-ms of latency and just need to set appropriate gains, but the analog design is a bit more complicated. Still, this is IMO much easier than an ADC -> FPGA -> DAC pipeline.
Prototyping SMT parts you can either buy protoboards with the chip mounted and pins for use with a breadboard, SparkFun and AdaFruit make tons of modules like this, or try AliExpress, and you can find devboards for pretty much any microcontroller or FPGA too. If the chip you need to work with doesn't have such a board available, you can get generic breakout boards for most SMT packages and solder the chips on yourself. It's not that difficult, though it takes decent equipment and a bit of practice. Having custom PCBs made is also super cheap now, and that is how I would recommend approaching this, if you're willing to tackle the soldering challenge and don't' mind the somewhat long iteration cycle as you wait for boards to arrive from Asia (or don't mind paying for premium shipping or a more-local manufacturer).
I have found allowing overrides is unfortunately the least annoying of two bad options. But I still get unreasonably annoyed when web apps steal Ctrl-K which I use constantly.
If I specifically want to search the entire corpus of data on an infinitely-scrolling site, I will use its search function intentionally, since that is a semantically different action.
So yeah, it does provide access to the framebuffer, and has a reasonably capable CPU - more or less like PCs of the time did, so of course it's a 'perfectly capable 2D platform' but in this era I don't think we were quite at the point where brute-forcing the graphics pipeline in software was 'easy', and the 2D hardware capabilities were... let's say 'not exploited' by Nintendo's SDK.
It wasn't preventing anyone from producing 2D games, obviously good games could be made, it was just definitely not optimized for that, and that just put more pressure towards 3D, that already had a lot of cultural pressure towards it. If the culture was there, I'm sure developers would have hacked away at it and developed it into a strong 2D platform, but without that it was a barrier.
I'm pretty sure the hardware would have given developers a real run for their money to create a SNES-level JRPG experience with smooth, good quality sprite-based graphics. As far as I know it has no 2D acceleration like the SNES, and a very small texture buffer, which leaves slow software rendering directly to the framebuffer, or low quality texture-based sprites. The hardware was really not designed for this type of game, so few were made.
Not providing any hardware to handle those types of games was a function of 3D being all the rage, and the hardware being very clearly targeted at that, but it also meant that creating 2D games was not just out of fashion, but impractical.
However you are right, it is hard to make an unambiguous distinction, so I am with you - consoles should also be forcibly opened up. I do strongly hold the philosophical view that if you own any computing device you, as the owner should have absolute control of what that device trusts as far as any cryptographic 'locks' are concerned. The place where this seems to have both a) the largest negative impact on the market and b) the best chance of people caring and doing something about it, seems to be with mobile computing, so that is where the voice are the loudest, but personally at least, I hold the same view about any device.
Our society has long held that reverse engineering is perfectly acceptable when it comes to interoperability / competition, even if the OEM doesn't appreciate it. Now, we have progressed technologically to the point that an OEM can literally prevent any reasonable manner of that, if they want to. I just don't think our laws / society have really caught up with that fact yet, but for me it follows directly from the reasoning behind allowing reverse engineering that we shouldn't allow this.
So I don't know why you keep bringing this up as if it is a counterpoint. Yes, it's a similar situation, and yes anything we do about Apple should apply to Sony as well.
The intent of the GPL to allow distribution to third parties seems pretty clear, and a company refusing to deal with you after you exercised a right explicitly granted by the licence definitely seems like a 'dick move', despite being legal.