So seriously that when they irrevocably lose control over my private contact list, they'll offer me a year's free credit monitoring for it.

That seems to be the accepted norm nowadays for fucking up and exposing private data to criminals. Lose your financial information? Free year! Lose your contact list? Free year! Lose your medical data? Free year!

Congress needed to grow some balls to hold CEO's accountable about 15 years ago. It's too late now, the horse is out of the barn.

No, we're talking about Medicare Advantage where private insurers oversee some Medicare benefits, in the promised belief that letting them do so would bring better efficiency and thus cost savings to the taxpayer. The reality is that it brought better revenue-generating efficiency to the insurers and higher costs to the taxpayer. Why does anyone ever believe that it's a good idea to let foxes watch the hen house?

The fact is that this is fraud, plain and simple. Only doctors should ever make diagnoses. Allowing insurers to add their own post-treatment diagnoses is unconscionable, and asking to be ripped off. If you took your car for a brake job and two weeks later the dealership's finance department sent you a bill for suspension work that had never happened you wouldn't pay it. Why is this different?

I remember the first time I opened Mosaic in late '94, having no idea what it was. My university department had a brand new lab of Linux machines and had given all of us EE students accounts, so I was learning my way around a unix-like OS for the first time. No one had yet configured a home page in Mosaic, and I had no idea what a URL was, so I stared at a seemingly useless grey screen for a few minutes, clicked a couple of arrows and the home button a few times, which did nothing, and then moved on.

The professional-looking application that appeared to do nothing intrigued me though, enough that I reopened it a couple of weeks later, by which time someone had configured the homepage to point at the department's brand new homepage. There wasn't too much there, just a simple welcome message, the (then-obligatory) link to CERN and a few other links. Just enough to get started ... and have my mind blown.

I soon discovered the Cambridge University coffee machine, MUDs, an early CGI scripted site (a write-your-own-adventure where you could add new nodes), and a new way to spend hours of my life. I learned how to fix Makefiles and compile code, and write enough html to put up my own basic homepage on the department webserver. (Security being non-existent then!). I learned about the beginnings of the internet, found the websites of both BBN Networking and VeriSign, and thought they'd both be cool places to work. By happy coincidence I several years later married an American and crossed the Atlantic, and ended up working for both of those companies.

I built a good career on my discovery of that lab, Linux and Mosaic...

They've been doing this forever now.

Wow, congratulations on getting that take completely wrong. You've shot the messenger.

Fortinet is a Californian company. The Dutch report is about research into ongoing world-wide exploitation. Fortinet products have been used in critical infrastructure around the globe, including water, oil and gas pipelines in the US. This is not an issue to take lightly.

I've personally been involved in three companies' transitions to Agile, all incredibly successful.

The first was was a large well-known managed security provider. I joined them when a waterfall project was already 6 months late, and spent the next 9 months working long hours to get to a release, and then the following year fixing it to attain most of the requirements. We implemented Agile and Test Driven Development, and soon after got to a regular release cycle along with a good work-life balance. Along the way we developed our own DevOps tools, cutting overnight deployment times from 8-12 hours to under 4, and eliminating a lot of risk at the same time. We already practiced DevOps ideology to some degree anyway - Developers and QA were heavily involved in production deployments and support even under Waterfall, but once we went Agile the tool development paid for itself very quickly. This was before DevOps was even a term in common usage, and before tools such as Ansible et al. existed.

The second was a subsidiary that was acquired by the first, a cyber-intelligence reporting company used by many Blue Chips and several three letter agencies. Their biggest problem wasn't so much Waterfall vs. Agile, but the extremely manual and complex deployment process that led to major QA headaches. Each deployment resulted in outages because so much information had to be hand-typed into the install programs, and that support was straining the small development team and delaying the next project. I was tasked with integrating the development team and ideology, so naturally moved them to the Agile process and pushed the DevOps toolset that we'd developed. Within 3 months we eradicated most of the quality problems that had plagued them for years.

