Re:You people make me farking laugh (and cringe)
on
Sony vs Modchips
·
· Score: 2
Of course Sony can do anything they want. It's a free country.
The complaint is about: Apparently there were DOZENS of mod chips available that let you play copied games, and Sony did not do anything about it. Now the first chip comes out that lets you play copied games, PLUS it lets you play imported disks, and Sony is suddenly attacking this one, and ignoring the others still! This would seem to imply they consider the ability to play imported games a real threat, as opposed to the copies.
Re:There ARE modchips that still disallow CD-Rs
on
Sony vs Modchips
·
· Score: 2
Some may argue that this is not true, but what is true is that anybody buying a mod chip for playing imported disks is probably going to buy the one with the extra "feature" that it plays anything, since probably the price difference is zero.
Somebody else said that the ability to play imported disks necessarily means the machine will play anything, for techinical reasons. I don't know if this is true, though.
Not everybody at MicroSoft is an idiot. Why is it that they depend on details of the BIOS, which they do not have complete control over, and has lousy archaic interfaces?
It is true that anybody that makes a motherboard will test that it runs Windows, but that testing is not going to be very complete and there are many machines that are older than the newest versions of MicroSoft software. I can be pretty sure that if somebody loads WinXP on a machine and it fails, they will blame MicroSoft rather than the unusual BIOS chip in their machine.
KDE requires you to use their window manager. Yea you can change it, but a "hacker" can also mess up Windows so that the average user cannot figure it out either. So this is not a problem with KDE any more than Windows. (it is true that Gnome's ability to use different window managers messes it up, mostly in the preferences because the average user has no idea what is a "window manager preference" and what is some other preference).
You are correct about the slowness. Both KDE and Gnome (and Windows) are forcing huge amounts of complexity on use because nobody designing these has had an actual "innovation". Try ROX or some of the tiny window managers to see some attempts to be different, and compare their sizes to KDE/Gnome/Windows. Unfortunatly I am starting to despair that we will never see an "innovation" because of the vast number of sheep that are locked into the Windows interface, even MicroSoft is having trouble making any changes!
Technically Linux is slower because of Xlib's horrid design. This is a fact and something should be done about it. The solution is not to make some forced toolkit/dll, though, it is to write *HARD* code to do *FAST, POWERFUL* graphics operations.
Apple gives the developers plenty of other tools that can be user-unfriendly, so I don't think that is the reason there is no compiler.
What I am proposing is that the developers have the ability to put system("gcc/tmp/the_sourc_code.c -o new_plugin.so") into the application. Yea it's hard, but no harder than any other system call, and the end user has as much need to understand it as a need to understand any other call in the system toolbox. The user only thinks they are getting a fast plugin.
Certainly MSoft cannot make some of the ie code call any GPL code directly. The GPL code has to at least be some sort of "plugin" that IE can function without, and it probably has to be an easily added & removed component.
The question is if this sort of add-on is allowed. I believe it is, but there may be more information.
MSoft can be a pain and license the header files so they cannot be included by GPL code, their management has threatened to do this but I think their engineers may be showing a little backbone recently and stopping them from being totally mindless assholes.
In my (rather limited) experience in programming Win32 and MSDOS I have encountered this:
Setting the line dash style broke in Win98 and WinME. This appears to be a direct attempt to break non-MFC programs that tried to simulate the mouse highlight. It broke Qt, the GTK port, and FLTK. It appears to be fixed again in XP and always worked in NT.
Append, join, subst, (ie every single program that could do anything similar to a symbolic link) disappeared or broke in Window 3.1. Again I think this is a direct attempt by MicroSoft to disallow Unix compatability (symbolic links would allow the MSDOS file system to match a Unix file system, and are probably easy to implement, so I cannot think of any other reason they don't do it).
Support for switchar disappeared in MSDOS 6. This broke most of my programs which exec'd other programs, and again appears to have been done purposely to break Unix compatability (they could instead have made the programs accept either - or / easily enough...).
Storage and retrival of the current directory changed in MSDOS 5 to uppercase the name and turn all forward slashes into backward slashes and truncated all the filenames at 8.3 characters. This broke an enormous amount of Unix-ported software and required it to be rewritten to store the current directory locally.
Since I have done very little Windows programming, yet have encountered these, I would say the claim that Windows remains compatable between versions is false. It also seems to me that most of the changes are on purpose to sabotage the ability to write portable programs.
The entire purpose of this is to make competitors to Windows illegal or impossible to use.
You can do DRM in an Open Source way, such that OSS software could be allowed to copy a data stream from the network and put it on a device, and despite the full access to the source code it is impossible to use that data stream for any other purpose. This will be *WAY* harder to crack than what MSoft is proposing, the people who want DRM should realize that MSoft will sell "source code" as well, harder to read, but somebody with the right resources can still decode the instructions and chips. It is a lot safer to make a design that assummes the user can read the source.
What is done is you use public/private key encryption. A new DRM display or speaker has this device embedded in epoxy at a very late point. The device has a *fully documented* interface and takes a digital stream input and processes it and puts it on the display, it also has an interface that outputs the public key. Getting the private key would require smashing the device to the point that it is inoperable, so would any attempts to remove this device and insert a home- built one. The device could also have a settable clock imbedded and a random number generator that cannot be set.
A company that wants to send you content that you can only display on your device would request the key. Open source software can read the key and send it. It can also lie and send any key it wants to, but that is pretty useless because you will just get data you cannot use. The provider then checks the key against a trusted central manufacturer database to make sure it is not a fake key by somebody who built their home-brew device. The provider would then send the encrypted data. Open-source software can store the data or send it to the device.
If they want to limit the time they can look at it, the encoded data includes a clock range and the random key. It must match. If you try to reset the clock (this must be allowed because the power might fail, and the provider wants the clock to be at a time in the future) the random number will change. You will have to request the data again, sending the old one (the provider also cannot decode it, but may have a header encoded with their own keys containing the data checksum and the clock you asked for before).
Obviously this system has lots of "fair use" infringements, but it would work, and in fact is probably much more in the interests of the digital content providers. MicroSoft's "solution" is 100% designed to further their own interests. They are as willing to screw the RIAA as to screw the users, you know.
Um, I think Mac OS has done this for a long time. Certainly I have been fooled by closing all the PhotoShop windows, then thinking the menu is for the Finder and trying to pick a menu item.
I agree with the questioner as to why the user should care. We need to come up with an interface where there is not difference between closing all the programs and quitting the application.
The GUI purpose of this is to make menu items that create a new document, or configure the program, available, even though the program is closed. I don't have any good ideas here. The original Mac had "paper" that you clicked on to create new documents, one piece of paper for each application. You could also create a new document if you click on the application icon (most do this already). I don't know about configuration, the best I can think of is to require an open document to configure.
Systems where the user cannot tell if the program has really exited are pretty common. People here have mentioned Emacs, but also IE on Windows (and a lot of other MicroSoft software) do this. It would be nice if these hacks were not necessary, if programmers would stop being so lazy and perhaps improve the startup time so having the program already running is not so necessary! But it does not look like that is going to happen, sigh...
If "System Preferences" does something unwanted on exit, I would consider it a bug if it can be exited without at least asking the user!
I think the complaint about Objective C is not that "[foo...]" is uglier than "foo(...)" but that it uses both styles in the same program. SmallTalk only used the square bracket syntax for all function calls.
The problem is that the original Objective C was a C preprocessor that did not even parse things, it acted like a macro processor and replaced any "[...]" sequence preceeded by anthing other than a C identifier with a C function call taking string arguments.
If they had worked harder to parse C some more I'm sure they would have used a syntax like "method(object,...)" so that you could easily switch function calls to method invocations.
Or they could have used SmallTalk unchanged.
But the actual compromise is not something anybody should be proud of!
Have you thought about how useful it would be for end-user applications to have guaranteed access to a compiler? Granted the programming of the application is going to be hard, but imagine things like database front ends or presentation software where the user can hit a button that says "make this thing I've built with the GUI run 100 times faster" and after 10 seconds or so there is a compiled plugin. They don't have to know C or shell scripts or type anything, but the compiler could be a huge advantage.
The only reason to not include the compiler by default is so that Apple could make money selling it (the GPL means any buyer can give away free copies, but Apple could include something non-GPL such as a library or header file in order to make that not useful).
But Apple seems to be giving it away for free, so I am at a loss as to why they did not include it. There is junk on the system disk dozens of times larger than all the development tools (like sample movies and images) so they are not saving much space. And it seems the sales record keeping and pressing of extra $19.95 disks and the free download site are costing more than the marginal cost of sticking them on the distribution.
No, actually all the graphs I saw started at the same time. The difference is the graph I had shows only the last few days, where RHAT does quite well compared to MSFT. By picking other ranges you can find one where MSFT does very well compared to RHAT. In fact if Yahoo let you arbitraily pick the start and end date of the graph it should be possible to search for the range which maximizes (RHATin*MSFTout)/(MSFTin*RHATout) and get something that looks really good for RHAT! (or if you are a MSFT defender, reverse the search and "prove" just the opposite). Lying with statistics is easy and fun.
Part of the problem is that "DPI" matters at all. Those idiots who helped make the X11 font naming mechanism did not care about any program other than xterm. XTerm just picks a font and uses it's size to space the lines, and thus does not require the font to be any particular size. So they said "hey we are going to be all proper here and use the point size, measured in actual physical points". It didn't matter that NONE of the rest of Xlib measured things in points (everything else is measured in pixels), they just blissfully went and did this, since Xterm would never care as long as it read the font size.
Then of course as soon as anybody does anything other than xterm (like a control panel) that is laid out, and it runs on a screen that claims a different DPI, they fonts scale and the display is completely messed up! Then, instead of saying "well X is a stupid design" (which is the correct answer), they say "you should design an elaborate toolkit that scales the display to match the font" (which is stupid, besides doing that would be a lot easier if we could control how big the fonts are, anyway!).
Oddly enough MicroSoft copied this in their font interface (must have been an early attempt at sabatoge). They quickly realized their mistake and made negative sizes set the "pixel size", they also froze the systems idea of "DPI" to a constant so anybody using the old interface got predictable results.
This is interesting. I had no idea that rpm could do this, I assummed that "rpm a b" was the same as "rpm a" followed by "rpm b". I probably would have thought a solution was impossible, just like the orignal poster, and tried to back out stuff to get things to install.
Now that I see this, it suddenly seems totally obvious, and in fact I am now at a loss to think of any possible alternative, though I was imagining strange partly-installed package states before. In fact it *has* to work this way!
The problem is that there is an impossible learning step from the "I don't know how to do this" to the "its obvious". This is true of most of Linux (and Windows, too!), and is probably why it is hard to teach.
On a more practical note it is a good sign of how a cli is more easily extended than a gui: a naive GUI to rpm would probably have you click on a file and it installs. But that does not allow you to install two files at the same time! The GUI would have to be comletely rewritten so that you can select a set of files and then hit the "install" button, making the single-file case a lot harder and nonintuitive. While the naive CLI would be "rpm x" and when somebody realized that the multiple files was needed it changes to "rpm x..." and does not break the old one-file command!
Another note: why the hell does "rpm filename" not do something intelligent? Everybody keeps saying "it's not too hard to type 'rpm -Ivh filename'" but that is completely false. The truth is, it is not too hard to type "rpm filename" (or just "filename", lets put some GUI ideas into the shell) but that "-Ivh" is HARD. I actually think the CLI is a powerful and not hard tool, but these posts are making this argument into a joke.
Do you actually think the investors in VA are unaware that the stock lost 99% of it's value, and that moderating SlashDot is going to hide this fact from them?
Face it, everybody here is aware that the stock dropped like a rock and is worthless. I think it is interesting that it is not dropping right now (not that I would recommend anybody buy it, either), since I (and I bet you) would assumme it is still dropping. Why can't people point out facts that contradict the assummed wisdom?
Gee, it's too bad I can't adjust the starting and ending day more precisely, maybe that is a feature we need. At least the other posters (both pro and anti- rhat/linux) brought up these charts at the default settings.
Did any other companines (not counting little things that don't issue stock) put the word "Linux" in their names? I can't think of any but there must be some more examples?
The offer was for about $30 per share, but if you got one of these you could buy that while the stock was selling for over $300 per share. There was a limit of 160 shares (at least on the one I got) so you were not going to become filthy rich overnight with this, I also suspect there was no way to sell it soon enough to multiply your investment by 10, as anybody with any sense would expect, it immediately dropped to a more logical level of about $120 per share. (PS I of course waited too long and sold it for about $55 per share and thus made very little).
I also think there was something funny going on that caused the stock to inflate so fast. Aren't there some accusations that the brokerage manipulating this and several other stocks?
Xlib is such a horrid mess that it is much more productive to write a nice higher level that can be implemented on both Xlib and Win32. This is what all the toolkits do to allow the programs to be portable (Qt is one example, but all the other Linux toolkits have some kind of Windows port as well).
The advantage of not using Xlib is the hope (maybe a vain hope...) that Xlib can be eradicated from Linux as well.
Believe me, a savings of $500 per box would be the number one decision maker at an effects house. You obviously don't have any experience with the management of one or you would know better.
Linux is winning the renderfarms because the software used has little or no reliance on underlying system or hardware support and is thus not locked into Windows. Most rendering has to read and write files and do a lot of number crunching, so reliance on Windows-proprieterary libraries and interfaces is eliminated (reliance on Unix is also eliminated, the "Linux is Unix and thus easy to port to" argument is greatly exaggerated here).
In such a playing field Linux wins easily. Linux offers a few unimportant technical advantages (much better networking support, and a lot smaller memory usage when no GUI is running), so I think about 50% of the reason for Linux's popularity is due to cost, and about 50% due to the preferences (biases, if you want) of the IT staff.
They are missing video cards, keyboards, and monitors, (and may be missing floppy and CD drives, though the ones I am familiar with are not) and may not be all that valuable to schools.
Correct. The equivalent on Windows to this is VC++ project files. On the software I am working on, these have been a pain to maintain and debug and they will fail mysteriously on other people's machines (though the pain is probably less than the pain of configure, to be honest). Also annoying is the fact that the files are totally unreadable and are about a dozen times larger than all the NT-specific source code in our project (fltk). I always compile on NT using a batch file or gmake as these project files require launching the VC++ IDE which I otherwise don't use, I have also deleted my local CVS copies of these as the tiniest change will cause an extremely long CVS update time (over a 56K link), this makes CVS updates tolerable but also means I am always forgetting to update these when the set of files in the project changes.
I do have to say that the gmake file for NT is nice and clean due to the unifomity between the Windows platforms. A lot of pain would be saved if the Unix people started refusing to support some of the older and non-standard Unix versions so that we could use a single makefile.
One comment: if at all possible, the biggest win in readability and maintanability is to put explicit #ifdefs into the source, and use gmake and the output of uname to put 'if's into the makefile. This stuff is immesurably easier for a programmer to figure out and debug than autoconf. It would be nice if somebody made a make replacement that explicity compiled the dependency rules from a sequential language with normal if and looping constructs and obvious built-in tests for all the stuff in autoconf.
Clicking on the title bar is not "easy"? Well, I guess that proves that the MicroSoft engineers are idiots and don't do user testing at all. There are a whole lot of useful functions (like moving the window or closing it or iconizing it) that require clicking the title bar, and they made them not "easy" according to your definition.
I still find it hard to believe you have not tried a system that does not raise the windows when you click on them. BlackBox by default raises the window on clicks (so did NeXTStep, which BlackBox copies). Last time I tried it it was impossible to turn off this behavior unless you also switched to point-to-type.
If raising to type is so important, why does MicroSoft (and Gnome and KDE) go through all this trouble of making toolbars and docks and non-modal dialog boxes that stay on top even though you can interact with the lower windows? The answer is that in fact they are working around a basic design error by "fixing" it in the specific cases where it is most annoying.
This is exactly the same as the state of word processors in 1980 or so. It took ages (like 4 years or more) for the concepts of always-on insert mode and of a newline being a character you could insert and delete like any other from appearing in commercial word processors, despite ten years or more of the existence of such ideas in Emacs or other "professional software". The reason was a total paranoid fear of being "confusing" to the end user, and this was backed up by bogus tests by people who were not novice users, but instead highly experienced users conditioned by years of overtype word processors and thus unable to handle the slightest change in behavior of their programs.
I worked on a word processor then and they had us dedicate 3 pages (!) to describing the optional insertion mode and refused to allow us to default to insert mode being on at startup.
Then in 1984 the Macintosh came out, for *real* novice users, and, guess what, the text editing was in insert *ALL THE TIME* and they spend ZERO pages in their very friendly manual explaining it!
I think the same thing is true of click-to-raise (and click-to-type, but that is another battle) and someday you will wonder how you ever believed differently.
You may think I am full of shit, but I know for a fact that you have not used a non-click-to-raise system for any serious amount of time.
You might allow it when you are not using your connection, however. Then you are helping your neighbor and it isn't costing you anything.
Honestly, I can understand the cable provider's need for something to stop this. However I think the only way is to charge for bandwidth usage. Any other scheme just makes people cheat.
Slashdot Mirror
The complaint is about: Apparently there were DOZENS of mod chips available that let you play copied games, and Sony did not do anything about it. Now the first chip comes out that lets you play copied games, PLUS it lets you play imported disks, and Sony is suddenly attacking this one, and ignoring the others still! This would seem to imply they consider the ability to play imported games a real threat, as opposed to the copies.
Somebody else said that the ability to play imported disks necessarily means the machine will play anything, for techinical reasons. I don't know if this is true, though.
Unfortunately they are also cheaper here than anywhere else. They are most expensive in the poorest 3rd-world countries (if they exist at all there).
Oops.
It is true that anybody that makes a motherboard will test that it runs Windows, but that testing is not going to be very complete and there are many machines that are older than the newest versions of MicroSoft software. I can be pretty sure that if somebody loads WinXP on a machine and it fails, they will blame MicroSoft rather than the unusual BIOS chip in their machine.
So why is this?
You are correct about the slowness. Both KDE and Gnome (and Windows) are forcing huge amounts of complexity on use because nobody designing these has had an actual "innovation". Try ROX or some of the tiny window managers to see some attempts to be different, and compare their sizes to KDE/Gnome/Windows. Unfortunatly I am starting to despair that we will never see an "innovation" because of the vast number of sheep that are locked into the Windows interface, even MicroSoft is having trouble making any changes!
Technically Linux is slower because of Xlib's horrid design. This is a fact and something should be done about it. The solution is not to make some forced toolkit/dll, though, it is to write *HARD* code to do *FAST, POWERFUL* graphics operations.
What I am proposing is that the developers have the ability to put system("gcc /tmp/the_sourc_code.c -o new_plugin.so") into the application. Yea it's hard, but no harder than any other system call, and the end user has as much need to understand it as a need to understand any other call in the system toolbox. The user only thinks they are getting a fast plugin.
The question is if this sort of add-on is allowed. I believe it is, but there may be more information.
MSoft can be a pain and license the header files so they cannot be included by GPL code, their management has threatened to do this but I think their engineers may be showing a little backbone recently and stopping them from being totally mindless assholes.
Setting the line dash style broke in Win98 and WinME. This appears to be a direct attempt to break non-MFC programs that tried to simulate the mouse highlight. It broke Qt, the GTK port, and FLTK. It appears to be fixed again in XP and always worked in NT.
Append, join, subst, (ie every single program that could do anything similar to a symbolic link) disappeared or broke in Window 3.1. Again I think this is a direct attempt by MicroSoft to disallow Unix compatability (symbolic links would allow the MSDOS file system to match a Unix file system, and are probably easy to implement, so I cannot think of any other reason they don't do it).
Support for switchar disappeared in MSDOS 6. This broke most of my programs which exec'd other programs, and again appears to have been done purposely to break Unix compatability (they could instead have made the programs accept either - or / easily enough...).
Storage and retrival of the current directory changed in MSDOS 5 to uppercase the name and turn all forward slashes into backward slashes and truncated all the filenames at 8.3 characters. This broke an enormous amount of Unix-ported software and required it to be rewritten to store the current directory locally.
Since I have done very little Windows programming, yet have encountered these, I would say the claim that Windows remains compatable between versions is false. It also seems to me that most of the changes are on purpose to sabotage the ability to write portable programs.
You can do DRM in an Open Source way, such that OSS software could be allowed to copy a data stream from the network and put it on a device, and despite the full access to the source code it is impossible to use that data stream for any other purpose. This will be *WAY* harder to crack than what MSoft is proposing, the people who want DRM should realize that MSoft will sell "source code" as well, harder to read, but somebody with the right resources can still decode the instructions and chips. It is a lot safer to make a design that assummes the user can read the source.
What is done is you use public/private key encryption. A new DRM display or speaker has this device embedded in epoxy at a very late point. The device has a *fully documented* interface and takes a digital stream input and processes it and puts it on the display, it also has an interface that outputs the public key. Getting the private key would require smashing the device to the point that it is inoperable, so would any attempts to remove this device and insert a home- built one. The device could also have a settable clock imbedded and a random number generator that cannot be set.
A company that wants to send you content that you can only display on your device would request the key. Open source software can read the key and send it. It can also lie and send any key it wants to, but that is pretty useless because you will just get data you cannot use. The provider then checks the key against a trusted central manufacturer database to make sure it is not a fake key by somebody who built their home-brew device. The provider would then send the encrypted data. Open-source software can store the data or send it to the device.
If they want to limit the time they can look at it, the encoded data includes a clock range and the random key. It must match. If you try to reset the clock (this must be allowed because the power might fail, and the provider wants the clock to be at a time in the future) the random number will change. You will have to request the data again, sending the old one (the provider also cannot decode it, but may have a header encoded with their own keys containing the data checksum and the clock you asked for before).
Obviously this system has lots of "fair use" infringements, but it would work, and in fact is probably much more in the interests of the digital content providers. MicroSoft's "solution" is 100% designed to further their own interests. They are as willing to screw the RIAA as to screw the users, you know.
I agree with the questioner as to why the user should care. We need to come up with an interface where there is not difference between closing all the programs and quitting the application.
The GUI purpose of this is to make menu items that create a new document, or configure the program, available, even though the program is closed. I don't have any good ideas here. The original Mac had "paper" that you clicked on to create new documents, one piece of paper for each application. You could also create a new document if you click on the application icon (most do this already). I don't know about configuration, the best I can think of is to require an open document to configure.
Systems where the user cannot tell if the program has really exited are pretty common. People here have mentioned Emacs, but also IE on Windows (and a lot of other MicroSoft software) do this. It would be nice if these hacks were not necessary, if programmers would stop being so lazy and perhaps improve the startup time so having the program already running is not so necessary! But it does not look like that is going to happen, sigh...
If "System Preferences" does something unwanted on exit, I would consider it a bug if it can be exited without at least asking the user!
The problem is that the original Objective C was a C preprocessor that did not even parse things, it acted like a macro processor and replaced any "[...]" sequence preceeded by anthing other than a C identifier with a C function call taking string arguments.
If they had worked harder to parse C some more I'm sure they would have used a syntax like "method(object,...)" so that you could easily switch function calls to method invocations.
Or they could have used SmallTalk unchanged.
But the actual compromise is not something anybody should be proud of!
The only reason to not include the compiler by default is so that Apple could make money selling it (the GPL means any buyer can give away free copies, but Apple could include something non-GPL such as a library or header file in order to make that not useful).
But Apple seems to be giving it away for free, so I am at a loss as to why they did not include it. There is junk on the system disk dozens of times larger than all the development tools (like sample movies and images) so they are not saving much space. And it seems the sales record keeping and pressing of extra $19.95 disks and the free download site are costing more than the marginal cost of sticking them on the distribution.
No, actually all the graphs I saw started at the same time. The difference is the graph I had shows only the last few days, where RHAT does quite well compared to MSFT. By picking other ranges you can find one where MSFT does very well compared to RHAT. In fact if Yahoo let you arbitraily pick the start and end date of the graph it should be possible to search for the range which maximizes (RHATin*MSFTout)/(MSFTin*RHATout) and get something that looks really good for RHAT! (or if you are a MSFT defender, reverse the search and "prove" just the opposite). Lying with statistics is easy and fun.
Then of course as soon as anybody does anything other than xterm (like a control panel) that is laid out, and it runs on a screen that claims a different DPI, they fonts scale and the display is completely messed up! Then, instead of saying "well X is a stupid design" (which is the correct answer), they say "you should design an elaborate toolkit that scales the display to match the font" (which is stupid, besides doing that would be a lot easier if we could control how big the fonts are, anyway!).
Oddly enough MicroSoft copied this in their font interface (must have been an early attempt at sabatoge). They quickly realized their mistake and made negative sizes set the "pixel size", they also froze the systems idea of "DPI" to a constant so anybody using the old interface got predictable results.
Now that I see this, it suddenly seems totally obvious, and in fact I am now at a loss to think of any possible alternative, though I was imagining strange partly-installed package states before. In fact it *has* to work this way!
The problem is that there is an impossible learning step from the "I don't know how to do this" to the "its obvious". This is true of most of Linux (and Windows, too!), and is probably why it is hard to teach.
On a more practical note it is a good sign of how a cli is more easily extended than a gui: a naive GUI to rpm would probably have you click on a file and it installs. But that does not allow you to install two files at the same time! The GUI would have to be comletely rewritten so that you can select a set of files and then hit the "install" button, making the single-file case a lot harder and nonintuitive. While the naive CLI would be "rpm x" and when somebody realized that the multiple files was needed it changes to "rpm x ..." and does not break the old one-file command!
Another note: why the hell does "rpm filename" not do something intelligent? Everybody keeps saying "it's not too hard to type 'rpm -Ivh filename'" but that is completely false. The truth is, it is not too hard to type "rpm filename" (or just "filename", lets put some GUI ideas into the shell) but that "-Ivh" is HARD. I actually think the CLI is a powerful and not hard tool, but these posts are making this argument into a joke.
Face it, everybody here is aware that the stock dropped like a rock and is worthless. I think it is interesting that it is not dropping right now (not that I would recommend anybody buy it, either), since I (and I bet you) would assumme it is still dropping. Why can't people point out facts that contradict the assummed wisdom?
Gee, it's too bad I can't adjust the starting and ending day more precisely, maybe that is a feature we need. At least the other posters (both pro and anti- rhat/linux) brought up these charts at the default settings.
Did any other companines (not counting little things that don't issue stock) put the word "Linux" in their names? I can't think of any but there must be some more examples?
I also think there was something funny going on that caused the stock to inflate so fast. Aren't there some accusations that the brokerage manipulating this and several other stocks?
The advantage of not using Xlib is the hope (maybe a vain hope...) that Xlib can be eradicated from Linux as well.
Linux is winning the renderfarms because the software used has little or no reliance on underlying system or hardware support and is thus not locked into Windows. Most rendering has to read and write files and do a lot of number crunching, so reliance on Windows-proprieterary libraries and interfaces is eliminated (reliance on Unix is also eliminated, the "Linux is Unix and thus easy to port to" argument is greatly exaggerated here).
In such a playing field Linux wins easily. Linux offers a few unimportant technical advantages (much better networking support, and a lot smaller memory usage when no GUI is running), so I think about 50% of the reason for Linux's popularity is due to cost, and about 50% due to the preferences (biases, if you want) of the IT staff.
They are missing video cards, keyboards, and monitors, (and may be missing floppy and CD drives, though the ones I am familiar with are not) and may not be all that valuable to schools.
I do have to say that the gmake file for NT is nice and clean due to the unifomity between the Windows platforms. A lot of pain would be saved if the Unix people started refusing to support some of the older and non-standard Unix versions so that we could use a single makefile.
One comment: if at all possible, the biggest win in readability and maintanability is to put explicit #ifdefs into the source, and use gmake and the output of uname to put 'if's into the makefile. This stuff is immesurably easier for a programmer to figure out and debug than autoconf. It would be nice if somebody made a make replacement that explicity compiled the dependency rules from a sequential language with normal if and looping constructs and obvious built-in tests for all the stuff in autoconf.
I still find it hard to believe you have not tried a system that does not raise the windows when you click on them. BlackBox by default raises the window on clicks (so did NeXTStep, which BlackBox copies). Last time I tried it it was impossible to turn off this behavior unless you also switched to point-to-type.
If raising to type is so important, why does MicroSoft (and Gnome and KDE) go through all this trouble of making toolbars and docks and non-modal dialog boxes that stay on top even though you can interact with the lower windows? The answer is that in fact they are working around a basic design error by "fixing" it in the specific cases where it is most annoying.
This is exactly the same as the state of word processors in 1980 or so. It took ages (like 4 years or more) for the concepts of always-on insert mode and of a newline being a character you could insert and delete like any other from appearing in commercial word processors, despite ten years or more of the existence of such ideas in Emacs or other "professional software". The reason was a total paranoid fear of being "confusing" to the end user, and this was backed up by bogus tests by people who were not novice users, but instead highly experienced users conditioned by years of overtype word processors and thus unable to handle the slightest change in behavior of their programs.
I worked on a word processor then and they had us dedicate 3 pages (!) to describing the optional insertion mode and refused to allow us to default to insert mode being on at startup.
Then in 1984 the Macintosh came out, for *real* novice users, and, guess what, the text editing was in insert *ALL THE TIME* and they spend ZERO pages in their very friendly manual explaining it!
I think the same thing is true of click-to-raise (and click-to-type, but that is another battle) and someday you will wonder how you ever believed differently.
You may think I am full of shit, but I know for a fact that you have not used a non-click-to-raise system for any serious amount of time.
Honestly, I can understand the cable provider's need for something to stop this. However I think the only way is to charge for bandwidth usage. Any other scheme just makes people cheat.