Hacker News Reader

I don't understand your assertion that unmodified Linux does not work "as well as on any desktop" on Dell laptops. I'm typing this on an XPS 13 9343, running the mainline Linux kernel from the Arch Linux repositories, and everything works flawlessly out of the box (WiFi, Bluetooth, touchpad, audio, OpenGL, webcam, extremely low power consumption, etc). To be fair, kernel patches were necessary to fix some issues with the behaviour of the sound card when the laptop was new, but right now everything as reliable is as you can hope for. Granted, it only has Intel's built-in GPU, but that is more than enough for what I do on this machine.

Another thing I really like about Dell is that their products are designed to be repairable. The service manuals for their computers are freely available online[1] and even private customers can buy replacement parts directly from them. I've replaced the keyboard and the hinges on the screen before, and soon I will get a fresh battery to extend the life of this lovely machine even longer.

[1] e.g. for my laptop: https://downloads.dell.com/manuals/all-products/esuprt_lapto...

Mainline Linux eventually works on Dell laptops, like most vendors, but I've learned the hard way that this is far from guaranteed and out of the gate most laptops that come with Linux (not just Dell) are modified.

You can see the disclaimer that Ubuntu puts on all their certifications:

https://certification.ubuntu.com/hardware/201410-15913/

.. Which may well not apply to this laptop in particular, but it absolutely applies to laptops I've used.

Notably absent from the certification list is the XPS 15, which is sad because personally it's the one I'd want. From what I've seen of Linux running on XPS 15, it isn't great, though it is "functional."

Typing from my dell xps 15... what "isn't great" about it?

I bought a 9343 XPS 13 on release and it was horrible. Overtime it got better, but on first boot here is a list of issues it had:

* Resume from suspend didn't work and often left machines in an usable state. Relatively simple workaround was to disable suspend but definitely caught you off guard the first couple times.

* Keyboard would insert multiple characters per key press. This made the machine unusable without an external keyboard.

* There was a null pointer issue in the WiFi driver so if you were connected to WiFi but tried to switch networks it would trigger a full blown kernel panic. Workaround was to buy a USB -> Ethernet adapter so you could line in your network.

* Track pad issues to the point that the laptop required an external mouse.

I don't know if I remember all of the issues, but you can dig through the Dell Sputnik forum to find all sorts of old forum posts about issues...here is one from my own post history:

https://www.dell.com/community/Linux-Developer-Systems/Vario...

I spent a lot of time reporting, debugging, fixing, and helping other users try to fix issues in the early days.

In Dell's defense, they upstreamed the fixes so fixing a lot of the issues like resume from suspend and the keyboard was as simple as updating kernels. Additionally, the null pointer WiFi driver bug was fixed in a subsequent driver release.

But these changes didn't get included until several kernel releases later and the only way to unbrick/make the laptop usable was to hotfix/upgrade your kernel to an unstable version. But for a $1500+ laptop to come out of the box in an unusable state was extremely painful for early adopters. And I would say that my experience was far from perfect.

Sounds like they have improved greatly and I am still a tremendous supporter of the Sputnik effort at Dell (and overall fan)...but I (personally) wouldn't dismiss people's comments about it being imperfect.

that list reads like my typical woes with MS Windows... half the time or more they're caused by the hardware, not the software: ask anyone who does device driver programming.

back in the day (Windows XP era) i bought components and built a gaming computer, nothing extravagant but Windows, because games. there was a very narrow window between the newly installed vanilla OS booting up and BSODing. the problem disappeared once i managed to install drivers from the CD that came with the motherboard (had to act quick before the BSOD would hit).