The third was a different company that used a weird waterfall model. Instead of writing requirements, they wrote a draft of the user manual, and used that to code from. The quality was a clusterfuck. The low volume product appliance was installed for each customer by hand, from a 'gold' version built by whichever developer had time, from a cherry-picked code checked out of CVS on their development machine. Machines in the field were updated with hand-written scripts from specific version to specific version. The crappy home-built bug tracking tool was filled with bug reports closed as "can't reproduce". I did an analysis of the way that the software was installed and concluded that if there had been 13 point releases of a major version then there could potentially be any of 13! different versions of software actually in the field. No wonder no-one could reproduce so many of the customer-reported bugs. Other fun things included perl modules done badly. Data collection agents for different customer machine architectures all had their own version of the same module, so over time bugs that had been fixed for some architectures still existed in others. Feature changes that worked on one architecture then caused other bugs in others that didn't have the same set of fixes. Some architectures included the module, whilst others used them, leading to fun variable and function scoping bugs. I digress. We introduced Agile, Jira, a designated build system, DevOps, Subversion, etc. Subversion forced atomic code which worked wonders for the "can't reproduce" issues. We used DevOps techniques in the appliance update scripts. (It's amazing how much better a SQL database keeps working when you apply each update's table changes before its corresponding data changes, and force each of those updates in the correct order regardless of how many versions you are updating). The company ended up being bought by a major military manufacturer for over $100M.

The first company and its subsidiary committed to Agile and were very successful with it. The third company was always hedging in management. Despite Agile being introduced by a core group of developers who'd come together from the first, totally supported by our director (who hadn't), during the All Hands at the time of sale, the VP above claimed all credit for it. He hadn't even been at the company at the time, and was always pushing for "stretch goals", demanding time estimates instead of relative effort, and all manner of other Waterfallisms. We were successful, but it wasn't nearly so stress-free.

The point is that Agile can be successful. But Waterfall can also be successful if you have good requirements and a reasonable scope. It usually loses when management push the scope beyond what can be achieved in a reasonable timeframe. Bigger projects increase the time that customers wait, which often means demands for recreating the same functionality in an older release ... which ends up slowing down the project and results in a vicious spiraling deathmarch. The good thing about Agile (when done right) is that risk is mitigated. The problem comes when management cannot accept shifting priorities, and demand that feature X that they'd been thinking was coming next month still comes next month despite them green-lighting a big customer sale promising feature Y next month as well. It's the same problem at a different scale - too much work in too little time for the resources assigned. When Agile is done badly (like the 3rd company) management starts treating each sprint as a small waterfall that is merely part of one larger waterfall. It still has several benefits (such as code always being releasable, and flexibility to shift priorities at the point of development), but that problem of too much work in too little time rears its ugly head again. People start working longer hours to cram both features X and Y into next month's release cycle, and that extra effort is then reflected in velocity charts used to plan sprints. It's another form of a spiraling deathmarch.

The one thing that I really missed about Waterfall though was that big sense of accomplishment once a release was done and the major bugs addressed; and the period of mental downtime that often followed as the next release was being scoped and planned. With Agile it can feel relentless.

The nuts are castle nuts with cotter pins. When installed correctly, the cotter pins do not move or bend in use, so work hardening fatigue should not be an issue. The question is, what broke?

The reports that for the 3 previous flights had recorded cabin pressurization issues suggest that the plug was no longer sealed against the fuselage. That implies that either the seal failed (unlikely, IMO), one or more of the bolts yielded or snapped, a the castle nut(s) somehow loosened.

The fact that other airlines have now found loose bolts suggests that the problem should now be easy to identify and a solution found. Napkin math finds that an 8 ft x 5 ft panel at 40000ft exerts a force of ~ 70000 lbs, assuming cabin pressure at 14.7lb/in^2. That's static pressure though, if that panel is over or near the wing then that force could be slightly higher. That's not insignificant although I'm guessing at the plug size there. The worst case scenario is that Boeing didn't allow a large enough safety factor in their bolt size calculations. It's likely that they are already using high grade bolts, so will have little room to maneuver there. With so few bolts holding that plug in I'd expect to see a fairly high factor of safety to ensure that a problem with one bolt would not automatically cascade into failures of the others. Ideally, two bolts at opposing corners of the plug would be enough to hold it in place even if the cabin depressurizes, without those bolts yielding permanently. Reworking the fuselage and plug to allow bigger bolts would likely be a nightmare scenario for Boeing, possibly not even economically fixable for planes already delivered.

The best case scenario is that somehow hardware of a lesser quality got into their supply chain. It would still have expensive repercussions for Boeing, requiring investigation of the chain of certificates of conformity of that hardware, and efforts to remediate trust in the market, but at least replacing the bolts is a relatively cheap affair.

