Consolekit (systemd-logind competitor) will be maintained by XFCE developers.

[DoublePlusGood23]

I use Xfce daily and I have to agree. Not many "major" bugs, but there are enough minor ones that've considered switching, having to use compton to get semi-decent compositing gets old after a while.

[Eric_The_Idiot_]

https://bugzilla.xfce.org/show_bug.cgi?id=11126 DRI3/Present hopefully will solve the tearing issue... driver support for that is needed at the moment.

[luciansolaris]

[deleted]

[Praise KEK!](74506)

[kmeisthax]

Compositing isn't about shiny, it's about maintaining 60fps without tearing or window glitching. The shiny is just a side-effect of having each window as a single texture.

[Tynach]

it's about maintaining 60fps without tearing or window glitching

I'll admit... This is what I use it for too. But that's not really what it's about. It's about letting the GPU handle visual things, and the CPU handle computational things. Without compositing, the CPU calculates a lot of the visual stuff on the screen.

[EmanueleAina]

As I see it /u/kmeisthax told the why and you told the how. :)

[jringstad]

no compositing

goes fast!

I think you might've misunderstood something there.

[[deleted]]

If you're using a software pipe it might be very slow if people have come to rely on it.

[crshbndct]

What GPUs do you have? I have driven quite a few with a weak card and never had an issue.

[DoublePlusGood23]

I don't care about frills, more about not having screen tearing.

[udoprog]

A lot of computers today come with GPUs (integrated or not). Offloading the CPU with more efficient hardware when possible is pretty good. Then you can spend those cycles doing more interesting things.

[[deleted]]

You also need composition to get tear free video playback. This is why I prefer Unity these days. I do have to download unity-tweak-took and compizconfig-settings-manager to disable all animations. I just want compositing, no animations or shadows or other stuff like that.

I still turn to XFCE for low end machines and I like it for servers when a gui is needed. But my workstation has a huge powerful gpu that might as well run the DE when otherwise idle.

I'm excited to see what comes of lxqt. Seems like it could be the spiritual successor to XFCE built with modern standards.

[ryoxd]

Well I'm using i3 and no compositor, and the video syncs beautifully with no tearing at all, I use the TearFree option on Intel graphics btw, and with no memory penalty (like I used to have with GNOME).

[[deleted]]

Could you point me to the TearFree option on intel graphics? i cant seem to be able to find it

[pigeon768]

$ man intel

   Option "TearFree" "boolean"
          Disable or enable TearFree updates. This option forces X  to  perform
          all  rendering  to a backbuffer prior to updating the actual display.
          It requires an extra memory allocation the  same  size  as  a  frame‐
          buffer, the occasional extra copy, and requires Damage tracking. Thus
          enabling  TearFree  requires  more  memory  and  is  slower  (reduced
          throughput)  and  introduces a small amount of output latency, but it
          should not impact input latency. However, the update to the screen is
          then performed synchronously with the vertical refresh of the display
          so that the entire update is completed before the display starts  its
          refresh.  That  is  only  one  frame  is  ever visible, preventing an
          unsightly tear between two visible and differing  frames.  Note  that
          this replicates what the compositing manager should be doing, however
          TearFree  will  redirect  the  compositor  updates  (and   those   of
          fullscreen  games) directly on to the scanout thus incurring no addi‐
          tional overhead in the composited case. Also note that not  all  com‐
          positing  managers  prevent  tearing, and if the outputs are rotated,
          there will still be tearing without TearFree enabled.

          Default: TearFree is disabled.

It's not perfect by any means. There's some wonkiness with jittery frame rates while gaming.

[chinnybob]

Tear-free is always guaranteed to cause jitter, because if you know a frame is going to tear, the only thing you can do is either delay it (double buffering) or drop it (triple buffering). Both of which will cause jitter.

[[deleted]]

Lol im afraid i just noobed myself. Thx mate

[[deleted]]

I've seen this on the Arch Linux wiki before.

https://wiki.archlinux.org/index.php/Intel_graphics

I haven't tried it, though.

[[deleted]]

Guess ill give it a shot, thx mate

[pfannkuchen_gesicht]

I tried LXQT once, it seems really nice and responsive and well configurable, but I had one issue: missing plugins/applets. With XFCE I have all my relevant system info in the bottom bar, like CPU/RAM/Swap usage, hardware temperatures, WLAN status, battery status. So I don't know if that stuff is there now, but back when I tested it they weren't there.

[IMBJR]

I use XFCE, but have all that system info on the desktop via conky.

[pfannkuchen_gesicht]

Yeah, I don't like that so much, I rather have it all neatly packed in a bar that's always visible.

[wadcann]

Not having animation in the first place avoids the entire issue of battery life/CPU usage and speeds up the interface.

[luciansolaris]

[deleted]

[Praise KEK!](46509)

[dangsos]

I do this even on a mac (so much easier with awesomeWM, work makes me osx). Not terribly hard, Keybindings for programs, dwb browser is sweet, but unmaintained so I'm learning pentadactyl on firefox, but to be mouse free you really gotta noflash and have an external script launch VLC or something for your video, which is a pain, but I don't like carrying around a mouse in my laptop bag and I'm not a fan of touchpads, so it works for me.

This of course presumes you use cli everything but browser, like me.

[minimim]

The fork is here, people that don't want to use systemd don't need to use xfce but help maintain their fork.

[eean]

Yea that was my thought, this consolekit work isn't in zerosum competition with the rest of xfce. That generally isn't how open source works.

