Phased rollouts, people. It seems we have to learn this lesson over and over again. In any large enough deployment that gets enough updates, the day will come that someone pushes an update that causes widespread breakage. Phased rollouts give you a chance to notice things are going wrong and stop before every system has been affected.

> If cloud service providers are the only ones who can get security right

I don't understand. First of all, it seems to me that if you're using cloud services, you have already taken some steps away from security. For one thing, you have your service and/or data on a system that is accessible remotely...over the public Internet. For another, the service/data is on machines controlled by some other organization. I'm not saying this isn't acceptable ever, but I am saying that this isn't obviously getting security right.

But maybe it's not really "getting security right", but only "getting zero trust right". That leads me to my second point: If the cloud providers can do it, why couldn't it be done by others?

The article makes the point that it's all very complex and everything needs to be tracked and authenticated. I'm sure this isn't already universally done, but is it really that hard? Every organization I've ever worked at already authenticated users. Only authenticated users have access to most resources. Source code, documentation, and, in many cases, configuration parameters can only be altered by authenticated users, and a log is kept of what was changed when and by whom. A lot of what I understand the article to be asking for seems to already be in place.

Then we get to:

> The hardware stack is controlled by the cloud service providers. For the most part the CSPs build their own hardware and theyâ(TM)ve even been building their own CPUs. They build their own network devices, NVMe SSDs and motherboards.

I don't think this is quite true. As far as I know, cloud providers generally use commercially available CPUs (with some widely publicized security vulnerabilities, no less) and use commercially available SSDs.

> There is a single software stack that they control and, for the most part, they write themselves

I would be shocked if this were true. As far as I know, these software stacks are largely built from open source software (hi, Linux!). To the extent that the stack is open source, nothing prevents a not-cloud-provider from using the very same software. To the extent that the stack is not open source, I'm not sure that should inspire more confidence in its security. Besides, "software stack that they control" sounds nice, but I guarantee you that the software stack is too complex for anyone to really vouch for its security.

> They do not have to have network monitoring, multi-factor monitoring, OS monitoring, etc.

I am not sure why the author thinks this is true.

All in all, I understand the idea that not every organization has the budget and competence to make sure everything they do is subject to all the authentication, audits, updates, monitoring, and logging you might wish for. But the problem with using a cloud service provider to handle this for you is that they really can't; you need to access the cloud somehow, which means you will have some hardware that runs software, and users that need to be authenticated, have their authorization revoked when appropriate, etc. At best, you can outsource part of it all to the cloud service provider...but it does require that you trust the cloud service provider to do their part of the job. At that point, is it really zero trust anymore?

> it's probably just easier and more trouble free to buy a Windows machine

That's what I thought, too. I was ready to buy Windows for my new gaming PC...and then I started reading about Microsoft refusing to let Windows install on computers that are otherwise perfectly capable of running it, Windows sending data to several different companies, and ads in the OS. I haven't managed to convince myself that this is something I want to pay for.

This has basically been killed by poor computer security.

Running any software yourself means you have the not inconsiderable burden of keeping up with security updates (or not, but that has its own cost).

Email is insecure at the protocol level and has been completely overrun by spam (in part because of the poor security). Over time, we have accumulated a variety of kludges to help improve email security a bit, but they mostly just add more complexity, while the insecure underpinnings are left in place.

The result is that running your own email server, you have to keep the software up to date, you have to somehow filter out the single-digit percentage of real email from the deluge of spam. You also have to jump through all the hoops to implement the variety of security kludges that have been built around email, or else various large providers will not accept your emails. Even when you do everything right, some email will still be blocked, or even go missing without anybody being able to tell you what happened to it.

There was a time when I ran my own mail server and I even wrote one of the early Bayesian spam filters. No more. The effort just isn't worth it on such a small scale. These days, I pay a company to take care of it for me. I've been a happy customer for more years than I can remember.

> > How do you figure? The difference between 40 hours and 37-38 hours is only about 6%.

> They are going from 48 hours to 40 hours. The difference between 48 hours and 37-38 hours is basically one full workday.

Ah, your mention of 37-38 hours made me think you were talking about England having that vs. 40 hours, but I understand now you were making an argument about going from 48 down to 37-38. That's indeed a much bigger step, although the caveat that this doesn't necessarily imply a proportional loss in productivity still applies.

I understand the point you are making about "if we use more, someone else must make do with less" when it comes to CO2 emissions. We've agreed (Paris Agreement) to limit global warming and this puts a cap on net CO2 emissions. Because there is a maximum, it's a zero-sum game; if someone has more, others must have less.

Standard of living vs. hours worked doesn't work that way. Without spending too many words on it, we have plenty of room to boost productivity per hour worked by putting in more electricity, mechanization, and computerization - just to name a few examples of how economic output can be quite independent from hours worked. Because it's really about value generated and not about hours put in, even keeping standard of living constant doesn't mean that a shorter work week in one country implies that people in other countries must work longer.

It's also worth noting that standardizing on 8 hours per day dates back to the 1920s or earlier for many countries, with some industries doing it in the 1800s. This is well into the times when these countries had low wages, lax labor laws, and lax environmental laws.

One famous example is Henry Ford reducing work hours to 5 days, 40 hours a week in 1926. This actually *increased* productivity, and other automobile makers ended up following the example. Given the less than ideal treatment of workers and the environment that has persisted till well after that time, I would argue that this certainly falls within an era when the USA was a country with lax labor and environmental laws. And Ford automobiles at the time were very much manufactured in the US; no reliance on cheap foreign labor.

