4 ms·

This is true of Windows as well. What is your reference point for ease of use?

PeterisP 6y ago
The reference point for ease of use is either (a) having the OS preinstalled, or (b) clicking 'next' a few times and waiting some time after a download or inserting media. That's how most people have obtained their OS, they never ever touch boot settings. It must either come preinstalled by the manufacturer, or be installable from a GUI launched from their existing OS, which is what they have done if they have installed a newer version of windows than they had originally.
- fuzzfactor 6y ago
  tl;dr --first sentence & footnote only Multibooting is definitely the way to go, it could be seen 20 years ago when drive space began to outpace size needs of Windows' C: volume under typical user conditions. Every Windows PC eventually was going to have enough drive space for more than one OS, in the long run (now) room for many more. And the hardware was going to boot so fast, there was going to be no reason not to just quickly and simply reboot to Linux for the internet, or Windows for office work or gaming. But you have to be able to teach multibooting, and for that you have to practice it yourself reliably. Well, I'm here to say there are advanced geeks who are still just as bad at multibooting as below-average Windows users are at Linux. So Linux is still not flying off the shelf even though it's free, and can be added to Windows PC's without Windows users losing anything. For years now. The hardware was made for this since the beginning (using multiple floppies, then later multiple HDDs) but it could be considered a manual operation. Later DOS versions supported the IBM concept of partitioning a single HDD into a maximum of 4 primary partitions, analogous to a 4-drawer filing cabinet being replaced by a digital alternative. A folder(s) containing an OS can safely be stored in any drawer no differently than any other folder. Windows iconized DOS directories as folders as time went on. The BIOS (later a biosmenu) chooses which HDD to boot to in the original way, then further boot (menu) sectors/files on the HDD choose a partition having a folder containing an OS, then any OS treats each partition equivalently to a separate _drive_ of its own. This part of the process wasn't even that slow when PC's were 1/10 the speed. And Windows responded by salvos of bloat with each revision, sometimes in separate inter-revision events where much larger amounts of downloaded material was retained by huge leaps over what the originally issued OS started out doing, as drive space made excellent leaps in affordable space for users, the excellence was nullified. In my estimation a most Ballmerish occurrence. Also the original NT6 Vista & Windows 7 versions started out with the BOOT folder right there in the C: volume where the default bootmenu it contains could conceivably be edited easier (easier than it was later when hidden in a separate unexpected partition). Except for the NT6 boot files which became more arcane by orders of magnitude, this is by design. You need sufficient BCDEDIT skillz at the administrative command line to modify your default NT6 bootmenu, but you only needed a text editor for the human-readable BOOT.INI of NT3-5 or CONFIG.SYS in W9x. And with NT5 (or NT6 using BIOS/MBR) you could still boot (multiple) Linux(s) from the regular Windows bootmenu, but no Linux for you with NT6 bootmenu in UEFI, this is by design. No overcoming Windows SecureBoot obstacles in UEFI for Linux either until earlier this year in 2020, this only set Linux back 6 years when it comes to brand-new PC's. And all you have to do is learn how to multiboot well enough so you only have to teach people how to use a boot menu(s) in the way that everyone should have already been using now for decades.[0] Now in a FAT32 ESP with UEFI/GPT, Linux installers put their boot files alongside Microsoft's in the generic shared EFI folder, while the Linux OS itself can be completely directed to a single unused partition, /home /var /usr everything on a single type 83 EXTx volume. Without touching Windows on its established NTFS partition. It works so well, it's the closest thing to Linux on a Windows partition. Windows can make the partition and Linux can do the rest. Then you have two completely different formatted partitions each containing their native OS, and the original common FAT32 ESP containing the key EFI folder now having both OS's boot files in their own subfolders. And the proper Linux install just leaves your mainboard with a new UEFI top-priority firmware bootentry pointing to the new Linux bootfiles in their EFI subfolder, pushing the established firmware bootentry for Windows down the list in the mainboard UEFI. This is after the Linux setup process autofinds and autoadds the Windows install already present on its NTFS volume to the new grub menu so you can choose original Windows or new Linux while the UEFI is set to select the new Linux subfolder within /EFI. You can always set the mainboard UEFI back to boot to the unchanged established Microsoft UEFI bootentry instead of the new Linux UEFI bootentry, and the PC will act like Linux is not there at all, the new grub bootmenu will not appear and Windows will not normally be able to see or access the Linux partition. You could also use a built-in mainboard firmware bootmenu to manually choose between Windows or Linux during bootup, not much differently than if they were on separate HDDs, without needing any grub access to Windows, but not every UEFI mainboard even has a built-in bootmenu any more like BIOS did (BIOS could only choose from different HDDs, not the individual OS's on the HDDs like UEFI sometimes can do in addition), and they are all different but can be useful when there. ______________ [0] If a real programmer is interested, what is still missing is a new standard open-source UEFI bootmenu firmware executable. User-configurable to allow flexibly selecting which mainboard UEFI entries appear on its own menu when called, and their boot priority. And as simple as possible, to be unchanged afterward, we already have overly complex grub & Windows OS bootloaders downstream on the HDD, as moving targets. We just need a new hypervisory bootmenu upstream, to run under UEFI before booting an OS or its particular bootfiles, so there will be a standard way to select from firmware bootentries themselves. Without having to properly access the (otherwise confusing but potentially simple) UEFI boot choices manually while booting, using increasingly divergent mainboard Setup routines as more years go by. In the form of a small .efi executable to be placed on the ESP volume, which can be called from the startup.nsh batch textfile (also store startup.nsh on the ESP volume). While still being able to eventually obtain Microsoft SecureBoot signatures to any extent needed for such a useful bootmenu.efi & startup.nsh to come into simple routine use. Which if present, a startup.nsh file is already the thing addressed by UEFI before the mainboard ratchets down to booting the top-priority bootentry in its own UEFI list instead, and startup.nsh is a userfile so we would best start using it. But nobody's using startup.nsh yet, it's still not significantly underway for over 6 years now. It's just another obstacle where the resulting UEFI mainboard boot-performance landscape is ridiculously unstandard (and getting worse) by comparison to the previous BIOS approach which was never a formally published standard at all, and BIOS got better over the years. That's damage from a big UEFI foisting salvo by design, fully forseen. And Microsoft SecureBoot still looms large as a related obstacle from 2014 since they have not yet signed an open-source UEFI Shell for SecureBoot operation either. Shouldn't be essential for developing a .efi executable bootmenu program anyway, but still a bad lingering deficiency in simple UEFI utilities, and confirms Ballmer's ghost still haunts regardless of WSL or what anyone says otherwise.
  - PeterisP 6y ago
    I fail to see why I would want multiboot. If I do need to run software from two or more different OSes on the same hardware then it's strictly preferable to run them at the same time and/or switch between them without losing any context/state of the software in the other OS. I can do that decently with virtualization. Having to reboot is a really, really big drawback that's justified only if it's otherwise impossible or impractical to achieve what you need - but it is possible and practical, so multiboot is not really necessary.
  - LargoLasskhyfv 6y ago
    Or you could simply use a fast and physically small USB keychain, and start from that(maybe even loading it into RAM and operating from that(RAM DISK). For the system and programs it doesn't really matter today. They are almost all fast enough. Use the internal storage for your own data only. Use another USB-stick/keychain for another system if you need it, and so on. Sounds hacky and amateurish, but can work well, depending on your use case(s).
pmontra 6y ago
Installing Windows from scratch can be as difficult as installing Linux. OEMs preinstall it and make sure their HW works with Windows. That's the real difference.
- fogihujy 6y ago
  I'd say the more user-friendly Linux distros like Mint actually beat Windows installation experience; Windows has lagged behind recently, and there's little incentive to improve it since it's pre-installed anyway.
  - nvrspyx 6y ago
    That's still not the point. The point being made is that most people don't even install an OS to begin with. They use whatever is pre-installed.

The reference point for ease of use is either (a) having the OS preinstalled, or (b) clicking 'next' a few times and waiting some time after a download or inserting media. That's how most people have obtained their OS, they never ever touch boot settings. It must either come preinstalled by the manufacturer, or be installable from a GUI launched from their existing OS, which is what they have done if they have installed a newer version of windows than they had originally.

fuzzfactor 6y ago
tl;dr --first sentence & footnote only Multibooting is definitely the way to go, it could be seen 20 years ago when drive space began to outpace size needs of Windows' C: volume under typical user conditions. Every Windows PC eventually was going to have enough drive space for more than one OS, in the long run (now) room for many more. And the hardware was going to boot so fast, there was going to be no reason not to just quickly and simply reboot to Linux for the internet, or Windows for office work or gaming. But you have to be able to teach multibooting, and for that you have to practice it yourself reliably. Well, I'm here to say there are advanced geeks who are still just as bad at multibooting as below-average Windows users are at Linux. So Linux is still not flying off the shelf even though it's free, and can be added to Windows PC's without Windows users losing anything. For years now. The hardware was made for this since the beginning (using multiple floppies, then later multiple HDDs) but it could be considered a manual operation. Later DOS versions supported the IBM concept of partitioning a single HDD into a maximum of 4 primary partitions, analogous to a 4-drawer filing cabinet being replaced by a digital alternative. A folder(s) containing an OS can safely be stored in any drawer no differently than any other folder. Windows iconized DOS directories as folders as time went on. The BIOS (later a biosmenu) chooses which HDD to boot to in the original way, then further boot (menu) sectors/files on the HDD choose a partition having a folder containing an OS, then any OS treats each partition equivalently to a separate _drive_ of its own. This part of the process wasn't even that slow when PC's were 1/10 the speed. And Windows responded by salvos of bloat with each revision, sometimes in separate inter-revision events where much larger amounts of downloaded material was retained by huge leaps over what the originally issued OS started out doing, as drive space made excellent leaps in affordable space for users, the excellence was nullified. In my estimation a most Ballmerish occurrence. Also the original NT6 Vista & Windows 7 versions started out with the BOOT folder right there in the C: volume where the default bootmenu it contains could conceivably be edited easier (easier than it was later when hidden in a separate unexpected partition). Except for the NT6 boot files which became more arcane by orders of magnitude, this is by design. You need sufficient BCDEDIT skillz at the administrative command line to modify your default NT6 bootmenu, but you only needed a text editor for the human-readable BOOT.INI of NT3-5 or CONFIG.SYS in W9x. And with NT5 (or NT6 using BIOS/MBR) you could still boot (multiple) Linux(s) from the regular Windows bootmenu, but no Linux for you with NT6 bootmenu in UEFI, this is by design. No overcoming Windows SecureBoot obstacles in UEFI for Linux either until earlier this year in 2020, this only set Linux back 6 years when it comes to brand-new PC's. And all you have to do is learn how to multiboot well enough so you only have to teach people how to use a boot menu(s) in the way that everyone should have already been using now for decades.[0] Now in a FAT32 ESP with UEFI/GPT, Linux installers put their boot files alongside Microsoft's in the generic shared EFI folder, while the Linux OS itself can be completely directed to a single unused partition, /home /var /usr everything on a single type 83 EXTx volume. Without touching Windows on its established NTFS partition. It works so well, it's the closest thing to Linux on a Windows partition. Windows can make the partition and Linux can do the rest. Then you have two completely different formatted partitions each containing their native OS, and the original common FAT32 ESP containing the key EFI folder now having both OS's boot files in their own subfolders. And the proper Linux install just leaves your mainboard with a new UEFI top-priority firmware bootentry pointing to the new Linux bootfiles in their EFI subfolder, pushing the established firmware bootentry for Windows down the list in the mainboard UEFI. This is after the Linux setup process autofinds and autoadds the Windows install already present on its NTFS volume to the new grub menu so you can choose original Windows or new Linux while the UEFI is set to select the new Linux subfolder within /EFI. You can always set the mainboard UEFI back to boot to the unchanged established Microsoft UEFI bootentry instead of the new Linux UEFI bootentry, and the PC will act like Linux is not there at all, the new grub bootmenu will not appear and Windows will not normally be able to see or access the Linux partition. You could also use a built-in mainboard firmware bootmenu to manually choose between Windows or Linux during bootup, not much differently than if they were on separate HDDs, without needing any grub access to Windows, but not every UEFI mainboard even has a built-in bootmenu any more like BIOS did (BIOS could only choose from different HDDs, not the individual OS's on the HDDs like UEFI sometimes can do in addition), and they are all different but can be useful when there. ______________ [0] If a real programmer is interested, what is still missing is a new standard open-source UEFI bootmenu firmware executable. User-configurable to allow flexibly selecting which mainboard UEFI entries appear on its own menu when called, and their boot priority. And as simple as possible, to be unchanged afterward, we already have overly complex grub & Windows OS bootloaders downstream on the HDD, as moving targets. We just need a new hypervisory bootmenu upstream, to run under UEFI before booting an OS or its particular bootfiles, so there will be a standard way to select from firmware bootentries themselves. Without having to properly access the (otherwise confusing but potentially simple) UEFI boot choices manually while booting, using increasingly divergent mainboard Setup routines as more years go by. In the form of a small .efi executable to be placed on the ESP volume, which can be called from the startup.nsh batch textfile (also store startup.nsh on the ESP volume). While still being able to eventually obtain Microsoft SecureBoot signatures to any extent needed for such a useful bootmenu.efi & startup.nsh to come into simple routine use. Which if present, a startup.nsh file is already the thing addressed by UEFI before the mainboard ratchets down to booting the top-priority bootentry in its own UEFI list instead, and startup.nsh is a userfile so we would best start using it. But nobody's using startup.nsh yet, it's still not significantly underway for over 6 years now. It's just another obstacle where the resulting UEFI mainboard boot-performance landscape is ridiculously unstandard (and getting worse) by comparison to the previous BIOS approach which was never a formally published standard at all, and BIOS got better over the years. That's damage from a big UEFI foisting salvo by design, fully forseen. And Microsoft SecureBoot still looms large as a related obstacle from 2014 since they have not yet signed an open-source UEFI Shell for SecureBoot operation either. Shouldn't be essential for developing a .efi executable bootmenu program anyway, but still a bad lingering deficiency in simple UEFI utilities, and confirms Ballmer's ghost still haunts regardless of WSL or what anyone says otherwise.
- PeterisP 6y ago
  I fail to see why I would want multiboot. If I do need to run software from two or more different OSes on the same hardware then it's strictly preferable to run them at the same time and/or switch between them without losing any context/state of the software in the other OS. I can do that decently with virtualization. Having to reboot is a really, really big drawback that's justified only if it's otherwise impossible or impractical to achieve what you need - but it is possible and practical, so multiboot is not really necessary.
- LargoLasskhyfv 6y ago
  Or you could simply use a fast and physically small USB keychain, and start from that(maybe even loading it into RAM and operating from that(RAM DISK). For the system and programs it doesn't really matter today. They are almost all fast enough. Use the internal storage for your own data only. Use another USB-stick/keychain for another system if you need it, and so on. Sounds hacky and amateurish, but can work well, depending on your use case(s).

pmontra 6y ago

Installing Windows from scratch can be as difficult as installing Linux. OEMs preinstall it and make sure their HW works with Windows. That's the real difference.

fogihujy 6y ago
I'd say the more user-friendly Linux distros like Mint actually beat Windows installation experience; Windows has lagged behind recently, and there's little incentive to improve it since it's pre-installed anyway.
- nvrspyx 6y ago
  That's still not the point. The point being made is that most people don't even install an OS to begin with. They use whatever is pre-installed.