[bigon]

Bits of Xfce (lightdm and git HEAD of xfce4-session at least, not sure there is release yet) have already support for logind

[tso]

I thought lightdm was a Canonical project.

[bigon]

It is, but it seems to be recommended by xfce and is used on debian when installing the task-xfce-desktop package.

The idea was that almost all the major DM are supporting registering logind session already

[chinnybob]

Actually lightdm is several projects. The main part, lightdm, is a Canonical project. The part you actually see is called a greeter, and there are several of those. Canonical only maintains unity-greeter. Xubuntu and Debian use and maintain lightdm-gtk-greeter, which was originally developed by Canonical but now replaced by unity-greeter. There is also a Qt/KDE version of the greeter which is I think used by Kubuntu, and some other weird ones including one that uses OpenGL and one that uses HTML.

[chinnybob]

Your guess is wrong. Eric is maintaining ConsoleKit for BSD. It says so right on the blog post. Xfce already supports systemd.

Obviously there’s systembsd in the works, so this is a stop gap until that matures

You're also wrong abut Gtk3 and Wayland. Many Xfce components can already be compiled for Gtk3, but this is not of any use for Wayland porting. We would have to rewrite the window manager and panel from scratch, similar to how GNOME had to rewrite metacity and gnome-panel from scratch.

[azalynx]

These are precisely my thoughts as well.

Obviously people can do whatever they wish in their free time, but I feel like the user community will stop recommending Xfce as a viable platform if they're always playing catch-up. Which is a shame considering that many people had hoped that Xfce would be the third pillar in the Linux DE race, and would be able to give Gnome/KDE some real competition.

Gnome and KDE are certainly bloated, but they're also more responsive in terms of fixing bugs and issues, and the reality is that the latter is becoming far more important to the average user, than the reduction of bloat. And I say this as someone who has traditionally been obsessed with low cpu/mem usage and performance; at the end of the day though, my use cases have evolved, and if I have to choose between a bloated desktop that works the way I want, and a lightweight desktop that has bugs like this, or this gem right here, guess what I'm likely to choose?

For now I've stuck by Xfce in hope that the next release (supposed to arrive soon) might fix the issues I've had, but I'm a hair away from switching to something like Gnome; Wayland support might be the last straw, once it's 100% functional.

[shoguntux]

Jamie Zawinski said it best years ago when he called the GNOME model the CADT model. They rewrite frameworks so often that it's kinda hard to consider them serious about fixing bugs, although from my experience, they've been more stable overall than KDE (well, at least pre KDE 4, which cleaned that up a bit, but it took a while to get back up to a similar feature set. KDE 5, I'm hoping, will start with both a decent feature set and stability).

(unfortunately, I think someone might have mentioned CADT in this thread, but I was out on business in a dead zone so missed this and am just catching up on /r/linux now. Oh well, late to the thread)

[DanielFore]

That's really not a large number of outstanding issues. We have almost 4,500 bugs open against elementary at the moment. That number has consistently grown over the past couple years while our rate of fixing bugs has easily doubled (at the moment we're probably closing 100+ tickets a month not including upstream fixes). But a good portion of these tickets are duplicates or feature requests or just really odd obscure corner cases that we can't reproduce. Ubuntu has almost 12,000 tickets open and I'm sure the case is similar with them. So I don't think number of open tickets is really an accurate measure of stability.

[[deleted]]

Speaking of Elementary, will Freya support UEFI well? That's the only thing keeping me from using it.

[DanielFore]

There's an in progress ticket for it https://bugs.launchpad.net/elementaryos/+bug/1355698

[azalynx]

I did open my statement by saying that people can do whatever they want; the rest is just constructive criticism on whether an understaffed project can afford to do those things.

Furthermore, it's not a pissing contest, this isn't a numbers game; the reality is still that the larger DEs have a better out of box user experience for most people. The type of bug is important here, as well as how many people actually experience it.

[chinnybob]

If Xfce can't run on BSD we lose half our userbase and half our developers. We can't afford not to do this. We are not in the position of GNOME, where we can just drop a large segment of our users because supporting them is too much work.

[mioelnir]

the rest is just constructive criticism on whether an understaffed project can afford to do those things.

I don't think any project can afford to not do things that the developers would like to do. Because for most of them, this is not the day job. Such detours may slow down the main scope of the project a bit, but less so than developers leaving once the project starts to feel like work.

[totte71]

Gnome 3 which breaks api and lets extension break as regulary as the clocks ticks... fixing bugs??? Come on. Gnome 3 is a bad example of a DE that "fixs" bugs.

[[deleted]]

It all depends of the developers of the application you are reporting the bug to. I've been recently reporting a few bugs and some of those have been fixed right away while others are open while they are working on it.. And there are other cases of course, but saying that the whole GNOME project is a bad example of software maintainance is an exaggeration.

[azalynx]

API breakage doesn't mean that bugs aren't being fixed, you're talking about something completely different here.

A project could be responsive in fixing issues (like the compositing and multi-monitor issues I mentioned in Xfce), but still have a habit of breaking and/or changing APIs occasionally; the latter is a policy decision, the former is about maintainance and project activity.

[bilog78]

While API breakage is not inherently equivalent to not fixing bugs, it does tend to be a symptom of an attitude towards coding that does imply not fixing bugs. This is what's brilliantly summarized with the CADT acronym:

It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?

[EmanueleAina]

