This post represents my personal opinion. It does not need to represent any official opinion from any association I am involved with.
The Readme of the KDE Plasma Workspaces states clearly that our desktop is an X11 desktop environment:
KDE Workspace consisting of what is the desktop. The applications and libraries included aren’t required to b e portable and probably will only work with X11. On other desktops such as OS X and Windows, users wouldn’t r un these applications, but use the native ones instead. The typical application shouldn’t have dependencies i n workspace unless they are a component such as a screen-saver or panel applet.
So what does that mean? Our base system should work on every operating system supporting X11. Be at Linux, FreeBSD or Solaris. But how does the world look like, is this still the truth?
The world around us is changing and I would say that the statement is no longer true and soon needs to be adjusted to also include Wayland. This shows that we are at the point thinking beyond the X Windowing System. So what does that mean for the operating systems we support? At the moment Wayland is a Linux only system and given the current requirements it looks unlikely to be supported by non-Linux systems any time soon.
Wayland is of course only one example. There are more. Think about the deprecation of HAL or introduction of systemd. HAL we are still able to support in KDE thanks to our good hardware abstraction through solid. Systemd is not yet used, but I hope that this will change soon. Given these changes we must face the from a technology point of view all non-Linux are far behind Linux which means that on the long supporting the legacy technologies only for non-Linux becomes more and more a hurdle.
Personally I do not know any core developer of the KDE Plasma Workspaces using a non-Linux operating system. So you would expect that we have lots of bug reports for the non-Linux OS. Given that we already have hundreds of bug reports in KWin just about the stack on Linux which we use, there have to be even more for the non-Linux systems. No dev uses it, it gets not as tested as our Linux system, so there have to be bugs! So here the stats for KWin over the last 12 month:
- Linux: 1054 opened bugs
- FreeBSD: 4 opened bugs
- Solaris: 3 open bugs
All three Solaris bugs are actually build errors on Solaris containing patches – they should have been opened on reviewboard. Due to miss of quality non of the patches was included in the software. From the four FreeBSD bugs, two are crashes lacking debug symbols – something that does not happen on Linux any more. One bug was actually also present on Linux, but seemed to only apply for legacy technology. So we have something like 250 bug reports for Linux for each non-Linux bug report.
For Plasma it’s 3529 bug reports for Linux compared to 30 non-Linux (only X11). From the seven Solaris bugs, six are again build failures. FreeBSD are mostly crashes again with missing backtraces and so on.
So this tells us that basically Solaris does not have any users and that it only creates work for us, because they use different compilers. Nevertheless we do not seem to accept the patches. So it’s great that Solaris wants to provide packages for our workspaces, but it should not create work. And yes reporting a bug and discussing it and even rejecting a patch is creating work.
And there is more we have to consider: KDE Plasma Workspaces are nowadays more than a set of applications for X11. It’s an integrated system providing a consistent user experience. Important parts of this experience is also our Oxygen design which does not only require compositing but also advanced OpenGL effects such as the Blur filter. Unfortunately free drivers are not able to provide these requirements on non-Linux systems due to lack of KMS and Mesa frozen at the last version before KMS. What we provide for non-Linux does not match what we want to provide.
The free desktops still have a considerably small market share, but as also the bug reports show the non-Linux users make less than one percent of our user base. If we now think about the global market share for non-Linux KDE Plasma systems we come to a number very close to 0. Our resources are spare and we should make the best out of it. Spending time on hardly used systems which are lacking behind in the technology we want to use and cannot provide the minimum requirements for our workspaces, does not sound like a sane idea to me.
To me it is clear for quite some time already that I won’t accept patches any more for non-Linux. Including another code path or even a build flag for non-Linux systems is not worth the increasing maintaining costs. If non-Linux systems want to include patches they should do it downstream.
Also for the inclusion of new technologies we should not wait for the non-Linux to catch up or do sacrifices in order to still support non-Linux. If a new technology brings us great advantages on Linux but means we have to stop supporting non-Linux because they do not provide the technology, I think it’s better to be really good on the one system.
Please remember: this is my personal opinion.
You are perfectly right.
Being effective is very important.
sorry, i meant efficient
I guess both apply 🙂
I really hope that what you said will become kde guidelines, because in my opinion if linux want to be competitive in the desktop and business market it needs to cut out old stuff.
I understand that it is burdensome to support non-kms setups, and I could even agree it is the right call. but what about prop. driver blobs like nvidia?
Also, compilers on Linux tend to be to accepting, so the build failures I’d recommend that you pay attention to, as even if gcc accepts the code, it’s probably far from best practice.
Thinking about portability often makes code more modularized, which will be a good thing when the next change in tech comes around.
If it is an actual real error things get fixed. But that is hardly any time the case. Mostly its some headers missing on non-Linux.
I think your definition of what is “non-Linux” is a bit limited.
Take Clang/LLVM for example: FreeBSD will be the first fully FOSS system to adopt it as default compiler but some Linux distributions will likely follow – especially in the embedded/ARM sector.
Maybe we’ll end up in a world where all Fedora variants will be compiled with GCC, all MeeGo variants with Clang, and Ubuntu x86 with GCC and Ubuntu ARM with Clang.
FreeBSD is actually the technology avant garde in this case.
While I understand your concerns about legacy technology, the GNU grip on compilers in the FOSS world (and in turn the introduction on countless non-portable GNU-isms to the code) more than once actually caused competing compilers to be held back.
IMO especially FreeBSD is an area where its commercial distributors need to take responsibility. PC-BSD is a commercial FreeBSD distribution that ships KPW as default. So it’s in their interest to get a person maintain FreeBSD support upstream and not pass the workload to unpaid volunteers. Same with *Solaris: If they are interested to have KWP, Nexenta Systems and Oracle should assign a person to maintain the work upstream.
What’s wrong with accepting patches for compiler fixes? Shouldn’t those be upstreamed by default? For the rest, fully ack that developer effort should be focused, and +1 for what Marcus said.
ifdefs clutter the code. Reviewing even small patches and integrate it takes time. Just testing one patch is at least ten minutes. If there is no benefit for the software it is just wrong doing it in the first place
Compiling code is a benefit for the software 🙂
Sorry, but I’m going to do the slippery slope argument here: “KDE is an environment for Fedora 16 on x86-64 with ATI graphics” because non-rpm is too burdensome to support; developers don’t have non-x86 anyway; and ATI has better code for the kind of compositing we use.
Is that really where you want to go?
Don’t forget that the smaller OS communities tend to *first* try to fix the bugs inside their own packages or by upstreaming things directly. You may get fewer bug reports because the reports are filtered first. I know I wouldn’t rush off to KDE bugzilla with a FreeBSD or OpenSolaris problem before confirming that it’s not something caused by the platform itself.
I’ll grant you that KDE on Solaris has very few users. That’s partly because it’s such a pain in the ass to get KDE to build at all and packages lag. That, in turn, is because the goalposts keep getting moved by the folks on Linux ignoring other OSsen. Regardless, porters carry on. You then get patches to fix up assumptions that end up in the code — assumptions which don’t apply on other OSsen now, but you can be darn sure that at some point, the assumptions will change for you on Linux as well.
What will your answer be when (hypothetically) a compiler stops shipping C++ support at all and tells you “C++ creates too much work”?
You might not remember “all the world’s a VAX”, but it was the Solaris port (and the DEC Alpha port) of KDE a decade ago that finally got rid of the assumption that “all the world’s 32-bit”.
of course it’s not black and white.For the applications and libraries being multi-plattform seems fine also to me. But here I only question the workspaces. We always have to carefully consider what we want to achieve.
If “the KDE Desktop” doesn’t run there then that also hits the libraries and apps on such platforms. You get lesser developers, lesser testing and lesser patches for your libs and apps for such platforms.
The dependency to the KDE-stack your app may still have would become more expensive. A port to Qt-only could restore portability and solve bunch of problems the users of your app may face with such unsupported platforms.
Most of those 1000 reported KWin bugs are crashes from – guess what – Linux drivers! So if you let me interprete your reasoning, should we stop supporting KWin on Linux, because nearly every crash report “creates work for us” (looking at backtraces, closing as duplicates)?
That’s of course a serious issue for KWin, but Plasma with much more crashes from Linux does not have the driver problems. The issue for the many duplicates is a lack of DrKonqui which allows to report even if there are clear duplicates. The crash reports coming from FreeBSD (even when reported through DrKonqui) are just useless due to missing debug symbols. So these are different issues.
You’re right with this! These are exactly the same reasons, why Lennart won’t include support for non-Linux OS’es in systemd.
On Debian we had a veeery long discussion, whether systemd should be accepted as default, as this would create very much for for the kfreebsd and hurd ports of Debian. (and we still don’t have a decision yet)
But IMHO our goal should be to deliver the best user experience and the best technology possible, and if other OS’es don’t support the stuff we’re focusing on, waiting for them or supporting them would only create much pain. So it’s better to go forward and let other OS’es catch up.
Of course, cross-platform support is a good and important thing, but there are always some cases where it only does harm.
The GNOME devs are going in a similar direction, this is exactly what “GNOME OS” is about.
(And IMO, Debian will have to adopt systemd to not loose track with other distros)
— just my opinion 😉
Yes and I fully agree with Lennart on not including non-Linux OS in systemd. And I hope that Debian will decide for systemd and the motivation for this blog post was mostly systemd with both Debian and KDE in my mind 😉
The Debian Technical Committee will have to decide whether systemd will be default or not. (This is way to controversial in the Debian community, maybe even a General Resolution is needed)
But I also hope systemd will become default, and if you look at upstream development, everyone is ging towards supporting Linux as primary platform.
Speaking to GNOME devs at DS, one of the things they don’t understand about KDE is the “one abstraction layer over the next abstraction layer” policy – for them, this is a broken wheel, since with abstraction, you’ll never be able to support all features an interface can provide. They even outlined to me why this can be completely stupid sometimes.
And I must admit – while I was pro-Linux-only before already – they convinced me that abstracting everything is indeed a problem sometimes.
I’d say that “one abstraction layer over the next abstraction layer” is a huge exaggeration and usually comes from not understanding the respective technology at all.
Take for example Solid: how many GTK based application developers do you think have been using HAL’s D-Bus interface directly vs. how many were using the libhal abstraction layer?
Why would using a different abstraction of the same D-Bus interface be another layer?
Oh, and maybe they could tell you how good that abstraction worked out for them when HAL daemon was deprecated. How good does libhal deal with all the upower/udisk things?
While I like a lot of GNOME stuff, their attitude in that case is just stupid. To this day PulseAudio is basically alpha software and GNOME depends on it.
Similar situation with GStreamer: Here it crashes all the time. Thanks to Phonon I can just use VLC as back-end.
I totally agree with Martin!!!!!! …and Lennart 😉
Yes, ifdef are bad, but if bell labs could write plan9 without a single ifdef for endianness, then there should be hope for other projects as well.
Regarding systemd: Everyone seems to think lennart right on Linux only support, but I wonder: did he even contact anyone in the respective communities to see if they might be interested in collaborating on it?
I now guess that speed critical kwin components will be handcrafted assembler for amd64 since that’s the only relevant platform nowadays…
You should have noticed that I care how code looks like or why else would I be against useless ifdefs? So do you really think I would consider assembler code to be allowed to go in (apart from GL ARB assembler)?
So my post might have been a little provocative 😉
Anyway, some questions are still left unanswered though:
What about linux-non-kms drivers? Should they be dropped as well?
As someone pointed out, kms is coming to at least fbsd, and there was talk about adding it to osol as well. Would you still consider dropping those platforms from kwin?
I have given up on Non-Linux X11 desktops. They are just too much hassle.But I would love to know what the PC-BSD guys are saying.
I as a user fully support a Linux,Qt5,KMS,Wayland,systemd future and can’t wait to see it become a reality. OSX and Windows are not sleeping and Linux has to stay in the game. KDE as a community should decide what is best for its users. I hope they have the courage to make hard choices and communicate them correctly.
And what about this project?
http://windows.kde.org/
Personally I think that using human resources for this project instead of working for KDE to run even better on Linux, is a waste of time and resources.
This is about the KDE Frameworks and Applications. As explained in the introduction of my post the KDE Plasma Workspaces are only for X11. My complete post was only about the Workspaces. For KDE Frameworks and Applications I consider it as important to further continue to support multiple platforms.
I think you didn’t fully think it through.
The chances of MeeGo completely failing are not small. Does that mean that Plasma Active should be killed in that case as well?
Personally I think that it would be wise to consider Plasma Active as an alternative Android shell as well as the possibility of Plasma Active on top of Windows kernels.
So – focusing on Linux only stuff might be the way to go – Gnome is doing the same more or less.
Though what’s missed on Linux (and the Linux only stuff) is something to rely on. First you got devfs, then a bit HAL, then Udev etc. etc. – with ever changing things in the background how can you expect other systems implementing the things you want to rely on ?
Some other systems are maybe – due the lack of manpower – busy enough with their OS core and just don’t have the time implementing API’s to be Linux-conform which – when done – will change again.
If there would be finally something stable, for some years, then other systems might get the chance to implement it as well.
Very good point indeed!
When HAL came around its developers used a similar reasoning, i.e. that one didn’t have to port HAL itself but just needed to provide the same D-Bus interfaces on whatever the target platform used.
Anyone know how the implementation of the HAL D-Bus interface on top of all the u* services is coming along?
Udev has been around for 8 years now, and there’s no sign it’ll ever be replaced. So why don’t you just stop whining and shut the fuck up?
Ah – how sweet some bad words must be.
So – Udev is around since years – how long is it widely supported and used by software like KDE, Gnome or XFCE ?
Would you like to port things – if even possible – that have basically no practical usage ?
Even systemd is at the moment not widely adopted, it’ll be maybe, maybe not.
And don’t you think non-linux OS developers have other things to do than porting Linux-only software that may have changes, which will break the entire port, or maybe is never widely adopted ?
I think the people should try another OSes before say “any non-linux OS is a crap and it’s lacking technology”. Take udev by example: the project start was in 2003 but distros are really only using it about 2 or 3 years ago. FreeBSD has devd which does the same work (at least for what I use), but the project is more older and rock solid.
KMS is being ported do FreeBSD and will be ready in some months I think.
I hope the devs think with careful and love not only about support others Unix-like OSes, but support inside linux world. Not all distros are happy with whole “keeping changing all the way to do things in desktop every 2 years”.
Don’t get me wrong, I use GNU/Linux (mainly Arch Linux and Slackware) and FreeBSD both in desktop, laptop and servers and both OSes/distros has their strenghts and weakness and no one will satisfy all users.
Dude, get a clue. I used udev on gentoo something like 6 years ago, and it was the default back then. And udev has been used for a similarly long time on other distros too.
In terms of user numbers, you should also drop Linux support and concentrate on KDE on Windows.
The Linux desktop is dead. Face it!
This post was about workspaces and KDE does not offer a workspace for Windows. So sorry, your suggestion does not make any sense.
Please note that we provide more workspaces than just a desktop, so even if the Linux desktop were dead (seems quite alive here) there is no reason to stop developing other non-desktop workspaces.
Actually that is not true. KDE offers a Workspace for Windows: http://www.youtube.com/watch?v=Kn1vT4Z9Fx8
It may not be that mature but it works as the video shows.
no, it is not. No Plasma developer works on providing a workspace for windows. That it compiles and runs does not mean that there is an official support for it. e.g. where is kwin on windows?
It’s not dead. It’s Linux birthday that takes, too long. 😉
However, your analogy is completely wrong. BSD, Solaris existed long before Linux and it’s Linux that almost killed them. The same Linux will do with Windows, but its market is quite different, because it’s not about technical superiority only. It’s also about convincing third party members that they should write software for Linux.
Windows is loosing market share and Linux + Wayland + Desura (or better Steam in the future) has a chance to become much more popular than it’s now. With KDE and Gnome being focused on Linux, Linux’ chances will be much greater.
I fully agree with you.
If only this was an official KDE guildeline
Drop Windows and Solaris Support, keep Linux and FreeBSD.
I am using Linux also on x86- and Arm-Hardware with graphiccores only supported by the X11’s vesa driver, without working support for KMS or OpenGL, do I have to switch to another desktop environment, too, if those changes will be made?
What KDE seems missing is a builtbot, because KDE nurtures the fiction that it does not provide binaries. Of course compiling under as many environments as possible makes code better. I don’t see a reason why Solaris and FreeBDS should not be a target built then. Once you have a builtbot its easy to reject patches in an early stage when they break functionality. I also don’t understand why the number of krazy2 issues in the code base increases. For build issues no one should file a bug, it should result in automated rejection of the patch.
There is a dashboard where people can upload build results of current svn. e.g.
http://my.cdash.org/index.php?project=kdepimlibs&date=2011-08-29
I used to upload there Solaris build results while we still had a powerful build machine.
However it seemed to be just as ignored as krazy warnings.
Also since the great git disast^wmigration there doesn’t seem to be many people there.
krazy warnings are not ignored (by me). I set up my own CI system which generates krazy reports for me, so that I can see and fix new upcoming warnings.
ok, so software editors are perfectly right to ignore linux, because linux is only 1% of the market !
Even, if this is understandable and logical… This kind of reasonning is sad … :\
don’t think in percent but in number of users. The market share of Linux is big enough to be interesting for software developers.
It’s not about %, there are no users in Numbers on other Operating Systems… They really shouldn’t waste their resources where it’s not needed…
That’s the same thing Gnome was talking about if I’m not wrong. And I was waiting for this moment to arrive, when the best Linux desktops realise that they should concentrate on 1 OS where the user base is actually and make it really great for that 1 OS.