I ran Windows 95 on a 386SX-16 with an 80387, with 5MB of ram for a year as my main machine. It ran about as well as 3.1 did. The only real drawback was the disk space required for 95 over 3.1 + DOS.
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.