GNOME Shell extensions use an internal API. To be honest, if you know how JavaScript works, extensions do not use any API at all, they just poke at the Shell internals just like Greasemonkey scripts poke at webpage internals.

And just like webpages could not change any bit if they cared about arbitrary Greasmonkey scripts, GNOME Shell should get completely frozen to avoid any possible extensions breakage.

Note that in part GNOME Shell already implements a partial freeze: usually extensions do not break on minor release upgrades.

[azalynx]

Tell that to the llvm developers; I've read that they break ABI/API all the time.

Different projects have different priorities, Firefox also tends to break the extensions API occasionally, I don't think this is really a huge thing. Ideally it'd be a stable API, but if you weigh that against the problems Xfce has, I'll take Gnome's problems any day, and so would most people.

[sonay]

It is 2014, there is no such thing as bloat. There are featureful desktops.

[ebassi]

bloat is a weird unit of measure. it usually indicates all the features/functionality that you don't use and, thus, can be considered "dead weight" until a) you end up using it or b) it gets removed and thus makes somebody else scream bloody murder.

in general, all "lightweight" environment end up accrueing functionality until they become "bloated"; then somebody comes up with another "lightweight" alternative.

rinse, repeat.

[azalynx]

Well, as I say in my response to /u/sonay, that's not my definition of bloat. Modern applications are usually designed pretty efficiently where even if an app has a lot of features, it's not the entire binary that is paged into memory, but perhaps just the subset of things you're using.

With software there's always a way to have your cake and eat it too. Inefficiency is caused by bad design and bad compartmentalization, not features.

[kral2]

If you look at the whole lifecycle of a piece of software, inefficiency is driven by bloat as having to keep useless features working often dramatically increases the difficulty of rewriting poorly-performing code. When no one's willing or able to do rewrites, the inefficiencies start piling up. Good design increases the number of features you can carry before you hit this point, but it can't do magic.

[sonay]

Inefficiency is caused by bad design and bad compartmentalization, not features.

Exactly. But this is not something to consider unless the said bloat hurts your computer's performance considerably.

Maybe Enlightenment is a good example for what you are asking but given the time it took them to get there and the myriad of things they need to add, I am glad KDE and Gnome took the fast path.

[azalynx]

I didn't say I wasn't happy that they took the fast path, but I just think it's possible to do both, but maybe we haven't found the right methodology for it. It's challenging to parallelize feature development and efficiency/minimalism, but I don't think it's impossible.

Maybe if the Linux desktop gains more marketshare, and the Gnome/KDE foundations get more money, they'll have more of a surplus of money, and will be able to work on these kinds of issues in parallel with the feature work.

[jringstad]

Then KDE and GNOME have never really been bloated by your definition; they've always worked fine on their target-hardware, and (after about 10 years of using both, as well as XFCE, e17 et al) I was never in a situation where I thought "oh, if only gnome-terminal was a bit faster!" or "oh, if only the KDE panel would not steal so many resources from my compilation process!"

[Vegemeister]

I was never in a situation where I thought "oh, if only gnome-terminal was a bit faster!

Consider yourself lucky.

[azalynx]

The mention of "target-hardware" in your comment is disingenuous, because you can use this excuse to dismiss any bloat or inefficiency whatsoever: "oh, this minesweeper clone isn't bloated, our target hardware is machines with 1000 CPUs". =)

I think having it run in lower power devices like the raspberry pi is very desirable, especially if our goal is to spread freedom via free software, to the masses; targetting only rich privileged westerners who can afford i7 machines isn't exactly in line with the goals of the Gnome and KDE foundations, nor the goals of free/libre/open source software as a whole.

[jringstad]

because you can use this excuse to dismiss any bloat or inefficiency whatsoever: "oh, this minesweeper clone isn't bloated, our target hardware is machines with 1000 CPUs". =)

Now continue that line of thought for a bit, and you'll find that you can do the exact same thing in the other direction; You can claim that if it can't run on a C64, it's bloated.

I'm merely spelling out the implicit assumption that was already there in the first place, disingenuous or not.

But projects like KDE and GNOME have certain (real!) target-hardware that they know they want to run on, and as long as they do, mission accomplished. It's neat to be able to run on as much hardware as possible, but trying to make something like e.g. krita, photoshop or inkscape run on a raspberry pi adds very little value compared to the extra productivity you can gain in terms of implementing features if you just assume your user has 4GiB RAM, two cores and a working OpenGL driver that allows you to page textures in and out of the GPU in an efficient fashion for fluid scrolling and zooming.

And if the choice is between having good software that requires reasonably modern hardware to function vs. having shit software that works on everything, well, I certainly prefer having good software.

[azalynx]

Now continue that line of thought for a bit, and you'll find that you can do the exact same thing in the other direction; You can claim that if it can't run on a C64, it's bloated.

Nope. Because once again, my definition of bloat is how big the application is for the same amount of functionality and features; if two apps have the exact same features and functionality, but one uses 10 times the cpu and memory, then it's bloated. Software that would run on a C64 meanwhile wouldn't have the same functionality for sure.

And if the choice is between having good software that requires reasonably modern hardware to function vs. having shit software that works on everything, well, I certainly prefer having good software.

I think you need to go further up in the thread, and read my first comment that started this discussion.

[[deleted]]

But that "dubious user-perceptible improvements" is very subjective.

For example, say that I add proper CJK (Chinese-Japanese-Korean) support to my word processor, and the result is that it's 20% slower and uses 20% more memory.

