TopView was hardly a contender, it was very much designed for emulating the character map of existing displays. There was no support for graphics (other than arrays of fixed-pitch characters) at all.
GEM would have been a contender but I am pretty certain we had test versions of Windows before we saw GEM. GEM also had laughable errors in their interface design, too, for instance they did double-clicks by delaying the reporting of the first click to the program until enough time had passed that they knew it was not a double click, this is unimaginably stupid and would have made it look like a performance dog.
Um, Xt is gone. All the modern toolkits for X use Xlib (not that Xlib is that great, but it is not Xt).
I don't have any idea what you are talking about with "PUSH" and "PULL". "PUSH" as in very early versions of Windows was a horrid mistake that allowed all kinds of programming mistakes to crash. They fixed this real quick (what the hell do you think the call GetMessage() does and why do you have to call it and then call DispatchMessage()? That's called "fix it but retain backward compatability").
In fact one of the biggest annoyances and source of bugs in my code for Windows is that not every event is pulled. For instance mapping or unmapping a window will cause gdamm windows to call the event handler directly. This requires you to make sure the data is set up correctly to reflect the fact that the window has been deleted before you delete it (kind of a pain if that involves destroying structures of your own that contain the window id!). It is similar in difficulty to multithreaded programming, and there really is no reason, if they deferred it until I called GetMessage everything would be a lot easier!
I agree with you about that multi-button mouse thing. Steve Jobs must have had a bad experience in childhood where he pressed the wrong button on a mouse. Two buttons on the mouse can't possibly "confuse" users as much as the keyboard that has over a HUNDRED buttons!
I also worked on the NeXT which had a 2-button mouse and discovered that the control panel option that said "make right mouse button work" physically changed the event server, without it it was *impossible* for a program to distinguish the left and right mouse buttons. Every other control panel thing just set a variable that a program could ignore if it really wanted to, but this shows that Jobs has a real hostility toward multiple mouse buttons.
You are right about the average fuel efficiency tax, I think. That would contribute to the price of the sports car especially since most of those companies don't make anything with good mileage to bring the average down. What is the story with SUV's, though, don't they raise the average for GM or whatever as much or more?
I also realize that the main reason the sports car is expensive is because it is a fancy car that takes a lot of money to produce. I was just commenting on the original that said that part of the cost was due to fuel-efficiency taxes. I felt that any tax portion is mostly due to luxury taxes instead.
And yea 20mpg is not good, but it is still a lot less than the 12mpg that those SUV's get. I'm sure the SUV's are more efficient per pound of steel being moved around, but when the main purpose is to haul one person it seems that a fancy sports car is a better deal for the environment than an SUV.
Fancy sports cars are taxed by a "luxury tax" that correspondes to the price of the car, not the fuel efficiency.
Though certainly not great, I think many of them get better gas milage than a typical SUV, I know a Porsche Boxster (obviously not quite the type of car you are talking about, but the closest I know anything about) gets 20mpg in real city driving.
Can't possibly be patents. It's trade secrets that they are hiding. Whatever is patented is described in detail in the patent. Yes, some patents are obfuscated so the description is useless, but that is done for trade secret reasons, if they really thought the patent would save them from competition they would not have to obscure it.
I have also heard that the code had to be closed because of FCC regulations. You could violate phone regulations if you directly accessed the card, and they made the (foolish) assumption that lack of source code would prevent people from messing with the card registers (they seem to have neglected the fact that lack of source code means people are *more* likely to make a mistake messing with the registers, and they have completely underestimated the chances of bugs in the code violating the FCC regulations).
They can be sued when they are a monopoly. Right now there seems to be some competition in Linux. And I think they are still fighting that Windows system, too...
Qt was written in a good deal less time than Swing, and it is multiplatform.
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
Most of my ideas were inspired by ReiserFS. I also want support for very small files. Besides file system design I think this means the ability to put everything into the data, even the *name* of the file, since all the permissions and other attributes is going to be larger than the file data. I'm not sure if it is possible to put the name in, but I would like to see attempts to put the permissions into the data (this is tricky as a program must be allowed to write anything to a file, so the hierarchy of directories must dictate the actual permission).
Of course MicroSoft did something stupid. The registry is exactly the type of thing that Reiser (and I) am trying to get away from. Yet another file format and library to read it, so that all the tools you have to read an existing one cannot be used on it. In many ways the mess of/etc is perferrable since it allows *some* file manipulation tools to work, you can create or delete a whole catagory of information using normal tools, though trying to change individual records requires specialized programs (ie a text editor).
They should have either fixed their filesystem to support many small files. At least used a XFS type interface so the same calls could be used to manipulate the registry as any other files, this I hope will be what Linux does if they are forced to do it by the need for compatability or because nobody fixes the file system to be faster.
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
Why is "I don't know" better than "UTF-8 text with CRLF line endings"? And how exactly do you distinguish between a typed file and a file that just happens to start with those magic numbers?
"UTF-8 text with CRLF" is what I meant by an "I don't know" answer. The way you distinguish a typed file that just happens to start with the magic bytes is you look at more bytes until you are reasonably certain this really is the file type you want.
The UTF-8 BOM causes all sorts of problems with the standard Unix text tools. What tools take one off and put one on is an ugly complex question that requires changing about every program that might output text.
Raw text tools would be edit the text to put the BOM mark there (or remove it, or change it to something else to outwit the file system). My proposal is that the standard read/write of files is unchanged. It is the program's responsibility to read/write the identifier. For the vast majority of Unix text files you would put a comment line at the start with the id. Take a look at how Emacs can have an id at the start of the file for ideas. The BOM is not needed for data files that belong to a particular program, in fact the BOM can be used to identify raw text.
We need a system where getting the first 1K or so of a file is as fast as reading it's name. I.e. we need a system where it takes as much time to read the directory listing as it does to read the directory listing and open the file. Sounds like efficency to me.
The idea is that getting at least the first block of bytes of a file mapped into memory is much faster than opening the file. On Unix I propose that a block of data of a guaranteed minimum size be stored in the Inode and that getting it would be as fast as getting the permission of a file today. You may have to use a different call than open. Reading the names of files would be just as fast as it is on Unix today, but running file would be similar to getting the executable or directory bits for each file.
I assure you I have seen WinXP. Why do you think I said "MicroSoft lost it". And WinXP is exactly what I was talking about when I said users seem to be setting it back to the Win98 appearance.
Very few people change the window colors (they do like to change the desktop wallpaper, I agree). Get out of the computer lab and look at some real users such as secretaries. I would be suprised if you find any of them have changed their Windows boxes other than the desktop image.
I still feel that "themes" are an excuse for programmers to feel elite and avoid working on hard stuff (like the ability to render an image with fewer than 2 pages of code, or to draw UTF-8 text without hundreds of K of libraries). Making the screen look like Deep Space 9 does not make it user friendly!
Flashy appearance is not what users want. KDE realizes this, and so did MicroSoft and Apple at one time. "Themes" like a lot of X11 users seem to think are cool do NOT impress basic users. All the badly designed and candy coloring only impresses geeks who like to program these things because they are too lazy to program useful stuff.
MicroSoft has obviously fallen into this trap, which is probably good for Linux, as long as KDE with it's simple basic appearance remains clean. Take a look at how many WinXP users have gone through the trouble of changing the "appearance" back to the old standard. It looks to me like more than "customized" older Windows by changing the colors.
Flashy graphics only distracts from the job and I am glad that KDE defaults to none.
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
I'll bet that if a system was made that used "file" for everything, very quickly you would see "file" improved to the point that it identified everything 99% accurately (if you include accurately identifying a file without magic numbers as "I don't know what this is" rather than some random type). Also you would quickly see magic numbers stuck on everything, for instance raw UTF-8 would have a UTF-8 encoded non-marking-space (or whatever it is called) code at the start.
In any case I would expect it to be much more reliable than either filename extensions or Mac ids, both of which have the problem that they can be changed without changing the data and they can be lost in transmission.
I think the main argument against "file" for everything is the speed issue. We need a system where getting the first 1K or so of a file is as fast as reading it's name.
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
No, his recommendation is equivalent to having circutiry imbedded in the CD case that reads some data from the disk and displays the correct label on the case.
The only argument against doing this is the impracticality and expense of putting this circutry into each case, and the need to have designed CD's from the start to have space for this data. This actually matches the arguments against putting all data into the file stream (arguments I am finding very weak nowadays).
Re:extension? what do we need the extension for?
on
JPEG2000 Coming Soon
·
· Score: 2
You are talking about a file that has *NO* magic number at the start (ie it is just UTF-8 text). Violating the rules of "file" will cause it to fail. I might as well complain if on a Mac I decided I could use those 4 bytes of type information to store the first 4 characters of my text, and then complained that it opened random files!
There is lots of argument on all points of this. My opinion is that putting all the data in the file is the best solution, primarily because it can't get lost when the file is transmitted somewhere, but also because it is easy for a program to read, write, and alter it. But there is a lot of legacy files with no space in them to put such information. I consider the Mac id and the filename extension to be pretty much the same solution (put a few bytes of id somewhere other than the data stream).
Actually PNG's predictive encoding is a lot better for real images than GIF's LZW. LZW is designed for repeating patterns and thus worked well for dithering patterns that were once popular for making "color" when displays often had only 16 different colors. It also works good for letters against a solid background, espeically computer-generated lettering from fixed bitmaps, not photos or scans of letters.
Predictive encoding basically relies on assumming the first and second derivative of the image is very small. Ie that there are large areas of pretty even color, even though noise makes the pixels fluctuate such that there is no pattern for LZW.
Compress random gray-scale images (gray scale because both PNG and GIF start with the same 8 bits) and it is pretty obvious that PNG compresses much better.
Unfortunately people tend to ignore the fact that for color, GIF has to do a huge lossy step of reducing it to 256 different colors. It then compresses starting from 8 bits rather than the 24 bits PNG does and this 1/3 initial size more than makes up for the worse compression so many people think GIF is better.
Also some screen shots have patterns in them. The biggest culprit right now is that strange halftone that Windows puts into the scrollbars, this seems almost designed to make sure PNG style screen shots are bigger than LZW compressed files.
Re:oh, my first chance at seeing the dumb Katz
on
Review: Panic Room
·
· Score: 2
BUF did the flying around the interior of the apartment of Fight Club and did the flying around camera here, too.
I have Mandrake on my machine, and I even joined their club in order to support them. But I would like to upgrade my machine and I don't have DSL so I would like to buy a boxed set. But it looks like Fry's (big chain out here in California) has stopped carrying it (and they have not abandoned Linux, they still have RedHat and SUSE). I could shop around, but the fact that they have disappeared from the store I bought it from is alarming.
I would say that the DMCA and it's attacks on talking about how computers work is the equivalent of what the Soviet Union did.
But the entertainment industry is trying something even more difficult than the Soviet Union and KGB tried (and failed) to do! The USSR did not want *anybody* to read the forbidden material. The entertainment industry *wants* people to see the material yet somehow be unable to copy it!
What the Soviets tried to do did not violate the laws of physics and causality.
But they will be providing a device that checks the watermark!
If it does not play, the watermark is there.
If it does play, the watermark has been removed.
If these idiots really wanted to do anything, they would put in a secret watermark but NOT make it control playback. Then they could use that watermark to track down the initial source of who started copying it (since that person did not have the ability to test if they removed it).
Gosh you are right, we would hate to have the confusion that exists in other consumer products like cars. Nobody I know can figure out how to operate cars, it would all be fixed if only Ford was a monopoly, I'm sure.
It looks to me like the antialiasing is turned off.
I am using KDE2 with antialising turned on. The main problems are:
1. Use that new libXft that a big article was posted about in Slashdot a few weeks ago.
2. The defaults in KDE are awful, apparently it picks the first font alphabetically if it can't figure things out, which is some unreadable cursive thing called "Arioso". Changing all this was a chore, as the control panel is unreadable, and there were a zillion bugs so that the fonts kept reverting. Log out, log back in, try to fix them again, repeat a few times, and eventually I got them. Still get that cursive font every now and then.
Anyway after that bit of hell, it does look quite nice. And I did not do any of the stuff people say is needed: I did not install Windows fonts and I did not edit the.xftconfig file.
KDE3.0 I hope will fix these problems:
1. When they turn antialiasing on, default to something usable. Even better is to ship KDE with antialiasing turned on by default.
2. Change the font selection to select everything in pixel size (rather than "point size") so that the sizes don't change when your X server is upgraded to something that claims a different resolution (this also caused some pain for awhile). If they insist on this, please allow users to select fractional sizes. I would also round to the nearest pixel size if the selected pixel size is within about.1 of an integer (this may be Xft's responsibility).
3. Distribute the fixed libXft as part of the distribution so everybody gets nicer fonts without having to think about it.
Re:Valgrind and memory leaks
on
KDE 3.0 is Out
·
· Score: 3, Insightful
There's a better way. Make a class "Uncopyable", like so:
Unfortunately MicroSoft has f**ked us there, if you are interested in making portable shared libraries. It will fail to build a shared library if the implementation of the function is not there. The best this does then is that non-member functions cannot do a copy, but unfortunately member or friend functions still can. Of course you can make the function abort but that is enourmously less useful than detecting things at compile time.
I ifdef these things out on Unix but this useful thing is lost on Windows users.
Slashdot Mirror
The IE button is shown in lots of other Apple ads, so I doubt the trademark/permission was a problem.
GEM would have been a contender but I am pretty certain we had test versions of Windows before we saw GEM. GEM also had laughable errors in their interface design, too, for instance they did double-clicks by delaying the reporting of the first click to the program until enough time had passed that they knew it was not a double click, this is unimaginably stupid and would have made it look like a performance dog.
I don't have any idea what you are talking about with "PUSH" and "PULL". "PUSH" as in very early versions of Windows was a horrid mistake that allowed all kinds of programming mistakes to crash. They fixed this real quick (what the hell do you think the call GetMessage() does and why do you have to call it and then call DispatchMessage()? That's called "fix it but retain backward compatability").
In fact one of the biggest annoyances and source of bugs in my code for Windows is that not every event is pulled. For instance mapping or unmapping a window will cause gdamm windows to call the event handler directly. This requires you to make sure the data is set up correctly to reflect the fact that the window has been deleted before you delete it (kind of a pain if that involves destroying structures of your own that contain the window id!). It is similar in difficulty to multithreaded programming, and there really is no reason, if they deferred it until I called GetMessage everything would be a lot easier!
I agree with you about that multi-button mouse thing. Steve Jobs must have had a bad experience in childhood where he pressed the wrong button on a mouse. Two buttons on the mouse can't possibly "confuse" users as much as the keyboard that has over a HUNDRED buttons!
I also worked on the NeXT which had a 2-button mouse and discovered that the control panel option that said "make right mouse button work" physically changed the event server, without it it was *impossible* for a program to distinguish the left and right mouse buttons. Every other control panel thing just set a variable that a program could ignore if it really wanted to, but this shows that Jobs has a real hostility toward multiple mouse buttons.
I also realize that the main reason the sports car is expensive is because it is a fancy car that takes a lot of money to produce. I was just commenting on the original that said that part of the cost was due to fuel-efficiency taxes. I felt that any tax portion is mostly due to luxury taxes instead.
And yea 20mpg is not good, but it is still a lot less than the 12mpg that those SUV's get. I'm sure the SUV's are more efficient per pound of steel being moved around, but when the main purpose is to haul one person it seems that a fancy sports car is a better deal for the environment than an SUV.
Though certainly not great, I think many of them get better gas milage than a typical SUV, I know a Porsche Boxster (obviously not quite the type of car you are talking about, but the closest I know anything about) gets 20mpg in real city driving.
I have also heard that the code had to be closed because of FCC regulations. You could violate phone regulations if you directly accessed the card, and they made the (foolish) assumption that lack of source code would prevent people from messing with the card registers (they seem to have neglected the fact that lack of source code means people are *more* likely to make a mistake messing with the registers, and they have completely underestimated the chances of bugs in the code violating the FCC regulations).
They can be sued when they are a monopoly. Right now there seems to be some competition in Linux. And I think they are still fighting that Windows system, too...
Qt was written in a good deal less time than Swing, and it is multiplatform.
Of course MicroSoft did something stupid. The registry is exactly the type of thing that Reiser (and I) am trying to get away from. Yet another file format and library to read it, so that all the tools you have to read an existing one cannot be used on it. In many ways the mess of /etc is perferrable since it allows *some* file manipulation tools to work, you can create or delete a whole catagory of information using normal tools, though trying to change individual records requires specialized programs (ie a text editor).
They should have either fixed their filesystem to support many small files. At least used a XFS type interface so the same calls could be used to manipulate the registry as any other files, this I hope will be what Linux does if they are forced to do it by the need for compatability or because nobody fixes the file system to be faster.
"UTF-8 text with CRLF" is what I meant by an "I don't know" answer. The way you distinguish a typed file that just happens to start with the magic bytes is you look at more bytes until you are reasonably certain this really is the file type you want.
The UTF-8 BOM causes all sorts of problems with the standard Unix text tools. What tools take one off and put one on is an ugly complex question that requires changing about every program that might output text.
Raw text tools would be edit the text to put the BOM mark there (or remove it, or change it to something else to outwit the file system). My proposal is that the standard read/write of files is unchanged. It is the program's responsibility to read/write the identifier. For the vast majority of Unix text files you would put a comment line at the start with the id. Take a look at how Emacs can have an id at the start of the file for ideas. The BOM is not needed for data files that belong to a particular program, in fact the BOM can be used to identify raw text.
We need a system where getting the first 1K or so of a file is as fast as reading it's name.
I.e. we need a system where it takes as much time to read the directory listing as it does to read the directory listing and open the file. Sounds like efficency to me.
The idea is that getting at least the first block of bytes of a file mapped into memory is much faster than opening the file. On Unix I propose that a block of data of a guaranteed minimum size be stored in the Inode and that getting it would be as fast as getting the permission of a file today. You may have to use a different call than open. Reading the names of files would be just as fast as it is on Unix today, but running file would be similar to getting the executable or directory bits for each file.
Very few people change the window colors (they do like to change the desktop wallpaper, I agree). Get out of the computer lab and look at some real users such as secretaries. I would be suprised if you find any of them have changed their Windows boxes other than the desktop image.
I still feel that "themes" are an excuse for programmers to feel elite and avoid working on hard stuff (like the ability to render an image with fewer than 2 pages of code, or to draw UTF-8 text without hundreds of K of libraries). Making the screen look like Deep Space 9 does not make it user friendly!
It sounds quite scary, in fact, scary enough that I am not even going to attempt it. Sigh.
MicroSoft has obviously fallen into this trap, which is probably good for Linux, as long as KDE with it's simple basic appearance remains clean. Take a look at how many WinXP users have gone through the trouble of changing the "appearance" back to the old standard. It looks to me like more than "customized" older Windows by changing the colors.
Flashy graphics only distracts from the job and I am glad that KDE defaults to none.
In any case I would expect it to be much more reliable than either filename extensions or Mac ids, both of which have the problem that they can be changed without changing the data and they can be lost in transmission.
I think the main argument against "file" for everything is the speed issue. We need a system where getting the first 1K or so of a file is as fast as reading it's name.
The only argument against doing this is the impracticality and expense of putting this circutry into each case, and the need to have designed CD's from the start to have space for this data. This actually matches the arguments against putting all data into the file stream (arguments I am finding very weak nowadays).
There is lots of argument on all points of this. My opinion is that putting all the data in the file is the best solution, primarily because it can't get lost when the file is transmitted somewhere, but also because it is easy for a program to read, write, and alter it. But there is a lot of legacy files with no space in them to put such information. I consider the Mac id and the filename extension to be pretty much the same solution (put a few bytes of id somewhere other than the data stream).
Predictive encoding basically relies on assumming the first and second derivative of the image is very small. Ie that there are large areas of pretty even color, even though noise makes the pixels fluctuate such that there is no pattern for LZW.
Compress random gray-scale images (gray scale because both PNG and GIF start with the same 8 bits) and it is pretty obvious that PNG compresses much better.
Unfortunately people tend to ignore the fact that for color, GIF has to do a huge lossy step of reducing it to 256 different colors. It then compresses starting from 8 bits rather than the 24 bits PNG does and this 1/3 initial size more than makes up for the worse compression so many people think GIF is better.
Also some screen shots have patterns in them. The biggest culprit right now is that strange halftone that Windows puts into the scrollbars, this seems almost designed to make sure PNG style screen shots are bigger than LZW compressed files.
BUF did the flying around the interior of the apartment of Fight Club and did the flying around camera here, too.
I have Mandrake on my machine, and I even joined their club in order to support them. But I would like to upgrade my machine and I don't have DSL so I would like to buy a boxed set. But it looks like Fry's (big chain out here in California) has stopped carrying it (and they have not abandoned Linux, they still have RedHat and SUSE). I could shop around, but the fact that they have disappeared from the store I bought it from is alarming.
But the entertainment industry is trying something even more difficult than the Soviet Union and KGB tried (and failed) to do! The USSR did not want *anybody* to read the forbidden material. The entertainment industry *wants* people to see the material yet somehow be unable to copy it!
What the Soviets tried to do did not violate the laws of physics and causality.
If it does not play, the watermark is there.
If it does play, the watermark has been removed.
If these idiots really wanted to do anything, they would put in a secret watermark but NOT make it control playback. Then they could use that watermark to track down the initial source of who started copying it (since that person did not have the ability to test if they removed it).
Gosh you are right, we would hate to have the confusion that exists in other consumer products like cars. Nobody I know can figure out how to operate cars, it would all be fixed if only Ford was a monopoly, I'm sure.
I am using KDE2 with antialising turned on. The main problems are:
1. Use that new libXft that a big article was posted about in Slashdot a few weeks ago.
2. The defaults in KDE are awful, apparently it picks the first font alphabetically if it can't figure things out, which is some unreadable cursive thing called "Arioso". Changing all this was a chore, as the control panel is unreadable, and there were a zillion bugs so that the fonts kept reverting. Log out, log back in, try to fix them again, repeat a few times, and eventually I got them. Still get that cursive font every now and then.
Anyway after that bit of hell, it does look quite nice. And I did not do any of the stuff people say is needed: I did not install Windows fonts and I did not edit the .xftconfig file.
KDE3.0 I hope will fix these problems:
1. When they turn antialiasing on, default to something usable. Even better is to ship KDE with antialiasing turned on by default.
2. Change the font selection to select everything in pixel size (rather than "point size") so that the sizes don't change when your X server is upgraded to something that claims a different resolution (this also caused some pain for awhile). If they insist on this, please allow users to select fractional sizes. I would also round to the nearest pixel size if the selected pixel size is within about .1 of an integer (this may be Xft's responsibility).
3. Distribute the fixed libXft as part of the distribution so everybody gets nicer fonts without having to think about it.
Unfortunately MicroSoft has f**ked us there, if you are interested in making portable shared libraries. It will fail to build a shared library if the implementation of the function is not there. The best this does then is that non-member functions cannot do a copy, but unfortunately member or friend functions still can. Of course you can make the function abort but that is enourmously less useful than detecting things at compile time.
I ifdef these things out on Unix but this useful thing is lost on Windows users.
You think you are funny but you are really showing a lot of ignorance. The anti-MicroSoft site is selling Unix, not keyboards!