The principle of net neutrality will be established in international law, ensuring that the network will not discriminate against the traffic that passes across it. Any discrimination will be left to the end points, the clients, for people to decide for themselves what they censor, what communications they will or will not countenance.
...
It will also force governments to co-operate with one another to tackle the net's security vulnerabilities. It should force them to exchange data about security problems and work collaboratively to solve them and keep net criminals and military aggressors in their animal pens.
Great step in the right direction, those are the two issues I wanted to see addressed. I hope it's strongly phrased so as to strictly prohibit government-sponsored attack vectors like DDoS et al, as it appears from the above paragraph that it's aimed at spammers and other profiteers, completely missing the military possibilities.
Keep in mind that it's not enough to just have 40 HDCP devices, you also have to crack them all, which involves either some really clever known-plaintext attacks or disassembling the firmware on each device.
An engineer working for a company that has made (or prototyped) 40+ HDCP devices would probably have access to the needed data, which can then be copied, brought home, and evaluated. (My hasty reading of) Blom's scheme suggests that the calculation given that data isn't terribly complex. Since this puts that techie's job in jeopardy, the results would need to be revealed anonymously. Otherwise, I see little reason for not taking credit.... unless this is a top-level leak.
Search for "loopt" to take a look. It appears that AT&T has already opted everybody into it, and you can pay money to track your friends who haven't specifically opted out. I was able to opt out on the online payment area... I only found it by digging around the preferences.
He's "bitching" because maintaining a scraper is intensely time-consuming (trust me, I've written many many scrapers and greasemonkey scripts, including a Scroogle userscript). The IE portal was static for years upon years (see TFA), so the scraper needed no maintenance, which is quite different from any other results display.
However, writing a minimal stripping scraper shouldn't be too hard. Here's an email I sent to Scroogle:
Even if you can no longer offer a completely cleaned search results list, serving a somewhat cleaned version shouldn't be terribly difficult; just remove JS bits and rewrite the forms and images to point to locally hosted
copies at scroogle.org. This should remove the cookies and other tracking bits and shouldn't actually be too hard to do (or to maintain).
If you also pass it through an adblock subscription (or equivalent), the ads could be stripped as well, without requiring ongoing maintenance since it comes from another party. If this is too complicated, I think it fair to assume your users will be doing that.
Thanks for running the scraper for all these years!
I can't find any info on recent Lightning work (aside from the fact that the nightlies are still being pumped out)... the developer blog is offline (is mozillazine dead? their front page last speaks from June 2009...), and the Mozilla Calendar development roadmap was last updated about year ago.
Nevertheless, the roadmap's stated plan is to release Lightning 1.0 shortly after Thunderbird 3.0... no idea if that's still on track. If I recall correctly, the calendaring portion was so side-tracked that they removed it from TB3 altogether, also shunting all(?) Mozilla-(corporate)-sponsored time away from it. OpenOffice.org is actually the bigger pushing body for TB3 as an MS Outlook killer (which means a calendar is desired), but Oracle's purchase of Sun may have rearranged (or deferred) priorities.
When TB gets native calendaring, I'll push hard on migration from Outlook for my corporation. If Lightning becomes as stable and ready as Enigmail (which is to say that politics are the only barring element from inclusion), I may make that push anyway... but a streamlined integration is essential in the long run, and resistance to that makes me balk.
Dear Google - If you want to speed up the web as you so claim, and you're genuine in your interest, why is this not Free Software? Why are Google Wave and Google Android (both easily more profitable if closed up!) open platforms, but not this one (NOT profitable regardless of closed/open nature)? There is *NO* way you can compete with the last-mile (ISP) caching servers with respect to latency, so the only advantage comes from your minor optimization tweaks.
If you share these tweaks with the world, we can (a) see your transparency and your genuine interest in speeding up the net without so obviously gaining more data and --more importantly-- (b) the lower-latency last-mile providers such as ISPs, datacenters, and IT departments can actually deploy your superior technology in places where it matters.
In fact, the only place I can see using open DNS servers with benefit are when there are other freedom-related issues (censorship in specific), which of course lends itself to needing more transparency anyway!
There are currently three hits for "i8kspeedfan" on Google, all of them having the exact same text; slashdot, a slashdot syndicator, and the above notebookreview page. Maybe it refers to i8kfan, which is probably similar enough to Linux/*nix's i8kutils, which apparently has no project/home page. All I can find is Debian's i8kutils package (though its maintainer claims he is no longer maintaining it). The source is hosted with a direct tgz link from that page.
I mis-read my notes; that 100k/s figure for your standard desktop is actually 100M/s and comes from the password cracking competition at distributed.net. According to their current live stats, the fastest single-CPU system (an Intel Core i7 2666Mhz) is cracking ogrng at 204M/s and the average is 5.5M (with a wild standard deviation of 8.6M) and from current live multi-CPU stats, a 4-CPU Intel Core 2 quad-core (16 cores) at 3110MHz is cracking rc572 at 450.8M/s and the average is 36M (stdev=51M). That puts 100M/s at more than a standard deviation above average for even a multi-CPU system and more than ten standard deviations above the average single-CPU system.
The PS3s at 200k apiece look pretty measly now, falling well under the average desktop on Dnet (5.5M). Since even an AMD K6 can crunch away at 300k/s on rc572, it's probably reasonable to say that they're cracking something tougher than anything at Dnet. Generously pinning the PS3 to the Intel Core 2 Quad 3GHz (40M/s) means dividing my Dnet numbers by 200 or multiplying the government's numbers by 200.
At 40M/s times the 60 PS3s, we'd come to 2.4G/s, which can break an 8-character alphanumeric password in a day and an 8-character random printable (includes punctuation et al, 6.5 bits of complexity) in 22.7 days. Bring that to ten characters or six characters plus two words and you're suddenly talking about 500 years. Assuming they actively upgrade with no loss to data (to fit Moore's Law) and you're looking at 9 years ( log2(500) ).
I figure military-grade is probably 10-100G/s (with continuous upgrades according to Moore's Law), which would still take 3-7 years to find a 10-char password but blows through the 8-char password in 4-7 hours.
I've done a lot of password-cracking math, even toyed with the idea of writing an academic paper on it. Generally, I work on the (generous) assumption that a well-groomed single node can chunk through 100k passwords per second and that things scale perfectly, so 20 nodes would work through 2M passwords per second. They're claiming their 20-node cluster can handle twice that, and I fully believe it. Powerful GPUs are known to perform extremely well on password cracking, and PS3s certainly have them. That's twice the performance for half to a fifth the cost. Nice, but not "OMG."
They plan to scale up to 60 nodes, which is 12M pass/s. To break a 8-character monospace password (37 bits of complexity, which is pretty weak), it would take just under five hours ( 26^8/(12*10^6)/60/60 ). However, to break an 8-character alphanumeric password (case and numbers), that becomes seven months ( (26+26+10)^8/(12*10^6)/60/60/24/365*12 ).
This is only scary when you have a super-intelligent dictionary attack. Scrape the hard drive and any subpoenaed documents for words and add that to a dictionary of common password parts, then perform your dictionary attack -- dreadfully powerful. To avoid falling victim to this, a good rule of thumb is that words are awesome to use, and they're more secure, but they're only about as secure as two random characters (three with a rich vocabulary including 3 or more of: arcane words, uncommon foreign words, uncommon misspelled words, uncommon proper nouns, l33t-speak...). So that 13-char "secure password" you use that looks like metropolitan8 effectively only has three or four characters to a dictionary attacker, and that clever 14-char password of spageti4dinner has only five or six, depending on how good the attacker's dictionary is at misspelled words. A tip: put punctuation inside your words to break them up (without forming words), e.g. metr[opo;%litan8, and you've pretty much defeated the dictionary attack.
This is diffs the dissembled version of the original against the update on the server, then does the opposite on the client. I couldn't help but think of this as similar to Gentoo's model... download a compressed diff of the source and then recompile. Both have the same problem: too much client-side CPU usage (though Gentoo's is an extreme of this). Isn't Google Chrome OS primarily targeting netbooks? Can such things handle that level of extra client-side computation without leaving users frustrated?
I'd rather improve the distribution model. Since packages are all signed, SSL and friends aren't needed for the transfer, nor does it need to come from a trusted authority. Bittorrent comes to mind. I'm quite disappointed that the apt-torrent project never went anywhere. It's clearly the solution.
This is unchanged from the average (71.6% v 19.84%) or the oldest data in Dec '08 (70.8% v 20.8%).
There is no growth here, just the obvious resistance to change in the corporate world, which will be more reflected in Windows (IE6) than anything else.
.
We'll only really see the demise if IE6 when the corporate world fully adopts the next OS, which would be Windows 7, a year or three after its first service pack (assuming MS plays it smart). That means we're stuck with IE6 for at least another 2-3 years.
(Yes, I know that a large percentage of corporate deployments are still on Windows 2000. If they're moving to XP but aren't already too far along, it will hopefully be with IE7 or IE8, or even something else entirely.)
I don't understand where we're going here... If we group tabs, that lets us have MORE of them. The biggest problem with web browsing is that we have too many tabs, not that we lack space for them (that's the next problem!).
Like many people, I tend to leave tabs open for months on-end, as a sort of bookmark with slightly more immediacy. This doesn't need to consume resources:
I'd like to see a second level of caching; tabs ignored for long periods of time (default=12h?) just cache a PNG screenshot of each old tab and reload it (from disk cache or a deeper level of disk cache) when the user clicks on that screenshot. This would be especially useful for restoring sessions (no more password prompt!).
If a major player, usually seen as a freemail provider like google or yahoo, but certainly also any large corporation or government agency, were to simply start reporting their spam, the problem would go away.
Beef up and aid services like KnujOn and SpamCop and remove the ease of sending spam and (more importantly) the profitability. But that only goes so far -- it nails the pseudo-legit spammers, but it only slightly hampers the straight-up criminal ones (while eliminating their competition).
The next step is escalation; like Blue Security, create a do-not-email list (using hashed emails for privacy) and then after a lack of response from SpamCop's reports, utilize the opt-out requirement of the CAN-SPAM law to essentially flood the spammer with unsubscribe requests. I've detailed this proposal, along with how to decentralize it to make it immune to the DDoS that stopped Blue Software, on my website at http://khopesh.com/wiki/Ending_spam
I know Red Hat employs Drepper (or something like that), but a move by Debian has little meaning without support from other sources. It's been shown that even Ubuntu doesn't always follow suit with its upstream Debian Sid (e.g. they ship Firefox, not Iceweasel).
This absolutely MUST gain traction. Somebody must bite. Nokia could put it in Qt Embedded, Fedora could use it by default (and thus pressure Red Hat), Ubuntu could take a real look at it, FreeBSD could make the move, the Free Software Foundation could make a statement, etc.
Otherwise, we risk yet another rift in an already fractured community.
First: bravo. You have a wonderful voice and this will certainly open the door for a future in broadcasting. (Though you should invest in a spit-guard or whatever its' called so that your lip-smacking isn't as audible.)
Second: that's too much data at too high a frequency for me... how about a weekly podcast summing the week's activity (highlights only) in five minutes for an average activity week and ten minutes for a busy one? ("Busy" being relative not to traffic but rather notable insight.) Yes, this will require more editorial work (sorry, and no, I'm not volunteering).
This would be similar to Linux Journal's diff -u, a 3/4-page article within their UpFront section, summing the kernel development news of the past month.
Those cables I linked come in easily opened soft plastic sleeves, and their ordering time is essentially free since you'll be ordering other things (that you can't make) from them anyway; we're talking about 30-90 seconds of extra ordering time with big-O(1). And no, I don't test manufactured cables unless I think there's a problem with them. Not worth the time (it's too rare an occurrence).
Sharing honey wine with the delivery guy is one thing, but shouldn't there be non-IT people for receiving packages?
Let's see. The average Silicon Valley mid-level network engineer makes $85k/y, which is $40/h. $1.49 / $40/h * 60m/h = 2.23m... so I suppose it's mostly a wash if you can reliably make a cable that fast or you're paid less.
However, there's also the cost of the heads, cable, boots, and the loss of quality that this article is talking about, plus the fact that you can't keep that kind of pace for ten reliable cables, and your error rate will be higher than the manufactured cables, even at a slower pace.
Plus, I'm sure you'd rather be doing something else.
Right, but there is more detail than what RMS was quoted as having said.
Specifically, it's okay to have SaaS when the AGPL is involved, e.g. at http://autonomo.us/ (a AGPL'd twitter app), and sometimes even when the GPL is involved, e.g. http://savannah.gnu.org/
However, there's one more big point to mention: We pay money (directly and/or with our data and ad-watching) for SaaS because they maintain this all for us. We don't need patches for bugs or security issues because they do it for us, arguably better than we can. As to new features, well that's where RMS's points hit home.
I agree; you can get such things from internet resellers for dirt cheap these days. The math boils down to: $1.49 / ~5m × 60m/h = $17.88/h so if you make more than $17.88/h ($36000/y), it's cheaper to buy the superior cable online. Plus, it means you can spend more time on more important issues that can't otherwise be outsourced (e.g. fix that damn server).
However, I've found that the extra cables I like having lying around seem to walk away. Having the spool, heads, and crimper for custom cables also means I can create a standard-length cable in a pinch when there are no spare cables. Suddenly, that $1.49 cable gets storefront premiums, tax, gas money, AND your time at the store (or a hefty overnight shipping fee) versus just crimping the damn cable.
(Yes, I also have another solution -- a box of cables hidden in my office. shhh...)
That's right, all this for 14 giant-size icons on 14 pages of ads and other garbage to read the 14 sentences of text that contain all the important info.
Or I could paste them here.
Linux Foundation: The architecture of the OpenPrinting web-service will be overhauled to alleviate resource consumption, OpenJDK will become LSB compliant, and setting-up an access point will become easier in Linux under some of the 11 projects run for the Linux Foundation.
Mozilla Project: The Mozilla Project has 10 initiatives for the program this year, including automated duplicate detection for Bugzilla; integration of pre-existing, third-party extensibility into Ubiquity; and improvements to the Register Allocator of Trace Monkey.
OpenSUSE: Nine projects will be sponsored by OpenSUSE including porting from openSUSE to ARM; an implementation of the YaST education module; synchronisation with mobile devices; and porting openSUSE to MIPS.
Drupal: Drupal will receive a peer review platform for its forum, and API integration for Google Analytics under 18 sponsored projects for the Summer of Code this year. Others include: completion of version control integration and deployment to Drupal.org; a usability testing suite; and plans to 'make Drupal smart'.
KDE: KDE will sponsor 38 projects including: improving search and virtual folders in KDE4; plasma media center components; a crossplatform authentication and authorisation framework; weather support and enhanced plugin features for Marble; and finishing the Amorok playlist with multilevel playlist sorting.
Debian: Integration with the Amazon EC2 cloud service; automatic debug package creation and handling; and rewriting the Debian autobuilding infrastructure are all part of Debian's 11 projects accepted in this year's Google Summer of Code.
Apache Software Foundation: The Apache Software Foundation will sponsor 38 projects including: adaptive query targeting in distributed database environment; a Java debugger command line tool; Web-based management console for ServiceMix; a new user interface for the Apache Qpid JMX management console; and empowering Google Android applications to easily consume business services.
GIMP: An advanced GUI for brush dynamics and an improved nonlinear resampler with built-in antialiasing are some of the 6 projects sponsored by the GNU Image Manipulation Program (GIMP). Other initiatives include a "fast adaptive resampler tailored for transformations which mostly downsample", and some improvements to the foreground selection tool.
GIT: GIT will get 2 projects this year, which will add caching support to git-daemon, and an interactive graph GUI.
GNOME: The GNU Object Model Environment (GNOME) will sponsor 25 projects that will make conduits work as a daemon; integrate bugzilla into pulse; add support for Nautilus to Google docs; allow GNOME-Sudoku to be played with IM contacts; and improving the DVB experience with GNOME DVB daemon.
Joomla!: Eighteen projects are being sponsored by Joomla! in the program this year. Error handling will be improved; a common gateway will be added f
Except there's nothing particularly new, innovative, or resistant to AV in conficker. Conficker came to exist long after the vulnerability it exploits was publicly fixed. It is trivially detectable...
I don't disagree with your assessments, but that's not what I was talking about, either. The point is that we have no idea of what it can do. We know exactly how it got there.
As to how this relates to a virus acting as an anti-virus: When I said not detectable, I meant from the perspective of the everyday [l]user, not a security expert or security software. A zombie master wants his/her zombies to be otherwise clean and operable with minimal intrusion upon the system, as this minimizes detection and maximizes the zombie's potential uses (for the zombie master, but also for the user). Suppose this intrudes less than more typical anti-virus software but provides similar protection...
Because there is so much money to be made by botnets these days, it has moved from a "look what I can do" feat to a real business in its own right (legality aside). It is widely assumed that Conficker is among the first of a new breed of very carefully produced viruses and worms, written by professional developers who are paid quite well for their computer security and anti-anti-virus skills.
This class of developer knows exactly how the anti-virus companies work. It should have been expected by the Conficker designers that their virus would be examined in isolated networks. The designers would therefore be able to take advantage of that (it's easy enough to detect -- no word from the master servers, no ability to further infect, etc), and that's what we saw yesterday. Planned panic for no reason. At this point, most people think Conficker is either no serious threat, or an April Fools' Day prank. These people could be very wrong.
With the pressure off, infected machines are now able to go about their intended business, which could be sending spam, using distributed computing, farming user data, coordinated attacks of one type or another, or merely a conspiracy to protect computers from infections (a virally spreading anti-virus utility that you can't detect, stop, or remove? ingenious!).
The merits of a secret anti-virus product are more down-to-earth than you might think; most high-end zombie masters write their viruses so that they can't be detected by users and so that they are the sole "pwners" of the system -- competition is bad in this field. What you end up with is zombie masters who are suddenly interested in maintaining your computer for you - virus-free (save their virus), clean, efficient. If this zombie master is your federal government, merely reserving the right to use ("draft") your system as a "minute man" for emergencies where your computing power or attacking capabilities are needed, that might be a fair "tax."
This is composed purely of commodity parts. The power supply is the same thing you'd buy for your desktop, those are SATA disks (not SAS), and that looks like a desktop motherboard (see the profile view where all the ports on the "back" are lined up in the same manner they would need for a standard desktop enclosure).
Only the battery is custom (or even non-consumer grade), and you can note that since the power goes through the PSU first, that's DC power. DC is significantly better than AC, since the PSU then has to convert AC-to-DC (which wastes power and generates needless heat). While you can get DC battery supplies for server-grade systems, these are not server-grade systems. Built-in DC battery backup therefore affords them the ability to keep the motherboards cheaper. Very smart.
Also, if you recall from a few months ago, Google has applied pressure on its suppliers (I'm not sure why Dell comes to mind...) to develop servers that can tolerate a significantly higher operating temperature (IIRC, they wanted at 20 degree (Fahrenheit?) boost). I wouldn't be surprised if the higher temperature cuts down on operating expenses more than smarter battery placement.
I've actually proposed something very similar to this before, called a Solicited Bulk Realtime List, which would be an elaborate DNSBL-style spamtrap whose purpose is determining which lists play fair (no-unsubscribe vs opt-out vs opt-in vs confirmed-opt-in) regardless of solicitations. Such an index would enable users to safely unsubscribe, and perhaps more importantly, its widespread adoption would force all "list" emailers, be they spammers or not, to better implement subscription management.
SBRL would also enable the ability for a filter to set a threshold for new list mail. Let's say I completely block any "list" mail that the SBRL can't confirm unsusbscribe works, and then I count a day's incoming confirmed-opt-in emails plus twice the number of the remaining emails (opt-in/opt-out). Anything over my threshold gets digested just like a mailman list with the digest feature (a collection of all of them that came in over the day) rather than direct delivery.
An IT-grade implementation could have new addresses start at a high threshold (e.g. 10) and then lessen by one per business day until it hits the default threshold, e.g. 3.
Slackware was the Daddy. Like the God Amen, Slackware created himself.
Yes, that's one of my favorite mythological editing blunders: Atum (later lumped in with Amun and Re) was a creator god, first-born of the gods, who birthed himself from the waters of chaos (later personified as the god Nun) by His own will. The god Thoth, scribe of the gods, was on hand to record this birth of the first god.
I love Ancient Egyptian mythology, if for no other reason than the wonderful editing it went through when various cities unified (and thus merged their religions). Christianity is messed up too, but people ignore the inconsistencies (have you sacrificed any animals lately? Heathen?)
Slashdot Mirror
The principle of net neutrality will be established in international law, ensuring that the network will not discriminate against the traffic that passes across it. Any discrimination will be left to the end points, the clients, for people to decide for themselves what they censor, what communications they will or will not countenance.
...
It will also force governments to co-operate with one another to tackle the net's security vulnerabilities. It should force them to exchange data about security problems and work collaboratively to solve them and keep net criminals and military aggressors in their animal pens.
Great step in the right direction, those are the two issues I wanted to see addressed. I hope it's strongly phrased so as to strictly prohibit government-sponsored attack vectors like DDoS et al, as it appears from the above paragraph that it's aimed at spammers and other profiteers, completely missing the military possibilities.
As an FYI, here's the WikiPedia article on the Outer Space Treaty.
Keep in mind that it's not enough to just have 40 HDCP devices, you also have to crack them all, which involves either some really clever known-plaintext attacks or disassembling the firmware on each device.
An engineer working for a company that has made (or prototyped) 40+ HDCP devices would probably have access to the needed data, which can then be copied, brought home, and evaluated. (My hasty reading of) Blom's scheme suggests that the calculation given that data isn't terribly complex. Since this puts that techie's job in jeopardy, the results would need to be revealed anonymously. Otherwise, I see little reason for not taking credit. ... unless this is a top-level leak.
Search for "loopt" to take a look. It appears that AT&T has already opted everybody into it, and you can pay money to track your friends who haven't specifically opted out. I was able to opt out on the online payment area ... I only found it by digging around the preferences.
He's "bitching" because maintaining a scraper is intensely time-consuming (trust me, I've written many many scrapers and greasemonkey scripts, including a Scroogle userscript). The IE portal was static for years upon years (see TFA), so the scraper needed no maintenance, which is quite different from any other results display.
However, writing a minimal stripping scraper shouldn't be too hard. Here's an email I sent to Scroogle:
I can't find any info on recent Lightning work (aside from the fact that the nightlies are still being pumped out) ... the developer blog is offline (is mozillazine dead? their front page last speaks from June 2009...), and the Mozilla Calendar development roadmap was last updated about year ago.
Nevertheless, the roadmap's stated plan is to release Lightning 1.0 shortly after Thunderbird 3.0 ... no idea if that's still on track. If I recall correctly, the calendaring portion was so side-tracked that they removed it from TB3 altogether, also shunting all(?) Mozilla-(corporate)-sponsored time away from it. OpenOffice.org is actually the bigger pushing body for TB3 as an MS Outlook killer (which means a calendar is desired), but Oracle's purchase of Sun may have rearranged (or deferred) priorities.
When TB gets native calendaring, I'll push hard on migration from Outlook for my corporation. If Lightning becomes as stable and ready as Enigmail (which is to say that politics are the only barring element from inclusion), I may make that push anyway ... but a streamlined integration is essential in the long run, and resistance to that makes me balk.
(Remember, Iron is the no-phone-home, no-spyware, privacy-assured derivative of Chrome.)
Despite that, I hope to see a version of Iron based on the upstream's beta soon. When it comes out, it would be announced on the SRware forums.
Also interesting: The Google Chrome download page requires javascript!
You need a JavaScript-capable browser to download this software. Click here for instructions on how to enable JavaScript in your browser.
Dear Google - If you want to speed up the web as you so claim, and you're genuine in your interest, why is this not Free Software? Why are Google Wave and Google Android (both easily more profitable if closed up!) open platforms, but not this one (NOT profitable regardless of closed/open nature)? There is *NO* way you can compete with the last-mile (ISP) caching servers with respect to latency, so the only advantage comes from your minor optimization tweaks.
If you share these tweaks with the world, we can (a) see your transparency and your genuine interest in speeding up the net without so obviously gaining more data and --more importantly-- (b) the lower-latency last-mile providers such as ISPs, datacenters, and IT departments can actually deploy your superior technology in places where it matters.
In fact, the only place I can see using open DNS servers with benefit are when there are other freedom-related issues (censorship in specific), which of course lends itself to needing more transparency anyway!
The above post was also posted to http://forum.notebookreview.com/showthread.php?p=5573605#td_post_5572662 with a little more detail. This post predates the other by a few minutes (assuming properly synced clocks), so I'd guess it was the same person who posted both of them.
There are currently three hits for "i8kspeedfan" on Google, all of them having the exact same text; slashdot, a slashdot syndicator, and the above notebookreview page. Maybe it refers to i8kfan, which is probably similar enough to Linux/*nix's i8kutils, which apparently has no project/home page. All I can find is Debian's i8kutils package (though its maintainer claims he is no longer maintaining it). The source is hosted with a direct tgz link from that page.
I mis-read my notes; that 100k/s figure for your standard desktop is actually 100M/s and comes from the password cracking competition at distributed.net. According to their current live stats, the fastest single-CPU system (an Intel Core i7 2666Mhz) is cracking ogrng at 204M/s and the average is 5.5M (with a wild standard deviation of 8.6M) and from current live multi-CPU stats, a 4-CPU Intel Core 2 quad-core (16 cores) at 3110MHz is cracking rc572 at 450.8M/s and the average is 36M (stdev=51M). That puts 100M/s at more than a standard deviation above average for even a multi-CPU system and more than ten standard deviations above the average single-CPU system.
The PS3s at 200k apiece look pretty measly now, falling well under the average desktop on Dnet (5.5M). Since even an AMD K6 can crunch away at 300k/s on rc572, it's probably reasonable to say that they're cracking something tougher than anything at Dnet. Generously pinning the PS3 to the Intel Core 2 Quad 3GHz (40M/s) means dividing my Dnet numbers by 200 or multiplying the government's numbers by 200.
At 40M/s times the 60 PS3s, we'd come to 2.4G/s, which can break an 8-character alphanumeric password in a day and an 8-character random printable (includes punctuation et al, 6.5 bits of complexity) in 22.7 days. Bring that to ten characters or six characters plus two words and you're suddenly talking about 500 years. Assuming they actively upgrade with no loss to data (to fit Moore's Law) and you're looking at 9 years ( log2(500) ).
I figure military-grade is probably 10-100G/s (with continuous upgrades according to Moore's Law), which would still take 3-7 years to find a 10-char password but blows through the 8-char password in 4-7 hours.
I've done a lot of password-cracking math, even toyed with the idea of writing an academic paper on it. Generally, I work on the (generous) assumption that a well-groomed single node can chunk through 100k passwords per second and that things scale perfectly, so 20 nodes would work through 2M passwords per second. They're claiming their 20-node cluster can handle twice that, and I fully believe it. Powerful GPUs are known to perform extremely well on password cracking, and PS3s certainly have them. That's twice the performance for half to a fifth the cost. Nice, but not "OMG."
They plan to scale up to 60 nodes, which is 12M pass/s. To break a 8-character monospace password (37 bits of complexity, which is pretty weak), it would take just under five hours ( 26^8/(12*10^6) /60/60 ). However, to break an 8-character alphanumeric password (case and numbers), that becomes seven months ( (26+26+10)^8/(12*10^6) /60/60/24/365*12 ).
This is only scary when you have a super-intelligent dictionary attack. Scrape the hard drive and any subpoenaed documents for words and add that to a dictionary of common password parts, then perform your dictionary attack -- dreadfully powerful. To avoid falling victim to this, a good rule of thumb is that words are awesome to use, and they're more secure, but they're only about as secure as two random characters (three with a rich vocabulary including 3 or more of: arcane words, uncommon foreign words, uncommon misspelled words, uncommon proper nouns, l33t-speak ...). So that 13-char "secure password" you use that looks like metropolitan8 effectively only has three or four characters to a dictionary attacker, and that clever 14-char password of spageti4dinner has only five or six, depending on how good the attacker's dictionary is at misspelled words. A tip: put punctuation inside your words to break them up (without forming words), e.g. metr[opo;%litan8, and you've pretty much defeated the dictionary attack.
This is diffs the dissembled version of the original against the update on the server, then does the opposite on the client. I couldn't help but think of this as similar to Gentoo's model ... download a compressed diff of the source and then recompile. Both have the same problem: too much client-side CPU usage (though Gentoo's is an extreme of this). Isn't Google Chrome OS primarily targeting netbooks? Can such things handle that level of extra client-side computation without leaving users frustrated?
I'd rather improve the distribution model. Since packages are all signed, SSL and friends aren't needed for the transfer, nor does it need to come from a trusted authority. Bittorrent comes to mind. I'm quite disappointed that the apt-torrent project never went anywhere. It's clearly the solution.
This is misrepresentative and a sign of false hope; IE has lost no ground to FF according to that chart:
IE7 + IE6 + IE8 = 43.51 + 18.23 + 8.26 = 70.0% share
FF3 + FF2 + FF1 = 18.58 + 1.45 + 0.17 = 20.2% share
This is unchanged from the average (71.6% v 19.84%) or the oldest data in Dec '08 (70.8% v 20.8%).
There is no growth here, just the obvious resistance to change in the corporate world, which will be more reflected in Windows (IE6) than anything else.
.
We'll only really see the demise if IE6 when the corporate world fully adopts the next OS, which would be Windows 7, a year or three after its first service pack (assuming MS plays it smart). That means we're stuck with IE6 for at least another 2-3 years.
(Yes, I know that a large percentage of corporate deployments are still on Windows 2000. If they're moving to XP but aren't already too far along, it will hopefully be with IE7 or IE8, or even something else entirely.)
I don't understand where we're going here ... If we group tabs, that lets us have MORE of them. The biggest problem with web browsing is that we have too many tabs, not that we lack space for them (that's the next problem!).
Like many people, I tend to leave tabs open for months on-end, as a sort of bookmark with slightly more immediacy. This doesn't need to consume resources:
I'd like to see a second level of caching; tabs ignored for long periods of time (default=12h?) just cache a PNG screenshot of each old tab and reload it (from disk cache or a deeper level of disk cache) when the user clicks on that screenshot. This would be especially useful for restoring sessions (no more password prompt!).
With this second level of caching, extra tabs can be afforded, and things like tab grouping, tab trees, and multi-row tabs become feasible.
If a major player, usually seen as a freemail provider like google or yahoo, but certainly also any large corporation or government agency, were to simply start reporting their spam, the problem would go away.
Beef up and aid services like KnujOn and SpamCop and remove the ease of sending spam and (more importantly) the profitability. But that only goes so far -- it nails the pseudo-legit spammers, but it only slightly hampers the straight-up criminal ones (while eliminating their competition).
The next step is escalation; like Blue Security, create a do-not-email list (using hashed emails for privacy) and then after a lack of response from SpamCop's reports, utilize the opt-out requirement of the CAN-SPAM law to essentially flood the spammer with unsubscribe requests. I've detailed this proposal, along with how to decentralize it to make it immune to the DDoS that stopped Blue Software, on my website at http://khopesh.com/wiki/Ending_spam
I know Red Hat employs Drepper (or something like that), but a move by Debian has little meaning without support from other sources. It's been shown that even Ubuntu doesn't always follow suit with its upstream Debian Sid (e.g. they ship Firefox, not Iceweasel).
This absolutely MUST gain traction. Somebody must bite. Nokia could put it in Qt Embedded, Fedora could use it by default (and thus pressure Red Hat), Ubuntu could take a real look at it, FreeBSD could make the move, the Free Software Foundation could make a statement, etc.
Otherwise, we risk yet another rift in an already fractured community.
First: bravo. You have a wonderful voice and this will certainly open the door for a future in broadcasting. (Though you should invest in a spit-guard or whatever its' called so that your lip-smacking isn't as audible.)
Second: that's too much data at too high a frequency for me ... how about a weekly podcast summing the week's activity (highlights only) in five minutes for an average activity week and ten minutes for a busy one? ("Busy" being relative not to traffic but rather notable insight.) Yes, this will require more editorial work (sorry, and no, I'm not volunteering).
This would be similar to Linux Journal's diff -u, a 3/4-page article within their UpFront section, summing the kernel development news of the past month.
Those cables I linked come in easily opened soft plastic sleeves, and their ordering time is essentially free since you'll be ordering other things (that you can't make) from them anyway; we're talking about 30-90 seconds of extra ordering time with big-O(1). And no, I don't test manufactured cables unless I think there's a problem with them. Not worth the time (it's too rare an occurrence).
... so I suppose it's mostly a wash if you can reliably make a cable that fast or you're paid less.
Sharing honey wine with the delivery guy is one thing, but shouldn't there be non-IT people for receiving packages?
Let's see. The average Silicon Valley mid-level network engineer makes $85k/y, which is $40/h. $1.49 / $40/h * 60m/h = 2.23m
However, there's also the cost of the heads, cable, boots, and the loss of quality that this article is talking about, plus the fact that you can't keep that kind of pace for ten reliable cables, and your error rate will be higher than the manufactured cables, even at a slower pace.
Plus, I'm sure you'd rather be doing something else.
Right, but there is more detail than what RMS was quoted as having said.
Specifically, it's okay to have SaaS when the AGPL is involved, e.g. at http://autonomo.us/ (a AGPL'd twitter app), and sometimes even when the GPL is involved, e.g. http://savannah.gnu.org/
However, there's one more big point to mention: We pay money (directly and/or with our data and ad-watching) for SaaS because they maintain this all for us. We don't need patches for bugs or security issues because they do it for us, arguably better than we can. As to new features, well that's where RMS's points hit home.
I agree; you can get such things from internet resellers for dirt cheap these days. The math boils down to: $1.49 / ~5m × 60m/h = $17.88/h so if you make more than $17.88/h ($36000/y), it's cheaper to buy the superior cable online. Plus, it means you can spend more time on more important issues that can't otherwise be outsourced (e.g. fix that damn server).
However, I've found that the extra cables I like having lying around seem to walk away. Having the spool, heads, and crimper for custom cables also means I can create a standard-length cable in a pinch when there are no spare cables. Suddenly, that $1.49 cable gets storefront premiums, tax, gas money, AND your time at the store (or a hefty overnight shipping fee) versus just crimping the damn cable.
(Yes, I also have another solution -- a box of cables hidden in my office. shhh...)
That's right, all this for 14 giant-size icons on 14 pages of ads and other garbage to read the 14 sentences of text that contain all the important info.
Or I could paste them here.
Except there's nothing particularly new, innovative, or resistant to AV in conficker. Conficker came to exist long after the vulnerability it exploits was publicly fixed. It is trivially detectable ...
I don't disagree with your assessments, but that's not what I was talking about, either. The point is that we have no idea of what it can do. We know exactly how it got there.
As to how this relates to a virus acting as an anti-virus: When I said not detectable, I meant from the perspective of the everyday [l]user, not a security expert or security software. A zombie master wants his/her zombies to be otherwise clean and operable with minimal intrusion upon the system, as this minimizes detection and maximizes the zombie's potential uses (for the zombie master, but also for the user). Suppose this intrudes less than more typical anti-virus software but provides similar protection...
Because there is so much money to be made by botnets these days, it has moved from a "look what I can do" feat to a real business in its own right (legality aside). It is widely assumed that Conficker is among the first of a new breed of very carefully produced viruses and worms, written by professional developers who are paid quite well for their computer security and anti-anti-virus skills.
This class of developer knows exactly how the anti-virus companies work. It should have been expected by the Conficker designers that their virus would be examined in isolated networks. The designers would therefore be able to take advantage of that (it's easy enough to detect -- no word from the master servers, no ability to further infect, etc), and that's what we saw yesterday. Planned panic for no reason. At this point, most people think Conficker is either no serious threat, or an April Fools' Day prank. These people could be very wrong.
With the pressure off, infected machines are now able to go about their intended business, which could be sending spam, using distributed computing, farming user data, coordinated attacks of one type or another, or merely a conspiracy to protect computers from infections (a virally spreading anti-virus utility that you can't detect, stop, or remove? ingenious!).
The merits of a secret anti-virus product are more down-to-earth than you might think; most high-end zombie masters write their viruses so that they can't be detected by users and so that they are the sole "pwners" of the system -- competition is bad in this field. What you end up with is zombie masters who are suddenly interested in maintaining your computer for you - virus-free (save their virus), clean, efficient. If this zombie master is your federal government, merely reserving the right to use ("draft") your system as a "minute man" for emergencies where your computing power or attacking capabilities are needed, that might be a fair "tax."
This is composed purely of commodity parts. The power supply is the same thing you'd buy for your desktop, those are SATA disks (not SAS), and that looks like a desktop motherboard (see the profile view where all the ports on the "back" are lined up in the same manner they would need for a standard desktop enclosure).
Only the battery is custom (or even non-consumer grade), and you can note that since the power goes through the PSU first, that's DC power. DC is significantly better than AC, since the PSU then has to convert AC-to-DC (which wastes power and generates needless heat). While you can get DC battery supplies for server-grade systems, these are not server-grade systems. Built-in DC battery backup therefore affords them the ability to keep the motherboards cheaper. Very smart.
Also, if you recall from a few months ago, Google has applied pressure on its suppliers (I'm not sure why Dell comes to mind...) to develop servers that can tolerate a significantly higher operating temperature (IIRC, they wanted at 20 degree (Fahrenheit?) boost). I wouldn't be surprised if the higher temperature cuts down on operating expenses more than smarter battery placement.
I've actually proposed something very similar to this before, called a Solicited Bulk Realtime List, which would be an elaborate DNSBL-style spamtrap whose purpose is determining which lists play fair (no-unsubscribe vs opt-out vs opt-in vs confirmed-opt-in) regardless of solicitations. Such an index would enable users to safely unsubscribe, and perhaps more importantly, its widespread adoption would force all "list" emailers, be they spammers or not, to better implement subscription management.
SBRL would also enable the ability for a filter to set a threshold for new list mail. Let's say I completely block any "list" mail that the SBRL can't confirm unsusbscribe works, and then I count a day's incoming confirmed-opt-in emails plus twice the number of the remaining emails (opt-in/opt-out). Anything over my threshold gets digested just like a mailman list with the digest feature (a collection of all of them that came in over the day) rather than direct delivery.
An IT-grade implementation could have new addresses start at a high threshold (e.g. 10) and then lessen by one per business day until it hits the default threshold, e.g. 3.
Slackware was the Daddy. Like the God Amen, Slackware created himself.
Yes, that's one of my favorite mythological editing blunders: Atum (later lumped in with Amun and Re) was a creator god, first-born of the gods, who birthed himself from the waters of chaos (later personified as the god Nun) by His own will. The god Thoth, scribe of the gods, was on hand to record this birth of the first god.
I love Ancient Egyptian mythology, if for no other reason than the wonderful editing it went through when various cities unified (and thus merged their religions). Christianity is messed up too, but people ignore the inconsistencies (have you sacrificed any animals lately? Heathen?)