.... the parents can legally give them whiskey to make them go to sleep!

There's a bit of a selection bias in the interpretation. Saying things like "44% said they wanted to work from the office daily. Employees? 17%" does not necessarily imply that there's a boss/employee disconnect, it could just as easily mean that those who are more interested in an office environment have self-selected themselves into management. A different title for this story could easily be "People who enjoy office work more likely to be promoted".

In case you need an alternative, minikube is close. I also expect an open source equivalent will show up soon. Anyone know of one?

I'm curious on how thick they can make it, and what the R value would be. If it's a better insulator than glass, you could very rapidly see its applications in green buildings.

Though, let's not use this as an excuse to bring back "glass" blocks ;).

The approach makes some sense when the only client you're shipping to can render HTML. I've found that this is rarely the case.

JSON and YAML based REST API's (i.e. the API-First approach) are successful because the data is not tightly coupled to the presentation, and can be converted easily to whatever runtime is consuming it. The end result is that you don't have to provide different server-side code paths for a CLI, Mobile, Web, or embedded client, and can treat all of them as a "client". To offer up a real modern product surface with both a web experience and other integrations, this approach is a step back to the mid-2000's. Think "Let's build a JSP/Spring hybrid app that renders both JSON and HTML". The add-on feature of "you only ship the delta of the HTML" is just an implementation detail.

Even if you add an intermediary server layer that sits between the JSON api and the browser (i.e. the Backend-only-for-frontend antipattern), all you've done is add more code that you have to maintain. Personally, I like less of that.

What happens if someone relocates from San Francisco to Bangalore? The average software engineer salary there is (payscale) ~600K Rupee, so $8K/year. Moving someone with a $200K+ salary into that economy with no adjustments would be minting a brand new upper class. We know that rich people tend to sit on their money, choosing instead to have it accumulate, so there's an upper bound to the economic benefit of doing this; Is it ethical for Silicon valley to create a high-powered upper class, which they have their hooks in? Seems like colonialism all over to me.

I'm not saying that salary adjustments are ok; I'm saying that the alternative may not be better.

I can't tell if this is satire or not.

Bootcamp has been one of the very few reasons that I've stuck to OSX instead of transitioning to a linux machine; the ability to dual-boot into a moderately-powered windows gaming machine was lovely; but now? Abandoning my Steam library is probably not worth the MacBook premium.

Does anyone else suddenly have a mental image of CMOT Dibbler and his tray of sausages?

"Get your Bitcoin here! Pre-inflated! Onna stick! Free Dogecoin with purchase, and that's cutting my own throat!"

That's ok, he can always invoke the National Defense Authorization Act.

I'm not a doctor, and this is my opinion only, but if the president is your primary, trusted source of scientific information regarding Covid-19, I strongly, VERY strongly, encourage you to take his advice without delay.

A society where things are so convenient that people became shut-ins? Didn't Isaac Asimov have a book about that?

I gotta say, snark aside:
- I can now run browser validation tests in a headless container and hit Edge, Firefox, and Chrome. That's pretty fantastic.
- I can now have a browser that syncs against Office 365's SSO IDP delegation. No more blending work and personal browsing.

That's 42,343 people who are going to watch the movie just so they can complain about it online.

Desktop applications only have to worry about one user, Websites have to worry about all of them. As a result, in the early life of a website (with few users), it's relatively easy to have engineering focus on features, as most available web tech these days can handle that. As your user base grows, however, you start running into scale issues where features you've previously built don't hold up so well. Suddenly, you're putting a good chunk of your engineering effort into updating your existing features for the new # of users required. At the same time, the effort of adding a new feature becomes harder, because you can't just create a new one like before - you have to engineer it to perform at the scale of your current (and future) system, with all the yak-shaving of technical debt which may be involved.

In short: As things get bigger, they get harder.