A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of [email protected] and The GIMP
This article is getting so many things wrong for new users ๐คฆ
Example: It would be more productive if they explained the difference between how Windows detects and installs drivers vs Linux to let people know there may be extra steps. There are no functional differences between any distro detecting hardware on the same kernel version, but some do load Nvidia drivers during install by default, as an extra point.
Some hardware doesn't play well with deb based distros vs rpm based, it would be good to point out if your install is failing with errors that another distro may work
Absolutely not a thing ๐คฃ
Where did you get this idea? Packages are compiled by architecture.
This may also come down to hardware support generally; we ran into an issue upgrading an OS from CentOS 7 to Rocky 9; where RH had dropped support for our hardware during the RHEL 8 releases.
Debian, on the other hand, still had drivers available.
Yeah, it was some BIOS bug or hardware error that halted Debs, but RPM based would show that it worked around the issue and continued. As a Debian branch whatever was missing in main was probably missing throughout all the derivatives.
I tried every single* deb based distro on a Samsung laptop from 2010. Some installed but would freeze with error mid boot, some deb based refused to install and gave error upfront. I tried fedora and opensuse and they acknowledge the error and moved on.
Whatever hardware or bios bug or error handling problem tripped up the system , it was was prevrlant through all of the Debian Branch.
And No it wasn't secure boot. That was disabled.
That sounds like you had other issues going on. That has nothing to do with packages.
There is nothing about Linux, package managers, or packages themselves that is somehow incompatible with specific combinations of each along with the hardware it is running on. The kernel is where all the compatibility layers meld.
The kernel either runs, or it doesnt.
Its not the packages its that whatever Debian built and other derivatives of Debian, used as their base, did not work with that hardware. Trust me I distro hopped a ton to try and get a Debian to work. I didn't save the error, but however the NON Debian OS WORKED AND WOULD ACKNOWLEDGE THE ERROR ON SCREEN AND MOVE ON.
Sorry did not mean caps, caplock after OS lol.
Also an OS is not just the kernel, its your tools that boot the machine and recognize hardware, and what the OS it told to do with issues. So I assume Debian bug for specific hardware, and non deb distros didn't have the bug.
I deep dive issues as my job and nature, so trust me when I say a deb derived would not work I tried more than 10+ distros deb based. Only Fedora and SUSE ones worked (because non Debian build) not because of packaging
I'm not saying that whatever happened to you didn't happen. I'm saying that your assertion of "deb based distros not working with specific types of hardware" is 100% NOT a thing. Package managers DO NOT interact with hardware.
If you had issues, it was not because of deb packages or apt and your particular hardware, it was because of incompatibilities with the software versions being installed. Has absolutely nothing to do with deb packages.
I meant deb based as in those based on Debian OS...which feeds the other Debian based offshoots. I probably over simplified by original comment, I wasn't claiming deb package management was the issue, just the relation to Debian base OS being the issue. So whatever the base OS of fedora and SUSE is worked fine (those happen to be RPM packages) maybe Arch may have worked or failed also. The point of it all was , if one fails to install, try another distro, and I my case nothing based off of Debian could deal with the hardware issue
Out of misplaced nostalgia, I keep wantimg ZD to not completely fuck up for once.
Alas, I'll have to continue waiting.
Why does everything be number lists?