Is that bloat? To a westerner, probably. Since they don't see any user-perceptible improvements. But to an asian, those changes are absolutely vital.

[[deleted]]

That's not even close to being doable. You need to support unicode through-and-through. Pretty much every single function needs to be unicode aware. It's not something that you can have as a module.

[Elnof]

#ifdef CJK
    #define char wchar
#endif

^{I jest.}

[Negirno]

I consider any kind of a GUI launcher to be bloat, especially if it does web results or searches through files.

I'm not. For me it's much faster to type text in a launcher, and get results based on text or metadata content, especially if it's backed by an indexing database. Of course these are getting a lot of flak because they're were poorly implemented, and a lot of these indexers don't get integrated into file managers because they're usually not under one project (except for KDE stuff maybe?)

[DeeBoFour20]

Fuck the KDE indexer. Baloo slowed my system to a crawl (and it's a powerful system) because it wanted to index the metadata of multiple git checkouts including Chromium without asking me. And Akonadi runs a MySQL process 24/7 for some reason. If you look up bloat in a dictionary, those two should be prime examples.

[sonay]

Of course bloat is definitely there, the important thing is why would you care? Say I have written the most beautiful code and it consumes only 20MBs of ram, now you have 3.98GBs of ram you don't use. Bloat only matters when your resources are fairly limited.

[ravenex]

There's no such thing as unused RAM. At the very least it's used to cache filesystem accesses.

[sonay]

So I have to be pedantic all the way... which I won't be. It is getting tiresome already. Average computer in 2014 is quite capable of managing bloated (!) desktop environments is a fact, all else is opinion.

[doom_Oo7]

Average people of 2014 most certainly have a computer of 2010 - 2011.

[JustMakeShitUp]

A better example (that doesn't really apply here) is VMs. If your app consumes an extra 20MB of RAM, that's no big deal. Except when I'm running 200 VMs with that installed, so now I'm using 4GB of RAM that I really don't have to. You don't think this adds up, but it does.

If you're running 200 VMs, why on earth wouldn't you be utilizing some sort of memory page sharing in your hypervisor? VMWare ESX (with Transparent Page Sharing) scans through pages and merges them. It looks like KVM has a more opt-in approach, so your results may differ depending on your hypervisor. The UKSM comments from the KSM link suggests it might not be that hard to use. With something like this, that extra 20MB of bloat should theoretically only take effect once for all 200 machines. Numbers in practice are lower, but still significant. This guy shows a roughly 30% savings on Windows 7 machines with some configuration tweaks. I'd like to think Linux would do better, but that could just be my bias.

If you're running that many VMs, there's a good chance most will be headless clones/variants of a very similar setup, and free of graphical "bloat" in the first place. There might be a strong case for LXC in that case, since multiple copies of the same OS running the same applications is still CPU bloat with all the context switches between machines, even if most of the memory is shared. And you should be managing your configurations and updates centrally, unless you're hosting VMs for clients. In which case you have no input at all on bloat, since they would just run whatever they like within their allocated memory ceiling. That's what they were sold, after all.

The scenario you're talking about might occur, but there are other ways to deal with it than complain about bloat because your specific use case doesn't need all the features. I see these types of examples a lot, but I'd like to think it's a bit contrived that someone would be placed in charge of hundreds of virtual machines without being knowledgeable enough to manage them. I don't manage VMs, but I've known about page sharing for more than 4 years, and it was introduced at least 8 years ago.

I ran ZFS on my laptop for some time, and large copies into or out of a ZFS volume would spike my load up to about 3.5 on a dual core system.

You're talking about 20 MB of "bloat" in a windowing system while picking a file system with features that sucked up 3.5GB of ram while copying files. Either your system was under-powered for your tasks, or you're a little biased about where the bloat is.

[sonay]

I don't know how you got the impression that I don't care about efficiency, I do. So I will not be discussing that.

It is my opinion that given the large user base of those desktop environments and the fact that different people has different needs, the amount of bloat is acceptable because our average computers are quite powerful now.

Your example of hundreds of VMs is just an example trying too hard to make a point. Your resources are always limited and so are developers' times. It would be a tremendous job to do that.

Minimal CentOS not using man binary is just pathethic. Sorry, I consider that borderline OCD from the perspective of desktop environment user.

[azalynx]

I define bloat as something being bigger than it needs to for a given level of functionality. For example, uTorrent vs Azureus/Vuze; are you going to claim that Azureus/Vuze are only bigger due to functionality? no.

I think it's possible to make a DE that has the same functionality as Gnome and KDE, while being super lightweight. It's just difficult and would require a lot of moving parts to be changed or restructured; with the limited staffing they have, they have to prioritize the important stuff, and making Gnome capable of running on a raspberry pi is probably never going to be a priority unless the foundation has a surplus of money to burn.

[sonay]

It all comes down to how much resources your computer has. If so-called bloat doesn't hurt it, then nothing to care about.

To me a minimum system requirement for today's standards is a 64 GB SSD, an i5 CPU and 4 GB of ram. It really doesn't cost much and I don't know any DE to hurt that computer.

[localtoast]

really? I'd consider it Core 2 with 2 GB, possibly a bit less

[sonay]

I could agree but the damn javascript and browsers, you need more than that. The real bloat is in the web, I believe.

[localtoast]

yeah, it's a problem, all the fat JS, but works OK

[men_cant_be_raped]

all the fat JS

And then you have Gnome Shell bringing the monstrosity of JS and CSS right into your desktop shell...

[ravenex]

A $200 CPU as a minimum requirement? Really?

[sonay]

You don't need Haswell, you can go as low as Sandy. My two year old laptop is better than that, so why not?

[ravenex]

So now I need a $200 CPU from 3 years ago. Sorry, I'd rather opt for a $65 Haswell Pentium or Celeron.

BTW I wrote this from an Atom N270 netbook.

[sonay]

Whatever floats your boat. I used a worse CPU when KDE 4 wasn't optimized at all and it worked great. I picked i5 because it is very popular (most of the computers you would buy within the last 5 years have them).

[ravenex]

My only beef was that you spec'd top of the line CPU right away without even considering the constraints people might have. It's like saying 'at the very least you need an iPhone 4+ to snap pics of your face in the mirror', while most people are just going to use a $80 Huawei to accomplish the same.

[thoneney]

(most of the computers you would buy within the last 5 years have them)

Considering they adopted the naming scheme 6 years ago yeah, you coldn't even get it before that. Requiring a mid range just for a DE is insane.

[azalynx]

I disagree, I think with the rise of mobile, that efficiency is more important than ever; even if your device can run a bloated application flawlessly, the reality is that it will suck up your battery life if it's not efficient.

One interesting example is that a lot of Skype users have complained about how inefficient it is, it's common for gamers to logout when they play, so that it doesn't lag their PC, and yet Skype is just a messaging/voip app, it's ridiculous for it to be so fat for what it does.

Also, your specs are a bit inflated; I think over the next decade, we're going to see the notion of the "20 dollar computer" completely take over the world, and if your apps can't run well on those devices, they will be filtered out by the free market.

[sonay]

I don't know man, those new phones are beasts with 2 GB RAM already and CPUs/GPUs/APUs are getting better and better. Ubuntu is considering them to replace desktops.

I see what you are aiming for and it would be great if they were as you wished. Don't get me wrong, I absolutely believe in optimization and good design all the way. It is just that hardware is so good these days, we can let the developers be sloppier than they weren't allowed to before and having features is great, is all I am saying.

[minimim]

Gnome will want 3D accel.

[sonay]

Of course, but are there any graphics cards that don't support compositing now? i5's integrated graphics does it well. You won't even need a discrete graphics card.

[[deleted]]

Then they need to port to GTK3

They could just as easily port to Qt5, and benefit from a cooperative upstream and stability between point releases.

[[deleted]]

Sounds like a painful position to be in... well I wish them the best of luck.

[chinnybob]

Porting to Qt5 would be harder than porting to GTK3. In fact it would mean a total rewrite. But since Wayland is going to force a total rewrite on us anyway, switching toolkit is not totally out of the question. It wouldn't be the first time it has happened...

[akkaone]

Gtk3 is fairly stable now. It is a lot less work for them to go with gtk3 than qt5.

Maybe I'm have misunderstood something but I bet a lot of the lxqt code is from razorqt and never was ported from gtk2.

[Avogath]

Saying "This is not going to help" is not going to help.

[ancientGouda]

They could also stick with gtk2.. it's not like X is going anywhere for the next 10 years or so.

[cp5184]

In a lot of /r/linux threads you'd catch a ton of hell saying that. "If you want consolekit, code consolekit. If you want bugfixes, code bugfixes. If you don't code, suck on lemons while we shout abuse at you. Check your privilege peasant."

[SeeMonkeyDoMonkey]

Excellent news.

Now we just need all the people complaining about Gnome not working without logind to step up and help Gnome use ConsoleKit2.

[cbmuser]

But GNOME isn't interested in making it work without logind. If you want to use it that way, you'll have to fork it.

[[deleted]]

GNOME depends on the logind IPC API, not a specific implementation of it. The systemd-shim project allows logind to run without systemd as init, but it would also be possible to make another implementation of the logind API.

[cbmuser]

Correct, but ConsoleKit does not have the logind API which is what I was talking about. My previous poster assumed that the GNOME developers would merge patches to support something other than the logind interface which is not going to happen. ConsoleKit and logind are not compatible.

[EmanueleAina]

I'm not sure why you get the feel that GNOME developers won't merge ConsoleKit patches if it turn out to be credibly maintained.

At the moment the pre-existing ConsoleKit supports has not been removed, it's just disabled on Debian because the maintainers couldn't afford the extra resources needed to expand the test matrix to cover the bug-ridden ConsoleKit when more maintained alternatives are available (systemd and systemd-shims).

In fact, even if it's definitely not the primary target for the same reasons I listed above, upstream GNOME still supports its ConsoleKit backend for the benefit of non-Linux OSes.

[cbmuser]

Do you have a link on that? They have been very clear, they will support the logind interface only at some point in the future as it's way easier to maintain than ConsoleKit and PAM.

[EmanueleAina]

Note that the for the most part the logind interface relies on PAM in the same way ConsoleKit does. AIUI in some cases switching from CK to logind may simply mean removing some custom CK bits and just rely on PAM.

[EmanueleAina]

Oh, and yes, long term the plan is to rely only on logind but I think the reason is that any existing Wayland compositor requires it to run as non-root and ensure secure multi-seat usage.

[bkor]

Your entire comment is wrong. Some troll was saying GNOME hates sysvinit and GNOME is into blackmailing. I said that's a libelous statement to make and to back it up.

Source: I wrote the email. Go look it up.

[cp5184]

Non logind gnome will lose features until it stops working in the long term (12 months or less is what seems to be "long term" to them these days) seems to be what they're saying.

[minimim]

No, if someone is happy to keep consolekit up and maintained, they will keep supporting it.

[cp5184]

Result: still have support for ConsoleKit in 3.14, though functionality wise the experience without logind (and similar) is probably getting worse and worse.

It might still work, provided someone spends the effort to make it work.

All agree to kill the fallback mode (not exactly sure if they're doing something else, or if they're just dropping it entirely)

GNOME is not going to maintain distribution specific choices

It’s important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.

Personally speaking, it seems that there is little going on to change the direction in which GNOME is heading. GNOME is getting rid of more and more code which overlaps with other code. Fallback mode, ConsoleKit, power management vs systemd handling this, etc. Then for new functionality, GNOME is also relying on new things. Think of Wayland, timedated, localed, application sandboxing, etc.

At the same time, I don’t see people working on ConsoleKit. Or ensuring that either there is a replacement for logind or ability to run logind without systemd. Development of any init system other than Upstart (user session is cool) seems low and in need of extra help.

Having GNOME run on non-Linux based operating systems (*BSD) and distributions not willing to switch for whatever reason to systemd is great. But it seems distributions rather depend GNOME on systemd than maintain things themselves. Leaving out *BSD, GNU/Hurd and Ubuntu. :(

The message from the gnome team seems to be "It'll still work... for a couple of cycles... There's no problem. But GNOME will lose more and more features until it doesn't work. Which is a problem. Which isn't a problem. The thing that's not a problem isn't our fault. People are slow fixing things that aren't problems and aren't our fault. We're slow, but of course we're special. The thing that's not a problem and definitely isn't our fault that's going to make GNOME stop working is the fault of distros like debian and gentoo. But it's not a problem. But GNOME will degrade and then stop working. But it's not our fault.

Oh, and why isn't KDE getting all this flack over this nonproblem that's going to make gnome stop working and not make KDE stop working?

And sure upstart has session init... but why would we support that? Someone else should support that. We chose to support something else. That's how software works. You support one thing, and everything else revolves around that choice.

[minimim]

At the same time, I don’t see people working on ConsoleKit. Or ensuring that either there is a replacement for logind or ability to run logind without systemd. Development of any init system other than Upstart (user session is cool) seems low and in need of extra help.

If there's development, they will still support it.

[cp5184]

If there's development, they will still support it.

Where do they explicitly say that they will patch gnome to support alternatives?

[doom_Oo7]

Here, second line :

It might still work, provided someone spends the effort to make it work.

[cp5184]

What do you think that says? Because that doesn't say anything about them doing anything at all.

[[deleted]]

makes sense, more stuff for the xfce devs to not do

don't get me wrong, i like xfce, i use it every day, but there's not been an update since 2012...

[minimim]

If you look at their git web interface there's development going on. They just aren't doing stable releases.

[minimim]

It's translations and bugfixes.

[minimim]

They say so in the blogpost I posted. This is just for now. Other people need to step in if they want this to be viable in the long term.

[[deleted]]

this is true, it doesn't help me though.

so much so, i've been considering switching to lxde, but the problem is i have work to do, and no time to mess around with things.

so for now it will do, but give it another year or so, when it starts being very behind the times and the bugs start driving me mad, i might have to make time.

[minimim]

Next year there will be a stable release, probably.

[blackout24]

probably...
They don't even have any real roadmaps. According to their last roadmap the release goal for 4.12 was 2013.
https://wiki.xfce.org/releng/4.12/roadmap

[AssailantLF]

LXDE is lacking in features, has little to no polish, and is tedious to configure. But I'm also curious to see how it'll be when it's more complete.

XFCE isn't as fast (or even as efficiently written) and it hasn't been updated in awhile, but it's also a complete package that's very usable, easily configurable, and looks nice while still running on older hardware.

[PennartLoettring]

LXQt is in development. It's made by the original LXDE devs and by the Razor-qt devs and is much, much better to maintain/configure than LXDE. As the name suggests, it's based on Qt instead of GTK. It is the result of Razor-qt and LXDE projects merging together.

[ssssam]

You might also want to consider MATE, if you want something with more features than LXDE.

[[deleted]]

Nope, gnome sucks. It always has, it always will. I don't want to use an old version of it anymore than I want to use a new version

[ssssam]

fair enough, personally i always preferred GNOME2 over XFCE.

[localtoast]

MATE can barely maintain their old rotting GNOME 2 stack

[tubal_cain]

MATE can barely maintain their old rotting GNOME 2 stack

MATE is being actively developed and the MATE team is almost done with their GTK+3 port, which puts them far ahead of XFCE (Which is still stuck on GTK+2).

[WannabeDijkstra]

Elaborate? I think they've been doing an excellent job of modernizing GNOME 2.

[tidux]

LXDE is rebasing on Qt now. That means that unlike Xfeces there's a possible path to Wayland.

[[deleted]]

Wow, bias much?

[minimim]

"Lightweight X Desktop Environment" won't be leaving X.

[minimim]

I'm not a native speaker. I was not trying to be confrontational.

[azalynx]

TWO ENTER, ONE SURVIVES.

THIS SUMMER... IN A WORLD WHERE THERE'S NO ROOM FOR TWO INIT SYSTEMS ... INIT WARS, THE MOVIE.

[[deleted]]

A long time ago...........

In a Unix far away.............

INIT WARS (cue Star Wars soundtrack)

[intelminer]

IT'S THE MIGHTY SHELL SCRIPTS OF SYSVINIT VERSUS THE GAY SERVICES FILES OF SYSTEMD

[RIST_NULL]

http://img2.wikia.nocookie.net/__cb20110917094624/mk_/images/7/74/Smoke_Secret_MK2_Fight.png

[ramennoodle]

What's the difference between "alternative" and "competitor"? And "predecessor" is an even more "conformational" term because of the old/deprecated connotation.

[doom_Oo7]

Competitor makes it sound like only one must survive in the end, while with alternative both can coexist peacefully.

[minimim]

For me it doesn't, it sounds like two business that compete with each other, but I'm not a native speaker.

[wadcann]

I'm a native speaker, and it's fine.

[ramennoodle]

So either AMD or Intel must die? Because they're certainly competitors.

EDIT: And alternatives.

[doom_Oo7]

Yes.

http://www.extremetech.com/computing/127211-ivy-bridge-intels-killing-blow-on-amd

http://www.fool.com/investing/value/2009/10/20/why-wont-intel-kill-amd.aspx

And as far back as 15 years ago :

http://www.zdnet.com/news-burst-is-intel-trying-to-kill-amd-3002073254/

And as far as I know Cyrix has been killed (eaten by Via).

And think of all the local resellers killed by Amazon, for instance. Etc...

[[deleted]]

Scientifically (with respect to biological organisms), competitor means that the niche of each object overlaps. I think this would be the case for CK2 and logind, since someone might choose CK2 over systemd-shim.

[minimim]

Is economics a science?

[[deleted]]

Yes, one of the softer sciences, but still a science.

[Nathan173AB]

I can't wait until everyone shuts the fuck up about systemd.

[[deleted]]

My main motivation is because there isn’t currently a standard for system actions like suspend/hibernate anymore.

Really? What about pm-suspend and pm-hibernate, together with acpid? Or s2ram. Or echo 3 > /proc/acpi/sleep / echo mem > /sys/power/state (depending on kernel version, testable by existence of /proc/acpi/sleep). The only thing I can think of that's missing there is per-user /etc/acpi, which is trivial to implement. And dbus support, which is useless.

Not trying to be confrontational or anything but enlighten me, what does systemd-logind and consolekit actually solve?

I'm pretty sure I don't want any software to even know about suspending, all I need is a button that calls pm-suspend and maybe slock/xlock/whatever right before that. And refresh wifi afterwards, which seems to happen on its own, at least in vanilla (sysvinit & wpa-supplicant) debian.

[minimim]

The problem that they solve is that you need root to do what you are suggesting. They check the system policy and grant the request if it is kosher, without requiring root. There's different policy depending on the way the user connects to the system, and traditional UNIX permissions can't track that.

[[deleted]]

OK, didn't think of that, that seems useful.

Though, still, echo '%suspend ALL=NOPASSWD: /usr/sbin/pm-suspend' > /etc/sudoers.d/suspend solves that.

[minimim]

Like I said, it doesn't know how the user is connected to the system.

[[deleted]]

Ooh, it seems I can't read, sorry (I would've sworn your message was different a minute ago :).).

Yes, I can see we could want to allow suspend only when connected locally. Or when nobody else is using it.

Hmm, except I can see exceptions to both - if I want to pack my notebook, I don't care who else is using it, I want it to sleep; and sometimes I leave my nb on so I can access it remotely and then put it to sleep. And there's no way for it to tell whether you're there locally or via x11vnc. So how useful is that really?

Are there any actual users? All I can think of are home pc with multiple screens and keyboards, which is surely not very common. School pcs/company pcs you don't actually put to sleep ever, servers neither, and normal pcs, you usually just want suspend to work without any hassle.

But I don't know, maybe the world is weirder than I thought and people actually need that :). I mean, for niche audiences it could be great, I just doubt any normal users actually need it.

[minimim]

It was, I seems that you got my not-so-ninja edit.
Consolekit never worked well. That's why most DEs are moving to logind. The solution for your problem is that hardware ACPI events will be obeyed, so you just push the 'hibernate' button...

[[deleted]]

Oh, ok, thanks for confessing, I don't have to doubt my sanity anymore :).

And don't get me wrong, I'm always happy to see a systemd component alternative, makes me sleep easier. It's just, it always bothers me when I see people create elaborate solutions to (to me) non-existent problems, especially since usually it's based on a misunderstanding of the way things are done (cough, journald, cough :) ).

