MDI is the worst piece of crap ever invented. It was designed for Windows 3.0 to try to prevent inactive applications from swapping in. It serves NO OTHER PURPOSE!!!! Get that through your thick skull!
Unfortunately due to MDI Windoze has broken the UI by making windows "click to the top" even if you try to pick a menu item or click a button in them. This error existed in X once upon a time (in X9 I believe) and was fixed. That was only 15 years ago so I guess MicroSoft has not caught up.
At work we have perhaps 5 different tiff-reading programs for converting to other file formats. This is because none of them are able to read all the tiff variants we have encountered. You have to try each of them until you find a program that works.
Tiff is seriously broken by being too fancy. The fact that PNG supports exactly one compression format is a big win and I expect PNG will completely replace Tiff very soon (replacing GIF is less likely...)
If this was for piracy, it would be in MicroSoft's interest to advertise the fact that they can catch pirates using this. Prevention of piracy is far more useful than persecution after the fact.
Since they have not advertised this it would indicate the purpose of the ID is something else.
IMHO, this is just idiot programmers making a mess, not some great plot by the evil Redmond geniuses. In fact I fear the idiot programmers more than the evil monopoly!
I would think it can't be very hard to replicate the NT login screen and make a fake program that can steal passwords.
Unless it is impossible for a program to stop the Ctrl+Alt+Delete? I suppose that would make a real clone impossible. However a tiny hardware modification (probably doable with only access to the keyboard) would make this pointless.
Face it, we are not going to get most new hardware support without this. So there. And what Linus allows sounds no different than allowing binary-only programs to run on Linux and people don't seem too upset about that (yea, some are...)
What Mosix is doing should be totally disallowed. Even if they give the complete source code for the "kernel mods". With these rules MicroSoft could make "MSLinux with Windows compatability" where they provide a giant "binary module" and "kernel mods" which implement 500 new system calls, all of which call a numbered entry point in the "module".
Any kernel modifications must be approved by the development team and Linus and put into the official source tree. And if somebody convinces them that they really need their new module interface added (unlikely imho), there should be a requirement that a "reference implementation" of that module be provided with working source code so other people can understand exactly what the modifications do. (this reference implementation must be fully functional, but it may be useless, possibly because it is no faster than doing the same function some other way because it does not include the secret hardware/software that the module writers have).
I think the "taskbar" equivalent is more the Apple pulldown menu off the icon in the upper right that shows which app is current, not the finder.
I am quite glad Windoze has those individual menu bars, as otherwise we would be stuck with click-to-type because of people copying the one-menubar interface... Right now Point-To-Type support is probably Linux's #1 User Interface advantage over other systems. (the fact that you can click on a window without raising it under both click and point to type under most window managers is perhaps #2)
I do hate both of KDE and GNOME for not figuring out a way to provide users with the controls without wasting the screen space with a "taskbar". I personally would like to see both the "taskbar" and "start button" combined into a single pop-up menu that takes ZERO space when not being used.
Easier for Linux users than Microsoft users
on
ClearCase for Linux
·
· Score: 1
I agree with the earlier comment that Ctrl+C alienates Macintosh users.
But hey, why not have BOTH Alt+C and Ctrl+C do a copy? This is the sort of solution ideas we need.
(really in my code I use Ctrl+C for copy, for the same reason that MicroSoft does: I don't want to interfere with the use of Alt+C to copy other data (like graphics) and was too lazy to write the program to analyze what you selected last.)
Also PNG is not a lossy scheme and the authors said they will never put a lossy scheme into it. This is good, because we want to see ".png" and know it is lossless, and see ".jpeg" (or ".wl") and know it is lossy. Do-everything things like tiff are doomed because we want to know what is going on...
The only possible way to correctly "document" the WIN32 api is to release the source code. I am sure that there is no other accurate documentation, even at MicroSoft.
We do not want a "test suite" or a Windows Standards board. These could very well legislate an even worse interface (and quite likely incompatable with Windows programs) than already exists.
Source code is the only way. The DOJ should also test the code: it must be compiled by a disinterested party, installed on a blank machine, and tested to accurately run EVERY MicroSoft software product (and some large selection of third-party products). In addition, all future MicroSoft products must be demonstrated to run on a system made only from the published source code.
If MicroSoft adds something to the system they must provide source for this. However, they can provide a "reference" implementation, if they wish they can make an internal optimized version using secret faster algorithims. Software must be proven to work with the "reference" implementation.
No I worked mostly on SGI but recently am doing a lot more Linux and (sigh) NT work.
To be honest, I am not a sysadm but a software devloper. I just thought it was neat that I already bought the car that the NT guy is dreaming of getting.
And yes I know I misspelled Boxster so don't flame me I was typing too fast.
My Porsche Boxter is already bought and 1/3 paid for and I don't touch NT machines if I can help it.
So there.
Mesa is much faster than SGI's own code
on
Parallel Mesa
·
· Score: 1
(sorry about previous header, apparently hitting return after the subject posts the message!)
Anyway, this can be easily demonstrated by linking the same program with Mesa or with OpenGL on an SGI Irix machine. If you then run them both: well yes, of course the hardware is faster, but try a program that uses something that the hardware does not do (on mine, any texture mapping) and you will see that Mesa's software emulation is MANY TIMES faster than SGI's.
Perhaps SGI purposely maimed theirs to encourage people to buy more hardware, but I really suspect the reason is that the software writers there are not as good as the ones who work on Open Source.
No, it's immensly trivial. To run your new copy of MSQuicken you have to register at the MS web site. This will pop up a form for your name, address, phone number, where you bought the software, who recommended it, your hobbies, and all that. Most likely you dont *have* to fill it in but I figure a lot of people will. Submitting of the form will also transmit your CPU ID, and it will send back a cookie with a encrypted version of your cpu id (and perhaps everything you typed into the form encrypted as well).
MSQuicken will read the cookie file (I don't think they will even bother to put it somewhere else!) and decrypt it and refuse to run unless it results in the same CPU ID as the machine.
And the end user will be happy because their 1040 form comes up already filled in with their name and SSN and perhaps even their income...
When you get a new computer to replace the one that was stolen, you are going to find your software or your ISP does not work unless you mail the police report about your stolen computer (including it's ID) and your new computers ID to the software company. Then it is rather trivial for the databases to move the information from the old ID to the new one.
I believe the PID will be far more reliable than the SSN. Sometimes people mistype the SSN...
If you are the same person posting this "professional color management" rant over and over, you ought to try chilling out. Go outside and look at the sky or something...
Linux is missing a lot of stuff but "professional color management", that one you keep saying, is so far down the list as to be invisible.
I work in special effects at Digital Domain (using SGI, NT, and Linux) and I can confirm we don't give a shit about "professional color management" or CMYK or Pantone colors or any of the other things that are "missing from Gimp". In fact Gimp does everything we need in a painting program (we use Amazon Paint instead, as it is nicer, but Amazon has no more "color management" than Gimp).
Anybody who believes it is physically possible to match colors emitted from a phospher with colors caused by reflecting light off a silvered screen with colors produced by reflecting light twice through a dye and off a piece of paper should perhaps study physics a bit more.
We do exactly what everybody should do: print an output on the final medium and look at it and decide if the color is wrong. "Relative color management" (ie saying "it's too dark, make it lighter, even though it looks ok on the screen") works perfectly even on the cheapest hardware and software.
Slashdot Mirror
MDI is the worst piece of crap ever invented. It was designed for Windows 3.0 to try to prevent inactive applications from swapping in. It serves NO OTHER PURPOSE!!!! Get that through your thick skull!
Unfortunately due to MDI Windoze has broken the UI by making windows "click to the top" even if you try to pick a menu item or click a button in them. This error existed in X once upon a time (in X9 I believe) and was fixed. That was only 15 years ago so I guess MicroSoft has not caught up.
PLEASE NO MDI! Thank you.
NO! That's a different format!
The whole point of PNG is that it is relatively simple and small and the job it does can be easily described ("lossless image storage").
If you are tired of jpeg feel free to write your own lossy compression scheme, but make it a different file format, please!
At work we have perhaps 5 different tiff-reading programs for converting to other file formats. This is because none of them are able to read all the tiff variants we have encountered. You have to try each of them until you find a program that works.
Tiff is seriously broken by being too fancy. The fact that PNG supports exactly one compression format is a big win and I expect PNG will completely replace Tiff very soon (replacing GIF is less likely...)
If this was for piracy, it would be in MicroSoft's interest to advertise the fact that they can catch pirates using this. Prevention of piracy is far more useful than persecution after the fact.
Since they have not advertised this it would indicate the purpose of the ID is something else.
IMHO, this is just idiot programmers making a mess, not some great plot by the evil Redmond geniuses. In fact I fear the idiot programmers more than the evil monopoly!
I would think it can't be very hard to replicate the NT login screen and make a fake program that can steal passwords.
Unless it is impossible for a program to stop the Ctrl+Alt+Delete? I suppose that would make a real clone impossible. However a tiny hardware modification (probably doable with only access to the keyboard) would make this pointless.
Face it, we are not going to get most new hardware support without this. So there. And what Linus allows sounds no different than allowing binary-only programs to run on Linux and people don't seem too upset about that (yea, some are...)
What Mosix is doing should be totally disallowed. Even if they give the complete source code for the "kernel mods". With these rules MicroSoft could make "MSLinux with Windows compatability" where they provide a giant "binary module" and "kernel mods" which implement 500 new system calls, all of which call a numbered entry point in the "module".
Any kernel modifications must be approved by the development team and Linus and put into the official source tree. And if somebody convinces them that they really need their new module interface added (unlikely imho), there should be a requirement that a "reference implementation" of that module be provided with working source code so other people can understand exactly what the modifications do. (this reference implementation must be fully functional, but it may be useless, possibly because it is no faster than doing the same function some other way because it does not include the secret hardware/software that the module writers have).
I think the "taskbar" equivalent is more the Apple pulldown menu off the icon in the upper right that shows which app is current, not the finder.
I am quite glad Windoze has those individual menu bars, as otherwise we would be stuck with click-to-type because of people copying the one-menubar interface... Right now Point-To-Type support is probably Linux's #1 User Interface advantage over other systems. (the fact that you can click on a window without raising it under both click and point to type under most window managers is perhaps #2)
I do hate both of KDE and GNOME for not figuring out a way to provide users with the controls without wasting the screen space with a "taskbar". I personally would like to see both the "taskbar" and "start button" combined into a single pop-up menu that takes ZERO space when not being used.
I agree with the earlier comment that Ctrl+C alienates Macintosh users.
But hey, why not have BOTH Alt+C and Ctrl+C do a copy? This is the sort of solution ideas we need.
(really in my code I use Ctrl+C for copy, for the same reason that MicroSoft does: I don't want to interfere with the use of Alt+C to copy other data (like graphics) and was too lazy to write the program to analyze what you selected last.)
Also PNG is not a lossy scheme and the authors said they will never put a lossy scheme into it. This is good, because we want to see ".png" and know it is lossless, and see ".jpeg" (or ".wl") and know it is lossy. Do-everything things like tiff are doomed because we want to know what is going on...
The only possible way to correctly "document" the WIN32 api is to release the source code. I am sure that there is no other accurate documentation, even at MicroSoft.
We do not want a "test suite" or a Windows Standards board. These could very well legislate an even worse interface (and quite likely incompatable with Windows programs) than already exists.
Source code is the only way. The DOJ should also test the code: it must be compiled by a disinterested party, installed on a blank machine, and tested to accurately run EVERY MicroSoft software product (and some large selection of third-party products). In addition, all future MicroSoft products must be demonstrated to run on a system made only from the published source code.
If MicroSoft adds something to the system they must provide source for this. However, they can provide a "reference" implementation, if they wish they can make an internal optimized version using secret faster algorithims. Software must be proven to work with the "reference" implementation.
No I worked mostly on SGI but recently am doing a lot more Linux and (sigh) NT work.
To be honest, I am not a sysadm but a software devloper. I just thought it was neat that I already bought the car that the NT guy is dreaming of getting.
And yes I know I misspelled Boxster so don't flame me I was typing too fast.
My Porsche Boxter is already bought and 1/3 paid for and I don't touch NT machines if I can help it.
So there.
(sorry about previous header, apparently hitting return after the subject posts the message!)
Anyway, this can be easily demonstrated by linking the same program with Mesa or with OpenGL on an SGI Irix machine. If you then run them both: well yes, of course the hardware is faster, but try a program that uses something that the hardware does not do (on mine, any texture mapping) and you will see that Mesa's software emulation is MANY TIMES faster than SGI's.
Perhaps SGI purposely maimed theirs to encourage people to buy more hardware, but I really suspect the reason is that the software writers there are not as good as the ones who work on Open Source.
No, it's immensly trivial. To run your new copy of MSQuicken you have to register at the MS web site. This will pop up a form for your name, address, phone number, where you bought the software, who recommended it, your hobbies, and all that. Most likely you dont *have* to fill it in but I figure a lot of people will. Submitting of the form will also transmit your CPU ID, and it will send back a cookie with a encrypted version of your cpu id (and perhaps everything you typed into the form encrypted as well).
MSQuicken will read the cookie file (I don't think they will even bother to put it somewhere else!) and decrypt it and refuse to run unless it results in the same CPU ID as the machine.
And the end user will be happy because their 1040 form comes up already filled in with their name and SSN and perhaps even their income...
When you get a new computer to replace the one that was stolen, you are going to find your software or your ISP does not work unless you mail the police report about your stolen computer (including it's ID) and your new computers ID to the software company. Then it is rather trivial for the databases to move the information from the old ID to the new one.
I believe the PID will be far more reliable than the SSN. Sometimes people mistype the SSN...
If you are the same person posting this "professional color management" rant over and over, you ought to try chilling out. Go outside and look at the sky or something...
Linux is missing a lot of stuff but "professional color management", that one you keep saying, is so far down the list as to be invisible.
I work in special effects at Digital Domain (using SGI, NT, and Linux) and I can confirm we don't give a shit about "professional color management" or CMYK or Pantone colors or any of the other things that are "missing from Gimp". In fact Gimp does everything we need in a painting program (we use Amazon Paint instead, as it is nicer, but Amazon has no more "color management" than Gimp).
Anybody who believes it is physically possible to match colors emitted from a phospher with colors caused by reflecting light off a silvered screen with colors produced by reflecting light twice through a dye and off a piece of paper should perhaps study physics a bit more.
We do exactly what everybody should do: print an output on the final medium and look at it and decide if the color is wrong. "Relative color management" (ie saying "it's too dark, make it lighter, even though it looks ok on the screen") works perfectly even on the cheapest hardware and software.