All four of us return to talk about KDE, FOSS phones and watches, Solus’ growing pains, perfect code and more.
News
More eKciting developments in the land of KDE
Purism will team up with KDE for their Librem 5 phone
Replicant doubles the number of supported devices
Connect Watch smartwatch with AsteroidOS crowdfunding campaign
Solus growing pains
Ikey tells us about his recent scaling problems and what he has done to fix them.
Entroware
This episode of Late Night Linux is sponsored by Entroware. They are a UK-based company who sells computers with Ubuntu and Ubuntu MATE preinstalled. They have configurable laptops, desktops and servers to suit a wide range of Linux users. Check them out and don’t forget to mention us at checkout if you buy one of their great machines.
All software has bugs. But should it?
Joe attempts to argue that properly written software should be bug-free and should only require maintenance for compatibility and new features.
See our contact page for ways to get in touch.
I guess Joe is running some nice simple RISC architecture, stays away from these overly complicated Intel CPUs and doesn’t need more than 2^16 bytes of RAM ^^
Maybe you should try running vanilla OpenBSD without and 3rd party packages, Joe. They take good care of having clean code (except the 3rd partystuff under /usr/[Gaint Nasty but Unavoidable]/ like clang needed to build on platforms like arm64). You could even run it on some nice proven hardware like Alpha or HPPA. No Vax though, they let this one die some releases ago because the hardware became too difficult to maintain.
And you would think companies selling network gear with a 80% margin had the money to offer for people who can write clean code, right? Nope, Cisco’s buggy code is legendary. You have them fix one thing and they break two (seemingly unrelated) other things in the process or introduce a regression making the device too slow for your network to even work properly.
Love the show!
+1 for Ikey and Falim in the bugs in code debate. It had me laughing, reminding me of times when die hard windows fans would tell me about how rubbish Linux is, as if they had any experience with it. I think, in this case, Joe was maybe a little unrealistic in his expectations 😉
Great episode, quite fun.
With regard to Purism, I think you guys are overly negative; mainly because I really want something like this to happen ever since Openmoko failed to make another phone after their 2008 model, the Neo Freerunner. Now why do I trust them at all? They managed to deliver Coreboot on a Skylake notebook, which equals delivering on their promise. (I also remember how they altered specs after their Librem 15 crowdfunder, which was really bad, too; but they can’t make their phone worse than i.MX6 and that should be fine enough to me).
As I transitioned to hardware, and thus Purism being criticised for not being set on a hardware platform: While I understand that this feels dodgy, it seems justified to me. First, the i.MX 6 is the best hardware out their to run GNU/Linux distributions, as the Vivante GPU (GC 2000; etnaviv driver) that is integrated offers mainline graphics acceleration, which, as you know if you are familiar with ARM SoCs at all, is pretty remarkable. Maybe look up the old Novena computing platform crowdfunder, which also used the i.MX 6 for that reason.
i.MX 6 is pretty old though (announced in early 2011, being made in a 40 nm CMOS process, ARMv7 architecture). That’s why Purism is looking into the i.MX 8 (28 nm, ARMv8) as last announced early this year. It is not shipping yet, and the Vivante GC7000 GPU is not yet supported by the etnaviv driver. While it would be great to use this never chipset, it is uncertain as to whether they will be able to pull that of. I believe it is totally right to try that chipset out and not just go with the i.MX6 regardless.
With regard to software, Todd Weaver stated in an interview (I have watched Bryan Lundukes interview and listened to the interview with the OpenBSD focused garbage.fm podcast) that they want to make a phone with mainline Linux support, so that you can run any ARM distribution (including Android, if you want to get all the apps). Therefore I don’t really think it matters whether they manage to pull of their GNOME based mobile OS or ship with something Plasma Mobile based.
So I am really wanting to see this happening and even if they won’t deliver, I wouldn’t be sad about having paid 600 USD for this dream, even though that is a lot of money for me.
I couldn’t find the viewpoint of ownership that Ikey described on the Public Money Public Code site. The argument I saw in the video was that the government doesn’t own its software the same way that it owns its buildings because it licenses its software from large corporations. I agree though that the citizens are not entitled to everything owned by the government, but it is within their rights to demand government software be open source if they want to.
I think the question of taxpayer money is not as straightforward as that site or the discussion on the podcast make it out to be. Open source software costs a little more to maintain than proprietary because there is the overhead of publishing it including the cost of making sure nothing bad is published (like hardcoded passwords). There is also the issue that for some projects the government will need to pay someone for a custom solution. Many companies will charge more if they have to open source the solution because that means they can’t sell parts of it to other customers as easily or reuse proprietary code that they already have written. I’d like software to be as open as possible. I’m just noting the argument has to be more nuanced than saying everything about open source is better.
I think there is a spectrum of sloppy to perfect on which all software sits. You could argue that most software is too far to the sloppy end, but I don’t think it is practical to argue that people should never make mistakes the way Joe seems to.
I investigated Replicant a couple years ago. I don’t know how much it has changed since. At the time, it supported only phones that were at least three years old. The Replicant maintainer said that this was because only those older phones had the modem separated in a way that could be secured. I guess they have relaxed that aspect in order to support newer hardware. Besides the old hardware, the issues I had with Replicant were that it seemed to have one main maintainer that did all the merging with a couple other people who would occasionally submit patches. The maintainer responded to most feature requests by saying that he did not have time to add them. The Replicant release cycle seems to be to wait for wait for the Cyanogen/Lineage version to be completely frozen and then support it as the newest Replicant (so about two major versions of Android behind). This puts a lot of burden on them to backport security fixes to a branch that is no longer maintained upstream and from looking through the issue tracker the rate at which this happened seemed pretty variable. Maybe it has gotten better in the last two years.