True, having the right complexity class is more important than a constant factor of 10. But if you have two algorithms with the same complexity class, there can be a practical difference. And there are also some theoretical measures that would make sense such as the number of comparisons. However if you take that measure, I believe mergesort has been proven to be less than a factor of 10 from optimal. So the only way to beat mergesort by a factor of 10 would be something which is not a comparison sorting algorithm, and thus something that only works in cases where the keys have a special structure. Beating mergesort by a factor of 10 in the general case is just not possible. BTW when doing a mergesort of a linked lists, you can do some neat optimizations that improve the best case complexity in cases where large parts of the input are already sorted - of course this have a small additional cost in the average case.
16-bit support was dropped when 64-bit support was added
Not completely. The 64 bit CPUs are fully backward compatible. Some of the 16 bit support was dropped from the 64 bit mode. But the CPU still starts up in 16 bit mode, and much of the BIOS is 16 bit code. From there you can switch to 32 bit mode and only then can you switch to 64 bit mode. Once you are in 64 bit mode a few features are missing, you don't have any virtual 86 mode, and segmentation doesn't apply to 64 bit code. You can still run 32 bit code with the ordinary segmentation, and I even think you can run 16 bit code as long as you intend to run it in protected mode.
Works fine even on a live filesystem if it's the journaling type.
you shouldn't rely on that. You are not reading it atomically. Data can change while you are reading the drive. The image you end up with could be in an inconsistent state. If you take the image and write it back to disk, I would expect the file system driver to replay the journal on the first mount and mark the file system clean. But just because the file system driver flips a flag to say the file system is good doesn't mean it has fixed the inconsistencies it does not know about.
How likely is it to go wrong? I cannot give you the numbers, but obviously the more write activity is going on while creating the image, the higher probability. I'd force a full fsck of the file system after restoring and be prepared to handle loss of a few files. I'd much rather use tar to make a backup by reading through the file system. Of course you can also choose to make seperate full backups in each way.
Some people have suggested, that you can use LVM to make a snapshot of a live file system atomically. I haven't tried it, but it should work, unless there is a kernel bug. Of course I have heard of nasty kernel bugs, such as some kernel versions where directly reading the device could corrupt the file system. (In which case it will be nice to have a backup).
a RAID with a failed disk is less reliable than a normal drive, since at that point any failure of one of the several remaining disks
True if you are talking about RAID 5. If you are running RAID 0 on top of RAID 1, then it is not that bad. Two disk failures would only cause data loss if they happened to be the mirrors of each other. Still if you are one disk down, you still have both the risk of its mirror to fail and the risk of another pair having a double fault. So the risk is slightly higher than a single disk fault, but not much since the double fault isn't highly likely in the first place. (This construction makes most sense when you care about write performance, if you don't care about write performance you might be better off using RAID 6).
Sounds to me like what you are asking for is a RAID controller. But I can't really see the point in building that into the disk. Having them seperate give you a lot more flexibility to choose what kind of RAID you want.
I'm currently using KDE and am tired of the hidden and undocumented configuration settings but even with that it's better than guhnome.
The main reason I'm using KDE is, that I can configure the window manager to behave exactly the way I want it. And it wasn't all that difficult to find the options I needed to change in kcontrol, but I'm a little disappointed with Fedora making the Gnome configuration tools that much easier to find in the menus than kcontrol. Are there useful undocumented configuration options I should know about as well?
What's the right answer to this question, and why?
Part of the answer is, that if you do sign it, you are putting yourself in a situation, where you are vulnurable to collision in the hash function you are using, even if the hash function is resistant against all other kinds of attack. So if you are using MD5, and you would sign such a message without considering the weakness of MD5 every time you sign something, you'd better not use MD5 at all.
There are two things you can do mitigate the risk. You can avoid using a hash, which is known to be weak. And you can avoid signing something you didn't generate yourself. If I was in the situation described, I might generate another postscript file myself with the original text and sign that instead. Of course if I was signing not the postscript file alone, but a complete email with the postscript file as an attachment, I would be less vulnurable.
Of course I should also check if the mail they send was signed. If they had signed a mail with the postscript file attached, that could be a proof of them trying to commit fraud. But if that mail was not signed, there would not be evidence showing who was trying to commit fraud.
How real is this risk?
The MD5 collision, and the pair of postscript files are very real. You can find the postscript files on the net, and it is easy to use the collision from those files to create a new pair of postscript files with different texts, even without understanding how the original MD5 collision was found.
But I guess people rarely sign a postscript file by itself. More often people sign an email, and it usually starts with some headers, which the attacker could have a hard time guessing. But someone might be able to pull that off as well. To know how large the risk is, you'd have to consider how the exact bytesequence being hashed was generated. Thus now in every case where MD5 is being used, there would be a need for a proof showing, that it would not be vulnurable.
Last time I checked Lovecraft wrote fiction. And crappy fiction, at that.
Do you feel better off knowing that? (That might actually be the point the GP was trying to make). Didn't read any Lovecraft myself though, don't know what I'm missing.
I wonder why a comment with two thirds of misinformation gets rated Informative.
There are actually several SHA-1 replacements out there, including SHA-224, SHA-256, SHA-384, and SHA-512.
True.
None cracked yet.
Also true AFAIK. I have not heard of anyone breaking those. But I must admit, I don't know if the weaknesses found ind SHA-1 applies to other variants of SHA as well.
And for just creating a signature-bound digest of a text that is then acted upon by a more secure scheme, like 2048 bit RSA, SHA-1 is still fine. An attacker in that case would generally need the private RSA key to just get to the point he could start cracking the SHA1 digest:).
You are completely mistaken about this part. A chain is not stronger than the weakest link. If you do signatures using SHA-1 and RSA, only one of the two has to be broken to forge a signature. When you sign a message, you put a signature on the output of the hash. If anybody can find another message with the same hash, they can simply put together your signature with the other message, and it will be a valid signature on a message you had never seen.
What could save you is the fact that there are different degrees of brokenness for a hash function. There are three kinds of common attacks to attempt on a hash function. The easiest one is to just generate a collision where you get to choose both messages. Next comes the problem of generating a collision where you are given one of the messages. Finally the hardest case is to be given a hash value and having to generate a message with that hash without having already an example of how to reach that hash value.
For MD5 an actual collision has been found, but still now algorithm to find a collision with an arbitrary message. For SHA1 there is AFAIK only demonstrated weaknesses. I have yet to see an actual SHA1 collision.
For signatures it might not be considered enough to just find a collision, after all you have to match the hash of a message, which was already signed. But even though you might feel secure, there are some things to worry about. First of all, once a technique to find collisions have been found, it only takes a little extra work to generate meaningful collisions. This is obvious to people with sufficient knowledge of the field, but a wouldn't believe this until it was actually demonstrated. With MD5 it has been demonstrated how to take two arbitrary plaintext files and from those generating two postscript files containing the two different texts but the same hash. Postscript was obviously chosen because the format contains a Turing complete language and thus was an easy target. But even simpler formats might be targeted with some additional work.
Consider the following scenario you send a signed email to somebody. You receive a reply saying something like "thank you for your email, but we need the signature on a postscript version, could you please sign the attached file?", and you find attached a postscript file containing the exact text you originally wrote. Would you sign that postscript file?
I wonder if the watermark could be tampered artificially enough to make the source unidentifiable?
I think (but I don't have a hard proof of this), that given just a single watermarked encoded and not the original uncompressed video, it would be impossible to remove enough traces of the watermark to make it unrecoverable without completely destroying the quality. The reason I think this is, that in those places where the watermark has improved the quality, there is still happeneing a rounding, and when somebody want to remove the watermark, they don't know in which direction the rounding was in the two cases. This will in most cases leave you with two possibilities for the unimproved value. And you cannot guess which of the two it was. Even if you add random noise, it has to be so much that the copyright holder, who knows which positions to look for, cannot see a statistical bias away from the original.
Assuming you had two watermarked copies, you could choose the unimproved value in most cases except from those few, where both watermarks had improved the same positions. Those positions might be enough to still figure out what the original watermarks were. But as you take more and more different watermarks, you will be able to remove more of the watermark. I don't know where the limit is going to be, but I'm pretty sure 40 versions is going to be enough to remove all traces of the watermark from my scheme. (And I find it hard to imagine any watermarking scheme, that could still preserve the watermark if you combined that many versions, though maybe the combination have to be more soffisticated than simply an average).
At some point I did a scetch of a somewhat similar idea in some net forum. Though I would not remove bits, rather I'd do an encoding with slightly increased quality in a few random places. (That way I would hope to prevent people bitching about reduced quality). And how much the watermarking costs in terms of extra space could be computed exactly. I haven't done any calculations on the extra space, but I would expect a few KB for a full movie.
To explain what my idea was I'll first give a short reminder of how jpeg works. Blocks of image data are transformed using something based on fourier transformations. The resulting coefficients are then rounded to different scales. For high frequency components a scale with larger steps can be used as errors in these components are not easilly noticed. There is a table of standard steps to be used for each combination of horisontal and vertical frequency. (I left out the part about how to handle colour components, which is not relevant for the following idea).
Making a minor change to one of the step sizes is not going to cause a major difference in the size of the compression or the quality. By picking some of the entries at random and reducing the step size you are going to increase the quality of random parts of the picture. Now what I want to do is to make a redundant encoding of a signature on the text from the watermark and use those bits to choose places to increase the quality. The signed text itself is included in the begining of the file.
First of all removing the signature would means you couldn't compute the step sizes, and thus you couldn't correctly decode the file. And if the file was reencoded, you might still be able to extract the watermark by comparing with the original uncompressed movie. You would just have to find enough of the places where quality was increased. (And enough is a lot less than all of them).
The signature used in the encoding should be performed using the buyer's private key. In addition to this, I would sign the entire encoded movie using the seller's private key to be able to detect if a file is corrupted (as a service for the users). The part about the user signing something could be replaced with just using a hash of the text, but that might weaken the proof of origin of a particular movie a bit.
Now all of this could be combined with features to prevent users from accidentially losing a copy to a cracker/pirate. Since this is not intended to prevent users from intentionally copying the file, it could be a lot better and less intrusive than DRM.
This is also true of any Java phone, which has perhaps the best security model in any shipping operating system today. The whole idea that buggy apps can trash your phone is bizarre.
I'd say that is the way it should be. But there can be bugs in the JVM causing it to crash on bad code or be exploitable by malicious software. I haven't owned a phone with a JVM, so I can't say too much about the quality of those. But even much simpler phones have had bugs causing them to misbehave, crash, or reboot in some situations.
I'd like the even of a phone crashing or misbehaving in any way to be so unusual that we think of it as a bizzare event when it happens. But unfortunately it seems most vendors focus more on adding features than providing a good implementation of the existing set of features.
It says something about using FreeNet, Tor, and PGP. Last time I checked none of these were wiki software packages.
It also says something about modified versions. It also says something about wikipedia, maybe they are using that software as well. So here follows a few quick questions and answers. Can this set of software be used as basis for an anonymous uncensorable wiki? Yes. How much work would it be to implement? Probably a lot. Is this particular implementation real or varpor ware? I don't know.
I had a similar idea myself, but it never became more than an idea. To make this uncensorable, it would have to not be hosted on one centralised server, but rather have the data replicated in a P2P network. This is pretty much the idea in FreeNet. You'd have to download a piece of software to actually access the system. This program would have to talk some special protocol with the other peers. To make it accessible to the average user, it would then provide a webserver, that you could use through a portnumber on localhost. I think FreeNet already has something like that. But rather than transfering html documents over the P2P network, you could use the P2P network to create some kind of database, and simply run wikipedia on top of that.
I say Wikipedia here, because that is what I thought this particular project had in mind. The idea I had in mind would have been using a different layer on top, something similar to worldforum.dk where you can put a small piece of javascript in your bookmarks and using that start a discussion thread about an arbitrary web page. (Worldforum sucks because it never reached a critical mass, and in spite of that performance sucks as well, and these days there are more spam than content, but that's besides the point, all three are issues that might be solvable).
Now to help on credibility of such a system where anybody can post anonymously, it should be possible for you to prove that two messages written by you were in fact written by the same person. Of course that proof also has to be something that you can give anonymously. It should work in such a way, that initially when you write something, you are completely anonymous. But at a later point if you choose to do so, you can prove that two messages have the same author. With clever cryptography it could probably even be done in such a way, that you can either give a proof that anybody can verify, or you can decide to do a proof that only one particular person can verify. (That last part can be done by designing the proof in such a way using that person's private key, it would be possible to forge the proof. Since this person know he generated the private key himself and didn't give it to anybody, he knows that the proof cannot be a forgery.)
That way if somebody doubt your credibility, you can show which information you provided earlier. This needs to encorporate a time stamping mechanism as well. Such that it can be verified that you did in fact provide the information before it became public knowledge. And if somebody copy other peoples information claiming to be the original source, it can be verified who posted the information first.
...this is probably going to screw up all those bot-nets.
Why? A good botnet shouldn't rely on the clock of the bots. In fact it relies on the bots being machines with clueless administrators. So it would rely on as little as possible of the setup of the machine it is running on. It is not like the local clock is the best or only way to know what time it is, and botnet could work even without knowing what time it is.
neither TCP nor IP have time information in the headers
I think they do. I don't know exactly how it works, but netcraft use it to report the uptime of servers. There is also a feature in nmap which does something similar, though it doesn't seem very reliable to me.
But this whole thing seems unrealistic anyway simply because you don't know which machine to be monitoring, and you can't be monitoring every machine on the internet.
That's like saying if it weren't for car thieves necessitating keys and alarm systems, then the price of cars would only be the cost of the materials that go into it.
If I was going to buy a car, it would be in my best interest to have a good lock on the car. If I was going to buy an operating system, it would not be in my best interest to have loads of artificial restrictions in the operating system.
People always asks about the chicken and the egg. I have known for years, that the egg came before the chicken. It is quite obvious, when you think about it. Egg laying creatures have existed long before the chicken, one of them slowly evolved into the chicken. When the first chicken saw the light of day, it came from an egg, and so did its ancestors for generations.
I agree with everything you said except from the actual numbers. I guess they are probably random numbers picked to show the point but still...
Maybe at 120 cars a minute
If you have 120 cars per minute, they are most likely driving too close. The adviced distance between cars to avoid collisions is minimum two seconds (may even be a law in some places). Which means you will always have less than 30 cars per minute per lane. So with 120 cars per minute you will either have at least five lanes, or cars driving too close.
There is nothing wrong with X. The primary reason not to use X applications under Mac OS X is the fact that Mac OS X uses a different graphical system. It is exactly the same as using with using X applications with Windows. The native user interface is a different one. There exist an aqua program, that implements an X server, but using X applications that way is never going to work as good as on a system using it natively.
What Apple should have done was to develop an X server for their hardware, and extent it with the necesarry features to do cool graphical things. I don't know if something fairly standard like Open GL would have been sufficient, or if more is needed. But X is extensible, so they could have done this.
On top of this X server, they should then have implemented an XDM with the look and feel they wanted (a typical Linux distribution come with three implementations, there is no reason why Mac OS X couldn't have included an entirely different or (gosh) given the user a choice). Of course the login screen is just a minor detail. What they also should have done was to implement Aqua as a windowmanager/desktop environment on top of X.
I'm not suggesting the look and feel should have been any different from what it actually is - just that it should have been implemented in the way such a thing is intended to be done on top of X. As long as you only use aqua applications, you wouldn't notice a difference. But if you were to combine aqua and X applications, you'd see it working a lot better. First of all, aqua could actually know which windows belongs to which programs, and not just see the all as being one application called X. Another advantage is, that if you liked to, you could actually install another environment like KDE and from the login screen choose which one you wanted to use today. And you would be able to use aqua applications under KDE. If Apple had done this right, the majority of the users would never have noticed, that OpenOffice was a native X application and not an aqua application.
I guess I actually agree with you. I'm just trying to explain, that it is not the users disliking X applications for no good reason. It is actually Apple, who decided to make X applications second class by design. Why did Apple do it this way? The only explanation I can think of is that this way it would be a little less work to implement aqua. Of course choosing to save time on implementation did mean the result was not as good as it could have been. Having worked with Mac OS X as well as Windows, I like Mac OS X better. Still aqua is not as nice to work with as KDE. Aqua could have beaten the user experience of KDE, if Apple had decided to do it right and implement aqua as an X server and a window manager.
Re:package manager need tons of work
on
Fedora Linux
·
· Score: 1
Thank you, I'm going to bookmark your post and try it out on my next opportunity. The fifth thing I asked for was something similar to "rpm --queryformat", which is very convenient in scripts.
Re:package manager need tons of work
on
Fedora Linux
·
· Score: 1
However, it's very feature deficient when compared to apt
One of the things that have kept me from moving from Fedora to an apt based distribution is the fact, that there are tasks I know how to acomplish with rpm, but don't know how to do with apt. Maybe you can help me one step closer to switching, by explaining how I do the following taskks with apt.
Find out which package a particular file came from
Get a list of the files which came from a particular package installed on my system
Given a.deb file get a list of files it will install on my system
Get a list of all installed packages with names matching an expression
Get a list of selected properties of a set of packages in a format I can define on the command line
Verify the signature on a.deb file
Verify if some files on my system are those originally installed by a package or if they have been modified.
Extract the files from a.deb package without installing it
Slashdot Mirror
True, having the right complexity class is more important than a constant factor of 10. But if you have two algorithms with the same complexity class, there can be a practical difference. And there are also some theoretical measures that would make sense such as the number of comparisons. However if you take that measure, I believe mergesort has been proven to be less than a factor of 10 from optimal. So the only way to beat mergesort by a factor of 10 would be something which is not a comparison sorting algorithm, and thus something that only works in cases where the keys have a special structure. Beating mergesort by a factor of 10 in the general case is just not possible. BTW when doing a mergesort of a linked lists, you can do some neat optimizations that improve the best case complexity in cases where large parts of the input are already sorted - of course this have a small additional cost in the average case.
How likely is it to go wrong? I cannot give you the numbers, but obviously the more write activity is going on while creating the image, the higher probability. I'd force a full fsck of the file system after restoring and be prepared to handle loss of a few files. I'd much rather use tar to make a backup by reading through the file system. Of course you can also choose to make seperate full backups in each way.
Some people have suggested, that you can use LVM to make a snapshot of a live file system atomically. I haven't tried it, but it should work, unless there is a kernel bug. Of course I have heard of nasty kernel bugs, such as some kernel versions where directly reading the device could corrupt the file system. (In which case it will be nice to have a backup).
Sounds to me like what you are asking for is a RAID controller. But I can't really see the point in building that into the disk. Having them seperate give you a lot more flexibility to choose what kind of RAID you want.
There are two things you can do mitigate the risk. You can avoid using a hash, which is known to be weak. And you can avoid signing something you didn't generate yourself. If I was in the situation described, I might generate another postscript file myself with the original text and sign that instead. Of course if I was signing not the postscript file alone, but a complete email with the postscript file as an attachment, I would be less vulnurable.
Of course I should also check if the mail they send was signed. If they had signed a mail with the postscript file attached, that could be a proof of them trying to commit fraud. But if that mail was not signed, there would not be evidence showing who was trying to commit fraud.
The MD5 collision, and the pair of postscript files are very real. You can find the postscript files on the net, and it is easy to use the collision from those files to create a new pair of postscript files with different texts, even without understanding how the original MD5 collision was found.
But I guess people rarely sign a postscript file by itself. More often people sign an email, and it usually starts with some headers, which the attacker could have a hard time guessing. But someone might be able to pull that off as well. To know how large the risk is, you'd have to consider how the exact bytesequence being hashed was generated. Thus now in every case where MD5 is being used, there would be a need for a proof showing, that it would not be vulnurable.
True.
Also true AFAIK. I have not heard of anyone breaking those. But I must admit, I don't know if the weaknesses found ind SHA-1 applies to other variants of SHA as well.
You are completely mistaken about this part. A chain is not stronger than the weakest link. If you do signatures using SHA-1 and RSA, only one of the two has to be broken to forge a signature. When you sign a message, you put a signature on the output of the hash. If anybody can find another message with the same hash, they can simply put together your signature with the other message, and it will be a valid signature on a message you had never seen.
What could save you is the fact that there are different degrees of brokenness for a hash function. There are three kinds of common attacks to attempt on a hash function. The easiest one is to just generate a collision where you get to choose both messages. Next comes the problem of generating a collision where you are given one of the messages. Finally the hardest case is to be given a hash value and having to generate a message with that hash without having already an example of how to reach that hash value.
For MD5 an actual collision has been found, but still now algorithm to find a collision with an arbitrary message. For SHA1 there is AFAIK only demonstrated weaknesses. I have yet to see an actual SHA1 collision.
For signatures it might not be considered enough to just find a collision, after all you have to match the hash of a message, which was already signed. But even though you might feel secure, there are some things to worry about. First of all, once a technique to find collisions have been found, it only takes a little extra work to generate meaningful collisions. This is obvious to people with sufficient knowledge of the field, but a wouldn't believe this until it was actually demonstrated. With MD5 it has been demonstrated how to take two arbitrary plaintext files and from those generating two postscript files containing the two different texts but the same hash. Postscript was obviously chosen because the format contains a Turing complete language and thus was an easy target. But even simpler formats might be targeted with some additional work.
Consider the following scenario you send a signed email to somebody. You receive a reply saying something like "thank you for your email, but we need the signature on a postscript version, could you please sign the attached file?", and you find attached a postscript file containing the exact text you originally wrote. Would you sign that postscript file?
Assuming you had two watermarked copies, you could choose the unimproved value in most cases except from those few, where both watermarks had improved the same positions. Those positions might be enough to still figure out what the original watermarks were. But as you take more and more different watermarks, you will be able to remove more of the watermark. I don't know where the limit is going to be, but I'm pretty sure 40 versions is going to be enough to remove all traces of the watermark from my scheme. (And I find it hard to imagine any watermarking scheme, that could still preserve the watermark if you combined that many versions, though maybe the combination have to be more soffisticated than simply an average).
At some point I did a scetch of a somewhat similar idea in some net forum. Though I would not remove bits, rather I'd do an encoding with slightly increased quality in a few random places. (That way I would hope to prevent people bitching about reduced quality). And how much the watermarking costs in terms of extra space could be computed exactly. I haven't done any calculations on the extra space, but I would expect a few KB for a full movie.
To explain what my idea was I'll first give a short reminder of how jpeg works. Blocks of image data are transformed using something based on fourier transformations. The resulting coefficients are then rounded to different scales. For high frequency components a scale with larger steps can be used as errors in these components are not easilly noticed. There is a table of standard steps to be used for each combination of horisontal and vertical frequency. (I left out the part about how to handle colour components, which is not relevant for the following idea).
Making a minor change to one of the step sizes is not going to cause a major difference in the size of the compression or the quality. By picking some of the entries at random and reducing the step size you are going to increase the quality of random parts of the picture. Now what I want to do is to make a redundant encoding of a signature on the text from the watermark and use those bits to choose places to increase the quality. The signed text itself is included in the begining of the file.
First of all removing the signature would means you couldn't compute the step sizes, and thus you couldn't correctly decode the file. And if the file was reencoded, you might still be able to extract the watermark by comparing with the original uncompressed movie. You would just have to find enough of the places where quality was increased. (And enough is a lot less than all of them).
The signature used in the encoding should be performed using the buyer's private key. In addition to this, I would sign the entire encoded movie using the seller's private key to be able to detect if a file is corrupted (as a service for the users). The part about the user signing something could be replaced with just using a hash of the text, but that might weaken the proof of origin of a particular movie a bit.
Now all of this could be combined with features to prevent users from accidentially losing a copy to a cracker/pirate. Since this is not intended to prevent users from intentionally copying the file, it could be a lot better and less intrusive than DRM.
I'd like the even of a phone crashing or misbehaving in any way to be so unusual that we think of it as a bizzare event when it happens. But unfortunately it seems most vendors focus more on adding features than providing a good implementation of the existing set of features.
I had a similar idea myself, but it never became more than an idea. To make this uncensorable, it would have to not be hosted on one centralised server, but rather have the data replicated in a P2P network. This is pretty much the idea in FreeNet. You'd have to download a piece of software to actually access the system. This program would have to talk some special protocol with the other peers. To make it accessible to the average user, it would then provide a webserver, that you could use through a portnumber on localhost. I think FreeNet already has something like that. But rather than transfering html documents over the P2P network, you could use the P2P network to create some kind of database, and simply run wikipedia on top of that.
I say Wikipedia here, because that is what I thought this particular project had in mind. The idea I had in mind would have been using a different layer on top, something similar to worldforum.dk where you can put a small piece of javascript in your bookmarks and using that start a discussion thread about an arbitrary web page. (Worldforum sucks because it never reached a critical mass, and in spite of that performance sucks as well, and these days there are more spam than content, but that's besides the point, all three are issues that might be solvable).
Now to help on credibility of such a system where anybody can post anonymously, it should be possible for you to prove that two messages written by you were in fact written by the same person. Of course that proof also has to be something that you can give anonymously. It should work in such a way, that initially when you write something, you are completely anonymous. But at a later point if you choose to do so, you can prove that two messages have the same author. With clever cryptography it could probably even be done in such a way, that you can either give a proof that anybody can verify, or you can decide to do a proof that only one particular person can verify. (That last part can be done by designing the proof in such a way using that person's private key, it would be possible to forge the proof. Since this person know he generated the private key himself and didn't give it to anybody, he knows that the proof cannot be a forgery.)
That way if somebody doubt your credibility, you can show which information you provided earlier. This needs to encorporate a time stamping mechanism as well. Such that it can be verified that you did in fact provide the information before it became public knowledge. And if somebody copy other peoples information claiming to be the original source, it can be verified who posted the information first.
Will all the crashes will be blamed on bad drivers?
But this whole thing seems unrealistic anyway simply because you don't know which machine to be monitoring, and you can't be monitoring every machine on the internet.
There is nothing wrong with X. The primary reason not to use X applications under Mac OS X is the fact that Mac OS X uses a different graphical system. It is exactly the same as using with using X applications with Windows. The native user interface is a different one. There exist an aqua program, that implements an X server, but using X applications that way is never going to work as good as on a system using it natively.
What Apple should have done was to develop an X server for their hardware, and extent it with the necesarry features to do cool graphical things. I don't know if something fairly standard like Open GL would have been sufficient, or if more is needed. But X is extensible, so they could have done this.
On top of this X server, they should then have implemented an XDM with the look and feel they wanted (a typical Linux distribution come with three implementations, there is no reason why Mac OS X couldn't have included an entirely different or (gosh) given the user a choice). Of course the login screen is just a minor detail. What they also should have done was to implement Aqua as a windowmanager/desktop environment on top of X.
I'm not suggesting the look and feel should have been any different from what it actually is - just that it should have been implemented in the way such a thing is intended to be done on top of X. As long as you only use aqua applications, you wouldn't notice a difference. But if you were to combine aqua and X applications, you'd see it working a lot better. First of all, aqua could actually know which windows belongs to which programs, and not just see the all as being one application called X. Another advantage is, that if you liked to, you could actually install another environment like KDE and from the login screen choose which one you wanted to use today. And you would be able to use aqua applications under KDE. If Apple had done this right, the majority of the users would never have noticed, that OpenOffice was a native X application and not an aqua application.
I guess I actually agree with you. I'm just trying to explain, that it is not the users disliking X applications for no good reason. It is actually Apple, who decided to make X applications second class by design. Why did Apple do it this way? The only explanation I can think of is that this way it would be a little less work to implement aqua. Of course choosing to save time on implementation did mean the result was not as good as it could have been. Having worked with Mac OS X as well as Windows, I like Mac OS X better. Still aqua is not as nice to work with as KDE. Aqua could have beaten the user experience of KDE, if Apple had decided to do it right and implement aqua as an X server and a window manager.
Thank you, I'm going to bookmark your post and try it out on my next opportunity. The fifth thing I asked for was something similar to "rpm --queryformat", which is very convenient in scripts.