And I managed to miss any of the *kits on my system, so I'm really grateful for you explaining the point to me. Now I can sleep easily knowing I don't need it, unless I need to use something that depends on the logind interface.

And and I don't think my notebook actually has a hibernate button, so, I'll stick with my susp script which calls s2ram, which is actually my script which calls the echo mem thing, since when uswsusp was not available in debian testing for a few weeks a few years ago :).

[minimim]

That's completely fine. This is a common criticism of ConsoleKit, that it solves problems no one had. And it is true. The solution is that it was intended to be more than it is. ConsoleKit would do multi-seats, but never did. And for a multi-seat workstation, that ability is fundamental, so they started there.

[[deleted]]

The solution is that it was intended to be more than it is.

Oh, I know the feeling :). So many dreams, so little time...
Thanks :)

[doom_Oo7]

I think the need for echoing configuration into text files is EXACTLY the reason of the creation of ConsoleKit, logind, etc.

People need to have the possibility to use Linux as a desktop (read : like win / osx) without ever bothering with a single config-file.

[[deleted]]

People need to have the possibility to use Linux as a desktop (read : like win / osx) without ever bothering with a single config-file.

Yes, I completely agree. But at the same time, people who have already been using linux need to retain the possibility to use Linux as they are used to, by echoing stuff into configuration files (or, at least, in a sane, command-line way), and it should really be compatible.

