🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆.
𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍
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.
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 removedty, 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? removed 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.
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?
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.
nnn has the worst learning curve, but at least the number of commands is brief and all fit on the one help page. I was wishy-washy on it until the selection improvements last year, but now I reach for it about half the time I do anything file/dir related - even the short things, and 100% for anything batch-related.
There’s a ticket for this, which has been rejected. The author believes a better approach is to keep adding variants for every minor change. I did make a comment essentially arguing your point, but @dessalines@lemmy.ml disagrees.
A good action would be to go to github and upvote the closed feature request, but I’m beginnig to believe the only option is to hard-fork the project so we can add this feature. I really hate hard forks, but sometimes it’s the only option when there’s such a fundamental disagreement.
Maybe if enough folks went and advocated for #586, @dessalines might be pursuaded.
You’re not going to get a telephone number you can call, but the documentation maintained by Arch is far superior to that offered by Ubuntu. If support is your biggest concern, you’re far better served by Arch.
I sopped using EMACS because chording is horrible for RSI and carpal tunnel. Same reason I moved off kakoune (which the author of the article mentions frequently). Kakoune is heavily chorded.
Helix is nearly pure modal, except for basic shift and some simple alt chords: most mode sequences like m-, space-, etc bring up a context menu with next-key options for the mode; it’s fantastic for learning, and for remembering those things you use so rarely you never quite memorize them.
I think at this point, what’s needed is a wiki page comparing the various forks and options. I’m not a heavy *Tube user, and I can’t keep track.
AFAICT, there are at least five active Tube front-end apps:
Active, committed maintainers are one of the most important features of any such tool, as Google constantly works to sabotage alt front-ends and timely work-around updates are critical. But some sort of feature comparison matrix would be nice.
I respect your opinion on this, and will say only one more thing: having worked in the corporate software space for decades, you don’t want their software. Most of it is utter crap. It’s a consequence of finance having too much indirect influence, high turnover, a lot of really uninspired and mediocre developers, and a lack of the fundamentally evolutionary pressures that exist in OSS. The only thing corporations do better is marketting.
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.