hardware is crap.

    commit 277918494930ec3fb0c7fdbd4d35060a3bc6d181
    Author: imp <imp@FreeBSD.org>
    Date:   Thu Oct 25 17:17:11 2018 +0000

        Update comment for AMI00[12]0 override.
     
        The AML is even stupider than always returning 0. It will only return
        non-zero for an OS that reports itself as "Windows 2015", at least
        on the Threadripper board's AML that I've examined.
     
        Those AMLs also suggest we may need this quirk for AMI0030 as well.
        There may be other cases where we need to override the _STA in a
        generic way, so we should consider writing code to do that.

    diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
    index 515370d5584..bed7ecd411c 100644
    --- a/sys/dev/acpica/acpi.c
    +++ b/sys/dev/acpica/acpi.c
    @@ -2222,10 +2222,10 @@ acpi_DeviceIsPresent(device_t dev)
            status = acpi_GetInteger(h, "_STA", &s);
  
            /*
    -        * Onboard serial ports on certain AMD motherboards have an invalid _STA
    -        * method that always returns 0.  Force them to always be treated as present.
    -        *
    -        * This may solely be a quirk of a preproduction BIOS.
    +        * Certain Treadripper boards always returns 0 for FreeBSD because it
    +        * only returns non-zero for the OS string "Windows 2015". Otherwise it
    +        * will return zero. Force them to always be treated as present.
    +        * Beata versions were worse: they always returned 0.
             */
            if (acpi_MatchHid(h, "AMDI0020") || acpi_MatchHid(h, "AMDI0010"))
                    return (TRUE);

The laptop I witnessed had issues with sleep and resume (simply didn't work out of the box, sometimes wouldn't resume and other times would resume inappropriately and overheat in a bag) and very bad issues with audio. It was a coworkers laptop and they gave up after a while.

    > > I really want unmodified Linux to work as well on my laptop as it does on nearly any desktop I've built.
    > I don't understand your assertion ... everything works flawlessly out of the box ... To be fair, kernel patches were necessary to fix some issues ...

'needs kernel patches' != 'unmodified'

> And I don't mean what Dell does - I'm grateful for what they do, but I really want unmodified Linux to work as well on my laptop as it does on nearly any desktop I've built

While I'm very happy to see the work System76 are doing, I don't think this characterization of Dell is quite right. I'm typing this comment on a Precision 5510 that runs Arch flawlessly. It runs Arch flawlessly because it's not burdened with NVidia graphics -- I can well imagine that would be a nightmare, as I have to deal with NVidia's terrible hardware on several workstations.

Avoid Optimus like a plague if you are using Linux. There are quite decent Thinkpads with Ryzen/Vega APUs these days (like A485) which should work fine with upstream kernel and Mesa. But of course it's still Lenovo, so various blobs like UEFI remain.

While I agree generally on most distros, it works really well with Arch and is pretty easy to setup:

- https://wiki.archlinux.org/index.php/NVIDIA_Optimus

- https://wiki.archlinux.org/index.php/PRIME

Arch Linux is nearly entirely unusable with this Thinkpad, which is a shame since that's my distro of choice usually. I fiddled with drivers for a good while but was getting severe issues hanging with proprietary Nvidia, and Nouveau simply crashed on boot. I'm currently on Fedora, which is one of the few distros that seemed to work without crashing all the time.

Most painless config for me is to enable Nvidia only when I really need it. Say when I need to run a graphic-heavy application I spawn up a new X11 process running atop Nvidia drivers. For daily stuffs, I stick with Intel drivers

I got Arch working fine on a Thinkpad with a GTX 900m series card. I just followed the guide for bumblebee. This was a good number of years ago though, but it still works with updates and all

Nvidia blob doesn't really support PRIME properly. You can't use integrated GPU (Intel) to run your DE, while offloading specific heavy tasks to discrete one (Nvidia) which is kind of the main point. If you want to use PRIME, stick to AMD / Mesa.

Are you sure about that? I could swear when I was running Arch the DE was using my Intel GPU. I used either optirun or primusrun to use the Nvidia GPU. Granted, it was a pain to setup and I never could figure out why HDMI connected to a monitor would not work but was fine with a TV.

> I used either optirun or primusrun

Neither is PRIME. PRIME would mean doing something like:

    DRI_PRIME=1 glxinfo

Which will run it on one GPU, and display through another. Bumblebee is a workaround for this mess, not a proper upstream solution.

I have two system with integrated and discrete GPUs:

1. Intel Haswell + AMD RX460 (Desktop)

