Tim: >> I'll hazard a guess that your drive, and motherboard, mightn't have a >> 10 year lifespan. And even if fault-free, mightn't be useful in 10 >> years, either.
home user: > old system: > first hard drive - 4 years; replacement - still going. > monitors (dual-monitor desktop) - one lasted 5(?) years, the other still > going. > everything else - original components still going. > So you're right about the drive. > After 12 years, still not aware of anything I can't do other than 2K and > higher video, and better-than-24-bit color. My computing needs haven't really changed much, but software bloat, and programmers deciding there's no need to be efficient when you have a multi-gigahertz CPU and oodles of RAM, does mean that system requirements are a ever-moving goalpost. I used to be able to do all that I needed on a computer with no heatsink on the CPU, and 16 megs of RAM. I'm still doing essentially the same tasks, most of the time. Reading, writing, printing... I'm dreading the day they decide Linux needs an Artificial Idiot included internally. But there's always some change that's a major aggravation. Yesterday was a frustrating exercise "in can I upgrade my old CentOS LAN server box?" They've, now, removed the MATE desktop (probably because it needs X, and they've abandoned that), and *only* have KDE and Gnome 3 as choices (both of which I find absolutely hideous to attempt to use, for a multitude of reasons). If I'd done an upgrade over the top I'd be left with an unworkable system, fortunately it was a trial on a spare drive. I highly doubt I'd change it to Fedora, because the rapid OS churn is a pain. I want my server to sit in the background and just work. I don't want to be continually managing it. I liked an OS that was so similar to Fedora that I'm not going mental gymnastics working between the two of them. I don't like the Debian (and derivatives, such as Ubuntu) way of doing things. >> Although the kernels (and ancillary files) size has increased over the >> years, there's been a recent push (and pushback) about not just >> continually adding drivers, but removing ancient ones that no-one's >> likely to be still using. > Overall, seems like a good idea. But the SW engineers must be careful. > I'm not the only one keeping things many years. I anticipate inflation > will push more people into keeping things longer. From what I gather, it's mostly really ancient things they're considering. Which puts people with specialist applications in an awkward spot, more than the general user. I've still got a 16 bit motherboard here, it's all but useless, it's just sitting on the pile of "what can I do with it?" things. Every now and then I'd try something on it for the sake of it. Most distros *require* 32 bit hardware, these days. You can't even start an installation on it. So a lot of old stuff has already been abandoned by everyday users, because they had to. >> This is one aspect of Linux that gets a lot of stick: Huge monolithic >> kernels, where they shove *everything* in the kernel, rather than >> having the kernel just for the OS, and let all the drivers be separate >> (microkernels). There's issues of filesize, memory size, stability, >> debugging, and security, with huge kernels. And though the actual >> kernel isn't all that big, the other associated files can be >> (initramfs, especially). > Trade-off no matter what they do. Makes me glad I'm not part of the > Linux development/maintenance teams. > > Not for planning the install, but for my education and understanding: > In the context of your last sentence, what file(s) are you considering > to be the "kernel", and where (path) are they, given that you consider > initramfs* to not be a part of the "kernel"? It's like defining a motherboard. The CPU does the work, and it uses other resources available to it (memory, storage, display). So the CPU is the core of a computer, but it's not a computer without all the rest. Or like defining an OS. An OS is what boots, what organises how the system is run, and what programs make use of. The easiest part to define out of that is what *isn't* the OS. A word processor is a program that I run on a computer system, it's not the OS. But to type, to see what I'm doing, and print the results, requires drivers. To the word proc, they're part of the OS. To the OS, they're input/output interfaces. The kernel is essentially the core of programming that does the work in that OS. Which is the vmlinux file, these days. The initramfs (initial RAM file system, it's drivers, tools, and scripts) is extra things used by the kernel. And there's even more *things* that are files in the rest of the directory tree. You can take a lot of those things out of the kernel bundle of doo-dahs, and still have a working kernel. Of course it will have less in-built features. Tools can be in the kernel, or they can be files somewhere in the rest of the directory tree. The same can be said for drivers and handlers. There's a speed efficiency in not separating them out (if it's already there, in RAM, that's faster than loading from storage, again and again). There's a debugging and updating efficiency in separating them out. A programmer can fix or improve a graphics card driver, for instance, simply by updating their driver. Without having to release a new kernel, which will take much more time, and the entire kernel team debugging *it* plus everything else that's changed. Take CUPS, for example. Most of what it does are files in /usr (in bin, libs, sbin, subdirectories). (Do "rpm -ql cups" in a command line to see.) It doesn't need to be in the kernel. My old Amiga 1200 had an interesting hybrid system. There were two ROM chips with most of the OS in them. You could boot from a disk that added more features (more commands, more drivers), but it could boot up in a simpler mode without them. Plugged in hardware such as interface cards, had their own ROMs with default drivers and they were read by the system at bootup and incorporated into it. You could install files to your system from a disk that provides updates of many things that were already in the ROMs (if there was a command or driver provided as a file, it was used instead, rather than reflashing firmware code - with all the risks that entails). It's kernel was very small. The OS was expandable beyond its original designs. And you didn't have to keep on changing your OS to improve your system. Someone comes up with a better file browser, or graphical interface to some feature, it's a new system library file (or files) installation, and everything improves without the major upheaval of changing OS. You had many years of running the same OS, and being able to acquire software that ran on it. And programmers had a system stability (I'm talking about "stability" as stable known features, not system flakiness) they could develop software on it, rather than having to continually relearn what the OS required of them. To me, having to change the OS so often is a pain. Imagine having to rebuild your entire house just because you wanted to change the furniture in the lounge. It's one reason why commercial software is nearly always Windows or Mac. They've got a *few* long-term systems, and long-term customers, to exploit. Not of course ignoring that private Linux users are generally non-paying customers for their entire OS and software collection, and are firmly in that mindset. There are commercial users of Linux, paying for software and service. But as far as I can see, it's mostly serving-related. But long term stability is also an anathema to commercial exploitation. They don't just want to sell you one thing, once, they want you as a repeat cash cow. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
