By and large, I agree with what you say. However, I've noticed (insert sarcastic "woooow") that Google's getting really really big, particularly in the web search area.
I think it's time thinking about whether Google is holding a monopoly (or whether they're approaching that), how they might use and abuse their monopoly position, and what can be done, should be done and is being done about it.
Just so we are well prepared if and when we ever need to turn our conclusions into actions.
I can change search engines on a whim. But *I don't want to.*
If people want to use IE6, I'm fine with that. ( don't like that choice, but people have a right to make that choice, and I want to respect that right.
However, I want that choice to be made in a fair way---I want the outcome to be the result of peoples' choices, not monopoly abuse. Even if people want Windows, I think there's a reasonable argument for the browser ballot thing.
(That doesn't preclude there being reasonable arguments against, of course; nor does it say whether "the net argument" is for or against.)
Of course, politicians like regulating things they have no business regulating.
They do have a business regulating monopolies and, more generally, eliminating market failures.
Now, if Google is never an abusive monopolist, this post is irrelevant;) -- so let's argue about whether Google is a monopoly or not, and if so whether it's abusive.
His conclusions were that ARMA was (very) far from being realistic, but that it was OK because it would have been boring and tedious to act exactly like a real soldier in a real war.
Never having been in a warzone, why is it boring?
I imagine you spend a lot of time digging trenches, marching from A to B, making sure your equipment works. The few clips from real wars I've seen (probably with a biased selection by the media), say from the Iraq war, show soldiers out on a job to arrest someone. Then there's the bomber planes doing most of the heavy duty destruction work.
Is it "only" boring because there's very little time spent in close combat? If that is indeed the case, you could, you know, make a game that focuses on the exciting bit.
(Before the moralists get to it: yes, war is terrible, stressing to the soldiers, needlessly destructive, and so forth; I'm with you on the "Peace, maan" philosophy. Interpret my comment in context, sanely)
You might have to write a bit of arch-specific code to get Linux running, and fix a few portability bugs in some applications, but it should be easily doable to get something going.
The carrier would have the other copy of the key in it's servers.
No! No, no, no!
I don't want to talk privately with my carrier.
Or at least, that's not my primary concern. I want my carrier to require me to prove my identity to them (so no one can impersonate me and rack up my bill), and I want to be able to prove my identity to them (so I can make calls).
I don't know the telephone protocol header diagrams; if I'm roaming it might be the case that I want to tell a bit of routing information to the other provider, tell something in secret to my service provider, but my main concern is that I want to communicate in private with the call recipient.
And to do that with gold-plated privacy I really need to pre-distribute long keys to every person I want to talk to. Not going to happen. It appears we will need a public key infrastructure. And for people to sign up to it without even knowing it's there, it'll probably have to be run by either the government or the telecommunications operators. But if it's run by the telecoms, they can MITM me, so that means the government. Meh...
Storing passwords securely is anything but trivial
It's a solved problem, and it was a solved problem in the 70's.
Store the sha1 hash of the password. Then, when the user inputs "open sesame", compare sha1("open sesame") to the stored hash. If they're the same, assume the user input the right password.
(Other cryptographic hash functions will do, and you probably want to add salt, but that's the basic idea.)
I don't see why you wouldn't want to use the secure solution over the obscure one. If it takes 1ms rather than 1ns to check the password, is the human typing it in really going to notice?
When there is a secure solution, why settle for the obscure one?
encryption is nothing more than security through calculated obscurity.
I think you can only prosecute an argument for that claim successfully if you engage in semantic shifting.
That is to say, you're right only if you take the word `obscurity' to mean something different from what everybody else takes it to mean.
Security by obscurity generally means you're relying on the adversary to be ill-informed about some aspect of the crypto which wouldn't be a problem for him to know about in a "real" cryptosystem, and/or extremely limited in computational power.
For instance, the windows 95 screen saver password (at most 14 characters) was stored in the registry, xor'ed with a fixed key of length 14. Probably a const char screen_saver_xor_pad[14] = [...], "safely" hidden away in some undisclosed source code. Security by obscurity.
This is also how DRM works: encrypt a bit string f with key k, then send k and e_k(f) to the recipient, but sneakily, hoping that the recipient will only decrypt and use f in accordance with the rules your piece of software implements. Security by obscurity.
Take on the other hand AES. Go do an exhaustive key search. If you're smart, do a meet-in-the-middle. That's sqrt(2^n), which is still exponential (it's sqrt(2)^n). Okay, n is fixed, but still: the best attack is (essentially) brute force. That's real security.
Then there's of course the gold-plated but impractical security (well, encryption): whenever you want to send a message m that's b bits long, come up with a uniformly random b-bit key k, then transmit m XOR k. Perfectly secure, but good luck sending k to the recipient. You can pre-share it, though, so if you put 4 TB of random key in your submarine, it can send 4 TB back to HQ confidentially. Or you can do quantum key distribution (if you have the required equipment).
I recommend that while your post has a valid point, you try to refrain from commenting on the more technical aspects of security.
I recommend you try to refrain from assessing peoples' understanding of the technical aspects of security and making recommendations based upon that assessment. I haven't seen anything in your parent's post which suggests they don't understand the subject matter, unless we take your semantic shift to be The Right Way to understand "obscurity."
They're there to allow companies to use inadequate security measures without public shame.
And the politics is really the problem.
Let's classify the world into four types of people: politicians, security experts, telecommunications lobbyists and the regular citizens.
The politicians want to stay in office. The security experts want good security. The telecommunications lobbyists want cheap security. The regular citizens don't know there's a security concern (except from what they hear from Hollywood).
The politicians can stay in office if they can afford a good campaign. The telecommunication lobbyists want to make a deal. The security experts are few, unconnected and don't have much money in comparison. The uneducated masses aren't going to change their voting based on GSM security even if they knew about it and understood the issues.
And so you will have the politicians portraying the security experts as evil people (which the media will dutifully transmit to the public), all while the telecommunications people get to use cheap and poor security.
(replace telecommunications with banking if you want to get really bummed out...)
'This is theoretically possible but practically unlikely,' says Claire Cranton, a GSM spokeswoman, [...] 'To do this while supposedly being concerned about privacy is beyond me.'
What? Come again?
If Ms. Cranton doesn't even know the argument for full disclosure, why is she the person speaking on behalf of the GSM Association?
Now, we can discuss among ourselves when full disclosure is better than limited disclosure and vice versa, but at least we understand both positions. She doesn't?
Also, if the attack is practically unlikely, why the big concern about privacy? Didn't Ms. Cranton just say this wasn't a big problem, yet at the same time shame Nohl for causing a big problem?
Simon Bransfield-Garth, the chief executive of Cellcrypt, says Nohl's efforts combined with inadequate security designed into the damn thing could put sophisticated mobile interception technology [in the hands of outlaws].
Fixed that for Mr. Bransfield-Garth. The system isn't weak because of Nohl's deeds or misdeeds. It's weak because it's poorly designed. I have seen telecoms security protocols. Only banks have protocols worse than these:(
Parsers are an unnecessary added layer of complexity. What should happen is that the application returns a machine readable responses.
If you can write a parser, isn't that proof that the response is machine readable?
Just to be sure I'm clear---I'm advocating that you parse an output that has a well-specified structure, not just the patterns a person eyeballs in some text.
This well-specified structure is then part of an API, with all the shame on the developer if he breaks the API or makes incompatible changes. Or just frequent changes.
Maybe we're talking about the same thing? If you use Music Player Daemon, I'm talking about writing parsers for the network protocol (which you can put on/dev/std{in,out} with netcat), not scraping the output of the `mpc' interface.
Maybe what you want is the Presentation Layer of the OSI network stack---which really isn't a network issue but an interprocess communication issue; networking is just one communications medium, unix pipes another. I think this is what ASN.1 is meant to provide; have you looked at that? (My very, very limited understanding of ASN.1 is that it's a good idea gone awry.)
Heck, you should have bought that winning lottery ticket!
Even more ridiculous, if there's a pot of one US megabuck and one ticket which wins the pot, of 100 people buying it 99 are out one megabuck. So the net effect to the economy of the lottery is -98 megabucks.
Man, someone should ban all lotteries!
Now, seriously: If we assume the net effect of moving money from one set of hands to another is 0 (for no particular reason, except I felt like shitting a 0), then the cost of the lottery is what the people running the lottery could have done for the economy with the same time and resources. Opportunity cost is well understood.
I think what you're pointing to is the invalid assumption (made by the author of TFA, I assume; I didn't read it, this is/., etc.) that the best thing that the company could have made happen instead of spending $1 on nothing was spending $1 on saving $10.
(And the obvious answer to the claim that it could is "if it could, why didn't it?". Unravel the answer to that to discover why it couldn't.)
If a sector is 4096 bytes, and you create a 1024 byte file, it still occupies 4096 bytes on the disk, as the HDD won't write anything else but that file to the sector.
Wrong. Probably on more than one level.
I'm not an expert on disks and their interfaces, but I know a little about file systems. I know fershur though that disks don't have any notion of files.
I assume that disks have the following interface: you can point it to a place p in RAM and ask it to write the next n bytes in n-byte-disk-block number k, where n is a constant specified by the disk; i.e. write(p, k). You can symmetrically read(p, k): copy n bytes from disk block number k to RAM, starting where p points at. You can also ask the disk for the block size, get_n().
An easy way to lay out files in n-byte blocks is that each block contains data from zero or one files---the implication being that to get the data that makes up a file f, you store a list of blocks containing the data in f, then access each block in sequence. The other implication being what my parent said: a 1024-byte file will take up a 4096-byte block for itself. (The assumption here is that the data for the file starts at the first byte of the 4096-byte block, for each block in the list, and runs to the end of the block, maybe except for the last block in the block list.)
It's also possible to store files more densely, but not requiring the file to start at the first byte of the 4096-byte block. That means you need to store an offset into the block as part of each element of the block list*.
So for two 2048-byte files to share block k, one would be stored at "(k, 0)" and the other at "(k, 2048)". Similarly, four 1024-byte files could be stored at (k, 0), (k, 1024), (k, 2048) and (k, 3072).
You may be familiar with the programming trick of stealing bits off an int pointer; this is similar to what goes on here---by making your pointer-to-somewhere-on-disk type more coarse-grained, it can be stored in less bits. Or reversely, by using more bits, you can point to more stuff (or more detailed stuff).
* Yes, there may be smarter ways. Yes, you can also store the file "tails" (pieces that go in the last, possibly-unfilled, block) together, multiple tails (or short files) in one block. It's faster to write a new block if you don't have to preserve old contents, so that's a strike against packing small files. It's more space efficient, but finding a good allocation of tails is essentially approximating the knapsack problem (which is NP-hard), so finding the optimal packing is infeasible. Et cetera. In short: There are trade-offs.
Now, please someone correct my model of disk interfaces:)
It just needs to ask for a password to get at the keyring where it stores the WPA2 key.
Last I checked (at or after Hardy), when I walked through my university halls for a few minutes, then opened my laptop and wanted to go to slashdot, I still had my home IP. There's no encryption on the network.
What did I do different/wrong?
Also, use WPA2. From what I hear, WEP is broken (dead horse). So is WPA (dying horse, if not dead yet). Use WPA2. I want to encourage people to use WPA2 as the canonical arbitrary, "random" wifi encryption scheme, when they just need a name to throw around.
HTML hardly constitutes "programming" in any reasonable sense.
I know that full well, but it always gets brought up in these kinds of discussions. We might as well stop and think about why.
What are the similarities between writing HTML and programming? (Let's just assume there is _one_ HTML, and I'll get back to why that assumption is okay to make).
It has a formal grammar and syntax
You're telling the computer what to do (and it responds)
You're creating a "computer-something"*
* (a bit string that makes computers do something more or less exclusive to computers; i.e. not an mp3 bit string or a jpg bit string, but a web page bit string** or an ELF bit string or a...)
** (yes, it's really just text; it's really the internet/browser medium and its peculiarities that're interesting here)
What's the main difference? HTML can't really compute anything. There are computations involved in rendering it, sure, but you can't say <add>2, 2</add> and expect $BROWSER to render 4. I think this is the part which people who say "HTML isn't programming" like to point at.
Going back to the similarities: what do you learn by writing HTML? You learn that you can bend the machine to your will, if and only if you pronounce the right magic spell in the correct way. Some mispronounced spells just do the wrong thing (what does 'bgcolor="ff00fff"' render as?), while others make your magic lab explode (no body text gets rendered).
These lessons are fundamental to programming (and, really, writing instructions in any formal grammar; Apache configuration files spring to mind, as does sendmail line noise).
I think this is the first important reason why it always gets lumped in. The second is that it tends to attract the same kind of people: people who like creating "computer-somethings"; some of these will transition into doing real programming.
How about writing BAT files (windows shell scripts, for those who might not know ^_^)? The DOS(-ish) shell is rather limited in what computations you can express. You get to manage control flow, but the only data you really get to manipulate is text. Is that programming? I think it may be fair to lump it in, but just barely (or I only learned a subset?)...
When you hear "$PERSON wants to learn programming. What do I teach them?" and next hear "HTML", you might appreciate why that answer isn't (necessarily(!)) stupid or wrong: you do learn something that's useful for programming from doing not-programming.
I suggest you evangelize this viewpoint to five African tribes fighting over the arable land available, only enough to feed one of them.
Do I have a point? Yes. Sometimes, it's "us or them". Resorting to evil may be necessary for survival.
Then again, I'm probably making your point: by having to resort to tribes in Africa, I'm implicitly saying that in the rich western societies, you can uphold a high moral standard without having to fear for your life. We can the go on to quibble about pleasure and convenience.
(I like to smoke inside my dorm room, especially during the winter. The tapestry might be smelly, and the next occupant might not like that. Am I being a rude, selfish bastard, disrespecting my fellow human beings? I am being selfish, and I am doing something another person might not like, but there's broad consensus that what I'm doing is OK. How broad does the consensus need to be? <can-of-worms>...)
I can't help but feel that we've lost something valuable.
Perhaps I'm just stating the obvious, but that thing would be (a feeling of, real or not) independence---that you could get by with your own mind, body and toolbox, without having to call upon experts whom you might feel have some power over you (the power to set a price if nothing else).
all you get back is [...] a text stream. [...] could return structured results to the caller.
Parsers. 'Nuff said.
Two rules often forgotten: "You should never have to tell the computer something it already knows"
I'd like to extrapolate that: you should never have to tell the computer the same thing twice. You should be able to make the computer act on general rules.
I really hate that with Network Manager, I can't tell it "whenever you see one of the essids [home, work], connect automatically". Why the hell do I have to spend my precious time clicking stuff when I already know what I'm going to click on?
(Linux lets me express general rules about what my computer should do, in the language of shell scripts etc.; for that, I love it. Thanks also to wpa_supplicant's roaming mode.)
You make it sound like your trains don't even have free internet...
</smug-bastard>
We have that here in Denmark. It's dog slow, but it's enough to browse slashdot via ssh+elinks. (Also, it's a small country over here; so cross-country trips are at most one day even with the slow trains.)
If the thought "I might harm someone" never enters your mind when you are driving a 1000+ pound vehicle at 60+ miles an hour [...]
I hope this would have been obvious to me, had I driven a car---and so is hopefully obvious to people who do drive.
But let's consider---if people are always aware that they might harm someone, and by acting however they feel natural nothing bad happens, aren't they going to learn to trust their natural not-reflected-upon reactions? How will this influence their driving decisions when drunk?
Slashdot Mirror
By and large, I agree with what you say. However, I've noticed (insert sarcastic "woooow") that Google's getting really really big, particularly in the web search area.
I think it's time thinking about whether Google is holding a monopoly (or whether they're approaching that), how they might use and abuse their monopoly position, and what can be done, should be done and is being done about it.
Just so we are well prepared if and when we ever need to turn our conclusions into actions.
I can change search engines on a whim. But *I don't want to.*
If people want to use IE6, I'm fine with that. ( don't like that choice, but people have a right to make that choice, and I want to respect that right.
However, I want that choice to be made in a fair way---I want the outcome to be the result of peoples' choices, not monopoly abuse. Even if people want Windows, I think there's a reasonable argument for the browser ballot thing.
(That doesn't preclude there being reasonable arguments against, of course; nor does it say whether "the net argument" is for or against.)
Of course, politicians like regulating things they have no business regulating.
They do have a business regulating monopolies and, more generally, eliminating market failures.
Now, if Google is never an abusive monopolist, this post is irrelevant ;) -- so let's argue about whether Google is a monopoly or not, and if so whether it's abusive.
His conclusions were that ARMA was (very) far from being realistic, but that it was OK because it would have been boring and tedious to act exactly like a real soldier in a real war.
Never having been in a warzone, why is it boring?
I imagine you spend a lot of time digging trenches, marching from A to B, making sure your equipment works. The few clips from real wars I've seen (probably with a biased selection by the media), say from the Iraq war, show soldiers out on a job to arrest someone. Then there's the bomber planes doing most of the heavy duty destruction work.
Is it "only" boring because there's very little time spent in close combat? If that is indeed the case, you could, you know, make a game that focuses on the exciting bit.
(Before the moralists get to it: yes, war is terrible, stressing to the soldiers, needlessly destructive, and so forth; I'm with you on the "Peace, maan" philosophy. Interpret my comment in context, sanely)
My right hand is suck and tired
That was a typographical penis---I mean error.
You need to get your partner into "the mood"
Not around here, you don't.
My right hand is suck and tired of being treated like a piece of meat! It has emotions too!
And porting Linux/*BSD/Chrome to those architectures, if not done yet, will be relatively easy.
With high probability, it's already done. For most applications, a simple recompile should do.
See for instance http://en.wikipedia.org/wiki/List_of_Linux_supported_architectures and https://buildd.debian.org/stats/
You might have to write a bit of arch-specific code to get Linux running, and fix a few portability bugs in some applications, but it should be easily doable to get something going.
Again, that's true only if you change the meaning of "obscurity".
Nitpick: it's 2^(n/2). [rather than sqrt(2)^n]
2^(n/2) = 2^(1/2 * n) = (2^(1/2)) ^ n = sqrt(2) ^ n.
Which nit were you picking? That I went too fast? Your observation that the key length is effectively halved is still true, FWIW.
The carrier would have the other copy of the key in it's servers.
No! No, no, no!
I don't want to talk privately with my carrier.
Or at least, that's not my primary concern. I want my carrier to require me to prove my identity to them (so no one can impersonate me and rack up my bill), and I want to be able to prove my identity to them (so I can make calls).
I don't know the telephone protocol header diagrams; if I'm roaming it might be the case that I want to tell a bit of routing information to the other provider, tell something in secret to my service provider, but my main concern is that I want to communicate in private with the call recipient.
And to do that with gold-plated privacy I really need to pre-distribute long keys to every person I want to talk to. Not going to happen. It appears we will need a public key infrastructure. And for people to sign up to it without even knowing it's there, it'll probably have to be run by either the government or the telecommunications operators. But if it's run by the telecoms, they can MITM me, so that means the government. Meh...
Storing passwords securely is anything but trivial
It's a solved problem, and it was a solved problem in the 70's.
Store the sha1 hash of the password. Then, when the user inputs "open sesame", compare sha1("open sesame") to the stored hash. If they're the same, assume the user input the right password.
(Other cryptographic hash functions will do, and you probably want to add salt, but that's the basic idea.)
I don't see why you wouldn't want to use the secure solution over the obscure one. If it takes 1ms rather than 1ns to check the password, is the human typing it in really going to notice?
When there is a secure solution, why settle for the obscure one?
encryption is nothing more than security through calculated obscurity.
I think you can only prosecute an argument for that claim successfully if you engage in semantic shifting.
That is to say, you're right only if you take the word `obscurity' to mean something different from what everybody else takes it to mean.
Security by obscurity generally means you're relying on the adversary to be ill-informed about some aspect of the crypto which wouldn't be a problem for him to know about in a "real" cryptosystem, and/or extremely limited in computational power.
For instance, the windows 95 screen saver password (at most 14 characters) was stored in the registry, xor'ed with a fixed key of length 14. Probably a const char screen_saver_xor_pad[14] = [...], "safely" hidden away in some undisclosed source code. Security by obscurity.
This is also how DRM works: encrypt a bit string f with key k, then send k and e_k(f) to the recipient, but sneakily, hoping that the recipient will only decrypt and use f in accordance with the rules your piece of software implements. Security by obscurity.
Take on the other hand AES. Go do an exhaustive key search. If you're smart, do a meet-in-the-middle. That's sqrt(2^n), which is still exponential (it's sqrt(2)^n). Okay, n is fixed, but still: the best attack is (essentially) brute force. That's real security.
Then there's of course the gold-plated but impractical security (well, encryption): whenever you want to send a message m that's b bits long, come up with a uniformly random b-bit key k, then transmit m XOR k. Perfectly secure, but good luck sending k to the recipient. You can pre-share it, though, so if you put 4 TB of random key in your submarine, it can send 4 TB back to HQ confidentially. Or you can do quantum key distribution (if you have the required equipment).
I recommend that while your post has a valid point, you try to refrain from commenting on the more technical aspects of security.
I recommend you try to refrain from assessing peoples' understanding of the technical aspects of security and making recommendations based upon that assessment. I haven't seen anything in your parent's post which suggests they don't understand the subject matter, unless we take your semantic shift to be The Right Way to understand "obscurity."
They're there to allow companies to use inadequate security measures without public shame.
And the politics is really the problem.
Let's classify the world into four types of people: politicians, security experts, telecommunications lobbyists and the regular citizens.
The politicians want to stay in office. The security experts want good security. The telecommunications lobbyists want cheap security. The regular citizens don't know there's a security concern (except from what they hear from Hollywood).
The politicians can stay in office if they can afford a good campaign. The telecommunication lobbyists want to make a deal. The security experts are few, unconnected and don't have much money in comparison. The uneducated masses aren't going to change their voting based on GSM security even if they knew about it and understood the issues.
And so you will have the politicians portraying the security experts as evil people (which the media will dutifully transmit to the public), all while the telecommunications people get to use cheap and poor security.
(replace telecommunications with banking if you want to get really bummed out...)
Or am I wrong? Please, someone tell me I'm wrong.
'This is theoretically possible but practically unlikely,' says Claire Cranton, a GSM spokeswoman, [...] 'To do this while supposedly being concerned about privacy is beyond me.'
What? Come again?
If Ms. Cranton doesn't even know the argument for full disclosure, why is she the person speaking on behalf of the GSM Association?
Now, we can discuss among ourselves when full disclosure is better than limited disclosure and vice versa, but at least we understand both positions. She doesn't?
Also, if the attack is practically unlikely, why the big concern about privacy? Didn't Ms. Cranton just say this wasn't a big problem, yet at the same time shame Nohl for causing a big problem?
Simon Bransfield-Garth, the chief executive of Cellcrypt, says Nohl's efforts combined with inadequate security designed into the damn thing could put sophisticated mobile interception technology [in the hands of outlaws].
Fixed that for Mr. Bransfield-Garth. The system isn't weak because of Nohl's deeds or misdeeds. It's weak because it's poorly designed. I have seen telecoms security protocols. Only banks have protocols worse than these :(
Besides, dispatcher.d scripts allow me to define rules for each connection
Ah, I see you've read some of the non-existing manual ;-) Or did you read some documentation which does exist? If so, where?
Thanks :)
Parsers are an unnecessary added layer of complexity. What should happen is that the application returns a machine readable responses.
If you can write a parser, isn't that proof that the response is machine readable?
Just to be sure I'm clear---I'm advocating that you parse an output that has a well-specified structure, not just the patterns a person eyeballs in some text.
This well-specified structure is then part of an API, with all the shame on the developer if he breaks the API or makes incompatible changes. Or just frequent changes.
Maybe we're talking about the same thing? If you use Music Player Daemon, I'm talking about writing parsers for the network protocol (which you can put on /dev/std{in,out} with netcat), not scraping the output of the `mpc' interface.
Maybe what you want is the Presentation Layer of the OSI network stack---which really isn't a network issue but an interprocess communication issue; networking is just one communications medium, unix pipes another. I think this is what ASN.1 is meant to provide; have you looked at that? (My very, very limited understanding of ASN.1 is that it's a good idea gone awry.)
Heck, you should have bought that winning lottery ticket!
Even more ridiculous, if there's a pot of one US megabuck and one ticket which wins the pot, of 100 people buying it 99 are out one megabuck. So the net effect to the economy of the lottery is -98 megabucks.
Man, someone should ban all lotteries!
Now, seriously: If we assume the net effect of moving money from one set of hands to another is 0 (for no particular reason, except I felt like shitting a 0), then the cost of the lottery is what the people running the lottery could have done for the economy with the same time and resources. Opportunity cost is well understood.
I think what you're pointing to is the invalid assumption (made by the author of TFA, I assume; I didn't read it, this is /., etc.) that the best thing that the company could have made happen instead of spending $1 on nothing was spending $1 on saving $10.
(And the obvious answer to the claim that it could is "if it could, why didn't it?". Unravel the answer to that to discover why it couldn't.)
If a sector is 4096 bytes, and you create a 1024 byte file, it still occupies 4096 bytes on the disk, as the HDD won't write anything else but that file to the sector.
Wrong. Probably on more than one level.
I'm not an expert on disks and their interfaces, but I know a little about file systems. I know fershur though that disks don't have any notion of files.
I assume that disks have the following interface: you can point it to a place p in RAM and ask it to write the next n bytes in n-byte-disk-block number k, where n is a constant specified by the disk; i.e. write(p, k). You can symmetrically read(p, k): copy n bytes from disk block number k to RAM, starting where p points at. You can also ask the disk for the block size, get_n().
An easy way to lay out files in n-byte blocks is that each block contains data from zero or one files---the implication being that to get the data that makes up a file f, you store a list of blocks containing the data in f, then access each block in sequence. The other implication being what my parent said: a 1024-byte file will take up a 4096-byte block for itself. (The assumption here is that the data for the file starts at the first byte of the 4096-byte block, for each block in the list, and runs to the end of the block, maybe except for the last block in the block list.)
It's also possible to store files more densely, but not requiring the file to start at the first byte of the 4096-byte block. That means you need to store an offset into the block as part of each element of the block list*.
So for two 2048-byte files to share block k, one would be stored at "(k, 0)" and the other at "(k, 2048)". Similarly, four 1024-byte files could be stored at (k, 0), (k, 1024), (k, 2048) and (k, 3072).
You may be familiar with the programming trick of stealing bits off an int pointer; this is similar to what goes on here---by making your pointer-to-somewhere-on-disk type more coarse-grained, it can be stored in less bits. Or reversely, by using more bits, you can point to more stuff (or more detailed stuff).
* Yes, there may be smarter ways. Yes, you can also store the file "tails" (pieces that go in the last, possibly-unfilled, block) together, multiple tails (or short files) in one block. It's faster to write a new block if you don't have to preserve old contents, so that's a strike against packing small files. It's more space efficient, but finding a good allocation of tails is essentially approximating the knapsack problem (which is NP-hard), so finding the optimal packing is infeasible. Et cetera. In short: There are trade-offs.
Now, please someone correct my model of disk interfaces :)
It just needs to ask for a password to get at the keyring where it stores the WPA2 key.
Last I checked (at or after Hardy), when I walked through my university halls for a few minutes, then opened my laptop and wanted to go to slashdot, I still had my home IP. There's no encryption on the network.
What did I do different/wrong?
Also, use WPA2. From what I hear, WEP is broken (dead horse). So is WPA (dying horse, if not dead yet). Use WPA2. I want to encourage people to use WPA2 as the canonical arbitrary, "random" wifi encryption scheme, when they just need a name to throw around.
South Korea is not a technological paradise. We have fast broadband but that's about it.
Nah, you guys also have insanely high APM counts and unmatched muta-micro. Just go forge-fastexp and turtle, then you can tech all you like.
Wait, we were talking about StarCraft, right?
HTML hardly constitutes "programming" in any reasonable sense.
I know that full well, but it always gets brought up in these kinds of discussions. We might as well stop and think about why.
What are the similarities between writing HTML and programming? (Let's just assume there is _one_ HTML, and I'll get back to why that assumption is okay to make).
* (a bit string that makes computers do something more or less exclusive to computers; i.e. not an mp3 bit string or a jpg bit string, but a web page bit string** or an ELF bit string or a ...)
** (yes, it's really just text; it's really the internet/browser medium and its peculiarities that're interesting here)
What's the main difference? HTML can't really compute anything. There are computations involved in rendering it, sure, but you can't say <add>2, 2</add> and expect $BROWSER to render 4. I think this is the part which people who say "HTML isn't programming" like to point at.
Going back to the similarities: what do you learn by writing HTML? You learn that you can bend the machine to your will, if and only if you pronounce the right magic spell in the correct way. Some mispronounced spells just do the wrong thing (what does 'bgcolor="ff00fff"' render as?), while others make your magic lab explode (no body text gets rendered).
These lessons are fundamental to programming (and, really, writing instructions in any formal grammar; Apache configuration files spring to mind, as does sendmail line noise).
I think this is the first important reason why it always gets lumped in. The second is that it tends to attract the same kind of people: people who like creating "computer-somethings"; some of these will transition into doing real programming.
How about writing BAT files (windows shell scripts, for those who might not know ^_^)? The DOS(-ish) shell is rather limited in what computations you can express. You get to manage control flow, but the only data you really get to manipulate is text. Is that programming? I think it may be fair to lump it in, but just barely (or I only learned a subset?)...
When you hear "$PERSON wants to learn programming. What do I teach them?" and next hear "HTML", you might appreciate why that answer isn't (necessarily(!)) stupid or wrong: you do learn something that's useful for programming from doing not-programming.
sacrificing morality for quality of life is EVIL.
I suggest you evangelize this viewpoint to five African tribes fighting over the arable land available, only enough to feed one of them.
Do I have a point? Yes. Sometimes, it's "us or them". Resorting to evil may be necessary for survival.
Then again, I'm probably making your point: by having to resort to tribes in Africa, I'm implicitly saying that in the rich western societies, you can uphold a high moral standard without having to fear for your life. We can the go on to quibble about pleasure and convenience.
(I like to smoke inside my dorm room, especially during the winter. The tapestry might be smelly, and the next occupant might not like that. Am I being a rude, selfish bastard, disrespecting my fellow human beings? I am being selfish, and I am doing something another person might not like, but there's broad consensus that what I'm doing is OK. How broad does the consensus need to be? <can-of-worms>...)
I can't help but feel that we've lost something valuable.
Perhaps I'm just stating the obvious, but that thing would be (a feeling of, real or not) independence---that you could get by with your own mind, body and toolbox, without having to call upon experts whom you might feel have some power over you (the power to set a price if nothing else).
Does that resonate with you?
all you get back is [...] a text stream. [...] could return structured results to the caller.
Parsers. 'Nuff said.
Two rules often forgotten: "You should never have to tell the computer something it already knows"
I'd like to extrapolate that: you should never have to tell the computer the same thing twice. You should be able to make the computer act on general rules.
I really hate that with Network Manager, I can't tell it "whenever you see one of the essids [home, work], connect automatically". Why the hell do I have to spend my precious time clicking stuff when I already know what I'm going to click on?
(Linux lets me express general rules about what my computer should do, in the language of shell scripts etc.; for that, I love it. Thanks also to wpa_supplicant's roaming mode.)
Why would I want a perfectly good Linux machine to look like a Windows machine?
Don't you get it? In China, 2010 is the Year of Linux on the Desktop.
:(
You make it sound like your trains don't even have free internet...
</smug-bastard>
We have that here in Denmark. It's dog slow, but it's enough to browse slashdot via ssh+elinks. (Also, it's a small country over here; so cross-country trips are at most one day even with the slow trains.)
If the thought "I might harm someone" never enters your mind when you are driving a 1000+ pound vehicle at 60+ miles an hour [...]
I hope this would have been obvious to me, had I driven a car---and so is hopefully obvious to people who do drive.
But let's consider---if people are always aware that they might harm someone, and by acting however they feel natural nothing bad happens, aren't they going to learn to trust their natural not-reflected-upon reactions? How will this influence their driving decisions when drunk?