This is NOT the "holy grail"
on
CNet on WinFS
·
· Score: 1
I will describe the "holy grail":
1. There is ONE call to get any piece of data on the system. This takes a "name" which is a block of bytes and a length. No bytes are illegal in that block. This means you get the name of files, their size, the protection attributes, the data, the "resource fork" and everything with the same call. There are NO other calls that return information.
2. The information returned is a block of bytes and a length. Notice that this is exactly the same format that names are. You may have to use "read" and "seek" calls to look at this block of data, but you know it is a block of data. The block of data can range from 0 bytes in length to any number of terabytes, short files (less than 100 bytes) would be stored extremely efficiently.
3. When a filename identifies a block of data, adding a special divider character (ideally nul, but it will probably have to be "/") to the end and then more characters, will identify sub-parts or attributes of this block of data. This can be done by providing the block of data to a user-level program that further parses it (imagine a tar file or compressed), or a user-level program that even communicates with other systems (imagine a filename that indicates a document over http). Although these programs can interpret the text after the slash in any way they want, calling programs will likely assume that adding any character other than '/' to a name will not get a sub-part, but instead get a 'brother' of that previous name.
4. These blocks of data are atomic. You can create a new one and nobody sees that fact until you close it and they then open the same name. You can modify one and nobody sees that fact until you close it and they open it. If they have already opened the file they will see the old data until they close it.
5. There are calls to insert data into the blocks as well as overwrite it. In fact it may be ok if insertion and truncation are the only write operations.
This is NOT what Microsoft is going to come up with! Why? Because it is too simple to emulate this on other systems and thus remove any uniqueness of Windows. They do not want this and they will not make it. Because this is not what they are going to make, though, they cannot say they are making the "holy grail" without lying.
The BIOS in fact required *TWO* calls to draw a character on the screen. One call moved the cursor, and another call put a character under the cursor without moving it. This is twice as bad as the worst possible design I would have thought possible.
It seems difficult to believe that anybody smart enough to run an assember could design such a pessimissicly bad design, but those IBM engineers did it.
You write to an I/O address that causes the video memory to respond and turns off the normal memory in that same area. This was pretty common then and was called bank-switching, which I referred to.
You are correct that bank-switching is pretty obsolete nowadays and not used. Partly due to the fact that modern devices take only 1/100 or so of the available memory space, while then a video screen took about 1/10 (or 1/2 on 64k machines). The other reason is that virtual memory means that "holes" such as the IBM-PC had at 640K are no longer a problem, as a continuous address space can still be presented to the applications.
Using the GPL and LGPL on software is for extremely selfish, greedy, and capitalistic reasons. It means the author retains control over the software, while still letting people use it. Others cannot modify the and sell the software without the original author having the ability to see those modifications. But the original author retains the right to do anything with the software, including making closed-source modifications and selling them! In fact the GPL could be a very powerful way for a corporation to force a standard that they control onto all machines, and certainly serves as a way for a corporation to advertise it's own programming ability without losing any rights to what they wrote.
I am absolutely certain that all the authors who chose the GPL (rather than BSD) license for their code did it for selfish reasons. Maybe to make money or retain the ability to make money. Maybe to refuse others the ability to make money or changes to their code. Maybe to refuse others the ability to hide their original contributions and remove attribution for their work.
We have entered into an age of Newspeak though when a license designed to protect the original author's rights is considered "communistic", while a giant corporation that controls what you can do with your personal property is considered "capitalistic"
Although I have heard that Gates never said this, you are misinformed about the state of things in 1983 (not 1981, at that time there was no 640k barrier, there was either a 64K or a 1meg barrier).
Having 1 megabyte of memory was well within the realms of possibility. 256K chips were available and 32 of these would give you 1 megabyte. And the 8088 used by the IBM PC was designed to address 1 megabyte. It had 20 address lines.
The complaint that probably gave rise to this was that the IBM PC design dumped the video memory at the 640K location, thus splitting the memory and making the top third almost useless. At that time bank switching the video memory was quite common and they should have done this, or at least put the video memory all the way at the end and thus given a 1044K limit. This stupidity was certainly IBM's fault, Microsoft had nothing to do with that design, I believe.
However the 640K limit was complained about plenty, by people comparing it to the 1Meg limit that the hardware naturally had. Maybe even Bill Gates complained or defended this design, giving rise to this quote.
Unfortunatly history has been mangled and people think the complaint was comparing to more modern multi-megabyte machines. Actually the complaint is similar to complaints about the versions of Windows and Linux that could not do more than 2Gigabytes, even though the Pentium can address 4 gigabytes. The complaint was about a factor of 2, not of 100.
Files should be identified by a series of bytes. Especially as file systems evolve to be more like data bases. We should not have to write huge kludges in software in order to recode the names we want into some idiot's idea of what is a "legal file name". We got rid of record-oriented text-only file data before 1970, replacing them with raw binary data, and it is universally considered a huge win and the basis of all modern computer systems. But since then only Unix has had the brains to realize that these same rules apply to filenames (almost, it still does not like the 0 byte or the "/" byte, but that is enormously better than any other system).
I am absolutely floored that the same people who claim "command line is hard" are the same ones who will argue incessently for case-insensitivity, when this is a feature that is ONLY for use by command-line programs!!! GUI users click on files and would never notice if more than one had the same name, and in modern GUI's they are often clicking on a representation of the data and couldn't care less what the file name is at all.
Why people think this UI issue must be "solved" at such a low level is beyond me. People also confuse one space with two and "0" with "O" but for some reason nobody seems to think it is a good idea to fix that with the file systems, but they seem completely brainwashed into believing that this must be done or the system is somehow "hard to use". In reality it would be trivial to achieve this at the application level (along with spelling correction of typed filenames and many other related fixes) but nobody tries this because of the perverse fact that the non-unique and unpredictable mapping of byte streams to filenames makes such solutions more difficult!
It's really hard if your program only supports English.
However if your program already supports multiple languages, including several others that are right-to-left, and the other version of the program for Windows already supports this language, it is very easy. This is the source of the complaint.
How come the games, which expect to be running off the CD, work when there is no CD? I would think that even if they did not try to prevent this, there would be plenty of calls to the system that would act different because there is no CD in the drive and the game does not work.
Though I agree with some of your stuff, I think C++ could be improved even if you don't improve the linkers.
Your explanation that the vtable must be built from the public headers is wrong. All the modern compilers build it only in one source file (the rules vary but typically the one containing the first virtual function). It should be possible to add syntax to allow this to be more supported.
My proposal:
1. You should be able to define a new private member function at any time. Just write "int Foo::bar() {...}" and you will have a private method called bar(), whether or not it is defined in the header. This does not break any object-orientedness, as only other private members can call this. But it does get rid of a lot of annoyance in implementing classes, where you have to debate whether to change the header files or instead duplicate code or use pointers in order to get the implementation you want. Also private static data, and private static methods (probably by putting "static" before them).
2. Allow the token "..." to be at the end of a class definition. This is an indication that there are more items afterwards. This means the sizeof() and entire vtable is not yet determined. However a lot of inline functions can be declared. C++ already supports this as saying "class Foo;" is the same as saying "class Foo {...};" in this new syntax. You can also declare the rest of a class by declaring it again with "..." at the start, if the compiler sees this it knows that the vtable can be defined now.
While we are at it, I would really like to see a phony type called "0" which can be used as an argument class. "0" is unique in that it is the only type that can be automatically cast to a pointer or a number. A function declared as "int foo(0)" would be called in preference to "int foo(int)" when the argument is a literal zero. This would allow classes to match pointers better, and allow the compiler to compile around the "if" that is normally needed in the common case where initializing to a null or zero value is significanlty different that initializing to anything else.
Since zero work or communication is needed to "obtain" the right to redistribute the source, it can be considered a gift or grant by the GPL. Another way to look at it is that somebody who has zero interest in redistributing the source still has the rights to do so. If in fact there was some "work" required to "obtain" these rights, then the person with zero interest in using these rights would not have them, right?
The theory is that no monopoly can control Linux because anybody who wants to can make their own version. So an alternative could rise pretty easily, and people could switch to it pretty easily, thus preventing an evil Linux company from taking over.
However I would expect that IBM or RedHat or Microsoft or whoever becomes the dominant Linux distributor could slap enough proprietary stuff on top that people will be unable to switch. I mean you can switch from an Intel to an AMD processor right now, but that does not mean you can as easily get away from Microsoft, the same thing would be true, just at a higher level.
Still it would be better than the current situation.
1. X has problems, but like many of it's detractors you don't know what the problems are. The networking is NOT the problem, nor is the encode/decode overhead. In fact any secure windowing system is going to require a context switch, and the encoding/decoding into a stream allows the number of context switches per command to be 1/1000 or less, as opposed to the 1:1 level for Windows. The networking actually *helps* here, plus the minor advantage that you get remote display for free.
X's problems are: #1 is the ancient colormap and blt graphics model that pretty much requires any advanced drawing to draw a local bitmap and send it. #2 the source of your lagging window dragging is the seperation of the window borders into the "window manager", they should instead be drawn by the same program that draws the rest of the window, in fact this could even be slower and people will think it is better, as long as the window all moves and resizes as one unit, and the previous image is erased all at once.
2. "Consistent widget set". Here I very much disagree. On Windows programs use different widget sets (maybe you have not tried any 3D modelling programs or any games or media players on Windows?). The only concrete thing people say ("shortcuts are different between programs") is in fact not enforced even if you used MFC for everything. And I would like to meet that mythical user who is "confused" because the borders on the buttons are different colors between their programs. Nobody seems too worried that the buttons on their phones are different colors or shapes, and in fact the competing phone companies actually actively make them different. Personally I think this "consistency" argument is bogus, and too often used when in fact the real problem is *bad* interfaces.
3. C++ less efficient? I don't think so.
4. Avoid.so hell. Here I agree with you 100%. Listen up Gnome people: the fact that two programs use the same function does NOT mean you have to put it in a shared library! Big deal you just saved a few hundred bytes of memory, but you are causing endless pain! There should be ONE shared library that covers everything involved in any normal application that draws on the screen. Okay I'll let you also require xlib, but eventually even that should go in.
5. Fast browser: I use Konq and it seems pretty good.
6. yea
7. I am also amazed at how well wine is working.
8. I'm afraid "backwards compatability" is absolutely vital. No matter what is written as an alternative word processor, the number 1 question anybody wants to know is "can it import/export MSWord?" Import means import the actual programming so automatic page numbers and so on work, so your idea of using the HTML output of Word is useless.
9. I agree that there is nothing wrong with compiling stuff as part of the job of installation. The users really don't seem to care how long it takes to install. And there is no reason compiling cannot be hidden behind a user-friendly facade just like all the cp and chmod stuff that those installers do already.
10. I agree, close all the ports by default. A user is much more likely to find out how to turn on what they need than to turn things off. Microsoft could do this as well, though they have this rabid need to control the end user's computer and will probably keep something running listening to outside commands.
Although I see no need to turn it into an hourglass, it would help a big deal if you would only get one copy of the program even if you clicked many times.
I think this requires Linux to start being daring and add a few things that have been long missing from Unix. As far as I can tell there is no reliable way to determine if a program you are about to run is already running. Something should be added to do this.
The launcher can then send a signal to the program and it can respond by raising it's windows.
Getting a different result from middle-click and Ctrl+V is the result of fixing the clipboard. In fact in all modern programs you will get different results. Some broken programs will give the same result for both actions, the same as the new programs do for middle-click.
Think hard: middle-click can really be considered an improved version of drag & drop, where you can rearrange, open and close, and raise windows before you finish a drop. Selecting text starts a drag, clicking the middle mouse button ends. You might as well be complaining that Ctrl+V on Windows does not paste the most recent object you dragged.
At first I thought this was really an accident, but in fact reading some of the early ICCCM documents, it was fully intended that the middle mouse be seperate from any permanent clipboard, and the clipboard setup used by KDE and Gnome (and fltk) now is the original design, not a fix. The ICCCM documents did confuse things by not calling it drag & drop (a term that existed even then, I believe) and also with a lot of talk about an obsolete idea for a third buffer called the "secondary selection" intended to allow people to swap two pieces of text (a probably stupid and now obsolete idea).
In any case, the fixed programs do something different. This is a GOOD thing!
So the GPL doesn't grant anything that normal copyright law doesn't grant. It only grants an easier path to obtain permission to redistribute than most copyrighted works happen to.
The GPL does "grant" permission to redistribute and spells out exactly how you can. You don not have to "obtain" permission, so this certainly is a grant of a freedom that normal copyright does not have.
Even a copyright that says "you can copy this if you send me your first-born" is a grant of freedom, since in normal copyright you cannot copy even if you do send your first-born.
If you have a piece of GPL code, you can still do everything you can with copyright, for instance you can still ask the original author for permission to copy the work (in case you want to copy it in ways that are not granted by the GPL).
I think the reason so many are confused about the GPL is that for 99% of the users it has no effect (since they are not intending to copy and redistribute the programs). There is also the fact that receiving any large block of legalese usually means somehow that you are getting screwed. And also for the modern person, almost any piece of source code they have ever seen has been public domain, leading them to the conclusion that this is the natural state for visible source code and thus to the conclusion that the GPL is some kind of restriction (while those same people would think a GPL on a printed book would be a grant, since the natural state for a printed book is that you are not allowed to copy it). Oddly enough these same people who complain about the GPL's "restrictions" don't see any problem with the fact that they cannot copy closed source compiled binaries, and would not even complain if they recieved a copy of linux that was missing the source. But somehow the existence of source code that they can read but cannot copy is somehow a huge restriction on their freedom, while the absence of that source code at all is ok.
If IBM really stole SCO's code and put it in Linux, and that is damaging SCO's business, then the number one priority of SCO is to get that code out of Linux, so that it can stop damaging their business. They can then go and sue IBM for damages.
SCO is refusing to do the one step that would be absolutely vital to them if they want to stop this "damage" from any stolen IP. They must identify the exact code so it can be removed and thus mitigate their damages. Not doing so is proof that the stolen code is actually worthless to them.
You are absolutely right that SCO has the right to prove that IBM stole their code and the right to sue IBM for it. The problem with SCO is that has little or nothing to do with their actual actions. What SCO does is print press releases, apparently designed to convince idiot investors that either they are going to get paid by IBM or all Linux users, or that Microsoft will pay them.
Don't be a moron. Windows could easily pop up a "push here to run the disk" button. You could then push it, or ignore/cancel it and hit play in your CD player instead. Real CD's would like this because people would not miss the opening animation.
And if this was such a great idea, why don't hardware CD players have "autorun"? I have three of these and all of them require me to hit play before they play the disk I inserted (granted some have autorun, but at least 3 dont).
Why do spammers make much uglier, misspelled, and weird garbage-filled mail in attempts to get around the filters? If what this guy says was true, they would not be doing that.
The "convoluted javascript" itself may be detected by a Bayesian filter and the message can be rejected due to that, without actually figuring out the javascript.
I'm pretty certain filters are already deleting mail due to detection of the use of unnecesssary HTML entities. Thus the spammers attempts to get around the detection actually makes their mail easier to detect.
No matter what method is used to detect if a program is a pirate copy, making it work "degraded" rather than failing outright is a very good idea if you want to prevent piracy.
The reason is that it makes it much harder for the person trying to crack the copy protection to figure out if they did it. They have to have a reliable test to see if it is "degraded" and they have to wait at least as long as the test takes. Ideally the program should work perfectly for many minutes and then start to degrade. So even perfect detection of degradation has to wait many minutes.
The risk is that the cracker will instead go after the degradation instructions rathar than the actual copy-detection instructions, thus they have more chances to "fix" the software. However I think this is way offset by the increased difficulty of figuring out if you successfully cracked the program.
I would not be suprised if doing nothing but *claiming* this degradation happens may be the most effective copy protection of all. The crackers will be driven nuts trying to figure out if they have cracked it successfully or not!
In addition, I really suspect this has nothing to do with any physical degradation of the disk. They have (or claim to have) some method of detecting the original disk, like weird pits on the original CD. But I think it is unlikely these change over time or anything.
In our software (digital compositing) I have given up on getting correct png gamma values, they are *always* wrong. Not just photoshop but all other software I have seen that writes png does this. Our software always ignores it and assummes the sRGB gamma (ie it assummes the 8-bit data goes unchanged to the display).
That's nonsense. If in reality it was impossible to sell Windows at all, there would be MANY alternatives that would appear. Perhaps 25% of them would be variations of Linux with Wine, maybe 25% pure Linux and BSD. And perhaps 25% would be all new systems with (gasp!) innovations (something sorely lacking from Microsoft and Linux). Also you seem to have forgotten Macintosh, which would immediately expand to about 25% of the market.
It would actually be an amazing and productive similar to the 1980's in software advancement and hardware sales.
Sadly it is not going to happen. Windows is going to continue to be sold. Absolutely worst that could happen is that IE's ability to load plugins will be removed.
Slashdot Mirror
I will describe the "holy grail":
1. There is ONE call to get any piece of data on the system. This takes a "name" which is a block of bytes and a length. No bytes are illegal in that block. This means you get the name of files, their size, the protection attributes, the data, the "resource fork" and everything with the same call. There are NO other calls that return information.
2. The information returned is a block of bytes and a length. Notice that this is exactly the same format that names are. You may have to use "read" and "seek" calls to look at this block of data, but you know it is a block of data. The block of data can range from 0 bytes in length to any number of terabytes, short files (less than 100 bytes) would be stored extremely efficiently.
3. When a filename identifies a block of data, adding a special divider character (ideally nul, but it will probably have to be "/") to the end and then more characters, will identify sub-parts or attributes of this block of data. This can be done by providing the block of data to a user-level program that further parses it (imagine a tar file or compressed), or a user-level program that even communicates with other systems (imagine a filename that indicates a document over http). Although these programs can interpret the text after the slash in any way they want, calling programs will likely assume that adding any character other than '/' to a name will not get a sub-part, but instead get a 'brother' of that previous name.
4. These blocks of data are atomic. You can create a new one and nobody sees that fact until you close it and they then open the same name. You can modify one and nobody sees that fact until you close it and they open it. If they have already opened the file they will see the old data until they close it.
5. There are calls to insert data into the blocks as well as overwrite it. In fact it may be ok if insertion and truncation are the only write operations.
This is NOT what Microsoft is going to come up with! Why? Because it is too simple to emulate this on other systems and thus remove any uniqueness of Windows. They do not want this and they will not make it. Because this is not what they are going to make, though, they cannot say they are making the "holy grail" without lying.
The BIOS in fact required *TWO* calls to draw a character on the screen. One call moved the cursor, and another call put a character under the cursor without moving it. This is twice as bad as the worst possible design I would have thought possible.
It seems difficult to believe that anybody smart enough to run an assember could design such a pessimissicly bad design, but those IBM engineers did it.
You write to an I/O address that causes the video memory to respond and turns off the normal memory in that same area. This was pretty common then and was called bank-switching, which I referred to.
You are correct that bank-switching is pretty obsolete nowadays and not used. Partly due to the fact that modern devices take only 1/100 or so of the available memory space, while then a video screen took about 1/10 (or 1/2 on 64k machines). The other reason is that virtual memory means that "holes" such as the IBM-PC had at 640K are no longer a problem, as a continuous address space can still be presented to the applications.
Using the GPL and LGPL on software is for extremely selfish, greedy, and capitalistic reasons. It means the author retains control over the software, while still letting people use it. Others cannot modify the and sell the software without the original author having the ability to see those modifications. But the original author retains the right to do anything with the software, including making closed-source modifications and selling them! In fact the GPL could be a very powerful way for a corporation to force a standard that they control onto all machines, and certainly serves as a way for a corporation to advertise it's own programming ability without losing any rights to what they wrote.
I am absolutely certain that all the authors who chose the GPL (rather than BSD) license for their code did it for selfish reasons. Maybe to make money or retain the ability to make money. Maybe to refuse others the ability to make money or changes to their code. Maybe to refuse others the ability to hide their original contributions and remove attribution for their work.
We have entered into an age of Newspeak though when a license designed to protect the original author's rights is considered "communistic", while a giant corporation that controls what you can do with your personal property is considered "capitalistic"
Although I have heard that Gates never said this, you are misinformed about the state of things in 1983 (not 1981, at that time there was no 640k barrier, there was either a 64K or a 1meg barrier).
Having 1 megabyte of memory was well within the realms of possibility. 256K chips were available and 32 of these would give you 1 megabyte. And the 8088 used by the IBM PC was designed to address 1 megabyte. It had 20 address lines.
The complaint that probably gave rise to this was that the IBM PC design dumped the video memory at the 640K location, thus splitting the memory and making the top third almost useless. At that time bank switching the video memory was quite common and they should have done this, or at least put the video memory all the way at the end and thus given a 1044K limit. This stupidity was certainly IBM's fault, Microsoft had nothing to do with that design, I believe.
However the 640K limit was complained about plenty, by people comparing it to the 1Meg limit that the hardware naturally had. Maybe even Bill Gates complained or defended this design, giving rise to this quote.
Unfortunatly history has been mangled and people think the complaint was comparing to more modern multi-megabyte machines. Actually the complaint is similar to complaints about the versions of Windows and Linux that could not do more than 2Gigabytes, even though the Pentium can address 4 gigabytes. The complaint was about a factor of 2, not of 100.
Files should be identified by a series of bytes. Especially as file systems evolve to be more like data bases. We should not have to write huge kludges in software in order to recode the names we want into some idiot's idea of what is a "legal file name". We got rid of record-oriented text-only file data before 1970, replacing them with raw binary data, and it is universally considered a huge win and the basis of all modern computer systems. But since then only Unix has had the brains to realize that these same rules apply to filenames (almost, it still does not like the 0 byte or the "/" byte, but that is enormously better than any other system).
I am absolutely floored that the same people who claim "command line is hard" are the same ones who will argue incessently for case-insensitivity, when this is a feature that is ONLY for use by command-line programs!!! GUI users click on files and would never notice if more than one had the same name, and in modern GUI's they are often clicking on a representation of the data and couldn't care less what the file name is at all.
Why people think this UI issue must be "solved" at such a low level is beyond me. People also confuse one space with two and "0" with "O" but for some reason nobody seems to think it is a good idea to fix that with the file systems, but they seem completely brainwashed into believing that this must be done or the system is somehow "hard to use". In reality it would be trivial to achieve this at the application level (along with spelling correction of typed filenames and many other related fixes) but nobody tries this because of the perverse fact that the non-unique and unpredictable mapping of byte streams to filenames makes such solutions more difficult!
It's really hard if your program only supports English.
However if your program already supports multiple languages, including several others that are right-to-left, and the other version of the program for Windows already supports this language, it is very easy. This is the source of the complaint.
How come the games, which expect to be running off the CD, work when there is no CD? I would think that even if they did not try to prevent this, there would be plenty of calls to the system that would act different because there is no CD in the drive and the game does not work.
Though I agree with some of your stuff, I think C++ could be improved even if you don't improve the linkers.
Your explanation that the vtable must be built from the public headers is wrong. All the modern compilers build it only in one source file (the rules vary but typically the one containing the first virtual function). It should be possible to add syntax to allow this to be more supported.
My proposal:
1. You should be able to define a new private member function at any time. Just write "int Foo::bar() {...}" and you will have a private method called bar(), whether or not it is defined in the header. This does not break any object-orientedness, as only other private members can call this. But it does get rid of a lot of annoyance in implementing classes, where you have to debate whether to change the header files or instead duplicate code or use pointers in order to get the implementation you want. Also private static data, and private static methods (probably by putting "static" before them).
2. Allow the token "..." to be at the end of a class definition. This is an indication that there are more items afterwards. This means the sizeof() and entire vtable is not yet determined. However a lot of inline functions can be declared. C++ already supports this as saying "class Foo;" is the same as saying "class Foo {...};" in this new syntax. You can also declare the rest of a class by declaring it again with "..." at the start, if the compiler sees this it knows that the vtable can be defined now.
While we are at it, I would really like to see a phony type called "0" which can be used as an argument class. "0" is unique in that it is the only type that can be automatically cast to a pointer or a number. A function declared as "int foo(0)" would be called in preference to "int foo(int)" when the argument is a literal zero. This would allow classes to match pointers better, and allow the compiler to compile around the "if" that is normally needed in the common case where initializing to a null or zero value is significanlty different that initializing to anything else.
Since zero work or communication is needed to "obtain" the right to redistribute the source, it can be considered a gift or grant by the GPL. Another way to look at it is that somebody who has zero interest in redistributing the source still has the rights to do so. If in fact there was some "work" required to "obtain" these rights, then the person with zero interest in using these rights would not have them, right?
The theory is that no monopoly can control Linux because anybody who wants to can make their own version. So an alternative could rise pretty easily, and people could switch to it pretty easily, thus preventing an evil Linux company from taking over.
However I would expect that IBM or RedHat or Microsoft or whoever becomes the dominant Linux distributor could slap enough proprietary stuff on top that people will be unable to switch. I mean you can switch from an Intel to an AMD processor right now, but that does not mean you can as easily get away from Microsoft, the same thing would be true, just at a higher level.
Still it would be better than the current situation.
1. X has problems, but like many of it's detractors you don't know what the problems are. The networking is NOT the problem, nor is the encode/decode overhead. In fact any secure windowing system is going to require a context switch, and the encoding/decoding into a stream allows the number of context switches per command to be 1/1000 or less, as opposed to the 1:1 level for Windows. The networking actually *helps* here, plus the minor advantage that you get remote display for free.
.so hell. Here I agree with you 100%. Listen up Gnome people: the fact that two programs use the same function does NOT mean you have to put it in a shared library! Big deal you just saved a few hundred bytes of memory, but you are causing endless pain! There should be ONE shared library that covers everything involved in any normal application that draws on the screen. Okay I'll let you also require xlib, but eventually even that should go in.
X's problems are: #1 is the ancient colormap and blt graphics model that pretty much requires any advanced drawing to draw a local bitmap and send it. #2 the source of your lagging window dragging is the seperation of the window borders into the "window manager", they should instead be drawn by the same program that draws the rest of the window, in fact this could even be slower and people will think it is better, as long as the window all moves and resizes as one unit, and the previous image is erased all at once.
2. "Consistent widget set". Here I very much disagree. On Windows programs use different widget sets (maybe you have not tried any 3D modelling programs or any games or media players on Windows?). The only concrete thing people say ("shortcuts are different between programs") is in fact not enforced even if you used MFC for everything. And I would like to meet that mythical user who is "confused" because the borders on the buttons are different colors between their programs. Nobody seems too worried that the buttons on their phones are different colors or shapes, and in fact the competing phone companies actually actively make them different. Personally I think this "consistency" argument is bogus, and too often used when in fact the real problem is *bad* interfaces.
3. C++ less efficient? I don't think so.
4. Avoid
5. Fast browser: I use Konq and it seems pretty good.
6. yea
7. I am also amazed at how well wine is working.
8. I'm afraid "backwards compatability" is absolutely vital. No matter what is written as an alternative word processor, the number 1 question anybody wants to know is "can it import/export MSWord?" Import means import the actual programming so automatic page numbers and so on work, so your idea of using the HTML output of Word is useless.
9. I agree that there is nothing wrong with compiling stuff as part of the job of installation. The users really don't seem to care how long it takes to install. And there is no reason compiling cannot be hidden behind a user-friendly facade just like all the cp and chmod stuff that those installers do already.
10. I agree, close all the ports by default. A user is much more likely to find out how to turn on what they need than to turn things off. Microsoft could do this as well, though they have this rabid need to control the end user's computer and will probably keep something running listening to outside commands.
Although I see no need to turn it into an hourglass, it would help a big deal if you would only get one copy of the program even if you clicked many times.
I think this requires Linux to start being daring and add a few things that have been long missing from Unix. As far as I can tell there is no reliable way to determine if a program you are about to run is already running. Something should be added to do this.
The launcher can then send a signal to the program and it can respond by raising it's windows.
Getting a different result from middle-click and Ctrl+V is the result of fixing the clipboard. In fact in all modern programs you will get different results. Some broken programs will give the same result for both actions, the same as the new programs do for middle-click.
Think hard: middle-click can really be considered an improved version of drag & drop, where you can rearrange, open and close, and raise windows before you finish a drop. Selecting text starts a drag, clicking the middle mouse button ends. You might as well be complaining that Ctrl+V on Windows does not paste the most recent object you dragged.
At first I thought this was really an accident, but in fact reading some of the early ICCCM documents, it was fully intended that the middle mouse be seperate from any permanent clipboard, and the clipboard setup used by KDE and Gnome (and fltk) now is the original design, not a fix. The ICCCM documents did confuse things by not calling it drag & drop (a term that existed even then, I believe) and also with a lot of talk about an obsolete idea for a third buffer called the "secondary selection" intended to allow people to swap two pieces of text (a probably stupid and now obsolete idea).
In any case, the fixed programs do something different. This is a GOOD thing!
most copyrighted works happen to.
The GPL does "grant" permission to redistribute and spells out exactly how you can. You don not have to "obtain" permission, so this certainly is a grant of a freedom that normal copyright does not have.
Even a copyright that says "you can copy this if you send me your first-born" is a grant of freedom, since in normal copyright you cannot copy even if you do send your first-born.
If you have a piece of GPL code, you can still do everything you can with copyright, for instance you can still ask the original author for permission to copy the work (in case you want to copy it in ways that are not granted by the GPL).
I think the reason so many are confused about the GPL is that for 99% of the users it has no effect (since they are not intending to copy and redistribute the programs). There is also the fact that receiving any large block of legalese usually means somehow that you are getting screwed. And also for the modern person, almost any piece of source code they have ever seen has been public domain, leading them to the conclusion that this is the natural state for visible source code and thus to the conclusion that the GPL is some kind of restriction (while those same people would think a GPL on a printed book would be a grant, since the natural state for a printed book is that you are not allowed to copy it). Oddly enough these same people who complain about the GPL's "restrictions" don't see any problem with the fact that they cannot copy closed source compiled binaries, and would not even complain if they recieved a copy of linux that was missing the source. But somehow the existence of source code that they can read but cannot copy is somehow a huge restriction on their freedom, while the absence of that source code at all is ok.
And exactly why are you seem convinced this obvious idea won't be done by KDE?
Or NeWS a couple years before that!
If IBM really stole SCO's code and put it in Linux, and that is damaging SCO's business, then the number one priority of SCO is to get that code out of Linux, so that it can stop damaging their business. They can then go and sue IBM for damages.
SCO is refusing to do the one step that would be absolutely vital to them if they want to stop this "damage" from any stolen IP. They must identify the exact code so it can be removed and thus mitigate their damages. Not doing so is proof that the stolen code is actually worthless to them.
You are absolutely right that SCO has the right to prove that IBM stole their code and the right to sue IBM for it. The problem with SCO is that has little or nothing to do with their actual actions. What SCO does is print press releases, apparently designed to convince idiot investors that either they are going to get paid by IBM or all Linux users, or that Microsoft will pay them.
Don't be a moron. Windows could easily pop up a "push here to run the disk" button. You could then push it, or ignore/cancel it and hit play in your CD player instead. Real CD's would like this because people would not miss the opening animation.
And if this was such a great idea, why don't hardware CD players have "autorun"? I have three of these and all of them require me to hit play before they play the disk I inserted (granted some have autorun, but at least 3 dont).
I think my false positive rate will actually be much lower than 10%! So this works much better for me!
Why do spammers make much uglier, misspelled, and weird garbage-filled mail in attempts to get around the filters? If what this guy says was true, they would not be doing that.
The "convoluted javascript" itself may be detected by a Bayesian filter and the message can be rejected due to that, without actually figuring out the javascript.
I'm pretty certain filters are already deleting mail due to detection of the use of unnecesssary HTML entities. Thus the spammers attempts to get around the detection actually makes their mail easier to detect.
No matter what method is used to detect if a program is a pirate copy, making it work "degraded" rather than failing outright is a very good idea if you want to prevent piracy.
The reason is that it makes it much harder for the person trying to crack the copy protection to figure out if they did it. They have to have a reliable test to see if it is "degraded" and they have to wait at least as long as the test takes. Ideally the program should work perfectly for many minutes and then start to degrade. So even perfect detection of degradation has to wait many minutes.
The risk is that the cracker will instead go after the degradation instructions rathar than the actual copy-detection instructions, thus they have more chances to "fix" the software. However I think this is way offset by the increased difficulty of figuring out if you successfully cracked the program.
I would not be suprised if doing nothing but *claiming* this degradation happens may be the most effective copy protection of all. The crackers will be driven nuts trying to figure out if they have cracked it successfully or not!
In addition, I really suspect this has nothing to do with any physical degradation of the disk. They have (or claim to have) some method of detecting the original disk, like weird pits on the original CD. But I think it is unlikely these change over time or anything.
In our software (digital compositing) I have given up on getting correct png gamma values, they are *always* wrong. Not just photoshop but all other software I have seen that writes png does this. Our software always ignores it and assummes the sRGB gamma (ie it assummes the 8-bit data goes unchanged to the display).
That's nonsense. If in reality it was impossible to sell Windows at all, there would be MANY alternatives that would appear. Perhaps 25% of them would be variations of Linux with Wine, maybe 25% pure Linux and BSD. And perhaps 25% would be all new systems with (gasp!) innovations (something sorely lacking from Microsoft and Linux). Also you seem to have forgotten Macintosh, which would immediately expand to about 25% of the market.
It would actually be an amazing and productive similar to the 1980's in software advancement and hardware sales.
Sadly it is not going to happen. Windows is going to continue to be sold. Absolutely worst that could happen is that IE's ability to load plugins will be removed.