The fat32 formated partitions are EFI System Partitions used to boot your PC. I assume that sda3 is the one Windows created, while a later Linux install created sda5 as an alternative. Yet sda5 doesn’t seem to be really used (with that cute 9MB used), so your Linux boot stuff -including a bootloader that would allow you to start Windows (or you picking directly from EFI?)- is probably all sitting alongside Windows’ EFI stuff in sda3.
In fact I wouldn’t touch anything there without some backup.
in the name of nvidia of all corporations
So that’s the conversion you are hallucinating and reacting to, instead of my simple light remark that “nearly a decade after support dropped is not the usual definition of old”. Explains a lot.
I have not clue who you think or rather hallucinate to talk to… Go troll someone else.
And it’s wrong. You can downvote me every single time, yet reality will not change.
I you’ve got an old piece of hardware with nvidia hardware you know the pain. Nvidia stopped supporting 390 drivers back in 2022.
That’s literally the beginning the post setting the baseline for “old” here.
Sure it is, but I would call my hardware old already. Your “old” means reaching end of support life nearly a decade ago (390 was the last one released with support for those cards… in early 2018 - don’t know where you got 2022 from, that’s when they dropped everything pre-Maxwell).
an old piece of hardware
“old” does an incredible amount of heavy lifting here: nvidia390 is the one supporting 15 year old Fermi Cards. 😆
yes
yes
only if your hardware agrees and you can do without some features
as just an init system: no, but you get a much more complete package
who cares?
with Cinnamon DE: very Windows-esque UI
While I support the general advice, “very Windows-esque UI” is not a benefit for less tech-literate people. It’s the former Windows-users that conditioned themselves to expect Windows UI with all it’s shortcomings. The average elderly relative who doesn’t use anything but ~3 pre-installed programs does not care normally and can get much eaiser and more intutive UIs than those close to Windows.
Yes, the system expects regular updating. But Arch is entirely pragmatic. What has enough popularity and a mainainer to do the work will be kept in the repositories, even more if you include the AUR (also stuff moving between them when popularity and/or demand of packages changes). And because it is constantly moving on with new packages a lot is kept in parallel: There are a lot of packages in the repos in different versions, one being cutting edge, one being the lower version dependency for other packages not upgraded yet.
For reference: Yes, Arch for example expected you to update to the new open source NVIDIA drivers the day NVIDIA dropped the Volta, Pascal and Maxwell cards (GTX 1080 and below). But at the same moment the nvidia-580xx driver was introduced to the AUR, including explicitly being supported officially still. And the same happened every time a set of hardware got dropped (nvidia-470, nvidia-390, nividia-340), still kept unofficially for legacy reasons as long as it’s technically feasible. So I can in fact still run graphics cards from 2006 20 years later…
Or for another example: Yes, Arch runs kernel 7.0.12 right now and updates the kernel on a weekly basis. Yet it also has the LTS version 6.18 (guaranteed to get support until end of 2028 upstream) fully supported in the repos. And again, including the AUR I can still run the oldest still officially supported (until end of this year) long-term-support Linux kernel 5.10.
And those are basically the most extreme examples in terms of losing support, one being the constantly developed core of the whole system, the other on proprietary drivers of a private company. Otherwise the amount of 1990s tech still support by Linux is actually insane.
— Written on an ancient toaster (AMD FX series from 2011, gtx750ti from 2014, non-EFI motherboard) running Arch… which nowadays runs -given: older- games with better performance than years ago, because “the newest stuff” does introduce constant improvements and optimisation instead of new drains on your ressources like you are used to because they want you to buy new stuff.
While I understand the idea in general Tux, the penguin, is basically freely available, do whatever you want with it, and you are explicitly encouraged to integrate the design into Linux related projects… as long as you mention the author should someone ask (source)
I wouldn’t even buy a pre-fabricated sticker but do one myself. But that wasn’t the question…
PS: the Impressum here or here, down at the bottom labeled “Impressum”?
You could click the link already provided above. Just the Table of Contents at the top gives you a good overview about issues with Brave without reading anything else…
upgrade to next kernel version != patch the kernel with backported security fixes
Debian daring to suggest that using your real name to identify yourself on the system is a reasonable choice for most people. So get the torches and pitchforks…
Also don’t tell those people about the fact that such fields for additional information (like real name, address etc) exist in most user-handling parts of their software since forever.
You get asked for your real name when creating a new user for longer than Linux even exists. It’s just that noone actually cares. But now that’s suddenly an horrific anti privacy policy because the narrative demand that it is.
deleted by creator
Have in mind that compressed filesystem would be slower.
Often the opposite is true, depending on case. Compressed files load faster, so if you have the cpu power to spare (which you usually have in games while loading) and loading speed is the bottle-neck then compression speeds things up, often considerably.
And even in the age of ssds processing data and moving it through ram is much faster than the disk, so even for writing some amount of transparent compression is possible without affecting speeds.
Might be just my experience but what actually keeps people from switching is a proper support time line. Long-term and rolling releases can keep people using them for years after which they actually know what they want, what they can get used to and they don’t wanjt. Most distros however screw up something at the inevitable upgrade long before that, which then leads to “well, guess I could reinstall and try something else anyway”.
Setups like Android or those new fancy ummutable distros don’t actually make anything more secure. If the underlying OS is drectly exploited they don’t protect you. Not having a mechanism included to get you root permissions regularly, doesn’t help you against exploits achieving the same in unplanned ways. In fact -allthough that’s a minor issue- you can probably specifically target the latter distros even after a patch: After all we are talking about direct changes to binary code here. On that level you could get ideas about manipulating the overlay to access the unpatched files.
In the end the most effective way to be more secure is not a mass produced thing like Android that locks out everyone (and not even being that good at it because there are masses working to circumvent it to get control over their device back), but to minimise you attack surface: Don’t have stuff activated you don’t need. Have a kernel compiled for your device with only exactly the components you really need. Or whitelist all kernel modules you need and nothing more. Explicitly declare what a user can do and access actively (see: SELinux, AppArmor with strict policies) instead of relying on the underlying passive permission system.
Gnome normally brings their simple GNOME Document Scanner (
simple-scan), KDE comes withskanliteorskanpage.xsaneis an older GTK-based frontend, there’s also the GIMP plugin usingxsane.NAPS2is an independent fully-featured frontend. And a lot of dedicated OCR software (including stuff likeOCRFeederorPaperwork) also supports sane.PS: even the basic tools support previews, then letting you select only the specific area you want to scan.