Interesting Links for 31-08-2012

[andrewducker]

• What Killed the Linux Desktop
  (tags: linux software operatingsystems )
• Apple Rejects App That Tracks U.S. Drone Strikes. Huzzah for censorship!
  (tags: apple censorship usa military )
• Antarctic may host hundreds of billions of tons of methane.
  (tags: antarctic methane globalwarming )
• Why Johnny can’t stream: How video copyright went

Comments

[steer]

What Killed the Linux Desktop Hmm... cf the usage stats here

[andrewducker]

Windows covers pretty-much as much hardware - and does so by keeping driver API solid for long periods of time. The biggest problems with Windows 2000 and Windows Vista when they launched was lack of drivers due to a new driver model, and that's something they try to avoid. If you're going to cover large amounts of hardware then you want to make it as easy as possible for the manufacturers to write drivers for you - which is something, as the article makes clear, that the kernel developers aren't interested in.

[steer]

Windows covers pretty-much as much hardware - and does so by keeping driver API solid for long periods of time.How often do you install windows from scratch? My experience is that if you install windows onto a new machine it is every bit as difficult to get hardware working properly as Linux. Most users do not see this because they don't do a "from fresh" install. Last time I did this the windows install took ten hours longer than the linux install (which took an hour). I still get the odd crash full-screening flashplayer on windows

[andrewducker]

Never had any problems with Windows 7 - the drivers installed instantly, and worked just fine from scratch, grabbing new versions from Windows Update as you go. Versions of Windows from the early days certainly had problems, but nowadays it all works completely smoothly so far as I can tell.

With the two networks printers I have, I just clicked the button to add a networked printer, it scanned the network, found it, and installed the drivers. The only proprietary driver I needed there was to be able to scan remotely.

DirectX is entirely backwards compatible. If you install the latest version then it includes support for older versions, and I tend to find that graphics Just Works nowadays, and has for a few years.

The kernel people, including Linus, have stated in the past that they have no interest in keeping the binary driver interfaces stable - they want open-source drivers that are recompiled whenever the kernel is.

[steer]

DirectX is entirely backwards compatible. If you install the latest version then it includes support for older versions,

Sure -- but it wasn't in the bad old days. I will say that now it is pretty smooth... though I never did get my sound card to work reliably with windows in my current machine. Eventually I fell back to using the less powerful on motherboard sound card.

Never had any problems with Windows 7 - the drivers installed instantly, and worked just fine from scratch, grabbing new versions from Windows Update as you go.

You have been very lucky. I've had horrible, horrible problems with many windows versions including windows 7. I guess I am the type who fiddles with stuff and reinstalls often so I'm more prone to coming across these things. Probably install windows once every other year on average (that's over several machines) and linux once a year (more often because it's much quicker to do).

With the two networks printers I have, I just clicked the button to add a networked printer, it scanned the network, found

[andrewducker]

That article starts off by agreeing with me!
"What you want is a stable running driver, and you get that only if your driver is in the main kernel tree."

The problem is that many drivers are _not_ in the main kernel tree, nor are they likely to be, and they _are_ affected by the changes.

Of course, there are incompatibilities at all levels - but there's no reason to not support multiple sound systems. If your drivers work correctly then they can be called by a wide variety of different subsystems without a hitch.

[steer]

That article starts off by agreeing with me!

At a superficial level -- but then goes on to point out that the best way to get a stable running driver is not stable kernel binary interfaces.

The problem is that many drivers are _not_ in the main kernel tree, nor are they likely to be, and they _are_ affected by the changes.Many? I'm not that convinced. Or rather, OK you're technically correct that there are many drivers not in the main kernel tree but when was the last time you needed one. In the last five years I've needed

[andrewducker]

So we agree that there are many drivers not in the mainline tree, and that this is an issue for those drivers.

Personally, I've never needed a driver not in the mainline tree, because I don't run Linux (well, except as a core part of Android, where all of that is taken care of for me). The few times I've tried to run Linux long-term I've run into fairly major problems quite quickly, and stopped.

[steer]

So we agree that there are many drivers not in the mainline tree, and that this is an issue for those drivers.We agree that there are many drivers not in the mainline tree. It potentially could be an issue for those drivers but I've never encountered such a situation to my knowledge. The non mainline tree drivers I've used have not been hurt by the situation. While the number of drivers outside the mainline tree will only increase (because nobody's going to reincorporate some 12 year old bit of hardware) the proportion of users affected will decrease because things are swiftly put into the mainline tree -- so the issues I had with drivers outside the mainline tree were only issues because it takes time for Ubuntu to get the latest kernel -- that is the lag from new hardware->hardware drivers written and incorporated in kernel->your OS uses that kernel

[andrewducker]

Both my routers almost certainly are, my Synology NAS definitely is. I don't have a satnav, lacking a car (or license).

Anyway, getting back to the article, Miguel isn't actually (now I go and re-read the article) saying that the problem _is_ the constant breaking changes in the kernel API - he's saying that this set the tone, and that everyone else then does the same - including changes to things like the sound infrastructure. And, one assumes that he'd know, being the founder of GNOME.

[steer]

Ooops -- *blush* you are correct. I picked up the wrong thing from the article. I think we've been barking up the wrong tree quite loudly with this discussion

[andrewducker]

I'm equally as guilty. I posted something, only half-remembered it the next day, and rather than going back to first principles decided to pick holes in what you were saying. Not a _great_ argument technique!

[steer]

I did read the whole article but sort of speed read the step from "kernel programmers" to library/userspace stuff so I thought he was advocating the idea that a stable kernel API would fix things... his other points are not so bad.

[danmilburn]

The key sentence from that article being: "(remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech .)"

Well, at least we all know where we stand.

Meanwhile, every time there's even a minor kernel update on my machine at work, I have to remember to reinstall the graphics card drivers. If I forget, then I can't run X. So now I just don't ever update the kernel. Nvidia are, of course, unlikely to GPL their code.

[steer]

Wow. Old school. Which distro still needs that, I will for sure avoid it. Ubuntu sorts this automatically.

[danmilburn]

This is CentOS 5. Which I have to run at work, because it's the only Linux distro our software officially supports. It is of cousre massively out of date, but graphics drivers are certainly an case where the ones from Nvidia/AMD are unlikely to ever be included in the kernel source tree. And, well, I've never had to reinstall my graphics drivers after running Windows Update.