Okay, finally an explanation as to what is going on. I read all that mailing list and I still had no idea.
However it is not clear why any of this could not be done by GM as it modifies a page. Couldn't GM "read a preferences file" and then act on that to change the modifications to the page, rather than relying on inserting a command into the page to read the preferences? That would seem to avoid the need for this obviously bad idea. Or is there a better example where this does something you really couldn't do otherwise?
That does sound good. In fact the labels can point anywhere and thus the user can label anything that can be named, such as url's or files in other user's directories, etc.
I very much want to see a non-GUI api that the gui is built on top of, in it's own *relatively small* library. The fact that you have to link in all of kde/gnome in order to use their prefix filename scheme is making that a dead-end, if kde/gnome is required for this it is going nowhere. As I see it, some interface to take a set of labels, and another that takes a standard "single string" representation of a set of lables, and returns a list of matches, would work. Also the ability to add or delete any label from any file.
The actual filename can be left up to the program. However I expect the GUI will just present the user with the ability to add as many labels. It will pick one to name the file, adding suffixes as needed to avoid name collisions.
Well, no, I'm thinking the opposite. The whole point of the design is so that existing programs can work and you can communicate a "label" identifier of a file to it. I don't see any reason that the vast majority of programs won't work with a file system that interprets names this way. As the first poster pointed out, there may be problems with programs that search directories recursively.
On the other hand, trying to make my proposal atop an existing filesystem would require the creation of vast numbers of very small directories, this is probably way too expensive. I think the file system has to change.
Putting it in the GUI library is NOT the thing to do. We need open("name") to work. This is also why we need FUSE. It is useless that KDE lets some programs open a filename with http: at the start, we need *all* programs to open it, and there is no need for any other interface, thus I think the only correct thing to do is replace the open() system call. Same is true of any label-based filesystem.
Your ideas match pretty much what I have heard as the way to implement labels.
We certainly don't want a different interface for opening hierarchial files and labelled files. Unfortunatly one fear of having Apple or Microsoft do this is that they won't get it and will put in a different interface, possibly botching it so bad that you cannot use a string to identify a file.
The directory "/set1/set2/set3" would contain all the files that are in all three of those sets. If any of those files are also in another set (set4) there *may* be a subdirectory called set4 containing those files. Assumming a finite number of sets the directory hierarchy will end after a point, though the same file will show up more than once if a search (possibly huge numbers of repititions).
To fix existing programs some background tree-balancing algorithim would keep an actual directory matching one of the possible names for each non-empty subset. All other connections would be shown as symbolic links, which would stop most existing hierarchial searching programs from going down them. Notice that this has nothing to do with the implementation, it is just how the API works. I doubt building a label system without fs support would work.
Like the other responders, I would like to see screen shots showing exactly what you are talking about. Use the Vera fonts, which are included with Linux. If you have good examples, maybe it will get people to fix them.
It's true there is a lot of "why don't you code it yourself" responses, when in reality it is extremely difficult to fix code you are unfamiliar with, even if you are a programming genius, while somebody working on the software already may be able to fix it in a minute.
But conversely, doing absolutley *nothing* to help (or even to prove that you have actually observed what you are talking about) is equally bad. Screen shots and comments like "it would be better if this is moved 10 pixels to the left" *are* useful and also prove you are not just flaming but actually have observed and thought about what you are complaining about.
You still need synchronization of some sort so that the calling program can know when it can overwrite or free the buffer. The way to do this is effectively what X (and Windows) does, which is to copy/move the data over to the other process in an effectively synchronous block operation.
The other end can interpret the data as you said and then free/reuse the memory. Such a polled operation may be very good on modern systems as it would get rid of tearing simply without using double buffering.
Though that is a good joke, I believe in reality the "false positive rate" is measured releative to how much non-spam there is, not the total amount of mail. Therefore deleting all mail is a 100% false positive rate.
No, of course not. But they are the best example of terrorists I can think of where the goal is not to kill people. They would consider it successful if they blew up an empty building, while a "homicide bomber" would consider that a failure.
I would think "homicide bomber" is where the primary purpose of the bomb is to kill people, while just "bomber" includes ones that are designed to damage or destroy buildings or other objects and any deaths are not the primary purpose. For instance eco-terrorists are typically "bombers" but not "homicide bombers".
You are right that transparent windows *could* have been done ages ago, just drawing the border is technically just as useful as transparency.
However these window managers did not remove the window that was being dragged, you still saw the opaque window, plus the moving rectangle. So it was not the same as transparency, nothing was revealed while moving windows.
I don't understand what you mean by "having any file be an executable command"
Imagine a shell interface in about 1970 when Unix was first developed. If you had a text file and you wanted to edit it, you typed "vi filename" or "emacs filename". The innovation is that you could instead type just "filename" and it would figure out what to do (ie run your favorite editor on that file).
I'm pretty certain this could have been implemented on the systems that existed in 1970, and it's just that nobody thought of it. I think Microsoft deserves a compliment in actually inventing this.
I don't think the Mac counts. You could delete the creator resource and the file would not work. You could also have two different image files and running them would run two different programs, as the resource would be different. This is much more like the Unix "!#" except in many more files.
I think what he meant is that packaging means it is possible for a program on Linux to use a shared library even if it is not part of the base system.
However, first of all zlib is part of the base system on Linux and not on Windows, this is the much bigger difference in this case, so whatever happens here does not prove anything about packaging.
Second, I really have not seen packaging work for the sort of third-party programs that would be vulnerable. If say zlib was not part of Linux, but Debian noticed that it was used by hundreds of their programs, they would package it and put a dependency in all of *their* programs. But a third party, not paying close attention to Debian, or interested in running on multiple Linux versions, would still be statically-linking in zlib.
I'm in favor of app-dirs type distribution. In this case a program that needs zlib might (I hope) include libzlib.so in the appdir (and arrange things so the appdir is first in LD_LIBRARY_PATH). If there is a vulnerability, the zlib could be replaced, or removed/renamed so that the fixed main zlib is visible. Now I admit this is far from perfect but it does seem to me that this makes installable applications without dependencies, but still fixible, at least *possible*.
I find it hard to believe that Microsoft did force-feedback first.
Mouse right-click for a context menu was well established on X-windows long before Microsoft did it.
I don't think a scroll wheel that tilts sideways is an innovation, it is obvious. What *is* an innovation is making the scrollwheel, all earlier attempts was to make a 2-D extra control for panning. Deciding to reduce the control to 1-D is true innovation and I think Microsoft did it.
DirectX and DRI are totally different. DirectX is an API for end programs while DRI is an implementation of an API. I have to complement Microsoft in DirectX in doing the f**king obvious of implementing backup versions of the functions, rather than the stupidity of every other graphics API (especially on Unix, but including GDI32) where you have to query to find out what is supported and then write your own damn backup versions.
My list of innovations from Microsoft:
The "taskbar" where the indication of a window is unchanged whether or not it is "iconized". All previous interfaces had an "icon" that only appeared when the window itself was removed from the screen.
Realizing that "icons" are far less important than text and making the text much bigger, and enclosed in a box, in the taskbar.
Removing the divider line between the window border and contents on Win95. (I personally did this earlier on my NeXT software, but I doubt they stole from me, and I certainly did not popularize it). Making resize work without visible controls.
The general idea of having any file, not just programs, be an executable command. You can double-click any file and it will launch something. Before this only a small set of files worked (ie in Unix executable files and ones that start with !#, on the Mac files were "marked" by the previous program that ran them and unmarked files did not do anything). The real proof that this is innovative is that, if you think about it, it is unrelated to the GUI. A shell in 1970 *could* have implemented this, where you type the name of any file, and it does something. It would have worked quite well with computers that existed then. This, I think, is the true test whether something is "innovative", is the fact that it did not exist earlier for any reason other than the fact that nobody thought of it.
The mouse scroll wheel, as you mentioned above.
I may be wrong, but the "combo box" is a Microsoft innovation, one of the only ones I can think of for GUI. This is a combination of text editing and a popup list. Do not confuse with the lame implementation with the scroll bar and non-positional popup, but the basic idea of using the same widget to pick from a list and also type in selections not on the list was not seen before Microsoft did it. Certainly not in X or Mac or NeXT.
Non-obtrusive on-the-fly spelling correction (the red squiggle)?
I'm sorry, I'm stumped. I have been here for about 1/2 hour, trying fairly to think of another innovation from Microsoft, and I can't think of one. In any case, I think the above is a fair list. It may sound short, but there are companies where a truly fair criteria would give them a zero-length list.
Of course there are two products with different interpretations of the data:
Apache, which interpretes things wrong.
Another product that interprets things correctly.
Despite there being two products, it should be obvious why Apache is the one at fault and the only one that needs fixing.
Re:Anti-aliasing still looks bad
on
Longhorn Preview
·
· Score: 1
I have to agree. Take a look at the top-left screenshot. WTF? There is obvious good antialiasing on *some* of the fonts (on the left) yet on other fonts, such as in the tooltip, there is *no* antialiasing. I have seen Linux do this, but not *in the same application*, Microsoft must have really innovated to achieve this!
And I am pretty pissed off at the sheep who complain that anything other than a pixel-perfect representation of windows 98 is "blurry". *that's how it is supposed to draw!* At least we can point out that *some* of the fonts are drawn correctly in Windows and some people with a little bit of visual sense will be able to tell that it is better by direct comparison. I am sick to death of posts saying how to "fix" antialiasing in Linux which is really instructions on how to turn it off. At least OS/X made it impossible to turn off, as far as I can tell, stopping this disease on their platform...
RMS has spent most of his life at a college, and many of the people he works with are students or workers at the college. For students, beer is a very common item to get for free (ie at a party), yet it has enough value that they are willing to pay for it when free beer is not available.
The article indicates that at the time a typical Compaq PC-clone came with 256K of memory.
My personal recollection is that 512k quickly became the standard on a base machine, however I was working in PC software at the time and our company may have bought expensive machines (they all had hard disks, too). The 640k barrier prevented anything larger from being standard (simpler circuitry would mean the next step is 1M and you would waste 3/4 of that because of the 640k boundary).
Really, what possible reason is there for a large number of people sharing a NAT to click on the same ad? In any scenario I can think of, that would not indicate any more interest or likely purchases than even one click.
Even if the boss at a company sent out a letter to all 100 employees saying "I want to buy this, check it out and see if you approve", I really doubt the effect on the company is any better than if the boss had just bought the item without any clicking. Certainly it's not 100 times better.
Therefore it seems that not counting the same IP address more than once would be fine for making an accurate guess of the real interest in an ad. Or maybe take the log of the number from the same IP, that might be a good compromise.
I have only seen Ctrl+Tab switch tabs in the same window on Windows. To switch windows you use Alt+Tab, whether the window is in the same application or not.
Please don't call these newer window schemes "MDI". The name "MDI" should be reserved for the obsolete scheme where there are overlapping and movable subwindows. When the windows are all fixed in the same place and selected by tabs it should be considered "tabbed" as in "tabbed browsing". It is true that some Windows applications can do both MDI and tabbed browsing, but in actual use everybody sets them to tabbed, so the MDI is just an obsolete leftover.
The scheme where overlapping toolbars are removed and instead placed in non-overlapping positions inside a big window, possibly with a tabbed area for the document in the middle, I call "tiled" windows, though I'm not sure if there is a real name for this. My personal feeling is that this is not necessary and is caused by a bug in all current window systems, in that clicking in a window raises it. This makes overlapping toolbars useless for more than one document, forcing them to be attached to the window.
As for the scroll wheel, actually X does deliver well-defined events for moving the mouse wheel, at least up and down. The scheme is a kludge (it reuses the interface for button 4 and 5 on the mouse) but it has been there for years, and if a KDE program works at all with the scroll wheel it is using this interface. Therefore whatever your problem with the scroll wheel is, it is not due to a missing "standard up/down message in X".
In a standard modern helicopter, is any of the rotor's airfoil (ie near the center) in negative airflow? Or is it spun so fast that none of it is? Or is that the point where the airfoil ends next to the hub?
It would seem to me that the ideal design for a helicopter is to make the rotor be a long non-lift pole with the airfoils only at the ends, so there is no airfoil in low or negative wind. Obviously that is not how they are built, instead the airfoil goes almost to the hub and has pretty much the same cross section over the entire length. Any explanation for this?
Slashdot Mirror
Okay, finally an explanation as to what is going on. I read all that mailing list and I still had no idea.
However it is not clear why any of this could not be done by GM as it modifies a page. Couldn't GM "read a preferences file" and then act on that to change the modifications to the page, rather than relying on inserting a command into the page to read the preferences? That would seem to avoid the need for this obviously bad idea. Or is there a better example where this does something you really couldn't do otherwise?
That does sound good. In fact the labels can point anywhere and thus the user can label anything that can be named, such as url's or files in other user's directories, etc.
I very much want to see a non-GUI api that the gui is built on top of, in it's own *relatively small* library. The fact that you have to link in all of kde/gnome in order to use their prefix filename scheme is making that a dead-end, if kde/gnome is required for this it is going nowhere. As I see it, some interface to take a set of labels, and another that takes a standard "single string" representation of a set of lables, and returns a list of matches, would work. Also the ability to add or delete any label from any file.
The actual filename can be left up to the program. However I expect the GUI will just present the user with the ability to add as many labels. It will pick one to name the file, adding suffixes as needed to avoid name collisions.
Well, no, I'm thinking the opposite. The whole point of the design is so that existing programs can work and you can communicate a "label" identifier of a file to it. I don't see any reason that the vast majority of programs won't work with a file system that interprets names this way. As the first poster pointed out, there may be problems with programs that search directories recursively.
On the other hand, trying to make my proposal atop an existing filesystem would require the creation of vast numbers of very small directories, this is probably way too expensive. I think the file system has to change.
Putting it in the GUI library is NOT the thing to do. We need open("name") to work. This is also why we need FUSE. It is useless that KDE lets some programs open a filename with http: at the start, we need *all* programs to open it, and there is no need for any other interface, thus I think the only correct thing to do is replace the open() system call. Same is true of any label-based filesystem.
Your ideas match pretty much what I have heard as the way to implement labels.
We certainly don't want a different interface for opening hierarchial files and labelled files. Unfortunatly one fear of having Apple or Microsoft do this is that they won't get it and will put in a different interface, possibly botching it so bad that you cannot use a string to identify a file.
The directory "/set1/set2/set3" would contain all the files that are in all three of those sets. If any of those files are also in another set (set4) there *may* be a subdirectory called set4 containing those files. Assumming a finite number of sets the directory hierarchy will end after a point, though the same file will show up more than once if a search (possibly huge numbers of repititions).
To fix existing programs some background tree-balancing algorithim would keep an actual directory matching one of the possible names for each non-empty subset. All other connections would be shown as symbolic links, which would stop most existing hierarchial searching programs from going down them. Notice that this has nothing to do with the implementation, it is just how the API works. I doubt building a label system without fs support would work.
Like the other responders, I would like to see screen shots showing exactly what you are talking about. Use the Vera fonts, which are included with Linux. If you have good examples, maybe it will get people to fix them.
It's true there is a lot of "why don't you code it yourself" responses, when in reality it is extremely difficult to fix code you are unfamiliar with, even if you are a programming genius, while somebody working on the software already may be able to fix it in a minute.
But conversely, doing absolutley *nothing* to help (or even to prove that you have actually observed what you are talking about) is equally bad. Screen shots and comments like "it would be better if this is moved 10 pixels to the left" *are* useful and also prove you are not just flaming but actually have observed and thought about what you are complaining about.
You still need synchronization of some sort so that the calling program can know when it can overwrite or free the buffer. The way to do this is effectively what X (and Windows) does, which is to copy/move the data over to the other process in an effectively synchronous block operation.
The other end can interpret the data as you said and then free/reuse the memory. Such a polled operation may be very good on modern systems as it would get rid of tearing simply without using double buffering.
Though that is a good joke, I believe in reality the "false positive rate" is measured releative to how much non-spam there is, not the total amount of mail. Therefore deleting all mail is a 100% false positive rate.
Actually they used plenty of fiberglass in the generator, so it is unclear why they did not use it for the blades.
This is false. Microsoft can and will get the source code to any vendor's driver they want. To Microsoft the drivers are not closed source.
My understanding from the other posts is that it is something like this:
if (pentium4) {
fast_code();
} else {
slow_code();
}
When in fact the following will work just as well:
if (supports_sse) {
fast_code();
} else {
slow_code();
}
Where "supports sse" returns true on pentium4, and on the AMD chips, and also on a lot of other chips, including older chips from Intel!
I can see why they wrote it the way they did, however, and it is hard to say whether it is malicious or not.
Actually I think people have sex more often then they are killed :-)
However I certainly agree with your sentiment!
No, of course not. But they are the best example of terrorists I can think of where the goal is not to kill people. They would consider it successful if they blew up an empty building, while a "homicide bomber" would consider that a failure.
I would think "homicide bomber" is where the primary purpose of the bomb is to kill people, while just "bomber" includes ones that are designed to damage or destroy buildings or other objects and any deaths are not the primary purpose. For instance eco-terrorists are typically "bombers" but not "homicide bombers".
You are right that transparent windows *could* have been done ages ago, just drawing the border is technically just as useful as transparency.
However these window managers did not remove the window that was being dragged, you still saw the opaque window, plus the moving rectangle. So it was not the same as transparency, nothing was revealed while moving windows.
I don't understand what you mean by "having any file be an executable command"
Imagine a shell interface in about 1970 when Unix was first developed. If you had a text file and you wanted to edit it, you typed "vi filename" or "emacs filename". The innovation is that you could instead type just "filename" and it would figure out what to do (ie run your favorite editor on that file).
I'm pretty certain this could have been implemented on the systems that existed in 1970, and it's just that nobody thought of it. I think Microsoft deserves a compliment in actually inventing this.
I don't think the Mac counts. You could delete the creator resource and the file would not work. You could also have two different image files and running them would run two different programs, as the resource would be different. This is much more like the Unix "!#" except in many more files.
I think what he meant is that packaging means it is possible for a program on Linux to use a shared library even if it is not part of the base system.
However, first of all zlib is part of the base system on Linux and not on Windows, this is the much bigger difference in this case, so whatever happens here does not prove anything about packaging.
Second, I really have not seen packaging work for the sort of third-party programs that would be vulnerable. If say zlib was not part of Linux, but Debian noticed that it was used by hundreds of their programs, they would package it and put a dependency in all of *their* programs. But a third party, not paying close attention to Debian, or interested in running on multiple Linux versions, would still be statically-linking in zlib.
I'm in favor of app-dirs type distribution. In this case a program that needs zlib might (I hope) include libzlib.so in the appdir (and arrange things so the appdir is first in LD_LIBRARY_PATH). If there is a vulnerability, the zlib could be replaced, or removed/renamed so that the fixed main zlib is visible. Now I admit this is far from perfect but it does seem to me that this makes installable applications without dependencies, but still fixible, at least *possible*.
I find it hard to believe that Microsoft did force-feedback first.
Mouse right-click for a context menu was well established on X-windows long before Microsoft did it.
I don't think a scroll wheel that tilts sideways is an innovation, it is obvious. What *is* an innovation is making the scrollwheel, all earlier attempts was to make a 2-D extra control for panning. Deciding to reduce the control to 1-D is true innovation and I think Microsoft did it.
DirectX and DRI are totally different. DirectX is an API for end programs while DRI is an implementation of an API. I have to complement Microsoft in DirectX in doing the f**king obvious of implementing backup versions of the functions, rather than the stupidity of every other graphics API (especially on Unix, but including GDI32) where you have to query to find out what is supported and then write your own damn backup versions.
My list of innovations from Microsoft:
The "taskbar" where the indication of a window is unchanged whether or not it is "iconized". All previous interfaces had an "icon" that only appeared when the window itself was removed from the screen.
Realizing that "icons" are far less important than text and making the text much bigger, and enclosed in a box, in the taskbar.
Removing the divider line between the window border and contents on Win95. (I personally did this earlier on my NeXT software, but I doubt they stole from me, and I certainly did not popularize it). Making resize work without visible controls.
The general idea of having any file, not just programs, be an executable command. You can double-click any file and it will launch something. Before this only a small set of files worked (ie in Unix executable files and ones that start with !#, on the Mac files were "marked" by the previous program that ran them and unmarked files did not do anything). The real proof that this is innovative is that, if you think about it, it is unrelated to the GUI. A shell in 1970 *could* have implemented this, where you type the name of any file, and it does something. It would have worked quite well with computers that existed then. This, I think, is the true test whether something is "innovative", is the fact that it did not exist earlier for any reason other than the fact that nobody thought of it.
The mouse scroll wheel, as you mentioned above.
I may be wrong, but the "combo box" is a Microsoft innovation, one of the only ones I can think of for GUI. This is a combination of text editing and a popup list. Do not confuse with the lame implementation with the scroll bar and non-positional popup, but the basic idea of using the same widget to pick from a list and also type in selections not on the list was not seen before Microsoft did it. Certainly not in X or Mac or NeXT.
Non-obtrusive on-the-fly spelling correction (the red squiggle)?
I'm sorry, I'm stumped. I have been here for about 1/2 hour, trying fairly to think of another innovation from Microsoft, and I can't think of one. In any case, I think the above is a fair list. It may sound short, but there are companies where a truly fair criteria would give them a zero-length list.
Of course there are two products with different interpretations of the data:
Apache, which interpretes things wrong.
Another product that interprets things correctly.
Despite there being two products, it should be obvious why Apache is the one at fault and the only one that needs fixing.
I have to agree. Take a look at the top-left screenshot. WTF? There is obvious good antialiasing on *some* of the fonts (on the left) yet on other fonts, such as in the tooltip, there is *no* antialiasing. I have seen Linux do this, but not *in the same application*, Microsoft must have really innovated to achieve this!
And I am pretty pissed off at the sheep who complain that anything other than a pixel-perfect representation of windows 98 is "blurry". *that's how it is supposed to draw!* At least we can point out that *some* of the fonts are drawn correctly in Windows and some people with a little bit of visual sense will be able to tell that it is better by direct comparison. I am sick to death of posts saying how to "fix" antialiasing in Linux which is really instructions on how to turn it off. At least OS/X made it impossible to turn off, as far as I can tell, stopping this disease on their platform...
RMS has spent most of his life at a college, and many of the people he works with are students or workers at the college. For students, beer is a very common item to get for free (ie at a party), yet it has enough value that they are willing to pay for it when free beer is not available.
The article indicates that at the time a typical Compaq PC-clone came with 256K of memory.
My personal recollection is that 512k quickly became the standard on a base machine, however I was working in PC software at the time and our company may have bought expensive machines (they all had hard disks, too). The 640k barrier prevented anything larger from being standard (simpler circuitry would mean the next step is 1M and you would waste 3/4 of that because of the 640k boundary).
Really, what possible reason is there for a large number of people sharing a NAT to click on the same ad? In any scenario I can think of, that would not indicate any more interest or likely purchases than even one click.
Even if the boss at a company sent out a letter to all 100 employees saying "I want to buy this, check it out and see if you approve", I really doubt the effect on the company is any better than if the boss had just bought the item without any clicking. Certainly it's not 100 times better.
Therefore it seems that not counting the same IP address more than once would be fine for making an accurate guess of the real interest in an ad. Or maybe take the log of the number from the same IP, that might be a good compromise.
I have only seen Ctrl+Tab switch tabs in the same window on Windows. To switch windows you use Alt+Tab, whether the window is in the same application or not.
Please don't call these newer window schemes "MDI". The name "MDI" should be reserved for the obsolete scheme where there are overlapping and movable subwindows. When the windows are all fixed in the same place and selected by tabs it should be considered "tabbed" as in "tabbed browsing". It is true that some Windows applications can do both MDI and tabbed browsing, but in actual use everybody sets them to tabbed, so the MDI is just an obsolete leftover.
The scheme where overlapping toolbars are removed and instead placed in non-overlapping positions inside a big window, possibly with a tabbed area for the document in the middle, I call "tiled" windows, though I'm not sure if there is a real name for this. My personal feeling is that this is not necessary and is caused by a bug in all current window systems, in that clicking in a window raises it. This makes overlapping toolbars useless for more than one document, forcing them to be attached to the window.
As for the scroll wheel, actually X does deliver well-defined events for moving the mouse wheel, at least up and down. The scheme is a kludge (it reuses the interface for button 4 and 5 on the mouse) but it has been there for years, and if a KDE program works at all with the scroll wheel it is using this interface. Therefore whatever your problem with the scroll wheel is, it is not due to a missing "standard up/down message in X".
In a standard modern helicopter, is any of the rotor's airfoil (ie near the center) in negative airflow? Or is it spun so fast that none of it is? Or is that the point where the airfoil ends next to the hub?
It would seem to me that the ideal design for a helicopter is to make the rotor be a long non-lift pole with the airfoils only at the ends, so there is no airfoil in low or negative wind. Obviously that is not how they are built, instead the airfoil goes almost to the hub and has pretty much the same cross section over the entire length. Any explanation for this?
Linux usage could be easily gauged by some sort of on-line registration of the purchased copy.