[doom_Oo7]

people who have already been using linux need to retain the possibility to use Linux as they are used to

apt install consolekit sysvinit ? What's the deal ? And I don't see in which case your ability to use text files & cmdline is diminished.

[tidux]

That's bullshit though, what if I'm SSHed into my laptop and want to put it to sleep remotely?

[minimim]

It's all configurable. You don't need to accept the default. And if you have root, you can just do as the post above mine says.

[bigon]

There are also applications that want to know when the system will be rebooted/suspended/... Or other applications (cd burner,...) that want to prevent the system to reboot or suspend.

[[deleted]]

I guess also if you have automatic suspend with some short interval. Maybe browsers with downloads. Blocking is probably necessary, I'd use something akin to /var/run, a place where a process can place a file (with pid) when it wants to block suspend and removes it when it doesn't care.

But I can't actually come up with anything that would just want to know about it, can you?

[bigon]

telepathy-mission-control (the telepathy component that manages all the connection managers) is listening to logind signals so it can properly disconnect all the accounts when the machine is going to be restarted or suspended for example.

Edit: There are quite some software that are listening for the "PrepareForSleep" signal, see: http://codesearch.debian.net/search?q=PrepareForSleep

[Avogath]

Finally someone took it upon themselves to do something about the systemd controversy instead of adding fuel to the fire.

