But the problem's larger than that. In the Microsoft world, this might work fairly well, although I'm not sure how well it'd work with several computers.
It'll almost certainly start to break in real conditions. Every normal MS user I've seen has their system filled with the strangest junk that doesn't even bother with complying with most of the requirements for making a well behaved windows program, so I doubt it'll work very well.
Besides, in practice it probably won't help much. I do have an use for a system like this due to my large amount of user accounts and computers. A normal user doesn't. A normal user wants to find the report they wrote months ago that somehow ended in the system32 directory, and unless they added metadata, it sounds like WinFS won't help that much.
That's nice, but it's not all that different from just making folders. MS Word files already have fields for metadata that could be filled in, but nobody uses them, and few can be filled automatically.
Linking documents to each other sounds nice, but it's only usable for geeks, or people who obsessively classify everything. It's not enough to have a 'From' field filled in with Joe's name. You need to create a database of people on your system to make it work well.
For example, I wrote a Perl script that reads all my IM and IRC logs and email and stores them in a database. That's because I use many systems. Sometimes I use my main computer, or my laptop, or a second account on my main system from the latop, a few times I used a command line client from my server. Add to this that I have MSN, AIM, YM and Jabber accounts, two email addresses, and IRC clients on two computers...
Now, in all that mess I want to find the URL Joe gave me a week ago. This is rather complicated because now I need a database that links joe@joe.com, joe666@msn.com, joe!hellraiser@rr.com and gives the common name of 'Joe' to them. The result for me is really nice, I can talk to a person switching between IM and IRC, on different computers, and still follow it as one unique unbroken conversation.
Now, give this system to my mother, about who I spoke earlier, and you'll get an even greater mess than what she makes with filenames.
This shows exactly what I'm talking about. You call it 'photo'. Somebody else will call it 'image', 'photograph', or something else. You could make them equivalent, but then you'll find somebody who uses both 'photo' and 'image' for different purposes.
For this to work you need to agree on some universal classification. This can work in a well organized company, but normal users will have lots of problems with it.
For example, suppose I save this post. How to classify it? Is the category 'slashdot' or it's a 'text document' about WinFS? Perhaps 'web' category, 'slashdot' subcategory of type 'text'?
There's a system that exists already and that's not vaporware. ReiserFS 4.
You can "cd" into a file like a directory and see the metadata. Things like bitrate for MP3, and all that stuff.
SQL doesn't fit that well with filesystems, btw. Relational databases work great with rigid categories. But beyond very rudimentary classification it won't work well because everybody has their own idea of what a good classification should look like.
But the thing is, you're replacing directory structure by keywords. Instead of Q:\Reports\Joe you'd probably get something like this:
Author: Joe Type: Report Subject: Network security analysis
You still have to specify all the stuff you ever want to be able to search for somewhere. If directories didn't work, keywords won't work much better. Disagreements persist as well. For example, perhaps I think that reports about network security go in a "Network" category, or perhaps it's called "Networking" or "Security", etc.
In the end, you'd need to specify 20 keywords per file because you don't know how people will try to search for it, unless you're in an organization with strict naming formats. But then, you could just use directories anyway.
WinFS uses keyworks. So where do they come from? Perhaps MS Word embeds the name of the user who wrote it, ok. But we can search for that already. The really useful information would have to be added manually.
Now, this may be useful in a huge company with thousands of documents, but for normal people this sounds pretty much useless. If your technophobic grandma can't properly name a document, she won't be able to introduce the proper keywords either.
Of course they can be improved. It's just that WinFS might not be the right way of doing it.
WinFS and similar approaches seem to take the view of that directories are horribly complicated, so users have to be able to search for information to find it anywhere. Find a document from Joe, and so on.
Now, the problem with that is to do interesting searches such as "reports from joe" you need some kind of metadata that specifies the file's a report, and that it comes from Joe.
If we do this WinFS thing assuming users can't keep a good directory structure, why would they specify the correct metadata? After all, somebody has to mark it as a report. I know from experience that trying to make my mother type a decent filename is a problem.
Examples: She will write a document, and save it with a name like "letter", "invitation" or "invoice". Then later she'll open it, use it as a pattern for a different invoice, and save it back with the same name. In the best case, she'll call it invoice2. She will also keep two completely separate invoices in one document, one page for each.
So, would she even bother to provide some consistent information when asked to specify a subject, a person, keywords and stuff like that? I'm completely sure that no.
Obscurity is always compromisable, that's why it's obscurity. Sure, I could visit every shop I can think of, and choose the weirdest lock I can find. But all the attacker has to do is to come take a look at it, and if they still don't know how it works, buy one of their own. I will get a false sense of security hoping that the attacker will lose hope after finding this wonderfully strange lock. Even worse, this lock might be crap, and it'd be hard to find since it's so uncommon.
You might think this won't happen with you, but believe me, it does. Humans are horribly prone to pick some completely stupid thing and think of it as the best thing since sliced bread. This is demostrated by this same article. It'd have been easy to just use the SSL library, or some well known algorhitm, but the author just had to write their own, either because they didn't know better, or because they mistakenly thought making their own lock would make it harder to attack.
On the other hand, I could easily go the lock everybody knows about (say, 3DES), which while not terribly pretty is known to be impossible to pick, and concentrate on other things, like getting a heavy and ugly but secure door made of solid steel.
This also goes for computer system. You can mess all day making FTP run on port 666, and have the root user renamed to "shiva", and even rename/bin/bash to/bin/foobar, but in the end, all this stuff is of very little use. Now, things like grsecurity, SELinux, NX and well configured permissions are the really effective things.
From the point of view of security, if you didn't think the mines would be good for something, you wouldn't put them there. Since there is a path, as soon as one enemy figures it out, the whole army can get through it. This is bad because perhaps you didn't add enough defence to stop the attackers if the mines don't work. Probably you spent money on it too, that could have went instead to something not so easily avoided. It's as simple as an enemy spying somebody walking into the castle by that path, or watching as they're being set up.
From the practical point of view, it's also a bad idea because sooner or later somebody from your team, perhaps even you will get blown up. The mines could also become your prison. You can always leave a heavily guarded castle from the front door without problems. But if there are mines around you risk giving the enemy information on their position.
This is where the analogy breaks down. In real combat you could lay mines in such a way that the hidden path would lead right through the best defended place. But that doesn't really apply to computers. In computer programs, security could be mostly be viewed as a set of concentric rings. Once you figure out how to bypass one of them, it's as if the whole ring vanished.
Adding layers of security does help, but obscurity still isn't security.
The castle walls, moat and alligators continue to work just fine even if your attacker has a full plan of the whole castle. On the other hand, the whole castle will be compromised if somebody ever notices the tunnel.
Even when you can add obscurity as an additional layer, it still has dangers. Say, you keep your alligators in a pond inside the castle, hoping that you'll catch some attackers off guard that way. The danger in that is that it's quite possible that you'll spend some time thinking about your incredible cleverness instead of concentrating on something useful.
Well, the concept of an OTP always has "truly random" mentioned somewhere in it. It's because the whole thing works on the idea that by adding truly random noise to a message produces something that looks like more noise.
Security by obscurity means the security of your system depends on its implementation being secret. Say, some program claiming to be secure that sends "encrypted" data by XOR'ing it with the string "password" which is fixed. Same goes for a chat server I reverse-engineered which tried to make it difficult to write different clients by sending you a number, and requiring you to apply some math on it and send it back. As soon as somebody decompiled it, the math that had to be done was found, so it was broken and anybody could write their own client.
Now, real security is something like ssh, where even if you have the source, know how all the encryption works, and are Bruce Schneier, and you still can't do anything better than to try every possible key
Security by obscurity has nothing to do with passwords. A password is an unknown information that changes for every user. Obscurity in a system is constant.
Security by obscurity means your system relies on that the mechanism is unknown. For example, this timestamp program. As soon as it was found how it worked, it could be instantly broken.
Good security is when an attacker can't break your system faster than brute force, even when given all the computing power, knowledge of how it was built and tools on the planet.
A really secure lock is one you have to brute force by trying every possible key, or breaking the door. Security by obscurity is when you hope nobody will ever find that your door can be easily opened by kicking it in the right place, so you paint the door with a different color, hoping nobody will recognize that it's the vulnerable kind.
Your example doesn't work, by the way. A moat with alligators provides real security. Security by obscurity would be if your castle had a secret tunnel ending in a dark cave, that'd let you get directly inside. That kind of thing only protects you as long as nobody finds about it.
If it's a predictable sequence, then it's not a one time pad.
An OTP needs to be only used once, and to be completely random. Besides, it can't be generated in place. I wrote a small chat program that used an OTP once.
The way you do it is to use some good random number generator, such as/dev/hwrandom on boards that support it, wait until enough data has accumulated, and send a copy to the person you want to talk to. Then you need some kind of protocol to agree on which part of the file you're using.
There will be a protocol in any case. What people don't get is that for a program to communicate with a GUI some protocol has to exist. In both Windows or Linux there is a protocol, which is just the set of rules that say how do you ask the GUI to put a button where you want it.
A different issue is what medium you use to send this protocol. X is a separate process on the system, so you need to connect to it somehow to ask it to do something. On UNIX, the most elegant way is UNIX sockets, which work the same way as a TCP/IP connection, except they're faster because it's all done locally. You can easily use a TCP/IP socket instead and instantly get network transparency.
There are other IPC (Inter-Process Communication) ways on UNIX, but they're mostly less comfortable to use, and some just work in ways that would make things more complicated that they need to be. For example, you may have heard of mmap, but if you tried to only use mmap to send commands to the X server it'd almost certainly be much messier and slower than it currently is.
First, the example you talk about doesn't really apply here. It makes sense to pay every month for a mail server because electricity, a network connection, support, etc are recurrent charges to the mail provider. If you owned your own, you'd do exactly the same. You pay somebody else because you don't have the infrastructure or admins for it. There's no way a mail provider could charge a single fee without going bankrupt due to customers who use the service for too long.
Now, it makes no sense at all for software. When I buy MS Word, MS doesn't need to pay every month for the maintenance of that service. I'm the one who pays for the electricity for the computer it runs on, and the one who pays for the support.
Second, you present a kind of a renting 'Nirvana' where everything will go great and nothing will ever fail. In practice, outsourcing critical infrastructure is a *huge* mistake, because then it will be out of your control. If your company's business will grind to a halt without a working word processor, you don't buy a subscription that makes it possible to suddenly stop working.
Even if your data is all safely backed up, what happens when this company goes out of business? Are you sure they'll make an effort to contact you to send your data to you? Will you be able to do anything useful with it if they disappear?
A 1000 GHz CPU does 10^12 operations per second. Let's suppose in one clock cycle we can try one key. Let's take a million of those CPUs. We get 10^18 tries per second.
Number of seconds needed to try them all: 340282366920938463463374607431768211456
Or: 10790283070806014188970529154990 years.
If you could get computers 10^6 faster, and 10^6 times more of them, then you could get it done in somewhere about 10 years.
However, I doubt we'll ever have so much processing power, or so many computers.
Corruption would be something completely independent of whether they're paying a local distribution or Microsoft. And heck, even in the corruption case some of that money could be used to pay for a new house for the corrupt person, which would at least involve some of it going to the local industry while giving it to MS is a 100% warranty that it won't happen.
You could as well argue that lowering the price of oil won't make a difference, because businesses will simply pocket the difference. Some will try of course, but there's such a thing as capitalism, and they'll be in a disadvantage respecting to those who lower the prices.
Yeah, it may not be computer scientists. Maybe part of it is used to pay somebody to wipe the floor, or to upgrade the server room. It'd still be better than paying MS.
And sure, corruption can happen. But what does that have to do with what we've been talking about? It's a fundamentally different problem.
Ok, then please restate what you're saying in a different way, because I just don't get it. Take this post for example:
>>...if we get countries to switch to Free Software, they'll stop sending money to Microsoft and instead use it to feed their own computer scientists.
Dream on.
As I said, it's only the initial acquisition that's free. It costs money to support IT regardless of whose software you're using.
So, which part of what I said doesn't make sense? If Microsoft software was replaced by a local Linux distro, wouldn't the money spent go instead to the local industry, where it'd feed local computer experts?
Yes, software costs money to support. So what about it? With OSS, money spent on support is spent paying local system administrators and local programmers. In poor countries, wages are typically pretty low as well, so local support would be also much cheaper. And why couldn't it be purchased?
Option A: Brasil pays Microsoft for Windows, Office and tech support. Result: money goes to MS, which is in the US
Option B: Brasil pays less to a local Linux distro for the packaging and support. Result: money goes citizens of Brasil
Yes, both options cost money. However, with option B it's somebody in Brasil who gets paid, instead of MS getting richer.
Why option B overall costs less? Because Brasil only needs to pay for what it really needs to be well supported. Citizens can get Linux for free, with the result of having more money for buying food or something else. Schools can have it for free if they want. And the ones who pay, benefit the local economy.
You also seem to ignore that wages are much lower in some places. My aunt, who works as a university teacher in Russia earned somewhere about $100 US a month the last time I asked. Now, doesn't the price of Windows seem to be rather significant when that's your wage?
I've been to a very interesting conference by (IIRC), Marcelo Branco about Free Software in Brasil at HispaLinux.
He very convincingly explained, that Free Software *does* help. In countries that aren't filthy rich, the Microsoft tax is actually very significant, and makes a lot of money go to Microsoft instead of being used for something useful. When Brasil buys thousands of Windows licenses, that's millions that are going to Microsoft, instead of the local industry.
The mistake you seem to be commiting is the same as the people who say we shouldn't explore space before we solve poverty on earth. Well, I've got some news for you.
Many of those things are related. Of course, Free Software won't save the world. However, if we get countries to switch to Free Software, they'll stop sending money to Microsoft and instead use it to feed their own computer scientists.
Just run ntpdate when you connect instead of on boot. And kill ntpd before disconnecting. You can do this easily on Linux. On Windows I heard some programs exist to do this as well.
This is not about broadband arrogance anyway. ntpd uses much fewer server resources than ntpdate every second. In fact, many public ntp server administrators often complain about that every hour at:00 minutes they get a ntp version of a slashdotting because people stick ntpdate in crontab.
There are many NTP servers that are free to access out there. Please keep them that way by observing a simple netiquette.
That's a very good way of getting blocked at firewall level. It's rather stupid too, since if you need so much precision just use NTP instead.
It is a wrong use of ntpdate as well. Its point is to set the time to the correct one at startup, since ntpd only makes gradual corrections and won't make time go backwards for example to avoid breaking things.
So, configure ntpdate to run once at boot, then start ntpd to keep it in sync.
Slashdot Mirror
Thinking that helping everyone helps you isn't altruism. It's just as self-interested as hoarding, except it's a different strategy.
But the problem's larger than that. In the Microsoft world, this might work fairly well, although I'm not sure how well it'd work with several computers.
It'll almost certainly start to break in real conditions. Every normal MS user I've seen has their system filled with the strangest junk that doesn't even bother with complying with most of the requirements for making a well behaved windows program, so I doubt it'll work very well.
Besides, in practice it probably won't help much. I do have an use for a system like this due to my large amount of user accounts and computers. A normal user doesn't. A normal user wants to find the report they wrote months ago that somehow ended in the system32 directory, and unless they added metadata, it sounds like WinFS won't help that much.
That's nice, but it's not all that different from just making folders. MS Word files already have fields for metadata that could be filled in, but nobody uses them, and few can be filled automatically.
Linking documents to each other sounds nice, but it's only usable for geeks, or people who obsessively classify everything. It's not enough to have a 'From' field filled in with Joe's name. You need to create a database of people on your system to make it work well.
For example, I wrote a Perl script that reads all my IM and IRC logs and email and stores them in a database. That's because I use many systems. Sometimes I use my main computer, or my laptop, or a second account on my main system from the latop, a few times I used a command line client from my server. Add to this that I have MSN, AIM, YM and Jabber accounts, two email addresses, and IRC clients on two computers...
Now, in all that mess I want to find the URL Joe gave me a week ago. This is rather complicated because now I need a database that links joe@joe.com, joe666@msn.com, joe!hellraiser@rr.com and gives the common name of 'Joe' to them. The result for me is really nice, I can talk to a person switching between IM and IRC, on different computers, and still follow it as one unique unbroken conversation.
Now, give this system to my mother, about who I spoke earlier, and you'll get an even greater mess than what she makes with filenames.
This shows exactly what I'm talking about. You call it 'photo'. Somebody else will call it 'image', 'photograph', or something else. You could make them equivalent, but then you'll find somebody who uses both 'photo' and 'image' for different purposes.
For this to work you need to agree on some universal classification. This can work in a well organized company, but normal users will have lots of problems with it.
For example, suppose I save this post. How to classify it? Is the category 'slashdot' or it's a 'text document' about WinFS? Perhaps 'web' category, 'slashdot' subcategory of type 'text'?
There's a system that exists already and that's not vaporware. ReiserFS 4.
You can "cd" into a file like a directory and see the metadata. Things like bitrate for MP3, and all that stuff.
SQL doesn't fit that well with filesystems, btw. Relational databases work great with rigid categories. But beyond very rudimentary classification it won't work well because everybody has their own idea of what a good classification should look like.
But the thing is, you're replacing directory structure by keywords. Instead of Q:\Reports\Joe you'd probably get something like this:
Author: Joe
Type: Report
Subject: Network security analysis
You still have to specify all the stuff you ever want to be able to search for somewhere. If directories didn't work, keywords won't work much better. Disagreements persist as well. For example, perhaps I think that reports about network security go in a "Network" category, or perhaps it's called "Networking" or "Security", etc.
In the end, you'd need to specify 20 keywords per file because you don't know how people will try to search for it, unless you're in an organization with strict naming formats. But then, you could just use directories anyway.
And how exactly will WinFS solve this?
WinFS uses keyworks. So where do they come from? Perhaps MS Word embeds the name of the user who wrote it, ok. But we can search for that already. The really useful information would have to be added manually.
Now, this may be useful in a huge company with thousands of documents, but for normal people this sounds pretty much useless. If your technophobic grandma can't properly name a document, she won't be able to introduce the proper keywords either.
Of course they can be improved. It's just that WinFS might not be the right way of doing it.
WinFS and similar approaches seem to take the view of that directories are horribly complicated, so users have to be able to search for information to find it anywhere. Find a document from Joe, and so on.
Now, the problem with that is to do interesting searches such as "reports from joe" you need some kind of metadata that specifies the file's a report, and that it comes from Joe.
If we do this WinFS thing assuming users can't keep a good directory structure, why would they specify the correct metadata? After all, somebody has to mark it as a report. I know from experience that trying to make my mother type a decent filename is a problem.
Examples: She will write a document, and save it with a name like "letter", "invitation" or "invoice". Then later she'll open it, use it as a pattern for a different invoice, and save it back with the same name. In the best case, she'll call it invoice2. She will also keep two completely separate invoices in one document, one page for each.
So, would she even bother to provide some consistent information when asked to specify a subject, a person, keywords and stuff like that? I'm completely sure that no.
Well, it's just hard to make exact analogies.
/bin/bash to /bin/foobar, but in the end, all this stuff is of very little use. Now, things like grsecurity, SELinux, NX and well configured permissions are the really effective things.
Obscurity is always compromisable, that's why it's obscurity. Sure, I could visit every shop I can think of, and choose the weirdest lock I can find. But all the attacker has to do is to come take a look at it, and if they still don't know how it works, buy one of their own. I will get a false sense of security hoping that the attacker will lose hope after finding this wonderfully strange lock. Even worse, this lock might be crap, and it'd be hard to find since it's so uncommon.
You might think this won't happen with you, but believe me, it does. Humans are horribly prone to pick some completely stupid thing and think of it as the best thing since sliced bread. This is demostrated by this same article. It'd have been easy to just use the SSL library, or some well known algorhitm, but the author just had to write their own, either because they didn't know better, or because they mistakenly thought making their own lock would make it harder to attack.
On the other hand, I could easily go the lock everybody knows about (say, 3DES), which while not terribly pretty is known to be impossible to pick, and concentrate on other things, like getting a heavy and ugly but secure door made of solid steel.
This also goes for computer system. You can mess all day making FTP run on port 666, and have the root user renamed to "shiva", and even rename
Almost certainly yes.
From the point of view of security, if you didn't think the mines would be good for something, you wouldn't put them there. Since there is a path, as soon as one enemy figures it out, the whole army can get through it. This is bad because perhaps you didn't add enough defence to stop the attackers if the mines don't work. Probably you spent money on it too, that could have went instead to something not so easily avoided. It's as simple as an enemy spying somebody walking into the castle by that path, or watching as they're being set up.
From the practical point of view, it's also a bad idea because sooner or later somebody from your team, perhaps even you will get blown up. The mines could also become your prison. You can always leave a heavily guarded castle from the front door without problems. But if there are mines around you risk giving the enemy information on their position.
This is where the analogy breaks down. In real combat you could lay mines in such a way that the hidden path would lead right through the best defended place. But that doesn't really apply to computers. In computer programs, security could be mostly be viewed as a set of concentric rings. Once you figure out how to bypass one of them, it's as if the whole ring vanished.
Adding layers of security does help, but obscurity still isn't security.
The castle walls, moat and alligators continue to work just fine even if your attacker has a full plan of the whole castle. On the other hand, the whole castle will be compromised if somebody ever notices the tunnel.
Even when you can add obscurity as an additional layer, it still has dangers. Say, you keep your alligators in a pond inside the castle, hoping that you'll catch some attackers off guard that way. The danger in that is that it's quite possible that you'll spend some time thinking about your incredible cleverness instead of concentrating on something useful.
Well, the concept of an OTP always has "truly random" mentioned somewhere in it. It's because the whole thing works on the idea that by adding truly random noise to a message produces something that looks like more noise.
But that's not what security by obscurity is.
Security by obscurity means the security of your system depends on its implementation being secret. Say, some program claiming to be secure that sends "encrypted" data by XOR'ing it with the string "password" which is fixed. Same goes for a chat server I reverse-engineered which tried to make it difficult to write different clients by sending you a number, and requiring you to apply some math on it and send it back. As soon as somebody decompiled it, the math that had to be done was found, so it was broken and anybody could write their own client.
Now, real security is something like ssh, where even if you have the source, know how all the encryption works, and are Bruce Schneier, and you still can't do anything better than to try every possible key
Security by obscurity has nothing to do with passwords. A password is an unknown information that changes for every user. Obscurity in a system is constant.
Security by obscurity means your system relies on that the mechanism is unknown. For example, this timestamp program. As soon as it was found how it worked, it could be instantly broken.
Good security is when an attacker can't break your system faster than brute force, even when given all the computing power, knowledge of how it was built and tools on the planet.
A really secure lock is one you have to brute force by trying every possible key, or breaking the door. Security by obscurity is when you hope nobody will ever find that your door can be easily opened by kicking it in the right place, so you paint the door with a different color, hoping nobody will recognize that it's the vulnerable kind.
Your example doesn't work, by the way. A moat with alligators provides real security. Security by obscurity would be if your castle had a secret tunnel ending in a dark cave, that'd let you get directly inside. That kind of thing only protects you as long as nobody finds about it.
If it's a predictable sequence, then it's not a one time pad.
/dev/hwrandom on boards that support it, wait until enough data has accumulated, and send a copy to the person you want to talk to. Then you need some kind of protocol to agree on which part of the file you're using.
An OTP needs to be only used once, and to be completely random. Besides, it can't be generated in place. I wrote a small chat program that used an OTP once.
The way you do it is to use some good random number generator, such as
There will be a protocol in any case. What people don't get is that for a program to communicate with a GUI some protocol has to exist. In both Windows or Linux there is a protocol, which is just the set of rules that say how do you ask the GUI to put a button where you want it.
A different issue is what medium you use to send this protocol. X is a separate process on the system, so you need to connect to it somehow to ask it to do something. On UNIX, the most elegant way is UNIX sockets, which work the same way as a TCP/IP connection, except they're faster because it's all done locally. You can easily use a TCP/IP socket instead and instantly get network transparency.
There are other IPC (Inter-Process Communication) ways on UNIX, but they're mostly less comfortable to use, and some just work in ways that would make things more complicated that they need to be. For example, you may have heard of mmap, but if you tried to only use mmap to send commands to the X server it'd almost certainly be much messier and slower than it currently is.
First, the example you talk about doesn't really apply here. It makes sense to pay every month for a mail server because electricity, a network connection, support, etc are recurrent charges to the mail provider. If you owned your own, you'd do exactly the same. You pay somebody else because you don't have the infrastructure or admins for it. There's no way a mail provider could charge a single fee without going bankrupt due to customers who use the service for too long.
Now, it makes no sense at all for software. When I buy MS Word, MS doesn't need to pay every month for the maintenance of that service. I'm the one who pays for the electricity for the computer it runs on, and the one who pays for the support.
Second, you present a kind of a renting 'Nirvana' where everything will go great and nothing will ever fail. In practice, outsourcing critical infrastructure is a *huge* mistake, because then it will be out of your control. If your company's business will grind to a halt without a working word processor, you don't buy a subscription that makes it possible to suddenly stop working.
Even if your data is all safely backed up, what happens when this company goes out of business? Are you sure they'll make an effort to contact you to send your data to you? Will you be able to do anything useful with it if they disappear?
No, 128 bit SSL is secure pretty much forever.
A 1000 GHz CPU does 10^12 operations per second.
Let's suppose in one clock cycle we can try one key.
Let's take a million of those CPUs. We get 10^18 tries per second.
Number of seconds needed to try them all:
340282366920938463463374607431768211456
Or:
10790283070806014188970529154990 years.
If you could get computers 10^6 faster, and 10^6 times more of them, then you could get it done in somewhere about 10 years.
However, I doubt we'll ever have so much processing power, or so many computers.
Now you're just completely obviously trolling.
Corruption would be something completely independent of whether they're paying a local distribution or Microsoft. And heck, even in the corruption case some of that money could be used to pay for a new house for the corrupt person, which would at least involve some of it going to the local industry while giving it to MS is a 100% warranty that it won't happen.
You could as well argue that lowering the price of oil won't make a difference, because businesses will simply pocket the difference. Some will try of course, but there's such a thing as capitalism, and they'll be in a disadvantage respecting to those who lower the prices.
Ok, now I seriously don't get it.
Yeah, it may not be computer scientists. Maybe part of it is used to pay somebody to wipe the floor, or to upgrade the server room. It'd still be better than paying MS.
And sure, corruption can happen. But what does that have to do with what we've been talking about? It's a fundamentally different problem.
So, which part of what I said doesn't make sense? If Microsoft software was replaced by a local Linux distro, wouldn't the money spent go instead to the local industry, where it'd feed local computer experts?
Yes, software costs money to support. So what about it? With OSS, money spent on support is spent paying local system administrators and local programmers. In poor countries, wages are typically pretty low as well, so local support would be also much cheaper. And why couldn't it be purchased?
Wow, you managed to miss it. Let me try again.
Option A:
Brasil pays Microsoft for Windows, Office and tech support.
Result: money goes to MS, which is in the US
Option B:
Brasil pays less to a local Linux distro for the packaging and support.
Result: money goes citizens of Brasil
Yes, both options cost money. However, with option B it's somebody in Brasil who gets paid, instead of MS getting richer.
Why option B overall costs less? Because Brasil only needs to pay for what it really needs to be well supported. Citizens can get Linux for free, with the result of having more money for buying food or something else. Schools can have it for free if they want. And the ones who pay, benefit the local economy.
You also seem to ignore that wages are much lower in some places. My aunt, who works as a university teacher in Russia earned somewhere about $100 US a month the last time I asked. Now, doesn't the price of Windows seem to be rather significant when that's your wage?
See?
And your point is?
I've been to a very interesting conference by (IIRC), Marcelo Branco about Free Software in Brasil at HispaLinux.
He very convincingly explained, that Free Software *does* help. In countries that aren't filthy rich, the Microsoft tax is actually very significant, and makes a lot of money go to Microsoft instead of being used for something useful. When Brasil buys thousands of Windows licenses, that's millions that are going to Microsoft, instead of the local industry.
The mistake you seem to be commiting is the same as the people who say we shouldn't explore space before we solve poverty on earth. Well, I've got some news for you.
Many of those things are related. Of course, Free Software won't save the world. However, if we get countries to switch to Free Software, they'll stop sending money to Microsoft and instead use it to feed their own computer scientists.
You still can do it.
:00 minutes they get a ntp version of a slashdotting because people stick ntpdate in crontab.
Just run ntpdate when you connect instead of on boot. And kill ntpd before disconnecting. You can do this easily on Linux. On Windows I heard some programs exist to do this as well.
This is not about broadband arrogance anyway. ntpd uses much fewer server resources than ntpdate every second. In fact, many public ntp server administrators often complain about that every hour at
There are many NTP servers that are free to access out there. Please keep them that way by observing a simple netiquette.
That's a very good way of getting blocked at firewall level. It's rather stupid too, since if you need so much precision just use NTP instead.
It is a wrong use of ntpdate as well. Its point is to set the time to the correct one at startup, since ntpd only makes gradual corrections and won't make time go backwards for example to avoid breaking things.
So, configure ntpdate to run once at boot, then start ntpd to keep it in sync.