You are still conflating the process of manufacturing vs able to design a safe aircraft. The ability of Boeing to correctly manufacture an aircraft to it's design was not the cause of 737 Max 8 crashes. The ability of Boeing to create a safe design was. (As an aside: I don't think self certification of a design should be a thing)
I perused that document. It says quite a bit on how the FAA needs to work on type certificates, but seems limited to that. It says nothing on airworthiness certificates.
I'm assuming you know this, but the reason people say there's a hard difference on this is because they really are two different topics covering two different things.
For the uninitiated, and simplified. For a particular aircraft you are about to board to be legally allowed to fly it needs an airworthiness certificate. An airworthiness certificate says _that_ particular airplane is essentially _identical_ to a prototype (or set of identical prototypes) that the manufacture has flight tested and demonstrated is safe to the certifying authority. The formal acceptance of the prototypes safety is called a "Type" certificate.
The ability to say "we made this identical to our prototypes" is what the FAA is restoring the authority of Boeing to self certify, and is a _normal_ thing for a manufacturer to have. It's _abnormal_ for a manufacturer to not have that, as it's the certifying authority basically saying "you don't know how to physically construct airplanes".
The document referenced says the FAA essentially accepted proofs / was pressured to accept assertions from Boeing that the type was actually safe, when it was not. That's basically saying Boeing didn't know how to _design_ aircraft.
Right, but the crux of OIG's finding is that there isn't a hard difference between the two.
The plane was not built to the spec that FAA type-certified. But at the same time it wasn't clearly out of certification either.
There were significant changes made to MCAS since the the type certification. However, there was no clear delineation of what types of post-certification changes would require another FAA type certification.
The permeability of the two types of certifications and the amount of design changes that can happen between them is the entire problem OIG is pointing out.
> FAA essentially accepted proofs / was pressured to accept assertions from Boeing that the type was actually safe
No, the document says Boeing's ODA team was pressured to accept assertions from Boeing's management. The Boeing ODA team is employed by Boeing. They are given de facto self-certification authority either by actually self-certifying (in the airworthiness case), or by choosing what it flags to FAA for external certification (in the design/type case).
Are you thinking of Daisy wheel? Dot matrix uses a set of pins arranged in a matrix that they ram forward to press the ribbon against the paper. Daisy wheel uses a raised character glyph and slams it forward into the ribbon. Every typewriter I've used has full glyphs.
The thing to remember about US states is that conceptually they are countries bound together in a Federation. There's a crap ton of complicated rules, but generally your state has a lot more power over your life than the US Federal Government does.
It's possible, but my anecdata is that the four people who have run into the back of my car in the past ten years have all been middle-aged men distracted by phones.
Two Audis (one of them written off to the point it had to be lifted onto the breakdown truck with a Hiab), one Hyundai of some sort, and one bicycle.
The cyclist was the only one I felt in any way sorry for, because he did actually hurt himself pretty badly and obliterated his carbon wheel and forks, but he shouldn't have been dicking around with his phone while riding down a steep hill at what I can tell from his Strava trail was around 35mph.
At no time did my car suffer any more than a bit of scuffing and damage to the old tennis ball over the tow hitch to stop the grease getting on my trousers.
I would say something a little different. The kernel is a _library_ that has an init routine you can provide the function for. Or put another way, without the kernel your go program would have to have drivers statically compiled into it. This was the world of DOS, btw.
I agree with your point, but I must correct you on DOS: it had device drivers too. :) That's how we used to access mouse input, CD drives, network, extended memory, etc. Yes, it sucked on the graphics and sound; every app basically had to reimplement its own graphics and audio layer from scratch, but the rest was quite abstracted away.
There were generic VESA SVGA drivers towards the end of the MS-DOS era.
Sound blaster(16) also came close to being standard enough that games could just support that.
Extrapolating I think MS-DOS was on a nice trajectory to having complete enough (and reasonably simple and non-bloated!) APIs for everything important, when it was killed off. Late MS-DOS 32-bit games were usually trivial to install and run.
More importantly, a kernel is a platform. Conceptually it isn't that much different than other platforms such as Chrome or Roblox. They all have to care about the lifecycle of content, expose input events to content, allow content to render things, make sure bad things don't happen when running poorly programmed or malicous content, etc.
Yeah no. An operating system kernel doesn't just act as a host for userland processes, it interacts with hardware. Hardware behaves in weird and unexpected ways, can be quite hard to debug, can fail, etc.
This is why Linux is excellent. Users of other operating systems often remind people to update their device drivers. A non-technical Linux responds asking what the heck device drivers are. To the casual user, device drivers become invisible because they work exactly as intended.
The kernel talks to the device using an API it exposes. Similarly Chrome will talk to the OS using an API it exposes. OS APIs can also behave in weird and unexpected ways, be hard to debug and fail. Chrome protects the content it hosts from this complexity. Interacting with the layer underneath you is part of your job of hosting things on top of you.
Those are just drivers to stuff that runs its own cpu and interfaces over some kind of serial port. Printers are a well known example of this. Also intel wireless nics with their firmware blobs.
Not are drivers are like that. For instance, drivers/input/serio/ps2-gpio.c is all about timing the right signals.
You are missing the point. The kernel is still abstracting over those GPIO timings so programs don't need to know the timings themselves. This is the benefit of using a platform. These low level things get abstracted away from what you have to do.
Oh, I see. You're piecing together the layers much like a cake.
The way I see it, everything is tied together as some kind of flow chart where different elements have different jobs. Linux is quite a small part of the system when compared to Google Chrome. Even if you were to invert the cake, as a whole it still wouldn't make sense to me to see it that way.
Hardware tends to have more distinct layering than the lalala-land of software where pretty much anything goes.
It's not really Netflix. Its Microsoft, Apple and Google.
So say goodbye to using teams on Linux. Using Microsoft365 on any hardware that is not Microsoft approved.
Or logging in to your bank without an iPhone or an android. We will surely complain but the bank will say that we only support secure devices and that means iPhones and Android, and how come you are making a big deal about it just buy one of these two everyone else has one.
> Or logging in to your bank without an iPhone or an android.
This is already possible (and common!) many banking apps, for better or worse, use device attestation features that require varyingly official copies of android. Were you already complaining about this?
Yes, "we" were, definitely. I already can't freely choose the OS that I have installed on my phone because I'm limited in the apps that I can install. For example many government ID and banking apps will refuse to work on GrapheneOS even though that OS is security-focused and will probably keep you safer than your regular Chinese Android flavor. But it's not sanctioned by a big international corporation so it's a no. Is your argument that we shouldn't complain since it is already happening somewhere ?
What's an "official" copy of Android ? AOSP is supposed to be open-source. "Official" means controlled by a multinational corporation. I'm very puzzled that the reaction to these entities gaining even more power, outside of democratic control, is met with a "oh it may me worse, it may be not" type of reaction.
Would you be ok if for example your government's website to pay your taxes mandated a device with attestation knowing you can only get one from Google, Apple or Microsoft ?
I am not unaware of the potential dangers of device attestation.
> Would you be ok if for example your government's website to pay your taxes mandated a device with attestation knowing you can only get one from Google, Apple or Microsoft ?
My point is this is already possible today. A lot of apps do it. An open attestation API means that, at least theoretically, systems not owned by one of those three providers could be used. Today you get, functionally, a signal of "this is blessed android or not". An alternative world where the device attests "I am grapheneOS" and it is up to the service to accept that attestation or not is strictly better than the ability today.
I'm not sure what your point is here. How credentials are stolen today is irrelevant to the fact that today, right now, at this very moment, banks can and do already do the thing you're worried will be possible only due to the prevalence of passkeys.
Oh my point is that their device attestation thing is security theater.
It's clearly just for getting that iso certification.
It's a power play by the platform vendors.
The vendors are literally saying:
We now have this "security" feature and banks have to use it to be compliant and it only works on our platforms, so I guess you have to use our platform unless you want to be unbanked.
I mean, I would agree that it's not a particularly useful thing for consumer-phone-bank usecases, but that doesn't mean the feature is bad (or harmful).
Just to be clear, no one is saying
> banks have to use it to be compliant
nor are they saying
> it only works on our platforms
As far as I know, if systems were to use attestation it would be in a lot of senses more open than what attestation is available today (in the sense that more devices could use it). But also I don't think anyone who works on passkeys is saying banks need to support FIDO attestation to be "compliant".
reply