And? It works on iOS.

I’m missing the point. Was it that systems like Briar can’t work in iOS because they aren’t mesh net? If so, why not choose one that does, like Session?

Last time they tried this (that was Munich IIRC) it was just too early. All they really had access to was OpenOffice, which - and I appreciate all the work that went into it by all the selfless contributors! - was kind of shit. Now there are a least three office suites with decent MS compatibility, which is critical for being a functioning part of a larger organization, not to mention Office365 web if worst comes to worst. At least they wouldn’t have to roll back everything if they encounter problems, like Munich did.

This is great news.

Related, but just hanging this on here. As the default (as installed) security of distributions has improved, so have the amount of headaches when trying to use tools like this increased. For decades, when I’ve had issues like this is not been because of a LAN firewall issue, and so now my first thought is never been, “I should check the firewall,” when it should.

Sadly, firewall info is almost always locked down so that apps can’t even check by themselves and provide helpful hints to users.

Anyway, it’s been a hard lesson for me to learn, for some reason. I need to practice my mantra: it’s always the firewall.

Creative Commons is exactly the tool you need for licensing; they even have a “build-your-own” customized license tool. The tool will generate an icon, text, and a link to easily understandable legalese for your license.

CC is like GPL (but more flexible) for art, and it’s an awesome service.

Flatpack puts all app data in ~/.var?? Ewww! No thanks.

I’m cheering her on if only because any of her wins has to burn another ulcer in Trump’s stomach.

Plus, Biden might be able to beat Trump again; I’m not so sure how he’d do against Haley, especially after she’d pivot post-primary to more moderate center messaging.

I’m still glad she’s hanging in there being a distraction for Trump. She’s definitely going to lead the party ticket in 2028, though. This is just a pre-game practice for her, and the Democrat party better be paying attention. I mean, assuming Trump fails to turn his presidency into a perpetual dictatorship a-la Putin, which is still on the bingo board.

Your point is a very important one. The numbers have to come up so that manufacturers notice. It might make the difference in a laptop designer choosing a well-Linux-supported wifi chip, instead of a shitty, closed chipset like Broadcom. When the price-per-unit difference is pennies, knowing that you’re potentially losing some thousands of customers in exchange for saving a few cents per unit can make the difference in how you choose.

It also matters in user choice in the workplace. The more normalized Linux is, the more likely there will be skills in IT support, more mass-management tools, and more willingness to allow employees to choose their OS.

But where it really matters is in standards. Diversity puts pressure on software developers to use standardized and open data exchange standards. I can’t emphasize enough how important diversity in OSes is to driving creation of, and conformance to, standards, and how much of an anathema to standards monocultures are.

Even within OSS this is true: github and git have become monocultures; they aren’t standards, they’re tools developers are forced to use if they want to interact with the wider development world in any meaningful way. They’re not bad; git became dominant largely because github used to be so fantastically better than anything else available at the time; but now, their very dominance stiffles diversity and innovation. Want to try the rather exciting pijul, the patch-based spiritual successor to darcs? Fuck you, because you won’t be able to collaborate with anyone, and you repos won’t work with any proglang module systems like cargo or Go modules, because it isn’t git[1]. Monocultures are bad, whether they’re evil corporation software, or FOSS.

Higher Linux use increases diversity, encourages data format standards, and creates a healthier ecosystem. That’s why these numbers are important.

[1] Go and Rust’s cargo support more VCSes than git, but they could easily not, and I’m sure the maintainer’s of the vcs code wish they could drop support for some of the long tails - and everything that isn’t git is on the long tail at this point. There are attempts at creating some standards around this; ActivityPub has tossed around ideas, forgefriends has been trying for a breakthrough for years - none of them address the root issue of how tools can access sourcecode efficiently in a way abstracted from the underlying vcs. Any such tool currently must have some bespoke code to speak the network language of the vcs, for every vcs. And since git is the most popular, when faced with the daunting task of supporting N vcses, when N-1 of them are in toto used by a small percent of users, it’s just easier to support only git.

I think at 25 in a row it’s a silver jubilee.

Now’s a great time to learn about rate limiting and honeypots. Even so, I hope you can talk them down further seeing as you don’t sound like a large company.

Sure. My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix. It tends to get your software out there and used faster if you bootstrap the packaging - immediately, if you have an AUR account.

IMHO, Nix is unreasonably harder. There are frequently small projects that don’t get packaged for most distros. When I encounter these, I have a couple of options:

• Submit a packaging request. Hope someone is willing to accept it. Wait until it is packaged.
• Install it from source and let it pollute the core system. Hope this causes no issues. Manually track and maintain the installation. If lucky, the software lets itself be installed somewhere non-standard, in which case I can use stow and keep things a bit cleaner.
• Throw together a package for it and let my distro manage the installation.

The third option is preferrable to the others, for a variety of reasons, and it’s easy on most distros. On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

Arch. Or, rather EndeavourOS. I’ve lived with several distros (daily driver desktops, laptops, servers) for years: debian, Ubuntu, Gobo, gentoo, Redhat, CentOS, Arch, Artix, and EndeavourOS. Redhat was my least favorite, and EndeavourOS probably my most.

I’m currently running Endeavour on my desktop, Artix on my laptop, and vanilla Arch on several servers and ancillary devices. All of the Arches are basically the same day-to-day, except Artix; Artix is the lightest, but also the most work, and I probably wouldn’t choose it again.

I like Arch because - for me - it’s been stable and pain-free from dependency-hell, of which Redhat distros were the worst. I will not go back to any point release distro - rolling release has been so much better for me. The Arch wiki is the best source of Linux information on the internet, and the AUR has almost everything in it, and is easy to contribute to. PKGBUILDs are easy to write; it’s hardly any more work to put one together to install something and have it managed by the package manager, than to not.

I’m interested in playing more with some of the source-based distros like void, alpine, tinycore, venom, and kiss; my experience with gentoo leads me to believe I won’t be happy with any as daily drivers.

However, I’m very interested in Chimera.

I maintain some software, and Nix is by far the hardest to deal with. To package config files are relatively complex, and to submit a package you have to download the entire Nix repo, which is huge. Getting a package to build correctly can be a challenge.

It’s a pretty large ask for software contributors, who may have to iteract with a half dozen different distros. Now, you could say, leave it to the distro people to do the packaging, but it remains a barrier for entry and is by nature exclusive.

I don’t use NixOS, so I have little motivation to stay conversant with Nix and, frankly, it’s so demanding I don’t bother anymore. I can make RPM, deb, and aur packages trivially, and without having to hold Gb of some package repo (which I otherwise don’t use) on my disk.

I was going to suggest the opposite. I have nothing but problems with fractional scaling on Wayland, which is one of the main reasons I still run X. My main workstation has 3 monitors, and X’s fractional scaling works smoothly.

With a lot of distros defaulting to Wayland, it’d be interesting to know which OP is running, and causing them grief. Does Pop!OS use X only for now?

So, CUDA is SIMD for (or backed by) GPUs?

It is so stupid that this app is needed, and so useful.

It’s never in Recents. Recents is utterly useless unless you’re using one of the Google apps, and even then it’s unreliable.

K, this is one of those “and now I’m afraid to ask” memes, but comnents like yours have me super confused. What’s all the CUDA about?

I have 2 machines with AMD CPU/GPU hardware. SOC maybe? I really didn’t pay much attention outside of wanting the extra CPU cores for… reasons. They’re both Ryzen, one’s a 5, 'tother a 7. The GPU component has always worked fantastically, but I don’t stress it much as I’m not a gamer. The CPU component has been a dream for my many-threaded needs. And so I’m confused when people chip in about this news complaining about AMD. What, exactly, isn’t working for people, and why don’t I notice it?

It’s just wierd. Sort of vim-ish, but mostly not. The bindings are really NIH - makes sense to the author, I guess, but it could have been so much easier if a few more of the key bindings were shared with… anything else. It’s an entirely new modality I have to switch to whenever I use it.

I think the biggest stumbling block is that it’s almost vim key bindings, and the muscle memory betrayed me in the cases where it isn’t. I still have to bring up the help occasionally for the stuff I use less frequently, b/c I can’t trust it’ll be something sensibly from vim or readline.

You see what the common factor here in OP’s problems is, though, right? Flatpack and Snap - whether you’re pro or con - are new and have warts, and the distros jumping to them are “easy, beginner-friendly” ones. Sure, installing an add-on for the wrong OS for some software is bound to cause problems; that’s not a Linux-specific issue. But the sorts of issues OP is complaining about are because of complications caused by the software distribution mechanism, issues that had long been resolved on many distros.

I think I saw this in an episode of Blue Eye Samurai.