3 ms·
I really wanted this same laptop, but I got the 9360 in the end because of the lack of Ubuntu support on the 9365. > Dell have decided, arbitrarily, not to sup
by rlpb 9y ago
I really wanted this same laptop, but I got the 9360 in the end because of the lack of Ubuntu support on the 9365.
> Dell have decided, arbitrarily, not to support Linux on this machine...Ubuntu doesn't seem to detect when you've rotated the screen for tablet mode or stuff like that
I suspect that this is exactly the reason why Dell decided not to ship with Ubuntu on this particular machine. I'm not sure that GNOME has support for tablet mode yet; Unity 7 (16.04 LTS) certainly doesn't.
> Maybe Ubuntu could have stopped this by detecting compatibility issues between the firmware package and the hardware.
Firmware updates come directly from https://fwupd.org/ https://fwupd.org/ I believe. Ubuntu (like other distributions) doesn't have anything to do with distribution and release management of the the firmware blobs themselves; that's done entirely by Dell I believe.
> Dell's BIOS definitely should have stopped this by detecting the compatibility issue between its own settings and the firmware package.
What exactly do you mean by "brick"? Dell explicitly don't support Ubuntu on this particular machine. If you had been running Windows, would you still be stuck? If not, I don't think you can reasonably blame Dell here. They don't QA with Ubuntu (or any Linux) on this hardware, and you knew this before you purchased.
- eli_gottlieb 9y ago>Ubuntu (like other distributions) doesn't have anything to do with distribution and release management of the the firmware blobs themselves; that's done entirely by Dell I believe. Indeed, and yet here y'all are, saying that if I didn't want a brick, I shouldn't have run Linux. Ubuntu didn't do anything to the hardware, it just queued up a Dell-distributed, Dell-released firmware update to run upon BIOS POST. Since this update was supplied by the manufacturer, I expect that at the very least, it can check for BIOS settings which render the update incompatible, and should most probably just, you know, install itself cleanly. It should never, ever brick the machine, because why in the hell is the manufacturer sending me something that bricks their own hardware? >What exactly do you mean by "brick"? By brick I mean brick. It fails POST and the several input combinations for resetting to a clean BIOS don't work either. Dell is having to send a technician to me to replace the motherboard, after which I can once again figure out the BIOS settings to run Ubuntu cleanly. This doesn't mean that Ubuntu crashes after GRUB loads it. It means the BIOS no longer loads, period, let alone GRUB and Ubuntu. >Dell explicitly don't support Ubuntu on this particular machine. If you had been running Windows, would you still be stuck? If not, I don't think you can reasonably blame Dell here. They don't QA with Ubuntu (or any Linux) on this hardware, and you knew this before you purchased. Bull. They QA their own BIOS and firmware. The whole point of firmware-BIOS-OS separation is that the operating system never even speaks to the BIOS directly. BIOS runs the bootloader, bootloader loads the OS, OS proceeds according to a standard for how PCs are run. What I do to customize the machine is my responsibility, but proprietary updates from the manufacturer are theirs. If I've altered the BIOS settings to run a different operating system, the update needs to detect the altered settings and, if necessary, refuse to run. Then I can get on with my usage of the machine I bought. It's not my job customize their firmware, nor should their firmware updates have compatibility issues that cripple the BIOS, ever, period.
- rlpb 9y ago> Bull. They QA their own BIOS and firmware. The whole point of firmware-BIOS-OS separation is that the operating system never even speaks to the BIOS directly. BIOS runs the bootloader, bootloader loads the OS, OS proceeds according to a standard for how PCs are run. The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different. Further, manufacturers usually try to unify (to some level) firmware updates for different systems into fewer actual binary blobs to reduce release engineering workload. What keeps a complex system such as this working smoothly is QA. Dell cannot reasonably be expected to spend effort on QAing combinations they clearly do not support. While the fact that your system was bricked is likely a bug that should not have happened, nevertheless I think it's unreasonable to blame Dell for this as viciously as you are doing because they do not support or QA that combination and cannot be expected to do so. That they're fixing it is the most I think you can reasonably expect. I understand that you've accidentally ended up having a poor experience here. But you can't reasonably expect that to reflect on the experience others might get following a path Dell actually supports and can reasonably be expected to actually QA.
- eli_gottlieb 9y ago>The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different. Assuming that they're all still Dell-made firmware blobs, I don't see why they'd be different at all. Anything that Ubuntu can "do to them" ought to ruin the signature. Only an authentic Dell firmware blob should actually make it through the BIOS' checks to installation. It's like saying, "look, you opened our cryptographically signed file under our system, sure, but you downloaded it through an unsupported channel."
- vetinari 9y ago> The complexity here is that the firmware updates shipped for Linux may well take a different QA path to the firmware updates shipped for Windows, as the distribution channels are different. No, the update content in different OSes is identical. The firmware is being updated by UEFI capsule; the only differing part is what puts the capsule content into it's space. There's actually a third way how to do an update: straight from UEFI.