"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."
Most codebases that ban exceptions do it because they parrot Google.
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.
If my system doesn’t work - I want to be alerted. If notification was supposed to be sent but wasn’t - it’s an error regardless of whether it wasn’t sent because of a bug in my code or external service being down. It may be a warning if I’m still retrying, but if I gave up - it’s an error.
“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.
If you mean that sites with expired certificates may technically be accessible if one jumps through enough hoops and ignores scary warnings - yes, of course you’re right.
Maybe this will just teach everyone to click through SSL warnings the same way they click through GDPR popups - for better or worse.
We wanted TLS everywhere for privacy. What we ended up with is every site needs a constant blessing from some semi-centralized authority to remain accessible. Every site is “dead by default”.
This feels in many respects worse than what we had with plain HTTP, and we can’t even go back now.
I was hoping for easy backup via zfs send as well, but turns out it’s not so easy atm.
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 not to give you shell access. Guess those who want flexibility can always just install Incus on top of any Linux they like, but it would be nice to have an escape hatch for when IncusOS gives you almost everything you want…
The ticketing system might very well be the oldest.
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.
Well, direct democracy already exists in various forms (e.g., referendums, propositions on California ballots, etc.). Sometimes bad decisions are made, but I wouldn’t call it a total disaster. Can it be improved through technical means? How much improvement would it take for it to be better than the status quo?
I wonder if technical complexity of implementing online age checks is about the same as implementing a robust direct democracy system - one where people can vote down bad laws instead of outsourcing those decisions wholesale to politicians they don’t even like?..
We may want to start thinking about smartphones as infrastructure.
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?..
It depends. If your codebase is already free of lint warnings - adding a blocking check to prevent new ones is no big deal. But if your blocking check means that everyone has to drop everything and spend a week fixing code - of course this won't be smooth.
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.
I believe Norton Commander was the original product (for MS DOS), Midnight Commander is its open-source cross-platform clone. FAR Manager is another notable TUI clone of NC.
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.