Tag: computers

The state of FLOSS and the tech industry

I’ve read an article today, in ZDnet, mourning how desktop distributions seem to wax and wane. It really made me think about how to properly convey what I feel to be the root issues with desktop adoption of Linux (and the wider CS industry), and why I think most people are very, very wrong about it.

Most people, normal people, they do not care about shiny. They don’t care if their email client or word processor is written in C++, Rust, JavaScript, Python, Ruby, or FORTRAN. They just want something that is simple to use and allows them to accomplish their tasks. It feels like most programmers and designers have lost that concept. I’ve met people in this industry who thought that they could sell people their products based on metrics like memory usage and number of packets transferred. Very excited people tell me how they use MapReduce and AngularJS and MongoDB and MariaDB (sometimes all four at once), like they deserve an award for Most Use of All Available Frameworks And Patterns Released This Decade. There’s a great article I read recently that puts in no uncertain terms: You are not Google. Even Google isn’t Google. Following these “trends” may make your product seem “trendy” to other developers, but all you are doing is wasting your time while leaving your users under-satisfied. Focus more on your software and how it can help people, and less on how it can help your résumé.

Meanwhile, I’ve seen libre software developers put up on their homepages that they now offer Flatpak images and are very excited to tell you that. Nobody knows what that means outside of developer circles! Do you think your grandparents care that your word processor is available in Flatpak or Snap? Do they even know what that means? In addition to this, Flatpak and Snap are anti-solutions. They don’t solve any real problems; they only serve to create new ones. What if a user or distribution wants to use ALSA instead of PulseAudio? What if a user or distribution uses an alternative to systemd? What if a user wants to use sound from their existing session at all? What about CPU architectures that aren’t supported by all developers, like ARM, POWER, or RISC-V? Focus more on your software and how it can help people, and less on following the trendy new shiny.

My personal hope for this industry is that we gain stronger distributions with better focus, and that developers leave packaging to the distribution packagers. This would allow us to have a few different desktop distributions. Distributions could be working together on a common frameworks, like KDE, while having specific plans and goals in mind. Gentoo and Arch for the tinkerers; Gentoo with more focus on source building, Arch with more focus on a tightly integrated system. Adélie and Fedora for the general public; Adélie with more focus on stability and portability (X11, PPC/ARM), Fedora with more focus on incubating new systems. Obviously there would be distributions that would pop up with unique goals; their work could be integrated later in to a main distribution that is aligned with it.

I feel like this could really be a way forward towards more wide adoption of Linux, on the desktop and beyond. I hope we can work together towards it.

(As a small aside that I wanted to note: I hope “The Year of the Linux Desktop” never comes. I hope that we usher in an Era of the Linux Desktop.)

Speaking with authority

I’ve just spent the better part of three hours arguing on IRC about Let’s Encrypt clients. After speaking with two others, I realised that nobody who I spoke with before knew their facts were facts.

