Every now and then a fossbro tries to incorrect my terminology and insist I say “GNU/Linux” instead of “Linux”. I wrote this to save myself some time. Instead of engaging with the fossbro, I can just paste this link and wrap up the conversation while they read.
Excerpt:
“A specter is haunting the Linux community. Where lies productive discourse about operating systems, there also lies a danger. For the longer such discourse lasts, the greater the risk that the discourse shall be interrupted by The Interjection: an abomination brandished by a raging fossbro determined to contribute absolutely nothing to the discussion. The standard fossbro interjection begins:
‘I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.’
Sensible retorts, such as “Nobody asked you”, “Please leave us alone”, and “Sir, this is a Wendy’s” are useless defenses. Nay, the greatest weapon against misguided pedantry is pedantry itself.
Let’s talk about why not to use the term “GNU/Linux”.
Every now and then a fossbro tries to incorrect my terminology and insist I say “GNU/Linux” instead of “Linux”. I wrote this to save myself some time. Instead of engaging with the fossbro, I can just paste this link and wrap up the conversation while they read.
@Seirdy Yeah, the term basically exists because RMS likes getting credit for things, as far as I can tell. There isn't an argument for it in modern linuxes. As for what's a GNU/linux as people use the term, I think it's basically synonymous with "linux distribution" (or meta-distribution), maybe with the added specification that it should contain primarily free software or separate free and non-free into different repositories.
I like "linux distributions" or just "linux" better.
By putting a "works in any browser" badge on your site, you legally consent to receive bug reports from me when I use your site in the SerenityOS Browser, NetSurf, LiteHTML, Servo, dilloNG, and w3m.
Many open standards can support profile hydration:
Ariadne: map an email identifier to supported verified accounts.
The IndieWeb: map a webpage with h-card to any account, with less-robust reciprocal-link verification.
WebFinger: map an email-like identifier (an acct: URI) to a list of links.
vCard: upload a vCard containing profile information, possibly with “share contact”.
I think h-card-based hydration is the best place to start. We can later add support for more options:
Keyoxide profiles already contain h-card microformats, so we get that for free.h-card microformats can have u-key properties, potentially triggering an Ariadne-based verification of accounts enumerated by the h-card.h-card can map to vCard4
Depending on how keyoxide-web issue 141 goes, WebFinger could also indirectly give Keyoxide support.
A rough timeline of QUIC support in OpenSSL-like libraries:
BoringSSL implements QUIC.Quiche, a QUIC library, requires BoringSSL. Nginx can be patched to use Quiche for HTTP/3.Nginx’s experimental QUIC branch (nginx-quic) is released. It requires BoringSSL.Some organizations (mostly Akamai) fork OpenSSL to implement the BoringSSL QUIC API, calling their fork QuicTLS. They plan to upstream changes.nginx-quic supports building with QuicTLS too.OpenSSL decides against the BoringSSL API and declines QuicTLS patches, preferring to write their own incompatible implementation.LibreSSL implements the BoringSSL QUIC API.nginx-quic can link against LibreSSL as well as BoringSSL and QuicTLS; they all use similar APIs.
(I believe wolfSSL is mostly compatible with the BoringSSL QUIC API, but I might be wrong.)
Developers will have a harder time supporting multiple TLS implementations, hurting the viability of e.g. LibreSSL-based distributions.
A rough timeline of QUIC support in OpenSSL-like libraries:
BoringSSL implements QUIC.Quiche, a QUIC library, requires BoringSSL. Nginx can be patched to use Quiche for HTTP/3.Nginx’s experimental QUIC branch (nginx-quic) is released. It requires BoringSSL.Some organizations (mostly Akamai) fork OpenSSL to implement the BoringSSL QUIC API, calling their fork QuicTLS. They plan to upstream changes.nginx-quic supports building with QuicTLS too.
UX tip: Matrix and XMPP clients don’t need lock indicators for large-enough E2EE rooms. You’ll know the room has encryption enabled because someone will say they’re getting decryption or key-fetching errors.
For personal reasons, I am stepping away from or reducing my involvement in some communities to better focus on other things. You will likely hear from me less.
My site will probably update less frequently too. Some timed posts may fire, but I won’t be actively writing much. I most likely won’t POSSE those timed posts.
I’ll probably be back eventually, but not for a while.
Most of these are pages that blur the line between “document” and “app”, containing many interactive controls. Being concerned about them is valid; however, I think the concern is misplaced at this stage.
For an independent engine, I’m more interested in simple “web documents”. Those need to work well before tackling “Web 2.0” territory. Specifically: articles progressively enhanced with images, stylesheets, and maybe a script or two. Understanding how well Web 2.0 sites render isn’t really useful to me without first understanding how well documents render.
When testing my site, my main pain points are: a lack of support for <details>, misplaced <figcaption> elements, my SVG profile photo not rendering (it renders when I open it in a new tab), and occasional overlapping text. The only non-mainstream independent engine I know of that supports <details> is Servo.
Most of these are pages that blur the line between “document” and “app”, containing many interactive controls. Being concerned about them is valid; however, I think the concern is misplaced at this stage.
For an independent engine, I’m more interested in simple “web documents”. Those need to work well before tackling “Web 2.0” territory. Specifically: articles progressively enhanced with images, stylesheets, and maybe a script...
The core elements of a people-focused (as opposed to a community-focused) social network are subscribing to people for content and interacting with their content. Atom (and RSS) feeds already provide “subscription” functionality; what if we went further?
Atom feeds can serve as the foundation for distributed social media. The OStatus protocol suite describes how Salmon, ActivityStreams, and threading extensions can turn an Atom feed into a “social media feed” that people can interact with. Throw in WebSub for real-time push-based updates. This OStatus + WebSub system was the precursor to the current ActivityPub-based Fediverse.
The IndieWeb has similar concepts. The IndieWeb community uses microformats for metadata, including the h-feed feed format. It also uses Webmentions for interaction between sites.
The best part of this approach is the simplicity. Besides a Webmention receiver and a WebSub hub, all you need is a static server to deliver markup files. A separate program on your machine (i.e. not necessarily your server) can ping your WebSub hub and send Webmentions; I happen to like the command-line program Pushl. Once all the pieces come together, you start to wonder why we let social media companies flourish instead of lowering the barrier to join something like the IndieWeb. This is what the Web is made for.
The core elements of a people-focused (as opposed to a community-focused) social network are subscribing to people for content and interacting with their content. Atom (and RSS) feeds already provide “subscription” functionality; what if we went further?
Atom feeds can serve as the foundation for distributed social media. The OStatus protocol suite describes how Salmon, ActivityStreams, and threading extensions can turn an Atom feed into a “social media feed” that people can interact with. Throw in
What if Firefox and Chromium placed a year-long moratorium on all new browser features unrelated to security, accessibility, and internationalization? Effort not spent on those initiatives could be re-directed towards bugfixes.
Defining the word “major” might be hard but I think it’s an interesting idea.
I’m not too worried about including Safari since it could spend those months catching up.
What if Firefox and Chromium placed a year-long moratorium on all new browser features unrelated to security, accessibility, and internationalization? Effort not spent on those initiatives could be re-directed towards bugfixes.
Defining the word “major” might be hard but I think it’s an interesting idea.
Some of my coworkers subscribe to my site's feeds using Microsoft Outlook. Outlook doesn't support XHTML feed contents, but it does support escaped HTML feed contents. My Atom feeds use XHTML but my RSS feeds use HTML, so I re-introduced RSS discovery for them.
Also, Outlook renders feed contents using the same HTML renderer it uses for emails. That HTML renderer is the Microsoft Word HTML renderer. Word's HTML renderer is based on Internet Explorer's MSHTML (Trident).
So IE was sunset on consumer editions of Windows two days ago, but I guess it lives on like this. I updated my my thoughts on IE's not-quite-demise to reflect that: https://seirdy.one/notes/2022/06/15/internet-explorer-is-almost-gone/
Some of my coworkers subscribe to my site's feeds using Microsoft Outlook. Outlook doesn't support XHTML feed contents, but it does support escaped HTML feed contents. My Atom feeds use XHTML but my RSS feeds use HTML, so I re-introduced RSS discovery for them.
Dillo’s domain name has expired, making it impossible to fetch its Mercurial repository from its canonical location. Fortunately, Mercurial is a distributed version control system, and I had a copy. I pushed my copy to hg.sr.ht; you can see it there.
“systemd has the right goals but also has poor architecture: i like operating it but i don’t like its underlying design” is so much harder to digest than “systemd good” or “systemd bad”
“sandboxing is good when done in a way that gives users the ability to control how their programs run, and doesn’t have to make your computer locked down like iOS” is harder to digest than “sandboxing good’ or “sandboxing bad”.
“verified boot that lets users control the signing key allows users to verify that the boot sequence is what they want it to be, ensuring that their FDE isn’t compromised; however, most existing implementations give vendors control that should belong to users” is harder to digest than “verified boot good” or “verified boot == DRM”.
it’s hard not to sound like a corporate shill, which is the opposite of what I’m trying to be whenever I start talking about security. Fossbros have given the entire FLOSS community these warped preconceived notions on what sandboxing, verified boot, and even Systemd are and aren’t.
it sucks to have nuanced views on the internet
“systemd has the right goals but also has poor architecture: i like operating it but i don’t like its underlying design” is so much harder to digest than “systemd good” or “systemd bad”
“sandboxing is good when done in a way that gives users the ability to control how their programs run, and doesn’t have to make your computer locked down like iOS” is harder to digest than “sandboxing good’ or “sandboxing bad”.
devs of bloated software should have to make a pilgrimage to bangladesh and inhale the fumes of the e-waste burn pits to understand the carbon footprint of their bloaty software causing people to buy new computers.
Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default.
If you read the actual proposals and W3C specs, you’ll find a different story.
Everybody: please calm down, take a deep breath, and read before you make such prescriptive advice.
FLoC is terrible, but telling everyone to add a magic “opt-out header” in every situation conveys a misunderstanding of everything you need to know about the opt-in/out process.
Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default.
Gregory's Server
@Seirdy Yeah, the term basically exists because RMS likes getting credit for things, as far as I can tell. There isn't an argument for it in modern linuxes. As for what's a GNU/linux as people use the term, I think it's basically synonymous with "linux distribution" (or meta-distribution), maybe with the added specification that it should contain primarily free software or separate free and non-free into different repositories.
I like "linux distributions" or just "linux" better.