This reply is not really accurate. Neither the $3000 card or the $200 card do the algorithim.
The hardware manufacturers need to have a reason to do this algorithim (or do the compute-expensive portion of it) and (if it is also technically possible) you will see it.
Almost everything the cards does is algoirthims invented 30 years ago. The clever engineering is getting them to run fast and to correctly select a subset of the possible algorithims to implement. There are also hundreds of graphics algorithims invented 30 years ago that are *not* on any hardware card.
Probably right that we don't want stuff stored at the root level other than system structure.
So I guess my complaint is that "My Documents" is shown by MSoft at the "root", rather than it's actual location. This defeats the whole advantage of forcing the physical disk structure to be part of the hierarchy: if a disk fails or changes it is clear what portion of the tree is affected.
I think a solution for MSoft would be to have the Explorer and file chooser start up with "My Documents" preselected, but in it's actual place in the hierarchy. It would look exactly as though you navigated down to it in the current one.
Of course as they have named the directories down there now, it makes the Unix directory naming look like a work of genius... Maybe they could fix it so it is not nested in so many levels. Perhaps C:/People/username (or/home/username ???)
That's exactly what I was saying, perhaps I was not too clear.
In early Windows, the left-hand button was a horizontal bar in a box, and a single click dropped down a menu, and a double click closed the window (close was also on this menu). In the upper right were maximize and iconize buttons.
In Windows 95, I consider the X button as "new", while the old top-left button was still there and working exactly as before, but they changed it's appearance so it no longer has a border and it displays a "tiny icon".
It is possible that double-click no longer closes the window, I never use that and don't have a Windows machine here to test.
Actually MicroSoft ought to scrap that button and move the X to the left. I never use the menu. I have also seen normal users accustomed to Windows on a Linux box with KDE set to put the X in the left and they never seem confused, it appears the X is much more important as a visual clue than the button location.
When trying to help someone over the phone, it is immesurably easier to instruct them to type mysterious syntax than it is to instruct them to push mysterious buttons. You can spell out the syntax letter by letter. They can also read back the response. Most GUI's, by the time they get to stuff that normally requires a shell, require a great deal of work to determine if the user is even looking at the correct program or dialog box.
Otherwise there is no reason for the beginning user to see a shell, I agree.
I still feel that "shell" is a much better word for people to see, and it means as much to a typical user as "terminal emulator" or other such verbage.
The fact that point-to-type is not the default is one of the major problems with the Gnome and KDE slavish copying of MicroSoft.
I have never seen a person who learns point-to-type (you can get this on Windows and NT by messing with the resource manager) switch back, and they quickly become frustrated when encouterint click-to-type. Where I work more than half the NT machines have been switched to point-to-type.
The fact is that point to type is, without question, superior. It is as close as possible to the ideal way to direct keyboard input to several objects using current hardware (the ideal would be to somehow read your mind or track your eye movements to see what thing you are thinking about).
The fact that this is not the default on all Unix systems (or on new versions of Windows, for that matter) is a good indication of how harmful the engraned user expectations are to advancing the design of machines.
re: The average end
user wants to be able to download program XYZ, double click on it, and have it install
Bullshit. This is exactly the type of "windows blinders" that people here are complaining about.
The average user does not want to "install" a program when they double click on it. They want to use the program! In fact the average user would be overjoyed if they could throw the program in the trash can if they don't like it and it is gone.
It is unbelievable that people complaining about the mysteries of Linux can blindly spout crap like "install" and think they are describing real non-computer-expert's thoughts.
Of course I should point out that Linux is as bad or worse than Windows with this "install" shit.
Or even better, they should use the old Unix "file" command to identify the file types. The advantage is that the data itself describes the association, so the association cannot get lost by the user transferring the file from one system to another, possibly through an intermediate form that only copies the data.
Of course both Windows and Unix make it very slow to get at the data, while fast to get at the less-important "filename". This is all backwards.
Please don't mess up the file system even more with "attributes", thank you.
I agree the disks should be at the top. There is no reason for the stupid MSDOS syntax, just/cdrom and/floppy, etc should work. I think many Linux machines are set up this way.
However "My Documents" is a good indication that MicroSoft is not studying things much either. In fact "My Documents" is ON one of the disks. Removal of the C: drive will cause "My Documents" to become empty, which would be somewhat confusing to the user who can clearly see from that display that they are NOT on the C: drive!
It should initialize with the *actual* "My Documents" directory already opened and highlighted.
Unlike either Windows or Linux it would make sense for this directory to be immediately under the physical disk seperations.
Another idea would be to hide structure that cannot be changed without turning the machine off anyway. So the top level should be something like this:
/cdrom
/floppy
/My Documents
/Joe's Documents
/Sally's Documents
/The web
You will favor that until the moment that you need to type a filename that is the prefix of an existing filename. Then you will probably not be so happy...
Having tried both I greatly prefer hitting a keystroke to add characters.
Not quite, in earlier versions of Windows the left-hand button brought up a menu of options, and double-clicking it closed the window. In fact it still does, but they changed it from looking like the button to being a tiny (and quite illegible) icon for the application.
I suspect the test users found the double-click unintuitive. They should have scrapped the pulldown menu and made the button a close button, but somebody there wanted to keep it, and so they stuck a new button on the right.
Unfortunately it is this same unwillingness to get rid of functions that is causing Gnome to bloat up just like Windows.
Although I agree that a JavaOS would run Java stuff much more efficiently, you do seem to blame some of the wrong things for the Java bloat. In particular you claim that not using native services and reimplementing them in Java loses.
I don't think this is true. In my experience it takes far more code to interface to an existing high-level interface than to reimplement it. My best example is X window managers, I have written both them and toolkits that talk to them. I would say 50% of the window manager is interfacing code to the applications, and the code the toolkit uses to talk to the window manager is 1.6 times larger than the code in the window manager to draw and drag windows. Thus if the window manager were eliminated we would all programs would have a piece replaced with a piece that is 1/1.6 in size, and ALL of the window manager is removed. This would result in significant savings overall.
Another way to look at it is to imagine the widgets in your JavaOS. Do you really think that at the widget point (like the interface to a text input field) Java would abrubtly stop being used, and the rest coded in assembler or C? Or, more likely, wouldn't the widget itself be in Java and talking to a lower-level interface that draw letters and rectangles. And then wouldn't that lower interface be well-documented and the "widget" just run in user space?
Of course it would work like this, because it would be about a million times easier to design such a system. The same thing is true when writing a toolkit to run on a system you don't control.
The problem with Java is not that it is a bad idea to program to a low level, but that the implementation itself is badly done and bloated. Swing could learn a lot from gtk or even (god forbid) mfc.
Even if they are using GPL code in their in-house products, they don't have to release this source if they are not selling or otherwise distributing the program outside the company.
It is also quite likely that they are not using any GPL code, so they can even sell their programs. They are using LGPL libraries plenty, I'm sure, so if they modify those for their own use they need to release those modifications.
Just because it runs on Linux does not mean it has to use the GPL, no matter how much Bill Gates wishes otherwise...
Moving images with motion blur look vastly better than ones without. Usually the detail is much clearer, in your example the image with motion blur would allow you to follow one of those background characters with your eye and actually you would think you saw it rather clearly. Without motion blur your eye would usually register the several seperated images of the character and not match up the details, and certainly not see it "move".
Grain is also a huge help, though it is not clear why. Originally it was done to make the images match the live action, but it is added to all-cg like FF and Toy Story. Apparently your eye filters out the grain and the fact that this filter is "turned on" causes your brain to also filter out lots of other CGI artifacts and make everything look more solid.
Live action has also had to live with the depth of focus problem for a long time. In fact in live action you cannot make all the distances be in focus at once. I think the trick is to get you to look at the object that is in focus, if your eye wanders to the out-of-focus background then the director is not doing their job.
Don't blame "hardware" for the budget. To the average geek who buys a computer it may seem that hardware is the only expense. But for this it is people's salaries that far outweigh other things. Office space rental may also outweigh the hardware cost. The distributor probably paid 10 times more for advertising than the "hardware" cost, as well.
This means that they did not use Linux just to save money. It also explains why they are willing to spend money on SGI equipment that was already dated when they got it, and quite expensive compared to home machines.
I'm not sure if you are joking, but of course the frame rate is frozen at 24 fps because that is the rate the film projectors in the movie theatres go at. So they had no choice.
It should be obvious that the cg can, in theory, look just as good as real images at 24fps.
The incredible frame rates being done by game hardware is attempting to make up for the lack of motion blur. The fact that we are able to tolerate 24fps indicates that 80fps (or whatever is standard now) is totally unnecessary, if other work was done to improve the images.
I attribute the slowness to some inexperienced character animators. Possibly also they previewed stuff at 30fps on video (but that sounds like a really stupid mistake for such an expensive production). They certainly had motion blur.
Although cable is similar, "expensive water" at least allows competition. A new company is able to produce bottled water without having to reverse engineer and risk lawsuits or buy licenses from the already existing water producer.
The problem with using utf-16 is that you have to somewhere provide 8-bit support for back compatability. This means that at some level every single call to process text is duplicated with an 8-bit and a 16-bit version.
Although in theory you should be able to cram all this into a "8-bit compatability library", the real world is not as nice as theory. In fact you need to duplicate the interface almost everywhere. And when you do this the 8-bit interface is used so much the 16-bit one is often not debugged and does not work (Xlib has a lot of this).
UTF-8 is an enormous win because it does not require dupliating the interface. I think we can safely switch all the interfaces to utf-8 with a simple rule that "erroneous sequences" are treated as the individual bytes in iso-8859-1 (this allows 99.9% of ios-8859-1 text through, but more importantly it deletes the need to handle "errors" in the interface). Even if people don't buy this the interfaces can be controlled by a simple "utf-8" mode switch, and even if this fails to be communicated correctly to the other end the software on the other end can be fixed to have a "override that switch" control.
In reality, "wide characters" and so on have been a horrible error and are probably the main reason internationalization has not happened. The only things wide characters give you is "go to character N fast". But in fact there is no reason for such an operation to be fast, it has nothing to do with parsing text (which is word-based), there are just morons out there in compsci who think it is necessary because it was fast for 8-bit bytes.
I would love to see "wide characters" (at least for any interfaces) put in the dustbin as soon as possible. The fact that some people still think they have any advantage at all shows that there is still a long way to go, sigh...
Slashdot Mirror
The hardware manufacturers need to have a reason to do this algorithim (or do the compute-expensive portion of it) and (if it is also technically possible) you will see it.
Almost everything the cards does is algoirthims invented 30 years ago. The clever engineering is getting them to run fast and to correctly select a subset of the possible algorithims to implement. There are also hundreds of graphics algorithims invented 30 years ago that are *not* on any hardware card.
The fact is your business may have done better if there was competition at higher levels.
A pattern is also evidence that the compression could be better.
So I guess my complaint is that "My Documents" is shown by MSoft at the "root", rather than it's actual location. This defeats the whole advantage of forcing the physical disk structure to be part of the hierarchy: if a disk fails or changes it is clear what portion of the tree is affected.
I think a solution for MSoft would be to have the Explorer and file chooser start up with "My Documents" preselected, but in it's actual place in the hierarchy. It would look exactly as though you navigated down to it in the current one.
Of course as they have named the directories down there now, it makes the Unix directory naming look like a work of genius... Maybe they could fix it so it is not nested in so many levels. Perhaps C:/People/username (or /home/username ???)
Anybody actually use the imbedded elisp code in Emacs for anything useful?
In early Windows, the left-hand button was a horizontal bar in a box, and a single click dropped down a menu, and a double click closed the window (close was also on this menu). In the upper right were maximize and iconize buttons.
In Windows 95, I consider the X button as "new", while the old top-left button was still there and working exactly as before, but they changed it's appearance so it no longer has a border and it displays a "tiny icon".
It is possible that double-click no longer closes the window, I never use that and don't have a Windows machine here to test.
Actually MicroSoft ought to scrap that button and move the X to the left. I never use the menu. I have also seen normal users accustomed to Windows on a Linux box with KDE set to put the X in the left and they never seem confused, it appears the X is much more important as a visual clue than the button location.
Otherwise there is no reason for the beginning user to see a shell, I agree.
I still feel that "shell" is a much better word for people to see, and it means as much to a typical user as "terminal emulator" or other such verbage.
I have never seen a person who learns point-to-type (you can get this on Windows and NT by messing with the resource manager) switch back, and they quickly become frustrated when encouterint click-to-type. Where I work more than half the NT machines have been switched to point-to-type.
The fact is that point to type is, without question, superior. It is as close as possible to the ideal way to direct keyboard input to several objects using current hardware (the ideal would be to somehow read your mind or track your eye movements to see what thing you are thinking about).
The fact that this is not the default on all Unix systems (or on new versions of Windows, for that matter) is a good indication of how harmful the engraned user expectations are to advancing the design of machines.
GTK is LGPL you idiot. You can make closed source apps and charge all the money you want for them.
Bullshit. This is exactly the type of "windows blinders" that people here are complaining about.
The average user does not want to "install" a program when they double click on it. They want to use the program! In fact the average user would be overjoyed if they could throw the program in the trash can if they don't like it and it is gone.
It is unbelievable that people complaining about the mysteries of Linux can blindly spout crap like "install" and think they are describing real non-computer-expert's thoughts.
Of course I should point out that Linux is as bad or worse than Windows with this "install" shit.
Of course both Windows and Unix make it very slow to get at the data, while fast to get at the less-important "filename". This is all backwards.
Please don't mess up the file system even more with "attributes", thank you.
However "My Documents" is a good indication that MicroSoft is not studying things much either. In fact "My Documents" is ON one of the disks. Removal of the C: drive will cause "My Documents" to become empty, which would be somewhat confusing to the user who can clearly see from that display that they are NOT on the C: drive!
It should initialize with the *actual* "My Documents" directory already opened and highlighted.
Unlike either Windows or Linux it would make sense for this directory to be immediately under the physical disk seperations.
Another idea would be to hide structure that cannot be changed without turning the machine off anyway. So the top level should be something like this:
/cdrom
/floppy
/My Documents
/Joe's Documents
/Sally's Documents
/The web
Having tried both I greatly prefer hitting a keystroke to add characters.
It should be easier to tell people to click "shell" or "run shell" than to say "run the terminal emulator program".
I suspect the test users found the double-click unintuitive. They should have scrapped the pulldown menu and made the button a close button, but somebody there wanted to keep it, and so they stuck a new button on the right.
Unfortunately it is this same unwillingness to get rid of functions that is causing Gnome to bloat up just like Windows.
I don't think this is true. In my experience it takes far more code to interface to an existing high-level interface than to reimplement it. My best example is X window managers, I have written both them and toolkits that talk to them. I would say 50% of the window manager is interfacing code to the applications, and the code the toolkit uses to talk to the window manager is 1.6 times larger than the code in the window manager to draw and drag windows. Thus if the window manager were eliminated we would all programs would have a piece replaced with a piece that is 1/1.6 in size, and ALL of the window manager is removed. This would result in significant savings overall.
Another way to look at it is to imagine the widgets in your JavaOS. Do you really think that at the widget point (like the interface to a text input field) Java would abrubtly stop being used, and the rest coded in assembler or C? Or, more likely, wouldn't the widget itself be in Java and talking to a lower-level interface that draw letters and rectangles. And then wouldn't that lower interface be well-documented and the "widget" just run in user space?
Of course it would work like this, because it would be about a million times easier to design such a system. The same thing is true when writing a toolkit to run on a system you don't control.
The problem with Java is not that it is a bad idea to program to a low level, but that the implementation itself is badly done and bloated. Swing could learn a lot from gtk or even (god forbid) mfc.
It is also quite likely that they are not using any GPL code, so they can even sell their programs. They are using LGPL libraries plenty, I'm sure, so if they modify those for their own use they need to release those modifications.
Just because it runs on Linux does not mean it has to use the GPL, no matter how much Bill Gates wishes otherwise...
Grain is also a huge help, though it is not clear why. Originally it was done to make the images match the live action, but it is added to all-cg like FF and Toy Story. Apparently your eye filters out the grain and the fact that this filter is "turned on" causes your brain to also filter out lots of other CGI artifacts and make everything look more solid.
Live action has also had to live with the depth of focus problem for a long time. In fact in live action you cannot make all the distances be in focus at once. I think the trick is to get you to look at the object that is in focus, if your eye wanders to the out-of-focus background then the director is not doing their job.
This means that they did not use Linux just to save money. It also explains why they are willing to spend money on SGI equipment that was already dated when they got it, and quite expensive compared to home machines.
It should be obvious that the cg can, in theory, look just as good as real images at 24fps.
The incredible frame rates being done by game hardware is attempting to make up for the lack of motion blur. The fact that we are able to tolerate 24fps indicates that 80fps (or whatever is standard now) is totally unnecessary, if other work was done to improve the images.
I attribute the slowness to some inexperienced character animators. Possibly also they previewed stuff at 30fps on video (but that sounds like a really stupid mistake for such an expensive production). They certainly had motion blur.
In my experience most people do call it "K-illustrator"
Direct links from the page sound like a good idea. This would avoid the feedback problem if they did not count toward the totals that make the page.
It would still be fascinating. Now go outside and play.
Although cable is similar, "expensive water" at least allows competition. A new company is able to produce bottled water without having to reverse engineer and risk lawsuits or buy licenses from the already existing water producer.
Although in theory you should be able to cram all this into a "8-bit compatability library", the real world is not as nice as theory. In fact you need to duplicate the interface almost everywhere. And when you do this the 8-bit interface is used so much the 16-bit one is often not debugged and does not work (Xlib has a lot of this).
UTF-8 is an enormous win because it does not require dupliating the interface. I think we can safely switch all the interfaces to utf-8 with a simple rule that "erroneous sequences" are treated as the individual bytes in iso-8859-1 (this allows 99.9% of ios-8859-1 text through, but more importantly it deletes the need to handle "errors" in the interface). Even if people don't buy this the interfaces can be controlled by a simple "utf-8" mode switch, and even if this fails to be communicated correctly to the other end the software on the other end can be fixed to have a "override that switch" control.
In reality, "wide characters" and so on have been a horrible error and are probably the main reason internationalization has not happened. The only things wide characters give you is "go to character N fast". But in fact there is no reason for such an operation to be fast, it has nothing to do with parsing text (which is word-based), there are just morons out there in compsci who think it is necessary because it was fast for 8-bit bytes. I would love to see "wide characters" (at least for any interfaces) put in the dustbin as soon as possible. The fact that some people still think they have any advantage at all shows that there is still a long way to go, sigh...