Honestly, kind of most excited about std::env::home_dir() being fixed/undeprecated. That’s the kind of thing that some languages would leave unfixed for eternity, until half the community recommends not using the stdlib even for basic uses.
Linus has also declared Rust as basically inevitable before, since more and more kernel maintainers retire and not many young devs learn C anymore, at least not to a proficiency where you can handle kernel development.
You mean Gitea? Forgejo is a fork from it, maintained by a non-profit, so preferrable to most folks.
At $DAYJOB, we’re currently setting up basically a way to bridge an interface over the internet, so it transports everything that enters on an interface across the aether. Well, and you already guessed it, I accidentally configured it for eth0 and couldn’t SSH in anymore.
Where it becomes fun, is that I actually was at work. I was setting it up on two raspis, which were connected to a router, everything placed right next to me. So, I figured, I’d just hook up another Ethernet cable, pick out the IP from the router’s management interface and SSH in that way.
Except I couldn’t reach the management interface anymore. Nothing in that network would respond.
Eventually, I saw that the router’s activity lights were blinking like Christmas decoration. I’m guessing, I had built a loop and therefore something akin to a broadcast storm was overloading the router. Thankfully, the solution was then relatively straightforward, in that I had to unplug one of the raspis, SSH in via the second port, nuke our configuration and then repeat for the other raspi.
They are working on a new touch keyboard: https://invent.kde.org/plasma/plasma-keyboard
But yeah, no idea when it’ll be ready.
Apparently, the name is derived from “jetstream”, so it probably is supposed to be pronounced like cheddar. But a German who does not know that would probably pronounce it as Yetta, yes.
I have no idea, if it’s any good, but apparently this exists: https://content.luanti.org/packages/JALdMIC/aw_personaje_anthro/
I believe, you could in principle use any Blender model, although I’m guessing, they’d need to match in terms of animations. I’m not deep into either Luanti modding or Blender, so not sure how it works together, but here’s some documentation describing it: https://docs.luanti.org/models/using-blender/
[email protected] was developed as a commercial title a few years back. I believe, @[email protected] contacted the devs to get it open-sourced.
They’ve posted on Mastodon, that it is a (D)DoS: https://linuxrocks.online/@[email protected]/113995906036180301
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.
Over-full stack developer.
Well, I’m hoping, they also talked about whether she wants a public proposal. If she told him to ask her with a megaphone, whether she wants tea, then she’s hopefully sure enough. Well, and it’s not either like she’ll have to empty that cup of tea right then and there. There’s still plenty ways to back out, if she starts doubting herself.
Chances are, they’ve talked about it beforehand and it’s only a matter of making the decision public…
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:
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.
To point it out for folks unfamiliar with Rust, I consider this comment borderline misinformation.
I don’t know in what world the Rust compiler is considered unreliable. In my experience, it is one of the most reliable toolchains across all programming languages.
The Rust compiler is slow, because it does so many more checks than the C compiler, which is what these devs want. This is also barely relevant while actually developing, because then incremental compilation kicks in, which makes subsequent builds rather quick.
And Rust binaries are primarily larger than C binaries, because it does not use dynamic linking of dependencies. In the kernel, you cannot use dynamic linking anyways, because you need a running kernel to have a filesystem from which to dynamically load these.