The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
This has a bit of Barr bias. Nothing's "wrong" -- Barr's system just doesn't have things like Realplayer installed, so mplayer is saying "I won't be able to play.rm files because you don't have realplayer installed." Of course, clarifying that would weaken his point that his onging grudge war with A'rpi (ex-mplayer lead, who is equally responsible for the A'rpi-Barr flamewar).
You're getting paid to stand in the damn bakery each day.
If you want to say "I'll pay $100 bounty via PayPal to whoever correctly ansers my question first", as you would if you went to Microsoft with a Word or Visual Basic issue and expected support, you're likely to have better luck. If you're paying for support, *then* you can say things like "foo doesn't work, and I'm upset". You aren't, so you can't.
Hell, if you don't have a dedicated support package and you're using a general piece of horizontal market software, all the tech support people are going to tell you is "reinstall", then "return it" if their list of eight checklisted items (equivalent to an open source FAQ) doesn't provide an answer.
Ask a specific question. If you say "Can someone help me to get X working...", you're going to get a "no". Why? Think of what you actually just asked -- you, one of zillions of people, just said "will you commit an unknown amount of time to providing me with support for free".
If you say "When I run foo, I get a 'RTC support not included' error. What can I do to fix this?", and you *checked* the documentation and google first, then you're likely to have a lot more luck, because the other folks can immediately respond with an answer. They just can't *do* anything with a "it doesn't work" post, and most folks are not interested in investing the time require to send out another post with a list of what information is required so that perhaps they can get a response back so that perhaps they can fix a random person's problem. You need to send out a post with enough information to allow the folks you're asking for help to answer your question without immediately needing to ask you for even more information.
This is no different from free support for closed-source software. You'll get the same response on USENET if asking a question about Half-Life. If you're paying someone to sit on the phone and answer questions (like someone at Microsoft with an MSDN support incident, or someone at Red Hat with a commercial support package), *then* things may be different.
It's not just a matter of *insulting* the other person -- you need to include enough information to let them do your request.
This build does not contain all available options in mplayer. There's no mga or xmga support (which I use), for instance. If you want the goodies, you have to do the build yourself.
If you want to watch other titles on the DVD, use dvd://1, dvd://2, etc.
MPlayer does *not* have DVD navigation support (as xine and ogle do), so if you're a DVD fan and using the DVD browser interface is important to you, you may want to not use mplayer with DVDs.
If you want to use a nondefault audio track and subtitles, you'll need to specify them. I needed -aid and -sid to watch my new copy of Ghost In the Shell in Japanese with English subtitles, rather than the nasty ol' dubbed version. Mplayer isn't going to give you a menu of said options -- you need to print 'em out with mplayer dvd:// -v and fill in the id numbers yourself.
Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing.
No. Xine should be installed on systems intended for non-techie end users. Mplayer is not a particularly great choice for non-techies. A'rpi is very much opposed to the idea of binary distributions (since it means that things may run slightly slower on a given system), and Mplayer can support so many things that to set up everything required for full support during a build can take a long time. It's less bad than building GNOME or KDE, but it's definitely not an "rpm -Uvh" either.
That being said, I use mplayer exclusively, and love it to death. It's keyboard controllable, can be used without one of those godawful "fake media player" UIs, is faster than anything else in existence, and has support for just about every interface and codec under the sun (that Open Source folks can get their hands on or reverse engineer). Those of you not familiar with Barr and A'rpi (the lead mplayer developer for a long time) should be aware that the two intensely dislike each other, and have flamed each other for ages. Regardless of how good Barr is in most areas (and this review seems pretty reasonable, saying that "mplayer ain't a great choice for Linux newbies", which is definitely true), keep in mind that he's quite likely to have some bias, as A'rpi does when talking about Barr on the mplayer website. I take both with a big, big grain of salt.
Perhaps some collaboration between MPlayer and Xine should occur.
It does. Of course, it's full of people flaming each other for not giving sufficient credit, but the two projects have shared a *ton* of code in the past, and is the only reason either of them are as good as they are.
What you just asked for is a system where you can get a tested release.
Red Hat provides that. It's their distribution. If you yank out parts and something doesn't work...it's not a huge surprise. The equivalent to BSD 4.x is Debian stable or RH 7.x (which is what most people see to use for production servers running RH, due to strong maturity). Just because Linus has tagged something as "2.6-pre-foo" doesn't mean that you have a tested, complete system. That means that *he* is getting close to the point where he's ready to hand the kernel off to *Red Hat and other distro vendors* to begin testing and integration. It doesn't mean that the kernel is end-user ready if you want a tested environment.
After the kernel hits 2.6 and it's been poked at a bit and decided that there's at least a decent chance that you can use it without problems, Red Hat will put it into Rawhide. That should be considered post-development -- about alpha quality. As a matter of fact, Rawhide doesn't even have formal "releases" -- it's a working repository for integration folks -- so it might be considered pre-alpha using conventional definitions. That's when testing on a wide variety of systems begins. When RH feels confident that there aren't known problems after trying on a number of systems, they move to beta, of which Severn is their current release. This is already much further down the pipeline than you're talking about, and it's just *beta*. You may not have a tested upgrade path, but you can probably use the software. Don't cry if it doesn't work -- it hasn't passed rigorous QA, but you can probably use it on a testing system without egregious problems. *Finally*, RH does a release. RH's releases tend to be considered a bit bleeding-edge, relative to extremely conservative distributions like Debian stable (wasn't that long ago that Debian stable finally left the 2.2 kernel). After the thing's been out a bit and bugfixes have been released (kind of like businesses wait a bit after a new Windows release to let people hammer on the thing and find any dings that missed earlier examination), *then* you can consider the thing stable in a conservative sense. *Only* from release to release is there a tested upgrade path on software.
Your problem was that you were jumping the gun WRT testing by a long way. When you upgrade from FBSD 5.x, you've at least had the piece of software "integrated" into the rest of the software. It's equivalent to Rawhide, if not beta. You were yanking something that Linus hasn't even felt comfortable handing off to QA people yet and saying "gee, it doesn't work".
Other distros have their own approachs -- I just happen to know RH's better -- but the point remains that there's a hella lot more testing in the pipeline before that software should be considered something that you'd want to put on your system. How do you know you aren't going to run into filesystem corruption, or God knows what? The development releases are releases intended specifically for the use of kernel developers, and if anyone else can get good out of 'em...great. 2.6-pre *is* part of 2.5, ignoring the unusual naming. It's just denoting the fact that there's an intention to move to 2.6 soon. 2.6.0, the first release QA/integration folks should be looking at, is still months away.
Now, a lot of Linux folks like seriously riding the metal, and some folks use development kernels, even doing ballsy things like putting them on their personal workstations. However, they also don't say "Linux sucks" if something doesn't work or they wipe out their filesystem. A fair number of 'em don't realize that what they're doing is a bit risky -- it's not just using mozilla daily snapshots. There ends up with this misperception on Slashdot that folks should be able to comfortably run development releases of kernels. Folks, it's called "development" for a reason -- it isn't even alpha yet!
I don't think you can realtime-ize Linux effectively without a wrapper. Linux is (comparatively) big, has a ton of functionality, and is constantly being extended by folks who aren't trying to maintain a hard realtime system.
It's a whole different ballgame than the sort of software being used for tiny hard realtime systems.
You consider Linux amaturish because you broke your copy when you replaced your kernel with a development kernel and upgraded modutils to a version that your distro vendor definitely doesn't support? I mean, seriously, what kind of standards do you keep? Yes, you need to know what you're doing if you're tossing a new kernel in. Try doing the same thing on Windows -- putting the kernel from XP into 2000 -- and see how far you get.
I'll be very impressed if BSD can do the same thing you were trying to do with Linux -- take all the modules from one version, upgrade to a new kernel and expect to use the all the modules from the older version.
Finally, you're right that *ix is overkill for small embedded devices, but I think that these folks are talking about larger embedded devices, things like Linksys routers and the like, that have a web server and firewalling system. Windows CE isn't much more appropriate for small embedded devices.
I don't understand, unless my understanding of what "dark matter" is is seriously wrong. I thought that dark matter was simply non-light-emitting matter. Plannets, dust, rocks, the like. Not stars. And the problem is that we can't easily monitor dark matter, because it isn't emitting energy.
All this "not interacting with regular matter" business comes off as completely strange to me.
Not many companies will be willing to take the legal risk of losing their *own* game by using HL2 source. There are *tons* of freely available 3d engines out there.
Cheating is more likely to hurt Valve, as it severely damages multiplayer value.
You know, I majored in both CS and philosophy, and did take OS design. Frankly, if you're taking a *real* philosophy class (not like ethics or something that's just blathering back classic Grecian material, but with hard analysis of the nature of reality going on) I think that it's a pretty much untenable position that you can zip through a philosophy class but not through an OS course.
I went into OS knowing most of the material, so I may be a bit biased, but I could have fast-forwarded through almost all of it. Try fast forwarding through a philosophy class trying to show an isomorphism between the properties of infitesimals and the properties of the operators and units used in human value calculations (yes, actually a lecture). Not bloody likely. You have to rewrap your brain around a lot of things that you take for granted.
Second: The problem with "letting the market decide" between open and closed source is this: proprietary companies are the ones in the best position to bid on software. Cuz, like, they have salesmen and stuff.
This is a *huge* deal.
Keep in mind that the reason that salesmen and marketers exist -- a large chunk of the spending of most companies -- is to figure out how to subvert buying policies. If the government has a particular purchasing policy, how can it be avoided or exploited? "Wining and dining" is a phrase that we don't find disturbing, because it's so common -- and yet it itself is indicative of attempting to muck with the purchasing process.
Closed source and propriatary formats are wonderful for providing lock-in. Lock-in can be a massive hidden cost that can slip under the noses of purchasers.
I was talking about things from the point of view of OS vendors. There are a number of vendors that built their own OSes based on licensed code. I don't think that will happen again.
I'm willing to bet you're a moderate quality amateur mechanic, hence the choice of looking down this particular nose.
Actually, the opposite. I have essentially no practical mechanical expertise, and a far lower than normal level of automobile knowledge. My level of knowledge *was* why I selected that case, though -- I know that I'd feel unfairly put upon if mechanics were insulting me about my lack of knowledge.
No. It's no less funny when it's one's self, if one has the understanding that what the support people hate isn't stupidity, or inexperience, but sloth.
I can't agree. It's true that sloth (true sloth, not sloth defined as the unwillingness to run out and study and become conversant with the subject, which I consider ignorance, not sloth) is the theme of a few UF tech cartoons, but an overwhelming number portray users as simply being inhumanly, incredibly stupid.
Furthermore, I've never had to work phone tech support (for which I consider myself fortunate -- I know people that *have* done tech support, and it seems to be quite unpleasant), but I have done IT work in the past, some of which involved face-to-face support. Perhaps it's easier because I know, at least vaguely, the people that I'm supporting, but while I certainly saw understandable ignorance, I did not see an unwillingness to do reasonable tasks themselves. There were cases where people did not have enough time -- they do not have the luxury of sitting down and dicking around with computers all day, as I have, because they have some other task assigned them by their manager -- but I don't consider that a reprehensible personal failing in them.
At this point, due to SCO screwing everyone over, no company is going to be willing to ever touch another OS based on propriatary code licensed from someone else again. They've been burned once -- not again. Given that an in-house solution is insanely expensive, this just adds more impetus to the Linux push.
Exactly. There's no need to deal with phone lines, with monopolies, connections, etc.
The laws in place were put in place to avoid consumer getting screwed. Today, we need laws *not* being added to squash new VoIP companies to avoid consumers getting screwed.
Exactly. This is unenforceable and stupid, made by folks trying to adapt old-media rules to the Internet to keep old business models afloat. You *cannot* sanely enforce this -- if you want to do something equivalent but reasonable, your only option is a tax on Internet data as a whole.
*God*, I hate people trying to legislate the Internet. I wish I had a list of "good" tech politicians (the EFF oughta provide this) to support. That Rick what's-his-name from Virginia that keeps hitting Slashdot seems to have pretty pro-tech views, for instance.
Unfortunately, UI can also be an area that should *not* be consumer-driven.
The recent facination (last five years) with media player authors to make "pretty" interfaces that immediately grab a user's interest is a great example. The UIs are far less usable, are inconsistent, are frequiently slower and buggy...yet authors keep pumping out these damned bitmap interfaces to DVD players, movie file players, audio file players, etc.
The problem is that every time someone does something with a tiny bit of justification, everyone copies it wrong.
Bitmapped interfaces have seen two major insurgences that are still present. The first, pointed out earlier, was in media player apps. There are a number of cases, but I think the first instance I know of was WinAmp. WinAmp was trying to fill a hole that had never been filled before. It needed to remain constantly up on a user's desktop to keep title, volume, and position available. However, it needed to save space (see the minimized form) -- I can't think of a good way to provide equivalent functionality using standard widgets. Anyway, a difficult HCI call -- to deviate from the standard OS interface was made. It has definitely had drawbacks, but there's at least a good argument that it was worthwhile.
Along came a huge number of media player designers, all of whom looked at WinAmp and decided at the bitmapped interface was what made the thing successful. They started churning out all kinds of horiffic unusable media players that *did* catch the eye, and *did* get users to try them out...only to hit irritation with the interfaces. Media players pioneered spikes hanging off of windows.
The other major example is graphic plugins, dating back to Kai's Power Tools. For those not familiar with the tool, KPT is a set of Photoshop plugins. It was written by Kai Krause, an extremely talented graphics programmer. He felt that using custom bitmapped widgets was a good idea. Again, his decision was somewhat arguable, but it let him showcase some of his software's effects, and more importantly, he did a reasonable job for someone going with an inconsistent interface -- he did a few things that would have been difficult with a conventional widget set. KPT had a tremendous functionality set, and succeeded wildly, allowing the company to grow, change names, and develop and acquire other software products like mad. The company continued to produce other outstanding products, also with bitmapped interfaces (with greater and lesser degrees of justification for their nonstandard interfaces. KPT Bryce is a notable example.
Naturally, a number of other, less talented, Photoshop plugin development companies that were producing products that were not particularly price-competitive or feature competitive looked at KPT and said "Gee...KPT uses a bitmapped interface and is successful. That must be what we're missing." Over the next few years, a *flood* of inconsistent, bitmap-interfaced Photoshop plugins hit the market. These were, as a rule, less well-done than the original KPT, and were a complete pain in the ass for a set of people that mostly used Macs, and had traditionally had one of the most consistent user interfaces in the history of personal computing.
Bitmapped, custom interfaces are almost always a bad idea.
There was also an influx of CD-ROM based titles with bitmapped interfaces starting in the early CD-ROM days. Lots of low-budget titles, educational titles, etc. Macromedia Director played a major role in the proliferation of these. Again, a bitmapped interface added nothing to usability, and frequently exposed bugs. It took a few years, but eventually designers realized that users didn't *like* atrocious bitmapped interfaces, and stopped.
Today, almost all games have a menu system that uses a nonstandard, bitmapped interface. Part of this is because they often have console ports, where there *is* no standard widget system, and part of it is because there's a perception that the customer *wants* a m
Slashdot Mirror
It does not expect you to KNOW what codecs you want to use and already have them downloaded.
Try playing DivX when you lack support, mate. And at least with Mplayer, you'll get a vaguely helpful message -- not with Windows Media Player.
The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
.rm files because you don't have realplayer installed." Of course, clarifying that would weaken his point that his onging grudge war with A'rpi (ex-mplayer lead, who is equally responsible for the A'rpi-Barr flamewar).
This has a bit of Barr bias. Nothing's "wrong" -- Barr's system just doesn't have things like Realplayer installed, so mplayer is saying "I won't be able to play
You're getting paid to stand in the damn bakery each day.
If you want to say "I'll pay $100 bounty via PayPal to whoever correctly ansers my question first", as you would if you went to Microsoft with a Word or Visual Basic issue and expected support, you're likely to have better luck. If you're paying for support, *then* you can say things like "foo doesn't work, and I'm upset". You aren't, so you can't.
Hell, if you don't have a dedicated support package and you're using a general piece of horizontal market software, all the tech support people are going to tell you is "reinstall", then "return it" if their list of eight checklisted items (equivalent to an open source FAQ) doesn't provide an answer.
That's just how software is.
More seriously, there *is* a wrong and right way.
Ask a specific question. If you say "Can someone help me to get X working...", you're going to get a "no". Why? Think of what you actually just asked -- you, one of zillions of people, just said "will you commit an unknown amount of time to providing me with support for free".
If you say "When I run foo, I get a 'RTC support not included' error. What can I do to fix this?", and you *checked* the documentation and google first, then you're likely to have a lot more luck, because the other folks can immediately respond with an answer. They just can't *do* anything with a "it doesn't work" post, and most folks are not interested in investing the time require to send out another post with a list of what information is required so that perhaps they can get a response back so that perhaps they can fix a random person's problem. You need to send out a post with enough information to allow the folks you're asking for help to answer your question without immediately needing to ask you for even more information.
This is no different from free support for closed-source software. You'll get the same response on USENET if asking a question about Half-Life. If you're paying someone to sit on the phone and answer questions (like someone at Microsoft with an MSDN support incident, or someone at Red Hat with a commercial support package), *then* things may be different.
It's not just a matter of *insulting* the other person -- you need to include enough information to let them do your request.
This build does not contain all available options in mplayer. There's no mga or xmga support (which I use), for instance. If you want the goodies, you have to do the build yourself.
mplayer dvd://
If you want to watch other titles on the DVD, use dvd://1, dvd://2, etc.
MPlayer does *not* have DVD navigation support (as xine and ogle do), so if you're a DVD fan and using the DVD browser interface is important to you, you may want to not use mplayer with DVDs.
If you want to use a nondefault audio track and subtitles, you'll need to specify them. I needed -aid and -sid to watch my new copy of Ghost In the Shell in Japanese with English subtitles, rather than the nasty ol' dubbed version. Mplayer isn't going to give you a menu of said options -- you need to print 'em out with mplayer dvd:// -v and fill in the id numbers yourself.
Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing.
No. Xine should be installed on systems intended for non-techie end users. Mplayer is not a particularly great choice for non-techies. A'rpi is very much opposed to the idea of binary distributions (since it means that things may run slightly slower on a given system), and Mplayer can support so many things that to set up everything required for full support during a build can take a long time. It's less bad than building GNOME or KDE, but it's definitely not an "rpm -Uvh" either.
That being said, I use mplayer exclusively, and love it to death. It's keyboard controllable, can be used without one of those godawful "fake media player" UIs, is faster than anything else in existence, and has support for just about every interface and codec under the sun (that Open Source folks can get their hands on or reverse engineer). Those of you not familiar with Barr and A'rpi (the lead mplayer developer for a long time) should be aware that the two intensely dislike each other, and have flamed each other for ages. Regardless of how good Barr is in most areas (and this review seems pretty reasonable, saying that "mplayer ain't a great choice for Linux newbies", which is definitely true), keep in mind that he's quite likely to have some bias, as A'rpi does when talking about Barr on the mplayer website. I take both with a big, big grain of salt.
Perhaps some collaboration between MPlayer and Xine should occur.
It does. Of course, it's full of people flaming each other for not giving sufficient credit, but the two projects have shared a *ton* of code in the past, and is the only reason either of them are as good as they are.
What you just asked for is a system where you can get a tested release.
Red Hat provides that. It's their distribution. If you yank out parts and something doesn't work...it's not a huge surprise. The equivalent to BSD 4.x is Debian stable or RH 7.x (which is what most people see to use for production servers running RH, due to strong maturity). Just because Linus has tagged something as "2.6-pre-foo" doesn't mean that you have a tested, complete system. That means that *he* is getting close to the point where he's ready to hand the kernel off to *Red Hat and other distro vendors* to begin testing and integration. It doesn't mean that the kernel is end-user ready if you want a tested environment.
After the kernel hits 2.6 and it's been poked at a bit and decided that there's at least a decent chance that you can use it without problems, Red Hat will put it into Rawhide. That should be considered post-development -- about alpha quality. As a matter of fact, Rawhide doesn't even have formal "releases" -- it's a working repository for integration folks -- so it might be considered pre-alpha using conventional definitions. That's when testing on a wide variety of systems begins. When RH feels confident that there aren't known problems after trying on a number of systems, they move to beta, of which Severn is their current release. This is already much further down the pipeline than you're talking about, and it's just *beta*. You may not have a tested upgrade path, but you can probably use the software. Don't cry if it doesn't work -- it hasn't passed rigorous QA, but you can probably use it on a testing system without egregious problems. *Finally*, RH does a release. RH's releases tend to be considered a bit bleeding-edge, relative to extremely conservative distributions like Debian stable (wasn't that long ago that Debian stable finally left the 2.2 kernel). After the thing's been out a bit and bugfixes have been released (kind of like businesses wait a bit after a new Windows release to let people hammer on the thing and find any dings that missed earlier examination), *then* you can consider the thing stable in a conservative sense. *Only* from release to release is there a tested upgrade path on software.
Your problem was that you were jumping the gun WRT testing by a long way. When you upgrade from FBSD 5.x, you've at least had the piece of software "integrated" into the rest of the software. It's equivalent to Rawhide, if not beta. You were yanking something that Linus hasn't even felt comfortable handing off to QA people yet and saying "gee, it doesn't work".
Other distros have their own approachs -- I just happen to know RH's better -- but the point remains that there's a hella lot more testing in the pipeline before that software should be considered something that you'd want to put on your system. How do you know you aren't going to run into filesystem corruption, or God knows what? The development releases are releases intended specifically for the use of kernel developers, and if anyone else can get good out of 'em...great. 2.6-pre *is* part of 2.5, ignoring the unusual naming. It's just denoting the fact that there's an intention to move to 2.6 soon. 2.6.0, the first release QA/integration folks should be looking at, is still months away.
Now, a lot of Linux folks like seriously riding the metal, and some folks use development kernels, even doing ballsy things like putting them on their personal workstations. However, they also don't say "Linux sucks" if something doesn't work or they wipe out their filesystem. A fair number of 'em don't realize that what they're doing is a bit risky -- it's not just using mozilla daily snapshots. There ends up with this misperception on Slashdot that folks should be able to comfortably run development releases of kernels. Folks, it's called "development" for a reason -- it isn't even alpha yet!
Sorry, the Linux world runs much faster than that. There's Linux in a Toaster already.
I don't think you can realtime-ize Linux effectively without a wrapper. Linux is (comparatively) big, has a ton of functionality, and is constantly being extended by folks who aren't trying to maintain a hard realtime system.
It's a whole different ballgame than the sort of software being used for tiny hard realtime systems.
You consider Linux amaturish because you broke your copy when you replaced your kernel with a development kernel and upgraded modutils to a version that your distro vendor definitely doesn't support? I mean, seriously, what kind of standards do you keep? Yes, you need to know what you're doing if you're tossing a new kernel in. Try doing the same thing on Windows -- putting the kernel from XP into 2000 -- and see how far you get.
I'll be very impressed if BSD can do the same thing you were trying to do with Linux -- take all the modules from one version, upgrade to a new kernel and expect to use the all the modules from the older version.
Finally, you're right that *ix is overkill for small embedded devices, but I think that these folks are talking about larger embedded devices, things like Linksys routers and the like, that have a web server and firewalling system. Windows CE isn't much more appropriate for small embedded devices.
I don't understand, unless my understanding of what "dark matter" is is seriously wrong. I thought that dark matter was simply non-light-emitting matter. Plannets, dust, rocks, the like. Not stars. And the problem is that we can't easily monitor dark matter, because it isn't emitting energy.
All this "not interacting with regular matter" business comes off as completely strange to me.
It's not actually a huge risk.
Not many companies will be willing to take the legal risk of losing their *own* game by using HL2 source. There are *tons* of freely available 3d engines out there.
Cheating is more likely to hurt Valve, as it severely damages multiplayer value.
The "heavily modified previous version" would fall in line with many previous 3d engines like Q1/Q2.
You know, I majored in both CS and philosophy, and did take OS design. Frankly, if you're taking a *real* philosophy class (not like ethics or something that's just blathering back classic Grecian material, but with hard analysis of the nature of reality going on) I think that it's a pretty much untenable position that you can zip through a philosophy class but not through an OS course.
I went into OS knowing most of the material, so I may be a bit biased, but I could have fast-forwarded through almost all of it. Try fast forwarding through a philosophy class trying to show an isomorphism between the properties of infitesimals and the properties of the operators and units used in human value calculations (yes, actually a lecture). Not bloody likely. You have to rewrap your brain around a lot of things that you take for granted.
It will require the addition of high-level software. It's not possible with just a VM system.
Second: The problem with "letting the market decide" between open and closed source is this: proprietary companies are the ones in the best position to bid on software. Cuz, like, they have salesmen and stuff.
This is a *huge* deal.
Keep in mind that the reason that salesmen and marketers exist -- a large chunk of the spending of most companies -- is to figure out how to subvert buying policies. If the government has a particular purchasing policy, how can it be avoided or exploited? "Wining and dining" is a phrase that we don't find disturbing, because it's so common -- and yet it itself is indicative of attempting to muck with the purchasing process.
Closed source and propriatary formats are wonderful for providing lock-in. Lock-in can be a massive hidden cost that can slip under the noses of purchasers.
I was talking about things from the point of view of OS vendors. There are a number of vendors that built their own OSes based on licensed code. I don't think that will happen again.
I'm willing to bet you're a moderate quality amateur mechanic, hence the choice of looking down this particular nose.
Actually, the opposite. I have essentially no practical mechanical expertise, and a far lower than normal level of automobile knowledge. My level of knowledge *was* why I selected that case, though -- I know that I'd feel unfairly put upon if mechanics were insulting me about my lack of knowledge.
No. It's no less funny when it's one's self, if one has the understanding that what the support people hate isn't stupidity, or inexperience, but sloth.
I can't agree. It's true that sloth (true sloth, not sloth defined as the unwillingness to run out and study and become conversant with the subject, which I consider ignorance, not sloth) is the theme of a few UF tech cartoons, but an overwhelming number portray users as simply being inhumanly, incredibly stupid.
Furthermore, I've never had to work phone tech support (for which I consider myself fortunate -- I know people that *have* done tech support, and it seems to be quite unpleasant), but I have done IT work in the past, some of which involved face-to-face support. Perhaps it's easier because I know, at least vaguely, the people that I'm supporting, but while I certainly saw understandable ignorance, I did not see an unwillingness to do reasonable tasks themselves. There were cases where people did not have enough time -- they do not have the luxury of sitting down and dicking around with computers all day, as I have, because they have some other task assigned them by their manager -- but I don't consider that a reprehensible personal failing in them.
At this point, due to SCO screwing everyone over, no company is going to be willing to ever touch another OS based on propriatary code licensed from someone else again. They've been burned once -- not again. Given that an in-house solution is insanely expensive, this just adds more impetus to the Linux push.
The Penguin just gets bigger and bigger.
Oh, great. Corrupt rich old white men beat that pants off of a socialized system.
Exactly. There's no need to deal with phone lines, with monopolies, connections, etc.
The laws in place were put in place to avoid consumer getting screwed. Today, we need laws *not* being added to squash new VoIP companies to avoid consumers getting screwed.
Exactly. This is unenforceable and stupid, made by folks trying to adapt old-media rules to the Internet to keep old business models afloat. You *cannot* sanely enforce this -- if you want to do something equivalent but reasonable, your only option is a tax on Internet data as a whole.
*God*, I hate people trying to legislate the Internet. I wish I had a list of "good" tech politicians (the EFF oughta provide this) to support. That Rick what's-his-name from Virginia that keeps hitting Slashdot seems to have pretty pro-tech views, for instance.
Argh. The last sentence of the parent should be ..big chunk...by other people".
Unfortunately, UI can also be an area that should *not* be consumer-driven.
The recent facination (last five years) with media player authors to make "pretty" interfaces that immediately grab a user's interest is a great example. The UIs are far less usable, are inconsistent, are frequiently slower and buggy...yet authors keep pumping out these damned bitmap interfaces to DVD players, movie file players, audio file players, etc.
The problem is that every time someone does something with a tiny bit of justification, everyone copies it wrong.
Bitmapped interfaces have seen two major insurgences that are still present. The first, pointed out earlier, was in media player apps. There are a number of cases, but I think the first instance I know of was WinAmp. WinAmp was trying to fill a hole that had never been filled before. It needed to remain constantly up on a user's desktop to keep title, volume, and position available. However, it needed to save space (see the minimized form) -- I can't think of a good way to provide equivalent functionality using standard widgets. Anyway, a difficult HCI call -- to deviate from the standard OS interface was made. It has definitely had drawbacks, but there's at least a good argument that it was worthwhile.
Along came a huge number of media player designers, all of whom looked at WinAmp and decided at the bitmapped interface was what made the thing successful. They started churning out all kinds of horiffic unusable media players that *did* catch the eye, and *did* get users to try them out...only to hit irritation with the interfaces. Media players pioneered spikes hanging off of windows.
The other major example is graphic plugins, dating back to Kai's Power Tools. For those not familiar with the tool, KPT is a set of Photoshop plugins. It was written by Kai Krause, an extremely talented graphics programmer. He felt that using custom bitmapped widgets was a good idea. Again, his decision was somewhat arguable, but it let him showcase some of his software's effects, and more importantly, he did a reasonable job for someone going with an inconsistent interface -- he did a few things that would have been difficult with a conventional widget set. KPT had a tremendous functionality set, and succeeded wildly, allowing the company to grow, change names, and develop and acquire other software products like mad. The company continued to produce other outstanding products, also with bitmapped interfaces (with greater and lesser degrees of justification for their nonstandard interfaces. KPT Bryce is a notable example.
Naturally, a number of other, less talented, Photoshop plugin development companies that were producing products that were not particularly price-competitive or feature competitive looked at KPT and said "Gee...KPT uses a bitmapped interface and is successful. That must be what we're missing." Over the next few years, a *flood* of inconsistent, bitmap-interfaced Photoshop plugins hit the market. These were, as a rule, less well-done than the original KPT, and were a complete pain in the ass for a set of people that mostly used Macs, and had traditionally had one of the most consistent user interfaces in the history of personal computing.
Bitmapped, custom interfaces are almost always a bad idea.
There was also an influx of CD-ROM based titles with bitmapped interfaces starting in the early CD-ROM days. Lots of low-budget titles, educational titles, etc. Macromedia Director played a major role in the proliferation of these. Again, a bitmapped interface added nothing to usability, and frequently exposed bugs. It took a few years, but eventually designers realized that users didn't *like* atrocious bitmapped interfaces, and stopped.
Today, almost all games have a menu system that uses a nonstandard, bitmapped interface. Part of this is because they often have console ports, where there *is* no standard widget system, and part of it is because there's a perception that the customer *wants* a m