Do you have any general or philosophical aims with Solus OS? You’ve created the Budgie desktop and Raven notification centre, for example – are you aiming to create as much from scratch as possible?
I wouldn’t say that we have set out to create things ‘just because’ – that’s one of the things I definitely wanted to avoid. If there are places where we can re-use technology then by God we’ll use those, because it saves us having to write the code ourselves.
With Budgie itself, the idea was to try and integrate as much as possible with the GNOME stack; we’ve seen a few desktops pop up over the last few years – some more popular, more well-known than others, and they achieve their aims through a fork. Now, a few years ago, I tried the same thing myself – needless to say, I got a bad taste in my mouth through doing it. My approach with Budgie was ‘let’s see what we can do without forking – let’s try this the vanilla way, the proper open source way’. That’s worked to an extent, but a post went up [on the Solus blog] yesterday explaining that we actually have to cut back on some of our dependency on GNOME.
For Solus itself – because Solus itself is independent as well – again, it comes from experience. A few years back, we had the SolusOS, and the reason I went from scratch in the second phase is that I’d done the whole being a downstream – it didn’t work out. For what I wanted to do – with what I would class as a consumer-grade operating system, not just a desktop Linux for someone to download – it just wasn’t possible as a downstream. When we closed down SolusOS itself there were 7,000 packages in the repo that we were maintaining through various fixes, customisations and optimisations, so in the end I realised that everything I want to do, I would have to do myself. On occasion I’ve been accused of re-inventing the wheel – now, that’s not actually the problem here. The problem is that the wheel is kind of square, and I’d like a tyre.
What happened to EvolveOS and the original SolusOS that it grew out of, and why did you reboot the project later on?
This is where it starts to get a bit complicated… So to start from the end, EvolveOS and SolusOS are the same thing – we had to rebrand. I was living in the UK myself until last year, when I came back home [to Ireland]. So the problem I had is that I wanted to, ironically, protect the project from patent trolls, and in the process I had to apply for a trademark to protect the project. On April Fool’s day last year, of all days, I had a letter come through saying that I was going to be threatened with legal action, and I thought it might be about the name Evolve. It actually wasn’t – it was about the use of OS! Apparently the Ordnance Survey took a dislike to my using of it, as I was informed that the trademark was held by the Secretary of State – so I wasn’t allowed to use my name because of a map maker! When I was trying to explain it to people they were like, ‘Well what about Chrome OS? What about iOS?’ When I was in the UK at the time, Google was heavily invested with a lot of start-up companies and giving out Chromebooks and that, and that was through a partnership deal with the government. Apple had just furnished the House of Lords and the House of Commons with iPads. I imagine that the Secretary of State was quite happy to ignore the fact that they were using OS in their names… But the small fry like me? So I said, ‘Okay, we’ll change it.’ We went through a week trying to come up with a name, but in the end I decided to go back to the old name, which is where SolusOS comes in.
I closed down SolusOS over two years ago, I think. The problem we had at the time, to be quite honest about it, was that we started off with SolusOS 1, which was Debian Squeeze-based, and it got to the point where that was starting to become end-of-life and we were looking to the future. We put a survey out to the community and I said, ‘Look, this is how it’s been so far and we’ve had nothing but grief being a downstream.’ The things that we wanted to do, being a proper desktop project (and we were kind of popular so we were obviously doing something right), were too much work as a downstream. Now, if our diff to Debian was 7,000 packages, at that point you sit there and ask yourself, ‘wouldn’t it be easier if we just did this from scratch?’ And that’s completely my rationalisation of the whole thing. So I put it to the community – we can go on being a Debian-based distro, or we can try and do this from scratch. I think about 70% were in favour of doing this from scratch.
So we went off, and for Solus 2 Alpha 9 we put out something that was built from scratch. We were using GNOME at the time as well and we were going to investigate putting extensions on – all that was going on – and most of the people were happy. The problem was that a significant amount of the community was turning poisonous, and on top of that my right-hand man at the time was turning against me and trying to take the project away from me, which is something not many people will know, but it would be nice to set the record straight.
How did the community start to turn against the project?
“We want to stay as Debian. We will keep it as Debian.” They tried their utmost to ruin it – we had DDOSes and everything against our servers. It was absolutely mind-blowing how bad things went. But then I had my right-hand man at the time editing Wikipedia and things like that, to list himself as the founder and take the project away from me. Now, to say I was losing control of the project is an understatement, so much like with a rabid dog, I put it down, which is the nicest way of putting it. I was nice about it – you know, man power, doing it all from scratch and such, whatever it was I said – but I really felt I had no choice. At the time, people were doing this ‘informed journalism’ that they like to do on the Linux blogs… I was even cited as “stopping Solus” and that I was “leaving Solus for my new job”, and there was a Dr Something-or-other, one of the lead Linux bloggers, who was posting all these links claiming that I was on a $100,000 salary – I was sitting there thinking, ‘Jesus Christ. I must have missed the memo!’ But in reality, I had started my job six months prior to shutting down Solus. It’s a well-known fact that I work for Intel, I’ve been with them for three years now and I work in Intel’s open source technology centre. The idea of me joining an open source division to not work on open source doesn’t really add up!
When you rebooted the project, did you work with many other developers or was it still a one-person project?
On both sides it was a one-person project. Solus 1 itself started right after I left Mint – I don’t know if you know the history of this, but LMDE [Linux Mint Debian Edition] was originally my project.
So a few years ago one of the first projects that I really did start to contribute to in a big way was Linux Mint. It started off with small things but I got a bit more involved, and this is around the time that Ubuntu – I mean, this is the kind of shock and horror we had back in the day – Ubuntu switched the window decorations to the left. How dare they! Nowadays they’re like, ‘Fuck it, we’ve got Mir. You’ve seen Amazon? Now you’ve got Amazon.’ So this was the height of controversy back then, and the first tool that I wrote was actually Mint Desktop, which has been forked time and time again and now exists in the MATE desktop as the MATE Desktop Tool. I gradually stepped-up my involvement in Mint, then one day it kind of occurred to me: ‘Why are you guys based on Ubuntu? They’re based on Debian – just cut out the middleman!’ They said that there are all these advantages to being based on Ubuntu. So I said re-implement them. Apparently they’d had some form of effort a couple of years ago to attempt a Debian distro – didn’t work, backfired. So I said I’d do it. 17 days afterwards, I uploaded an ISO with an installer I’d written as well: ISO 43.
I was with Mint for a while, and while I won’t go into all the details of why I left there, suffice it to say that I felt things weren’t going in the way I thought they should have. Even simple things – back then everyone was going mad about having Compiz, but if anyone ever asked me for wobbly windows again I’d give them wobbly legs, to be honest with you. But that was the kind of stuff – you had things like Emerald, you had SimpleCCSM, you had all these things that were in the Ubuntu repos that weren’t in the Debian repos. And it was like, well, we’ll add these things then, we’ll just make it better. To my thinking, LMDE was taking a back seat and it wasn’t something I was happy with – in my opinion, they were taking safe bets. Personally, I like to take a few risks – I think that’s healthier and I think everyone benefits from somebody innovating; if someone has their finger in the market and they’re stirring things up, I think that’s good. I didn’t think that’s what Mint was doing at the time so I thought I’d do it myself, and that’s where the original Solus came about.
How about now – do you have a small core of developers working with you?
In terms of the core you’ve got myself; Josh Strobl, who’s the one you see posting on the blog, and he’s in Finland; and Justin Zobel, who’s out in Australia. We all do the core bugs and packaging and stuff, but I’m the code monkey. Budgie and things like that are explicitly my domain. We actually struck gold, though, with the latest version of Budgie because it got a bit of a visual overhaul. The author of the Arc theme [http://ift.tt/1Q4TLYE] was working directly with us, so he’s done all the theming and design for the new desktop, so you can actually see in the Git history that he’s made changes there. All the theming is implemented in SASS and that stuff goes way over my head – it makes it look good!
With the Budgie desktop and Raven notification centre, what are your aims in terms of user experience and functionality?
I wanted something that was a modern take on the traditional desktop, but not too traditional. Right now, I’m going through a few different distributions and desktops just to see if I’m really doing the right thing. While a lot of them are very, very pretty, they’re too much in your face – ‘Would you look at all the work we’ve done down on this panel? And Jesus would you look at the gradients!?’
To me, that’s completely distracting – I want something that’s pretty but functional, so I can just get on with my job while the operating system gets out of my way. At the end of the day, the only purpose of an operating system is enabling me to safely and easily use my software. The problem with too many distros and too many desktops is that they try and get up in your face: having welcome screens, first-run tours, ‘Look at our massive software centre that takes eight minutes to load’. Not interested in all that. I just want something that gets out of the way.
So when I first started with Budgie, my first approach was to do what [Linux] Mint did years ago before they went ahead and forked everything under the sun to make Cinnamon, which was GNOME Shell Extensions. So I tried that but there were things I was deeply unhappy with. I can’t stand JavaScript. It’s something that happens in the KDE world as well: ‘We’re going to have this Qt application, but it’s really going to embed a JavaScript interpreter’ – that’ll do wonders for my performance, thank you. And Cinnamon, GNOME Shell, they’re all completely JavaScript – it’s like, ‘What are you doing? Take advantage of the architecture; write native code!’ People like to use all these pretty, high languages… Whatever. I leave that off.
I also couldn’t get rid of GNOME Shell’s Overview mode. I don’t mind a window overview, but a shell overview with a search prompt and all these workspaces up the side of it? I couldn’t stand it so I said I’d write my own. The idea was to use the GNOME software; re-using all the components but putting a different experience on top of that.
Why did you fork eopkg off the PiSi package manager?
When we first adopted it, I was looking at the different implementations, and I hate, hate, Debian packaging – it’s like they looked at it and said, ‘Well, we need a way to get this software, turn it into a tarball, but make it as stupidly complex as we can in the process, and then just validate the reason for maintainers to exist.’ That’s my understanding of Debian packaging, and I know I’ll get a lot of hate for that, but to be honest I’m not there to make friends, I’m there to make a product.
So I looked around to see what’s easier for the developer experience because – and I’ve said this before – I don’t care about the user experience of the package manager. Well, that’s not strictly true; they should know that they’re able to install software, remove software, update and search for stuff – that’s it. You don’t want someone interacting with the package manager, not in my distribution. That’s the goal: to actually get rid of it, so the user doesn’t even know about it. So I asked what was easier for the developer experience. With Solus 1, I was doing all the Debian packaging – about 7,000 different packages. I didn’t want to do another Debian package as long as I lived! I looked at RPM in openSUSE and Fedora and thought they’re just making life hard for themselves – I want to automate most of this, save myself the bother.
So I kept looking around and a friend of mine, Steely, pointed me in the direction of PiSi, and I thought, ‘Jesus Christ – this has everything in one place, and the format’s not stupid! I can work with this.’ At the time, the build spec files were Python and XML – I’ve completely replaced all of that since; we have a simple YAML file in which you have your setup build and install steps; they had macros and variables available to them, essentially Bash scripts and some version information. Nowadays it does all the package splitting for us, adds the automatic binary dependencies, package config dependencies, which is what I wanted. There’s only one other distro that has such a streamlined developer experience and that’s the one I get paid to work on, which is Clear Linux.
What’s on the agenda for Solus OS in 2016?
So Solus 1, as it stands, is technically a traditional distribution because we use package management as a deployment tool. With Solus 2, package management will only be a build tool – the end operating system that you get will not have a package manager. We will be completely separating the operating system itself from the apps, so your operating system itself will be updated in one atomic operation.
The advantages you’re going to have there are that if you’re using a particular Gtk version – say, for the Budgie desktop – you’re going to be having your own version if necessary for your apps. An update to the apps will not affect the operating system, and an update to the operating system should definitely not break the applications, which is the problem that we see in every single Linux distribution out there today. So we’re going to be completely separating that so you have your OS and your apps, and that’ll be the same on every single vertical. And I do mean that in plural – by the end of this year, Solus will be running on more than just a desktop…
Solus 2.0 is also going to be completely stateless by default – as in /etc and /var, places like this, will have no configuration files in them whatsoever apart from the ones that you create. The inspiration for this has actually come from Clear Linux – it’s not a new concept, but the only place it has ever been implemented correctly is the Clear Linux project. We’re going to be splitting the operating system data and the vendor configuration from what is the system administrator or user configuration, which means you’re going to be looking at a very tiny /etc tree. It would be considered a developer error in Solus 2 if any of the base operating system is ever altered in any way outside of a software update – it will not be permitted.
Going back to “running on more than just a desktop”, what exactly do you have in mind?
I issued a challenge to Mark Shuttleworth, which he’s not responded to: I gave him to the end of 2016 to make a better tablet operating system than me. ‘Convergence’ – I hate that word. The problem with convergence is that you’d make everything completely generic, and you’re taking the lowest common denominator approach – at no point are you optimising for the architecture or even for the platform that you’re going to be using.
So the way that we’re going to be approaching this in Solus is that we’re splitting up the way that we organise the repo. At the moment, you just have the one big, almighty, chunky repo, and we’re going to be splitting it off into the concept of layers. You’ll have your core layer, which is where all the bootstrap works and that is literally the bare minimum required to have a booting environment that you can just log into and do nothing else. One of the things that’s actually going to piss a lot of people off is that glibc will not be in there. There’s going to be a great reduction in the GNU userland, to make it more streamlined. So you’ll have your core repo, which is going to be shared between all of the verticals, and one of them will be the desktop one. The advantage is that you’re going to have intermediate layers – some of them might be shared, some of them might not – and we’ll be able to chop and change those layers between different hardware devices.
One of the aims for Solus 2, once we’ve picked up enough support, is hardware-specific builds. Now, the way we’ll have it, you’ll have your core build and that’s going to be specific to that piece of hardware itself – so at the moment it’s just generic x86/64. We’ll be able to do nice things like put in one that’s optimised for Haswell, or Skylake. You’ll also have an intermediate layer that they all share, where they might not need the optimisations in there, so it’s going to be simple libraries that won’t benefit from optimisation. Then we go up to the higher levels of the stack and you’re going to a GNOME Common, for example, that is shared between them – that might contain things like the FreeType libraries, even the Wayland libraries; all this shared userspace that would happen on a tablet and on a desktop.
The nice thing we can do there is something called profile guided optimisation. What we’d end up doing is a lot of stress-testing sessions on the devices in question, we’d generate the necessary performance data from those sessions, and then for each of those builds they would have the appropriate optimisation data, so you’ve already taken advantage of the correct hardware-specific build data from the core layer that you’re already using – say it was Haswell – and then you have your intermediate layer, which is then being geared specifically for, say, a tablet. With everything that’s happening on a tablet you have different events, different file descriptors being used, different call paths – you end up with something that’s highly optimised for that particular device. It’s going to be interesting to implement and immensely beneficial – it means that when we look towards OEM, which is the great end goal, we’d be able to ship something specifically for a device very trivially, just by changing the config of which particular pattern we want to use to ship to that image.
The best thing is that we’d then be doing a merge of those particular layers into one binary source, and that constitutes the operating system itself, so that comes through and then all the user has to do is update, because that stream is then updated again and they have a diff to apply to their system. So you have these different end points that we merge together into a single binary end point, which becomes the operating system for that system. So we turn what is a distribution at the moment into a series of less generic building blocks that we can then merge together. It’s like putting LEGO together but making sure there’s not even a millimetre gap between them – that’s what Solus 2 is going to look like. But we’re not there yet.
As Josh [Strobl] put it: Solus 1 was building the engine, Solus 2 is building the car. I think that’s a brilliant analogy, considering the way that we’re going to be doing it. We’ve got the core operating system, it exists, and with Solus 2 we’re re-organising it, thinking of the distribution as a set of different streams. The whole thing is going to be about merging streams, so conceptually we’ll be building in a completely different way, and at that point it stops being a distribution. A distribution is exactly what it says on the tin: it’s a loosely organised, badly interconnected set of packages, and you kind of hope that they all stick in the same place when they land. Solus is pretty good at it, but you still have to account for hundreds of tiny different configuration changes that could exist across this vast ecosystem of packages. What we’re doing is talking about an operating system that is being streamed from a single binary source, so at that point it stops being a distribution, which is definitely the ultimate goal.
Support Solus
“You have to be realistic in supporting yourself,” Ikey added towards the end of our conversation, “and, let’s be honest, Solus is a fucking expensive project to run. In the last year alone it cost me several thousand pounds… To avert that with Solus 2, people who are supporting us on Patreon and things like that are going to get early access to the builds. We’ll be doing the public milestones and everyone can use those. For people who are supporting us we’ll be giving them a dedicated email address where they can get support from us, and we’ll be announcing up-to-the-minute releases for them so they can be keyed into the release immediately.”
If you’re a fan of Solus, why not help pay the bills and head to Patreon?
from Linux User & Developer – the Linux and FOSS mag for a GNU generation http://ift.tt/1Q4TJQn
via IFTTT
Posts
No comments:
Post a Comment