Some 15.04 annoyances...

[xennex81]

Recycling electrons: https://www.kubuntuforums.net/showthread.php?68088

Btrfs has oodles of advantages over other file systems. Note particularly Oshun's examples in his post #24 in that thread.

The problem is that it puts certain features in the wrong place. Most of these things are not meant for the filesystem to do.

You can see it because now to do these things, you are suddenly dependent on learning that specific filesystem's way of doing it. It is no longer a component that stands loose, that is separate from the filesystem layer. So it's like Microsoft selling windows with Explorer (Internet Explorer). You can't (couldn't get) explorer without Windows, and you can get Windows without Explorer. Not sure how to frame it.

You lose differentation into layers and the independence that results from it. Now suddenly in order to do backups you must do BTRFS. And how compatible is it going to be if some deviate form of that surfaces? You are putting all kinds of features into that FS and tying it to that FS. And you lack or lose the freedom to go elsewhere.

Rollback:
Auto-snapshot prior to package install/update.
Delete auto-snapshots at a configurable number or age.
Restore the rollback snapshot when requested.

Backup:
Incremental auto-backup at a configurable interval.
Restore backup on request.

The fun thing I'm playing with lately is the send/receive feature. You can send a subvolume to a different device or to a file for backup purposes.

Only the latter seems to be somewhat a part of what a filesystem could do. But now the filesystem is also taking the role of the volume manager.

I don't fancy this ****. You are going the wrong way. Added complexity, added dependence, trying to solve a problem in a place where it shouldn't be solved. Etc. Perhaps this is meant as one of those "let's agree to disagree" instances ;-).

[SteveRiley]

You can see it because now to do these things, you are suddenly dependent on learning that specific filesystem's way of doing it. It is no longer a component that stands loose, that is separate from the filesystem layer.

In the abstract, this could be the basis for a sound argument. In practicality, it isn't.

Let's consider snapshots. While there are many techniques for taking snapshots of file systems, having the mechanism integrated into the filesystem itself makes the most sense. Btrfs's snapshot implementation needs to concern itself only with the internals of Btrfs formats and state machine. The code is likely to be much cleaner in this case and safer, too. Snapshot functionality is pretty basic; there's no need to have a "full featured" third party snapshot utility.

You lose differentation into layers and the independence that results from it. Now suddenly in order to do backups you must do BTRFS. And how compatible is it going to be if some deviate form of that surfaces?

You write as if Btrfs removes choice, which is absolutely not the truth. You can use whatever backup tool you wish -- such tools are almost always agnostic of the filesystem. The developers of Btrfs have chosen to incorporate some features that simplify backups; these features take advantage of capabilities offered by COW and snapshots. You can snapshot a filesystem and then btrfs-send it, via a variety of protocols, to some other location.

Now think about what happens when it's time to restore. Again, if you used some other backup utility, you'd have to use that utility's restore function. It's not like there's any independence here. I bet, though, that btrfs-receive will be a whole lot smoother of an operation.

"some deviate form" sounds like FUD. There will be no deviate Btrfs data formats -- the disk format is now stable.

You are putting all kinds of features into that FS and tying it to that FS. And you lack or lose the freedom to go elsewhere.

Your second sentence is false -- Btrfs does not rob you of choices. Your first sentence reads like a complaint. A lot of people want these features.

Only the latter seems to be somewhat a part of what a filesystem could do. But now the filesystem is also taking the role of the volume manager.

To which I, and thousands of others, say bring it on! Volume managers are complex, unwieldy, and brittle. In many ways, they're a lot like GRUB. Trying to do too much. Volume managers exist because filesystems have been stuck with partitions, disk geometry, and other crufty legacy crap mostly related to hardware limitations. Now comes Btrfs, with entirely new visions for what a filesystem can do. It cares not about any of the old limitations. Placing a filesystem directly on the disk without arbitrary partition boundaries is super cool. Taking a snapshot and having a fully atomic, static representation of a currently-mounted filesystem is super cool.

systemd, UEFI, GPT, and now Btrfs will greatly simplify the day-to-day tasks of managing racks of Linux boxen. Yes, there is a learning curve. But that's no reason to plant one's self firmly in the past.

[markslaw]

Glad to see that I'm not the only one having Plasma crash and burn on them. BTW, besides reinstalling the o/s when the black screen appears, what is the solution? Maybe Plasma wasn't such a great idea to start with. Kind of seems like the folks who write Kubuntu have Redmond Fever, a case of Microenvy, maybe?

[xennex81]

@SteveRiley:

These are all non-following logical sentences. They call it "non-sequitor".

Just because BTRFS adds choice doesn't mean it doesn't take away choice.

