Plan to get rid of ConsoleKit in GNOME 3.14
Before the start of the GNOME 3.14 cycle, Ryan Lortie announced his intention to make most GNOME modules depend on a logind-like API. The API would just implement the bits that are actually used. According to Ryan, most GNOME modules only use a selection of the logind functionality. He wanted to document exactly what we depend on and provide a minimal API. Then we could write a minimal stub implementation for e.g. FreeBSD as we’d know exactly what parts of the API we actually need. The stub would still be minimal; allow GNOME to run, but that’s it.
Not done for GNOME 3.14. Needs urgent help.
As didn’t see the changes being made, I asked Ryan about it during GUADEC. He mentioned he underestimated the complexity in doing this. Further, his interests changed. Result: still have support for ConsoleKit in 3.14, though functionality wise the experience without logind (and similar) is probably getting worse and worse.
Systemd user sessions
In future I see systemd user sessions more or less replacing gnome-session. The most recent discussions on desktop-devel-list indicated something like gnome-session would still stay around, but as those discussions are quite a while ago, this might have changed. We’re doing this as systemd in concept does what gnome-session does anyway, but then better. Further, we could theoretically have one implementation across desktop environments. I see this as the next generation of the various XDG specifications.
Coming across as forcing vs “legacy”
From what I understood, KDE will also make use of user sessions, logind, etc. However, they seem to do this by calling the existing software “legacy” and putting everything into something with a new name. Then eventually things will be broken of course. Within GNOME we often try to make things really clear for everyone. E.g. by using wording usch as “fallback”. It makes clear our focus is elsewhere and what likely will happen. I guess KDE is more positive. It might still work, provided someone spends the effort to make it work. In any case, the messaging done by KDE seems to be very good. I don’t see any backlash, though mostly similar things is occurring between GNOME and KDE. There are a few exceptions, e.g. KWin maintainer explicitly tries to make the logind dependency as avoidable as possible. I find the KDE situation pretty confusing though; it feels uncoordinated.
Edit: At least the user session bit in KDE is undecided. It was talked about and seemingly agreed between two well known KDE people, see here, but still undecided. Same person clarifying this requested that I clarify that I’m not from KDE. I am not from KDE.
Appearance that things work fine “as-is”
In a lot of distributions there is still a lot of hacks to make Display Managers, Window Managers and Desktop Environments work with the various specifications and software written loads of years ago. Various software still does not understand XDG sessions. They also do NOT handle ConsoleKit. Distributions add hacks to make this work, doing the ConsoleKit handling in a wrapper.
This is then often used in discussions around logind and similar software.
“My DM/WM/DE is simple and just works. There is no problem needing to be solved.”
There are various distributions which have as goal to make everything work, no regressions are allowed. If you use such a distribution and given enough manpower, enough hacks will be added which on short term ensures things work. However, those temporary hacks are hacks. E.g. if some software should support XDG sessions and it does not, eventually the problem is with that software.
Looking at various distributions, I see that those temporary hacks are still in place. Especially funny one is Mageia, where XDG session support is second class. The XDG session files are generated from different configuration files. This results in fun times when a XDG session file changes. Each time this happened, the blame is quickly with the upstream software. “Why are they changing their session files, it should just never change”. While the actual problem is that the upstream files are thrown away!
The support for unmaintained software has at various points resulted in preventable bugs in maintained software. While at the same time the maintained software is considered faulty. I find this tendency to blame utterly ridiculous.
Aggressive anti-advocacy
There are many people who have some sort of dislike for systemd. In the QA session Linus had at Debconf, he mentioned he appreciates systemd, but the does NOT like the bughandling. In various other forums I see people really liking systemd, but still having their doubts about the scope of systemd.
When either liking or disliking systemd, it is important to express the reason clearly and in a non-agressive way. Unfortunately there are a few people who limit their dislike in ways that’ll result in them being ignored completely. Examples are:
- Failure to understand that a blank “you cannot rely on it” statement is not helpful
If a project sees functionality within systemd that is useful, it is you’ll not get very far with stating that the project is bad for having used that. Or suggesting that there is some conspiracy going on, or that the project maintainer is an idiot. That’s unfortunately often the type of “anti-systemd advocacy” which I see.
- Failure to provide any realistic alternatives
Suggesting that systemd-shim is an alternative for logind. It’s a fork and it took 6 months or so to be aligned with latest systemd changes. Further, it’s a fork with as purpose to stay compatible. It’s headed by Ubuntu (Canonical) who are going to use systemd anyway.
The suggestions are often so strange that I have real difficulty summarizing them. - Continuous repeat of non-issues
E.g. focussing on journald. Disliking e.g. udev or dbus, confusing the personal dislike as a reason everyone should not use systemd.
- Outright false statements
E.g. stuff “systemd is made only for desktops”, “all server admins hate it”. If you believe this to be true, suggest to do your homework. That, or staying out of discussions.
- Suggesting doom and gloom
According to some of the anti-advocacy, there’s a lot of really bad things in systemd. A few examples: my machine should continuously corrupt the journal files, my machine often doesn’t boot up, etc. As it’s not the case, such a claim pretty much destroys any credibility they might have had with me.
Anyone trying systemd for the first time will also notice that it’ll just work. Consorting to this type of anti advocacy will just backfire because although systemd is NOT perfect, it does work just fine.
- Lack of understanding that systemd is providing things which are wanted
Projects have depended on systemd because it does things which are useful. As a person you might not need it. The other one believes he does need the functionality. Saying “I don’t” is not communication. At least ask why the other believes the functionality is useful!
- Lack of understanding that systemd is focussed to adding additional wanted functionality
Systemd often adds new functionality. A large part of that functionality might have been available before in a different way. It’s something which most people seem to worry about. It’s usually added as a response to some demand/need. Having a project listen to everyones needs is awesome!
- Personal insults
This I find interesting. The insults are not just limited to e.g. Lennart, the insults are to anyone who switched to systemd. A strategy to of having people use something other than systemd by insulting them is a very bad strategy to have. Especially if you lack any credibility with the very people you need and whom you are insulting.
- Failure to properly articulate the dislikes
There are too many blank statements which apparently has to be taken as truths. Saying that something is just bad (udev, dbus, etc) will be ignored if the other person doesn’t see it as a problem. “That systemd uses this greatly used component is one of the reasons not to use it”. Such a statement is not logical.
- The huge issues aren’t
Binary logging by journald. Anti-advocacy turns this into one of the biggest problems. The immediate answer by anyone is going to be that you can still have syslog and log it as you do now. If you advocated this as a huge issue, then anyone trying to decide on systemd will quickly see that this huge issue is not an issue at all.
The attempt is to make people not use systemd. In practice, if the huge issues aren’t an issue, then the anti advocacy is actually helpful to the adoption. The biggest so called problems are easy, so anyone quickly gains confidence in systemd. Not what was intended! - Outright trolling
For this I usually just troll back 😛
What I suggest to anyone disliking systemd is to not make entire lists of easily dismissed arguments. Keep it simple (one is enough IMO), understandable but also in line with the people you’re talking to. Understand whom you’re talking to. Anything technical can often be sorted out or fixed, suggest not to focus on that.
Once the reason against is clearly explained, focus upon what can be done to change things. Here the focus should be on gaining trust and give an idea on what can be done (in a positive way).
Don’t ignore people who dislike systemd
Due to having seen the same arguments for at least 100 times, it’s easy to quickly start ignoring anyone who doesn’t like systemd. I’ve noticed someone saying on Google+ that the systemd should not be used because Lennart is a brat. Eventually enough is enough and it is time to tell these people to STFU. But that’s not according to one part of the GNOME Code of Conduct, “assume people mean well”. Not believing in people meaning well and ignoring it has bitten me various times.
Turns out, this person is concerned that his autofs mounted home directories won’t be supported some time in the future. So this person does follow what Lennart writes. While it appeared to me he’s just someone repeating the anti-advocacy bit, he has a valid concern. I still think it is unacceptable to call people names and said so, but it
is equally important to ensure things are still possible.
Can a “not supported” still be made to work?
Systemd developers are quick to point out that something is not supported. E.g. a kernel other than Linux. A libc other than glibc. Some use cases are not. But there’s a important thing to know: would the usecase be impossible, or would it take way more effort?
The type of effort is also important. For a different kernel/libc, you’d need a developer with good insight into these things. For others, it might be possible by customizing things. I assume the autofs homedirs will always be possible, just not always taken into account.
If it is not supported but can be used anyway if you’re an “ok” sysadmin, that’ll mean for most people it’ll be possible. A “not supported by systemd” does therefore not 1 on 1 relate to impossible. If you want a different libc but you’re are a sysadmin and not a developer that’s quickly seen as impossible. While another “not supported” is actually perfectly possible.
IMO it is good that not everything is supported. Ensure that whatever is supported works really well. But at the same time, I think more focus should be on ensuring people do understand that a “not supported” does not mean “cannot work”.
My opinion on systemd as a release team member
I like *BSD. I like avoiding unneeded differences, this easies portability.
There are some interesting tidbits I’ve learned. Apparently OpenBSD has a GSoC student working on providing alternative implementations for hostnamed, timedated, localed and logind. I don’t think it’s enough, because it needs to be maintained fully. I further think that a logind alternative cannot be written together with the other bits during just a summer. Whatever it is, I think this will make it even easier to use systemd. This is not what some of the anti-advocacy is intending to happen. Oh well.
There seems to be another round of (temporary) increase of people disliking systemd. I’m pretty sure it’ll quiet down to normal levels again once Debian has systemd in a stable release for a few months.
Eventually they’ll notice that although systemd is not perfect, it just works. Unfortunately, this all doesn’t help in with the concerns I still have.
What to do with ConsoleKit?
“From what I understood, KDE will also make use of user sessions, logind, etc. However, they seem to do this by calling the existing software “legacy” and putting everything into something with a new name. Then eventually things will be broken of course. ”
Can you provide some sources on where you read this? I’m fairly sure this is not what you describe.
I wouldn’t be surprised if I had that entirely wrong.
I heard or read it during GUADEC, then discussed it during GUADEC. I tried researching this, but failed to get any meaningful information. I also don’t quite understand how the support will be kept optional. Is it some sort of trade off? E.g. duplicating code / relying on unmaintained software / what? How would you otherwise properly deal with multi session and multi seat support?
I did find some systemd stuff: https://github.com/eliasp/plasma-workspace-units
How relevant it is, no clue.
That work is indeed in early stages, to support systemd user sessions, but IIRC it still needs on something being implemented in systemd before it can be actually usable.
As for the rest, so far there has been discussion but most of it has been informal, to my knowledge, nothing set in stone, and no discussion of “legacy” whatsoever.
You’re misrepresenting KDE here.
We do not have concrete plans for a systemd-based session right now. There has been some discussion, some proof-of-concepts, but as we have more infrastructural construction sites right now (just moved to a new major version, Wayland coming up, etc.), we haven’t gotten around to this topic.
We’re certainly not planning to leave users in the cold, mindlessly moving onto systemd without paying attention to current usage scenarios.
The conclusion you’re taking (“everything will be broken of course”) seems utter nonsense to me, and I think you’d do yourself good if you rephrased it. It would also show more respect towards your Free software peers, and alleviate the impression that you’re just taking an opportunity to make ungrounded rants about something you do not have any reliable information about.
Next time, if you’re unsure, before trash-talking, find me or someone from our team, so your information is more informed. Or, barring that, maybe don’t mention it, if you don’t know.
I’m not trash talking, I think you’re being overly sensitive?
I mentioned in the post I said it felt uncoordinated because I have no clue whom to contact. It’s not clear and I mentioned as such. I also mentioned “from what I understood” to ensure that it is clear I’m not sure. Further, the intention of the paragraph is not to complain about KDE, it is to highlight that there are differences.
Regarding trash talking: “We’re certainly not planning to leave users in the cold, mindlessly moving onto systemd without paying attention to current usage scenarios.”
I’m not sure, but it seems you’re suggesting that GNOME does that, which to me comes over as trash talking. Then asking not to trash talk?
Regarding that it’ll degrade: My genuine concern is for instance ConsoleKit. It’s not maintained, so if you’re using that now, it’ll get more broken. There are various other infrastructure bits that get more and more broken if you are not using systemd. I’d like to know how that’s dealt with. Because unless something is done, it’ll be worse experience. And it doesn’t really matter who causes it, I’m after the user experience.
I have talked to the GSoC student, and he said that hostanamed was in a nearly complete state (i.e. needs porting and to be checked for any memory leaks with gdb), while timedated and localed were just a stubs. He also said that logind was going to be more difficult (perhaps if he heard from KDE, GNOME, Enlightenment, etc. what they actually *needed*, it would be a little easier).
He did say that he would continue to work on it past GSoC.
Hopefully once I finish my SAT’s I can help with porting and testing.
For anything other than logind, the work should be doable IMO.
Regarding logind requirements:
I was expecting that to come out from Ryan. I cannot find the discussion with Ryan archived anywhere (regarding 3.14 plans). I’d prefer giving you a link (we usually ensure discussions are logged, so bit surprised I cannot find it). It was a result of the following blogpost: http://blogs.gnome.org/desrt/2014/02/19/on-portability/
In brief from what I recall: GDM is troublesome. Probably need to do something special in GDM. All other modules are more simple in their usage. Though IIRC modules sometimes use a library which then expects the logind dbus API.
Please also read the comments he made in his blogpost. I’m wondering if I also spoke to him about it, but could’ve only been at FOSDEM, and the blogpost is dated after FOSDEM.
I personally I’m ok with ensuring our usage is limited as to ensure portability. Don’t really see anyone within GNOME spending time to figure things out (lack of interest or ability). For me I’m not able.
The OpenBSD GSOC project is located here: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git
@Luca Beltrame
Sure, see this post by Martin. You can see that Aaron Seigo himself has no problem with Martin’s plan.
https://plus.google.com/115606635748721265446/posts/GMtZrNCeaLD
There is no real plan yet though, these are all informal discussions or side projects. The MLs have been silent on this topic for a while (because there are bigger hurdles to tackle first).
No, not a real plan, but there is definitely an intention, correct? I know you won’t leave people off in the cold, (we aren’t either).
Anyways, thanks for letting me know. I thought you guys were seriously moving to systemd and actually made some headway. In which case, race ya to the finish line. 🙂
Jesus H. Christ. What a bucket of negativity. I realize developers are constantly stuck in a negative feedback loop — but this post is ridiculous. Why even bother to respond to most of these things? systemd is the best thing to happen to Linux in a long time. You should be able to spot the difference between useful feedback and useless doomsaying in about 5 seconds — at which point you can ignore the useless stuff.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
“Ignore the trolls” is bad advice: it sends the wrong message to outsiders. The standard you walk past is the standard you accept etc.
Don’t just ignore them – ban them on sight 🙂
And explain that in general, but there’s no point wasting precious developer’s time on arguing with every misguided idiot out there.
What a load of idealistic nonsense.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
> According to some of the anti-advocacy
I am not anti-systemd (actually i’m a happy systemd user) – but have been suffering the problem
> A few examples: my machine should continuously corrupt the
> journal files, my machine often doesn’t boot up, etc. As it’s not
>the case, …
It doesn’t help to close your eyes and hold your breath – the problem is there – but it is not caused by systemd (see fx: redhat bugzilla #1138315).
The problem is caused by btrfs and heavy fragmentation of files that have incremental updates (like the journal files). And yes, because the seconds used to append to the journal on btrfs – some other services time out and systemd startup is completely broken (no logind, no gdm, etc.) just endless stopping and restarting random services (redhat bugzilla #967521).
The only thing that work is to reset the computer hard and hope you corrupt the journal, so you can have a fresh one for next boot. Otherwise you are stuck again on next boot.
systemd could be a bit more generous and start the debug shell after having failed starting logind a few times or if the boot took more than 5 minutes.
I just reinstalled my system with xfs on lvm (like the old days) – and now I can compile SW, copy files, etc, without the computer freezing. Oh, and also, now firefox doesn’t freeze for seconds when I open a new tab (from the old btrfs filesystem):
$ filefrag .mozilla/firefox/*/places.sqlite
1071 extents found
$ time cp .mozilla/firefox/*/places.sqlite /tmp
real 0m2.955s
user 0m0.000s
sys 0m0.126s
$ filefrag .mozilla/firefox/*/cookies.sqlite
186 extents found
$ time cp .mozilla/firefox/*/cookies.sqlite /tmp
real 0m1.313s
user 0m0.000s
sys 0m0.005s
Oh… So I should STFU.
Thank you for telling me that. Without your input, I would not have known that being critical of a piece of software was not in the realm of acceptability.
(I don’t get the passion people can have for systemd. It looks like cognitive dissonance to me but hey, who am I to speak up? I’m just a user after all so I guess I’m a negligible quantity).
If you read the paragraph, it’s about people who can only make a comment such as “Lennart is a brat”, nothing more. In *those* cases, I *initially* suggest to say STFU. If you read on, you’ll notice that saying STFU is actually bad and I think saying STFU is wrong.
Regarding the comment you just made: Aside from misunderstanding me (can happen), what is your problem with systemd? I don’t understand what you’re after with “cognitive dissonance”, nor with “just a user”. The entire blogpost is a request from people disliking systemd to better articulate what they dislike, combined with a better explanation and better attempt at understanding dislikes.
Regarding being critical: Calling someone a brat is not being critical. It’s being a dick. It’s perfectly possible to be critical without insulting someone.
(BTW, you don’t have to publish this if you don’t want to ; I’m not a monster and I will understand your decision ; but then I’d appreciate if you drop me a mail to warn me of that).
It’s actually a bit more complex than just that. For someone to be the focus of a lot of negative energy from everywhere around the world, it takes some quite solid reasons that are more than probably deeply rooted in the personality of such a person. That clearly doesn’t help to improve confidence on that person’s work. Thus, the personality of a maintainer is going to affect its audience – whether he likes it or not. Successful projects often have a benevolent dictator. Being a dictator doesn’t make you benevolent. Yet, saying “I dislike systemd because I dislike Lennart” is quite inefficient. A better worded sentence is “I fear systemd because I fear Lennart”. And you all know that the expression of fear can be quite violent.
Regarding my “cognitive dissonance” remark: liking something that you know is hurting you is cognitive dissonance. It happens because someone decide to invest part of his energy into something. Once you are in this state, it becomes harder and harder to admit that you’re hurt by the thing you’re investing in. Since I firmly believe that systemd is hurting the Linux ecosystem and since I’m pretty sure everybody with a sufficient technical level knows that something isn’t going well, the cognitive dissonance diagnostic is obligatory.
Some people are going to say “again, he’s bashing systemd without providing any information about what makes him unhappy with this wonderful product”. Given the fact that most of my criticism seems to be in one or another category above – the categories of criticism which is denied any meaning – it’s going to be difficult to argue. So I’d stay with the following : the software architecture of systemd is fundamentally broken, due in large part to invalid strategic choices ; and systemd is an infamous hydra whose goal is unknown and unsure – there is no way to know where it will stop (I do not imply there that systemd is going to do bad things. I simply want to stress out that no process is out of reach for systemd).
* systemd-shutdownd ? (WT…?)
* systemd-timedated ? (I guess no existing NTP client were working well enough)
* systemd-hostnamed ? (let me get that straight: /etc/hostname was too complex. Seriously?)
* systemd-sleep ? (with its “it’s a hack” directory).
* systemd-module-load ? (I guess modprobe was horribly broken)
And I might continue. As of today, I cannot say which part of the system will be integrated into systemd – but I guess the answer is “all commonly available services”. So I guess we’ll see upnpd in a coming release (because It Makes Sense).
That doesn’t mean that systemd is stupid. There are good ideas in systemd – most of them coming from launchd. But these good ideas are not implemented correctly (this is a common problem in many project in which Lennart is involved. He has good ideas. Yet, by some unexplained magic, he’s able to transform all of them into the software architecture equivalent of the USSR bureaucracy – bloated and opaque. One of the last example: kdbus ; good premise, very bad and broken conception).
There is hope for anti-systemd advocates: the embedded world is still largely systemd-free and will remain so for a few years (because, you know, glibc). There is room to implement a modern init system that do not replicate the errors of systemd. But this hope is easily crushed : it might already be too late to compete with systemd on the desktop world. The major distribution already made their choice – and that choice is likely to be definitive if the major desktop UI decides to depend on systemd too. Please remember that having both GNOME and KDE depend on systemd will lock users for a very, very long period – systemd will be virtually impossible to replace at the distribution level. Given that no alternative is going to be used in the foreseeable future, the community has little interest in creating one. It would take a incredible series of equally incredible events to go back to the drawing table.
I’m pretty sure some of you already have labeled the above statement “foolish” or worse. That’s OK. The systemd opponents have been very vocal on the technical and architectural side yet their voice is not heard – so why should mine be?
As I said, I’m just a user. I’m not a developer – and it seems that being one is a sine qua none condition to be audible. I understand that it’s the basis of the open source software meritocracy: those who do are more important that those who use. Yet, the “you don’t do, so shut up” defense being more and more common does not make it acceptable on any ground – especially for projects that care their users.
So let’s state my view differently : some gnome users are unhappy/scared/displeased by systemd and they don’t want to be forced to choose between using GNOME and not using systemd.
Can’t someone consider that as a legitimate concern? What are you going to do for them that doesn’t contain the sentence “There’s a place I know that I’d like you to visit. You’ll find it at the south of Heaven”?
I agree that it’s not an easy choice. On one hand, systemd seems to implement the thing you want. On the other hand, there is no reason why a UI system should depend on the init system. It makes no logical sense. You have the possibility to allow your users to not be locked in – by applying simple design principles : “program to an interface” and “both low level and high level code should depend on an abstraction”. It’s your call.
> Oh… So I should STFU.
Yes. Please. Pretty-please.
Sounds right. I deserved that, as my comment has limited (if any at all) value – although I’m not sure you are the one who should tell me that. But you probably know better.
Indeed it took many months to develop cgmanager and systemd-shim enough to work with recent systemd versions, i. e. >= 205. That was the “big change” which moved cgroup creation into PID1 behind a D-BUS API, and pretty much changed everything on that side. Fortunately now current systemd-shim works with all recent versions, and updating it to e. g. some API changes in 214 was done after a few days only. Plus, the necessary changes to systemd are now much smaller as logind itself does not need to be patched any more.
In summary, while the changes in 205 were a lot of work, it was an one-time transition and made future maintenance/compatibility shims a lot easier to do. This should equally be true for a possible shim for *BSD, as logind now just expects a particular D-BUS interface, and in theory you could even write a shim which doesn’t do any actual cgroup creation at all.
I think you give way too much credit for haters. I mean yepp, constitution and such, assume people mean well and so on – but look at the Debian constitution: I especially like the part about not forcing others to do the job. I’m pretty sure there got to be such thing for Gnome too. You do the job, you do it good or not is of no concren of those who are not ready to step up and do it better. Keep up the good work, choose the API that feels right and don’t give a shit on idiots who’s only contribution is some retarded mockery. Even if they mean well but fail to express it adequately – it shouldn’t be your problem to extract the tiny bits of valid concerns out of stinking pile of hatred. If something fails for haters just because they didn’t bother to submit polite bug report it’s their fault. Be no means you’re expected to cater for people who publickly call the names.
> What to do with ConsoleKit?
What do you mean? What do we always do with unmaintained software which being deprecated for almost a decade already?
What *is* the long-term plan for the BSD folks after the migration to systemd user sessions? I’ve heard plenty of discussion about logind compatibility, but very little about compatibility for systemd user sessions. I really hope such sessions aren’t limited to some least-common-denominator subset for which a compatibility shim can be written. For instance, I’d like to see user sessions using socket activation, bus activation, sandboxing/containerization, etc.
I’m a BSD user and the point is:
Are you a free software community? Are you acting like a community?
If yes, so I need to tell ya we (BSD users and developers) are a free software community TOO and you can’t forget us purposelly!
If no, so keep making GNU/Linux-only software. But interestingly, everything the BSD community creates is always available to other systems as well, OS X, Linux and sometimes Windows. Why you cannot do the same? It seems like Microsoft doing softwares for Windows only, and if we wanted to use a platform-specific software, well, we’d are using M$ softwares.
Think about it.
The problem is that I know of a few BSD people providing patches to GNOME, but we’re totally lacking any developers.
I’ve highlighted ConsoleKit as a problem, what more to do?
One of the items in the Debian social contract is that you cannot demand work from others. GNOME organization obviously is not Debian and GNOME is available to other systems. Maybe GNOME would rely on certain API’s not available on *BSD and it wouldn’t work. It would still be available. We cannot do the same because the things we want to have aren’t available. GNOME should probably do better, but lack of any developers using BSD is a problem. It’s been that way since I’ve been contributing AFAIK. That’s since 2005 or so.
Olav, if you (GNOME team) have not BSD developers you can change that. How? Some options: making a campaing like this slogan “WE ARE LOOKING FOR BSD CONTRIBUTORS” or making the Gnome code as default more generic, it means, more Unix compatible and if the system is Linux so the “fallback” could be systemd and Linux-specific technologies. What you cannot do is to force Linux things for every GNOME user. I’m using KDE now because of internal projects like this: https://freebsd.kde.org/
Please, less Red Hat and more Unix.
“The problem is that I know of a few BSD people providing patches to GNOME, but we’re totally lacking any developers.”
You want more developers? Make a campaign like this: “WE ARE LOOKING FOR MORE BSD PORTERS”. What’s the problem? The argument for this campaign is: “We are trying to bring GNOME for everywhere”. The first step is develop generic code.
I really don’t understand! You claim BSD is old, BSD doesn’t have news features, is very traditional and blah blah blah…but you never have supported ZFS, BE, launchd or others. ZFS has born almost 10 years ago and GNOME and KDE don’t support it!! But I bet that when we are ready to use Btrfs you will be the first to support it saying promotional phrases like “Welcome to the inovative file system”… inovative? revolutionary? This is FUD and a hypocritical attitude!
If you want to bring GNOME for “everywhere”, the first step is generic code. The second is generic to be the default and the specific only for those operating system who uses specific things and JUST IF the users want (like systemd), it means, systemd support should be the “fallback”!
I have installed Debian for my friends what they did? “The sound of linux is so poor, Windows is better” and they returned to Windows. Why? Well, if you haven’t forced the Pulseaudio-only support for us, probably my friends still having Linux :). Pulseaudio is full-featured, but what this mean when the main feature is bad? That’s why Unix philosophy cannot be hurted 😉
I like the idea of Systemd, but as experienced user I dislike its implementation style.
Like how you need to add services, what kind queries are required to be done etc.
I don’t take any part for its technical functionality does it corrupt files or how the development is going etc.
I just care how easily I can configure the system, back the settings up, transfer settings, modify settings etc without ending up reading manuals and guides.
And there, the old fashion INIT just rules out. It was designed to be very simple old fashion in the Unix style (designed for multi-user environments, for networks in tens of thousands computers, high faulty tolerance etc etc).
When looking systemd, it looks like the designer didn’t understand what is so great in Unix “Everything is a file” and “Plain text configuration file” philosophy.
To me it just looks like someone got an idea to implement a WIndows Register to Unix-like systems with good intentions, but just bad implementation.
Sure technically and functional side it can be superior to INIT, but I install and configure Linux system from late 90’s or few years back, that uses INIT without problems, without reading manuals (never have, never will) but Systemd is just like braindead cryptic system.
Why can’t the configurations and data be readable pure text files?