jbangert

I don't think the pilot factors in that much into the cost of operating a helicopter. Even a small helicopter (e.g. Robinson R-44 which is a bare bones trainer) needs a ~250k complete overhaul every 2200 hours/12 years in service. Add $60 dollars per hour in fuel and 60-100 per hour of miscellaneous other maintenance, and your variable costs quickly approach 300/hr. Add in all the fixed overhead, and a tiny helicopter that can take 2 passengers and limited baggage will run $400 dollars per hour easily (which is about what they rent for). A bigger turbine helicopter is significantly more expensive.

Most of this is because helicopters are complex machines (you're spinning really big blades pretty fast. Then using the blades + bearing to also lift the weight of the helicopter + more. Oh and you're changing the pitch angle of the blades. Oh you mean changing the pitch angles of the blades WHILE THEY GO AROUND...) and any failure in any of these parts is usually fatal so they have to be built and maintained to a very high degree of reliability.

Airplanes are much simpler (the spinning propeller attached to an engine is one part. The wing generating lift is another part. the flight controls are yet another part) and have more opportunities for redundancy ( a wing has multiple spars, and is attached to the airplane with many bolts. All helicopter blades meet in one hub, which is attached on one axis).

Combine that with aircraft scaling up more (you can build 500 person aircraft, but only 20 person or so helicopters), going much faster (a 120 dollar/hr propeller plane will outrun many/most helicopters) and the cost to go a given distance by plane will always be much cheaper than a helicopter.

Well, we start running one instruction, it just never quite finishes. The other OISC systems run way more than one instruction, they’re just always the same one with different parameters.

It’s not even desktop users; most desktop users download Ubuntu and never touch anything, on reasonably common PC hardware. Kernel regressions mostly get caught in the Ubuntu betas or testing tracks (e.g. Debian Sid).

The typical user the kernel developers focus on here is a kernel developer: always running the latest kernel with a stable user space. I find it extremely narcissistic that they reject security improvements for billions of devices, for what essentially just makes developers lives easier,

But do you want your box to send silently corrupted data for the next two years? Or would you rather reboot every night, and maybe escalate to your red hat support contract, where someone will then fix the underlying bug (for which you now have crashdumps),

Fixing all memory corruption bugs is infeasible without fundamentally changing the way Linux is developed. There is so much code (and it’s being added to, changed, etc.) written by humans that make mistakes.

There will always be some bugs that are in between being discovered (by someone, maybe malicious, maybe not), and being fixed. How else do you prevent against vulnerabilities in that stage?

A few points:

1) failing loudly is better than failing silently. A memory corruption issue (or a bad refcount, etc.) is not a benign issue that only becomes relevant under carefully crafted exploit conditions. You need the carefully crafted exploit to get the system back into an attacker controlled state (I.e. code execution); by itself (with non-malicious inputs, usually something random or slightly atypical — enough to not have been noticed yet, but typical enough that some program does it) the system is likely to either panic immediately (same result as with pax) or to corrupt some memory, in which case you will have a lot of strange behaviour to track down later (users will probably blame them on hardware or on their user space, so you might never see them. for example a recent OSDI paper showed that ext3/4 had several real world data corruption bugs. If these aren’t as frequent as the recent bcache issues, no one notices).

2) When I was doing research projects (into memory defenses on the kernel) about 3 years ago, there was no (commonly used, that I saw) automated testing infrastructure in the kernel. This makes catching regressions, especially in drivers for rare hardware, hard to catch. While tests aren’t a panacea, i think Linux overestimates what fraction of problems Code reviews will catch.

3) the “don’t break user space” strategy is already failing. Every mainstream distribution and embedded vendor stays on an old kernel branch. Big deployments do staged rollouts and extensive burn in tests. This isn’t just because the kernel, but because of extensive abreaking changes everywhere (compilers, standard libraries, etc. all need to change sometimes).the last time this happened, IIRC it was some audio bug in a strange configuration. In my experience, running a non standard Linux audio confit causes countless breakages, so an additional one in the kernel that might save my personal data from being exfiltrated is worth it. Most users have average (and therefore well tested) setups, which means thy won’t see breakages as often.

Perfect software doesn’t exist, and even MSFT backed off maintaining religious backwards compatibility (note that Microsoft’s approach was not to flame at developers and hinder new development, but through extensively building compatibility shims. Often, these came with trade offs strongly in favours or security, e.g. UAC).

Breaking user space is ok; users already expect breakage, and the cost of the additional breakages is low (to users and to society as a whole) compared to the cost of security breaches [citation needed, but Linux kernel security is relied on in a lot of places].

At least in the east bay, one reason why HOV lanes might run more effectively is that they are also express lanes (limited points at which you can merge in and out). On the other lanes, passing on the right/not passing in the left lanes is ok which slows down merging considerably. Also HOV lanes by definition have twice the (passenger) usage per car, so 2 HOV lanes and 4 regular ones are moving the same amount of people.

Car companies (at least European ones) tend to be pretty transparent about this: - Audi (example): letter (car/SUV/race car)+ number (quality: 1-cheap, 8-luxury) - BMW: first number is a quality class, two numbers is the Engine size. - Mercedes: first letter is a quality class, number is the engine.

Other luxury consumer goods use pretty similar schemes, e.g. Audio gear (e.g. bang + olufsen: the higher the number the better, with some number of meaningless zeroes added depending on fashion).

One observation might be that these companies all have halo products that are used to anchor/promote the volume offerings that drive revenue (e.g. The Audi r8 and the a3, the 90k speakers and the 1k set)

This simplified algorithm doesn't distinguish between learners (readers) and proposers (writers) to the value. I'd say this conveys the core ideas of paxos, and it makes sense to treat learners as a (performance-critical) extension/optimization, just like the many optimized paxos variants in the literature. Another benefit of treating read/write as a single operation is that it serializes reads and writes (e.g. in a distributed log).

Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).

A lot of research has been made in this direction by the PaX team/brad spender of grsecurity. In fact, many of these techniques were first implemented on modern kernels by that bunch. However, political moves have always clouded that -- pax/grsec is run as a project of passion and not as a day job, and therefore there has always been reluctance to deal with those (and get involved in sometimes very territorial code review/maintenance sessions).

Unfortunately, by not really crediting or even acknowledging this research (and also ignoring a lot of work thats been happening in academia on hardening commodity kernels and applications), the Linux kernel is a)playing catch up to other operating systems (instead of adapting newer techniques) and b) alienating researchers even further.

C++ compilers (at least on most current code bases that don't need modules) still need to parse and lex headers though -- so actual executable code is pretty rare. Most compilations are also debug builds which don't optimize(but creating debug information can also be slow; the really slow step is usually linking)