The real problem is when you have someone who is just competent enough to deliver mostly-working bit terrible code. Which the rest of the team has to maintain.
If the person is fresh out of college, of course, this is understandable and a senior person will likely be mentoring them, and reviewing their code. But when you have two such people who gravitate to reviewing each other's code, you have a serious problem that may not be immediately apparent.
Are you talking about flash embedded in the mcu, or separate flash chips? The mcu can usually reflash itself, modulo fuses, but I can't recall having seen a standalone flash chip which lacked a write protect (or write-enable) pin. A physical toggle switch on that line seems like a solid protection against NSA style firmware hacking.
Unless you're talking about a pin supplying a required programming voltage, that WE pin is just hooked up to internal gates that suppress writes. There are relatively easy ways to back-door gates (e.g., with secret access patterns or data sequences).
Sounds like the point of the (presumably criminal) trial was to determine whether Vanderklok was guilty of the charges presented - once he was acquitted, there's no point in continuing. If he wants to present a case against his accusers to show _them_ as being guilty of violating the law, he can, but that's a separate case - which he has indeed filed, very recently - and would be dealt with at a different trial.
In general, most ISPs will drop any routes more specific than a /24. Presumably datapath has negotiated with some specific providers to allow /32s; it's up to that ISP to scale their routers to handle it; other ISPs will only see the /24 aggregate.
Assuming this is a part 91 flight, when flying overwater more than 30 minutes flight time or 100 nm from short, they are legally required to have on board:
* A life preserver for each occupant of the plane
* Enough liferafts for all occupants [however they can share the same one as long as they're not exceeding the rated capacity and buoyancy]
* A flare for each liferaft
* One portable, floating, water-resistant emergency radio beacon
* A lifeline
* Survival kits attached to each liferaft
Then you have the remainder of the plane falling, uncontrolled, and potentially towards populated areas. Without a parachute at least the pilot will (hopefully) be trying to aim for an empty patch, and with a parachute at least the rest of the plane is falling rather slowly.
The pilot can aim for an empty patch, then activate the parachute so that the cabin lands softly and the rest of the plane falls on an empty field. Having the chute system installed doesn't remove any options from the pilot.
First, removing the cabin will cause a large shift in the plane's center of gravity; without adjustment of the flight controls, it is likely to stall, dive, tilt to the side, enter a spin, or some combination of the above, and is unlikely to hit anywhere near where it was aimed.
More importantly, though, the parachute is also meant to provide an escape mechanism for unrecoverable spins and stalls, not just engine failures or fuel exhaustion. In a spin or stall 'aiming for an empty patch' is, essentially, not possible, as the control surfaces of the plane are not usable due to reduced airflow. Additionally, in IMC (Instrument Meterological Conditions), it's not possible to see a safe landing spot. This is an ideal use case for a parachute, but if the plane breaks away as you say, the remainder of the plane will land in an unpredictable location.
There's also the increased complexity involved with ensuring all flight control and avionics connectors between the cabin and body of the plane break away reliably and quickly when the parachute is deployed, and never break away otherwise.
In short, adding a breakaway cabin might make the pilot safer (but might not, given the additional complexity for breakaway avionics and flight controls), but it puts more risk on the public at large when deployed, so it's understandable why such a system was never developed (with the possible notable exception of military ejection seats).
The Winklevoss Bitcoin Trust is not an exchange, it's an Exchange Traded Fund. Basically you can think of it as a shell company that exists solely to possess (approximately) 0.2 BTC per share; buying into it is _approximately_ equivalent to buying BTC (less the trust's expenses). It's no different in theory from precious-metal ETFs like GLD or PPLT, although I'd expect expenses to be lower since no precious metals need to actually be stored.
The operation of a trust like this is simplified by the fact that the Trust itself never buys bitcoins, and sells bitcoins only as necessary to pay the Trust's expenses. The day-to-day arbitrage that causes the price to track that of actual bitcoins is something that third parties do; they can exchange a certain number of bitcoins for a certain number of shares (and vice versa).
Anyway, it's a lot easier to run a trust like this than an actual exchange; you don't need to track lots of tiny transactions, allow every random person on the internet to open accounts, generate 1099-B forms, hold significant US dollar deposits, etc.
Heck, it doesn't even need a hot wallet; in that prospectus, exchanges of BTC for shares take three business days for settlement, which is more than enough time for a quorum of people to get their keys out of their respective bank safe deposit boxes around the country and sign a multi-signature settlement transaction offline.
The big advantage of this trust, though, is that once it is listed on a big stock exchange, you'll be able to go to any stock broker and buy an interest in bitcoin. Your accountant will be able to deal with the tax implications easily, since it's just a stock, and you'll even be able to do margin transactions through properly licensed and insured brokers. It'll take a lot of the infrastructure risk out of a bitcoin investment (although volatility risk will of course remain in full force).
Yeah, it's totally reasonable that they won't have a timeline the day they got the report. And if they fix it the next day, who cares that they didn't give an ETA? Clearly they had better things to do than reporting back.
Well, that depends. CLOCK_MONOTONIC_RAW does avoid NTP slewing, but NTP doesn't just adjust the time scale to adjust for offsets - it also attempts to correct for frequency error in your system clock itself. If you use CLOCK_MONOTONIC_RAW, you don't get that correction; you get something that on desktop hardware can easily be tens of ppm off from actual time. Of course, your MONOTONIC_RAW clock is still subject to the vagaries of physics; as temperature or system load changes, depending on the quality of your time source, you might get significant changes in the rate of CLOCK_MONOTONIC_RAW as well (which NTP will correct for in CLOCK_MONOTONIC, given enough time to adjust).