[moonpie@osiris ~]$ du -h $(which filelight)
316K /usr/bin/filelight
K = kilobytes.
[moonpie@osiris ~]$ pacman -Ql filelight | awk '{print $2}' | xargs du | awk '{print $1}' | paste -sd+ | bc
45347740
45347740 bytes is 43.247 megabytes. That is to say, the entire install of filelight is only 43 megabytes.
KDE packages have many dependencies, which cause the packages themselves to be extremely tiny. By sharing a ton of code via libraries, they save a lot of space.
Exactly this. Kde's graphical application store actually has a warning on arch, since pacman can be even more problematic when it comes to abstraction layers like GUI's.
At this point, rpm's and deb packages can be auto updated through their relevant package managers. And it looks like gnome software is attempting to try to get user packages installed via flatpak entirely.
Addictive arcade game about archery. Reminds me of flappy bird, not in the raw mechanics, but in the way they are both addicting in the same manner.
Gameboy roguelike that is simple, but very elegant.
Sadly, since romhacking went down, I don't think it's possible to find the translation patch for it, unless they uploaded it to the internet archive.
Also by double speak games, and open source gridland is a variant on the match 3 style. During the day phase, you accrue and store resources, and build stuff. During the night phase, you fight.
https://wiki.archlinux.org/title/Graphics_tablet
The Arch Linux kernels include drivers by the linux-wacom and DIGImend projects. linuMLx-wacom supports Wacom devices, while DIGImend supports devices from other manufacturers. Both projects publish a list of supported devices: linux-wacom, DIGImend
Due to how many devices are supported, your best bet is to simply go to your nearest store that sells them and then checking if Linux supports it against those two lists, which there is an extremely high chance it does.
Then you should also check reviews, to make sure you get a good one.
I have a Wacom Intuos CTL-4100WL, and it's served me well for math notes using Xournal++ (app for handwritten notetaking), but I truly have no idea how good it is for actual drawing related applications, as I don't do it for that at all.
I use https://github.com/Ylianst/MeshCentral
For this usecase. This also lets me do things like run admin cmd commands. It should be noted, however, that the Windows UAC prompt won't show up in a VNC session by default, you either need to configure UAC, or set up RDP.
you'd really have to verify isolation.
What if they live streamed the entire process, like on twitch?
I am building a homelab for during college (4 years) and I don't really feel like doing a release upgrade (ie: debian 11 to 12) in the middle of schooling or over a break when i wanna relax and just chill. Debian offers 2 years of support official, and like 4 extended (unluckily, the times didn't align so if I picked debian I would have to upgrade during college),and Rocky/alma offer 4 years official and like 8 extended.
I might be wrong (on phone rn), I recommend checking https://endoflife.date
Big difference, big enough that this factor is the singular reason companies go with them. Not having to do release upgrades as frequently means less maintenance, means less costly.
I'll say it again and again. The problem is neither Linus, nor Kent, but the lack of resources for independent developers to do the kind of testing that is expected of the big corporations.
Like, one of the issues that Linus yelled at Kent about was that bcachefs would fail on big endian machines. You could spend your limited time and energy setting up an emulator of the powerPC architecture, or you could buy it at pretty absurd prices — I checked ebay, and it was $2000 for 8 GB of ram...
But the big corpos are different. They have these massive CI/CD systems, which automatically build and test Linux on every architecture under the sun. Then they have an extra, internal review process for these patches. And then they push.
But Linux isn't like that for independent developers. What they do, is just compile the software on their own machine, boot into the kernel, and if it works it works. This is how some of the Asahi developers would do it, where they would just boot into their new kernel on their macs, and it's how I'm assuming Overstreet is doing it. Maybe there is some minimal testing involved.
So Overstreet gets confused when he's yelled at for not having tested on big endian architectures, because where is he supposed to get a big endian machine that he can afford that can actually compile the linux kernel in less than 10 years? And even if you do buy or emulate a big endian CPU, then you'll just get hit with "yeah your patch has issues on machines with 2 terabytes or more of ram" and yeah.
One option is to drop standards. The Asahi developers were allowed to just merge code without being subjected to the scrutiny that Overstreet has been subjected to. This was in part due to having stuff in rust, and under the rust subsystem — they had a lot more control over the parts of Linux they could merge too. The other was being specific to macbooks. No point testing the mac book-specific patches on non-mac CPU's.
But a better option, is to make the testing resources that these corporations use, available to everybody. I think the Linux foundation should spin up a CI/CD service, so people like Kent Overstreet can test their patches on architectures and setups they don't have at home, and get it reviewed before it is dumped to the mailing list — exactly like what happens at the corporations who contribute to the Linux kernel.