1. 11

  2. 5

    I don’t think it’s fair to say installing Linux on an older laptop is a poor experience. From my personal experience, installing Linux on laptops 2 years or older of age is a great experience. As opposed to a shiny new laptop with Nvidia Optimus and some new wireless chipset.

    I run Linux on a couple of laptops, and have done so for a decade now. Linux support does not become worse as time goes on.

    1. 2

      I’ve had three or four pieces of hardware that used to work with Linux, but don’t any more. Largely this is because Linux refuses to provide a stable API, so out-of-kernel drivers that aren’t actively maintained won’t work on newer kernels. Specifically I’m thinking of qc-usb (Logitech QuickCam) and synce (Windows CE devices). The *BSD approach to this kind of thing seems much better.

      1. 2

        I have installed Linux on numerous laptops over many years–many distributions, Red Hat-based, Debian-based, and in recent years Arch (which I use on my desktop). I have never had a totally successful configuration of any distribution on any laptop. Resuming doesn’t work; or it works when you suspend to RAM but not to disk; or you can resume but then the audio doesn’t work, or the USB, or the wifi; or these things can be made to work but require manual intervention after resume.

        FreeBSD did work quite a bit better (after extensive configuration), but still wasn’t perfect. I haven’t tried OpenBSD. At this point I just run OS X on my laptop, even though I find it deeply frustrating to use (once you are used to a good tiling window manager anything else feels pointlessly clumsy), simply because suspend and resume works perfectly 100% of the time and I never have to deal with it and I can just hand it to a normal person to use without having to say, “oh, the wifi doesn’t come up after resume but it’s easy to work around, you just have run systemctl restart whatever, now let me spend half an hour explaining to you what a terminal is and how you use it.”

        1. 1

          Not sure which world you live in.

          I have a brand new mid-2013 MacBook Air 11" 1.3GHz for just a few weeks (couldn’t pass on the 799$ sale), brand new OS X 10.9 with no third-party drivers installed; freezes all the time; just right now the sound has stopped working (neither the internal speakers, nor the headphones jack has any output; all after simply playing some online radio from within Safari; restart, and it’s fixed). The ssh over WiFi doesn’t work properly, because the WiFi chip goes into sleep mode after 0.2s of no traffic, causing huge delays when typing (there’s a workaround with ping -i0.2 of your local gateway (now let me spend half an hour explaining to you what a terminal is and how you use it)).

          I had an OS X 10.8 mid-2013 MacBook Air 13" 1.7GHz from work before that, which froze frequently, too; although on that one I did have some external drivers installed, so, I wasn’t sure who was to blame. A MacBook Pro 13" would freeze when connecting / disconnecting several iOS devices. An older aluminium MacBook 13" would loose sound system-wide when playing VLC and doing rewind, requiring a reboot. An iBook G4 before that, which I’ve used for some BlueTooth development, also experienced frequent freezing.

          1. 1

            My MacBook Air is from 2011 and has none of those problems–it does take a number of seconds to fully resume after a suspend, but everything works: wifi, sound, SSH (I’m usually using it to connect to my Arch box and use Emacs under screen), etc. I’m certainly willing to believe that the newer devices are flakier; I haven’t had any experience with them.

            1. 1

              When on WiFi, and without any network activity (no downloading/streaming/radio/background-updates), with just the passive ssh sessions being active (not being actively used), what do you get from:

              ping -i1 `netstat -rn | grep -m1 ^default | awk '{print $2}'`


              sudo ping -i0.2 `netstat -rn | grep -m1 ^default | awk '{print $2}'`

              If the round-trip time results vary significantly, like they do for lots of OS X users on various versions and with different hardware, then this means that all your first-during-this-0.2s-interval keypresses in ssh are likewise delayed by the same amount of time.

        2. 1

          As a concrete example, my Thinkpad x220 had about 7.5 hour battery uptime when I installed Linux to it after opening the box. Now I have 8 hours with the same battery, which also has lost 20% of its maximum capacity.

          1. 1

            Exactly. I have a Toshiba Portege R500 (2007!) which still works perfectly out of the box, with battery life matching my new Lenovo Thinkpad Yoga.

            The latter has several issue with Linux, despite being an Intel graphics device (specifically, there have been serious problems with its USB subsystem just stopping and wireless and the touchpad not working when waking from suspend - both problems are only present on Linux).

            I feel like Linux laptop support in newer models is degrading though. At the end of 2012, I installed Linux on a Sony Vaio with Nvidia Optimus hybrid graphics, and everything worked fine out of the box, I only needed to install Bumblebee to get the dual graphics working. Earlier this week, I expected the same experience on a ThinkPad W530 and lost a day and a half before having a system that works, but is still pretty unreliable. Of course, those are only 2 samples, and the general trend might be something different entirely.

        3. 4

          Another in a long line of Theo de Raadt trolls.

          Where does he think virtually all *BSD drivers come from? Oh that’s right, they’re ported from knowledge gleaned from Linux, or often, share the same code that was developed for Linux.

          1. 1

            I disagree, this not how driver development works on any platform.

            There’s the kms/drm graphics stuff (which is intentionally MIT licensed so it can be used in BSD and elsewhere), but otherwise there’s not some mountain of unattainable knowledge or code to glean from Linux. Hardware reference information, vendor reference drivers (which could be Windows, Linux, or BSD), talking to vendor engineers, and bit banging and reverse engineering are how drivers are birthed.

            Read http://en.wikipedia.org/wiki/Theo_de_Raadt#Free_driver_advocacy and the section below it. OpenBSD’s ACPI stack is one example of clean and fresh engineering.

          2. 2

            Hardware compatibility issues are really a curse on Windows and Linux. This is the main reason why I moved on from Linux to Mac: I was so tired of spending time solving driver issues (touchpad, graphics, webcam, Wifi, Ethernet, suspend and resume, etc.). Steve Jobs eventually convinced me there is some value in controlling the whole design system!

            I believe that the only way forward for Linux on the desktop is a strong cooperation between the distro and the hardware maker, like what Ubuntu and Dell did for the XPS 13 (Sputnik) or what Google did with the Chromebook Pixel.

            1. 1

              I used to be in the Mac camp for that reason, but power management has been horribly broken in the past two generations of both hardware and software.

              1. 1

                That’s interesting. I’m a recent Mac convert so I have no idea how it was a few years ago. What problems have you noticed?

              2. 1

                Google did with the Chromebook Pixel.

                While google used awesome hardware in the pixel, and it is an awesome machine.. they also used obscure, completely closed hardware for things like the trackpad and touch screen (for which - no alternatives exist). Totally not the direction I would like to see things go.

              3. 1

                That may be true for Ubuntu, Fedora or any other mainstream distros that aim to be user friendly (I have had this experience with couple of Ubuntu servers and co-worker’s computer [Ubuntu] really doesn’t work that great anymore), but it’s not necessary true for Arch Linux, Gentoo or any other distro in which you have full control of what is happening. Of course, it comes with cost of need to have some knowledge about what are you doing.