Linked by Thom Holwerda on Sat 1st Sep 2012 21:15 UTC
Windows The Verge published a video demonstrating how desktop mode and Office 2013 - a desktop application - work on Windows RT, the ARM version of Windows 8. The video showed a desktop mode that clearly didn't work well for touch, and even Office 2013, which has a rudimentary touch mode built-in, didn't work properly either. It looked and felt clunky, often didn't respond properly, and even showed touch lag.
Thread beginning with comment 533622
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Window opportuniry
by foregam on Sun 2nd Sep 2012 21:52 UTC in reply to "RE[5]: Window opportuniry"
foregam
Member since:
2010-11-17

Hmm, where to begin? First, the home user doesn't care one bit if their os has enterprise features. What they se is this: graphics crashed, all my programs went down with it. They do not care if it's because of unstable half-implemented video drivers, nor that some enterprise-level feature is present. They want it to work and do so relatively reliably. X, due to a combination of age and driver instability, is not reliable enough on an unpredictable home user situation. Yes, you can do amazing things with it on the corporate desktop but, to 99% of users, those features will never see the light of day. The other 1%… well, they're already using X.org aren't they? [...]

In my experience it has only happened with the (pre-AMD) ATI *cringe* and Nvidia binary drivers. The Mobile Radeon chipset in particular is such a crock that it can make a strong man weep. I don't remember X.org crashing on any other hardware.

That doesn't matter if distro x (Ubuntu, I'm looking at you) decides to patch glibc and break binary compatibility. It does happen. Add to that, drivers are not stable in Linux, by which I mean that I cannot simply download a driver and load it. No, it has to match the kernel version and compilation that I have in whichever distribution I'm running. That's ridiculous. I can run drivers, 32-bit ones at least, on Windows 7 now that were created when XP was released. It's not recommended of course, but there are times when it just has to be done. I don't care, and neither does the average user, about what happens to the internal kernel APIs. That's not what I'm talking about. If you are going to change those internal APIs though, you need to keep the external interfaces the same (a userland for drivers if you will). This is what Windows and OS X do, and guess what, it works. All the user has to do is download a driver for their version of the os (or the closest available if there isn't one), install it, and go. It's not that simple in Linux and, until it is, no one except developers and corporate IT departments will adopt it. It will never be that simple because maintaining such a stable external API isn't fun. It's that 20% that no one in the Linux community ever want to do because it doesn't have the shiny factor.

Good point, but I still have to see a desktop Linux user download drivers from the Net. Most of them, third-party drivers included, can be found in the distribution repositories.

You've just said it yourself. Most people don't want to be constantly updating, and they're quite content to have a few years between versions. The bleeding edge is called that for a reason, you know.

Come back when you've actually tech supported normal users on Linux as I have. Every problem I've listed is a recurring theme and has been for the last ten years, with the exception of Pulseaudio which is newer. It works for you. It can work for me. We both have the technical knowledge to fix it when something unexpected happens. Most people do not and, while both Windows and OS X can and do break, overall they break far less often. The breakage needs to keep to a minimum for a home desktop and, though programmers don't like to hear it, that means giving up new feature X and fixing old bugs in their programs. It's not fun. It's not rewarding. You'll never get recognized for fixing bugs and keeping stability. It is necessary, however, and this concept is fundamental to the desktop experience.

For some reason these features are promoted as enterprise stuff, so that's where you get them. Debian and Scientific Linux in my experience are great desktops but don't get as much attention as Ubuntu and Fedora.

Reply Parent Score: 1

RE[7]: Window opportuniry
by darknexus on Mon 3rd Sep 2012 09:08 in reply to "RE[6]: Window opportuniry"
darknexus Member since:
2008-07-15

Good point, but I still have to see a desktop Linux user download drivers from the Net. Most of them, third-party drivers included, can be found in the distribution repositories.

Nice in theory, but for quite a few device classes there simply aren't Linux drivers. Case in point, quite a few modern printers and almost all modern scanners. Granted, it's because these drivers haven't been developed. The reason is simple: there's no standard to target. Printers and scanners are not kernel drivers anymore (thank goodness for that) however, with scanners in particular, you face several problems when developing said driver. The version of sane used, the version of glibc and other libraries it is compiled against, 32-bit or 64-bit, etc. My scanner (Canoscan 5600F) has Linux drivers, but they're almost impossible to get working and require endless amounts of fiddling because the drivers Canon have provided do not match any version of SANE other than the one in RHEL. I'll stress that I understand the reasons and I know how to get it working; I bought this model, in fact, because it's compatible with all major operating systems that I use no matter how fiddly the Linux support is. I know the Linux community would blame Canon at this point and claim they should GPL their drivers (another argument I hate) but, if I were them, I wouldn't even bother making Linux drivers until I could reasonably target the majority of systems out there. That doesn't help the average home user that just wants to scan a few pictures however. To them, it doesn't work and there's nothing they can quickly install to make it work. It either works or it doesn't, and it doesn't help that most hardware doesn't even give an indication when they buy it if it's Linux compatible or not. If the driver is in the repositories and it fully supports your device, great. If it's not, and you're not a tech, you're royally screwed even if said driver does exist because the odds of being able to install it yourself (whether in source or binary form) are close to zero even if you follow the instructions exactly. Further, if your distro updates its kernel and it is a kernel driver, it gets wiped away and you have to do it all over again, and it might not work this next time around if an API has changed.
I haven't even gone into the trouble of trying to use Linux to communicate with an iDevice which, like it or not, is something a lot of home users will want to do. That's an entire can of worms in and of itself and yes, I know this is because of the fact that the developers of libimobiledevice and usbmuxd have to reverse engineer the USB communication protocol that Apple keeps changing. A test for you though: Say that to a typical home user and see if they understand it. My guess is their eyes will glaze over a bit until you finish and then ask: "Well, will it work or not?" Note, this isn't actually a guess. ;)

Reply Parent Score: 2