> It’s a targeted advertising machine that is extremely effective on kids and teenagers. It preys on them so, so efficiently. It’s a technical work of art. A young mind is extremely susceptible to the algorithms on those platforms. Much more than adults are, and adults are already really susceptible.
Sure, but the Australian government's definition of an age-restricted social media platform doesn't mention advertising or algorithms at all. Technically, their definition also covers algorithm-free social media like Mastodon, which I'd argue isn't nearly as harmful.
The framing of social media as something that's inherently bad no matter how you do it is a framing that helps social media giants like YouTube, Instagram and Facebook to continue to "do it" in a way that harms people. I'm sure they love the idea that the ills of social media can be solved by banning their least profitable users while doing nothing to regulate what they do with the others. They're probably thrilled that their healthier algorithm-free competitors haven't even entered the conversation. They want to be the tobacco companies of the future, because making addictive things for adults is incredibly profitable.
> (though this isn't the case for Anubis) the cliche inappropriately dressed inappropriately young anime characters dawned as mascots in an ever increasing number of projects
I think the fact that people bring up things that the Anubis mascot isn't when talking about Anubis is more telling of their own harmful (and potentially racist) biases against Japanese-styled media than it is about the idea of having anime-styled mascots for free software projects.
To be fair there are a lot of games on Steam that don't have DRM, which means you can just drag them out of the steamapps folder to a computer that doesn't have Steam and they work fine. The decision to add DRM comes from the developer/publisher, not Valve.
Did you forget about Vulkan? Valve and AMD are Khronos members and active contributors to the Vulkan spec. Games like Baldur's Gate 3 and Civ VII use Vulkan on Deck. There's a complete graphics ecosystem with full participation from the games industry that doesn't have Microsoft as the gatekeeper.
The more I think about it, the harder it is to recommend anything else for the average Windows gamer/prosumer but first-time Linux user.
- Rolling release, so you don't have to do a major upgrade twice a year - which would otherwise be much more often than Windows.
- Latest kernel and graphics drivers, so it works with newly released hardware with the best performance.
- Steam, NVIDIA drivers, H.264/H.265 codecs, Gamescope, GameMode, MangoHud, etc. all in the default repos - a huge boon for new Linux users compared to having them in an external repo like RPM Fusion or having to install them manually, which can otherwise cause confusing dependency problems over the life of the installation.
- Nothing unusual about it that would be confusing or cause compatibility problems. It's just a normal mutable binary distro with a normal package manager, upstream packages, glibc and systemd.
The biggest issue is the lack of an official graphical installer, but while the install process is intimidating, it's not very difficult for people who are patient, can follow detailed instructions, and have a vague idea of what a partition and a bootloader is.
I don't think being able to migrate your account addresses the rugpull concern. The rugpull scenario is that one day, in five years or so, bsky.app drops all AT Protocol support and transforms into a Twitter-like centralized social media website. The problem isn't that the account will stop "existing" but that Bluesky users will stop seeing it. The average non-techie Bluesky user who doesn't know about the AT Protocol won't even notice the change, except that, from their perspective, a tiny percentage of nerdy users have stopped posting. For you, "migrating" your account away is effectively just deleting it from the now-centralized Bluesky and willfully decreasing your audience by 100-fold or more.
The problem is a social not a technical one. It doesn't matter how good AT Protocol is at account migration. The vast majority of AT Protocol users think of themselves as Bluesky users and don't even know what the AT Protocol is. If the official Bluesky clients move away from the AT Protocol, the majority of users are moving with Bluesky.
For all the UX concerns people have with Mastodon/ActivityPub, at least they make it obvious that different users are hosted on different instances, and no one instance has more to gain than it does to lose by defederating.
It worked on my device. The page you linked looks very outdated and doesn't have my device's board or any device made in the past 5 years. The lists of unsupported devices also look pretty reasonable - old kernels, CPUs that don't support virtualisation and 32-bit ARM. Since modern ChromeOS uses the same virtualisation to run Android apps, I doubt there's a modern device where it doesn't work.
Sorry, but "CLI stuff" is not "as far as it goes" with desktop Linux apps on ChromeOS. ChromeOS provides Wayland and PulseAudio servers to the apps as well so GUI and audio works too. It even synchronises file associations and installs a ChromeOS-like GTK theme into the container. The Linux GUI apps I had installed back when I used it felt completely native.
I got a ChromeOS device a few years ago and it was great. I think they get an underserved bad reputation from being the locked-down devices you're forced to use in schools, but a personal ChromeOS device is a capable computer that can run any Android app or desktop Linux app.
Though having said that, in the past year I've replaced ChromeOS with desktop Linux (postmarketOS) and I love it even more now. 4GB of RAM was a bit slim for running everything in micro-VMs for "security," which is what ChromeOS does. I've had no trouble with battery life or Android emulation (Waydroid) since switching.
I only need to look at one file[1] (context[2], and it used to be worse[3]) to decide that I don't really want Hyprland, or anything else from that quick-and-dirty culture of software dev, on my system. Encouraging plugins to hook any function or method in a C++ program is insane. I'd be surprised if a Hyprland setup with multiple plugins could ever not be alpha-quality.
I don't see how AI can become democratized. (I don't follow this stuff too closely, but) it seems like larger models with less quantization and more parameters always outperform smaller models of the same type, and that trend isn't stopping, so if/when we get consumer hardware and local models that equal today's SotA SaaS models, the SotA SaaS models of that time will be even better, and even more impossible to run on consumer hardware. Not to mention that local AI is reliant on handouts from big business - both in base models that the community could never afford to train themselves, and in high-VRAM GPUs that can run big models, so if SaaS AI is more profitable, I don't think we'll be "allowed" to run the SotA at home.
Human skill was already democratized in that anyone can obtain skills, and businesses have to be good at managing those people if they want to profit from those skills - ultimately the power is in the hands of the skilled individuals. But in the hypothetical AI future, where AI has superhuman skill, and human skills are devalued, it seems like there will be a more cynical, direct conversion between the money you can spend and the quality of your output, and local/self-hosted AI will never be able to compete with the resources of big business.
As I understand, the AGPLv3 requires the corresponding source code to be provided under the same license, so the Arch guys wanting an AGPLv3 source package isn't just a niche Arch-specific concern or a "packaging issue," but a licensing requirement that can't be ignored or delayed.
> All you need to do is omit the Enterprise feature flag during compilation, and what you get is a 100% AGPL-3.0 build.
Maybe I'm misunderstanding, but my interpretation of this issue[1] is that Stalwart contains AGPLv3 licensed functions that call into the SEL licensed `has_tenant_access` function, among others, and that the affected functions are not conditionally compiled out of the AGPLv3 binaries. @afontenot says on that issue that they don't believe it's "possible to use Stalwart under the AGPL at present." Are they wrong and can that issue be closed?
I am also concerned about the webadmin. A free software program that downloads proprietary code on first start isn't free software in practice, and since there aren't two separate SEL and AGPLv3 licensed builds of the webadmin on GitHub, that must be the case.
> So while the optics of this situation may look rough from the outside, I promise it’s not some “open source in name only” kind of thing. It’s just one of those painful balance acts between building features, maintaining packages, and paying the bills.
I get it, but it's disappointing that AGPLv3 compliance is so low in the list of priorities that this licensing issue has been known about but not solved in 8 months, all while receiving grants intended for free software projects. That balancing act must have included the consideration that the free software community is regularly burnt by rug-pulls (Redis) and trust isn't easily won back once its lost.
> And hey, if you're heading back to Maddy, no hard feelings. But the door’s always open if you want to give Stalwart another shot down the road.
I might. Sorry if I've been harsh, but it's only because Stalwart is a very cool project. A FOSS all-in-one mail server written in a safe language is exactly what email needs, and since learning about it, I've been worried that it's too good to be true. Please don't let it be. I don't think it will gain the momentum to replace Postfix if it can't be packaged in Linux distros due to licensing issues.
I checked my repo to see which Stalwart version I was running and if I could update, and I was surprised to find that the Arch package has been deleted due to FOSS licensing concerns[1], the most severe of which seems to be that Stalwart can no longer build without proprietary code[2]. Other smaller issues include the fact that the web admin interface isn't included in the source distribution, but is downloaded from GitHub on first run, and _also_ seems to contain proprietary code[3].
These issues, which would be showstoppers for a real free software project, and pretty easy to fix if you were the rightsholder of the code, were promised to be fixed "in a few weeks" in September last year, and "in a few months" in January this year, however they're still not fixed, which means I can't upgrade - not that I probably want to anymore. I truly believe in free software, so I find the idea of using "open source" as an empty marketing bullet-point for at least eight months to be fairly distasteful. Might be time to switch to Maddy.
No, it's definitely a win for Linux. I get it. I've dabbled in software minimalism. I love native dev. I know the web "sucks." But the range of mainstream software available for Linux has exploded now that software is moving to the web (including Electron) and I can't see how that's a bad thing from the perspective of a Linux user. Of course I'd rather open a web browser to run an app than change my entire operating system to run an app.
There are even games like Infinity Nikki with anti-cheat that allows the Steam Deck but specifically detects and blocks desktop Linux. You have to wonder if that gets them any real security since the method they use to detect the Deck is probably spoofable.