I built a (research) library a few years ago to rewrite ELF binaries; our research projects ran into a lot of limitations with doing incremental patches to a binary (ELF has a lot of redundant representations of the same data). For us, parsing the binary into a normalized representation, modifying that, and re-serializing worked — we could make more intrusive changes to the binary, and (almost? I don’t recall anything breaking) everything in the Debian repos still ran after the binaries has been rewritten.
I expect the library is now woefully out of date, and documentation is mostly in the form of conference talk slides:
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.
Atomic clocks show up on surplus auctions/stores somewhat frequently (they’re called a Caesium frequency standard, e.g. the HP 5071). There’s a few reports of enthusiasts keeping them running at home (http://leapsecond.com/ptti2003/tvb-Amateur-Timekeeping-2003....)
I’m sure HP/Agilent/others will gladly sell you the newer state of the art modes as well (although as high precision, very low volume devices they’ll be fabulously expensive); if an industry consortium wants even more precision you could staff a research team and shave off a bit more frequency error.
However, I think for industry it’s cheaper to use GPS receivers instead of supporting a powerful transmitter (and its use of value able spectrum). GPS can keep incredibly accurate time.
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?
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)
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)
One approach to reducing vehicle collisions that wasnt mentioned much in the discussion so far are road rules and design.
It is unrealistic to expect perfect responses from human drivers, or even compliance with rules. Also, human attention is severely limited (there are only so many things a human can keep track of, especially for extended periods of time). In other countries(e.g. Europe, which as mentioned further down had a more severe drop in traffic fatalities), traffic rules are often very different. For example, right turning on a red light (which can lead to collosions, hit pedestrians, Etc.) and the rather confusing right of way situation (there is no general rule for right of way, stop signs are in the order in which people arrive -- which is hard to figure out for people. Right before left or yield signage doesn't require looking at every other lane, but allows the situation to be resolved statically). There are also cleverer incentives, such as dynamically times traffic lights that give you a 'green wave' if you're going the speed limit -- so people are conditioned to drive at normal speeds. Many traffic lights here even in well off cities seem to be completely unsynchronized(or they all turn green at the same time) training drivers to speed through.
Similarly, being originally from Germany (which has no speed limits in large parts of the highway network, and higher speed limits in other places), passing on the right (which means you have to be aware of twice as many lanes which could cut into yours) and the focus on enforcing speed limits and not following distance seems odd. 60 vs 70 or perhaps even 80 isn't going to make that much difference when avoiding a crash, but having half a second vs two or three seconds to react is substantial. I have heard many anecdotes of people getting expensive speeding tickets for going 80, not one for tailgating.
At the end of the day, there will be collisions, and there will also always be a human factor in them, however no matter how draconian we make the penalties or how much we shift blame (or even not assign it), people will still drive, and we should spend some time thinking about how to make realistic driving conditions safe.
This argument will seem a bit more empathetic if you don't consider it as killing 59 people outright, but increasing risk factors so that on average 59 additional deaths occurred(unclear over what timeframe and what the methodology is). Spread out over the world population (we share the same air) that is a relatively short amount of lifetime.
On the other hand, consuming more fuel, making car ownership more expensive etc also carries real costs. People can't get work done, spend more of that lifetime tAking less efficient means of transportation, doing less enjoyable things like waiting on a greyhound bus, etc.
The sensationalist 'caused x deaths' headlights are very hard to reason With and usually one sided. That being said, car emissions are still a problem and there is a reason for these(and other public health) rules -- the response should perhaps be a little bit less emotional though. ( there are plenty of scandals that are probably more worthy of this emotional response, e.g. Illegal dumping or contamination, unhealthy foods, antibiotic overuse, etc.)
Your mechanic doesn't do much work Porsches. I have used them a lot in the past when I had a Saab (which is ultimately gm/American technology), but now that I have a decade old Mercedes and a decade old Porsche (I prefer maintenance over deprecation). Once a your mechanic contractor called me after the meeting was scheduled to start and told me that they couldn't service the car because they had no experience, diagnostic tools or spare parts for my car, and other interactions with them weren't better. Another time, their suggested 'OEM' quality parts really werent.
Another factor might also be that many high end imports are services at the dealer/speciality shops and the service interactions with your mechanic are for cars that have less than stellar maintenance-- which skews the picture significantly.
guidelines on what rules can do (e.g. That restrict rules on other actions) act to increase agency, not decrease it so I'd say they reduce the amount of bureaucratic hassle (they also decrease the total complexity of rules)
Yes, but that exists in other places as well (usually zoning is done locally -- in Germany it's on the city or county level). However, the different categories and what zoning can do vs. what it can't do (preserve 'character' / quality of life/ etc. yes. Discriminate against specific industries/groups/etc not so much.) are decided on a more global level (which also makes the process somewhat more transparent). I believe there are still facilities for local exceptions etc ( e.g. All houses in this street are a certain brick colour, and that has to be preserved), but these are more an exception than a norm.
I expect the library is now woefully out of date, and documentation is mostly in the form of conference talk slides:
https://github.com/jbangert/mithril
there’s also https://github.com/aclements/libelfin (parsing only, supports dwarf); https://github.com/bx/elf-bf-tools (Turing machine inside elf relocations) and of course the “olg guard” of ELF reversing tools ERESI/elfsh (website seems down; GitHub mirror on https://github.com/thorkill/eresi).