The page about upgrading [0] does have this warning:
Back up your data
Performing a release upgrade is never without risk. The upgrade may fail, leaving the system in a non-functioning state. USERS SHOULD BACKUP ALL DATA before attempting a release upgrade. DebianStability contains more information on these steps.
I always find the rough edges on upgrading windows (and macos), I've had several computers that take 3-4 hours to hit a roadblock, give a inscrutable error message and rollback. I feel spoiled using nixos (once you get over the learning curve)
I once tried Spiral Linux, light fork of Sid with bundled Snapper stack. Switched to a giant-userbase distro, Fedora, mostly because Plasma was bad with 5k screens. Are there mainstream distros with easy rollback?
as much as I love Debian (been a faithful user since 25 years or so, no more Windows at home since then), that Windows ability is just really cool and Debian is still not on par I believe...
If you keep your /home on a separate partition, you can basically reinstall a whole system without much efforts. It's good to do that from time to time. etckeeper is very helpful too. Lots of desktop apps are AppImage nowadays, so if you keep them in the home directory, they'll persist.
But you can't do that on a live system as you can with Windows or macOS. Not a problem for pre release upgrade perhaps. But I'm so missing this feature from macOS.
You can if you're using LVM. Take a snapshot of the logical volume your system is on, then run `dd' against the snapshot, as it's essentially a frozen point-in-time.
I've used this trick many times in a live, rw environment.
Depends on your filesystem. For example, I certainly can as I’m using btrfs. I’m also using Timeshift for easy management of snapshots. As others have mentioned, there are other choices too like Snapper that all work well.
Can you not achieve the log history on a subtree with `git log my/subfolder/`? Tools like TortoiseGit let you right click on a folder and view the log of changes to it.
Yes it can, but the point is that in a git repo you store the entire history locally, so whenever you clone a repo, you clone its history on at least one branch.
So when you have a repo that's hundreds of GB in size, the entire history can be massive.
There are also some lovely cut in half shots in Chris Young's YouTube videos (one of the people that worked on Modernist Cuisine). e.g. https://youtu.be/IZY8xbdHfWk?t=239
Why is it always americans who are caught with being seemingly unaware of the rest of the world? Is it because we all speak their language? I didn't ever see it with Britons or Australians.
This is called MVHR (mechanical ventillation with heat recovery) in the UK. We're looking at putting it in, but have a fairly poorly insulated house, so it's not clear if the heat recovery is worthwhile. There is also PIV (positive input ventillation), which blows fresh air into a property (normally the hallways), but does not recover heat, or duct air from the rooms. So it's much simpler and cheaper to buy and install. It relies on the natural 'leakiness' of the property to vent stale air out.
// This is called MVHR (mechanical ventillation with heat recovery) in the UK.
These are actually two subtly different things. ERV (what I am talking about) recovers some of the moisture content along with heat, while an HRV (heat recovery ventilator and probably what you're talking about) does the heat but not the moisture. Depending on where you live this matters or doesn't matter (eg, if your winters are really dry and/or your summers are really humid, you want the ENERGY recovery ventilator to keep the house humidity closer to what you want vs equalizing with the outside.
// We're looking at putting it in, but have a fairly poorly insulated house, so it's not clear if the heat recovery is worthwhile
This doesn't make sense to me at all. First, if your house is "leaky" then why do you need mechanical ventilation at all, versus just relying on the natural air exchange (I can think of a valid reason but just curious how you think about it.) Second, if you DO put it in, your house is obviously better conditioned inside compared to outside so why wouldn't you want to recover that heat, at least for comfort if not economy?
// There is also PIV (positive input ventillation), which blows fresh air into a property (normally the hallways)
Yut but I think your hallway is then going to be as cold as the outside in the winter?
Regarding the new database version issue, I wonder why the caching layer can't just pass any query it is unable to process on to the underlying database?
This would be more complex if the feature you are using does not return a normal table of results back (e.g. the pub/sub support in Postgres).
> I wonder why the caching layer can't just pass any query it is unable to process on to the underlying database?
Because sometimes it's not about the query you pass in - it's about a new data type, for example. The layer may think it understands the query, but may not be able to handle the format of the results, or may cache them incorrectly.
For example, when SQL Server added the JSON data type, one of my customers found that the caching layer mangled it for some clients, but not others, or would return the correct result the first time, but the cached result was formatted incorrectly.
Another problem can be the connection itself, like when SQL Server added support for Always Encrypted, an end-to-end encryption method.
> I wonder why the caching layer can't just pass any query it is unable to process on to the underlying database?
A caching layer can do that, and I'd be surprised if serious ones don't. It might not be perfect when moving between DB versions though: the new version might perhaps introduce syntax that is mistaken for something else which the layer _thinks_ it understands. While this can be tested for to a large extent by the devs having access to alph/beta/rc versions, but I can still see things slipping through and you are relying on people keeping their versions of the caching layer as up-to-date as everything else which is not a given.
That is pretty much what Readyset does. The SQL parser identifies queries that are supported (and cached), and passes through all other requests to the backend database.
As we expand query support, we allow users to cache more and more queries.
reply