Different people all told me various incorrect information, such as:

  • No ACME client supports doing a manual DNS TXT record for verification bootstrapping until you have an httpd up. (acme.sh, dehydrated, and certbot all support this.)
  • LE needs IPv4 for the HTTP challenge. (It worked fine for me with an IPv6-only host. I’m not sure which it would prefer if it had the choice between v6 and v4, or if it’d use Happy Eyeballs and connect to whichever responded first.)
  • It isn’t possible to step through the process manually as a debugging aid; you have to rely on your ACME client’s debugging facilities. (https://gethttpsforfree.com/ helped a tonne.)
  • You have to be listening for the HTTP challenge on port 80. (The TLS-ALPN-01 challenge type exists which will only ever use port 443 for the challenge.)
  • Critique of how I isolated each service on a separate VM so that they would be more secure, saying it was “over-convoluted”.

All of these people spoke with an air of authority. They sounded like they genuinely knew what they were talking about, and were trying to inform me of the limitations of ACME clients / Let’s Encrypt. Nobody actually knew the answer, but they thought they were right because it fit their experience.

When I speak to people about technology, whether in real life, on IRC, or on a mailing list, I always try to make the limitations of my knowledge clear. Many is the time I have said “I’m not sure if you can do that”, or “I don’t know if X supports Y“. And sure, on occasion I will say “I have never done Y and last I knew X couldn’t do that”. Note, however, that all of these are presented as statements from my hive of knowledge, and not presented as plain facts. The art of communication seems to be lost on far too many in the technology field.

There is no shame in not knowing the answer to something. It is certainly more helpful to say “I’m not sure you can do that”, instead of “you can’t do that”. I almost gave up on Let’s Encrypt and wrote another article on how useless it is, because I was told by people who used Let’s Encrypt that it had all of these limitations that made it seem useless, arbitrary, and ridiculous to me. (Thanks to Rich Felker of musl, and Freeyorp, for setting the record straight.)

Maybe we need a new term for this. “Organic FUD”, since it comes from the community itself? At any rate, I hope that in the future, more people note the limitations of their knowledge up-front rather than sounding authoritative about a subject they know little about.

GitHub and IPv6, three years later

Three years ago, I wrote Going IPv6 native without IPv4, which noted all the services I couldn’t access over IPv6. After all this time, there is some good news, and bad news.

First, the good news: BitBucket, Savannah, and Launchpad all support IPv6 now!

Now, the bad news: GitHub still does not. This has actually prevented me from setting up a trial run of acme.sh on a server. The server I was going to test LE on is only connected to the public Internet via IPv6. Yes, I was actually trying to see if Let’s Encrypt has gotten any better, and I was prevented from doing it because GitHub does not support IPv6.

Authors of ACME clients, especially ones that are only available via GitHub: find a mirror that supports IPv6! At this point, now I’m going to have to set up acme.sh on my workstation, and then scp the certificates over to the server every 60 days. Thanks GitHub.

Further thoughts on Wayland

Previously on The Cat Fox Life, I wrote an accidentally now-infamous article on what I felt were lies/misconceptions that Wayland users were spreading about the Wayland system.

One of the Wayland community’s more prolific developers wrote a rebuttal to my article, then directly responded to me on HN. I hadn’t yet gotten around to properly responding to this in earnest, because I had a lot of personal IRL drama to deal with in February. I’m feeling a little under the weather today, with a minor head cold and sore throat, but Drew has reached out to me personally and the time to write this is now.

Before I begin, I feel like the original introduction to my previous article may have been worded slightly incorrectly. This was never an indictment of the developers of Wayland, but rather the rabid fanboys who spread BS on Reddit, forums, IRC, and such. There are rabid fanboys of systems I actually like, too; musl, s6, KDE, and Firefox come to mind. I don’t like those fanboys either, and I could probably write articles about lies they come up with, too. (Welcome to the Internet, I suppose.)

Drew wrote: LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory.

That’s perfectly correct, and I noted in my previous article: “I’ve been told that mentioning something that uses LD_PRELOAD is cheating and that you could own any application, not just Wayland. That is true! But this is being sold as “impossible to keylog”. It isn’t.”. This isn’t a mark against Wayland, but again, a mark against dumb people saying things they shouldn’t be and generating buzz. There have been multiple people on IRC and Reddit that have said that Wayland is immune to keylogging without clarifying that it’s the protocol, not the implementation. The developers of Wayland know that you need to secure the whole system, but these fanboys don’t.

Drew wrote: many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard.

I said in my article: “Wayland compositors universally require OpenGL profiles that older hardware, less expensive hardware, libre hardware, and most embedded chipsets do not provide.” GLESv2 is still not going to work on framebuffers, libre FPGAs, or embedded chipsets. At least, not without LLVMPipe, which would use a lot of CPU time and power on the hardware where it’d be relevant. That said, Drew wrote in his response: “writing an fbdev backend is totally possible and I’d merge it in wlroots if someone put in the time.” This gives me hope that perhaps it may be possible to run Wayland compositors on framebuffers some day. Additionally, I was too harsh when I said that Wayland is “designed” to “require” blobs. Of course it isn’t, and I shouldn’t have said that.

I would also like to note that although wlroots is used by “over 75% of all compositors”, there are four main compositors that I would suggest people think of when they think of Wayland: KWin (KDE Plasma), Mutter (GNOME, replacing Metacity), Sway, and Enlightenment. As far as I know, wlroots is only used by Sway out of these four. So while it has high number of market share, I’m not sure it has the same high number of installed user base, which coloured my initial perception on compositor GPU requirements. I am not sure what Mutter requires out of GPUs, but KWin’s Wayland compositor requires more than base GLESv2, and far more than KWin’s X11 compositor, which supports XRender (software) and OpenGL 2.0. Similarly, in my experience Enlightenment runs much better on older hardware using X11 rather than Wayland. It is good to know, though, that not all Wayland developers feel that they should be overutilising GPUs so much. I am glad that if wlroots had to require OpenGL, GLESv2 is the standard they chose.

Drew wrote: For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work.

This was actually very nice to hear! Wayland developers seem to want network transparency, but just don’t have the interested parties right now to make it reality. It’s good to know that ideas are not rejected in Wayland like the Wayland proponents in /r/linux said they would be because “that’s legacy X11 garbage”. (I suppose this comes down, again, to fanboys yelling and screeching.)

Drew wrote: A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation.

The difference being I rarely hit driver bugs or Xorg server bugs, but regularly hit compositor bugs. (KWin has crashed 27 times in the past year. Xorg, once, due to – you guessed it – a radeon.ko bug.)

Yes, the security holes are blatant speculation and were phrased in a mean and combative way. It was wrong and I publicly apologise, not only to Drew and other Wayland developers, but to any that may have felt personally attacked. Of course I didn’t mean it to be a personal attack, but it came off that way due to being written poorly. I regret that, and hope to learn from this experience.

As a conclusion, I still personally don’t see myself running Wayland any time soon. However, I would be happy and willing to merge Wayland packages in to Adélie Linux if someone is willing to maintain them.