As for Alaska Air, they just got very lucky. If someone had been sitting in that row, there is a good chance that they could have perished, either by leaving the aircraft, or due to exposure. Given that the pilots had notified the airline about the cabin pressure issues, that would have been slam-dunk negligence in the resulting lawsuits.

What utter drivel.

The 55mph speed limit was introduced during the 1973 oil crisis specifically to reduce gasoline consumption during a time where there were lines for gasoline in short supply. The crisis was exacerbated by the US predilection for large cars with big engines, and was a large factor in Detriot's fall from the wealthiest city in the US in 1960 to one of the poorest today. Asian and European manufacturers had been contending with oil supply issues ever since WWII, so had been built small cars with smaller engines for decades, and were therefore well positioned to supplant US manufacturers during the '70s oil crisis. Aerodynamic drag force increases with the square of velocity. 70mph is 27% faster than 55mph, but the drag force is 62% more. The faster you drive, the bigger the proportion of energy used to overcome drag becomes. That's why the Bugatti Veyron, the fastest production road car in the world, with a respectable drag coefficient, can only manage just under 2mpg at its top speed of 267mph. It burns through 26.4G of fuel in about 12 minutes. That's also the reason why the Toyota Prius, Honda Insight and Teslas have great drag coefficients by design - aerodynamic efficiency is absolutely essential to their success.

We currently have batteries that can be charged with 200 miles of range in 15 minutes. Contrary to your earlier assertion, they, along with regular charging stations already makes long distance trips practical. Charging may not be as fast as filling a gasoline tank (~300 miles in ~5 minutes), but that is usable and will improve. Even if you want an 80% charge (40 minutes), or full charge (1hr), planning can make that practical. My Tesla-owning friend plans his long distance trips with meal and rest breaks to allow for charging. Again, it's not currently as practical as gasoline, but it is not "completely impractical". And yes, there are indeed proposals to make long distance EV trips more practical. They mostly boil down to faster charging, higher capacity batteries and more, higher amperage charging stations. Technical and economic hurdles take time to overcome. Remember the 1908 Ford Model T had a maximum range of 200 miles, and there weren't yet many gas stations. That didn't stop Ford selling 15 million of them by 1927. The development of rechargeable battery technologies since the 1980s has been staggering, from NiCd batteries with a 50Wh/Kg energy density in the early '80s, through NiMh (90Wh/Kg) in the '90s (driven mainly by laptop and cellphone adoption), to today's LiPo batteries that are now reaching energy densities in excess of 250Wh/Kg and becoming ubiquitous. The challenge is that Lithium based chemistries are inherently more dangerous than Nickel, and that makes Lithium batteries more difficult to handle and charge. A NiCd battery tolerates extreme charge rates that Lithium batteries will not. We can easily charge a NiCd battery in 5 minutes if the charger can provide the current, but the range would only be 60 miles for a typical car-sized pack.

As a member of the "bike and choo choo" crowd myself, I very much consider the current practical limitations of EVs a bug, and not a feature. That's the reason why I currently still drive a car with an internal combustion engine. The writing is on the wall though as all the major car manufacturers are now investing heavily in EV technologies, and replacing gasoline engines with electric motors in future models. Even the next planned generation of the venerated VW GTI is rumored to be electric, so VW is obviously comfortable with the progress of technology development since the introduction the ID.4 with its frankly abysmal range. The reality is that really long trips by car are already impractical anyway when compared in time costs to aircraft. That used to be even more-so before 9/11 when security lines were speedy. If you're really worried about that extra hour spent charging during an 800 mile drive then maybe you should have flown. In terms of fuel consumption though, it's a mix. An SUV-full of people uses less fuel per passenger-mile than the average aircraft, but any road vehicle with only a driver and no passengers will use more. Thus, it's typically financially cheaper and more environmentally friendly to drive on a long distance family vacation, if you have the time, but the solo business traveler is better off on the aircraft nearly every time.

