The current iranian administration killed 500.000 kids (well, they sent them straight into Saddam's bullets after giving them a carton "key to heaven" - this is NOT a joke).
Entire countries spend hundreds of millions of dollars to fake the possibility that they might have the theoretical capability to build a low yield device, because actually building one would cost hundreds of billions.
Hmm. That "hundreds of billions" certainly includes R&D, doesn't it? Building a small bomb with stolen plans (assuming they are correct and exhaustive) and stolen plutonium should be more in the "a couple millions" ballpark, at least that's what my common sense thinks. Yes, stealing those plans is expensive and stealing plutonium is even more expensive. Building a suitable enviroment (laboratory) and finding qualified staff is expensive, too. But "hundreds of billions"? C'mon, we're not talking about inventing the stuff, we're talking about copy&pasting a single device.
Hmm, I know I'm probably wasting my time by replying to an AC but can you clarify? In what way are his LCD TV and PC "owning" him? Because he has to spend some more money and effort to get them to work together the way he likes?
I'm all for criticizing our way of life (if only for keeping us somewhat awake) but your statement doesn't make sense.
I'd hate to see such a large number of drives wasted. As everybody else has already stated: Trying to use them for a normal storage system would be a huge waste of time and money since you can buy the same capacity in much fewer drives for cheaper today.
So either make something really cool of them (and I don't consider ripping the magnets out "cool"...) or, by all means, donate them to some charity that will put them to good use.
If your employer is paranoid then take the time to wipe them with some "DoD-grade" disk-wiping tool. All you need is two old PCs, stick 4 disks into each of them before you leave and let the software work overnight (hint: you can surely find some linux livecd that includes a disk wiping utility). It will only take 12 days that way, or less if you can find more than two "old PCs"...
I did this a while back (with 50-something disks) and consider it kind of rewarding - how often do you get a chance to do something good with so little effort?
Yup, that's the kind. I have no idea what brand or model it was but it was comfortable enough to sleep in it for some hours without getting the usual "car-lag" later. I wonder if such a thing could be modded into a wheeled office chair anyhow...
1) The mailing list can not prove that the signature belongs to you unless your private key has been blessed (and related to your e-mail address) by a trusted 3rd party.
2) Tarpitting solves nothing really. Spammers work with large botnets, some as large as a million zombies. That's a lot of impact, even under the unrealistic assumption that each zombie could only deliver 1 or 2 messages per run.
3) Bandwidth is cheap but not free. You do have a point though; the cost of wasted of bandwidth is (by far) dwarfed by the cost of labor for filtering the mess down to somewhat tolerable levels.
4) You seem to be in the comfortable position that you only have to check your mail once per day, don't generally get much mail and apparently don't get any false positives either. Many of us would love to be there but for heavy mail users (most of which would be businesses) those "30 secs per day" come closer to "4-5 minutes" or worse. Ofcourse that's still no big deal in the big picture but it's measurable overhead that we all pay every day, for no particular reason. It looks even uglier from a business POV because in addition to this overhead you get to pay for setup and maintenance of a spamfiltering "solution".
I had the same idea a while back after I was allowed to sit in one of these expensive truck seats for a few hours (co-pilot). These really are amazingly comfortable...
My problem was the table, though - I guess it would have to be custom made. Ideally I would imagine some kind of attached dashboard (for monitor and keyboard) that moves when you adjust the back and flips out when you need to get up. Well, it would probably end up looking a bit like the Gravitonus Ergonomic Workstation - just a bit more affordable.
There'd be a trivial way to legislate spam: A central opt-in list, maintained by a central authority.
And a single point of failure. I could tick multiple boxes on that wonderful form...
Remember we're talking about a legislative approach here. The system is not queried for each E-Mail.
Don't make me subscribe to your newsletter on your servers, make me subscribe on that central server.
Requires total immediate cooperation from everyone all at once.
Wrong. Only from the senders of bulk mail who must adjust their subscription procedure accordingly.
So everybody who cares can verify that I requested to receive mail from spammer@viagra.ru - or not.
That can be done without a central authority -- just require me to cryptographically sign a message from them. Then, if there's ever a question, the mailing list can produce the signature.
Wrong. This is not about you being able to prove that you signed up, it's about the sender being able to prove that you signed up. If you complain and he can't prove => lawsuit.
Remember, only a handful of people is responsible for most of the spam in your inbox.
Actually, no one is. Spam pretty much never makes it to my inbox. Filtering really can be that good.
And if you think "a million dollars could be spent better elsewhere" then just consider how much the spam overhead costs our economy in lost productivity and "spam-fighting overhead"...
You know, it costs me almost zero time per day to deal with spam, and took maybe $100 worth of my time to add a spamfilter to my server -- that's a conservative estimate. So I think the "cost to our economy" is because of a stupid expenditure of money which could be better spent elsewhere -- and while the million dollars you're proposing might help, it's still a waste of money vs the very simple solution of having email providers add decent filters.
Do you think bandwidth and equipment of e-mail providers and ISPs are free? Do you think handling the remaining spam (and if it's only the proverbial "2 mails per day" for you) and false positives is free?
Well, why would the receiving MTA not accept configuration from me? It'd be in the protocol, remember?
Your config would sync to the MTA (and the other way) as part of the handshake. Versioning is easy to implement here since we're holding a cryptographic identity. The MTA would actually be the primary location where your config and white/blacklists are stored. Sync'ing with your client is merely done so that you can modify the stuff offline and for efficiency.
I'm not going to implement this due to time constraints but I may scribble up a RFC one day. Unless someone presents an insurmountable problem with my approach, ofcourse - but you didn't do that. All your questions (and this one is no different) still assume SMTP roles and semantics. You keep forgetting that backwards compatibility is not part of the idea.
Your question "What if the server doesn't comply" is akin to the question "What if your SMTP server doesn't accept the HELO command?". The answer is: In that case it is not a SMTP server or it has a bug.
Well, I can only repeat: Don't think in terms of SMTP. Once you forget that SMTP ever existed you realize that all the problems you mentioned are simply a matter of engineering the protocol properly.
I did admit in my first post what the big problem with my approach is: adoption. There is no sane "transition path". If there was then we'd probably already be using something like this...
Anyways, everything you mentioned is solvable. Multi-hop routing could be done just like I explained in my last post. Challenge deadlock is not an issue because challenges are not mails and not treated as such.
Mobility and "what about my ISP, multiple accounts, etc." issues seem complicated at a glance but are usually easy to solve, too. The general approach would be to replicate your blacklist, whitelist and settings to all receiving MTAs so they can make the right decisions on your behalf. You trust all your receiving MTAs by definition, thus this is just a matter of delegating various tasks to them - a matter of protocol design.
Your "solution" has one problem: it assumes a real-time interactive channel. How, for instance, is it going to ask the sender to respond to a captcha when the mail's being handled by an intermediate relay (ISP smart-host) and the sender isn't connected anymore?
That's a matter of protocol design, you're still thinking in terms of SMTP. There are various approaches to this but it boils down to: The challenges take place between the sending MUA and the receiving MTA. They happen in realtime whenever possible but can also be timeshifted when necessary. I see 2 possible scenarios in your intermediate hop example:
a) Relay can reach the final destination immediately. In that case I would propose to simply make the relay act as a proxy between the two endpoints.
b) Relay cannot reach the destination immediately (e.g. dialup). In that case I would fallback to store & forward like SMTP. The challenge can not be presented
immediately in that case but remember: if you're expecting a challenge then this is your very first contact to the recipient. I don't think the tiny
introductionary effort [of being presented with the challenge the next hour or day] is unreasonable.
There's an alternate option to make scenario b) even more comfortable: 3rd party challenge providers, like ReCaptcha. Even when you (i.e. your receiving MTA) is not directly reachable you, as a recipient, may choose to trust messages signed by such a 3rd party for these cases.
And if it asks you to authorize the mail, how is it going to do that without having to make you look at each and every incoming mail, spam or not, so you can decide?
Remember, the challenge happens before the e-mail will even be accepted for delivery. So there is no incoming mail to look at. Instead I would allow a short challenge message of maybe 60 characters or so. Sure, spammers would try to drown us in bogus challenges with advertising content but I think they would soon starve due to ineffectivity...
And if they don't - well. Then forget about the manual confirmation and rely on captcha alone. Cracking a captcha for each individual recipient simply does not scale, no matter how you do it.
Well, scratch the "bulk" then. Spam is any mail that I didn't request and don't want to get. This simplest definition should be sufficient for the model I proposed because the recipient can prove at any time that he did not allow the sender to contact him. It's ofcourse up to the recipient to actually file a complaint but I'm fairly convinced that most of us would - if those complaints actually translate into legal action against the sender.
On a side note: I get tired of people bragging about the efficiency of their spam-filters. The situation is not acceptable no matter how good we get at hiding the problem.
Spam constantly wastes a huge amount of technical and mental ressources worldwide and drastically reduces the usefulness of E-Mail as a whole.
There are possible technical and legislative solutions and I can't stop wondering why nobody with sufficient ressources has taken on the challenge, yet. This is not something an individual or a small group can solve in a realistic timeframe, due to the adoption and/or legal barriers. But a bigger entity with a large audience (google, yahoo, microsoft) could very well make a start and solve the technical part by enabling a SMTP-replacement like the one I outlined in the other post.
Spam is unsolicited bulk mail. Just like the paper-spam we get in our mailboxes. There'd be a trivial way to legislate spam: A central opt-in list, maintained by a central authority.
Don't make me subscribe to your newsletter on your servers, make me subscribe on that central server. So everybody who cares can verify that I requested to receive mail from spammer@viagra.ru - or not.
Enforcing that law and tracking down the original senders is a different story but claiming a lack of definition is ridiculous.
Further I firmly believe that if our government would spend only, say, a million dollars a year on a spam-fighting dept this could reduce spam by a large margin. This dept would maintain the aforementioned opt-in server and spend the rest of their time on tracking down reported spammers. Remember, only a handful of people is responsible for most of the spam in your inbox. No doubt, tracking them down and putting them behind bars is costly but it only has to be done a few times per year for great effect!
And if you think "a million dollars could be spent better elsewhere" then just consider how much the spam overhead costs our economy in lost productivity and "spam-fighting overhead"...
Well, I did look at it a few months back and it would segfault randomly. It generally felt like a huge hack that wants to do a little bit of everything but gets nothing right.
I'll keep it on my list, though, as it has interesting ambitions.
3G doesn't need to "convince" anyone, it's just the first step towards "internet everywhere". Imagine just opening your device anywhere and "being on" without further research into free Wi-Fi or hotspots. That's where we are heading, internet is becoming a commodity like radio or TV. 3G is most certainly not the end of the story but an important step towards bringing the infrastructure into place and providing gapless service, at least in urban areas, for a start.
Landlines at home will eventually die out just like phyiscal phone lines are dying out today. Offices, bigger institutions and power users will still have them but joe average will just use the "air service", paid through a flat fee to his provider of choice.
Consequently I can very well imagine providers starting to subsidize laptops and PCs just like they do with cell phones today. Most people really don't care about hardware specs, they just want to buy (or rent) "a computer" or "a laptop" to use google, e-mail and ebay and maybe write the occassional letter. Even today hardware has already become so advanced that the deciding factor for buying a computer is not CPU speed, RAM size or other performance metrics anymore. The deciding factors are screen size, "style" (see Apple) and battery lifetime. Now compare that to any contract-phone advertisement that you have seen recently? The similarities are not a coincidence.
Well, I haven't worked on millions-of-lines projects but I tend to agree that many dynamic languages probably scale poorly to the working style and staffing policy that are often found in such large projects. Nonetheless I think dynamic languages can *grow* well (even better than e.g. java in some regards) with your requirements when you start small or midsize and get bigger over time.
At least for python there are ways to emulate interfaces (PyProtocols, zope.interfaces) but don't forget that, depending on the requirements of your project, there are other approaches to encapsulation that may be a better fit. That's one of the strong points of a dynamic language: It enables you to shape your own rules and working environment in a much more fine grained manner than a static typed language ever could.
You're waging the old "static versus dynamic typing" war here. I'm more of a python guy myself (not much ruby expirience) but I'd like to reiterate the old argument from our side of the fence:
The added productivity that dynamic typing gives us often (not always!) dwarves the risk of obscure bugs sneaking in.
I think that's how most of us "average programmers" see it. A dynamic language can pay off, especially if you're a smaller shop where most people tend to know what they're doing.
I've found very little difference between consumer-grade equipment and carrier-grade equipment as far as reliability goes. If anything, there seems to be a bit of an edge to the consumer-grade equipment.
I don't think the word you are using means what you think it means.
Verbatim quote from wikipedia: Carrier-grade is a term for public network telecommunications products that require up to 5 or 6 nines (or 99.999 to 99.9999 percent) availability, which translates into between 30 seconds (6 nines) and 5 minutes (5 nines) of downtime per year. The term "5 nines" is usually associated with carrier-class servers, while "6 nines" is usually associated with carrier-class switches.
From the rest of your post I take it that you're trying to compare "consumer" hardware with "server" hardware, based on anecdotical evidence. Ofcourse you have a point, "buy two" is a legit approach to availability and it's done that way even in the high end. Nonetheless even when you "buy two" it's normally more cost effective to buy from the midrange than aiming for the very low end. The keyword is maintenance cost. You really want two PSUs per box, hot-swappable harddrives and fans because these components *will* fail multiple times during the lifespan of your typical server.
The idea is to keep the rate of incidents per machine as low as possible. If your ~100 hosts really have no second PSU and you haven't swapped a single fan or disk in the last 3 years then I predict a very interesting year for you, starting sometime in the near future.
I have an anecdote, too: One of our customers (with, until then, a similar attitude) was just recently taught his lesson by having a batch of single-PSU HP pizza boxes fail in rapid succession. Needless to say they're now happily paying the markup for half-decent machines with minimum redundancy because failover is more expensive than routine maintenance unless you're big enough to have n+1 clustering and automatic failover already built into your systems.
Well, technically you are correct but that doesn't negate the fact that an average linux desktop is much less consistent (in terms of widgets, fonts, etc.) than an average windows desktop.
Choice is a good thing and a more consistent UI will not make *me* switch to windows - I have different priorities. Nonetheless it cannot be disputed that the cluttered UI raises the barrier of entry for linux newbies. Yes, the default install of any given distros looks shiny and consistent. Until you decide to load amarok under gnome or evolution under kde...
I don't think this problem can or will be solved anytime soon, but it's a problem worth solving in the long term.
Well, I don't think your screenshot supports your argument very well.
While it's indeed a colorful blend there is still enough common ground to call it "somewhat consistent" which is more than I'd say about most linux desktops. First and foremost: All apps use the same fonts and font-sizes. Almost all icons obviously come from the same set (color scheme). Button sizes and ordering seem to be fairly consistent, too.
Now look at your linux desktop. The fonts in GTK apps looks different than those in QT apps. Button sizes and icons vary *wildly*. Etc. Etc.
I hate windows like the next guy (and consider the UI ugly) but calling it a more inconsistent UI than linux is not fair. KDE and Gnome still have a long way to go before I can't tell a GTK app from a QT app at a glance.
Yea sorry for posting early and thanks for the correction. I was actually still fiddling with the rule while posting and too quick with the submit button.
Thanks to you and the other guys who responded and confirmed. I have now patched my firewall and ssh config to (hopefully) limit any bruteforcing to one attempt per minute:/etc/sshd/sshd_config MaxAuthTries = 1/root/bin/firewall iptables -I INPUT -p tcp --dport 22 --syn -m limit --limit 1/minute -j DROP
Ofcourse what remains is the question of how many attempts would be realistically needed to break a weakened key? I'm eager to see the first proof-of-concept exploit.
Can someone explain what "guessable" means in this context?
Does that mean someone can now generate a "master-key" and ssh into root@any-debian-box that allows public key authentication? What does a realistic attack scenario look like?
C/R is annoying because people want their messages to be delivered, without additional work. It's not even that I have to scan a spambox, or that they look like any other e-mail. It's that I have do to ONE MORE THING to have the message delivered. If this had been the way e-mail worked originally, then people might accept it; but now, everyone is used to sending e-mail and having it arrive without interruption (generally speaking).
Well, I guess we have to agree to disagree. "Without additional work" is ignoring the work that we all have to spend on spamfiltering. And the risk of mail getting lost in someone's spam-folder or a company's misconfigured spamfilter. Have you tried to send a mail directly from a dynamic ip DSL/cable uplink recently?
Respectfully, I'm pretty convinced that it will not work unless the spam problem becomes so excessively bad that people are willing to change their e-mail habits. We are not yet to that point, thanks to all the other half-baked anti-spam solutions out there.
A matter of perception and the way you use e-mail. The spam problem may be mostly hidden to a gmail user exchanging the occassional mail with friends & family. People who depend on receiving cold contacts or who just deal with a lot of mail regularly will (by my expirience) mostly agree that the spam problem couldn't get much worse than it is today. Furthermore my proposed system (or most other working solutions) wouldn't even require that much of a change in the user expirience. Basically the user would be asked (instantly by his MUA) to solve a captcha for any recipient that he's sending to for the first time. Yes, it is an extra step but a very small effort when compared to today's spam fighting tactics.
I must say I'm pretty surprised about how many people seem to be satisfied with the current state of affairs here. Remember that over 90%(!) of all e-mail is spam. Now consider how much that eats into the productivity of a country or the human species as a whole.
Slashdot Mirror
Building a small bomb with stolen plans (assuming they are correct and exhaustive) and stolen plutonium should be more in the "a couple millions" ballpark, at least that's what my common sense thinks. Yes, stealing those plans is expensive and stealing plutonium is even more expensive. Building a suitable enviroment (laboratory) and finding qualified staff is expensive, too. But "hundreds of billions"? C'mon, we're not talking about inventing the stuff, we're talking about copy&pasting a single device.
Hmm, I know I'm probably wasting my time by replying to an AC but can you clarify?
In what way are his LCD TV and PC "owning" him? Because he has to spend some more money and effort to get them to work together the way he likes?
I'm all for criticizing our way of life (if only for keeping us somewhat awake) but your statement doesn't make sense.
Seconded!
I'd hate to see such a large number of drives wasted.
As everybody else has already stated: Trying to use them for a normal storage system would be a huge waste of time and money since you can buy the same capacity in much fewer drives for cheaper today.
So either make something really cool of them (and I don't consider ripping the magnets out "cool"...) or, by all means, donate them to some charity that will put them to good use.
If your employer is paranoid then take the time to wipe them with some "DoD-grade" disk-wiping tool. All you need is two old PCs, stick 4 disks into each of them before you leave and let the software work overnight (hint: you can surely find some linux livecd that includes a disk wiping utility). It will only take 12 days that way, or less if you can find more than two "old PCs"...
I did this a while back (with 50-something disks) and consider it kind of rewarding - how often do you get a chance to do something good with so little effort?
Yup, that's the kind. I have no idea what brand or model it was but it was comfortable enough to sleep in it for some hours without getting the usual "car-lag" later. I wonder if such a thing could be modded into a wheeled office chair anyhow...
Well, I'll try to keep it short.
1) The mailing list can not prove that the signature belongs to you unless your private key has been blessed (and related to your e-mail address) by a trusted 3rd party.
2) Tarpitting solves nothing really. Spammers work with large botnets, some as large as a million zombies. That's a lot of impact, even under the unrealistic assumption that each zombie could only deliver 1 or 2 messages per run.
3) Bandwidth is cheap but not free. You do have a point though; the cost of wasted of bandwidth is (by far) dwarfed by the cost of labor for filtering the mess down to somewhat tolerable levels.
4) You seem to be in the comfortable position that you only have to check your mail once per day, don't generally get much mail and apparently don't get any false positives either. Many of us would love to be there but for heavy mail users (most of which would be businesses) those "30 secs per day" come closer to "4-5 minutes" or worse. Ofcourse that's still no big deal in the big picture but it's measurable overhead that we all pay every day, for no particular reason.
It looks even uglier from a business POV because in addition to this overhead you get to pay for setup and maintenance of a spamfiltering "solution".
I had the same idea a while back after I was allowed to sit in one of these expensive truck seats for a few hours (co-pilot).
These really are amazingly comfortable...
My problem was the table, though - I guess it would have to be custom made. Ideally I would imagine some kind of attached dashboard (for monitor and keyboard) that moves when you adjust the back and flips out when you need to get up. Well, it would probably end up looking a bit like the Gravitonus Ergonomic Workstation - just a bit more affordable.
Do you think handling the remaining spam (and if it's only the proverbial "2 mails per day" for you) and false positives is free?
Well, why would the receiving MTA not accept configuration from me?
It'd be in the protocol, remember?
Your config would sync to the MTA (and the other way) as part of the handshake. Versioning is easy to implement here since we're holding a cryptographic identity. The MTA would actually be the primary location where your config and white/blacklists are stored. Sync'ing with your client is merely done so that you can modify the stuff offline and for efficiency.
I'm not going to implement this due to time constraints but I may scribble up a RFC one day. Unless someone presents an insurmountable problem with my approach, ofcourse - but you didn't do that. All your questions (and this one is no different) still assume SMTP roles and semantics. You keep forgetting that backwards compatibility is not part of the idea.
Your question "What if the server doesn't comply" is akin to the question "What if your SMTP server doesn't accept the HELO command?".
The answer is: In that case it is not a SMTP server or it has a bug.
Well, I can only repeat: Don't think in terms of SMTP.
Once you forget that SMTP ever existed you realize that all the problems you mentioned are simply a matter of engineering the protocol properly.
I did admit in my first post what the big problem with my approach is: adoption.
There is no sane "transition path". If there was then we'd probably already be using something like this...
Anyways, everything you mentioned is solvable.
Multi-hop routing could be done just like I explained in my last post.
Challenge deadlock is not an issue because challenges are not mails and not treated as such.
Mobility and "what about my ISP, multiple accounts, etc." issues seem complicated at a glance but are usually easy to solve, too. The general approach would be to replicate your blacklist, whitelist and settings to all receiving MTAs so they can make the right decisions on your behalf. You trust all your receiving MTAs by definition, thus this is just a matter of delegating various tasks to them - a matter of protocol design.
That's a matter of protocol design, you're still thinking in terms of SMTP.
There are various approaches to this but it boils down to: The challenges take place between the sending MUA and the receiving MTA. They happen in realtime whenever possible but can also be timeshifted when necessary. I see 2 possible scenarios in your intermediate hop example:
a) Relay can reach the final destination immediately. In that case I would propose to simply make the relay act as a proxy between the two endpoints.
b) Relay cannot reach the destination immediately (e.g. dialup). In that case I would fallback to store & forward like SMTP. The challenge can not be presented
immediately in that case but remember: if you're expecting a challenge then this is your very first contact to the recipient. I don't think the tiny
introductionary effort [of being presented with the challenge the next hour or day] is unreasonable.
There's an alternate option to make scenario b) even more comfortable: 3rd party challenge providers, like ReCaptcha. Even when you (i.e. your receiving MTA) is not directly reachable you, as a recipient, may choose to trust messages signed by such a 3rd party for these cases.
Remember, the challenge happens before the e-mail will even be accepted for delivery.
So there is no incoming mail to look at. Instead I would allow a short challenge message of maybe 60 characters or so.
Sure, spammers would try to drown us in bogus challenges with advertising content but I think they would soon starve due to ineffectivity...
And if they don't - well. Then forget about the manual confirmation and rely on captcha alone. Cracking a captcha for each individual recipient simply does not scale, no matter how you do it.
Well, scratch the "bulk" then. Spam is any mail that I didn't request and don't want to get.
This simplest definition should be sufficient for the model I proposed because the recipient can prove at any time that he did not allow the sender to contact him. It's ofcourse up to the recipient to actually file a complaint but I'm fairly convinced that most of us would - if those complaints actually translate into legal action against the sender.
I have outlined an open, spam-proof system here: http://mobile.slashdot.org/comments.pl?sid=549310&cid=23368790
Technically it is doable, the problem is adoption (chicken vs egg).
On a side note: I get tired of people bragging about the efficiency of their spam-filters.
The situation is not acceptable no matter how good we get at hiding the problem.
Spam constantly wastes a huge amount of technical and mental ressources worldwide
and drastically reduces the usefulness of E-Mail as a whole.
There are possible technical and legislative solutions and I can't stop wondering why nobody with sufficient ressources has taken on the challenge, yet. This is not something an individual or a small group can solve in a realistic timeframe, due to the adoption and/or legal barriers. But a bigger entity with a large audience (google, yahoo, microsoft) could very well make a start and solve the technical part by enabling a SMTP-replacement like the one I outlined in the other post.
Lacks sufficient definition? Are you kidding me?
Spam is unsolicited bulk mail. Just like the paper-spam we get in our mailboxes.
There'd be a trivial way to legislate spam: A central opt-in list, maintained by a central authority.
Don't make me subscribe to your newsletter on your servers, make me subscribe on that central server.
So everybody who cares can verify that I requested to receive mail from spammer@viagra.ru - or not.
Enforcing that law and tracking down the original senders is a different story but claiming a lack of definition is ridiculous.
Further I firmly believe that if our government would spend only, say, a million dollars a year on a spam-fighting dept this could reduce spam by a large margin. This dept would maintain the aforementioned opt-in server and spend the rest of their time on tracking down reported spammers. Remember, only a handful of people is responsible for most of the spam in your inbox. No doubt, tracking them down and putting them behind bars is costly but it only has to be done a few times per year for great effect!
And if you think "a million dollars could be spent better elsewhere" then just consider how much the spam overhead costs our economy in lost productivity and "spam-fighting overhead"...
Well, I did look at it a few months back and it would segfault randomly.
It generally felt like a huge hack that wants to do a little bit of everything but gets nothing right.
I'll keep it on my list, though, as it has interesting ambitions.
3G doesn't need to "convince" anyone, it's just the first step towards "internet everywhere".
Imagine just opening your device anywhere and "being on" without further research into free Wi-Fi or hotspots. That's where we are heading, internet is becoming a commodity like radio or TV. 3G is most certainly not the end of the story but an important step towards bringing the infrastructure into place and providing gapless service, at least in urban areas, for a start.
Landlines at home will eventually die out just like phyiscal phone lines are dying out today. Offices, bigger institutions and power users will still have them but joe average will just use the "air service", paid through a flat fee to his provider of choice.
Consequently I can very well imagine providers starting to subsidize laptops and PCs just like they do with cell phones today. Most people really don't care about hardware specs, they just want to buy (or rent) "a computer" or "a laptop" to use google, e-mail and ebay and maybe write the occassional letter. Even today hardware has already become so advanced that the deciding factor for buying a computer is not CPU speed, RAM size or other performance metrics anymore. The deciding factors are screen size, "style" (see Apple) and battery lifetime. Now compare that to any contract-phone advertisement that you have seen recently? The similarities are not a coincidence.
Well, I haven't worked on millions-of-lines projects but I tend to agree that many dynamic languages probably scale poorly to the working style and staffing policy that are often found in such large projects. Nonetheless I think dynamic languages can *grow* well (even better than e.g. java in some regards) with your requirements when you start small or midsize and get bigger over time.
At least for python there are ways to emulate interfaces (PyProtocols, zope.interfaces) but don't forget that, depending on the requirements of your project, there are other approaches to encapsulation that may be a better fit. That's one of the strong points of a dynamic language: It enables you to shape your own rules and working environment in a much more fine grained manner than a static typed language ever could.
You're waging the old "static versus dynamic typing" war here.
I'm more of a python guy myself (not much ruby expirience) but I'd like to reiterate the old argument from our side of the fence:
The added productivity that dynamic typing gives us often (not always!) dwarves the risk of obscure bugs sneaking in.
I think that's how most of us "average programmers" see it. A dynamic language can pay off, especially if you're a smaller shop where most people tend to know what they're doing.
I don't think the word you are using means what you think it means.
Verbatim quote from wikipedia:
Carrier-grade is a term for public network telecommunications products that require up to 5 or 6 nines (or 99.999 to 99.9999 percent) availability, which translates into between 30 seconds (6 nines) and 5 minutes (5 nines) of downtime per year. The term "5 nines" is usually associated with carrier-class servers, while "6 nines" is usually associated with carrier-class switches.
From the rest of your post I take it that you're trying to compare "consumer" hardware with "server" hardware, based on anecdotical evidence. Ofcourse you have a point, "buy two" is a legit approach to availability and it's done that way even in the high end. Nonetheless even when you "buy two" it's normally more cost effective to buy from the midrange than aiming for the very low end. The keyword is maintenance cost. You really want two PSUs per box, hot-swappable harddrives and fans because these components *will* fail multiple times during the lifespan of your typical server.
The idea is to keep the rate of incidents per machine as low as possible. If your ~100 hosts really have no second PSU and you haven't swapped a single fan or disk in the last 3 years then I predict a very interesting year for you, starting sometime in the near future.
I have an anecdote, too:
One of our customers (with, until then, a similar attitude) was just recently taught his lesson by having a batch of single-PSU HP pizza boxes fail in rapid succession. Needless to say they're now happily paying the markup for half-decent machines with minimum redundancy because failover is more expensive than routine maintenance unless you're big enough to have n+1 clustering and automatic failover already built into your systems.
Well, technically you are correct but that doesn't negate the fact that an average linux desktop is much less consistent (in terms of widgets, fonts, etc.) than an average windows desktop.
Choice is a good thing and a more consistent UI will not make *me* switch to windows - I have different priorities. Nonetheless it cannot be disputed that the cluttered UI raises the barrier of entry for linux newbies. Yes, the default install of any given distros looks shiny and consistent. Until you decide to load amarok under gnome or evolution under kde...
I don't think this problem can or will be solved anytime soon, but it's a problem worth solving in the long term.
Well, I don't think your screenshot supports your argument very well.
While it's indeed a colorful blend there is still enough common ground to call it "somewhat consistent" which is more than I'd say about most linux desktops. First and foremost: All apps use the same fonts and font-sizes. Almost all icons obviously come from the same set (color scheme). Button sizes and ordering seem to be fairly consistent, too.
Now look at your linux desktop. The fonts in GTK apps looks different than those in QT apps. Button sizes and icons vary *wildly*. Etc. Etc.
I hate windows like the next guy (and consider the UI ugly) but calling it a more inconsistent UI than linux is not fair. KDE and Gnome still have a long way to go before I can't tell a GTK app from a QT app at a glance.
Yea sorry for posting early and thanks for the correction.
I was actually still fiddling with the rule while posting and too quick with the submit button.
Thanks to you and the other guys who responded and confirmed. /etc/sshd/sshd_config /root/bin/firewall
I have now patched my firewall and ssh config to (hopefully) limit any bruteforcing to one attempt per minute:
MaxAuthTries = 1
iptables -I INPUT -p tcp --dport 22 --syn -m limit --limit 1/minute -j DROP
Ofcourse what remains is the question of how many attempts would be realistically needed to break a weakened key?
I'm eager to see the first proof-of-concept exploit.
Can someone explain what "guessable" means in this context?
Does that mean someone can now generate a "master-key" and ssh into root@any-debian-box that allows public key authentication?
What does a realistic attack scenario look like?
Well, I guess we have to agree to disagree. "Without additional work" is ignoring the work that we all have to spend on spamfiltering. And the risk of mail getting lost in someone's spam-folder or a company's misconfigured spamfilter. Have you tried to send a mail directly from a dynamic ip DSL/cable uplink recently?
A matter of perception and the way you use e-mail. The spam problem may be mostly hidden to a gmail user exchanging the occassional mail with friends & family. People who depend on receiving cold contacts or who just deal with a lot of mail regularly will (by my expirience) mostly agree that the spam problem couldn't get much worse than it is today. Furthermore my proposed system (or most other working solutions) wouldn't even require that much of a change in the user expirience. Basically the user would be asked (instantly by his MUA) to solve a captcha for any recipient that he's sending to for the first time. Yes, it is an extra step but a very small effort when compared to today's spam fighting tactics.
I must say I'm pretty surprised about how many people seem to be satisfied with the current state of affairs here.
Remember that over 90%(!) of all e-mail is spam. Now consider how much that eats into the productivity of a country or the human species as a whole.