I wrote a short guide on this method recently: https://lemmy.ml/comment/6708735

Everyone fully missing the point here. This is the banner image for !linux@programming.dev (that’s not where we are right now for the record), and it has a normal JPEG size of 7.7MB. When it’s served as WebP it’s 3.8MB. OP is correct that this is very stupid and wasteful for a web content image. It’s a triple-monitor 1440p wallpaper that’s used verbatim, and it should instead be compressed down to be bandwidth-friendly. I was able to get it to 1.4MB at JPEG quality 80, and when swapping it out in dev tools and performing A/B testing I can’t tell the difference. This should be brought to the attention of a mod on that community so it can stop sucking people’s data for no reason.

Wow I feel dumb for not thinking of that. In my defense I like the text as #FFF on gray. KOReader’s arbitrary CSS snippets and style tweaks are really neat.

This is all I needed to do so: https://www.mobileread.com/forums/showthread.php?t=314220

Run the script from the second post, then eject the Kobo and let it install. Afterwards you can open it from the new NickelMenu button at the bottom right. My Kobo just stays in KOReader mode all the time.

You can change the background color by changing the ["cre_background_color"] key in settings.reader.lua (again, I dislike needing to configure it like this). On my Android and desktop I set it to ["cre_background_color"] = "0xECECEC",, which inverts into a nice gray when I set it to night mode, then I invert all the image colors so they’re a normal color. Font color can’t be changed though, TMK. You can change font color with custom CSS snippets.

deleted by creator

Have you tried KOReader yet? It’s not Material UI and doesn’t have any sort of “theme”, since it’s very focused on just showing your text, but it lets you extensively pick fonts and styles for your books, has dictionary lookups (tap and hold), page view, and it can sync with itself (available on the desktop and many physical ereaders). My main gripe is that it’s very configurable, and I don’t personally like many of the defaults. After setting it all up it’s quite powerful, and I use it on my physical ereader, Android phone, and desktop PC in roughly the same configuration.

Garf

You can circumvent this by connecting to a router that has no access to internet. It will connect to the router, fail to connect to the internet, and then you can tell it to skip the initial setup and enable sideload mode.

JXL is the best image codec we have so far and it’s not even close. I did a breakdown on some of its benefits here. JXL can losslessly convert PNG, JPG, and GIF into itself, and can losslessly send them back the other way too. The main downside is that Google has been blocking its adoption by keeping support out of Chromium in favor of pushing AVIF, which started a chicken and egg problem of no one wanting to use it until everyone else started using it too. If you want to be an early adopter you can feel free to use JXL, but just know that 3rd party software support is still maturing.

Something you might find interesting is that the original JPEG is such a badass format that they’ve taken a lot of their findings from JXL and made a badass JPEG encoder with it named jpegli. Oddly, jpegli-based JPEGs are not yet able to be losslessly-compressed into JXL files, per this issue - hopefully that will be fixed at some point.

Yes it’s lossless. JPG->JXL lossless compression is generally 20% savings for free.

Arch should be fine for university stuff. The main problem with Arch is not Arch itself, but all the software it tracks being very fresh. You’ll be pulling updates as they come down the line, and that may result in temporary bugs or day-to-day workflow changes - caused by the software developers themselves. I don’t think an Arch system is unusually unstable or prone to breaking, but last year they did brick everyone’s GRUB loaders by pushing an update too early (post-mortem here). It’s up to you, but if you want to err on the side of system/software stability I would go for Mint/OpenSUSE Tumbleweed/Debian.

I don’t have any practical experience with EndeavourOS but TMK it’s just preconfigured Arch and it uses the default repos, so that sounds good to me. Vanilla Arch is not inherently better or worse, it’s just a more minimal starting point.

I haven’t used Kali Linux before, but hcxtools is available in the Debian repos so presumably your /etc/apt/sources.list is invalid (probably the LiveUSB has disabled non-iso sources). Can you post what is in that file?

Edit: Actually it looks like Kali uses a single line for its repo. Can you add

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

to your /etc/apt/sources.list, run an apt update and try again?

Flatpak is like an alternative packaging system that exists outside of your distro’s normal packaging model, e.g. apt/dnf/pacman etc. The killer features are that Flatpaks work on any distro with a single universal package, and that the software versions will be cutting-edge without needing cutting-edge system dependencies. Flatpaks run in their own dependency network and generally don’t rely on anything from the host system - this means that you can have arbitrary software on your machine that your distro/repo maintainers don’t need to compile/quality-control/stability-test/etc. It also comes with an easy sandboxing framework out of the box as a bonus.

In my case I usually use Flatpaks to get more current versions of software without totally messing up Debian’s “Debian does not break” stability model - Debian is meticulously maintained so that its “Stable” branch only has ultra-stable versions of software, at the expense of those packages being older and frozen. If you use a distro with smaller package repos (e.g. OpenSUSE/Fedora/etc) you’ll probably appreciate finding Flatpak versions of software that you’d normally need to manually compile.

Flatpaks are cool, and they have a specific use. They’re not the end-all be-all of packaging and they’re (hopefully) not going to replace apt/dnf/pacman. As for why they hate apt I have no idea. apt is good, and you can even make it a little nicer by installing nala and using that instead of apt.

If the basis of this thread is that you’re digging for distro recommendations I’d personally steer you towards Linux Mint and OpenSUSE Tumbleweed for their ease of use. Debian is a little more difficult to set up than Linux Mint but not tremendously so. Arch is more of an “intermediate” difficulty distro where the main challenge is that your system packages are fast-moving and can break/change in small ways from day-to-day. If you aren’t comfortable with Linux you might get frustrated with minor bugs that you don’t know how to troubleshoot. Conversely, if you want to learn Linux then dealing with Arch’s shenanigans will help expose you to various parts of the system naturally.