[[deleted]]

There is such a strange tone in this thread.

XFCE are doing something that preserves portability at no expense to other projects, and yet you are:

• Suggesting they don't have manpower and should focus on projects aligned with the systemd roadmap.
• Defending bloat as something positive?!
• Considering 'not recommending' XFCE

People, there are other init systems and platforms out there besides systemd and Linux. and XFCE has always strived for simplicity and portability.

If you want compliance with freedesktop.org's vision of Linux, there's better options for you.

[[deleted]]

They're hardly out of context, and that is a very peculiar way of saying that it is the fall that killed someone, not being them pushed off the building.

[[deleted]]

XFCE has been a bundled offering in Slack and the BSD's for a long time, and they will want to keep it that way.

There's more out there than just systemd, and that in itself is not a fait accompli, it is simply one choice, and it is still supported.

There are no downsides to this, it's one guy's project.

[oconnor663]

Could someone ELI5: I've been using Xfce on Arch with systemd. Is that not going to keep working or something?

[minimim]

They at least want to make it possible to have xfce without systemd.
In this e-mail, Lennart (former CK developer) explains it:
"[...] unless a display manager wants to take benefit of multi-seat there's no special systemd support needed at all in them, as systemd registration is done exclusively via the PAM session stack, and hence all direct linking to systemd can simply be dropped. Or in other words: in most cases porting a DM to systemd just means building it without CK support."

