Future of Cinnamon in Debian
preining.info
preining.info
Cinnamon on top of Ubuntu has been my absolute go-to for the past 10+ years for a very long list of reasons.
Having to switch to the OSX botched look-alike abomination that currently ships with Ubuntu (unity or something) would force me to walk away from Ubuntu altogether to switch to a distro that supports Cinnamon natively.
I truly hope someone technical enough will pick up the torch.
But as I'm getting older, and after being forced to use (begrudgingly, at first) alternative desktop metaphors at work, I've noticed that it does not really matter as much (to me) as I always thought.
Sure, there are things that you've learned to love and now think you cannot live without. And there are features that other approaches had that I though were completely pointless and a step backwards rather than forwards. Or at least just useless.
But now, I think it's all not so bad, actually. I'm writing this on Ubuntu 18.04, and I remember how much I used to despise the vertical icon bar on the left, that shows both currently running apps and also allows you to start often used programs with a single click. Now I just don't see it anymore. Except when I need to use it, and then I suddenly don't see anything wrong with it, anymore.
Mind you, I still have a list of must-have features for desktops. For instance, having virtual desktops that I can quickly change between using keyboard shortcuts. But my list of "must haves" has definitely changed over time (maybe even gotten smaller) -- which shows that the word "must" was apparently never right in the first place.
https://www.linuxmint.com/download_lmde.php
Still though, I have to imagine there is a lot of work / knowledge required to maintain Cinnamon on Debian proper.
Additionally, the old type-ahead complete was removed from filename-entry. Arch at least has a patch set to put this back, but the location-mode thing is resistant to fixing. I changed the default initialization with a simple patch to gtkfilechooserwidget.c but it only works for the first time I File->Open in a gtk3 application. The second reverts back to pathbar.
Interesting thing is that you can use the same philosophy in everyday life.
I made the switch when gnome 3 happened and have never looked back.
It’s themeable enough for me - xubuntu usually looks pretty good, you can get the themes on Debian easily enough.
It’s featureful enough, while still being relatively lightweight.
But the best thing about it? It’s not opinionated. You can decide what goes on your bars/panels, where they go at what size etc.
That's an investment you have to make if you want it to look like you want to. Maybe you just want to have a DE that works for you without tweaking it, which I understand. But I'm pretty sure you could make a GNOME desktop you like given the time.
Having tested multiple desktop environment and window managers, it's pretty great having such a diverse pool of choices : you can really ditch GNOME completely if you don't like it.
[0] : https://github.com/home-sweet-gnome/dash-to-panel#features
[1] : https://i.imgur.com/NRegvAo.png (The orange on the left is me failing to crop my left monitor correctly)
If I'm about to spend time customizing my DE to match my preferences and habits, I'd much rather spend the time on something that is made to be customizable.
The one part you can't replace is the shell, but you can pretty much configure every aspect of that using extensions. If you don't like the way the shell operates on a fundamental level, then you would probably be better served by using a different desktop.
This feels like ordering paella at a restaurant when I don't like seafood. Sure, I can eat around all the sea bits. But there's lots of other options at this restaurant, so why the f* would I order paella, knowing it has seafood I don't like?
I'm not gonna tell you not to order the paella, or that the paella is bad, or that the restaurant is bad, or whatever. But don't push the paella on me either please ;)
Edit: If the issue is that some extensions break and become unmaintained sometimes, that's unfortunate, but the only other solution there would actually be to put heavy limits on the extension API. Which would probably not be to your liking either because it would actually reduce customizability.
The problem is not that the extension API is too wide in scope, it's that you need to use an extension API at all to change even simple things.
> the extensions are configurability
And this is an inadequate mechanism.
(For me! If it works for you, that's great! Me, I like to be able to configure bars and widgets and menus and stuff wherever I want with a few clicks, which is why I run Xfce. Far be it from me to say there should only be one true desktop)
Edit: Somebody could probably make an extension to make the shell look and act like XFCE if that was really desired, for whatever reason. I don't think XFCE users would care much, but I just mean this as a way to illustrate what level the extension API sits at -- it's a level below the panels and menus and stuff.
There, that's the issue you're refusing to see. Having to discover and install extensions to do basic things is not a good feature.
If that's OK for you, great. Doesn't work for me.
Maybe they fixed things in the last few years, I have no idea, but last time I had to use Gnome 3 it broke existing DE muscle memory of using all sorts of environments across all sorts of platforms, and made it hard to discover how to change anything. Having to then install third party pieces to achieve minor change is not something I feel is an adequate replacement, particularly coming from systems where easy, built-in configurability comes as standard.
Again, if that all sounds fine to you, more power to you. To me it's an opinionated DE that tries its best to push its own ideas of usage on the user, and hides any/all options behind an API rather than exposing them to the user by default.
Why would I bother with such a DE when I can find one that supports what I want to do out of the box?
Right, so that is a problem, but it's a different problem from lack of configurability. Those things are being addressed in other ways such as with the extension rebooted initiative: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...
You're making a distinction of "third party" here but I don't understand why that really matters for configurability, for example it's no different from installing an unoffical XFCE panel applet, or using a third party file manager, etc. In the gnome shell, the extension API is built-in and standard. That is the configurability. If you're asking for specific panel settings to be included by default, that really isn't possible in a way that would please everyone -- you can look at the sheer number of panel extensions there are to see why that is the case. Again someone could make one to make it look and act exactly like XFCE's panel, but that would just be yet another option. Does that explain it? It's not really possible for the shell to act the way you're asking.
I support you using XFCE if that's what you want, but if you're asking for changes to be made in Gnome, those could probably not be made without causing much worse breakage. If you're not asking for that, then never mind, I misunderstood :)
Lack of out of the box configurability, lack of ease of discovery of configurability, lack of dependability on third party pieces (which may be essential to my workflow, that third party widget in Xfce isn't).
That initiative looks like a good move, I don't mean to disparage that.
> In the gnome shell, the extension API is built-in and standard. That is the configurability.
And that's not a good mechanism for me, as discussed.
> If you're asking for specific panel settings to be included by default
Yes, that's specifically my preference, for a system the user can configure, easily/out of the box, without relying on third parties to patch some really simple stuff back in.
> It's not really possible for the shell to act the way you're asking.
I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome. I have had no real interest in Gnome since the 2->3 transition and this approach is part of that.
I personally would describe that approach as actually more lacking in configurability, because with that you're limited to only the built-in settings. In my opinion all those could be improved with further improvements the extension system. In general I also see the line between "third party" as being blurry in these open source projects, because any random person can contribute something. But in the end, you deserve to use something that is to your preference.
>I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome.
Sorry, I guess I'm confused as to why you'd be talking about technical issues with GNOME, if it's been totally irrelevant to your interests for the last 10 years, and you don't even use it. If you're not interested to give constructive feedback or try to fix the issues, or try to describe different ways of achieving your workflow, then I would say I'm not really interested to discuss complaints about these things.
The problem is that the extension API is fundamentally unstable, and so extensions which provide the functionality that I consider a must-have, are unreliable, and may break in future versions of GNOME. I don't want to be in the position of debugging an extension which stops working in a future version of GNOME. I may be a kernel programmer, but as far as the desktop environment is concerned, I just want to be a user of it. And if an extension breaks, and I have to figure out which other extension might have the feature that I want, but which might require painful configuration somersaults after successive new GNOME versions, the answer is very simple. I'm just going to say, "No Thanks". KDE/Plasma supports what I consider to be fundamental key functionality, and I don't have to mess with it. And so GNOME is just not for me. If it works for you, great! But an extension API which is not stable, and when what I consider core functionality can only be provided by extensions which are resting on top of quicksand, is not going to be persuasive answer.
If KDE has a solution to this problem in the works, I'd love to hear about it, but AFAIK this is not solveable with code, because it's a headcount problem, not a technical one. Otherwise my suggestion would be the same as the kernel developers say to someone using out-of-tree drivers: either get your extension upstreamed, and deal with the long review process from the shell developers, and be prepared to explain in extreme detail why you need 2d workspaces and why it's worth it to have upstream maintain that... or just don't update your shell until the extension gets updated. This isn't really a Gnome specific problem either if you ask me, I haven't seen any desktop compositors for Linux that are active and offering a fully complete and stable API, because turns out it's not an easy thing to do.
GNOME has chosen not to do this. And so, GNOME is not for me, because I consider a 2-D workspace a "must have" feature. And so I will choose KDE over GNOME, because as a user (and I'm not interested in becoming a Desktop developer, sorry; I'm also not a web browser developer, or word processor or spreadshet developer, either. We can't be developers for everything), KDE meets my needs as a user. GNOME does not.
My main complaint with GNOME is that their answer for "you don't support feature X" is not, "yeah, sorry, we have an opinioned design, and go f*ck off", but rather, "Stop complaining, we have an extension for that". And so they don't understand that unstable extensions is not an answer to a user complaint that a feature doesn't exist. If they don't want to support a feature, that's fine. But don't try to use the lame excuse, "there's an extension for that", since they don't want to admit that they are asking users to rely on something that will randomly break.
If someone wants to use ZFS, I'll tell them that this is not supported by Linux. If you really want ZFS, use Illumos or FreeBSD. If you use Linux with ZFS, and it breaks, that's not my problem, and I'll be first to disclaim that Linux support ZFS. Because it really doesn't. There may be 3rd party developers who are trying to make that work, but I would never recommend to a user that they use Linux/ZFS, since if they need newer hardware support which is in a kernel not supported by Linux/ZFS, or their distribution has updated their default kernel to a version that doesn't support Linux/ZFS, they shouldn't come complaining to the Linux kernel community. Unfortunately GNOME is trying to have things both ways.
So the "just a few clicks and you can install an extension" is really a very weak, naive argument. One might even say, one made in bad faith. I don't tell people to use out-of-tree kernel modules either, because that's not really a solution for exactly the same reason. Instead, I tell them, yeah that sucks, I suggest that you not buy Nvidia hardware. :-)
>The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.
So just to be clear, that same problem propagates to upstream, which is exactly why the extensions break. If they wanted the extensions to not break so much, the alternatives there that upstream has would be:
- Hold up the release so that everyone gets a chance to update their extensions. This causes sweeping problems because now everything else is delayed if an extension developer is slow, and this may not even help if the extension developer has truly vanished, because then nobody will be around to update the extension. Gnome switched to time-based releases a long time ago to get away from those problems.
- Merge the extension upstream. There are a large number of extensions, and some of them conflict with each other, so this is sadly not feasible to do with every extension that everyone wants, and some people will still be unhappy because their extension was not popular enough to get merged.
- Limit the extension API to a small group of stable functions. This will reduce the total number of extensions, and people will still be unhappy because some things will not be part of this API (e.g. it's unlikely you'd get the full lower-level workspaces API that allows you to implement something like 2d workspaces).
- Don't allow extensions at all. Now if you want to change the shell's behavior, you have to do a hard fork.
So yeah, I agree extensions are sometimes not a valid solution to a feature request, but the problem is that every other solution is even worse, at least for Gnome anyway.
>I suggest that you not buy Nvidia hardware.
If you want to play this game, I could suggest that you just not use 2d workspaces. But I won't -- I think you deserve to use that feature if you want it. And if I did buy nvidia hardware, I would use nouveau :)
The kernel interfaces which are supported forever, and for which we will never break userspace, are the system call interface. We don't break that, because to do that would be to break faith with our users.
With GNOME, features are removed, and the lack of features are excused, by saying, "there's an extension for that". That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable. If the extensions API is not stable, then you shouldn't be encouraging out-of-tree users of that API. Because you're effectively promising that you will break them, all the time.
There are times when we in kernel land will say, that belongs in userspace; it's insane to put that functionality in the kernel. But when we do that, we offer stable system call interfaces so that you can do it in userspace, and users can trust that it won't break.
The bottom line is if the API is not stable, then there should be no external users of that interface. Which is why you shouldn't use Nvidia drivers. They are a bad idea. Similarly, people should not use GNOME extensions, unless they like being randomly broken at a distro upgrade.
And yes, I will not use 2d workspaes with GNOME, because I refuse to trust in extensions. My solution is to simply not use GNOME. Xfce and KDE support 2-d workspaces as core features. If GNOME can't, then to hell with it.
It's not different, it's mostly the same with extensions. They're strongly discouraged unless you're able to track upstream and follow the release. If someone can't do that, then don't depend on them to make an extension. You wouldn't make such a person a kernel maintainer of a key feature either.
>That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable.
That comes back to what I was saying earlier. The system call interface is very small and very limited compared to the total size of the kernel's API. It's not the same as the GS extension API, which is a huge API that allows access to various internals. The equivalent to create a "syscall API" in GNOME shell would be one of the options I said earlier -- "Limit the extension API to a small group of stable functions" which would not please you either, because that would essentially be removing APIs and would cause even more extensions to break and become impossible to implement.
Of course if you decided to stabilize everything then you would be stuck with a project where you can't refactor anything -- imagine a future for Linux where you have eBPF hooks across every function and internal structure, and you can't change any of them ever, because those kernel structures are now external API accessed by userspace. If you want GNOME to stabilize their internal API, that's really what you're asking them to do. Is that a good explanation of the problem? I'm trying to explain here why this is actually a really nasty technical minefield, and ultimately has little to do with release policy, or with any particular architectural decisions made by GNOME. There are basically zero active open source desktops that have a comprehensive and stable plugin API. KDE doesn't do it here either -- these particular areas are not even possible to change there with plugins, you're just lucky enough that the core workflow works for you.
>unless they like being randomly broken at a distro upgrade.
This is not strictly true. Just FYI, I've seen some GNOME-based distros that are starting to bring certain extensions into their release cycle, and make those part of the upgrade. But of course that falls on the distro to support the extension and do the testing before they ship, so the extension has to pass a certain quality and usefulness threshold first for that distro's users. If you get stuck using a GNOME-based distro in the future, you may want to check what their policy is there, you may be surprised (although I don't think any are shipping 2d workspaces).
>Xfce and KDE support 2-d workspaces as core features.
That's great, you should use those if those are what you like. But here is my perspective: If some XFCE or KDE developers (who know how to implement 2d workspaces) wanted to spare some time to revive the 2d workspaces extension in GNOME, and keep it working during distro upgrades, and support you doing what you like, I don't think any GNOME people would have a problem with that. Similarly, if it were possible in a reliable way, I don't think anyone in KDE or XFCE would have a problem if some GNOME developer maintained an optional XFCE or KDE extension to make those use a GNOME-style workspace overview, for those who prefer that design.
Fool me once, shame on you. Fool me twice, shame on me.
More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.
What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).
And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.
As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.
GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.
>Device drivers should live in the kernel. Period.
It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.
Secondly, extensions are not the answer, because extensions are inherently unstable. If you think the answer to supporting features is via extensions, then of _course_ GNOME doesn't have enough developers. Some featuers need to be in the core DE --- as 2-D workspaces was once a core feature. Ejecting features from the core feature set, and trying to implement them as extensions, is a receipe for P-A-I-N. It certainly isn't how KDE and XFCE handles 2-D workspaces; there it is implemented in C++ or C, and not in some Javascript extension language using unstable primitives that randomly change from GNOME version to GNOME version.
My Goal is to use a Linux Desktop Environment which meets my needs. And part of my needs is certain well-defined feature set which includes 2-D workspaces, and that they **NOT** be implented as an extension. Because extensions break. All. The. Damn. Time. I've been around since the very early days of GNOME, and GNOME had 2-D workspace support for years and years, and it was not a big deal. It was ejecting features from the core, and implementing them in unstable Javascript which is what caused the problems.
If GNOME simply said, F-U to certain classes of users, we don't think certain features deserve to exist, I'd probably respect them a bit more. I still wouldn't use GNOME, but at least they'd be honest. My complaint is trying to assert that extensions are an answer, and they're not, because it's really unfair to trick users into relying on something which is ultimately built on quicksand. Better to have a small feature set which you can support well, rather than a randomly fluctuating feature set which arbitrarily breaks across distro upgrades.
That would be OK for some minor adjustments, when user can live without this extension for a while. But for something as major as dash-to-panel, it should be official and updated synchronously with main project to be a proper option IMO. That's my reason to avoid this extension for now. It might be good, but I don't want to depend on it.
But I chose GNOME knowing they have a tendency to break a lot of extensions with new versions, which is honestly quite a pain and something I understand many (if not most!) don't want to deal with.
What exactly is the problem? It sounds like the configuration setting just moved, I can see that being inconvenient if you're used to the old way, but it doesn't seem like some big glaring design flaw.
>For a long time nautilus had a "Connect to server" option, but that went away
I believe that is still there if you click "Other Locations."
With Wayland finally taking off (color management be damned sad), maybe you could give Sway, the Rust tiling manager, a go. Debian has a page for it https://wiki.debian.org/sway
The closest thing is probably indeed KDE, which the Debian Cinnamon maintainer switched to as they say in the post…
KDE 4 was a low point, at least the first releases were buggy and didn't feel nearly as good as 3, but 5 has been absolute smooth sailing. It's surprisingly light and nimble, I use it on my Thinkpad X220i and it runs great, better than Cinnamon on Mint did when I tried that out.
There seems to be a lot of friction against giving KDE a go, and I just don't understand it.
It's called NIH syndrome.
Only the Qt thing is current, but memory is long on these things and a lot of people formed their opinions a decade ago. First impressions and whatnot.
I have not tried KDE in this decade, or the last. The article makes me curious. But Qubes is an Xfce desktop, and I am stuck there for the time being. It has been OK. Qubes desktop can't use a GPU anyway.
If Qt goes proprietary, it will fork without drama.
I don't know what the situation is these days though but anecdotally it seems GNOME has now become the "bloated" desktop, thanks to Javascript in the shell.
Firefox or Chrome will absolutely dwarf your DE in memory usage, so I don't think it's really a major differentiator between KDE and Gnome. If your PC has less than 2GB of memory, you'll run into other issues first.
[1] https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
So given that GNOME is unacceptable to me (it doesn't support 2-D workspaces as a core feature, and extensions which support 2-D workspaces regularly break because the extensions API is not stable), and while I'm very happy with Xfce, but I was concerned about its long-term maintainability since it's tied to X, and its developer community's ability to move to Wayland seemed questionable, I decided to give KDE a try.
To my surprise (I go back long enough to the days when KDE was highly opinionated and GNOME was the DE that had a lot more flexibility), KDE had support for everything that I needed (which is not a lot; I just want a decent, configurable window manager, and a decent terminal) and so spent the investment to move over to KDE.
I see that the Xfce folks are now starting to think about adding Wayland support, and that's great. My main priorities is that I not be left high and dry when there is a major release, and whether I get messed up because GNOME has broken some extension which I depend upon, or some future desktop hardware no longer works with xfree86, and only Wayland, it looked like KDE was the best bet for me as a user who just wants a window manager, decent terminal support, and a 2-D workspace. You'd think that is a simple ask, but unfortunately, these days, it's not something I can count upon --- but KDE seemed to be my best bet.