2. Intel Haswell + Nvidia GT750M (XPS 15 9530; Arch Linux)

Ultimately, I switched to using the discrete GPU on both systems.

Desktop: PRIME with Intel + AMD worked quite well (even with Steam applications running on the AMD GPU while the desktop was running on the Intel chip), but every now and then it caused the system to freeze, which was the reason I turned it off again :-/ Maybe I will try it again sometime in the future. But putting the additional energy costs aside, running the system exclusively on the AMD GPU is just fine (stable System + enough 3D performance for most games).

Laptop: Since nouveau had still the frequency issues last time I checked, I was mostly using the Intel GPU. Someday I was fed up with not being able to try any fancy new machine learning/neuronal network/CUDA based examples that I decided to install the proprietary Nvidia driver. I don't know what it is, but for me, the experience with the open source drivers feels much better (maybe the broken v-sync with the proprietary driver?!?). Every single time I come in contact with the Nvidia driver I wish that damn company would either die or provide (or at least support) open source drivers (and I don't really care about the license that much, the open source drivers just have a quality the proprietary ones lack).

When did support for the APUs get added to the kernel? My wife got fed up with Windows a couple of years ago, and I tried to set up a dual boot on her HP laptop, but Ubuntu wouldn't display anything above 800x600. The best I could tell was that there just wasn't support (at the time) for her AMD APU, but I can't remember which model it was. All the drivers I found on the AMD website only officially supported 14.04, but even 14.04 wouldn't recognize the proper screen resolutions. I've been meaning to try again since 18.04 was released (or at least see if anything had been added to the kernel), but I haven't gotten around to it yet. Fingers crossed...

Depends on which APU you have and which features you need. The latest Raven Ridge APUs had stability problems until 4.17, anything older should work on 18.04 which ships 4.15. HDMI/Displayport audio support for the older models landed in 4.15 but wasn't enabled by default until 4.17, so in 4.15-4.16 you have to pass the amdgpu.dc=1 kernel parameter for it work.

I recommend 4.19+ if you are planning to use one with Vega. Anything lower will have problems.

Don't use drivers from AMD site, use upstream kernel and latest Mesa release.

I have the A485, Windows is oddly a shit show with drivers. But linux is great with Arch and proton gaming. With the fat battery, it has great battery to boot

I will say Ryzen APU is very janky. The new model should be coming soon. Though it took a year and half for the first mobile apus to become obtainable.

> The new model should be coming soon.

Do you mean ones with Zen 2 / Navi? It might take a while, CPUs and GPUs aren't even out yet.

Not zen 2 / navi. There were some possible kernel patches for zen+ apu. There was a refresh coming for the desktop apus. I can't recall the name though. AMD has been really quite on the mobile front though :\

I see, thanks!

For a GPU we might get something based on RISC-V but not open source. That would already be a huge improvement if that was based on the RISC-V Vector ISA.

Esperanto systems will sell an IP core called ET-Graphics that should be able to handle a laptop workload.

The question is just if somebody will actually build end-user computer with that product. Its designed for machine learning after all and that is their core business.

> And I don't mean what Dell does - I'm grateful for what they do, but I really want unmodified Linux to work as well on my laptop as it does on nearly any desktop I've built.

Maybe I've been lucky, but over the last few years my rule has been "buy Dell" and Linux has just worked without any modifications. That includes laptops and desktops (I've replaced everything at home for everyone and at work) and I've never had problems.

This was the biggest pain point to me when looking for a new laptop. I wanted something where I could game after a day on the road lightly But no NVIDIA, It doesn't help AMD has subpar graphics performance per watt compared tt pascal.

I will say all my intel thinkpads were flawless with arch. My new a485(ryzen apu) is almost there

Speaking of System76, my 2011 Gazelle Pro has Nvidia graphics. It's never worked right, and is the only problem I've had. (Actually, it's a Sager Clevo.)

un-modified linux works fine on my xps 13 9360

I can throw basically any distro (at least anything that's fresher than debian stable) on it and all the hardware works out of the box

a laptop with open firmware would certainly be nice though