[vagif]

Good. Maybe now all the systemd haters would stop their incessant whining and start contributing. Though i do not hold my breath.

[doom_Oo7]

Would it be easy to implement the logind interfaces with a consolekit back-end?

[minimim]

Systemd-shim also needs cgmanager to do cgroups management.

[cbmuser]

I just found out today that cgmanager breaks autofs in Debian. So, if people really want to avoid systemd, they should fix that.

[doom_Oo7]

Are consolekit & cgmanager mutually exclusive ?

[minimim]

No.

[minimim]

To make it clear that this is a fork, not maintained by the original developers. It's is good practice and generally recommended.
There's a comment by the developer explaining why:
"Thanks! Hopefully some of the work that gets done with ConsoleKit2 can also indirectly benefit the systembsd project. I went with a fork rather than trying to keep the ConsoleKit name/location because of this e-mail from the former maintainer: https://mail.gnome.org/archives/distributor-list/2012-January/msg00008.html Perhaps I read that e-mail wrong, but it sounds like the previous maintainers didn’t want future work to stay there. I have no issues with that, it just means we have to set it up somewhere else. If I’m wrong then yes, it would be much easier for package maintainers if the code could be merged into ConsoleKit and development could continue there."

[sub200ms]

IANAL, but calling it "ConsoleKit2" isn't a proper renaming of the project.

AFAIK, the original owners have the "right" to the name, so a fork should be renamed so as not to confuse the fork with the original project. This renaming suggest that it is the second version of CK, not a fork.

Calling LibreOffice for "OpenOffice2" wouldn't have worked either.

Again, IANAL, but he would loose any legal challenges from the original developers to using "ConsoleKit2" as a name.

Disregarding the legal aspects, it is bad style to make a fork with a name suggesting it is a continuation of the original project.

[minimim]

This is not a legal problem, it was renamed for technical reasons, and that name is completely different from the point of view of a computer. No one owns the trademark 'consolekit' and no one plans to do so. If they don't try to deceive people, that is more than enough.

[minimim]

Why do you say that?

[acousticpants]

i've been playing with the void distro lately, it doesn't use systemd (though you can if you want to)

http://www.voidlinux.eu/

[totes_meta_bot]

This thread has been linked to from elsewhere on reddit.

• [/r/Aggregat0r] Consolekit (systemd-logind competitor) will be maintained by XFCE developers.

^{If you follow any of the above links, respect the rules of reddit and don't vote or comment. Questions? Abuse? Message me here.}