Once you choose BTRFS you lose the ability to go elsewhere. It is called vendor-lock in. In another realm perhaps. Your argument has been leveled against all the criticism of the Apple ecosystem. Apple doesn't take away choice. No, but it does, unless you stay far away from it.

The fact is that as soon as you start choosing BTFRS kinda solutions, it soon remains as the only choice. All the alternatives go away. You say so yourself. The BTRFS solution might be a lot smoother. Soon there will be tools that only work with BTRFS. The whole idea of containment goes out the door. It is just like GIT. I hate GIT. Git works by having no containment, only a database of additions or changes or modifications. There is no real container for anything like a data directory, or a working directory. These are all volatile, transient, short-lived. You cannot store anything anywhere safely because the wrong command will wipe everything. I don't even consider my own Github a safe place because I can destroy it with a single command and I might not know it in advance. It is not simple, not elegant. I haven't used Subversion but I'd rather stick to that, I'm pretty sure. So Github is barely a backup solution because you can wipe (inadvertedly) the entire history with one command. You have to keep local backups, but the whole idea of an online repository is backups in the first place. So it is no-go, it doesn't match with the intentions that a user brings to that system.

I often want to put aside in a different directory (tree) something in Git. It can't be done, because as soon as I checkout something, the old dir is gone. That's how often it is rewritten, so I don't have a new (extra) directory, no, the main directory is gone and replaced by something else. It is not trustworthy. At least not to me and I believe to many.

From what I now see, BTRFS is much of the same. It creates a certain kind of complexity that does away with regular, easy, fixed, level containment. It throws all of that containment or fixed levels of containment out the door? But we soon loose sight of what's where. I like my stuff to be inside my house, not floating somewhere between the walls of my house and my non-house, present when I call the right agent or admit the right command. I want it to be there non-sequitor, regardless, without having to do anything. I want it to be trustworthy. Not fancy ****. I have to go, I could write more, later probably, perhaps.

[SteveRiley]

Once you choose BTRFS you lose the ability to go elsewhere. It is called vendor-lock in.

The fact is that as soon as you start choosing BTFRS kinda solutions, it soon remains as the only choice. All the alternatives go away. You say so yourself. The BTRFS solution might be a lot smoother. Soon there will be tools that only work with BTRFS. The whole idea of containment goes out the door.

This is a ridiculous argument. Assigning "vendor lock-in" to a fully open disk format is surely twisting the definition of "lock-in."

Btrfs does not have the goal of replacing anyone's preferred tools. It's just providing alternatives. You could have a perfectly functioning system with EXT4 everywhere, running your favorite volume management, snapshotting, and backup tools. You could then rip and replace the EXT4 filesystems with Btrfs and the tools would still function as they always have.

I highly doubt that significant "Btrfs-only" tools will emerge. Different people prefer different filesystems for different uses. It's in the interest of third-party developers to support as many filesystems as possible. However, if someone does decide to write their tools only for Btrfs, that's their choice. You can still look elsewhere.

[xennex81]

