Sorry, you can't use my house for a party. You can't use your house, or any friends house. I have patented "having a party at a house" and will sue you for infringement if you dare try!
Yep, I was working in the software industry when the Mac came out, and the first thing my company did was make a game. They did this millipede ripoff in about 1 month, and if I remember right the major portion of the budget was spent on designing and printing the packaging. However it certainly used the mouse, and it would be difficult or impossible to duplicate Millipede so well on a mouse-less MSDOS machine.
Jason Linhart wrote the game, but I got the job of drawing most of the icons. I'm particularily proud of the swiss cheese, it's pretty hard to draw something legible in a 16x32 space in two colors!
If you already have a setup of hundreds of non-Mac machines running some clustering that doesn't work on Mac, you might be tempted to try replacing it with this code. It might work better, it might be nicer designed, it might be cheaper, or you might like it because it works on Macs or because the source is available. In any case there is a chance that you will like it and switch to it.
If you switch, you are suddenly in the position of being able to add Macintosh products to your cluster, and you may go out and buy some of those really fast Xserve boxes. And Apple makes money.
If Apple did not release this, or tried to sell it, you would most likely ignore it, be unable to add Macs to your cluster no matter how good they are, and Apple does not make money.
If the "old" functions are implemented by just changing the arguments and calling the "new" ones, then there is absolutely no problem with this. I suspect this is true in almost all cases.
The biggest problem is Microsoft's documentation refuses to reveal which functions are "old" and which ones are "new". Things ending in Ex are obviously "new" but there are also dozens of other functions that seem to have a whole set of parallel ways of getting done, and I have not been able to figure out from the documentation which is which. Window classes and DC's and some of WGL are what cause me the most pain, I have certainly wasted time trying different calls to discover that they all have exactly the same behavior underneath.
Recommendation to Microsoft, which I'm sure they will loathe: print some source code in your documentation. What I mean is documentation that says literally: functin foo() is obsolete and is implemented as "return fooEx(GetDC(blah),0,EXTRA_FLAG);"
Classes are usually capitalized in C++, you know. When my documentation says "Window" it means the class, when it says "window" is means an instance of the class. It used to read something like "When using Windoze you need to make sure all Windows are declared before you can call the blah() method, and unfortunately X11 requires the exact opposite." You need to learn a little programming before you start saying anything about capitalization.
Now my documentation reads "When using WIN32 you need to make sure all Windows are declared before you can call the blah() method, and unfortunately X11 requires the exact opposite."
Great, you have just made your favorite os look as stupid with letters and numbers as X. You should be real proud of yourself.
This thinking is right up there with the "you can't call things master/slave" ruling. If you actually knew anything about computer science history you would see that creative mispellings are usaully an indication of affection (unless it is blatently obvious: calling it "WinBlows" is obvious hostility, and is pronouced with obvious hostility). As you pointed out "Windoze" is not pronouced differently and is thus only useful for text, just like the capitalization is a handy shortcut for classes. No duh, when speaking, I have to say "Windows OS", "Window class", and "window". That does not mean I should be unable to use a convienent shorthand when writing. Now of course I call it "win thirty two" when talking, just to piss people like you off.
Windows could be equally friendly if it popped up a box that said "Do you want to run the software that is on this disk now?" yes/no. In fact this would be better, as you could stick the disk in the drive and walk out while it is spinning up and not miss the autorun splash screen (which often tells you what the hell is happening).
As several other posters pointed out, Linux from RedHat also has "autorun". And the posters are complaining that this sucks and we should not be copying misfeatures from Windows.
It is f**king annoying that they chose a common word for the name for their system. I am working on GUI interface software and the fact that by default you cannot tell whether I am talking about the OS or the plural of an object that is used quite a bit in GUI makes documentation almost impossible unless a different word is chosen for the name of the OS. So for very professional reasons I used "Windoze" for many years, with no complaints from users Windows users. Then suddenly people started saying "oh using that word means you hate Microsoft" I had to switch, I now am forced to use "WIN32" to indicate the operating system (you use "#ifdef _WIN32" to detect it in C++ code, so I guess this is an officially sanctioned name). Thanks a lot for making my documentation look a lot worse and more geeky than it needs to be.
I consider it extremely annoying the political-correctness has forced me to obfuscate my own work, and am very annoyed at people with your attitude, and the sad fact that all fun and creativity is being sucked out of this field by people like you.
All modern terminals and terminal emulators send something other than 127 for the Delete key, mine for instance sends ^[[3~. Therefore the behavior for this key is unchanged. The codes 127 and ^H are only sent by the key in the upper-right of the main keyboard that is usually marked "backspace", therefore both those codes should do backspace.
It would not even break emacs! Emacs puts the terminal in raw mode and thus it might need to be fixed seperately, but a change to the tty driver would make this work for all your command-line programs.
The delete/backspace thing is best fixed by having Unix machines treat *both* as backspace, so it does not matter which your terminal sends. Why this has not been fixed in Unix about 20 years ago is a mystery...
The VT100 codes are pretty "standard" and all terminal emulators use them, thus terminfo/termcap can pretty much be ignored. I have much more problems with programs that try to use termcap/terminfo than with programs that just assumme a VT100.
There is some standard from xterm so that mouse clicks send escape sequences, so a program that wants them can turn them on.
The first patches were not really solutions, they simply tested if this exploit was being tried and did an abort(), which means that slight variations would still crash it. However I wonder how many closed-source patches are of this nature? Probably a lot of them!
I can't tell from the reports whether the underlying cause has been identified and fixed yet. It sounds like it, but I am unsure.
No, this new bug was discovered in exactly the same way such bugs are discovered on Windows. Open source did not make it any less secure in any way.
Here is the bug report. Please examine it and tell me where they looked at Linux source code to discover the exploit:
I'm on a vacation and doing some hobby project and came across a minor fault when using assembler inlines. Result is the my linux console totally freezes (Can't even CAD the console, but ALT SysRQ still works). This problem must be a race since it doesn't trigger when system is loaded, or processes is straced. I'm not able to update my versions for some weeks due to my vacation, so problems might be fixes. I find this both to be a bug in gcc, that again triggers a kernel bug.
I need confirmation if this is an issue with gcc here (looks like the frstor is off by 4 compared to the address fsave gets).
first reply:
It locks my computer yes, but when I compiled using -S flag and looked at the assembler output, the fsave and frstore is not given the same offset in the stackframe. fsave is -124(%ebp) while frstor is -128(%ebp).
last reply:
Thanks for the respons. Seems to be harder to get up the eyes of the kernel people, since the floating point exceptions inside that signal handler fucks up the current linux-kernels. Haven't got any respons from any of the kernel developers yet. A bit scary I think. But a big thanks to you atleast for given this some attention.
Erm. It certainly does make it easier to find vulnerabilities.
In this case the availability of source code made no difference in the discovery of the vulnerability. If you read the original report, somebody discovered this by accident, and for several weeks suspected that something was wrong with his gcc compiler, without it occuring to him that if the whole machine crashes he has discovered an exploit. He did not use the source code of Linux or of gcc or even of libc to discover this vulnerability. In fact from the comments, nobody has been able to figure out where the bug is, despite the demo code, which means it is virtually impossible that anybody could have discovered this by examining the Linux source code.
Yes if somebody can get arbitrary code to execute, they could execute this and thus crash the machine. However I still feel that if somebody can get arbitrary code to execute, they could instead give themselves a shell (from which they could execute this bug and many others), or execute much more destructive code such as deleting files.
It does seem the main threat is that even a total novice who has a shell account can probably figure out how to crash a machine. This is a threat to universities providing rlogin and some similar stuff, but probably not to a lot of servers.
Hackers who have secret shell access are not going to crash the machine. That would be stupid, they would probably lose whatever they did to get the secret shell access, and lose the ability to mess with the machine or to use it to get into other machines, or use it to spew spam.
This is really only a problem for a system that provides shell accounts (or another way to run arbitrary software) remotely to normal users. Such a system is pretty insecure anyway. You can easily run software on Linux that will eat all the process time and make it so difficult to kill the runaway process that the machine might as well have crashed.
On a serious note, if you read the article, you will see that the crash was discovered by accident, without looking at the source code. In fact it sounds to me like they still have not figured out what the crash is, the patches appear to be testing to see if the program is trying this exploit and aborting the program if so.
So in fact this bug was discovered in exactly the same way as a Windows bug is discovered. This really is a good demonstration that availablity of the source code probably does not make it any easier for a black-hat to find an exploit, in this case it made no difference at all. Supposedly the OSS advantage is that it will be fixed sooner, let's see. IMHO the exising patches are not a solution. However the existing patches (add an if to get around the bug) are probably the same as what a lot of closed-source distributes as a "fix".
I like nothing about the new window managers. The KDE/Gnome programs should run without them. I am trying to get my window manager flwm to work, but having no luck. It is too hard to change the window manager to your own and getting it to work with the new wm hints is difficult.
Windows is Win2000. Most of our Linux machines are RedHat7.2.
I believe the problem is that Windows really does not like our pattern of memory access. When the software allocates 1G it then rapidly accesses all that memory in a somewhat repeating pattern. Certainly the results are indicating that Windows is cycling the whole thing to swap, while Linux is managing to limit the swap to a small section, perhaps only 2x the overflow. This is for programs that go over 1G by only a 100-200 M. I'm sure as usage went to 2Gig both Linux and Windows would suck equally, of course we never try that.
Uh, no, something is seriously wrong with your program.
Once the program is running in a window, the desktop environment will have no effect on the actual running speed. Certainly not a 10-15 times speed decrease.
I suspect you have a bug in your program possibly with window size requests, I have seen this before. The window managers are sending different sequences of size change requests, and due to some bug your program is going into a busy loop sending resizes and redraws as fast as possible. For some reason the sequence of size change requests from twm is not triggering this.
Are you sure you are not going into swap? I suspect that areas where Linux is much better than Windows are hiding the problem somewhat.
Here we run at least 1G on all machines, so whether you are running Linux or Windows the only thing that gets us into swap is our own huge appliations, which are compiled from the exact same code. It is pretty obvious that when memory runs out on Windows the machine and our app is dead, and it will switch from taking 1 hour to complete to 9 or 10 hours. On Linux when running the same thing the difference between going into swap or not is to go from 1 hour to maybe 1.5 hours. (note this is Win2K and RedHat 7.2, things may be different in newer systems).
What this means is that hitting swap is not so obvious on Linux, thus it may be hiding the fact that it is doing so.
In my experience memory usage of Linux running a desktop is now greater than Windows. Gone are the days when it was as much as 10 times smaller (remember runing FVWM?). The only reason we can keep our memory usage by our graphics programs the same size is that Linux is much better behaved when free memory gets tight.
You are confusing the "too much software" problem with what is being discussed. A few hundred text editors does not slow down the system when you only run 1 or 0 of them.
However a system that has to start a few hundred "services" or parse a few thousand "resources" or otherwise be forced to do hundreds of actions to get to the point the user wants (ie at the login screen, logged in, or having their new program running) is going to be slow.
I reboot the SAME hardware between Windows 2000, Redhat 7.2 with KDE, and Redhat 9.2 with KDE. I can tell you Windows wins handily in getting to the login screen from reboot, perhaps 10 times faster! Windows and 7.2 KDE are about tied with logging in (who knows what Windows is doing, I think our systems guys have messed something up, but it is KDE startup that is the problem here). KDE 9.2 logs in MUCH faster, but I still consider it unacceptably slow (I also use OS/X and it about matches this and is unacceptable, too). Windows is slower than KDE 7.2 in launching a web browser (IE on Windows and Konqueror on Linux), but here it is bad: launching a web browser (Konqueror) on KDE 9.2 is MUCH MUCH slower, so much so that I am forced to leave it running, while the Redhat 7.2 and Windows I have no problem with closing it when not needed (yes they probably "cheat" there, but even the first startup is slower than the first startup of Konqueror on 7.2). Also Linux has all the X problems of flickering on resize and subtle jerky movement of windows and even the mouse cursor, and anybody who pretends those aren't there is in denial (and I believe the only way to fix this is to get rid of the window manager and make programs draw their own window borders, but nobody wants to listen to me...)
Slashdot Mirror
Sorry, you can't use my house for a party. You can't use your house, or any friends house. I have patented "having a party at a house" and will sue you for infringement if you dare try!
Yep, I was working in the software industry when the Mac came out, and the first thing my company did was make a game. They did this millipede ripoff in about 1 month, and if I remember right the major portion of the budget was spent on designing and printing the packaging. However it certainly used the mouse, and it would be difficult or impossible to duplicate Millipede so well on a mouse-less MSDOS machine.
You can try it on a Mac here: Mouse Stampede
Jason Linhart wrote the game, but I got the job of drawing most of the icons. I'm particularily proud of the swiss cheese, it's pretty hard to draw something legible in a 16x32 space in two colors!
If you already have a setup of hundreds of non-Mac machines running some clustering that doesn't work on Mac, you might be tempted to try replacing it with this code. It might work better, it might be nicer designed, it might be cheaper, or you might like it because it works on Macs or because the source is available. In any case there is a chance that you will like it and switch to it.
If you switch, you are suddenly in the position of being able to add Macintosh products to your cluster, and you may go out and buy some of those really fast Xserve boxes. And Apple makes money.
If Apple did not release this, or tried to sell it, you would most likely ignore it, be unable to add Macs to your cluster no matter how good they are, and Apple does not make money.
If the "old" functions are implemented by just changing the arguments and calling the "new" ones, then there is absolutely no problem with this. I suspect this is true in almost all cases.
The biggest problem is Microsoft's documentation refuses to reveal which functions are "old" and which ones are "new". Things ending in Ex are obviously "new" but there are also dozens of other functions that seem to have a whole set of parallel ways of getting done, and I have not been able to figure out from the documentation which is which. Window classes and DC's and some of WGL are what cause me the most pain, I have certainly wasted time trying different calls to discover that they all have exactly the same behavior underneath.
Recommendation to Microsoft, which I'm sure they will loathe: print some source code in your documentation. What I mean is documentation that says literally: functin foo() is obsolete and is implemented as "return fooEx(GetDC(blah),0,EXTRA_FLAG);"
If you read my response you would see that I am *NOT* using it, I am using "WIN32".
Classes are usually capitalized in C++, you know. When my documentation says "Window" it means the class, when it says "window" is means an instance of the class. It used to read something like "When using Windoze you need to make sure all Windows are declared before you can call the blah() method, and unfortunately X11 requires the exact opposite." You need to learn a little programming before you start saying anything about capitalization.
Now my documentation reads "When using WIN32 you need to make sure all Windows are declared before you can call the blah() method, and unfortunately X11 requires the exact opposite."
Great, you have just made your favorite os look as stupid with letters and numbers as X. You should be real proud of yourself.
This thinking is right up there with the "you can't call things master/slave" ruling. If you actually knew anything about computer science history you would see that creative mispellings are usaully an indication of affection (unless it is blatently obvious: calling it "WinBlows" is obvious hostility, and is pronouced with obvious hostility). As you pointed out "Windoze" is not pronouced differently and is thus only useful for text, just like the capitalization is a handy shortcut for classes. No duh, when speaking, I have to say "Windows OS", "Window class", and "window". That does not mean I should be unable to use a convienent shorthand when writing. Now of course I call it "win thirty two" when talking, just to piss people like you off.
Windows could be equally friendly if it popped up a box that said "Do you want to run the software that is on this disk now?" yes/no. In fact this would be better, as you could stick the disk in the drive and walk out while it is spinning up and not miss the autorun splash screen (which often tells you what the hell is happening).
As several other posters pointed out, Linux from RedHat also has "autorun". And the posters are complaining that this sucks and we should not be copying misfeatures from Windows.
It is f**king annoying that they chose a common word for the name for their system. I am working on GUI interface software and the fact that by default you cannot tell whether I am talking about the OS or the plural of an object that is used quite a bit in GUI makes documentation almost impossible unless a different word is chosen for the name of the OS. So for very professional reasons I used "Windoze" for many years, with no complaints from users Windows users. Then suddenly people started saying "oh using that word means you hate Microsoft" I had to switch, I now am forced to use "WIN32" to indicate the operating system (you use "#ifdef _WIN32" to detect it in C++ code, so I guess this is an officially sanctioned name). Thanks a lot for making my documentation look a lot worse and more geeky than it needs to be.
I consider it extremely annoying the political-correctness has forced me to obfuscate my own work, and am very annoyed at people with your attitude, and the sad fact that all fun and creativity is being sucked out of this field by people like you.
Don't be an idiot. There is no requirement that source code be provided with any software that runs on Linux. That is FUD straight from Bill Gates.
The malware will come, and it won't have source code, just like the original poster said.
All modern terminals and terminal emulators send something other than 127 for the Delete key, mine for instance sends ^[[3~. Therefore the behavior for this key is unchanged. The codes 127 and ^H are only sent by the key in the upper-right of the main keyboard that is usually marked "backspace", therefore both those codes should do backspace.
It would not even break emacs! Emacs puts the terminal in raw mode and thus it might need to be fixed seperately, but a change to the tty driver would make this work for all your command-line programs.
The delete/backspace thing is best fixed by having Unix machines treat *both* as backspace, so it does not matter which your terminal sends. Why this has not been fixed in Unix about 20 years ago is a mystery...
The VT100 codes are pretty "standard" and all terminal emulators use them, thus terminfo/termcap can pretty much be ignored. I have much more problems with programs that try to use termcap/terminfo than with programs that just assumme a VT100.
There is some standard from xterm so that mouse clicks send escape sequences, so a program that wants them can turn them on.
The first patches were not really solutions, they simply tested if this exploit was being tried and did an abort(), which means that slight variations would still crash it. However I wonder how many closed-source patches are of this nature? Probably a lot of them!
I can't tell from the reports whether the underlying cause has been identified and fixed yet. It sounds like it, but I am unsure.
No, this new bug was discovered in exactly the same way such bugs are discovered on Windows. Open source did not make it any less secure in any way.
Here is the bug report. Please examine it and tell me where they looked at Linux source code to discover the exploit:
I'm on a vacation and doing some hobby project and came across a minor fault
when using assembler inlines. Result is the my linux console totally freezes
(Can't even CAD the console, but ALT SysRQ still works). This problem must be a
race since it doesn't trigger when system is loaded, or processes is straced.
I'm not able to update my versions for some weeks due to my vacation, so
problems might be fixes. I find this both to be a bug in gcc, that again
triggers a kernel bug.
I need confirmation if this is an issue with gcc here (looks like the frstor is
off by 4 compared to the address fsave gets).
first reply:
It locks my computer yes, but when I compiled using -S flag and looked at the
assembler output, the fsave and frstore is not given the same offset in the
stackframe. fsave is -124(%ebp) while frstor is -128(%ebp).
last reply:
Thanks for the respons. Seems to be harder to get up the eyes of the kernel
people, since the floating point exceptions inside that signal handler fucks up
the current linux-kernels. Haven't got any respons from any of the kernel
developers yet. A bit scary I think. But a big thanks to you atleast for given
this some attention.
What city are you in? Was that a big earthquake?
In this case the availability of source code made no difference in the discovery of the vulnerability. If you read the original report, somebody discovered this by accident, and for several weeks suspected that something was wrong with his gcc compiler, without it occuring to him that if the whole machine crashes he has discovered an exploit. He did not use the source code of Linux or of gcc or even of libc to discover this vulnerability. In fact from the comments, nobody has been able to figure out where the bug is, despite the demo code, which means it is virtually impossible that anybody could have discovered this by examining the Linux source code.
Yes if somebody can get arbitrary code to execute, they could execute this and thus crash the machine. However I still feel that if somebody can get arbitrary code to execute, they could instead give themselves a shell (from which they could execute this bug and many others), or execute much more destructive code such as deleting files.
It does seem the main threat is that even a total novice who has a shell account can probably figure out how to crash a machine. This is a threat to universities providing rlogin and some similar stuff, but probably not to a lot of servers.
Hackers who have secret shell access are not going to crash the machine. That would be stupid, they would probably lose whatever they did to get the secret shell access, and lose the ability to mess with the machine or to use it to get into other machines, or use it to spew spam.
This is really only a problem for a system that provides shell accounts (or another way to run arbitrary software) remotely to normal users. Such a system is pretty insecure anyway. You can easily run software on Linux that will eat all the process time and make it so difficult to kill the runaway process that the machine might as well have crashed.
On a serious note, if you read the article, you will see that the crash was discovered by accident, without looking at the source code. In fact it sounds to me like they still have not figured out what the crash is, the patches appear to be testing to see if the program is trying this exploit and aborting the program if so.
So in fact this bug was discovered in exactly the same way as a Windows bug is discovered. This really is a good demonstration that availablity of the source code probably does not make it any easier for a black-hat to find an exploit, in this case it made no difference at all. Supposedly the OSS advantage is that it will be fixed sooner, let's see. IMHO the exising patches are not a solution. However the existing patches (add an if to get around the bug) are probably the same as what a lot of closed-source distributes as a "fix".
Did anybody notice the interface is identical to X selection and middle-mouse paste?
I like nothing about the new window managers. The KDE/Gnome programs should run without them. I am trying to get my window manager flwm to work, but having no luck. It is too hard to change the window manager to your own and getting it to work with the new wm hints is difficult.
Windows is Win2000. Most of our Linux machines are RedHat7.2.
I believe the problem is that Windows really does not like our pattern of memory access. When the software allocates 1G it then rapidly accesses all that memory in a somewhat repeating pattern. Certainly the results are indicating that Windows is cycling the whole thing to swap, while Linux is managing to limit the swap to a small section, perhaps only 2x the overflow. This is for programs that go over 1G by only a 100-200 M. I'm sure as usage went to 2Gig both Linux and Windows would suck equally, of course we never try that.
Uh, no, something is seriously wrong with your program.
Once the program is running in a window, the desktop environment will have no effect on the actual running speed. Certainly not a 10-15 times speed decrease.
I suspect you have a bug in your program possibly with window size requests, I have seen this before. The window managers are sending different sequences of size change requests, and due to some bug your program is going into a busy loop sending resizes and redraws as fast as possible. For some reason the sequence of size change requests from twm is not triggering this.
Are you sure you are not going into swap? I suspect that areas where Linux is much better than Windows are hiding the problem somewhat.
Here we run at least 1G on all machines, so whether you are running Linux or Windows the only thing that gets us into swap is our own huge appliations, which are compiled from the exact same code. It is pretty obvious that when memory runs out on Windows the machine and our app is dead, and it will switch from taking 1 hour to complete to 9 or 10 hours. On Linux when running the same thing the difference between going into swap or not is to go from 1 hour to maybe 1.5 hours. (note this is Win2K and RedHat 7.2, things may be different in newer systems).
What this means is that hitting swap is not so obvious on Linux, thus it may be hiding the fact that it is doing so.
In my experience memory usage of Linux running a desktop is now greater than Windows. Gone are the days when it was as much as 10 times smaller (remember runing FVWM?). The only reason we can keep our memory usage by our graphics programs the same size is that Linux is much better behaved when free memory gets tight.
You are confusing the "too much software" problem with what is being discussed. A few hundred text editors does not slow down the system when you only run 1 or 0 of them.
However a system that has to start a few hundred "services" or parse a few thousand "resources" or otherwise be forced to do hundreds of actions to get to the point the user wants (ie at the login screen, logged in, or having their new program running) is going to be slow.
I reboot the SAME hardware between Windows 2000, Redhat 7.2 with KDE, and Redhat 9.2 with KDE. I can tell you Windows wins handily in getting to the login screen from reboot, perhaps 10 times faster! Windows and 7.2 KDE are about tied with logging in (who knows what Windows is doing, I think our systems guys have messed something up, but it is KDE startup that is the problem here). KDE 9.2 logs in MUCH faster, but I still consider it unacceptably slow (I also use OS/X and it about matches this and is unacceptable, too). Windows is slower than KDE 7.2 in launching a web browser (IE on Windows and Konqueror on Linux), but here it is bad: launching a web browser (Konqueror) on KDE 9.2 is MUCH MUCH slower, so much so that I am forced to leave it running, while the Redhat 7.2 and Windows I have no problem with closing it when not needed (yes they probably "cheat" there, but even the first startup is slower than the first startup of Konqueror on 7.2). Also Linux has all the X problems of flickering on resize and subtle jerky movement of windows and even the mouse cursor, and anybody who pretends those aren't there is in denial (and I believe the only way to fix this is to get rid of the window manager and make programs draw their own window borders, but nobody wants to listen to me...)
. Window