They are working on a new touch keyboard: https://invent.kde.org/plasma/plasma-keyboard
But yeah, no idea when it’ll be ready.

Well, I happen to be lucky enough that this particular project is actually developed as part of my dayjob. And the other projects, if I’m honest, are just projects I developed to scratch my own itch and then uploaded onto Codeberg with a libre license. I haven’t really announced them anywhere, except to a few colleagues, so I basically never get suggestions there.

But yeah, this project being part of my dayjob kind of makes it even more clear-cut that I’m not going to put in extra time to develop features that no one currently sponsors…

Got a comment last week on one of the open-source projects I’m contributing to. We have an issue open, documenting that we’d like to support a certain feature, and this person clearly took quite a bit of time to pull together information, which gets us over the first major hurdle for this feature.

But also, this feature is really not the highest priority to us right now. Really had to stop myself from promising that we’d look into it in my response, because it is still quite a bit of work to actually make it a reality. I’m still new to all this, so I still have to learn to not feel bad about it. If they want to scratch their own itch, they’ll have to scratch it in full. That I’d review their code before merging, is honestly already quite a bit of effort put in by me for something that I don’t care to solve right now. That I take time to respond is basic decency, but still also uses up time. Really, I had not understood before, how much work it has to be for maintainers with an actually active community.

Cubuntu is also a thing.

It’s the usual ridiculous premise of “AI is better, if you remove all the aspects that are actually involved in doing the thing”.
A real therapist looks at emotions, at your dynamic when you talk about your conflicts. They throw in suggestions to gauge your reaction. And they can get to know you and push you towards a positive outcome over many sessions. In particular, they also serve as a form of mediation. Having a person that holds you accountable for disrespectful behavior and for ridiculous expectations can do a lot for bringing a couple back on track. A chatbot just does not do these things.

But on top of that, even the methodology seems to be flawed. A person liking a response is not an indication of it being good. Sometimes, a therapist needs to tell you that you’re being an ass.

Like, yeah, the research itself has some amount of merit. A chatbot therapist might be better than having no therapist at all (so long as it doesn’t encourage self-harm). But the headline and the premise of the article is so far removed from any truth that it doesn’t belong in a science community.

[email protected] was developed as a commercial title a few years back. I believe, @[email protected] contacted the devs to get it open-sourced.

Tutorial: https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server

They’ve posted on Mastodon, that it is a (D)DoS: https://linuxrocks.online/@[email protected]/113995906036180301

Those regex crosswords ain’t gonna solve themselves…

Company-internal service where the users would write their desired configuration into an Excel file. Then they push that into a Git repo, which triggers a deployment of the service with the configuration read from all the Excel files.

(Other than things like locked down smart phone bootloaders, but that’s got nothing to do with the FOSS part of this discussion.)

See, I disagree on that. If I know something I could (help to) build will only ever be used by a few folks and can never help most people, then my motivation is significantly lowered. Well, unless I’m truly just scratching my own itch, but even then I might choose to not scratch my itch, because I’d rather quit using the platform, if possible.

And then, yeah, what the other person said about financing.

For Android, there are various small efforts in terms of forks, with the biggest being LineageOS. There are even some commercial efforts, like /e/OS. I think, Huawei also wanted to do a fork or something. No idea what happened with that.
But yeah, none of these efforts are hard forks, which can change more than superficial stuff. And it’s not for a lack of desire, but because it’s just such a ridiculous uphill battle to try to get anything noteworthy changed. Many times, LineageOS (and its predecessor CyanogenMod) had some cool features, which they later had to scrap, because they needed to follow what Google was doing and their features wouldn’t work with that anymore. If they would’ve seen any chance of a hard fork working out, they probably would’ve tried to go that route.

Well, any software needs to include a license of some form, if you want it to be usable by others. But if it’s not an open-source or libre license, then it’s a proprietary license. That’s not necessarily a bad thing. At that point, it depends on what’s actually written into the license. But it’s also not a good thing, as you miss out on various open-source benefits due to there being no proven legal compatibility with open-source licenses. Well, and if I remember correctly, FUTO’s license actively prohibits reuse of the code anyways.

Personally, I’m at the point where I try to only use community-developed software. I’ve seen it too often that even projects which are nominally open-source start becoming cunts…

Android, Chromium.

The problem is that:

1. Google puts in more development power than anyone else. Any forks we’ve seen so far are only really soft forks, as in they only apply a few patches on top of what Google puts out, rather than taking the project in a new direction, because you’d be behind pretty quickly.
2. These projects establish platforms that have shitty decisions baked in. For example, the Android dev tooling has Google ads/tracking as one of the built-in UI components, which is why even if you patch the OS, the apps will still be shitty. To actually change this stuff, you’d need a majority of users to switch to your fork and stay there for a few years.
3. Partially, it’s only financially viable for Google to develop these projects, because they have those Android ads or benefit from a web with less tracking protection. This makes it extremely unlikely for any other organization to be able to splurge a similar amount of money, which brings us back to a fork just being unlikely.

And so long as a fork is unlikely, Google can do shitfuckery quite similar to proprietary projects.

Yeah, everyone else had already answered that, which felt like we’re picking apart that specific thought experiment, even though there is actually a much more fundamental reason why it won’t work.

Perhaps also worth pointing out that the speed of light is that exact speed, because light itself hits a speed limit.

As far as we know, light has no mass, so if it is accelerated in any way, it should immediately have infinite acceleration and therefore infinite speed (this is simplifying too much by using a classical physics formula, but basically it’s like this: a = f/m = f/0 = ∞). And well, light doesn’t go at infinite speed, presumably because it hits that speed limit, which is somehow inherent to the universe.

That speed limit is referred to as the “speed of causality” and we assume it to apply to everything. That’s also why other massless things happen to travel at the speed of causality/light, too, like for example gravitational waves. Well, and it would definitely also apply to that pole.

Here’s a video of someone going into much more depth on this: https://www.pbs.org/video/pbs-space-time-speed-light-not-about-light/

Oh, that is actually the part I do agree with. I don’t think everyone will, but I do actually think JSON is easier to read and write (correctly) than YAML. I specifically wrote that JSON cares the least about that, because it was designed to just serialize JavaScript objects into strings and back. As far as its original purpose is concerned, no one would ever need to hand-edit JSON. Which is also why it doesn’t support comments (which is still somewhat of a dealbreaker for a configuration language, although I guess for your proposed workaround, one could potentially use a JSON flavor which supports comments; potentially, you can even write your JSON in the YAML file with comments directly and then not convert it, since YAML is a superset of JSON).

As for documentation, yeah, it is possible to convert, but it makes it more annoying, particularly also if you then can’t easily re-use configs in another project. And if you’re working in a team, having to explain to all your team members, how they can convert the official documentation, is also not really acceptable…

I love this comment. JSON is by far the format that cares the least about being human-readable or -writable, but you’re seriously proposing writing it rather than YAML. And I kind of don’t even really disagree. But a big problem with that strategy is that you won’t find documentation for how to write the configuration in JSON.

What comes sort of close, is that you can define so-called “schemas”, at least for JSON, TOML, YAML and XML. Here’s what that might look like for JSON: https://json-schema.org/learn/getting-started-step-by-step

I don’t know, if you can actually generate a GUI from such a schema, though. They’re intended for validating existing data, so I don’t know, if they give you enough data to work with to actually provide a GUI. For example, you don’t really have a human-readable name in these. The fields are rather called e.g. “productName”.