Is there any library for parsing and serializing #systemd config files in the
systemd.syntax(7) format (preferably for #Rust, but I guess I could do with C, too)? I can find multiple crates for ini files, but there are enough subtle differences (array-valued and duplicate keys, line continuations, strings, escaping) that they aren’t very useful.
@ryo @twann @be I also was thinking about this earlier today. Intuitively, it feels like we need to balance risk of some company taking the code and enforcing their own copyright vs the nuisance of involving heavy-weight legal machinery. As a further complication, we disagree with most uses of said machinery, except those that actively circumvent its other uses. Which makes it hard to form a coherent message.
- There’s the control over the software development at large by server administrators.
- There’s the control over how the server is run (and possibly what development goes on on the server’s own fork) by the end users.
- There’s the control over the software development at large by the end users.
Out of this, 1. is probably easiest (there’s just a relatively smaller group of developers and server administrators to coordinate), 2. boils down to effective ways of community governance. Both 1. and 2. involve processes that the respective parties are probably quite familiar with. But 3. feels tricky to achieve.
The lack of federation (cutting out server admins and developers are the same) gives undue influence to developers (see e.g., Signal). Going the other way, and making everyone self-host is technically difficult and unrealistic for most users, unless the technology is deliberately engineered to be trivial enough to allow this (see e.g., the Small Web movement).
free software, licenses
My view on software licensing: Intellectual property abolition (copyright is a spook) is hard to reconcile with copyleft (the desire to co-opt copyright itself to ensure that art, software, and science remains free). While releasing work into the public domain would be preferable, it runs the risk of the work being co-opted by others who will nevertheless enforce their own copyright.
My recommendation would be reserve copyleft for works with significant network effects, either because the work implements a protocol and relies on a network of users, or because the work is so complex it requires the cooperation of a large number of developers. Such works should be placed under the AGPL3.0 (but not later!), or even better, a modified version of EUPL without the GPL compatibility loophole, since network effects would otherwise give malicious actors an oversized influence once they co-opt the software projects.
A more principled approach would be to draft a license that prevents co-opting network effects without any attribution clause, so you’re allowed to do literally anything with the work except to try to enforce your own copyright in the traditional sense. However, such approach is likely impossible: if you don’t have to prominently display whose work you’re taking, how could anyone make sure that you comply with the license?
matrix, free software
Element has released a closed-source Teams integration for matrix. Sadly, this was expected, since they opted to release Synapse under the Apache 2.0 license instead of something more free like the GPLv3. At least that would have helped a bit, since they use DCO instead of CLA.
Unsurprisingly, the Hacker News crowd considers this not that bad, since “free software adherents” don’t have Teams accounts to worry about, amirite? No, 1. because having access to information about proprietary protocols and the ability to migrate from them helps everyone once the proprietary supplier decides to screw them over 2. even “adherents” are forced to use proprietary platforms sometimes (e.g., at work).
@aral Having to opt out this way feels a bit insidious:
Permissions-Policy was used to be named
Feature-Policy and had a different syntax. So maybe also adding
Feature-Policy: interest-cohort 'none'
would also be a good idea (although hopefully no browser that supports
Feature-Policy but not
Permissions-Policy does any FLoC). Also,
Permissions-Policy is used to opt out of a lot of other browser features, such as geolocation and payments. Opting out of these if you aren’t using the is probably a good idea, for the very least, to limit the impact of any potential XSS vulnerability. So an application that opts out of, say, camera access on every page except a videochat feature now must remember to opt out of FLoC everywhere, even on pages with a lenient
This is a (cynically, I’d say deliberate) mixing of responsibilities: while other permissions are about what code from the website can do,
interest-cohort is about what advertisers can do.
@jk If I want to engage with a talk, or just bond over being in the same subfield, I just talk with the author later in a more relaxed setting. I’ve probably already run into them earlier during the conference, because we attended mostly the same sessions.
Questions right after a talk are almost always adversarial: either there was a problem with the contribution that didn’t come up during review and the presence of the audience makes the author’s answer accountable (I’d guess this is fairly rare, and I’ve never seen it in practice), or the asker wants to push their own agenda to the audience (disregarding the author entirely).
Of course, for questions truly about something not being easy to follow (e.g., because of some formatting error on the slide, or unfamiliar notation, or just because the volume was too low to hear in the back), asking them immediately during the talk would be preferable. But I can see why moderating that could quickly become a challenge, unfortunately.
On a related note, I reorganized applications on my server into ephemeral #podman pods and containers created and deleted by #systemd
.target units. The Podman documentation already has something similar, but it turns out it’s perfectly possible (for now) to create empty pods and add container to them on the fly. As a bonus, I can create dependencies between containerized (Matrix) and native (Postgres) services, and container output is piped into the system journal.
delete from profiles where user_id='telegrambot'; delete from users where name='@telegrambot:marussy.com';
to make it register properly again. That wasn’t intuitive at all.
Statement on Richard Stallman rejoining the FSF board
@june Ça me surpris que styler les liens visité distinctivement est recommendé. Sites qui affichent les liens que j’ai visités me font me sentir observé. Je crois que les navigateurs limitent les styles
:visited sur les liens cross-origines parce qu’ils sont une méthode du traçage possible.
@june Ce police de caractères est si jolie. Ouvre l’inspecteur du DOM et recherche le nom de la fonte. Ah, elle est utilisée dans les cockpits des avions Airbus — c’est très intéressant !
@trysdyn @Azure One thing Matrix got right is their focus on APIs to easily extend homeservers with bridging to other protocols. This can be quite twisted, like annoying IRC users with weirdly formatted messages, but done right, it’s potentially quite convenient (especially for rooms that are available with multiple messaging clients, e.g., facilitating a conversation between Matrix + IRC + Telegram). Granted, solving the multi protocol issue on the client side used to be better (e.g., Pidgin), but nowadays every messaging application comes with its own Electron app that eats 600MiB of memory.
Even though there are bridging solutions for XMPP, too, I’m not aware of a dedicated interface (app service API) for that baked into the protocol (but I’m not that knowledgeable at XMPP, and specifying such an interface would be quite possible anyways). Nevertheless, the possibility of bridging is much more front-and-center for Matrix that for XMPP, and it seems easier to find well-maintained bridges for Matrix, which might sway some people towards it.
At least that’s the theory. I’ve been fiddling with setting up Synapse and bridges since a few days, so far unsuccessfully. Matrix does seem like a true test of devops skills, which is exactly the opposite of what you’d want in a convenient piece of software.