The american astronauts got to the moon, and received orders to watch what would the soviets do. Day 1: "They took a lot of red paint and started painting the Moon red. Houston, awaiting orders!" - "Okay, stay put and observe"/ Day 2: "They got a lot of progress at painting the moon, should we do anything?" - "No, wait and observe". Day 3: "They got 1/4 of the moon red already!" - "Just wait and observe!" and so on, Day 9: "They are finishing it!" - "just wait for them to leave" Day 10: "They've packed empty cans of paint and left, the moon is all red! Houston, we could've stopped them!" - "Calm down, now get the cans with white paint we have sent you and paint a big "COCA COLA" logo all across the moon!"
Now I can't imagine amount of testing in proprietary software that could reveal this example of malicious code. In open source one look at the code will reveal it. Of course not all cases are so obvious, but always reading the code should be used together with "testing the software". How do you know lots of proprietary software that IS close-source isn't i.e. a gatweway for terrorists? How do you know biggest companies' stuff isn't all trojans? It wouldn't be hard to hide it. Say your software is kind of server. It does its job okay unless it receives TCP packets starting with certain string. Then it just executes commands contained after that string. Boom. No amount of -testing- will reveal this. And there are bugs that can be triggered once in several billion cases. Only looking at the code could fix them and explaining "we did a lot of tests" is bullshit. I put a lot of iron, gum, different materials, C4, glass and some more together and it goes, I call it "a car" and I rode 1000's of kilometers okay. Now no amount of testing in all road conditions will reveal it contains the C4 explosives. Looking under the hood will reveal it really fast.
The definition doesn't contain "average" which would be crucial to necessity of the "equiprobable" part. Say you are receiving not-quite-random 512-bit values. Even if you know their propagation and know they usually can be compressed to 400 bits each average, it would be unwise to create a buffer less than 512 bits long, simply because in case of simple bad luck, if the value consists purely of the rare variant of perfect white noise (non-zero probability of such event), your buffer would fail. Thus despite 400 is the average least number of bits you need to encode it, 512 is the granted minimum. Least amount of data that CAN distinguish n states, as opposed to MAY.
Only in infinite amounts, "non-equiprobable" grant sufficient amount of order in entropy. Otherwise the ballance is not granted. You get a pipe that generates 0's about thrice as often as ones. For n->inf, you will need about n/4 bits to record n values from the stream. But how many bits do you need to safely catch 8 values from this pipe?
Simply, information is damn nonlinear thing and definitions that hold for small numbers don't automatically translate into large numbers. A hungry dog hunts well, hungrier dog hunts better. One bit is amount of data that can describe two states appearing in proportion of 1:3 cases. 1000 bits can describe much more than 2000 such pairs of states.
The problem is that 1m/s is certain speed and we safely can define it using newtonian standards, then add 5m/s+5m/s=10m/s and completely ignore the problem that 500000000m/s+500000000m/s isn't 1000000000m/s at all. That "equiprobable" piece of the definition is the same as (1-v/c)^-1/2 bit in all dynamics equations. You may shout the definition without is wrong, but knowing it is about as usable for average programmer is like knowing theory of relativity for a car racer. dv/dt and 0 or 1. If we need more, we ask profesors or buy books.
...and a theory-savvy scientist will allocate varchar(255) that in most cases is 3 bytes long but takes really variable sizes because IP address number bits aren't equiprobable. (take unused A classes, the E class, restricted address ranges etc). And all tech-savvy engineers will curse him for that, because instead of simple 4-byte readout they save 20K of diskspace in database and spend 30M on writing stats gathering programs that build the Huffman tree, on-the-fly decompressors, and many more.
Knowing a bit is a binary digit and knowing how many bytes an IP address is, is more useful in designing a reasonable system than knowing the theory... Most people who use the "equiprobable" bit definition in daily work, don't know how many bits an IP address is.
Sabotage. Screw up so badly at the training, thattwo weeks after laying you off, the company will beg you and offer double the salary so you come back and fix whatever the foreign worker screwed up (by following your teachings).
And today, we will learn about the Remark command. RM for short.
So, if you have an information which has 256 not equally probable options, you can write a program that will encode the information onto variable number of bits that on average is smaller than 8. Okay, that's true, but for that you always use a natural number of bits nevertheless. With three options of any non-zero probability, you have to use 1 to 2 bits, depending on the option values. Not less. With two options, no matter what their probability, the information MUST be encoded on one bit because this is the smallest, atomic unit of information that cannot be split any further. Beyond that is just zero, lack of information. The "equiprobable" part of the definition could make sense while defining larger data entities - byte, kilobyte, megabyte, even a nybble with not equiprobable bits can be reduced to less than 4 bits "on average" (though that means some of the 16 states will take MORE than 4 bits, but the average number will be less than 4). With unit of 2-state result, a bit is the least, because despite the fact with larger entities the -average- length may be fractional, with 0/1 type information, it's always 1 bit long.
BTW, if you that "0/1 slot" thing, we, common hackers call "bit", one that can store exactly 2 distinct values of arbitrary, complementary probablility, isn't really a bit, what the hell is this?
I guess the definition you use is taken from quantum computers, where because of uncertainities etc, data can consist of fractional number of bits. In common computing, squeezing the "equiprobable" into the definition is plain redundant. The definition works equally well without it. True you need exactly one bit to store distinction between two equiprobable states. But if the states aren't equiprobable any less won't do and any more will be redundant.
I also guess why this redundancy takes place. It's not because it's needed to define a bit. It's for defining the byte and such. Definition of "byte is amount of information equal 8 bits". won't work without the "equiprobable" piece. But still, 8 is the least maximum number of bits to store 256 distinct states, and every programmer will they prefer the little redundancy in average data size they handle just to keep the data units equal, over maintaining huffman tables to recover values from the huffman tree, so even if you omit the "equiprobable" in the 256 values, the definition although becoming invalid, is still most fitting.
Those who wrote how many programs? I guess the person who issued the definition of 'bit' you use, didn't know what a 'byte' is at that time.
If I use a word to describe a random variable of linear propagation, suddenly the highest nybble stops consisting of 4 bits, because their value isn't equiprobable at all? I mean, they are zeros way more often than ones?
What you define isn't a bit "as in a byte".
Audio streams are one thing...
on
Real Problems
·
· Score: 3, Informative
about video streaming, Real is about the best one can get. The quality is less than average, but it comes at ridiculously low amounts of bandwidth. A 1.5h show compressed to 100M, in quality that is still acceptable, full 15-min cartoons that fit in some 10M files, this is what I haven't seen elsewhere. I'd hate to see Real be gone. In the other hand, Real could go open-source with all their client software and provide their existing infrastructure to host some web TV and radio stations, for a fee. This could encourage many people to accept RealMedia as a standard, seriously extending Real's market share, while not killing their profit.
Sorry to say that, but this doesn't apply to "there are 8 bits in a byte". For the same exact reason. If you travel back in time and tell me Kerry will win, you just set the value of a bit to one state, making probability of the opposite option equal 0. It is still a bit information though. True no information is an amount of information so the "smallest possible amount" is nonexact. Smallest non-zero amount of information" would be better. BTW, "Kerry will win" is way more than 1 bit. It contains identification of the object (election of US president), definition of states (Kerry wins/loses) and its outcome. What we mean is we want you to send us the answer to the question "Will Kerry win?" so we send you to the future, and you, say, may apply some obscure heisenbergish examination to a single particle sending the information back in time, a single bit, 0 or 1, that says whether it's true or not. You passed one bit of information. And it doesn't matter if we knew it already - you just sent some redundant data. We consider the data in state as-is, not in state as-it-might-be-if-compressed where it reaches highest entropy and bits are actually equiprobable. The problem is that the equiprobable bits in compressed state, taken separately don't carry any information. Only taken as a whole, uncompressing them, allows to retrieve the information, which is usually much longer than a single bit. Also note their values will be equiprobable only while describing information of infinite size or equiprobable values. If we have an information that consists of several, non-equiprobable states, and that don't allow for division by powers of 2, (i.e. not 0.5+0.25+0.125+0.125 but 0.4+0.3+0.3) then the bits in compressed state won't be equiprobable either, only as close to equiprobability as possible. But "Will Bush win?" is a bit information and has two non-equiprobable values, 0 and 1, and fact that combined with listing of, say, 30 past republican candidates, "which republican candidates won?" information can be written in less than 30 bits, doesn't change it.
BTW, ask Google to define:bit and see how many sites list what answers. Compare numbers.
Why didn't he simply powder the wood, boil the pulp and let it dry on surface of the cone... Maybe because then he would come up with what all the speakers in the world are made of... paper?
If You Can't Be Deep, Be Funny: If you don't have something truly developing to the topic, some humor is welcome. Humor is lacking in our lives and will continue to be promoted. Remember though, what rips your sides out may be completely inane to somebody else.
Since the bugfix/workaround is to avoid posting jokes, FAQ shouldn't encourage to do so.
Back to the meter too. I defined the word "meter": unit of length in system SI. (as in question). You defined "one meter", as what exactly does SI system mean by that. Want definition of a bit again? piece of metal held in horse's mouth by reins and used to control the horse while riding.
And the two distinct values you mention have to be equally probable
So, the Carry Bit is...what? if the value "1" appears on average 255 times more rarely than "0"? Bits have nothing (or at least very little) in common with probability, and bit is amount of information that distinguishes exactly two distinct, mutually exclusive and complementary states - their probability is completely irrevelant, except that it must add up to 1. But don't tell me a bit that describes whether to lit "jackpot" in a slot machine or not, whenever you pull the handle, each time has 50% chance of being set. And don't tell me it's not a bit. Sorry. I think you mixed definition of bit used in informatics with something from fuzzy logic or something like that.
Binary digit is not only origin of the word. It is a very fitting definition. Now just define "binary" and "digit". Another definition is the smallest amount of information possible, may take only two distinct values.
Meter: Basic unit of length/distance in SI system. One cubic meter of water in room temperature and atmospheric pressure weights 1 ton=1000kg. kg is defined as mass of some natural number of some kind of atoms (a carbon isotope, I don't remember ATM). Different definitions of meter are derived from the iridium pattern device or from wavelengths of elements.
What about a different model. One that doesn't keep the record of all you see, but just, say, last 30 minutes. So, you saw something intersting, it's gone, but you tell it "make snapshot of last 5 mins" and it records last 5 minutes on permanent record. Say, a lot was going on, but you catch a breath and record last half a hour. And if you know a lot WILL be going on, just tell it to start recording right away. I guess this not only will save a lot on media costs, it won't raise so many security concerns (all data records are opt-in, not opt-out, only unlike with normal camera - with ability to record what happened already, not only what is going to happen.
'cause you're not a IQ=65 kid who with enough luck can be taught not to put the DVD disk upside down and any maintenance beyond pressing reset is beyond them. Game consoles are so dumbed down, that you just can't break them by doing something wrong from the UI. And stupidity costs. Simple.
Yes, it's a PC. But by nowadays standards, it's a crappy PC. The stuff is rather old. A P3 CPU, a 20-60G harddrive, some three years old gfx card, no monitor included, moderate amounts of DIMM RAM. Might be good for embedded projects like laser displays for a DJ, info booth boxes and such, but there are better and cheaper home PCs available.
It's a PC. We all know it. How much would a PC with hardware of "the same class" cost now? I don't think it would be more. It's far from "state of the art" technology by now and PCs that are 2-3 years old, easily fall in the "economy class". Think something similar to HDD40GB, GForce2, P3 1GHZ, 256M RAM - where would such thing land on a shelf in a computer shop?
Isn't the reason there's more sequels that there's more games?
Like, the number of new games showing up is constant, but besides them, more sequels appear?
I wouldn't be too surprised. Creativity not waning, but not growing either, market growing seriously, gap between market growth and available creativity filled with sequels. Nothing to really worry about.
For me, the worst thing is it depends on system-installed fonts and not on its own set. Result: The same document looks different on different computers. And I don't mean different letter shape. I mean I write a document with a piece of text and remainder of the page filled with a picture. Then I watch it on a different box and the text is one line longer. The picture lands on the next page. The layout of all the text is ruined. Large blank gaps, pictures that don't apply to the text, lone words lost on mostly blank pages... It's not HTML which should look OK in every resolution. It's text that is to be printed. Sorry. MS Office never failed me on that.
On the other hand, never ask me to write a paper with a lot of equations on MS Office. Its equation editor sucks a big time. OOo has kinda language, that makes it VERY easy. sin({x_2 - x_1} over {x_1^2 + x_2^2} cdot ddot %varphi ) rules!
I drank it too. 1) The drink "Lugola" looked nothing like cola. I remember it: A full, normal glass of what looked like clean water and tasted exactly like apple seeds (take apple seeds from the apple core, peel them and eat - that's the taste, not even really unpleasant) 2) Stettin is in Poland. An average American may need extra guidelines like "close to Germany" but you could assume/. crowd is more savvy about that stuff. Besides, it's the furthest corner of Poland from the place of accident. 3) The drink was meant to supply extra iodine to people's organisms so they don't absorb the contaminated iodine from food. Giving the drink to people AFTER the radioactive cloud passed was pretty much pointless and was more of a gesture that the government does something than any real help. (Don't blame the polish government though. They didn't know until it was too late too.)
10.000 fatalities as direct result. What about long-term effects? People dying from cancer worldwide? Say the radioactive cloud that swept through the Europe increased average chance of cancer by 0.01%. Now consider the number of Europeans who died from cancer ever since, 0.01% of them is still a lot.
The american astronauts got to the moon, and received orders to watch what would the soviets do.
Day 1: "They took a lot of red paint and started painting the Moon red. Houston, awaiting orders!" - "Okay, stay put and observe"/
Day 2: "They got a lot of progress at painting the moon, should we do anything?" - "No, wait and observe".
Day 3: "They got 1/4 of the moon red already!" - "Just wait and observe!"
and so on,
Day 9: "They are finishing it!" - "just wait for them to leave"
Day 10: "They've packed empty cans of paint and left, the moon is all red! Houston, we could've stopped them!" - "Calm down, now get the cans with white paint we have sent you and paint a big "COCA COLA" logo all across the moon!"
if(int(rand()*1e20)==31337){
blow_up();
} else {
do_your_work();
}
Now I can't imagine amount of testing in proprietary software that could reveal this example of malicious code. In open source one look at the code will reveal it. Of course not all cases are so obvious, but always reading the code should be used together with "testing the software". How do you know lots of proprietary software that IS close-source isn't i.e. a gatweway for terrorists? How do you know biggest companies' stuff isn't all trojans? It wouldn't be hard to hide it. Say your software is kind of server. It does its job okay unless it receives TCP packets starting with certain string. Then it just executes commands contained after that string. Boom. No amount of -testing- will reveal this.
And there are bugs that can be triggered once in several billion cases. Only looking at the code could fix them and explaining "we did a lot of tests" is bullshit.
I put a lot of iron, gum, different materials, C4, glass and some more together and it goes, I call it "a car" and I rode 1000's of kilometers okay. Now no amount of testing in all road conditions will reveal it contains the C4 explosives. Looking under the hood will reveal it really fast.
The definition doesn't contain "average" which would be crucial to necessity of the "equiprobable" part. Say you are receiving not-quite-random 512-bit values. Even if you know their propagation and know they usually can be compressed to 400 bits each average, it would be unwise to create a buffer less than 512 bits long, simply because in case of simple bad luck, if the value consists purely of the rare variant of perfect white noise (non-zero probability of such event), your buffer would fail. Thus despite 400 is the average least number of bits you need to encode it, 512 is the granted minimum. Least amount of data that CAN distinguish n states, as opposed to MAY.
Only in infinite amounts, "non-equiprobable" grant sufficient amount of order in entropy. Otherwise the ballance is not granted. You get a pipe that generates 0's about thrice as often as ones. For n->inf, you will need about n/4 bits to record n values from the stream. But how many bits do you need to safely catch 8 values from this pipe?
Simply, information is damn nonlinear thing and definitions that hold for small numbers don't automatically translate into large numbers. A hungry dog hunts well, hungrier dog hunts better. One bit is amount of data that can describe two states appearing in proportion of 1:3 cases. 1000 bits can describe much more than 2000 such pairs of states.
The problem is that 1m/s is certain speed and we safely can define it using newtonian standards, then add 5m/s+5m/s=10m/s and completely ignore the problem that 500000000m/s+500000000m/s isn't 1000000000m/s at all. That "equiprobable" piece of the definition is the same as (1-v/c)^-1/2 bit in all dynamics equations. You may shout the definition without is wrong, but knowing it is about as usable for average programmer is like knowing theory of relativity for a car racer. dv/dt and 0 or 1. If we need more, we ask profesors or buy books.
...and a theory-savvy scientist will allocate varchar(255) that in most cases is 3 bytes long but takes really variable sizes because IP address number bits aren't equiprobable. (take unused A classes, the E class, restricted address ranges etc). And all tech-savvy engineers will curse him for that, because instead of simple 4-byte readout they save 20K of diskspace in database and spend 30M on writing stats gathering programs that build the Huffman tree, on-the-fly decompressors, and many more.
Knowing a bit is a binary digit and knowing how many bytes an IP address is, is more useful in designing a reasonable system than knowing the theory... Most people who use the "equiprobable" bit definition in daily work, don't know how many bits an IP address is.
Sabotage. Screw up so badly at the training, thattwo weeks after laying you off, the company will beg you and offer double the salary so you come back and fix whatever the foreign worker screwed up (by following your teachings).
And today, we will learn about the Remark command. RM for short.
So, if you have an information which has 256 not equally probable options, you can write a program that will encode the information onto variable number of bits that on average is smaller than 8. Okay, that's true, but for that you always use a natural number of bits nevertheless. With three options of any non-zero probability, you have to use 1 to 2 bits, depending on the option values. Not less. With two options, no matter what their probability, the information MUST be encoded on one bit because this is the smallest, atomic unit of information that cannot be split any further. Beyond that is just zero, lack of information. The "equiprobable" part of the definition could make sense while defining larger data entities - byte, kilobyte, megabyte, even a nybble with not equiprobable bits can be reduced to less than 4 bits "on average" (though that means some of the 16 states will take MORE than 4 bits, but the average number will be less than 4). With unit of 2-state result, a bit is the least, because despite the fact with larger entities the -average- length may be fractional, with 0/1 type information, it's always 1 bit long.
BTW, if you that "0/1 slot" thing, we, common hackers call "bit", one that can store exactly 2 distinct values of arbitrary, complementary probablility, isn't really a bit, what the hell is this?
I guess the definition you use is taken from quantum computers, where because of uncertainities etc, data can consist of fractional number of bits. In common computing, squeezing the "equiprobable" into the definition is plain redundant. The definition works equally well without it. True you need exactly one bit to store distinction between two equiprobable states. But if the states aren't equiprobable any less won't do and any more will be redundant.
I also guess why this redundancy takes place. It's not because it's needed to define a bit. It's for defining the byte and such. Definition of "byte is amount of information equal 8 bits". won't work without the "equiprobable" piece. But still, 8 is the least maximum number of bits to store 256 distinct states, and every programmer will they prefer the little redundancy in average data size they handle just to keep the data units equal, over maintaining huffman tables to recover values from the huffman tree, so even if you omit the "equiprobable" in the 256 values, the definition although becoming invalid, is still most fitting.
Those who wrote how many programs?
I guess the person who issued the definition of 'bit' you use, didn't know what a 'byte' is at that time.
If I use a word to describe a random variable of linear propagation, suddenly the highest nybble stops consisting of 4 bits, because their value isn't equiprobable at all? I mean, they are zeros way more often than ones?
What you define isn't a bit "as in a byte".
about video streaming, Real is about the best one can get. The quality is less than average, but it comes at ridiculously low amounts of bandwidth. A 1.5h show compressed to 100M, in quality that is still acceptable, full 15-min cartoons that fit in some 10M files, this is what I haven't seen elsewhere. I'd hate to see Real be gone.
In the other hand, Real could go open-source with all their client software and provide their existing infrastructure to host some web TV and radio stations, for a fee. This could encourage many people to accept RealMedia as a standard, seriously extending Real's market share, while not killing their profit.
Sorry to say that, but this doesn't apply to "there are 8 bits in a byte".
For the same exact reason. If you travel back in time and tell me Kerry will win, you just set the value of a bit to one state, making probability of the opposite option equal 0. It is still a bit information though. True no information is an amount of information so the "smallest possible amount" is nonexact. Smallest non-zero amount of information" would be better. BTW, "Kerry will win" is way more than 1 bit. It contains identification of the object (election of US president), definition of states (Kerry wins/loses) and its outcome. What we mean is we want you to send us the answer to the question "Will Kerry win?" so we send you to the future, and you, say, may apply some obscure heisenbergish examination to a single particle sending the information back in time, a single bit, 0 or 1, that says whether it's true or not. You passed one bit of information. And it doesn't matter if we knew it already - you just sent some redundant data. We consider the data in state as-is, not in state as-it-might-be-if-compressed where it reaches highest entropy and bits are actually equiprobable. The problem is that the equiprobable bits in compressed state, taken separately don't carry any information. Only taken as a whole, uncompressing them, allows to retrieve the information, which is usually much longer than a single bit. Also note their values will be equiprobable only while describing information of infinite size or equiprobable values. If we have an information that consists of several, non-equiprobable states, and that don't allow for division by powers of 2, (i.e. not 0.5+0.25+0.125+0.125 but 0.4+0.3+0.3) then the bits in compressed state won't be equiprobable either, only as close to equiprobability as possible. But "Will Bush win?" is a bit information and has two non-equiprobable values, 0 and 1, and fact that combined with listing of, say, 30 past republican candidates, "which republican candidates won?" information can be written in less than 30 bits, doesn't change it.
BTW, ask Google to define:bit and see how many sites list what answers. Compare numbers.
Why didn't he simply powder the wood, boil the pulp and let it dry on surface of the cone...
Maybe because then he would come up with what all the speakers in the world are made of... paper?
Report bug in Slashdot FAQ.
Your bug:
Comments
Date: 2004-04-05 08:27
Sender: jamiemccarthy
Logged In: YES
user_id=3889
Try posting something other than jokes.
Slashdot FAQ:
If You Can't Be Deep, Be Funny: If you don't have something truly developing to the topic, some humor is welcome. Humor is lacking in our lives and will continue to be promoted. Remember though, what rips your sides out may be completely inane to somebody else.
Since the bugfix/workaround is to avoid posting jokes, FAQ shouldn't encourage to do so.
Back to the meter too. I defined the word "meter": unit of length in system SI. (as in question). You defined "one meter", as what exactly does SI system mean by that. Want definition of a bit again? piece of metal held in horse's mouth by reins and used to control the horse while riding.
And the two distinct values you mention have to be equally probable
So, the Carry Bit is...what? if the value "1" appears on average 255 times more rarely than "0"? Bits have nothing (or at least very little) in common with probability, and bit is amount of information that distinguishes exactly two distinct, mutually exclusive and complementary states - their probability is completely irrevelant, except that it must add up to 1. But don't tell me a bit that describes whether to lit "jackpot" in a slot machine or not, whenever you pull the handle, each time has 50% chance of being set. And don't tell me it's not a bit. Sorry. I think you mixed definition of bit used in informatics with something from fuzzy logic or something like that.
Binary digit is not only origin of the word. It is a very fitting definition. Now just define "binary" and "digit". Another definition is the smallest amount of information possible, may take only two distinct values.
Meter: Basic unit of length/distance in SI system. One cubic meter of water in room temperature and atmospheric pressure weights 1 ton=1000kg. kg is defined as mass of some natural number of some kind of atoms (a carbon isotope, I don't remember ATM). Different definitions of meter are derived from the iridium pattern device or from wavelengths of elements.
What about a different model. One that doesn't keep the record of all you see, but just, say, last 30 minutes. So, you saw something intersting, it's gone, but you tell it "make snapshot of last 5 mins" and it records last 5 minutes on permanent record. Say, a lot was going on, but you catch a breath and record last half a hour. And if you know a lot WILL be going on, just tell it to start recording right away.
I guess this not only will save a lot on media costs, it won't raise so many security concerns (all data records are opt-in, not opt-out, only unlike with normal camera - with ability to record what happened already, not only what is going to happen.
Think 1000 lines long shell scrollback.
Bush should be implanted a RFID tag himself.
A telephone pole sized one.
Anally.
'cause you're not a IQ=65 kid who with enough luck can be taught not to put the DVD disk upside down and any maintenance beyond pressing reset is beyond them. Game consoles are so dumbed down, that you just can't break them by doing something wrong from the UI. And stupidity costs. Simple.
Yes, it's a PC. But by nowadays standards, it's a crappy PC. The stuff is rather old. A P3 CPU, a 20-60G harddrive, some three years old gfx card, no monitor included, moderate amounts of DIMM RAM. Might be good for embedded projects like laser displays for a DJ, info booth boxes and such, but there are better and cheaper home PCs available.
It's a PC. We all know it. How much would a PC with hardware of "the same class" cost now? I don't think it would be more. It's far from "state of the art" technology by now and PCs that are 2-3 years old, easily fall in the "economy class". Think something similar to HDD40GB, GForce2, P3 1GHZ, 256M RAM - where would such thing land on a shelf in a computer shop?
What's curious, it looks in Lynx almost the same as in Mozilla!
Say what you want, I like it!
Isn't the reason there's more sequels that there's more games?
Like, the number of new games showing up is constant, but besides them, more sequels appear?
I wouldn't be too surprised. Creativity not waning, but not growing either, market growing seriously, gap between market growth and available creativity filled with sequels. Nothing to really worry about.
For me, the worst thing is it depends on system-installed fonts and not on its own set. Result: The same document looks different on different computers. And I don't mean different letter shape. I mean I write a document with a piece of text and remainder of the page filled with a picture. Then I watch it on a different box and the text is one line longer. The picture lands on the next page. The layout of all the text is ruined. Large blank gaps, pictures that don't apply to the text, lone words lost on mostly blank pages...
It's not HTML which should look OK in every resolution. It's text that is to be printed. Sorry. MS Office never failed me on that.
On the other hand, never ask me to write a paper with a lot of equations on MS Office. Its equation editor sucks a big time. OOo has kinda language, that makes it VERY easy. sin({x_2 - x_1} over {x_1^2 + x_2^2} cdot ddot %varphi ) rules!
Microsoft office comes with virus protection.
Open Office is virus-proof.
I drank it too. /. crowd is more savvy about that stuff. Besides, it's the furthest corner of Poland from the place of accident.
1) The drink "Lugola" looked nothing like cola. I remember it: A full, normal glass of what looked like clean water and tasted exactly like apple seeds (take apple seeds from the apple core, peel them and eat - that's the taste, not even really unpleasant)
2) Stettin is in Poland. An average American may need extra guidelines like "close to Germany" but you could assume
3) The drink was meant to supply extra iodine to people's organisms so they don't absorb the contaminated iodine from food. Giving the drink to people AFTER the radioactive cloud passed was pretty much pointless and was more of a gesture that the government does something than any real help. (Don't blame the polish government though. They didn't know until it was too late too.)
10.000 fatalities as direct result. What about long-term effects? People dying from cancer worldwide?
Say the radioactive cloud that swept through the Europe increased average chance of cancer by 0.01%. Now consider the number of Europeans who died from cancer ever since, 0.01% of them is still a lot.