Some 15.04 annoyances...

[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.

[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?

[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.

[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]

1. Kate: sudo chown -R $user .local/share/kate does the trick. Again, I think editing fstab using sudo rather than kdesudo changed the permissions in that directory.

Yes. Running graphical applications under sudo will often cause such problems.

[ronw]

2. Muon Update Manager - notification icon does not update after updates have been installed. Sits in tray, looking pretty, and saying that updates are available even though they are not. Can only be fixed by logout/login.

Same here, starting a couple of days ago. In addition to not hiding, if it goes red, it stays red even after you update. Sufficiently annoying that I just purged all the notification stuff.

[timgood]

1. Kate: sudo chown -R $user .local/share/kate does the trick. Again, I think editing fstab using sudo rather than kdesudo changed the permissions in that directory.
2. Muon Update Manager - notification icon does not update after updates have been installed. Sits in tray, looking pretty, and saying that updates are available even though they are not. Can only be fixed by logout/login.

[SteveRiley]

anonymous.katesession has the [Recent Files] section way at the bottom, so this is the one to look at.

Good find. I actually didn't look closely enough at that file. The word "anonymous" in the name made me think it wasn't all that relevant, heh.

[claydoh]

Actually, RecentDocuments is for things like krunnner and the kmenu's recents. (and they are not removed when clearing kate's recent docs list), so I am in error there.
Clearing the recents in Kate does not seem to remove anything from metainfos or anonymous.katesession.

Seems to be the same on my fresh install, and my upgraded-since-raring install.


Oops, I forget that these things are not saved back to config files until program exit, silly me!


anonymous.katesession has the [Recent Files] section way at the bottom, so this is the one to look at.

[SteveRiley]

I think they are actually in ~/.local/share/RecentDocuments/, and the metainfos contain file-specific settings. I cleared my recents in Kate, and the .desktop files relating to the recent files in my list were removed from there, but not from metainfos.

Hm. My ~/.local/share/RecentDocuments is empty (*). Each time I open a file in Kate, information about that document is added to metainfos (and also to anonymous.katesession). I wonder if this one of the many under-the-covers changes in Plasma / Frameworks 5?

I was thinking of file or directory permissions problems involving RecentDocuments

I was thinking the same, but for ~/.local/share/kate/.

(*) This is a new install, not an upgrade from 14.10

[claydoh]

That information is stored in ~/.local/share/kate/metainfos. Does that file exist, and does your user account have read/write access to the file?

I think they are actually in ~/.local/share/RecentDocuments/, and the metainfos contain file-specific settings. I cleared my recents in Kate, and the .desktop files relating to the recent files in my list were removed from there, but not from metainfos.

I was thinking of file or directory permissions problems involving RecentDocuments

[SteveRiley]

Another annoyance with Kate: does not show recently used files once Kate has been closed and re-opened. File/Open Recent is greyed out. Always.

That information is stored in ~/.local/share/kate/metainfos. Does that file exist, and does your user account have read/write access to the file?

[timgood]

Another annoyance with Kate: does not show recently used files once Kate has been closed and re-opened. File/Open Recent is greyed out. Always.

[mr_raider]

Ok. Figured it out. The /var/lib/machines subvolume seems critical. Don't touch it! Just rename @, @home and edit fstab to the new names. Then modify all isntances of @ in /boot/grub/grub.cfg

[SteveRiley]

It seems to me btrfs creates added complexity you don't want.

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.