From: nospam@needed.invalid   
      
   On Wed, 6/4/2025 10:35 AM, Alan K. wrote:   
   > On 6/4/25 10:20 AM, Dan Purgert wrote:   
   >> On 2025-06-04, Alan K. wrote:   
   >>> On 6/4/25 9:53 AM, Dan Purgert wrote:   
   >>>> In general terms, the easiest approach is installing from scratch on the   
   >>>> new hardware, and then copying your $HOME across.   
   >>> Are there any hardware configurations in the $HOME directory?   
   >>   
   >> What do you mean by "Hardware Configs" ?   
   >>   
   > I guess now that I think about it, any "hardware" specific stuff would not   
   be in a user folder, that would mean if you had 20 different user logins,   
   you'd have to have the same configuration in all 20 user directories.  Way   
   too much duplication.   
   >   
      
   On some OSes, the hardware drivers are distinguishable by   
   their using .ko as a file extension (I used to have some   
   stuff like that on the Apple "UNIX"). Windows uses .sys   
   for some things like that.   
      
   Maybe the file command has some distinction in the value it coughs up ?   
      
   There should be some way for a user to figure out the "hardware"   
   files that a modprobe might discover on every boot. The Linux OS   
   is adaptable, and the drive can be moved from one machine to   
   another, and a lot of hardwares are dynamically discovered   
   (as long as, say, a "class driver" happens to cover them).   
      
   The video is a bit different, in that there are multiple   
   drivers, and some need to be blacklisted so the "right ones"   
   giving a "best result" are loaded. Occasionally, things   
   like Broadcom Wifi are also like that, there are multiple   
   versions of drivers written by different bodies and some   
   steering is required for a result.   
      
   Video drivers on all OSes have "fallback" behavior. That's   
   partially what MESA is for. An example of a "right way to do it"   
   is the XVesa driver on Puppy. I don't think it is Direct Render Mode   
   (DRM), but the name implies it works on the assumptions of a VESA   
   compliant frame buffer is present on each video card. There   
   were only a couple Matrox cards, that weren't quite compliant   
   (leading to a discovery of what "non-compliant" video looks like).   
      
   But you would think these "drivers" are in a common tree,   
   and if users keep "tearing off with $HOME", the file system   
   arrangement has to allow for that part disappearing or new   
   accounts being created. There has to be a "system" part of   
   the file tree. There's a distinction between /usr/local/bin   
   and /usr/bin and /usr/sbin . The sbin being utilities   
   a "root" might use. We can't have user inspired code builds   
   pooping into /usr/sbin . That's how the tree develops, a   
   place for everything, and everything in its place.   
      
   When a new kernel is added to your OS, that's typically a   
   "genkernel". And if you open that in the kernel building   
   menu, you'll find a large quantity of material is turned on.   
   But you can go in there and remove everything not needed   
   on your current machine. Such a kernel file output ends up being   
   smaller. and you can also set build flags for the compiler   
   to generate "code for a Core2 Duo". And then the code runs   
   fastest on your Core2 Duo. But then, if you move the disk   
   to a radically different machine, there are going to be   
   lots of error messages, warnings, or just flat out stuff   
   not getting mounted. That's a good reason for a "genkernel"   
   to be present on your hard drive -- it covers off a   
   certain percentage of the problems caused by moving   
   a disk to another machine and trying to boot.   
      
   That's one of the reasons a user should try the Gentoo distro.   
   The Gentoo Handbook, leads you step by step through installation,   
   and it's like a tour of the Hollywood Stars. Since you're doing   
   a lot of the steps manually, you get to learn what a "chroot"   
   is and why you might need it one day. When I tell a person   
   to use "Boot Repair", it's because i don't want to be   
   explaining what a chroot is, and what the canonical form   
   of chroot commands is this week :-) The Boot Repair works   
   on Debian stuff, but when I unleashed it on Fedora, it   
   was "a swing and a miss". You kind of expect that.   
      
      Paul   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)