They rewrote the in-kernel support for NTFS a while back, and it works much better now. The old driver lacked proper write support and was kind of questionable in general.
They rewrote the in-kernel support for NTFS a while back, and it works much better now. The old driver lacked proper write support and was kind of questionable in general.
Unfortunately, modern web browsers are horrible pigs. No matter what distro you put on this thing, interacting with webpages will be s-l-o-w. (I have a similar laptop—2 GB RAM, Athlon64x2 CPU—running Gentoo, and while it’s functional in its primary job of “larger-screen video iPod for 720p or less”, starting a browser takes a while.) The niche your friend wants to make this machine fill is about the worst one possible for it.
Custom kernel (Accessory, rare):
Thing is, even when Ubuntu’s software has been packaged outside Ubuntu, it’s so far failed to gain traction. Upstart and Unity were available from a Gentoo overlay at one point, but never achieved enough popularity for anyone to try to move them to the main tree. I seem to recall that Unity required a cartload of core system patches that were never upstreamed by Ubuntu to be able to work, which may have been a contributing factor. It’s possible that Ubuntu doesn’t want its homegrown software ported, which would make its contribution to diversity less than useful.
I’d add irrational hate against Canonical to the list of possible causes.
Canonical’s done a few things that make it quite rational to hate them, though. I seem to remember an attempt to shoehorn advertising into Ubuntu, à la Microsoft—it was a while ago and they walked it back quickly, but it didn’t make them popular.
(Also, I’m aware of the history of systemd, and Poettering is partly responsible for the hatred still focused on the software in some quarters. I won’t speak to his ability as a programmer or the quality of the resulting software, but he is terrible at communication.)
And you have fixed versions every half a year with a set of packages that is guaranteed to work together. On top of that, there’s an upgrade path to the next version - no reinstall needed.
I’ve been upgrading one of my Gentoo systems continuously since 2008 with no reinstalls required—that’s the beauty of a rolling-release distro. And I’ve never had problems with packages not working together when installing normally from the main repository (shooting myself in the foot in creative ways while rolling my own packages or upgrades doesn’t count). Basic consistency of installed software should be a minimum requirement for any distro. I’m always amazed when some mainstream distro seems unable to handle dependencies in a sensible manner.
I have nothing against Ubuntu—just not my cup of tea for my own use—and I don’t think it’s a bad distro to recommend to newcomers (I certainly wouldn’t recommend Gentoo!) Doesn’t mean that it’s the best, or problem-free, or that its homegrown software is necessarily useful.
On the one hand, diversity is usually a good thing for its own sake, because it reduces the number of single points of failure in the system.
On the gripping hand, none of Ubuntu’s many projects has ever become a long-term, distro-agnostic alternative to whatever it was supposed to replace, suggesting either low quality or insufficient effort.
I’m . . . kind of torn. Not that I’m ever likely to switch from Gentoo to Ubuntu, so I guess it’s a moot point.
My experience (which is admittedly many years out-of-date) is that WINE isn’t very good at anything except games, because games are what the people who use it and work on it are most interested in. When other software works, it tends to be as much by coincidence as anything.
Money isn’t important. Some complex software is, in fact, maintained by unpaid volunteers who feel strongly about the project. That doesn’t mean it’s easy (in fact it’s quite difficult to keep the lights on and the code up-to-date), but it is A Thing That Happens despite being difficult.
What is important is the size of the codebase (in the case of a fork, that’s the code either written for the fork or code that the fork preserves and maintains that isn’t in the original anymore), the length of time it’s been actively worked on, and the bus factor. Some would-be browser forks are indeed trivial and ephemeral one-man shows. Others have years of active commit history, carry tens or even hundreds of thousands of lines of novel or preserved code, and have many people working on them.
If you’re interested in doing the tech equivalent of a party trick (except that it’s less interesting to watch), go ahead and try. You’ll probably just end up reinstalling almost every package on the system that differs between the base distro and the offshoot. Harmless, but also pointless, since you could just have installed Debian from the get-go and saved yourself a lot of trouble.
There are a whole bunch of Very Silly Things you can do in the Linux world that aren’t worth the effort unless your income relies on the creation of niche Youtube vids. For instance, it should theoretically be possible to convert a system from Debian to Gentoo without wiping and reinstalling. I’m not going to try it.
Gentoo supports either configuration, as it does with a lot of things. My systems were installed with split /usr and I have no intention of changing that, because the merge adds no value for me.
Even if the original issue had anything to do with ISOs, he’s way overestimating the level of protection on many install ISOs, in my experience—they’re just disk images, and presumably all the files read off them are passing through Ventoy itself. Even if you find one that performs some kind of verification, easy enough to change a jump instruction to a no-op somewhere in the machine code guts of a file as it passes through Ventoy, and prevent the verification from executing. (The difficult part is figuring out which instruction to change, but people have done it before.)
It can’t inject anything into the ISO files at rest without bricking then, and I don’t know if an OS that doesn’t verify it’s own image before booting.
As far as I can tell, this is not talking about ISOs installed using Ventoy, but precompiled blobs of things like Busybox that are included in the Ventoy install package. It’s an important distinction. The developer could bundle a tampered blob, include in the documentation the checksum that matches that blob, and then if someone checks with the upstream project and calls them out, say something along the lines of, “Oh, they must have withdrawn that release,” and replace it with an untampered blob. If they don’t fight to preserve the tampered blob, they might even get away with it.
-o PubkeyAuthentication=no
should only work if the server is configured to allow password auth at all. I believe the advice these days is to disable password auth completely for security.
Configuring captive portal wifi without network manager or any aids beyond what’s provided by wpa-supplicant. Eventually I gave up, since it wasn’t really that important.
Adjusting freetype so that it works more-or-less the way I want it to, because the maintainers hate anyone who disagrees with their current hinting algorithm and make the setting as opaque as possible. I would prefer it if they allowed me to have hinting on some fonts and exclude only the ones that were designed to be pixel-aligned, but unless something’s changed recently, that option isn’t even offered.
Gentoo is its own thing. You can bump packages yourself a lot of the time with a few commands. Or have the package manager install directly from upstream source control, if that’s your bag. Or you can hold on to older package versions for periods ranging from months to years, by stashing ebuilds in a local repository. At the same time, portage has reached the point where it bends over backwards to keep you from breaking stuff by accident. If you’ve done your setup right and use primarily stable keywords, breaking changes are very rare. And you’re free to install things outside the protection of the package manager, or package things yourself if you don’t mind working with bash scripting.
The tradeoff for all of this is that you have to spend a fair amount of time setting up and configuring stuff, and a fair amount of time compiling software if you want a USE flag combination other than what’s on the binhost. It also helps to spend time learning the ins and outs of the portage/ebuild ecosystem if you’re going to do anything unusual.
As for the proprietary nvidia drivers specifically, Gentoo currently has versions 390.157, 470.256.02, 525.147.05, 535.183.01, and four different 550+ available, which should cover most hardware of the past several years.
If you want to see whether certain software has been packaged without installing Gentoo, the best place to check is gpo.zugaina.org. The search function isn’t all that bright, but it’s the only site I know of that indexes all the official overlays and the Gentoo bugzilla along with the main repository.
I don’t know how Debian’s solution works, so I couldn’t say for certain. Gentoo usually installs the different package versions to their own directories, and there are methods for selecting a “system python” (or lua, etc) which is the target of the /usr/bin/python
symlink. Other versions have to be called with qualifiers (for instance, python3.10
). Python libraries installed through the package manager may install to one or several versions depending on the content of a couple of environment variables, and applications that need python can request a specific version if they need to, or accept the system python if they don’t care. (Note that python2 is no longer eligible to be the system python—you need at least one python3, although 2.7.18 remains in the package repository and can be installed as well if you really need it.)
Of course, if you’re not a programmer, you can leave the defaults for everything alone, and most of the time it should Just Work.
One problem with distro packages is that you can only install one version.
This isn’t technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn’t done universally for all packages.
It used to be much, much more difficult than it is today, but your experiences will still vary according to what type of printer you have. The problem is drivers. There are still printers out there that have no working Linux driver (mostly old, non-Postscript-supporting, with no Mac drivers either). Some will work with a generic driver, but some features aren’t available. The more annoying case is the one where the manufacturer put out a driver once, many years ago, it doesn’t work properly with modern versions of CUPS, and they can’t be arsed to revise it.
But most printers these days will do basic one-sided 100%-size prints out of the box, and that’s all many people need.
Some level of self-discharge happens over time with even a disconnected battery, but that does seem greater than expected. I’d suspect hardware issues, to be honest. Batteries are fickle little creatures that deteriorate over time no matter what you do. Maybe it’s misreporting the amount of charge left to the OS.
One thing people reading this should remember is that you cannot guarantee all packages on a Gentoo system will be updated simultaneously. It just can’t be done. Because several of the arches affected by this are old, slow, and less-used (32-bit PowerPC, anyone?), it’s also impossible to test all combinations of USE flags for all arches in advance, so sooner or later someone will have something break in mid-compile. For this change, that could result in an unbootable system, or a badly broken one that can’t continue the upgrade because, for example, Python is broken and so portage can’t run.
The situation really is much more complicated than it would be on a binary distro whose package updates are atomic. Not intractable, but complicated.
That being said, even a completely borked update would not make the system unrecoverable—you boot from live media, copy a known-good toolchain from the install media for that architecture over the borked install, chroot in, and try again (possibly with USE flag tweaks) until you can get at least emerge --emptytree system
or similar to run to completion. It’s a major, major pain in the ass, though, and I can understand why the developers want to reduce the number of systems that have to be handled in that way to as few as possible.
It matters, because it’s a tool. That means it can be used correctly or incorrectly . . . and most people who don’t understand a given tool end up using it incorrectly, and in doing so, damage themselves, the tool, and/or innocent bystanders.
True AI (“general artificial intelligence”, if you prefer) would qualify as a person in its own right, rather than a tool, and therefore be able to take responsibility for its own actions. LLMs can’t do that, so the responsibility for anything done by these types of model lies with either the person using it (or requiring its use) or whoever advertised the LLM as fit for some purpose. And that’s VERY important, from a legal, cultural, and societal point of view.