On 18/11/18 02:03 PM, Richard Brown wrote:
On Sun, 18 Nov 2018 at 20:53, Carlos E. R. <robin.listas@telefonica.net> wrote:
Then I'm afraid that we must advise people to install the traditional way with a separate /home partition, not a subvolume.
I do not see the sense, at all, to advise users to use a seperate /home partition to facilitate an upgrade approach which we do not recommend, document, consider in our packaging and tooling, nor test (or in other words..support).
Years ago I made the joking observation: "BtrFS - the One File System To Rule Them All", meaning all rives, all partitions ... everything.. So now you are telling us that is not a joke. *EVERYTHING*. You've made it clear, elsewhere, Richard, that for BtrFS even /boot should be part of The One File System. I'm not sure if you would want to make SWAP part of it too, but I can see how that, too, would be logical. (And you could exclude it from snapshots, couldn't you?) Carlos again:
In fact, I always install with a separate "/home" partition in order to be able to do just that: format "/" during fresh install if/when needed leaving "/home" with all my valuable data intact. I almost always upgrade instead, but if the upgrade crashes beyond repair, it is nice to have the alternative.
Some of us are a bit more paranoid about our DATA; some of us might think that even snapshots are inadequate insurance. Some of us put our data on other physical volumes, devices, more aggressive backups, even directly into the cloud. Some of us partition aggressively what is under /home. Or under something else. Developers are often cautioned to snapshot to revision control regularly, aggressively, to make small changes and test them. and RCS/VC at each change. I'm well aware that Snapper can be told to snapshot a folder at aggressive - one minute - intervals, but I think this is a bit wrong-headed and an abuse of the mechanism. Snapshots like that are not the same.
And with snapshots enabled I consider your above to be redundant - if the upgrade goes wrong I can always boot to a read-only snapshot from before the upgrade and rollback that way. In an absolute worse case where absolutely nothing works (which really, would be a tier of breakage I've never seen from openSUSE or SLE, despite my luck at seeing horrific breakages) users still have the option of booting to live media, chroot the disk in question, and rollback that way.
I disagree. Maybe its the way I make backups (or learnt the had way to do so) but the !FAIL!-ures I've had are not 'finger trouble' but catastrophic hardware, usually disk drive, problems. And lets get realistic about this, Richard, disk failure is way, way the most common failure mode in computing (apart from 'finger trouble'). It has always been why we run backups to other media, take them off site. Sorry, all you say about BtrFS just increases my paranoia towards it. It screams to me "Single Point of Failure!" Make that four exclamation marks.
We should optimise our distribution for the tools and workflows we have today and which we actively build, test, and support. We shouldn't have defaults chosen to facilitate inadvisable bad habits left over from a bygone age.
Calling doing regular backups, to other media, off site, "bad habits" is plain insulting. And yes, I know, you consider the IT managers and executives that consider such to be Good, if not "Best" practice to be 'dinosaurs', and due for extinction. You may have the sense not to say that to their faces but there it is' implicit, an emergent property of the stance you are taking in thread.
I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area.
Ah. You trust programmers. I've been one. I've been one for military-grade s/w and had to get past tests and testers like you would not believe, that would reduce people I've interviewed to tears (and have!). I don't trust my own code that made it past those reviews. And the youth, the commercial pressures ... sorry, I don't trust programmers and I think that it is foolish on your part to do so. Do I trust backup software? No, I don't trust backup software either, that's why I verify by doing restores from backup regularly. There's a Schrödinger's Cat law of backups. Until you 'open the box' and do the restore, the backup is in an indeterminate state. That's why I recognise that 'archiving a project' is not the same as a backup, and that's why I think the the backup-by-snapshot is not suitable for a lot of the work I and others do. Archiving, even RCS, is not the same as backups. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org