Things are moving forward for the Fedora Workstation project. For those of you who don’t know about it, it is part of a broader plan to refocus Fedora around 3 core products with clear and distinctive usecase for each. The goal here is to be able to have a clear definition of what Fedora is and have something that for instance ISVs can clearly identify and target with their products. At the same time it is trying to move away from the traditional distribution model, a model where you primarily take whatever comes your way from upstream, apply a little duct tape to try to keep things together and ship it. That model was good in the early years of Linux existence, but it does not seem a great fit for what people want from an operating system today.
If we look at successful products MacOS X, Playstation 4, Android and ChromeOS the red thread between them is that while they all was built on top of existing open source efforts, they didn’t just indiscriminately shovel in any open source code and project they could find, instead they decided upon the product they wanted to make and then cherry picked the pieces out there that could help them with that, developing what they couldn’t find perfect fits for themselves. The same is to some degree true for things like Red Hat Enterprise Linux and Ubuntu. Both products, while based almost solely on existing open source components, have cherry picked what they wanted and then developed what pieces they needed on top of them. For instance for Red Hat Enterprise Linux its custom kernel has always been part of the value add offered, a linux kernel with a core set of dependable APIs.
Fedora on the other hand has historically followed a path more akin to Debian with a ‘more the merrier’ attitude, trying to welcome anything into the group. A metaphor often used in the Fedora community to describe this state was that Fedora was like a collection of Lego blocks. So if you had the time and the interest you could build almost anything with it. The problem with this state was that the products you built also ended up feeling like the creations you make with a random box of lego blocks. A lot of pointy edges and some weird looking sections due to needing to solve some of the issues with the pieces you had available as opposed to the piece most suited.
With the 3 products we are switching to a model where although we start with that big box of lego blocks we add some engineering capacity on top of it, make some clear and hard decisions on direction, and actually start creating something that looks and feels like it was made to be a whole instead of just assembled from a random set of pieces. So when we are planning the Fedora Workstation we are not just looking at what features we can develop for individual libraries or applications like GTK+, Firefox or LibreOffice, but we are looking at what we want the system as a whole to look like. And maybe most important we try our hardest to look at things from a feature/usecase viewpoint first as opposed to a specific technology viewpoint. So instead of asking ‘what features are there in systemd that we can expose/use in the desktop being our question, the question instead becomes ‘what new features do we want to offer our users in future versions of the product, and what do we need from systemd, the kernel and others to be able to do that’.
So while technologies such as systemd, Wayland, docker, btrfs are on our roadmap, they are not there because they are ‘cool technologies’, they are there because they provide us with the infrastructure we need to achieve our feature goals. And whats more we make sure to work closely with the core developers to make the technologies what we need them to be. This means for example that between myself and other members of the team we are having regular conversations with people such as Kristian Høgsberg and Lennart Poettering, and of course contributing code where possible.
To explain our mindset with the Fedora Workstation effort let me quickly summarize some old history. In 2001 Jim Gettys, one of the original creators of the X Window System did at talk a GUADEC in Sevile called ‘Draining the Swamp’. I don’t think the talk can be found online anywhere, but he outlined some of the same thoughts in this email reply to Richard Stallman some time later. I think that presentation has shaped the thinking of the people who saw it ever since, I know it has shaped mine. Jim’s core message was that the idea that we can create a great desktop system by trying to work around the shortcomings or weirdness in the rest of the operating system was a total fallacy. If we look at the operating system as a collection of 100% independent parts, all developing at their own pace and with their own agendas, we will never be able to create a truly great user experience on the desktop. Instead we need to work across the stack, fixing the issues we see where they should be fixed, and through that ‘drain the swamp’. Because if we continued to try to solve the problems by adding layers upon layers of workarounds and abstraction layers we would instead be growing the swamp, making it even more unmanageable. We are trying to bring that ‘draining the swamp’ mindset with us into creating the Fedora Workstation product.
With that in mind what is the driving ideas behind the Fedora Workstation? The Fedora Workstation effort is meant to provide a first class desktop for your laptop or workstation computer, combining a polished user interface with access to new technologies. We are putting a special emphasis on developers with our first releases, both looking at how we improve the desktop experience for developers, and looking at what tools we can offer to developers to let them be productive as quickly as possible. And to be clear when we say developers we are not only thinking about developers who wants to develop for the desktop or the desktop itself, but any kind of software developer or DevOPs out there.
The full description of the Fedora Workstation can be found here, but the essence of our plan is to create a desktop system that not only provides some incremental improvements over how things are done today, but which tries truly take a fresh look at how a linux desktop operating system should operate. The traditional distribution model, built up around software packages like RPM or Deb has both its pluses and minuses.
Its biggest challenge is probably that it creates a series of fiefdoms where a 3rd party developers can’t easily target the system or a family of systems except through spending time very specifically supporting each one. And even once a developers decides to commit to trying to support a given system it is not clear what system services they can depend on always being available or what human interface design they should aim for. Solving these kind of issues is part of our agenda for the new workstation.
So to achieve this we have decided on a set of core technologies to build this solution upon. The central piece of the puzzle is the so called LinuxApps proposal from Lennart Poettering. LinuxApps is currently a combination of high level ideas and some concrete building blocks. In terms of the building blocks are technologies such as Wayland, kdbus, overlayfs and software containers. The ideas side include developing a permission system similar to what you for instance see Android applications employ to decide what rights a given application has and develop defined versioned library bundles that 3rd party applications can depend on regardless of the version of the operating system. On the container side we plan on expanding on the work Red Hat is doing with Docker and Project Atomic.
In terms of some of the other building blocks I think most of you already know of the big push we are doing to get the new Wayland display server ready. This includes work on developing core infrastructure like libinput, a new library for handling input devices being developed by Jonas Ådahl and our own Peter Hutterer. There is also a lot of work happening on the GNOME 3 side of things to make GNOME 3 Wayland ready. Jasper St.Pierre wrote up a great blog blog entry outlining his work to make GDM and the GNOME Shell work better with Wayland. It is an ongoing effort, but there is a big community around this effort as most recently seen at the West Cost Hackfest at the Endless Mobile office.
As I mentioned there is a special emphasis on developers for the initial releases. These includes both a set of small and big changes. For instance we decided to put some time into improving the GNOME terminal application as we know it is a crucial piece of technology for a lot of developers and system administers alike. Some of the terminal improvements can be seen in GNOME 3.12, but we have more features lined up for the terminal, including the return of translucency. But we are also looking at the tools provided in general and the great thing here is that we are able to build upon a lot of efforts that Red Hat is developing for the Red Hat product portfolio, like Software Collections which gives easy access to a wide range of development tools and environments. Together with Developers Assistant this should greatly enhance your developers experience in the Fedora Workstation. The inclusion of Software collections also means that Fedora becomes an even better tool than before for developing software that you expect to deploy on RHEL, as you can be sure that an identical software collection will be available on RHEL that you have been developing against on Fedora as software collections ensure that you can have the exact same toolchain and toolchain versions available for both systems.
Of course creating a great operating system isn’t just about the applications and shell, but also about supporting the kind of hardware people want to use. A good example here is that we put a lot of effort into HiDPI support. HiDPI screens are not very common yet, but a lot of the new high end laptops coming out are using them already. Anyone who has used something like a Google Pixel or a Samsung Ativ Book 9 Plus has quickly come to appreciate the improved sharpness and image quality these displays brings. Due to the effort we put in there I have been very pleased to see many GNOME 3.12 reviews mentioning this work recently and saying that GNOME 3.12 is currently the best linux desktop for use with HiDPI systems due to it.
Another part of the puzzle for creating a better operating system is the software installation. The traditional distribution model often tended to try to bundle as many applications as possible as there was no good way for users to discover new software for their system. This is a brute force approach that assumes that if you checked the ‘scientific researcher’ checkbox you want to install a random collection of 100 applications useful for ‘scientific researchers’. To me this is a symptom of a system that does not provide a good way of finding and installing new applications. Thanks to the ardent efforts of Richard Hughes we have a new Software Installer that keeps going from strength to strength. It was originally launched in Fedora 19, but as we move forward towards the first Fedora Workstation release we are enabling new features and adding polish to it. One area where we need to wider Fedora community to work with us is to increase the coverage of appdata files. Appdata files essentially contains the necessary metadata for the installer to describe and advertise the application in question, including descriptive text and screenshots. Ideally upstreams should come with their own appdata file, but in the case where they are not we should add them to the Fedora package directly. Currently applications from the GTK+ and GNOME sphere has relatively decent appdata coverage, but we need more effort into getting applications using other toolkits covered too.
Which brings me to another item of importance to the workstation. The linux community has for natural reasons been very technical in nature which has meant that some things that on other operating systems are not even a question has become defining traits on Linux. The choice of GUI development toolkits being one of these. It has been a great tool used by the open source community to shoot ourselves in the foot for many years now. So while users of Windows or MacOS X probably never ask themselves what toolkit was used to implement a given application, it seems to be a frequently asked one for linux applications. So we want to move away from it with the Workstation. So while we do ship the GNOME Shell as our interface and use GTK+ for developing tools ourselves, including spending time evolving the toolkit itself that does not mean we think applications written using for instance Qt, EFL or Java are evil and should be exorcised from the system. In fact if an application developer want to write an application for the linux desktop at all we greatly appreciate that effort regardless of what tools they decide to use to do so. The choice of development toolkits is a choice meant to empower developers, not create meaningless distinctions for the end user. So one effort we have underway is to work on the necessary theming and other glue code to make sure that if you run a Qt application under the GNOME Shell it feels like it belongs there, which also extends to if you are using accessibility related setups like the high contrast theme. We hope to expand upon that effort both in width and in depth going forward.
And maybe on a somewhat related note we are also trying to address the elephant in the room when it comes to the desktop and that is the fact that the importance of the traditional desktop is decreasing in favor of the web. A lot of things that you used to do locally on your computer you are probably just doing online these days. And a lot of the new things you have started doing on your computer or other internet capable device are actually web services as opposed to a local applications. The old Sun slogan of ‘The Network is the Computer’ is more true today than it has ever been before. So we don’t believe the desktop is dead in any way or form, as some of the hipsters in the media like to claim, in fact we expect it to stay around for a long time. What we do envision though is that the amount of time you spend on webapps will continue to grow and that more and more of your computing tasks will be done using web services as opposed to local applications. Which is why we are continuing to deeply integrate the web into your desktop. Be that through things like GNOME Online accounts or the new Webapps that are introduced in Software installer. And as I have mentioned before on this blog we are also still working on trying to improve the integration of Chrome and Firefox apps into the desktop along the same lines. So while we want the desktop to help you use the applications you want to run locally as efficiently as possible, we also realize that you like us are living in a connected world and thus we need to help give you get easy access to your online life to stay relevant.
So there are of course a lot of other parts of the Fedora Workstation effort, but this has already turned into a very long blog post as it is so I leave the rest for later. Please feel free to post any questions or comments and I will try to respond.
Redhat seems to acknowledge the problem, but is not brave enough to really adress it. There is a simple solution to the GUI toolkit and software installation issue (from a developers perspective) : abandon GTK+ and rpm, and switch to Qt and dpkg, to unify the Linux userspace , just like you are trying to do it with systemd!
All these stories about an understaffed GTK+ development team, badly maintained ports to Windows and MacOS, discussions about a standard GNOME IDE to make the platform easier to develop for, Glade finally as a first class citizen (after 16 years!) etc.
…and people still pretend like there would be no alternative.
If you want to have an outside perspective from a ISV, just take a look at what Valve is doing: They were looking for a IDE / a Visual Studio replacement under Linux, and what was the best they found? Qt Creator. They are happy. and it makes the choice of the toolkit for their debugger (vogl) obvious. They are also running KDE, which doesn’t force a certain usage paradigm upon its users, so they can have their good old & simple Win95 style interface.
What problems are you trying to solve? Switching to dpkg doesn’t solve anything, both Red Hat and Suse use RPMS for instance, that doesn’t mean you can take any Suse package and install on RHEL or the other way around.
And as I said I am happy for developers to use whatever toolkit they choose, but GTK+ works well for us as it allows us to evolve the toolkit along with our general user interface design work.
As for Valve, I try to speak with them regularly and I have no problems with the choices they make for themselves, for instance SteamOS is running GNOME Shell in the background, not that you are meant to use the desktop a lot with SteamOS. If you want to see a screenshot of the GNOME Shell desktop they ship I suggest looking here:
http://www.howtogeek.com/179883/how-to-use-the-steamos-desktop/
Yes, SteamOS runs GNOME, (and maybe only because they copied that choice form Debian), but since this is a blog post about a WORKSTATION OS, I was taking about, what Valve’s DEVELOPERS were using themselfs:
http://richg42.blogspot.com.br/2014/01/vogl-opengl-tracerdebugger-bonus-content.html
are you kidding, right ??
i am C programmer and sometime i need GUI library for C . why should i care about library which is not standard even in C++ ?? whole MOC stuff is crap .(of course i am not fan of C++ , but this is not even C++ )
rest assured. it dos not matter how good Qt is(or will be), it is not standard for developing , and this is big problem with it.
AWESOME!!! Looking forward for the next release!
Hi Christian,
Telsa Wyne’s notes on Jim Gettys’s talk are available in the web archive. In case you still would like to take a look at them :-)
I was looking for them a couple of years ago :-)
You speak about the way you will try to better integrate tools from other toolkits, but I hope you will also provide tools that can be good citizens on other toolkits as well.
Gnome-shell may be your interface of choice, but it’s not the interface chosen by all the Fedora users.
At work, we develop for Linux, but developers are required to run Windows on our desktops/laptops. Therefore, we run multiple remote X11 sessions off a handful of Linux servers. ie., “remote desktop” or “terminal services”. Please keep our use case in mind. I started contributing to the X2Go project, which is a remote desktop solution for Linux servers.
Michael, there is a Red Hat project called Spice (http://www.spice-space.org/) – it may be appropriate for your use case (a constrain is it requires virtualization, not just plain Linux servers). I hope Spice will be well-supported in Red Hat next-gen desktop :)
Great post. Thank you for sharing this with us.
I really love the development in this direction and am looking forward to the results.
Ubuntu has set up a sort of “LinuxApps” system already. It uses something called Content Hub (akin to Poettering’s “Portals” concept) as well as AppArmor to contain applications. Integrating some of those ideas + components could help to get the goal achieved more quickly.
For instance we decided to put some time into improving the GNOME terminal application as we know it is a crucial piece of technology for a lot of developers and system administers alike. Some of the terminal improvements can be seen in GNOME 3.12, but we have more features lined up for the terminal, including the return of translucency.>
This are great news! I hope requiered function get soon un-deprecated in vte3 or replaced. As far as I know nothing is wrong with it.
The terminal with transparence is crucial and nice :-)
I certainly hope that this effort will not be the first step towards broader integration of branding, advertising and for-pay distribution of third-party services and software. That practice, while financially successful for Apple (now there’s a bit of an understatement) has served to cripple the vitality of OS X as a platform for any use not aligned with Apple’s corporate goals. Closer to home (home being the Linux world), look no forther than the gradual crumbling and faltering of the Ubuntu One service.
If the ultimate goal of the Fedora Workstation is to improve system integration and minimize obstacles to getting an installation up and running (although I personally have found Fedora to be one of the easiest installations to do from an end-user perspective), that’s great. But if the ultimate goal is to compete with the likes of Apple and Ubuntu, I’d ask you to reconsider; I believe that’s a strategy ill-suited to the Fedora community and fraught with all of the perils of being the second (or third) player in a market dominated by alread-successful competitors.
Too much emphasis on GNOME, which I abandoned with alacrity when GNOME 3 was foisted on us – more to the point, how are you handling the Mate desktop environment?
I do recommend you trying out GNOME again, a lot of people who where not convinced early on are coming around these days, like this article author:
http://www.datamation.com/open-source/why-i-switched-to-gnome-1.html
As for alternate desktop environments, we are looking into various ways these can be installed currently.
I tried a short time ago and I must say it still not good enough for tasks that are usually done at WORKstations. The classic mode which is just a shade of the statement it was in 2010 is still much ahead.
I’m still waiting for a way to set the time until the monitor enters standby, to more than 15 minutes.
> I’m still waiting for a way to set the time until the monitor enters standby, to more than 15 minutes.
Not running Fedora here, but GNOME 3 on Ubuntu. I can do so by entering power-menue within the general settings. If this won’t work in your case, you can still fix this by entering this command in your terminal:
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout
while is where you declare the time in seconds you want the desktop to wait before falling into sleep mode. This should be it!
This is really great news. As an disgruntled Ubuntu user, I would love to have a distribution with a focus on both Freedom and workstation use.
When do you expect to the first releases to pop up?
The first Workstation release is planned to be out mid-October.
Regarding HiDPI support: I think that the effort went in the somewhat-wrong direction. What works out of the box now is: normal-DPI screens and double/triple-DPI screens. However, the task of getting a good image out of a 1920×1080 13.3″ laptop screen (i.e. on what I have) was simply dismissed as “impossible” at GUADEC, because it would require fractional scaling of the UI elements. 1x scaling makes the UI too small, and 2x is too large.
I have two suggestions about this.
One is to accept that, on such laptops, 1.5x font scale factor in gnome-tweak-tool gets you as far as it is reasonable to go, and GNOME should just expose this option as a regular preference that doesn’t require gnome-tweak-tool.
The other suggestion is to scale the UI by 1.5x as a special case (even though it is impossible to do nicely in the general case) and accept 48×48@1.5x icon sizes. The trick is that well-written GNOME applications respect the HIG, and it has some existing provisions regarding UI element sizes which can be exploited for good scaling. E.g. it requires all spacings to be multiples of 6 pixels, which does scale nicely. In all other cases, modify the automatic width/height logic so that it rounds the result appropriately for some predefined fractional scale factors to look nicely.
We cannot scale the UI by 1.5 on X without additional X extensions (its not about icons). With wayland we can and even do per monitor scaling (we currently have not implemented hidpi scaling on wayland at all though, hopefully gets done for 3.14)
I have a Zenbook 13″ with 1980×1080 and I found it helped a lot to turn on Large text under Universal Access in the control center.
In your post you have pointed to an issue of traditional distribution repositories – the need to maintain a huge list of packages, i.e. build, test, glue, fix them together (and this is hard! even for a single program). And this leads to inability to install packages from another distro or from upstream directly. But I think your solution to this issue – to introduce sandboxed apps and app store – is flawed in the free and open-source world. Aside security paranoids, sandbox is needed and justified for untrusted proprietary code. For open-source code, it is usually not needed – because there may be critical bugs or back-doors at most, but true malicious intents (and their non-trivial implementations) are very hard to hide. Yes, there is a problem when you get a proprietary program for GNU/Linux and it requires root access to install. But there is no issue to build a free software from source if it isn’t available in the repo… and automating this process for as many packages as possible should be encouraged (e.g. open build system from Suse).
What I see – you’re attempting to re-make the success of Android (and the likes – iOS, Windows to some extent). I find it funny how Gnome 3.12 mimics Android GUI a bit (the new tabs especially) – as a hint for its direction? In the linked video Lennart Poettering admires Android intent system. I admit, it is technically good-looking – for the proprietary apps use case, that is (while having its own serious flaws which nobody raises here – the user is responsible for looking through dozens of permissions – and eventually just accepts them if he finds the vendor trustworthy – so we’re back to the beginning!).
All this is understandable from making money PoV. What concerns me, this approach to end-user desktop contradicts to free and open-source community goals (to maintain and enhance our free comfortable environment). When Red Hat does this in its server business, it seems to be acceptable. But when it goes into our homes with these intents, it raises the friction.
And another friction comes from your methods – all this authoritative rhetoric and actions – simply ignoring approaches of the others, limiting the choices for them (e.g. “GNOME must tell distros how to pack it exactly”, this constant excuse “we’ve made a decision to drop this otherwise perfectly valid patch from you because it contradicts our architectural view; the program will work this way only – and won’t allow any others even as an option”).
While I love GLib/GTK technology and its world, I must admit I hope your attempt fails. This is very pitiful.
I don’t agree that it is just proprietary applications benefiting from sandboxing, not all open source applications are well maintained or maintained at all, so sandboxing can help keep these applications available for our users longer than we otherwise would feel comfortable about making them available.
And as probably expected I don’t agree with your description of authoritative rhetoric and actions. The linux community hosts a very wide range of people and projects, all doing a very wide variety of things. And that is great, more power to them, but just because that is the case doesn’t mean we should turn our corner of the community into a microcosmos of the larger community. We have our vision and are pursuing that with passion, just like all the other distributions and projects out there, over time we and the others will keep correcting our course as we see what works and what doesn’t, but that is how things should be, we gain nothing by trying to be a jack of all trades and master of none.
If you don’t want to settle for the Lego box consisting of random blocks, but you intend to build or improve the blocks needed to meet your own needs, knowing that it’s already what Red Hat / Fedora is doing, being a major contributor, does it mean that Red Hat want to put even more full-time paid developers on GNOME, Wayland and other technologies relevant for the best free desktop? At present, the main problem of these projects is the lack of manpower, and for each new version, nothing is ever finished, we still have the impression of a desktop in working progress, which we must constantly expect the next version.
ps: sorry for my english
We are steadily growing our team here, but of course developing and evolving a full operating system is no simple task, so no matter how many we hire we still need to work with the wider community to succeed here. Red Hat is quite big, but even we are not big enough to carry the whole linux ecosystem alone. But this effort is definitely a sharpening of our focus from our side, so instead of contributing a little a lot of places we aim to contribute in a more focused manner on things we think will have a big impact.
officially support KDE next and you’ll make yourself lots of friends.
I like the approach. Best of luck with the launch. I will be paying attention to this.
The problem I have is that you’ve just described making a product that I don’t want to use. I don’t want my desktop to be like OS X, Android or ChromeOS. I specifically avoid those thing because they don’t deliver what I want. But now you’re saying you want to make Fedora more like that and less like the OS I want. This is a distressing trend in the free software world :-(
“software collections ensure that you can have the exact same toolchain and toolchain versions available for both systems” –
I think it’s overreaching to say that it’s the “exact” same toolchain. Check out this bug: https://github.com/flavorjones/loofah/issues/60 . In that example, Ruby SCLs do not solve the issue, because libxml2 is still different between RHEL and Fedora. I know this because I’m using the ruby193 SCL on CentOS there :)
If you want to match RHEL’s environment, virtual machines are the only way to do that. SCLs are an interesting project, but they often get toted as a silver bullet for anything and everything.