Some 15.04 annoyances...

I ran into the exact issues you mentioned but somehow there aren't really solutions for the critical ones (most of the thread handles conky config and fs-discussions!?)

1. Kate keyboard shortcuts (Ctrl+A, Ctrl+C etc) not working. I get a message that 'the sequence is ambiguous" and am asked to resolve this in the settings/keyboard shortcuts panel. Even thought the shortcuts are clearly set to 'default' and the only ones, this continues. These shortcuts work in other apps like LibreOffice with no problems.

I have filed a bug report for the Kate keyboard shortcuts issue, and a fix is in the pipeline.

Is there any progress regarding the shortcut issue? I just found a similar issue in Kmail which should be fixed in the meantime but was unable to find yours.
Edit: Or is it this one?

4. Booting and re-login take a long time > 60 seconds sometimes.

I really hate this one. It didn't happen on the same system (with migrated user data) but appeared for a new user. Loging in takes a few minutes!
Were you able to solve this or did you also create a ticket for this one?

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. Any progress on this?

[MoonRise]

Only have one workspace so that would be why I don't have that and didn't notice.

[timgood]

Here is what fixed it for me finally.

own_window_hints undecorated,skip_taskbar

Aaah! But if you don't have 'sticky' it will only appear on your first workspace and not on any others. Have put 'sticky' back. So far so good. Now if only they would fix Kate's keyboard shortcuts. That is still really annoying me. So used to using them it has become automatic, and getting that error message...!

[life0riley]

Yes. Plasma 5 is starting to grow in me as I figure stuff out.

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

[life0riley]

Genius! Thanks.

[MoonRise]

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

[life0riley]

That's all you have in window hints?

[MoonRise]

Here is what fixed it for me finally.

own_window_hints undecorated,skip_taskbar

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

[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

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

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]

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]

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.