I really am still amazed that somebody considers "M$" an insult. "Microsuck" is an insult. Big difference, I think. For one thing it is obvious that whoever typed that spent some time and did not abbreviate.
I will stand by my argument that "M$" is a useful non-ambiguous abbreviation. Is an MS useful for getting a job at M$? Does M$ have a facility in MS? M$ uses MS for measuring time?
You lose all credibility as soon as you use "M$". It's like calling Linux "Linsux"
No idiot, it would be like calling linux "£x" in some world where 90% of the people writing messages used that abbreviation.
Calling Linux "Linsux" is like calling M$ "Microsucks", which is obviously an insult because it is a waste of typing when the proper name could be written with less keystrokes.
Face it, "M$" is a very useful and quick abbreviation that is not ambiguous. The letters "MS" mean MANY things (try typing them into Wikipedia).
The original poster used abbreviations that are in very common use. "M$" is not an insult, it is a quick and easy identifier. The letters "MS" read as "Multiple Sclerosis" to a lot of people, including me. It also a female title, means "Master of Science", "Mississippi", "millisecond", and quite a few other things.
Also the letter 's' is pronounced "ess" which is phonetically very different than "soft", while the $ actually has some typographic similarity to both an s and a t and thus abbreviates the name quite well. I at least don't even notice this and read it out loud as "Microsoft" or "m-soft".
The poster used "MSN" because that is not ambiguous (at least Wikipedia goes right to MSN when you type it in), the fact that the letters "MSN" are literally spoken out loud, and those initials are used right in M$'s own advertising and web pages!
The reason to not click windows to the top is so you can refer to some information in the top window while typing into the lower one! This is so you can work without being a crazy multitasking genius who has some kind of short-term photographic memory. It also means that drag & drop is useful, yet another invention that reduces the amount of crazy work you have to do. It also means that you don't have to have tiled windows and thus you don't have to resize your user interface elements strangely just to work on them, which is also a good sign that you are not trying to be a crazy genius.
And before you say "oh but that is not user friendly", get your head out of the sand and realize...
This one I knew would happen. No matter how many times I try to explain that this has NOTHING to do with "user friendliness" (unlike point to type, which does) somebody thinks it cannot happen because it will confuse the user. Now think VERY VERY carefully, and imagine if a program did this:
if (event == MOUSE_CLICK)
raise_my_own_damn_window();
If you do not understand the above concept, then please understand that the result is EXACTLY the same user interface you get now. IT IS NOT DIFFERENT! It is not less or more user friendly. It is the same, and therefore there is no "user friendliness" argument about this. It simply is a way to make the window system better designed so that alternatives are *possible*.
I certainly agree that Plan 9 does things right. Unfortunatly I don't know much about 8 1/2 (or whatever the windowing system is now). I would not be suprised if they did it right. Certainly the gui should be controlled with a stream written with the exact same calls as you write to files and other systems. I somewhat disagree with their scheme where the windows create multiple streams, I would prefer window creation to be more of a graphics operation imbedded into a single stream, like how NeWS did it. But even without knowing any details I can be sure they did better than X.
I was comparing Unix to, say, RMS (Record Management System on VMS, not Stallman). There would never have been any distributed file systems or remote disks or any kind of new storage with that. The largest program in the system was pip, which was the only program that new how to read all the hundreds of possible types of file.
Actually, could you hand me a binary, so I can request source code from him?
I know you are joking, but the GPL would only require that the person giving you the binary provide you with the source code. The original author is not bound by the GPL (they did not agree to it, they only said others have to agree to it if they want to copy the code). And besides the orginal author did distribute the source code so fulfilled the GPL requirements anyway.
Actually versions of X before 11 had click-to-raise behavior, it was removed, and for very good reasons that everybody seems to have forgotten now.
The desired UI I want is "don't raise the window if they click on a button or try to move the cursor in a text field, but do raise it if they click anywhere else". I also want to eliminate the huge mess of communication between the appliation and the window system about which windows are "children" and so on by allowing the application to choose which windows to raise in response to a click, but that will not change the user-visible interface.
The problem with your idea is that the application now has to inform the window system of whether or not any part of the window is a "click to raise area". Furthermore, you suggest that perhaps the window management ideas should be changeable, maybe buttons should raise the window. So maybe the application has to inform the window manager about whether the area is a button or a text field. But then somebody is going to say that the ideal arrangment is to raise for 1-line text fields and not for 2-d text fields, and this may not have been planned for because nobody thought to give these different identifiers. And on and on like this. If you don't believe this, why not take a look at the horrible mess of ICCCM and FreeDesktop window manager hints that are being used now in a desperate attempt to keep window stacking working the way the programs want, all of this would be eliminated if the program could make it's own decisions.
The window system should be as stupid and simple as possible, just like the file system does not handle anything other that a block of bytes. The reason we have networked file systems yet are still able to use an api designed in 1970 is because those people in 1970 were smart and did not put crap into the api because of some desire to force "consistency" between the programs. And all the man years of wasted effort in trying to fix the window manager hints could be put into improving the graphics or the rendering speed or something much more important.
I am unsure why the idea that this has to be pushed into a low level is so common. There must be something very tempting about it, as you seem convinced by the idea. I think the basic problem is developers panic that the programmers will "cheat" and that they have to be forced to conform to their vision about how the system should work. This may because of a lack of confidence in whether their idea is a good one or not. But this idea is absolutly indefensible from a technical standpoint and it is amazing that otherwise intelligent software developers will argue for it.
malloc allocates pieces of the processes virtual address space to the program. All this fragmentation disappears when the program exits, so this is not exactly a problem with "the system being up for awhile". However similar problems exist in the kernel memory allocation and those problems do persist until the system is rebooted.
As far as malloc goes, I don't believe fragmentation really slows it down, it has algorithims for immediately identifying a block of sufficient size, and does not do a search. It may slow down freeing slightly. The real problem is that all the useful items end up spread over a much larger amount of virtual memory and thus uses a lot more of it. This means more swapping (further made painful as lots of those swapped pages are partially filled with pieces of free blocks), and it also means malloc may fail to allocate something because no free block is big enough and your program will crash. And it means inefficiency in loading stuff into cache memory.
The system has some advantage that the use of VM means that (in most cases) it does not need to fit an allocation request in one hole because it can split it up into seperate pages (exceptions are where hardware actually requires contiguous real memory addresses). Also it only works with pages so if swapping happens it does not waste time reading/writing the data in the holes. But as many pointed out, if the memory is not contiguous then it does not load into caches efficiently, as the modern caches are far larger than the pages.
I was about to say that you only need access to the webserver to be able to send the compromises to clients, but that probably would not be enough to install a rootkit. So it does sound like they have stolen root passwords, though it is possible a local exploit. Or the machines were setup with the webserver running as root?
Stolen password would be a vector into Apache servers on other platforms as well - but the reports so far seem to be saying it is just Apache + Linux servers.
That's because the rootkit is Linux-only. Duh.
The attackers are either only targeting Linux machines because they have a rootkit for them, or they are using different techniques on other machines so nobody has noticed that they are the same attackers.
By "application" I meant everything running in the process that is talking to the system. This includes libraries, like the toolkit code that would implement your suggestion of "have applications look at a common configuration, like gconf does". All I can imagine is that you read my word "application" as "code the final programmer is expected to write". Sorry about the confusion.
There is a very good reason why the gconf reading is done by the appliation (or the library the application calls, if you want). I suppose you could make a window server that read gconf and somehow tried to enforce everything it says onto the instructions it is told by the application, but that would be senseless. It would also be a nightmare as it would require programs to understand exactly how the system is responding to gconf in order to communicate with it. So it is vastly simplified by moving all the decisions to the application / libraries.
I think you can see that if the system clicks the windows to the top, your own suggestion to have gconf control it is impossible unless the system reads the gconf database. But if the system does not click to the top, then the gconf stuff can decide easily!
Like I expected, somebody questioned whether not raising windows is user friendly. That question is TOTALLY IRRELEVANT!
Hopefully I can give you a clue. Here is some sample code that GOES IN THE APPLICATION (ie this code is NOT in the operating system), and the result is EXACTLY the same as what the system does now, so there is no question whatsoever about whether it is more or less user-friendly:
if (event == MOUSE_CLICK) {
raise_my_own_damn_window();
}
I apologize for the complex and high-level concepts that are in the above code, but I trust you can figure it out:-)
Forward slashes have been supported since MSDOS 2.0, actually. And they work in UNC paths and everything else. The problem is not MSDOS/Windows itself. The problem is with the vast number of people (read some of the other responders here) that don't believe they work, or only work in a subset of the MSDOS api. This leads to them writing software that refuses to parse forward slashes or pass them correctly to the operating system.
Microsoft is also a bit to blame for spewing out backslashes in api's where there is no reason to do so. It should ONLY have been used in output printed to command.com.
The only reason for backslash is to run executables in different directories in command.com without having to break it's back-compatability with the CP/M command shell. "dir/w" is parsed by command.com to run the "dir" program out of the path and pass "/w" as part of the argv. You have to type "dir\w" if you want to run the program called "w" in subdirectory "dir".
2. Clicking in a window DID NOT RAISE IT!!!! You clicked in the title bar to raise it.
#2 is the real killer and why overlapping windows worked 20 years ago and don't work now. And it is not just Windows, all the X desktops and OS/X have this foul behavior. A few people seem to remember how good focus follows mouse is, but the ability to click and do something in a window behind the current one appears to be forgotten by everybody...
Until I can write a program that can assumme that the user can click without raising the window, I do consider the current systems to be behind what we had 20 years ago. So yes the GP is correct.
And before you say "oh but that is not user friendly", get your head out of the sand and realize: the program can *raise itself* after it decides whether or not the mouse click is one that can raise it! If you can't figure that out, you have no business trying to argue about anything here.
Except for "dragging" the initial item, this is the same actions as a pop up menu. Your Eve example is a pop up menu. And there are circular pop up menus, and menus drawn as lots of floating icons, and menus that don;t appear until you start to drag or you hesitate. Some of these are already patented, so not only is their prior art, there may be patent violations here!
Great reading comprehension there! He said "Since I turned off automatic Windows updates". Please note that despite not being capitalized there are the words "automatic" and "updates" there. I don't think that means "I'm running Linux". Far more likely it means "I'm running Windows but I turned off the automatic Windows updates".
Anyway on Linux Hibernate really is not working at all for me, perhaps 50% (though I use it because if it works great, and if it fails I can reboot). Sleep seems ok but sometimes the wireless does not come back and it seems the only way to fix it is to close the lid and sleep again, it certainly seems like something should be possible to force the wireless to reboot from a menu item. Oddly enough my iBook has the same problem, except turning wireless off/on works as well as sleep to get it going again. I don't think the blame can be put on lack of documentation. Lack of documentation would mean the thing would not work at all, not that it would randomly work and not work! I also think Linux can be blamed for the not-uncommon problem where stuff like sound works and then abrubtly stops working: I'm sorry but again I can't see how lack of documentation explains this!
Newer versions of Windows are also doing memory randomization. I don't think this is done by the kernel in either Linux or Windows, but applications (and bootup launches a lot of those) does.
Actually that is a good question. Microsoft has long fought dual-boot machines, originally this was used to kill off BeOS, and to force games to run under Windows (rather than dual-booting with a special gaming operating system, which was considered at that time to be a good idea).
Although it is reasonably easy to find a machine with Linux installed, it is quite impossible to find a dual-boot Windows+Linux preinstall, despite the fact that this is the most popular arrangement for running Linux on a desktop.
Is Microsoft still disallowing OEM's from making dual-boot machines? If this is still true then this idea is not going to go anywhere, as it obviously violates that agreement.
Newer operating systems equipped with digital rights management software (DRM) will extract the watermark from audio files prior to playing them on the system. The DRM software will ensure that the user has paid for the song by comparing the watermark to the existing purchased licences on the system.
Either the article writer or somebody who talked to him is an idiot. I'm not saying this won't happen, but that is NOT "watermarking" in any useful way. That is DRM.
If you make a device that refuses to play a song with the wrong watermark, you have provided everybody with a cheap and foolproof method of figuring out if their software has successfully removed the watermark. Watermarks will be stripped and their purpose is defeated.
The problem is that it is almost impossible to explain this to some of the clueless people who are managing these organizations. So I would not be suprised if such a watermark-stripping-detector showed up on the market. The watermark detecting program should be kept in top secrecy with very little access down in a vault in the RIAA or whoever is doing this. But they are idiots and won't do that and the managers there will dictate that the thing that should be top-secret be instead available for $30 at Best Buy.
And if your new iPod or Zune rejects corrupted watermarks?
No, that would make it easy to detect if you successfully removed the watermark (assumming the iPod/Zune will play a song without any watermark in it).
If the players only play correctly-watermarked data, that is equivalent to them only playing "signed" data. Well that is the RIAA wetdream, not only do you have working DRM, but you have also made it basically impossible for anybody other than "professionals" to produce content (since they will not have the license to sign their songs).
In the real watermarking scheme, every single byte is changed. Basically the entire thing is covered with a huge watermark that is noise, with randomly and sparsely distributed blocks of the actual watermark. So finding identical bytes does not work.
Averaging would seem to work but supposedly the algorithims can survive quite a lot of coverage with random noise. If the watermarks are sparse enough, all that averaging will do is make a result that has *all* the watermarks of the originals. What they do need to do is avoid having huge numbers of different watermarks, as I doubt it will survive tens of thousands of different samples being averaged. This is probably a reason there will not be per-user watermarks.
If they have any intelligence, the program that detects the watermark will be kept secret. Without a way to tell whether you have removed the watermark, it is impossible to tell if you have done so.
Of course the problem is that there are clueless people in power who will think they can use the watermark to make a device refuse to play "pirated" content. As soon as they do this, the watermark will become useless, because there is now a trivial method to detect if you have successfully removed the watermark. This I think is the most likely downfall of this scheme.
I think the api is Linux-specific. Guessing at some man pages perhaps shmget is the function. Fortunately it is all hidden behind malloc so programs don't have to worry about it.
sbrk/brk date from the very first versions of Unix and are just emulated atop that code.
No, on modern systems pages are allocated and returned to the system. They are 8K in size on most systems. If you free an object that completely covers a page, it is quite possible the malloc code will return it to the system (not guaranteed to be immediately, as there is significant overhead in doing such calls, but generally it eventually will be returned). This has an additional advantage that trying to reference the deleted object may produce a memory trap. In addition the brk you are talking about is also in pages as far as the system is concerned, the pointer a program sees is rouinded up to the next page boundary.
Slashdot Mirror
I really am still amazed that somebody considers "M$" an insult. "Microsuck" is an insult. Big difference, I think. For one thing it is obvious that whoever typed that spent some time and did not abbreviate.
I will stand by my argument that "M$" is a useful non-ambiguous abbreviation. Is an MS useful for getting a job at M$? Does M$ have a facility in MS? M$ uses MS for measuring time?
it would be like calling linux "£x" in some world where 90% of the people writing messages used that abbreviation.
By "world" you mean "extremely tiny group of basement dwellers," right?
No, stupid. By "some world" I meant a fictional world, so that I could apply an analogy to the real world.
You lose all credibility as soon as you use "M$". It's like calling Linux "Linsux"
No idiot, it would be like calling linux "£x" in some world where 90% of the people writing messages used that abbreviation.
Calling Linux "Linsux" is like calling M$ "Microsucks", which is obviously an insult because it is a waste of typing when the proper name could be written with less keystrokes.
Face it, "M$" is a very useful and quick abbreviation that is not ambiguous. The letters "MS" mean MANY things (try typing them into Wikipedia).
Why don't you grow up?
The original poster used abbreviations that are in very common use. "M$" is not an insult, it is a quick and easy identifier. The letters "MS" read as "Multiple Sclerosis" to a lot of people, including me. It also a female title, means "Master of Science", "Mississippi", "millisecond", and quite a few other things.
Also the letter 's' is pronounced "ess" which is phonetically very different than "soft", while the $ actually has some typographic similarity to both an s and a t and thus abbreviates the name quite well. I at least don't even notice this and read it out loud as "Microsoft" or "m-soft".
The poster used "MSN" because that is not ambiguous (at least Wikipedia goes right to MSN when you type it in), the fact that the letters "MSN" are literally spoken out loud, and those initials are used right in M$'s own advertising and web pages!
The reason to not click windows to the top is so you can refer to some information in the top window while typing into the lower one! This is so you can work without being a crazy multitasking genius who has some kind of short-term photographic memory. It also means that drag & drop is useful, yet another invention that reduces the amount of crazy work you have to do. It also means that you don't have to have tiled windows and thus you don't have to resize your user interface elements strangely just to work on them, which is also a good sign that you are not trying to be a crazy genius.
And before you say "oh but that is not user friendly", get your head out of the sand and realize...
This one I knew would happen. No matter how many times I try to explain that this has NOTHING to do with "user friendliness" (unlike point to type, which does) somebody thinks it cannot happen because it will confuse the user. Now think VERY VERY carefully, and imagine if a program did this:
if (event == MOUSE_CLICK)
raise_my_own_damn_window();
If you do not understand the above concept, then please understand that the result is EXACTLY the same user interface you get now. IT IS NOT DIFFERENT! It is not less or more user friendly. It is the same, and therefore there is no "user friendliness" argument about this. It simply is a way to make the window system better designed so that alternatives are *possible*.
I certainly agree that Plan 9 does things right. Unfortunatly I don't know much about 8 1/2 (or whatever the windowing system is now). I would not be suprised if they did it right. Certainly the gui should be controlled with a stream written with the exact same calls as you write to files and other systems. I somewhat disagree with their scheme where the windows create multiple streams, I would prefer window creation to be more of a graphics operation imbedded into a single stream, like how NeWS did it. But even without knowing any details I can be sure they did better than X.
I was comparing Unix to, say, RMS (Record Management System on VMS, not Stallman). There would never have been any distributed file systems or remote disks or any kind of new storage with that. The largest program in the system was pip, which was the only program that new how to read all the hundreds of possible types of file.
Actually, could you hand me a binary, so I can request source code from him?
I know you are joking, but the GPL would only require that the person giving you the binary provide you with the source code. The original author is not bound by the GPL (they did not agree to it, they only said others have to agree to it if they want to copy the code). And besides the orginal author did distribute the source code so fulfilled the GPL requirements anyway.
It's the wrong trousers, and they've gone wrong! Help!
Actually versions of X before 11 had click-to-raise behavior, it was removed, and for very good reasons that everybody seems to have forgotten now.
The desired UI I want is "don't raise the window if they click on a button or try to move the cursor in a text field, but do raise it if they click anywhere else". I also want to eliminate the huge mess of communication between the appliation and the window system about which windows are "children" and so on by allowing the application to choose which windows to raise in response to a click, but that will not change the user-visible interface.
The problem with your idea is that the application now has to inform the window system of whether or not any part of the window is a "click to raise area". Furthermore, you suggest that perhaps the window management ideas should be changeable, maybe buttons should raise the window. So maybe the application has to inform the window manager about whether the area is a button or a text field. But then somebody is going to say that the ideal arrangment is to raise for 1-line text fields and not for 2-d text fields, and this may not have been planned for because nobody thought to give these different identifiers. And on and on like this. If you don't believe this, why not take a look at the horrible mess of ICCCM and FreeDesktop window manager hints that are being used now in a desperate attempt to keep window stacking working the way the programs want, all of this would be eliminated if the program could make it's own decisions.
The window system should be as stupid and simple as possible, just like the file system does not handle anything other that a block of bytes. The reason we have networked file systems yet are still able to use an api designed in 1970 is because those people in 1970 were smart and did not put crap into the api because of some desire to force "consistency" between the programs. And all the man years of wasted effort in trying to fix the window manager hints could be put into improving the graphics or the rendering speed or something much more important.
I am unsure why the idea that this has to be pushed into a low level is so common. There must be something very tempting about it, as you seem convinced by the idea. I think the basic problem is developers panic that the programmers will "cheat" and that they have to be forced to conform to their vision about how the system should work. This may because of a lack of confidence in whether their idea is a good one or not. But this idea is absolutly indefensible from a technical standpoint and it is amazing that otherwise intelligent software developers will argue for it.
malloc allocates pieces of the processes virtual address space to the program. All this fragmentation disappears when the program exits, so this is not exactly a problem with "the system being up for awhile". However similar problems exist in the kernel memory allocation and those problems do persist until the system is rebooted.
As far as malloc goes, I don't believe fragmentation really slows it down, it has algorithims for immediately identifying a block of sufficient size, and does not do a search. It may slow down freeing slightly. The real problem is that all the useful items end up spread over a much larger amount of virtual memory and thus uses a lot more of it. This means more swapping (further made painful as lots of those swapped pages are partially filled with pieces of free blocks), and it also means malloc may fail to allocate something because no free block is big enough and your program will crash. And it means inefficiency in loading stuff into cache memory.
The system has some advantage that the use of VM means that (in most cases) it does not need to fit an allocation request in one hole because it can split it up into seperate pages (exceptions are where hardware actually requires contiguous real memory addresses). Also it only works with pages so if swapping happens it does not waste time reading/writing the data in the holes. But as many pointed out, if the memory is not contiguous then it does not load into caches efficiently, as the modern caches are far larger than the pages.
I was about to say that you only need access to the webserver to be able to send the compromises to clients, but that probably would not be enough to install a rootkit. So it does sound like they have stolen root passwords, though it is possible a local exploit. Or the machines were setup with the webserver running as root?
Stolen password would be a vector into Apache servers on other platforms as well - but the reports so far seem to be saying it is just Apache + Linux servers.
That's because the rootkit is Linux-only. Duh.
The attackers are either only targeting Linux machines because they have a rootkit for them, or they are using different techniques on other machines so nobody has noticed that they are the same attackers.
I am dumbfounded.
Let me try again.
By "application" I meant everything running in the process that is talking to the system. This includes libraries, like the toolkit code that would implement your suggestion of "have applications look at a common configuration, like gconf does". All I can imagine is that you read my word "application" as "code the final programmer is expected to write". Sorry about the confusion.
There is a very good reason why the gconf reading is done by the appliation (or the library the application calls, if you want). I suppose you could make a window server that read gconf and somehow tried to enforce everything it says onto the instructions it is told by the application, but that would be senseless. It would also be a nightmare as it would require programs to understand exactly how the system is responding to gconf in order to communicate with it. So it is vastly simplified by moving all the decisions to the application / libraries.
I think you can see that if the system clicks the windows to the top, your own suggestion to have gconf control it is impossible unless the system reads the gconf database. But if the system does not click to the top, then the gconf stuff can decide easily!
Like I expected, somebody questioned whether not raising windows is user friendly. That question is TOTALLY IRRELEVANT!
:-)
Hopefully I can give you a clue. Here is some sample code that GOES IN THE APPLICATION (ie this code is NOT in the operating system), and the result is EXACTLY the same as what the system does now, so there is no question whatsoever about whether it is more or less user-friendly:
if (event == MOUSE_CLICK) {
raise_my_own_damn_window();
}
I apologize for the complex and high-level concepts that are in the above code, but I trust you can figure it out
Forward slashes have been supported since MSDOS 2.0, actually. And they work in UNC paths and everything else. The problem is not MSDOS/Windows itself. The problem is with the vast number of people (read some of the other responders here) that don't believe they work, or only work in a subset of the MSDOS api. This leads to them writing software that refuses to parse forward slashes or pass them correctly to the operating system.
Microsoft is also a bit to blame for spewing out backslashes in api's where there is no reason to do so. It should ONLY have been used in output printed to command.com.
The only reason for backslash is to run executables in different directories in command.com without having to break it's back-compatability with the CP/M command shell. "dir/w" is parsed by command.com to run the "dir" program out of the path and pass "/w" as part of the argv. You have to type "dir\w" if you want to run the program called "w" in subdirectory "dir".
20 years ago we had X windows with (in twm):
1. focus follows mouse
2. Clicking in a window DID NOT RAISE IT!!!! You clicked in the title bar to raise it.
#2 is the real killer and why overlapping windows worked 20 years ago and don't work now. And it is not just Windows, all the X desktops and OS/X have this foul behavior. A few people seem to remember how good focus follows mouse is, but the ability to click and do something in a window behind the current one appears to be forgotten by everybody...
Until I can write a program that can assumme that the user can click without raising the window, I do consider the current systems to be behind what we had 20 years ago. So yes the GP is correct.
And before you say "oh but that is not user friendly", get your head out of the sand and realize: the program can *raise itself* after it decides whether or not the mouse click is one that can raise it! If you can't figure that out, you have no business trying to argue about anything here.
Except for "dragging" the initial item, this is the same actions as a pop up menu. Your Eve example is a pop up menu. And there are circular pop up menus, and menus drawn as lots of floating icons, and menus that don;t appear until you start to drag or you hesitate. Some of these are already patented, so not only is their prior art, there may be patent violations here!
Great reading comprehension there! He said "Since I turned off automatic Windows updates". Please note that despite not being capitalized there are the words "automatic" and "updates" there. I don't think that means "I'm running Linux". Far more likely it means "I'm running Windows but I turned off the automatic Windows updates".
Anyway on Linux Hibernate really is not working at all for me, perhaps 50% (though I use it because if it works great, and if it fails I can reboot). Sleep seems ok but sometimes the wireless does not come back and it seems the only way to fix it is to close the lid and sleep again, it certainly seems like something should be possible to force the wireless to reboot from a menu item. Oddly enough my iBook has the same problem, except turning wireless off/on works as well as sleep to get it going again. I don't think the blame can be put on lack of documentation. Lack of documentation would mean the thing would not work at all, not that it would randomly work and not work! I also think Linux can be blamed for the not-uncommon problem where stuff like sound works and then abrubtly stops working: I'm sorry but again I can't see how lack of documentation explains this!
Newer versions of Windows are also doing memory randomization. I don't think this is done by the kernel in either Linux or Windows, but applications (and bootup launches a lot of those) does.
Actually that is a good question. Microsoft has long fought dual-boot machines, originally this was used to kill off BeOS, and to force games to run under Windows (rather than dual-booting with a special gaming operating system, which was considered at that time to be a good idea).
Although it is reasonably easy to find a machine with Linux installed, it is quite impossible to find a dual-boot Windows+Linux preinstall, despite the fact that this is the most popular arrangement for running Linux on a desktop.
Is Microsoft still disallowing OEM's from making dual-boot machines? If this is still true then this idea is not going to go anywhere, as it obviously violates that agreement.
Newer operating systems equipped with digital rights management software (DRM) will extract the watermark from audio files prior to playing them on the system. The DRM software will ensure that the user has paid for the song by comparing the watermark to the existing purchased licences on the system.
Either the article writer or somebody who talked to him is an idiot. I'm not saying this won't happen, but that is NOT "watermarking" in any useful way. That is DRM.
If you make a device that refuses to play a song with the wrong watermark, you have provided everybody with a cheap and foolproof method of figuring out if their software has successfully removed the watermark. Watermarks will be stripped and their purpose is defeated.
The problem is that it is almost impossible to explain this to some of the clueless people who are managing these organizations. So I would not be suprised if such a watermark-stripping-detector showed up on the market. The watermark detecting program should be kept in top secrecy with very little access down in a vault in the RIAA or whoever is doing this. But they are idiots and won't do that and the managers there will dictate that the thing that should be top-secret be instead available for $30 at Best Buy.
And if your new iPod or Zune rejects corrupted watermarks?
No, that would make it easy to detect if you successfully removed the watermark (assumming the iPod/Zune will play a song without any watermark in it).
If the players only play correctly-watermarked data, that is equivalent to them only playing "signed" data. Well that is the RIAA wetdream, not only do you have working DRM, but you have also made it basically impossible for anybody other than "professionals" to produce content (since they will not have the license to sign their songs).
In the real watermarking scheme, every single byte is changed. Basically the entire thing is covered with a huge watermark that is noise, with randomly and sparsely distributed blocks of the actual watermark. So finding identical bytes does not work.
Averaging would seem to work but supposedly the algorithims can survive quite a lot of coverage with random noise. If the watermarks are sparse enough, all that averaging will do is make a result that has *all* the watermarks of the originals. What they do need to do is avoid having huge numbers of different watermarks, as I doubt it will survive tens of thousands of different samples being averaged. This is probably a reason there will not be per-user watermarks.
You are assumming the watermark can be seen.
If they have any intelligence, the program that detects the watermark will be kept secret. Without a way to tell whether you have removed the watermark, it is impossible to tell if you have done so.
Of course the problem is that there are clueless people in power who will think they can use the watermark to make a device refuse to play "pirated" content. As soon as they do this, the watermark will become useless, because there is now a trivial method to detect if you have successfully removed the watermark. This I think is the most likely downfall of this scheme.
I think the api is Linux-specific. Guessing at some man pages perhaps shmget is the function. Fortunately it is all hidden behind malloc so programs don't have to worry about it.
sbrk/brk date from the very first versions of Unix and are just emulated atop that code.
No, on modern systems pages are allocated and returned to the system. They are 8K in size on most systems. If you free an object that completely covers a page, it is quite possible the malloc code will return it to the system (not guaranteed to be immediately, as there is significant overhead in doing such calls, but generally it eventually will be returned). This has an additional advantage that trying to reference the deleted object may produce a memory trap. In addition the brk you are talking about is also in pages as far as the system is concerned, the pointer a program sees is rouinded up to the next page boundary.