As pointed out in my previous reply, the difference between 37-38 hours and 40 hours isn't that much - if this worked for 40 hours, I would be very surprised if it didn't work for 38 hours.

> Well, countries like ours, where we can live well with 37-38 hours of work per week, can only get by because we rely on [cheap labor, lax social laws, and/or lax environmental regulations]

How do you figure? The difference between 40 hours and 37-38 hours is only about 6%. Even if we assume a proportional drop in productivity (which likely underestimate the productivity of a 37-38 hour work week), that's maybe 2-3 years of average economic growth. That's hardly going to make the difference between needing or not needing to rely on other countries for cheap labor/imports.

I really don't understand why seemingly all companies suddenly feel the need to roll out some half-baked generative AI feature in apps that people are already perfectly happy to use. Sure, it's cool technology and it has its uses. But after so many companies hopping on the bandwagon and coming up with something that is embarrassingly poorly received...why the rush to be the next one?

> Microsoft is Now Injecting Full-Size Edge Ads on Chrome Website

That's...quite evil. It makes me wonder why they care so much. They don't make any money selling Edge (right?). As far as I know, Edge isn't different enough from Chromium that it leads to some IE6-style lock-in. Yet they're mangling websites to insert ads that weren't there before, promoting...their own closed source shell around Chromium? If it's really that valuable to them, I worry about what's in there or what their plan is for the future. "Added trust of Microsoft" indeed.

Ruby is still there, getting updates, getting better. But there are a ton of programming languages out there, and Ruby just hasn't become as widely used as others. It's close enough to Python that going for both is extra effort to little benefit, and between the two, many organizations and most of the world seems to have settled on Python. For a while, it looked like Ruby had found a niche of its own with Rails, and to this day people generally associate the two, but people have moved on from Rails, and Ruby is back to relative obscurity. Shame, because I actually really like Ruby.

> So, the question becomes, do Rusts guardrails offer protection that you don't already get from unit tests run under a runtime sanitizer?

The answer to that is "yes". Running tests under a sanitizer will only find problems you actually exercise in your tests. By contrast, memory safety in the language means those problems don't exist, also in scenarios you haven't tested.

I went and read some of what Bjarne wrote, because I was curious. My verdict? A lot of words that don't add up to a solution.

The main theme can be summed up as "C++ is unfairly characterized as memory-unsafe, and besides, there are other safety properties we should care about."

He is, of course, right about the last part. But that doesn't negate the fact that lack of memory safety continues to be a huge source of real problems in real software.

As for the first part, I took a look at some of the work he references that he claims make C++ actually memory-safe. In short summary, the idea is a set of rules, mentioned in Type-and-resource safety in modern C++:

  1. every object is accessed according to the type with which it was defined
  2. every object is properly constructed and destroyed
  3. every pointer either points to a valid object or is the nullptr
  4. every reference through a pointer is not through the nullptr
  5. every access through a subscripted pointer is in-range

Then there are a host of programming rules (e.g. "don't use casts") and proposed static and run-type checks that, when implemented and used, would help enforce those rules.

Some static checks are claimed to exist, others remain to be implemented. Some checks, Bjarne claims, will have to be made at run-time (such as checking that a pointer being dereferenced is not nullptr). And a lot is left to "style rules".

Don't get me wrong, a lot of the recommendations Bjarne makes are good. But I was hoping it would add up to being able to statically verify the memory safety of C++ to the same level you can with Rust, and it does not. It's more like "If you follow these rules that preclude much of the language[1], it can be safe, although we can't prove it at compile time." [1] Convincing everyone in your organization that this is a good idea, and then rigorously enforcing it without any mistakes is left as an exercise to the reader.

Oh, and "Not everyone prioritizes 'safety' above all else.".

Which is, of course, why the NSA made its recommendation. We have had memory-safe programming languages for longer than we've had C++, but we continue to "prioritize" in a way that allows attackers to take over our computers, extract our data, etc. After decades of this, the NSA has said "Enough of this, we're going to put out an official recommendation and call out some problematic and better languages by name". Bjarne is saying "Now, now, let's not be hasty, C++ is perfectly safe if you carefully avoid all the pitfalls." Which we have tried to do for the last 20 years or so, and it has not been working. This recommendation isn't being hasty; if anything, it's quite long overdue.

> You're kidding, I hope? If kids don't know more than their parents about that newfangled cell-phone stuff, all is lost!

Many people who built much of the Web, the large tech companies, and many a smartphone app are parents now. The "parents are clueless about computers" idea is past its prime.

I expect this will end programming to about the same extent compilers have. There will be a whole range of things we programmers currently spend time on that we will spend considerably less time on, and we will spend that time on other things. And some people will still have to develop the software that makes this possible. We are not toggling switches on front panels anymore, and most of us are not hand-optimizing our machine code anymore, but previous leaps in computer programming have hardly put programmers out of work, and I doubt this one will, either.

Mostly Emacs org-mode. I use it mostly as plain text, but it's super powerful, so it can scale out from there. Markup, easy to use tables, hyperlinks, to-do lists, embedded code, you name it. It can even do things with calendars, though I have never used that functionality.

When I'm on the go, or expect to be on the go, or need to share with others, I use Google Keep on my phone. Much less featureful, but it has the all-important checkboxes that make it convenient for to-do list, shopping lists, and the like. I'm actually a big fan; it's simple and useful.

I'm not sure how well these will fit OP's use cases, but the question was what we use, and this is it for me. I've been using both for years and I'm happy.