azov

As to computers - it's not like you could walk into a store and buy one, they simply didn't produce them in quantity (central planning economy took a while to recognize that need). But if you could find one, access was not particularly restricted. You could also build a simple home computer yourself if you were into electronics. Schematics were published in hobby magazines and it was a cool thing to do, not something frowned upon by authorities.

"On a Mac with Apple silicon with macOS 26 or later, FileVault can be unlocked over SSH after a restart if Remote Login is turned on and a network connection is available."

https://support.apple.com/guide/security/managing-filevault-...

Google’s reasons for banning exceptions are historical, not technical. Sadly, this decision got enshrined in Google C++ Style Guide. The guide is otherwise pretty decent and is used by a lot of projects, but this particular part is IMO a disservice to the larger C++ ecosystem.

“External service down, not my problem, nothing I can do” is hardly ever the case - e.g. you may need to switch to a backup provider, initiate a support call, or at least try to figure out why it’s down and for how long.

Maybe this will just teach everyone to click through SSL warnings the same way they click through GDPR popups - for better or worse.

This feels in many respects worse than what we had with plain HTTP, and we can’t even go back now.

Was there an explosion of useful features in any software product you use? A jump in quality? Anything tangible an end user can see?..

IncusOS does not give you shell access, you have to figure out IncusOS ways to do things via their CLI/API. I haven’t found an easy way to do incremental backup of the whole system yet. You can backup individual instances/volumes via incus export (which seems to use zfs send under the hood), but not the whole thing.

I have mixed feelings about their decision to not give you shell access. Guess those who want flexibility can always just install Incus on top of any Linux they like…

AFAIK the very first large-scale commercial deployment of what we now call "distributed cloud apps" was SABRE, a ticket reservation system built back in 1960s, still in use today.

Immutable snapshots/offline backups help with those.

It’s not practical to run five sets of power lines to each house so that utility companies can compete in a free market. Thus utility companies are heavily regulated.

But it’s also not practical for each person to carry five smartphones. So, maybe we need to regulate this space as well?..

PS. Also, it’s a good idea to have manual override for whatever autoblocks you set up. Most linters already come with this feature.

For a team not used to code reviews, they might seem more trouble than they're worth at first. Most likely they will be more trouble than they're worth for the first few months. Keep doing them and eventually your smart developers will figure "if we have to do this anyway, we may as well find something useful to say" :)

A few things you can do to make it smoother:

- Manage expectations. Initially it may be as simple as "we just want to have a second pair of eyes on every change" or "be aware what other team members are up to" - i.e. communication first, improving code second.

- Set up your tooling to make the process smooth. If somebody wants to just get it over with - it should be easier for them to use your official review process then to use some side channel. A vicious alternative is to make using side channels harder ;)

- Leverage automation. Run tests, linters, static checkers, etc. on your PRs so that developers get something useful even if no human leaves interesting comments.

- If some team members already have experience with code reviews - adjust their workload so that they can do more reviews. They are effectively training others by example.

- Make sure that code changes under review are reasonably sized. Encourage submitting changes for review early and often. "Here is the feature I worked on for 3 months, and it's due on Friday, please review" won't make anybody happy.

- Make it less intimidating. Code reviews are not just for finding bugs and flaws, encourage reviewers to say positive things as well.

They are totally doing it by the book [1]

[1] https://en.wikipedia.org/wiki/How_to_Lie_with_Statistics

Windows Commander/Total Commander are also NC clones, but implemented as GUI instead of TUI.

NC was one of the most convenient UIs for managing files, it’s a pity none of the major operating systems adopted this style for their default file managers.

This is absurd. Why would anyone give you $120K if you’re saying right there you’ll be happy to accept $100K?

The first time this happens the programmer will spend hours looking for the first few places that need to be changed. Then he will spend days debugging, and hopefully will find the last few places.

Then, even though he is now informed about the connections, he will NOT refactor this code because he (a) has no time to refactor as he already spent a week on what seemed like a one-line fix, and (b) is now terrified to touch this code any more than absolutely necessary.

Then the cycle will repeat.

It's interesting to reflect on this 20 years later. Can we say that FogCreek won?..

> How do I enforce my rights in case of a flight problem? To enforce your claims, it is advisable to seek professional assistance.

This makes me reluctant to trust them or their advice.

I'd expect an honest answer to be "you can totally do it yourself, but we will help you for X% commission".

When I filled out compensation form they first lied to me about who operated the flight: it's not us, it's our codeshare! Once we sorted it out they lied about the distance: your disrupted journey was less than 1,500km, so here is less then half of your compensation (for a flight from London to San Francisco). I eventually got my full compensation, but it took several months of back and forth.

Airlines will absolutely lie to you, in writing, about the things that are trivial to verify. I guess there's no downside to them - in the best case some people may settle for no or smaller compensation, in the worst case they pay what they were supposed to pay anyway.