Okay, lets see your BASIC version. Did you do all the ISO-8859-1 characters? How about the MicroSoft characters between 0x80 and 0xA0? How about alternative 8-bit character sets? How about the German double-s? OOPS!
What happens when we have a secure service that wants to check if a file will be overwritten and it's test does not exactly match what the file system uses to check for filename equality. What happens when it's test is done on two file systems, or on a local cache that accidentally has a different algorithim htna the remote disk? Guess what? Can you say SECURITY HOLE?
This has absolutely NOTHING to do with making user-friendly searches. There is nothing that prevents an application from searching for all possible case variations or using far more complex things like spelling correction to find files. Get it?
The average user does not care and would NEVER notice case-sensitivity. In fact the average user does not see anything wrong with having several files with the same name (possibly something that should be supported somehow). You are talking about convienence for a COMMAND.COM user, even Unix shells have filename completion nowadays making filename complexity irrelevant.
I do want a merge. We don't have to call it OpenGL.
But I definately want a single "graphics context". It is insane that I have to use totally different code to draw a rectangle in my X window verses my OpenGL window. And for text, OpenGL has a way to specify a position and a color. I think it is entirely illogical that I cannot use these values to control how my text is drawn. Therefore any new way to add text should be added to OpenGL, or we should add *all* of OpenGL to the new "graphics context" that can draw this text.
I would also like to see a high-speed way to draw an image projected through the current transformation. Using OpenGL textures works, but I think there is too much overhead because it assummes the texture will be reused. In the case of a movie or other cg image that will change this is a waste.
For the windowing system I consider this a graphics operation is based on how NeWS worked: when I create a window I need a shape (path), a position (transformation), and a parent window. All of these are attributes of a "graphics context" and thus I again see to reason to not make "create a window" an operation in the graphics context.
Because equality of two filenames can be determined unambiguousely by comparing the bit patterns of the names.
With Unicode the mapping of upper to lowercase can be extremely complex, and potentially two file systems or programs would use different algorithims, resulting in very difficult to understand errors and potential security problems.
And there is nothing "user friendly" about case insensitivity. The average user picks a file by clicking on them!
Absolutely no way. Apple would have to make very serious design restrictions on there GUI if it was to be displayed in any legible way on an X window. It would be a complete waste of their time.
It would be nice if they allowed X applications to work (not window managers, though!). This could be done by either making a dummy X server or by replacing Xlib. I expect several third-party solutions for this will show up quite quickly.
Actually, middle-mouse-paste is much more equivalent to Drag&Drop than cut&paste. Think about it. Clicking the middle mouse button is equivalent to dragging from the last selection to this location. It has some huge advantages, too, in that you can use the mouse to move around windows before doing the drop.
In fact all this problem about being "unable to select what to replace" is also true of Drag&Drop, except because you have to hold the stupid mouse button down people don't think about the fact that they can't select what to replace. (I have tried using middle-mouse-drag to select the replacement but it does not seem to be user friendly).
If you treat it this way, it should be clear that middle-mouse-paste should work for any data type, as long as drag&drop works.
It would be nice if Apple, having much more control over the gui, might consider adding some ability like this.
I do believe that Unix will encourage interfaces that allow the direct typing in of filenames anywhere on the system into a single text field, using a non-shifted key ('/') on the keyboard, and a non-ambiguous display of a filename anywhere as a single line of text. This will have a significant positive effect on the "average" user as it allows names to be reliably copied between user interfaces and between text documents and interfaces.
Otherwise I see little visible effect of the underlying Unix on the user experience.
Lots of tech problems with this, mostly that the actual child windows and window borders are not controlled by OpenGL. You can draw the desktop and window borders using OpenGL, but the boundaries are going to remain opaque and square (unless you use the shape extension, but then they still lack partial transparency).
I do think a concerted effort should be made to merge the remaining graphics functionality into OpenGL (add TT anti-aliased unicode fonts, arbitrary clipping regions, and the ability to create and transform windows to the glxContext). Then programs could work exclusively in OpenGL and never think about drawing with X. However I mentioned this to Brain Paul once and he seemed to think it was a terrible idea.
I just don't see this. If software manufacturers make their software a pain to use, people will go to competitors. It is rather silly to state that the existence of a compiler is the cause of hard-to-use software!
The only con is extra disk space. I would leave off all the documentation (which is about half of it). The rest is probably tiny compared to all the free movies and sounds and images and ads and other stuff that is going to be on there!
And the stupid RIAA should realize that people will PAY for a site that they can get music that they know is not damaged or ads.
And trying to copy-protect these files is a mistake. People will go other places to get the same music stripped of the copy protection, because the copy protection is as big of an annoyance or "damage" as an ad and thus negates the whole advantage of the pay site.
1. "Windows uses shared libraries" But I don't think installation on Windows is too great either. They invented the term "dll hell".
2. "But glibc is huge!" I don't think he was talking about glibc or xlib or anything else you always get on a stock system. He's talking about libart and gnome libs and Qt: the files that are causing the problem! I don't see any reason why these cannot be static linked.
If we are worried about memory, add a hash encoding scheme for readonly pages so identical pages are in the same memory. This will result in probably more savings than shared libraries. If we are worried about disk space create a file system with the same type of hashing.
Also, what is wrong with source code? How about designing a "packaging" system that COMPILES the program. I believe users are willing to wait for the compilation, if only it was automatic.
The files for a package can all remain in a directory despite the problems with the Unix file system if you use symbolic links from the proper place to the package directory.
Actually it would be incredibly convienent for some application programs to be able to assume the compiler is installed. How about an applicattion that can convert "macros" into "plugins" (something I am working on right now).
I kind of feel they botched it by not including this stuff.
The average user does not ever need to see it. It can be there anyway.
Not exactly the same. The Allies would have had a lot easier of a time cracking the code if the Germans sold a box at Harrods that decoded the messages for them!
Having both the input and output of the encryption algorithim makes it a LOT easier to figure out the algorithim, for I hope obvious reasons.
It is possible to run a closed-source program on Linux!
This is certainly what any commercial offering expected will be: closed.
Even the RIAA might not mind open-sourced drivers for the types of sealed hardware they are interested in selling in the future, I hope this has taught them that even closed-source software drivers provide almost no protection whatsoever.
If the software is just like a remote control, and the image is decoded by hardware and goes straight from the player to the display card (not through system memory) then open-source gives them many advantages: a kool-looking ui with no work on their part, new navigation ideas, and quite possibly people will tell them about holes in their hardware security and suggest ways to fix them.
Simple. It is not totally ignorant of javascript. It knows how to "parse" it. And then it has a bunch of rules like "the tokens "foo" and "(" next to each other mean they are calling foo() and that probably means I should do this...
Actually just seeing all the string contants and assumming they are URL's should work and hardly requires even a "parser".
We are fighting to prevent the day when they will be unable to fast-forward through the ads on a DVD..
I think that is a powerful argument for a layman, and actually matches our own arguments. It is actually quite serious, there is "don't fast-forward" codes already on the DVD (I think we don't know how to decode them, or any navigation info, but DeCSS bypasses this by pulling the interesting movie data off the disk).
Most video cards use an 8-bit D/A converter, since they can be switched to some 8-bit (24 bit in PC-speak) mode. (some older cards use a 5 or 6-bit converter so that 8-bit mode is actually a waste of memory!) They almost certainly pad the 5 or 6-bit data with 1 or 0 to get the 8-bit input, or they might copy the top 3 bits to the bottom.
Perhaps more important is that this difference is miniscule compared to normal differences between CRTs and brightness settings and D/A errors.
CRT's on a PC are not linear. The ratio of brightness between 0x00 and 0x33 is actually LESS than the ratio between 0xCC and 0xFF.
The plot of brightness is actually a curve with a function "(x/255)^G+K" where G is about 2.3 for your normal crt (K is the brightness of the dark screen).
It just so happens that this curve very closely matches the human eye's color sensitivity. Thus each different numerical value results in approximately equal differences in perceived color.
LCD screens do not naturally have this response, but the manufacturers have been forced to copy it to make displays designed for CRTs look correct.
A big problem with CG is "partially clued" people that are aware of the screens non-linear response, but think that linear response will result in better pictures. They adjust the software or the D/A converters for this and actually produces worse output, where there are noticable steps in the black and many indecipherable values crammed up in the white end.
PC manufacturers, being cheap, have not done this, and actually resulted in better color. Macs and SGI workstations suffer from default settings that try to "solve" this problem.
564 is also true of XFree86 when run in 16-bit mode.
It certainly seems to me to be the best possible use of 16 bits. The only problem is that if you code the "easy" way and draw a gray image, it may come out somewhat green, if you really want gray you have to leave the bottom bit of green as a checkerboard to get real gray everywhere.
For some reason "flat tax" seems to mean two things that imho are totally unrelated.
First it means "simplified tax" where your "income" (or whatever is taxed) is a "simple" calculation, for instance it is how much money you were paid this year and there are no deductions.
Second it means "flat" in that the formula for figuring out how to convert this "income" to "tax" is to multiply it by a constant.
What I can't figure out is why everybody seems convinced that it is impossible to seperate these two ideas. Why can't the calculation of "income" be simplified, but you still use a tax table (and thus progressive) tax? (conversely, why can't you flat-rate a very complex income calculation like we have currently, a scheme big business would love...)
Without simplification, flat taxes are not going to do anything. Coorporations are actually taxed at a very high percentage, the reason they don't pay much is that they are able to deduct almost everything before this percentage is calculated.
Slashdot Mirror
Okay, lets see your BASIC version. Did you do all the ISO-8859-1 characters? How about the MicroSoft characters between 0x80 and 0xA0? How about alternative 8-bit character sets? How about the German double-s? OOPS!
What happens when we have a secure service that wants to check if a file will be overwritten and it's test does not exactly match what the file system uses to check for filename equality. What happens when it's test is done on two file systems, or on a local cache that accidentally has a different algorithim htna the remote disk? Guess what? Can you say SECURITY HOLE?
This has absolutely NOTHING to do with making user-friendly searches. There is nothing that prevents an application from searching for all possible case variations or using far more complex things like spelling correction to find files. Get it?
The average user does not care and would NEVER notice case-sensitivity. In fact the average user does not see anything wrong with having several files with the same name (possibly something that should be supported somehow). You are talking about convienence for a COMMAND.COM user, even Unix shells have filename completion nowadays making filename complexity irrelevant.
Biology is reverse engineering, and is illegal nowadays. Better look for a new job.
But I definately want a single "graphics context". It is insane that I have to use totally different code to draw a rectangle in my X window verses my OpenGL window. And for text, OpenGL has a way to specify a position and a color. I think it is entirely illogical that I cannot use these values to control how my text is drawn. Therefore any new way to add text should be added to OpenGL, or we should add *all* of OpenGL to the new "graphics context" that can draw this text.
I would also like to see a high-speed way to draw an image projected through the current transformation. Using OpenGL textures works, but I think there is too much overhead because it assummes the texture will be reused. In the case of a movie or other cg image that will change this is a waste.
For the windowing system I consider this a graphics operation is based on how NeWS worked: when I create a window I need a shape (path), a position (transformation), and a parent window. All of these are attributes of a "graphics context" and thus I again see to reason to not make "create a window" an operation in the graphics context.
With Unicode the mapping of upper to lowercase can be extremely complex, and potentially two file systems or programs would use different algorithims, resulting in very difficult to understand errors and potential security problems.
And there is nothing "user friendly" about case insensitivity. The average user picks a file by clicking on them!
It would be nice if they allowed X applications to work (not window managers, though!). This could be done by either making a dummy X server or by replacing Xlib. I expect several third-party solutions for this will show up quite quickly.
In fact all this problem about being "unable to select what to replace" is also true of Drag&Drop, except because you have to hold the stupid mouse button down people don't think about the fact that they can't select what to replace. (I have tried using middle-mouse-drag to select the replacement but it does not seem to be user friendly).
If you treat it this way, it should be clear that middle-mouse-paste should work for any data type, as long as drag&drop works.
It would be nice if Apple, having much more control over the gui, might consider adding some ability like this.
Otherwise I see little visible effect of the underlying Unix on the user experience.
I do think a concerted effort should be made to merge the remaining graphics functionality into OpenGL (add TT anti-aliased unicode fonts, arbitrary clipping regions, and the ability to create and transform windows to the glxContext). Then programs could work exclusively in OpenGL and never think about drawing with X. However I mentioned this to Brain Paul once and he seemed to think it was a terrible idea.
The only con is extra disk space. I would leave off all the documentation (which is about half of it). The rest is probably tiny compared to all the free movies and sounds and images and ads and other stuff that is going to be on there!
And the stupid RIAA should realize that people will PAY for a site that they can get music that they know is not damaged or ads.
And trying to copy-protect these files is a mistake. People will go other places to get the same music stripped of the copy protection, because the copy protection is as big of an annoyance or "damage" as an ad and thus negates the whole advantage of the pay site.
1. "Windows uses shared libraries" But I don't think installation on Windows is too great either. They invented the term "dll hell".
2. "But glibc is huge!" I don't think he was talking about glibc or xlib or anything else you always get on a stock system. He's talking about libart and gnome libs and Qt: the files that are causing the problem! I don't see any reason why these cannot be static linked.
If we are worried about memory, add a hash encoding scheme for readonly pages so identical pages are in the same memory. This will result in probably more savings than shared libraries. If we are worried about disk space create a file system with the same type of hashing.
Also, what is wrong with source code? How about designing a "packaging" system that COMPILES the program. I believe users are willing to wait for the compilation, if only it was automatic.
The files for a package can all remain in a directory despite the problems with the Unix file system if you use symbolic links from the proper place to the package directory.
I kind of feel they botched it by not including this stuff.
The average user does not ever need to see it. It can be there anyway.
Any free service like Napster is going to be flooded with junk and people trying to be clever by mislabeling files.
An organized source, controlled by somebody who cares about the contents, is worth money.
Having both the input and output of the encryption algorithim makes it a LOT easier to figure out the algorithim, for I hope obvious reasons.
A very very big difference from the RIAA's opinion!
It is possible to run a closed-source program on Linux!
This is certainly what any commercial offering expected will be: closed.
Even the RIAA might not mind open-sourced drivers for the types of sealed hardware they are interested in selling in the future, I hope this has taught them that even closed-source software drivers provide almost no protection whatsoever.
If the software is just like a remote control, and the image is decoded by hardware and goes straight from the player to the display card (not through system memory) then open-source gives them many advantages: a kool-looking ui with no work on their part, new navigation ideas, and quite possibly people will tell them about holes in their hardware security and suggest ways to fix them.
Simple. It is not totally ignorant of javascript. It knows how to "parse" it. And then it has a bunch of rules like "the tokens "foo" and "(" next to each other mean they are calling foo() and that probably means I should do this...
Actually just seeing all the string contants and assumming they are URL's should work and hardly requires even a "parser".
Since DeCSS does not need kernel modifications, I think you are wrong.
We are fighting to prevent the day when they will be unable to fast-forward through the ads on a DVD..
I think that is a powerful argument for a layman, and actually matches our own arguments. It is actually quite serious, there is "don't fast-forward" codes already on the DVD (I think we don't know how to decode them, or any navigation info, but DeCSS bypasses this by pulling the interesting movie data off the disk).
It should be possible to get rid of all the non-functional buttons by finding url's imbedded in the javascript.
"rollover" buttons should be detectable by the multiple images in the javascript.
And otherwise, try to pick out quoted strings and display them as text.
That will definately make a difference.
Most video cards use an 8-bit D/A converter, since they can be switched to some 8-bit (24 bit in PC-speak) mode. (some older cards use a 5 or 6-bit converter so that 8-bit mode is actually a waste of memory!) They almost certainly pad the 5 or 6-bit data with 1 or 0 to get the 8-bit input, or they might copy the top 3 bits to the bottom.
Perhaps more important is that this difference is miniscule compared to normal differences between CRTs and brightness settings and D/A errors.
The plot of brightness is actually a curve with a function "(x/255)^G+K" where G is about 2.3 for your normal crt (K is the brightness of the dark screen).
It just so happens that this curve very closely matches the human eye's color sensitivity. Thus each different numerical value results in approximately equal differences in perceived color.
LCD screens do not naturally have this response, but the manufacturers have been forced to copy it to make displays designed for CRTs look correct.
A big problem with CG is "partially clued" people that are aware of the screens non-linear response, but think that linear response will result in better pictures. They adjust the software or the D/A converters for this and actually produces worse output, where there are noticable steps in the black and many indecipherable values crammed up in the white end.
PC manufacturers, being cheap, have not done this, and actually resulted in better color. Macs and SGI workstations suffer from default settings that try to "solve" this problem.
It certainly seems to me to be the best possible use of 16 bits. The only problem is that if you code the "easy" way and draw a gray image, it may come out somewhat green, if you really want gray you have to leave the bottom bit of green as a checkerboard to get real gray everywhere.
First it means "simplified tax" where your "income" (or whatever is taxed) is a "simple" calculation, for instance it is how much money you were paid this year and there are no deductions.
Second it means "flat" in that the formula for figuring out how to convert this "income" to "tax" is to multiply it by a constant.
What I can't figure out is why everybody seems convinced that it is impossible to seperate these two ideas. Why can't the calculation of "income" be simplified, but you still use a tax table (and thus progressive) tax? (conversely, why can't you flat-rate a very complex income calculation like we have currently, a scheme big business would love...)
Without simplification, flat taxes are not going to do anything. Coorporations are actually taxed at a very high percentage, the reason they don't pay much is that they are able to deduct almost everything before this percentage is calculated.