The video is clickbait and a few of the distros are in categories just for dramatic effect. I personally share Chris’s criteria for “pointless” distros however, and I hope that his main “clickbait motive” was trying to stop people from hopping around from gimmick distro to gimmick distro when the real magic has always been with the Debian/Arch base underneath the hood. I don’t care to give Chris the attention he wants so I’d rather answer your questions instead of talk about the video directly:

I agree that Debian and Arch are “S-tier” distros. Not that they’re better than everything else for every usecase but they are very high quality community-run distros with large package bases, and they accomplish their mission statements with ease. If you’re a Linux power user for long enough you may eventually settle into one of these two distros because they give you a lot of room to mold your configuration without being opinionated by downstream distro maintainers.

Linux Mint is very good, and it’s probably the only “fork distro” that I recommend people use because it makes Debian/Ubuntu very simple and usable for new users, and it’s done so for many years with a great track record. I currently run Debian Stable but if you put a gun to my head and said “you can only run Linux Mint from now on” I’d be fine with it. Specifically, I prefer the LMDE edition but the normal version is good too.

You can run cutting-edge gaming stuff on Debian Stable and Linux Mint by using Flatpak Lutris/Steam, which uses its own cutting-edge Mesa package instead of the system’s, and you can also install a cutting-edge kernel on these stable distros by using Debian backports or e.g. XanMod. I prefer using stable distros like Debian Stable and pulling cutting-edge versions of your important packages through Flatpak or other means, which gives you a “stable base and rolling top”.

I think the general usecase for Arch has diminished from half a decade ago due to Flatpak’s popularity, and IMO a stable base setup makes more sense if you can get everything important that you need from Flatpaks. With Arch, not only are the programs you care about bleeding-edge, everything is bleeding-edge, and you may end up with annoying bugs from packages you didn’t even know existed.

If you want a more modern version of the Linux desktop without the bleeding-edge of Arch I think OpenSUSE Tumbleweed is a great cutting-edge distro. They have extensive automatic testing that ensures high system stability even while living near the edge of package freshness. The main downside is OpenSUSE’s smaller package base compared to Debian/Arch-based distros.

Try installing this AUR package: https://aur.archlinux.org/packages/lib32-libva1-compat

Architects vs developers.

I no longer use Arch, but this wouldn’t have happened to me because I used vanilla Arch. On Manjaro it can happen at any moment that an AUR package silently depends on a new part of a dependency not implemented in the older versions. The AUR does not care to figure out which exact version dependencies are needed for a program, because you are expected to always have an up-to-date Arch system before installing. If the AUR cared about Manjaro compatibility they would need to mark every dependency with a minimum version number, but that’s a lot of effort and the AUR understandably doesn’t care about supporting Manjaro’s repos. If Manjaro stood up its own AUR this would no longer be a problem.

(Personally, I don’t think AUR packages are a good idea for system stability/security even on vanilla Arch, but it is understandable that people like them for their convenience.)

r/linux4noobs -> !linuxquestions@lemmy.zip or any of the Linux communities seem to be responsive to questions. I think in these early stages the more niche communities need to exist within the larger communities. If the niche community gets too disruptive to the large community it can break out into its own community.

Arch has made a lot of mistakes, and their most recent one where they bricked everyone’s GRUB loader is the one that caused me to stop using it as a general recommendation. This sort of thing would never happen in Debian, and pretending that “every distro makes massive mistakes!” is disrespectful to distros that actually put a ton of effort into making sure these things don’t happen. Sweeping those mistakes under the rug is harmful to new users who don’t know what they’re signing up for when they download the distro that you are sugarcoating, and that is the primary reason to make sure that anyone considering Manjaro is aware of its past so they can make their own decisions.

Security updates aren’t delayed in Manjaro, they’re pushed through out of band.

Manually. Also read as: delayed. The comment from Arch’s security team that you are minimizing is part of the reason why this is a bad idea: “They just forward our security advisories without reading them. Leaving critical security issues to rot in their “stable” repositories while only pushing forward issues that are publicized or users telling them about”. Once again, why would I trust the Manjaro team to be on top of security when they can’t figure out how to keep an SSL cert alive? Their security mailing list hasn’t even been updated in a year.

Once you’ve compiled an AUR package it will remain compatible with the system you compiled it on until you update and introduce an incompatibility.

You are dodging the real dependency problem by focusing on this half. The real dependency problem is that when an AUR package updates and Manjaro’s packages are not new enough for the update, it will cause breakage. AUR packages are built with Arch Linux’s repos in mind and no care whatsoever for the versions of packages that Manjaro holds. Updating your AUR packages frequently will all but guarantee that you will eventually run an AUR update that requires a dependency with a newer version than Manjaro provides, and that app will break (or worse, the AUR package is a dependency for other apps which will cause further breakage). Even Manjaro knows this: “Using AUR also implies Arch stable branch - which is only achievable by using Manjaro unstable or testing branch.”. Also take it from their team: “The AUR is neither officially supported by Arch nor Manjaro. If you do use the AUR on Manjaro, use our unstable branch. Problem solved.”

That’s not the “Arch’s security team”, it’s one person on a 3rd party forum, with a history of issuing personal statements reeking of personal grudge. Yeah I know that comment unfortunately. It’s a singular, isolated piece of flamebait and it makes me sad to see it’s still being bookmarked and passed around 5 years later.

Yes very sad that a member of Arch’s security team made a warning about Manjaro’s security 5 years ago and still we have people pretending that it’s “flamebait” because that’s a convenient excuse to dismiss it.