I too would like to see the 55mph limit raised in many places where it still exists despite the fuel consumption impact of driving faster, but safety implications are relevant. The kinetic energy of a mass is also proportional to its velocity squared, so a car at 70mph has 62% more kinetic energy than one at 55mph. That makes accidents much more dangerous thus more likely to lead to incidents that cause larger traffic delays such as crush, rollover, ejection and death events that leave travel lanes blocked, instead of shunts that end up in the breakdown lane after a minute or two. Higher speeds require exponentially greater braking distances too, increasing the likelihood of accidents during sudden slow-down events. I can't help but feel (without any real statistical evidence) that speed limits are set too conservatively though. In a state where the 90th percentile speed during a traffic survey is supposed to be used to determine the speed limit, I'm often left wondering if that survey was undertaken during a traffic jam, as about 100% of traffic exceeds some of the limits around here. The devil on my shoulder wonders if the police just like letting everyone speed a little, knowing that they then have probable cause to stop anyone...

The 1973 National Maximum Speed Limit Law was expected to save 2.2% of consumption. In reality it only saved an estimated 0.5-1%, partly because many people simply ignored it. That was but a drop in the ocean though when compared to the shortage. Who could have possibly guessed that setting a price ceiling on oil would lead to a reliance on foreign oil from a tinderbox region? In the 3 years prior to the crisis, oil imports increased 52%, such that 83% of the oil used in the US was imported at the beginning of the crisis. Maybe if Nixon hadn't set that ceiling, the price of gasoline would have increased over those 3 years leading to at least some behavioral changes and softening the impact of the crisis. I have to agree with my motorcyclist friends that bemoan that speed limit applying to them. Their consumption has always been minimal compared to the average car.

You've no doubt heard the saying that adding more engineers to a late project just makes it later. I imagine that this must have been similar, but without the benefit of the original engineers who understood the design.

It's actually incredible that the TU-144 got off the ground at all.

Imagine what being on that team must have been like. The senior engineers are pissed off because they're using someone else's design. They are probably trying to influence it at every opportunity they can to satisfy their egos, but since they don't have the understanding of it that the original team had, they're just as likely screwing it up half the time anyway. No-one wants to be the guy that says, "no", and tell the bosses that something can't work, and everyone needs to be seen working hard, yet not be the guy finding problems. They can't admit that anything in the Western designs are better than the USSR would have produced, yet they are expected to use them anyway because everyone knows that much of them are. Yet, the designs were a work in progress - they would have contained deficiencies and errors still to be corrected. The engineers thus have to find, and fix those problems that everyone knows will exist, that no-one understands yet, in a culture where failure is not an option. Success will heap glory on the senior guys, yet failure will likely end junior careers before they've even taken off. Working with brand new high technologies would have been an attractive proposition, but it must have been stressful.

I introduce 'Pause Subscription'.

I haven't yet discovered what it takes to make me un-pause.

I might completely trust the software on my own computer if I'd written it all, never connected it to a network, turned it off and stored it in a grounded Faraday cage buried in 5m of concrete.

It wouldn't be very practical that way though, so I'm stuck to managing trust, like everyone else. The principle of least-privilege is vital.

They used to have a great windows app for configuring their stuff. Then they canned it in favor of their crappy hub, that only had about 20% of the functionality, was slow to use, and needed the internet.

Perhaps Phillips should look at what happened to Insteon's business after that.

What you really care about it its unladen speed though...

Most community access programs were built by cable companies as compensation for the monopoly they ended up with when they got their franchises in citys and towns. I don't know which city/town was the first to negotiate the idea, but the companies were quick to expand it. It was a great deal for them and they knew it.

"Hey, we'll give you a couple of local channels and equipment to fill them, just give us the right to monopolize street poles for the next gazillion years!"

Of course, we are the ones really paying via one of the obscure fees found in cable bills.

That's not a solution either.

Kids are immature. There's a reason why we have (notionally) separate adult and juvenile justice systems. School resource officers don't exist in most countries, and schools manage just fine without having to criminalize children. There are many problems with SRO dragging children off to juvi, amongst them is that it perpetuates systemic racism. Schools in less affluent areas are more likely to have aggressive policing in schools. We see stories of wealthy kids being kicked out of school and sent to rehab for drug use, and those of poor 8 year old kids cuffed and arrested for mouthing off at a teacher.

There needs to be a middle ground. Somewhere where it is safe for kids to make mistakes, and progressive in its application of corrective measures. Somewhere where past mistakes do actually get forgotten when corrections have led to better behavior.

Most children learn good behavior from their parents. A good home learning environment is difficult when Mom works two or three jobs and Dad isn't there. When your parents constantly worry about putting food in your belly and a roof over your head, they have little power to decide the quality of your education.