You're looking at it the wrong way. At the moment, there are two OS vendors that make OSs designed for consumers to use with digital media [...]
Gillmor didn't make those qualifications, so, no I am not looking at it "the wrong way".
Also, at this point, there is no reason why Linux couldn't become very widely used with consumers. Technically and in terms of ease-of-use, Linux with Gnome or KDE is comparable to Windows and Mac OS X, and Linux has a full complement of media viewers and creation tools. All it takes now is for more vendors to ship it preinstalled on supported hardware. And if both Windows and OS X go over to the dark side, the fact that Linux is easy to use and available matters. Actually, an ill-advised adoption of DRM by Windows and Mac OS could really help Linux in the consumer space...
What you describe leaves open the analog hole. Hollywood and the RIAA don't want that to happen, and Microsoft has given every indication that they intend to cooperate.
Most likely, what will happen is that Windows will continue to be able to play non-DRM content, but it will refuse to create non-DRM content unless you buy very expensive "professional" versions of the software and hardware you use, software and hardware that puts your signature on everything you create. Windows may also simply start putting non-DRM content under DRM without even telling you.
Mac OS X is becoming, whether by design or by accident, a Digital Rights Management operating system where the rights in question are the user's rights
So far, most operating systems other than Microsoft Windows are giving DRM a cold shoulder. Windows is the exception, not the rule.
In fact, it's hard to see how DRM could work if there were a lively, competitive market in operating systems, media software, and hardware. In some way, DRM can only work if Microsoft keeps 95%+ of the market, which is kind of scary, because it means that Hollywood is going to do what they can to support Microsoft's monopoly.
Lots of startups fail, so it isn't surprising that lots of first movers fail. If you have a significant head start on complex technology, your company will probably still do better than the average startup.
As for TiVo, they just didn't and don't have any particularly distinguished technology. DVRs had been around in research labs and as prototypes for a decade before TiVo came out. TiVo was simply the first to market at the point when disks and processors became cheap enough. DVRs are a technologically simple commodity consumer item, and that implies very tiny profit margins that only the large manufacturers can survive on. TiVo's attempts to generate revenue by selling subscriptions didn't help either: consumers know that program schedules already effectively free and that paying $12/month (or whatever it is) is way too expensive.
Don't you think e.g. ksycoca is a cool idea? Isn't automatic updating a good idea?
I'm sorry, perhaps I'm missing something. Are you excited about the fact that ksycoca notifies applications about configuration changes while the application is running? That may be impressive if you come from Windows, but the X11 resource system has had that for a long time.
Have you ever even seen how X resources work? Have you seen tools like "editres" in action? With a compliant toolkit, you can click on an application, get its widget tree, change properties or event bindings on the fly, and save your changes. Of course, it doesn't work with Gnome or KDE, and there is nothing equivalent.
dcop is also not high bandwidth
Well, then standard X11 IPC mechanisms should be sufficient and DCOP is not needed, which is kind of my point.
I am pretty sure, that they gave a lot of thought to these issues
Yes, but that doesn't mean that they made the right decisions. KDE and Gnome were really written with a Windows-like frame of mind: a single, local display under full control of a single environment. I think the people who started working on it didn't even appreciate the hard problems that X11 and X11 toolkits were already addressing when those projects started. And while the KDE and Gnome codebases are a lot cleaner than Xaw and Motif, functionally, they have thrown us way back.
In fact, neither Gtk+ nor Qt are really X11 toolkits--they are Windows-like toolkits that happen to run on X11. Someone should probably take a new stab at creating a modern X11 toolkit from the ground up. See here for some related work: XCB, Gettys, Sharp.
begin fixing the problem by focusing on GNOME rather than on KDE.
They are hacking both Gnome and KDE. But when they hack Gnome, it's simply "Gnome development" for the reasons you observe. When they hack KDE, well, some KDE developers complain.
There is nothing "modern" about a mess of configuration files in ~/.kde.
Evidently, gimp is triggering a bug in gtk's xdnd implementation, or it might still use the old obsolete motif dnd specification.
Maybe KDE should then also implement the "obsolete motif dnd specification".
Which X convention exists regarding event binding?
I can rebind events to actions through X resources. The mechanism works pretty well. KDE and Gnome have their own, incompatible, and more limited mechanisms as far as I can tell.
Bullshit. DCOP is a simple IPC/RPC mechanism built to operate over sockets. Either unix domain sockets or tcp/ip sockets are supported
And what makes you think that one application can connect to the sockets of the remote DCOP server? What happens if they can't? And why does DCOP seem to start up for everything if very few applications actually ever need high-bandwidth inter-client communication? If the KDE folks had put their mind to it, they could have figured out how to do high performance communications through an X11 server without opening sockets behind my back--it's not rocket science.
Overall, I'm not saying that KDE is bad, I'm saying it's living on its own continent, slowly drifting away from the X11 mainstream. That's fine--whatever makes people happy. But as far as I'm concerned, it's good that RedHat tries to create a version of KDE that's a little closer to the rest of the world. They won't fix what I would consider the major problems of KDE (or Gnome, for that matter), but maybe they make it at least a bit more usable for people who don't want to sell their soul to a single desktop.
Did I say it was different from Gnome? Both desktops, in fact, commit many of the same interoperability sins. But we are talking about KDE here and what RedHat is doing to fix the problem at the KDE end.
I hope RedHat will get around to doing a Gnome make-over as well. I also hope that RedHat will start hacking Gnome and KDE applications more deeply to remove dependencies on specific desktop environments from all of them.
Gimp and the KDE file manager, for example. KDE blames it on the Gimp, but it works fine with everything else.
"KDE flaunts many X11 conventions" Which? Give some examples.
Handling of defaults, resources, command line options, event bindings, widget trees, inter-client communication (via a separate server rather than the X server), among others.
Gnome apps do the same on KDE. nautilus e.g. starts esd, gconfd-2, nautilus-throbber, bonobo-activation-server and medusa-idled.
What's this obsession with Gnome? Did I even mention Gnome? Gnome has many of the same problems that KDE has, but Gnome isn't the subject of this discussion.
"it uses its own audio output" Pardon what? It's a sound daemon and afaik compatible to esound.
I have never seen it be compatible with "esound". xmms, for example, doesn't work when it is set to "arts" output and run under Gnome.
"KDE's drag-and-drop does not interoperate fully with non-KDE apps" Example? Btw which KDE version are you running?
File manager to Gimp, for example. I'm running the latest version in Debian (although I'm not running it very often anymore).
"KDE flaunts many X11 conventions" I don't understand this, is this bad?
Yes, it's bad. It makes KDE applications interoperate less well with the rest of X11 and requires more effort on the parts of users to figure it out (unless, of course, they only run KDE, which is the not-so-secret master plan of the KDE effort).
"KDE is probably due for a lot more cannibalization in the future." You're a troll.
I'm sorry, but how is a simple statement of what I believe is going to happen to KDE "trolling"? I think the mainstream future for KDE applications is that the useful ones will be picked apart, KDE desktop dependencies removed, and reused as part of a unified Linux desktop. RedHat has only begun down that road. You are free to disagree. Insults, however, won't get you anywhere.
For DVD playback, games, etc., you get an Xbox. For running Linux, however, a low-end PC is a better choice: easier to install, with more disk space, etc. Easy enough to understand?
I have found that KDE has become less and less interoperable with other desktops: it uses its own audio output, Gnome and other applications that were formerly listed in its menus seem to have disappeared, KDE's drag-and-drop does not interoperate fully with non-KDE apps, and KDE flaunts many X11 conventions. If you try to start up a KDE application under a non-KDE desktop, it starts up big, noisy background processes. Under Debian, installing KDE automatically made kdm the default on my machine.
The KDE attitude seems to be that there is a war to win for the Linux desktop, while other efforts are more geared towards providing interoperable toolsets of which you can reuse as much or as little as you like. Fortunately, KDE code is open source, and it is entirely appropriate for RedHat and other developers to pick apart the KDE distribution and code and reuse whatever parts are useful. That's how open source works: if a project fails to meet the needs of its users, it gets cannibalized and its parts reused. KDE is probably due for a lot more cannibalization in the future.
applying free market principles to software dev
on
Open Source Studies
·
· Score: 3, Insightful
Open source is really in many ways what happens when you apply free market principles to software development: people participate, and their contributions survive, based on actual needs, capabilities, and quality. If open source projects fail to meet the needs of their users, they split, and some branch will adapt, but without throwing everything away.
In contrast, closed source development usually involves assigning people to projects. Their primary motivation isn't the software itself (which they will likely never use), but their job and their stock. Determining features involves a few people guessing hard about what features end users may or may not want. Oh, sure, they listen, but as anybody who has gathered requirements knows, users generally aren't very good at communicating what tradeoffs are important to them. And when closed source projects fail in the market, any new entrant has to start from scratch.
It's not surprising that open source development is winning in the long run. It's central planning (Microsoft, Apple) vs. a free market of ideas (open source) all over again. And we already have a good idea which of the two approaches of organizing large numbers of people around a common goal works better.
[Xbox] consists of very powerful IBM-PC-based hardware
Yeah, 64M, a 733MHz PIII, some slightly outdated nVidia chip, and an 8G hard disk. Real "powerful". See that baby "fly". For the same price, you can get a real PC.
This is just precious: you consider forcing users to learn chicken scratches good design? The original Palms didn't even have a reference card. I don't know what kind of grandmother you have, but mine doesn't have the patience--she's too smart.
Graffiti was a fluke and an example of lousy design. They should have put a keyboard on those devices from the start, and not surprisingly, that's what everybody is moving to.
With peer-to-peer webcasting, multicast, wireless webs, etc., nobody will be able to measure anything "per 1000 listeners". Kind of like real broadcasts. But because it's so ad hoc, statistical estimates won't work either.
It seems likely that the whole broadcast/record industry was a fleeting phenomenon. Why not just give up on charging for recordings altogether? Between charging for live performances (bring your digital recorder if you like), government sponsorship, private foundations, and donations, we should be able to get more than enough of a thriving musical and artistic culture. That's how music and art were paid for before the 20th century.
Or, in different words, if the choice comes down to Britney Spears or civil liberties, I'll choose civil liberties, thank you very much.
Of course, that apparent chaos in the US was only a temporary phenomenon, and I think maybe the FCC and the rest of the government knew it would be.
The "chaos" wasn't apparent, it was real. And it continues: we still have, what, three or four different incompatible systems being used?
Europe has had many years of excellent service with GSM. Now the standard is getting a bit old, and maybe they'll switch to (and standardize on) something CDMA-based.
And what makes him think the chaos is only temporary in the US? Other, incompatible systems will come along and the chaos will continue.
In CVS, if you rename a directory, there's nothing that keeps track of the old name,
Sure there is. You rename by deleting the old file and adding it as a new file. It's simple and all versions of the software are consistent.
An explicit "cvs rename" command would basically do just that, but it could have a few more convenience features (linking logs together, handling directories automatically).
If you "mv" around files in the CVS directory, on the other hand, your repository will be inconsistent. Don't do that.
Norman rightfully complains about the poor usability of current systems. He diagnoses a lot of microscopic problems and admonishes companies to spend more time on fixing their products. But that's no real solutions: companies don't have the time or money.
Just look at the stuff coming out of Apple (where Norman used to work): sure, Aqua is a little nicer than Windows and has somewhat fewer blunders, but, believe me, it's not intuitive to the uninitiated.
The problem is that making usable programs is too much work and is too rigid and centralized a process. That's a technological problem, not an HCI problem, and until it is addressed, HCI design of the kind Norman prescribes is just like flailing in the water: it may keep you alive for a little while, but it is enormously exhausting and largely ineffective.
Consider getting a Mini-ITX system (mini-itx.com). For about $200, you can get a system with processor, memory, and a nice small case (e.g., caseoutlet.com). Just add a disk and install Linux on it. The system has TV-out and a bunch of other features.
Slashdot Mirror
Gillmor didn't make those qualifications, so, no I am not looking at it "the wrong way".
Also, at this point, there is no reason why Linux couldn't become very widely used with consumers. Technically and in terms of ease-of-use, Linux with Gnome or KDE is comparable to Windows and Mac OS X, and Linux has a full complement of media viewers and creation tools. All it takes now is for more vendors to ship it preinstalled on supported hardware. And if both Windows and OS X go over to the dark side, the fact that Linux is easy to use and available matters. Actually, an ill-advised adoption of DRM by Windows and Mac OS could really help Linux in the consumer space...
Most likely, what will happen is that Windows will continue to be able to play non-DRM content, but it will refuse to create non-DRM content unless you buy very expensive "professional" versions of the software and hardware you use, software and hardware that puts your signature on everything you create. Windows may also simply start putting non-DRM content under DRM without even telling you.
So far, most operating systems other than Microsoft Windows are giving DRM a cold shoulder. Windows is the exception, not the rule.
In fact, it's hard to see how DRM could work if there were a lively, competitive market in operating systems, media software, and hardware. In some way, DRM can only work if Microsoft keeps 95%+ of the market, which is kind of scary, because it means that Hollywood is going to do what they can to support Microsoft's monopoly.
If you wait long enough, almost any event "B" will follow almost any event "A" in close succession. That doesn't mean that "A" caused "B".
As for TiVo, they just didn't and don't have any particularly distinguished technology. DVRs had been around in research labs and as prototypes for a decade before TiVo came out. TiVo was simply the first to market at the point when disks and processors became cheap enough. DVRs are a technologically simple commodity consumer item, and that implies very tiny profit margins that only the large manufacturers can survive on. TiVo's attempts to generate revenue by selling subscriptions didn't help either: consumers know that program schedules already effectively free and that paying $12/month (or whatever it is) is way too expensive.
I'm sorry, perhaps I'm missing something. Are you excited about the fact that ksycoca notifies applications about configuration changes while the application is running? That may be impressive if you come from Windows, but the X11 resource system has had that for a long time.
Have you ever even seen how X resources work? Have you seen tools like "editres" in action? With a compliant toolkit, you can click on an application, get its widget tree, change properties or event bindings on the fly, and save your changes. Of course, it doesn't work with Gnome or KDE, and there is nothing equivalent.
dcop is also not high bandwidth
Well, then standard X11 IPC mechanisms should be sufficient and DCOP is not needed, which is kind of my point.
I am pretty sure, that they gave a lot of thought to these issues
Yes, but that doesn't mean that they made the right decisions. KDE and Gnome were really written with a Windows-like frame of mind: a single, local display under full control of a single environment. I think the people who started working on it didn't even appreciate the hard problems that X11 and X11 toolkits were already addressing when those projects started. And while the KDE and Gnome codebases are a lot cleaner than Xaw and Motif, functionally, they have thrown us way back.
In fact, neither Gtk+ nor Qt are really X11 toolkits--they are Windows-like toolkits that happen to run on X11. Someone should probably take a new stab at creating a modern X11 toolkit from the ground up. See here for some related work: XCB, Gettys, Sharp.
Well, I agree that that's a problem for KDE. But what do you want RedHat to do?
They are hacking both Gnome and KDE. But when they hack Gnome, it's simply "Gnome development" for the reasons you observe. When they hack KDE, well, some KDE developers complain.
There is nothing "modern" about a mess of configuration files in ~/.kde.
Evidently, gimp is triggering a bug in gtk's xdnd implementation, or it might still use the old obsolete motif dnd specification.
Maybe KDE should then also implement the "obsolete motif dnd specification".
Which X convention exists regarding event binding?
I can rebind events to actions through X resources. The mechanism works pretty well. KDE and Gnome have their own, incompatible, and more limited mechanisms as far as I can tell.
Bullshit. DCOP is a simple IPC/RPC mechanism built to operate over sockets. Either unix domain sockets or tcp/ip sockets are supported
And what makes you think that one application can connect to the sockets of the remote DCOP server? What happens if they can't? And why does DCOP seem to start up for everything if very few applications actually ever need high-bandwidth inter-client communication? If the KDE folks had put their mind to it, they could have figured out how to do high performance communications through an X11 server without opening sockets behind my back--it's not rocket science.
Overall, I'm not saying that KDE is bad, I'm saying it's living on its own continent, slowly drifting away from the X11 mainstream. That's fine--whatever makes people happy. But as far as I'm concerned, it's good that RedHat tries to create a version of KDE that's a little closer to the rest of the world. They won't fix what I would consider the major problems of KDE (or Gnome, for that matter), but maybe they make it at least a bit more usable for people who don't want to sell their soul to a single desktop.
Did I say it was different from Gnome? Both desktops, in fact, commit many of the same interoperability sins. But we are talking about KDE here and what RedHat is doing to fix the problem at the KDE end.
I hope RedHat will get around to doing a Gnome make-over as well. I also hope that RedHat will start hacking Gnome and KDE applications more deeply to remove dependencies on specific desktop environments from all of them.
Gimp and the KDE file manager, for example. KDE blames it on the Gimp, but it works fine with everything else.
"KDE flaunts many X11 conventions" Which? Give some examples.
Handling of defaults, resources, command line options, event bindings, widget trees, inter-client communication (via a separate server rather than the X server), among others.
Gnome apps do the same on KDE. nautilus e.g. starts esd, gconfd-2, nautilus-throbber, bonobo-activation-server and medusa-idled.
What's this obsession with Gnome? Did I even mention Gnome? Gnome has many of the same problems that KDE has, but Gnome isn't the subject of this discussion.
I have never seen it be compatible with "esound". xmms, for example, doesn't work when it is set to "arts" output and run under Gnome.
"KDE's drag-and-drop does not interoperate fully with non-KDE apps" Example? Btw which KDE version are you running?
File manager to Gimp, for example. I'm running the latest version in Debian (although I'm not running it very often anymore).
"KDE flaunts many X11 conventions" I don't understand this, is this bad?
Yes, it's bad. It makes KDE applications interoperate less well with the rest of X11 and requires more effort on the parts of users to figure it out (unless, of course, they only run KDE, which is the not-so-secret master plan of the KDE effort).
"KDE is probably due for a lot more cannibalization in the future." You're a troll.
I'm sorry, but how is a simple statement of what I believe is going to happen to KDE "trolling"? I think the mainstream future for KDE applications is that the useful ones will be picked apart, KDE desktop dependencies removed, and reused as part of a unified Linux desktop. RedHat has only begun down that road. You are free to disagree. Insults, however, won't get you anywhere.
For DVD playback, games, etc., you get an Xbox. For running Linux, however, a low-end PC is a better choice: easier to install, with more disk space, etc. Easy enough to understand?
The KDE attitude seems to be that there is a war to win for the Linux desktop, while other efforts are more geared towards providing interoperable toolsets of which you can reuse as much or as little as you like. Fortunately, KDE code is open source, and it is entirely appropriate for RedHat and other developers to pick apart the KDE distribution and code and reuse whatever parts are useful. That's how open source works: if a project fails to meet the needs of its users, it gets cannibalized and its parts reused. KDE is probably due for a lot more cannibalization in the future.
In contrast, closed source development usually involves assigning people to projects. Their primary motivation isn't the software itself (which they will likely never use), but their job and their stock. Determining features involves a few people guessing hard about what features end users may or may not want. Oh, sure, they listen, but as anybody who has gathered requirements knows, users generally aren't very good at communicating what tradeoffs are important to them. And when closed source projects fail in the market, any new entrant has to start from scratch.
It's not surprising that open source development is winning in the long run. It's central planning (Microsoft, Apple) vs. a free market of ideas (open source) all over again. And we already have a good idea which of the two approaches of organizing large numbers of people around a common goal works better.
If you want video, a digital camcorder is smaller, cheaper, and better. There are even some portable MPEG-4 recorders with hard disk coming out.
Yeah, 64M, a 733MHz PIII, some slightly outdated nVidia chip, and an 8G hard disk. Real "powerful". See that baby "fly". For the same price, you can get a real PC.
Graffiti was a fluke and an example of lousy design. They should have put a keyboard on those devices from the start, and not surprisingly, that's what everybody is moving to.
It seems likely that the whole broadcast/record industry was a fleeting phenomenon. Why not just give up on charging for recordings altogether? Between charging for live performances (bring your digital recorder if you like), government sponsorship, private foundations, and donations, we should be able to get more than enough of a thriving musical and artistic culture. That's how music and art were paid for before the 20th century.
Or, in different words, if the choice comes down to Britney Spears or civil liberties, I'll choose civil liberties, thank you very much.
I don't see the problem--if you don't want it, just don't use it.
In fact, if these fuel cells work with ethanol, maybe you could just order vodka or rum to power them :-)
The "chaos" wasn't apparent, it was real. And it continues: we still have, what, three or four different incompatible systems being used?
Europe has had many years of excellent service with GSM. Now the standard is getting a bit old, and maybe they'll switch to (and standardize on) something CDMA-based.
And what makes him think the chaos is only temporary in the US? Other, incompatible systems will come along and the chaos will continue.
Sure there is. You rename by deleting the old file and adding it as a new file. It's simple and all versions of the software are consistent.
An explicit "cvs rename" command would basically do just that, but it could have a few more convenience features (linking logs together, handling directories automatically).
If you "mv" around files in the CVS directory, on the other hand, your repository will be inconsistent. Don't do that.
Just look at the stuff coming out of Apple (where Norman used to work): sure, Aqua is a little nicer than Windows and has somewhat fewer blunders, but, believe me, it's not intuitive to the uninitiated.
The problem is that making usable programs is too much work and is too rigid and centralized a process. That's a technological problem, not an HCI problem, and until it is addressed, HCI design of the kind Norman prescribes is just like flailing in the water: it may keep you alive for a little while, but it is enormously exhausting and largely ineffective.
Consider getting a Mini-ITX system (mini-itx.com). For about $200, you can get a system with processor, memory, and a nice small case (e.g., caseoutlet.com). Just add a disk and install Linux on it. The system has TV-out and a bunch of other features.