It still doesn't follow what you say. If the replacement by or with BTRFS didn't create added specialized or uniquely available features, there would be no point to using it. The whole idea of (and what we've seen, that it is true) filesystem-integrated (and you went as far as saying that it replaces partitioning altogether) is that it provides features on the filesystem level that then do not have to be replicated on the application level.

Since these features are available, they will get used. Given enough traction, it means that solution providers start designing around and for this filesystem or this feature set.

Soon you'll have what you have in the iOS ecosystem. eBooks with special features only available on the iPad. This means premium content is only available on one platform.

And all of this arises, in the case of BTRFS, because of a mixup in functionality in between layers. Functionality is placed in the wrong layer (too deeply) and the result is that the functionality will disappear from the higher layers (where they are meant to be, as a way to be filesystem-agnostic). You said before that deviate forms will never arise, but at the same time you are describing it as the next evolution. This means you hold no other filesystem as a viable alternative (because it would be a step back) which means you expect tools to also evolve toward BTRFS.

So, your statements are logically inconcise. You speak against yourself. You expect EXT4 to be evolved out.To be 'deselected'. In evolutionary selection. Maybe you are right, but then clearly BTRFS can't be the 'last evolution' which means next evolutionary steps will arise.

And so on. Can't speak now. This shop closes.

"You can still look elsewhere" is a statement that might prove to be false.

[SteveRiley]

So, your statements are logically inconcise. You speak against yourself. You expect EXT4 to be evolved out.To be 'deselected'. In evolutionary selection. Maybe you are right, but then clearly BTRFS can't be the 'last evolution' which means next evolutionary steps will arise.

Wow... you're really reading an agenda into my posts here. Btrfs is not a universal replacement for all filesystems; in fact, like other COW filesystems, it's likely to be a poor choice for database and virtual machine storage (to name just two use cases). I never explicitly claimed an expectation for EXT4 (or other filesystems) to "be evolved out." Why are you trying to provoke an argument when there is no reason to have one?

You said before that deviate forms will never arise, but at the same time you are describing it as the next evolution. This means you hold no other filesystem as a viable alternative (because it would be a step back) which means you expect tools to also evolve toward BTRFS.

No. I said that the on-disk format is stable and no more changes will be made to that. This statement is directly from the Btrfs wiki.

It still doesn't follow what you say. If the replacement by or with BTRFS didn't create added specialized or uniquely available features, there would be no point to using it. The whole idea of (and what we've seen, that it is true) filesystem-integrated (and you went as far as saying that it replaces partitioning altogether) is that it provides features on the filesystem level that then do not have to be replicated on the application level.

Btrfs is the result of the desire to design a new filesystem that's unencumbered by limitations of the past. I'm not going to repeat its advantages here -- they're documented in many places. No one is forcing you to use Btrfs and I'm not aware of any evil plans to thwart the desires of those who wish to use something else.

[xennex81]

You yourself wrote:

Volume managers exist because filesystems have been stuck with partitions, disk geometry, and other crufty legacy crap mostly related to hardware limitations. Now comes Btrfs, with entirely new visions for what a filesystem can do. It cares not about any of the old limitations. Placing a filesystem directly on the disk without arbitrary partition boundaries is super cool. Taking a snapshot and having a fully atomic, static representation of a currently-mounted filesystem is super cool.

This seems to mean that BTRFS is meant or can replace partitioning. I suppose, since it is a filesystem, it can exist within a regular partition. But here we go immediately: we speak of partitions. Suppose partitioning is gone. WHAT THEN? Perhaps you didn't imply this.

The whole idea of partitioning (or logical volume managers) is for the partitions to be filesystem agnostic (to a reasonable degree, at least). You simply cannot mix filesystem and partition, we will always need partitions or you can't have "deviating" filesystems contained in any one of them, since they have to exist first before they can contain anything. So what you get is a filesystem that does the same as the LVM/partitioning already does. It creates or contains an LVM within itself? I've read a bit of the snapshotting and COW capability. It seems these 'subvolumes' are what you refer to as separate ..well, supposing you were referring to separate things that can be called partitions within the BTRFS 'partition'. It seems like they are slices. Their organisation may not be physical, in the sense that files are just arbitrarily located and a snapshot also exists as a logical set of files that already existed but have not yet been modified, or modified entities of those same files. A snapshot is a view and the view can create new 'atomic' copies of existing files. So as to maintain the view.

So what you get is an organisation that is 'in the air'. The slicing or splitting or partmentalisation exists logically on disk (through some data structure) but not in any sense physically (speaking of physical on-disk boundaries). Personally I greatly prefer physical boundaries that make sense to me.

But it is perfectly clear that you can't have different partitions containing different filesystems if this filesystem is being placed 'directly on disk' without arbitrary partition boundaries, as you wrote. What this means is that the BTRFS using its cloning or subvolume capability takes the place of the LVM or the partition table. Subvolumes are like subdirectories which has its advantage (although there is no reason an EXT3 filesystem can't have the same) and logically they seem to be different entities although it is drifty.

Of course, in a regular filesystem there is also no physical separation between directories, it is just that (in the sense that they have always used particularly random inodes and blocks etc.) directories or trees have in the physical representation always "shown up" as separate entities. In the sense that the user model of these things has been very concise and current. It was a fixed representation that you could depend on. Same with partitions. The LVM of Linux goes away a bit with this sentiment because it can create subvolumes that "wrap" around other subvolumes (it doesn't need to be contigious). I don't like that, because it starts to warp your mind.

And of course volume boundaries have always been troublesome because they imply space limitations and distributions that are rather fixed. But the only solution is to create a logical mapping of files across the space and do away with those physical boundaries. Apparently BTRFS can also add other block devices to its set, which means apparently (probably, to me) that it can add other separate partitions. The way an LVM can. This still means the filesystem is taking much of the place of the partitioning and voluming.

And of course you can say that this added features of the internal filesystem is no threat or by no means a threat or charge against the existing schemes. And perhaps you are right, if the BTRFS is indeed so contained to use cases such as you describe: professional, high level goals for complex systems doing "real world" tasks in the sense of database servers and other stuff that runs under high load.

And my argument falls on deaf ears if you think those things are good ideas ;-).

Haha. I'm saying Cloud, Git, etc. other stuff, it is too advanced for me, I cannot grasp it with my mind anymore. In the other topic we spoke about Cloud and how I don't want that. It's the same with this: I can't deal with this stuff and I have good reasons to as well.

systemd, UEFI, GPT, and now Btrfs will greatly simplify the day-to-day tasks of managing racks of Linux boxen. Yes, there is a learning curve. But that's no reason to plant one's self firmly in the past.

Perhaps the learning curve is in itself a bad idea. Perhaps being forced to learn it (because circumstances mandate you should) is what I vow against. Perhaps I am trying to defend my position and my sanctihood here. Perhaps I am not capable of going that road, but I see it before me that I will be forced to do these kind of things and I don't want to. It is a threat I see. You can speak lowly of the threat but you belittle the learning curve, as you put it, as well.

I am just defending my case. I am not attacking you. I experience a system attacking me. I can see where it goes, where it's leading. You think it is a good point to go, I think it is a bad point. Because I can't go there anyway or end up in world of hurt, which is going to happen anyway I believe If I see it Going that Way Now. There are more things in my life that are going that way, that Bad Way.

Take WordPress for instance. Bad omen. WordPress is going down the road of fastly introducing very many more features that all seem like a bad idea. I don't even want to go there but I have to for my work. Or it seems that way.

I am not belittling you, but I am belittling the case you make. I DO see a road with fewer options. I don't know why I am going there. I believe that I should not have to, but it is the same with Apple OS, Like I have Said. It is all about ecosystems. It is not about "vendor" lock-in in the sense of BTRFS being some enclosed vendor, but the toolset might migrate towards it and consumer and professional data-loads might advance there and I will be forced to work with it, perhaps, And I don't want to.

I consider it a real bad idea. We'll have to just disagree for now (because this is also not a place to hold this discussion for longer).

[SteveRiley]

Because I can't go there anyway or end up in world of hurt, which is going to happen anyway I believe If I see it Going that Way Now. There are more things in my life that are going that way, that Bad Way.

In free software, as in many other aspects of life, the only constant is change. If we wish to avail ourselves of the incredible work of the developers of free software, then we must accept the directions they wish to go.

(because this is also not a place to hold this discussion for longer).

Sure it is. Very few topics are truly prohibited at KFN

[life0riley]

Funny, I have full transparency and no disappearing. My window settings within conky are:

[FONT=Ubuntu Mono]# Window specifications #[/FONT]
own_window_class Conky
own_window yes
own_window_type conky
own_window_type override
own_window_transparent yes
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
own_window_argb_visual yes

No black background on any wallpaper.

timgood, try these settings for conky.

own_window_class Conky [COLOR="#FF0000"]<--I don't use this.[/COLOR]
own_window yes
own_window_type normal
[COLOR="#FF0000"]#[/COLOR]own_window_type override [COLOR="#FF0000"]<--Don't use this.[/COLOR]
own_window_transparent yes
own_window_hints undecorated,[COLOR="#FF0000"]above[/COLOR],sticky,skip_taskbar,skip_pager
own_window_argb_visual yes

Changing below to above in own_window_hints stopped conky from randomly disappearing. The downside is conky will appear on top of everything.

This is from the conky documentation for configuration settings.
http://conky.sourceforge.net/config_settings.html

own_window_class
Manually set the WM_CLASS name. Defaults to "Conky".

own_window_type
if own_window is yes, you may specify type normal, desktop, dock, panel or override (default: normal). Desktop windows are special windows that have no window decorations; are always visible on your desktop; do not appear in your pager or taskbar; and are sticky across all workspaces. Panel windows reserve space along a desktop edge, just like panels and taskbars, preventing maximized windows from overlapping them. The edge is chosen based on the alignment option. Override windows are not under the control of the window manager. Hints are ignored. This type of window can be useful for certain situations.

own_window_hints (undecorated,below,above,sticky,skip_taskbar,skip_ pager)
If own_window is yes, you may use these window manager hints to affect the way Conky displays. Notes: Use own_window_type desktop as another way to implement many of these hints implicitly. If you use own_window_type override, window manager hints have no meaning and are ignored.

[MoonRise]

Here is what fixed it for me finally.

own_window_hints undecorated,skip_taskbar

[life0riley]

That's all you have in window hints?

[MoonRise]

Yes. So far so good and it stays behind other windows.

[life0riley]

Genius! Thanks.

[MoonRise]

Trial and error!


Now, as far as Plasma 5, I happy now. I do miss Luna and YAWP and hope they get ported over soon. Otherwise, nice. Looking at ppa:kubuntu-ppa/backports now to update Plasma5 to the latest here.