There's an even more obvious solution: When you
work on your friend's computer have him/her create an account for you. In fact, I fail to see the problem at all. You'd have a problem working on a different computer only if it was a single user system.
When you move from one system to another that is the same in name but in fact has been customized, skinned and preferenced to the outlandish ideas (outlandish from your point of view) of another user, you might as well have moved to Mars.
Too bad it didn't hit him that this is precisely
why *nix supports multiple users.
Mr. Raskin, are you from Mars? Next time
you give an interview, please be sure to do your
homework. UI expert you may be, but you seem to
be unaware of the basics of OSes.
Lots of people have given their opinion on colors,
here's mine:
As far as possible don't specify colors at all on
your pages. HTML is about Viewer Control .
I stare at the screen for hours on end, and white
backgounds get too bright for me. I have no problem when I'm using a browser that allows me
to override document settings with my defaults, but otherwise I find looking at pages with different backgrounds a real pain.
To summarize, your markup should be structural, not presentational.
Hi. I'm Bernard Shit^Hfman, and I do computer consultancy services. I'm looking for contract work. I specialize in spam and sue services: I offer advice on how to spam, and then sue for damages. So any time you want to make some money, you can use my phone number as a starting point.
P.S If you don't get back to me within a month, you'll be liable for damages resulting from my going out of work. My lawyers will be getting in touch with you and you could be facing upto $1500 a day
P.P.S wanna fuck me?
100:1 ratio? On random data?
Considerations far more elementary than Shannon's
limits rule out compression of statistically random data by even a single bit. Here's why:
There are 2^n bit strings of length n. Any compression method purporting to compress random strings (by even a single bit) must produce output
of length at most n-1 for these 2^n inputs. But in that case the mapping is not unique, since there are only (2^n)-1 bit strings of length n-1 or less.
(So decoding is not possible.)
Once every so often some "researchers" claim to
have attained the holy grail of compression.
Too bad we never hear of them again:(
From the comp.compression faq this topic has generated and is still generating
the greatest volume of news in the history of comp.compression
...
The advertized revolutionary methods have all
in common their supposed ability to compress random or already compressed data.
I will keep this item in the FAQ to encourage people to take such claims with
great precautions
What has to be looked at is not the complexity
of decryption itself but the difference between the complexities of encryption and decryption. Public key encryption relies crucially on the assumption of a "computationally bounded adversary". If it turns out that whatever I can encrypt on my home box, someone with a bunch of supercomputers (wink, wink) can crack, then we have a problem.
Only randomized algorithms (i.e., ones that may produce the wrong answer) can achieve polynomial time.
Actually, ones that may produce no answer at all. There is really no such thing as producing the wrong answer because it is trivial (polynomial time) to verify if the answer is correct (i.e a given number is a factor).
Infact by the definition of NP-completeness it
must be possible to verify a solution in polynomial time (But yes, I do know that factoring
is not NP-complete).
Slashdot Mirror
There's an even more obvious solution: When you work on your friend's computer have him/her create an account for you. In fact, I fail to see the problem at all. You'd have a problem working on a different computer only if it was a single user system.
When you move from one system to another that is the same in name but in fact has been customized, skinned and preferenced to the outlandish ideas (outlandish from your point of view) of another user, you might as well have moved to Mars.
Too bad it didn't hit him that this is precisely why *nix supports multiple users. Mr. Raskin, are you from Mars? Next time you give an interview, please be sure to do your homework. UI expert you may be, but you seem to be unaware of the basics of OSes.
Lots of people have given their opinion on colors, here's mine:
As far as possible don't specify colors at all on your pages. HTML is about Viewer Control . I stare at the screen for hours on end, and white backgounds get too bright for me. I have no problem when I'm using a browser that allows me to override document settings with my defaults, but otherwise I find looking at pages with different backgrounds a real pain.
To summarize, your markup should be structural, not presentational.
Hi. I'm Bernard Shit^Hfman, and I do computer consultancy services. I'm looking for contract work. I specialize in spam and sue services: I offer advice on how to spam, and then sue for damages. So any time you want to make some money, you can use my phone number as a starting point.
P.S If you don't get back to me within a month, you'll be liable for damages resulting from my going out of work. My lawyers will be getting in touch with you and you could be facing upto $1500 a day
P.P.S wanna fuck me?
100:1 ratio? On random data?
Considerations far more elementary than Shannon's limits rule out compression of statistically random data by even a single bit. Here's why:
There are 2^n bit strings of length n. Any compression method purporting to compress random strings (by even a single bit) must produce output of length at most n-1 for these 2^n inputs. But in that case the mapping is not unique, since there are only (2^n)-1 bit strings of length n-1 or less. (So decoding is not possible.)
Once every so often some "researchers" claim to have attained the holy grail of compression. Too bad we never hear of them again
From the comp.compression faq
this topic has generated and is still generating the greatest volume of news in the history of comp.compression
The advertized revolutionary methods have all in common their supposed ability to compress random or already compressed data. I will keep this item in the FAQ to encourage people to take such claims with great precautions
What has to be looked at is not the complexity of decryption itself but the difference between the complexities of encryption and decryption. Public key encryption relies crucially on the assumption of a "computationally bounded adversary". If it turns out that whatever I can encrypt on my home box, someone with a bunch of supercomputers (wink, wink) can crack, then we have a problem.
Only randomized algorithms (i.e., ones that may produce the wrong answer) can achieve polynomial time.
Actually, ones that may produce no answer at all. There is really no such thing as producing the wrong answer because it is trivial (polynomial time) to verify if the answer is correct (i.e a given number is a factor).
Infact by the definition of NP-completeness it must be possible to verify a solution in polynomial time (But yes, I do know that factoring is not NP-complete).