On Sun, Mar 8, 2015 at 6:16 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
The fact is that what gets 'maintained' is the capability to configure. Yes a default is there in the 'template' when you create a user account. But you can alter that template. The idea of being forced to have a specific panel with specific icons & widgets and not being able to customise is abhorrent. Not even Windows users would put up with that!
Well, they actually do put up with essentially zero customization in their installer. OS X's installer is literally no customization at all. Both Windows and OS X installers are basic point and shoot installers, and as a result have no bugs or support calls.
You would not put up with the idea that all houses/home have to have the same rooms with the same furniture in the same position, would you?
Specious analogy. Rooms and furniture are discoverable things, you don't have to learn how to use them just because they're different sizes and shapes. That's not the case with Linux OS installers doing things differently. Compare the default openSUSE Btrfs install layout to Fedora's? Completely different. It's more different than mobile home vs mansion; it's more like refrigerator vs lawnmower. OK both have motors... hmm.
Away from the desktop things *have* to be confgurable. Apache, Postfix and more.
Sure fine, no complaints. I don't think anyone will argue against having good defaults.
I'd be less concerned about nutty partition layouts or many Btrfs subvolumes, stateless installs were the norm. For example, my cyanogen phone has 28 partitions. This is not by my choice, this is the design of the phone, in fact I have no choice in the matter near as I can tell without likely breaking it. Does 28 GPT partitions sound nutty to me? Yes, quite. Doesn't it negatively impact me? No. If anything it probably helps separate things so they the thing is easy to reset, restore, and update.
I'm not sure there is an analogy here other than the phone is running a version of Linux. Cyanogen is a option you've taken, or it is for most phones; IIR there's only the 1+1 that has it as stock.
The point is, I don't have choice in the layout, but I still had the choice to replace the bloated ATT Android that was on it with Cyanogen. The partition stuff was a non-factor, I didn't even notice that layout until months later and only because I got curious and went looking for it. Ergo, when partitioning, LVM, Btrfs, whatever, just become basic infrastructure, the user doesn't even have to be bothered with such things. But the linux desktop hasn't reached that level of standardization, either among distros, or often even different versions of the same distro, such things get changed and impact the user much more starkly than mobile devices which have done a better job of abstracting such "plumbing" concerns from the user. While there are several attempts, thus far there's no agreement. http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
Very Soon Now, I'd like to see out of tree snapshots taken, and for that tree to be updated atomically, rather than the currently active fs tree. That way if the update blows up, just delete that whole tree. No rollback even necessary. Further, the update can happen in a chroot or container so its update environment is more stable/deterministic; and further my environment isn't the one doing the update or affected by it. So I don't have to reboot to get the offline update. It's an online update, and an optional reboot at my convenience to realize the benefit of that update.
I'd stop and think. Part of the reason the BtrFS people seem to want the whole of the system to be the single BtrFS tree is to do what you're talking about, since there is no other FS. Having the BtrFS deal with snapshotting a mounted ReiserFS or ext4FS leads to all manner of complications.
I think this is a bad example, because why would anyone design something like this? Btrfs can't snapshot other filesystems unless those filesystems are inside a file on Btrfs. That's asking for all sorts of pathological behavior, and hence pointless. There is room for recognizing limitations of Btrfs, for example VM images: either use qcow2 on XFS and qemu-img to snapshot, or use LVM thin volumes and thin snapshots. So these could be boolean extensions on a spec that defines various standardized layouts.
Whether it is on your system is entirely up to you. You too can *choose* for it not to be so.
Choice without knowledge makes choice a coin toss. In order to make a meaningful choice requires knowledge.
I have no argument with statement. Sadly, we succumb to GUIs that try to embed such knowledge and really they are not 'expert systems' so much as the view of the programmer who put it together. Its one reason I prefer to use the command line for so many functions.
Yep, it's a trust problem. Sometimes the GUI will lie for expediency rather than creative convenience, and users end up with completely the wrong understanding of how things work.
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
The interesting this about that thread is that it walks a fine line between FOSS and the kind of formalisms about project management, scope definition and constraints, resource management and formal testing that one might associate with the traditional software development industry such as the old IBM, the old Oracle, the late 1990s Microsoft. No-one actually comes out and says that more formalism is needed, but it's there in the subtext.
There is something of a check and balance in FOSS, compared to the (hopefully) "benevolent" dictator model e.g. Apple, Google, Microsoft, IBM, etc. (i.e. here's our offering, take it or leave it, and all of our developers toe company party line). The distribution is actually limited by resources to what degree it can deviate from myriad upstreams. So getting a cohesive, integrated "OS" rather than a collection of packages, is really hard. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org