I live in an urban area, and although we have mail slots (five feet from the street, no great trouble for the mail carriers), we have to use the blue boxes on the streetcorners for outgoing mail. The reason is straightforward -- outgoing mail gets stolen. A lot of outgoing mail is used to pay bills, and so may contain money or identifying information useful for identity/credit theft. Small-scale identity theft and meth use are trending together (it requires time and concentration, which I gather methamphetamines provide), and stealing mail is one way to go about it.
The blue boxes probably aren't hugely secure since they depend on a lock with likely little diversity in the keys, but that aspect aside they're big sturdy steel things bolted to the ground, placed in visible and generally well-lit locations. Without them, folks living in this area would have go go to an actual post office, mail things at work, or perhaps retail stores would step in to fill the gap.
It's not just supported. The grocery thing is all about Prime. It's a tool to encourage people to buy Prime memberships, and to give members a reason to order and renew.
To understand this sort of thing you have to think about three issues: supply chains, inventory management and fulfillment. They're the three biggest logistical issues in retail. Actually building stores or finding customers or selling them stuff... a bit further down the list. For a big retail company, huge amounts of money are gained or lost based on those three processes, and small changes there have a far bigger effect than anything that goes on in a store. The supply chain is about getting ahold of the stuff you're going to sell. But getting it in just the right amounts, in the right places, at the right times, with the right number of nines in the probability it'll all happen correctly and the right number of zeroes in the dollar penalty if it doesn't. A "bubble" in the supply chain, where a shipment was late, equals lots of lost revenue -- not just in the store, but in the warehousing and all the disruptive ripple effects. It doesn't take much to disrupt a supply line -- a breakdown in a loading dock, a storm that delays a cargo carrier out of China from making port in Oakland or Los Angeles. You can see why big retailers like Target, Walmart or Amazon are so union-hostile; their systems are extremely vulnerable, and the economic impact of a strike has magnified.
Then there's inventory. If you're in the business of selling stuff, inventory is bad. You have to pay for the shelf it's sitting on, you have to keep it from getting wet or dirty (if it's perishable, you have to pay to keep it cold). And it's depreciating every minute it sits on your shelf, representing a paper loss you have to explain to the shareholders. Plus, it's taxable. Remember how smaller shops used to be out of everything around the end of the fiscal year? If you asked the shop keeper, he'd look a little frazzled and mumble "inventory," 'cause he was trying to get rid of as much as possible of it before the IRS made him pay taxes on it. Big retailers don't do that anymore, because they own so little inventory it doesn't hurt them -- and often they don't own the inventory that's on their warehouse or store shelves at all. The shift in power from the manufacturers to the retailers over the last decade or so displaced the tax burden of ownership back to the manufacturers, who in turn shift it backwards to their own supplies or subsidiaries, often in Asian countries that don't tax physical assets. The ideal arrangement from a retailer's point of view would be for the warehouses to have no shelves at all, but simply to be this giant tube through which products were hurled, changing quantities or packaging a little bit in midair, and never touching the floor once before landing in a different truck on the far side of the tube.
And then, fulfillment. For Amazon, that's putting the items in a box and tossing it into the UPS truck. For a big-box retailer it's putting a pallet of them on a truck and driving it to the store. It's a difference of scale made a little earlier on, but fundamentally it's no different. Products need to be physically located near the point of sale (that's the store the customer walks into or the room their web browser was in, whichever) to get it to them cheaply. That's "near" in terms of cost, which is sort of like physical distance but not precisely. The right amounts of inventory (or better, supply chain infeeds) need to be pre-positioned on transit arteries that can reach the stores with the demand or the shipping carriers' local shipping centers as quickly and cheaply as possible. Good highways, good weather, complaint carriers, cheap labor, and union leaders run out of town by a compliant local government eager for the thousands of low-wage jobs you're promising to bring in. Costs to get the product into customer's hands need to be minimized, whether that's with an effective supply system to brick-and-mortar
It varies. Some cars are loud. Some sections of track are loud; the tunnels under SF itself tend to be louder than those in the east bay, especially the high-speed sections south of Mission. Tunnels are inherently loud places. BART cars have a sort of trademark squalling sound you hear at speed in tunnels, especially when turning. For the most part it's easy to carry on a conversation with only slightly raised voices, but occasionally it's easiest just to pause for ten seconds until you pass that stretch of track.
Already do. BART has had ads in the stations and in the cars for at least the past year, encouraging cellphone users to maintain civil volumes.
For the most part the cellphone users on BART (and there are a fair number of them) seem to be pretty decent about it. I ride BART twice a day, and encounter two or three cellphone calls per trip. Perhaps once a week the user is loud enough to be a bother.
There seems to be some variation in the use of rum; my edition of Joy of Cooking gives nearly identical formulations for grog and toddy. I've had grog made with brandy instead of rum, and it's good that way also.
To summarize: splash lemon juice, 2oz rum (or brandy), large spoonful honey in a coffee mug. Fill mug the rest of the way with boiling water. Stir until honey dissolves. Optionally add cinnamon or clove. Do not inhale the fumes until it's cooled a bit.
I'm a Debian developer, and I haven't voted -- yet. I'll cast my DPL vote towards the end of the cycle, as usual. Here's why:
At the start of the cycle, I hadn't made up my mind. That's generally the case, except in one or two General Resolution votes where I already understood the issue under consideration (e.g. the non-free vote.)
I haven't finished reading the candidate platforms and debate material yet. When voting opens, the project leader debates are just freshly over. This year, since once again I couldn't attend them live, I have to read them afterward, which takes time. Last year the debate was cancelled, because an email debate had already occurred on debian-vote -- same situation. Voting in Debian is just like voting anywhere else, you often have to do a lot of reading to understand the issues. Debian developers are shy about this right now, because the Social Contract clarification vote a ways back opened a huge unforseen can of worms concerning the freeness of documentation, and derailed Sarge again, until a second vote was undertaken to put the issue off until post-Sarge.
With Sarge at a release tipping point (RC3 on the installer, and the Vancouver proposal still kicking around), I delay voting so I can see how those issues play out and adjust my planned vote.
My local Debian meetup is unpredictable, and there might be one, where some longtime DDs show up and can enlighten me on the machinations going on in the Debian functional committees. You know, all those smoke-filled rooms in which the ftpmasters and application managers and buildd administrators meet to shoot heroin and plot how they're going to sabotage the next planned release date and sell the sparc porters into slavery or whatever.
Google's users are already causing plenty of headaches for the rest of Usenet. Usenet participation on Google Groups is up a good deal since they switched over to their gmail-style interface, and had been growing steadily even before that.
Problem is, the new google-groups system has a number of interface problems which cause problems for everyone else on usenet -- the most serious of which tend to cause posters to reply to random points in established threads, and to post without any quoting to supply context. The UI does have a reply feature which supplies quoting, but it's hidden inside a DHTML-popout zone, while the large obvious "Reply" link offers no quoting. Their UI flattens threads, which leads users to lose track of thread structure and reply to the wrong post, confusing everyone.
Further, because they store infinite history, Google users who search around sometimes reply to months- or years-old threads which are no longer on anyone's news server and which make no sense outside of context.
I help moderate a newsgroup, and Google's users are causing no end of frustration and annoyance. It's hard to say whether the endless-September phenomenon of Google's ill-behaved userbase is really up to the standards of 1993 -- back then the AOL influx was apalling, but we had a fairly different signal-to-noise situation then. Maybe we're all just inured to this sort of thing by now.
OSX version of the screensaver downloaded on the afternoon of 26th November, compared to download just now (second checksum for reference, download it yourself as a hedge against a compromised server giving back good data to hosts known to have already downloaded the file).
Lines wrapped to reduce mangling.
- -rw-r--r-- 1 aqua staff 1120108 26 Nov 14:19 \.Trash/MLNS_screensaver_en.dmg ea8c53d0fb0f30faf3 6b93064936c6cf.Trash/MLNS_screensaver_en.dmg
- -rw-r--r-- 1 aqua staff 1120108 1 Dec 00:41 \
Desktop/MLNS_screensaver_en.dmg ea8c53d0fb0f30faf 36b93064936c6cf Desktop/MLNS_screensaver_en.dmg
Some. They still have the biggest share (31%) of the intel server market, but slipped a few percentage points during the recession, partly to Dell and IBM (disclaimer: just one source). HP losing some market share in 2001 and offering an Opteron server in 2004 seem implausible points of causality, though. If I were to speculate, HP's high level of diversification (relative to Dell, e.g.) and participation in the non-Intel server market reduces somewhat the influence over them by the Wintel duopoly. There's definitely a market demand for a viable 64-bit PC server platform. HP is perhaps a little more able to try to sell to that demand than an OEM more dependent on the favor of Intel et al.
Not that I'm fond of them as a company or anything, but my employer buys thousands of HP's servers, and HP has been selling Opteron-based servers (e.g.) for some while now. Even if AMD never achieved sufficient penetration with ia32, there's some hope that they'll gain some of the ephermeral credibility by being first to market with a workable ia32-compatible 64-bit architecture.
I made a related waggish proposal a couple of years ago:
1. Make tarball of backup 2. Encrypt if desired 3. Encode tarball, 4-8 bytes at a time, in email addresses 4. Put email addresses on web 5. Wait for spam
Presto -- spammers now pay for your backup; anytime you have a disk failure, just wait a while and watch your spamcan or smtp log, and reconstruct your backup at will.
(Some assembly required, offer void where prohibited)
I'd prefer a hard realtime system on general principles, but the description the engineer honcho gave was based on host PC control of lasing with a hardware interlock that cut off the power to the laser if it didn't receive a signal to continue from the host PC every millisecond (he may have been approximating). That insulates the system from overlong lasings; premature cutoff owing to crash or excess latency isn't going to blind someone. The remaining software problem to cover would be a fault whereby the host kept sending stay-on signals after it shouldn't, and that issue would be found regardless of OS.
Back to the principle, though, we trust DOS frequently to run elevators, flight control systems, security systems, etc. -- partly because there's very little DOS involved in those systems, and partly because it's never permitted to be a single point of failure in a safety-critical system. Somehow trusting anything to Windows 3.1, even with hardware interlocks, gives me creepy feelings.
This is going to sound like the total slashdot linux-zealot posting; sorry, but it happened.
In early 2000 the chief software engineer at LASIK came to give a talk before a Software Engineering course I was taking at Sonoma State (worthless CS program, but nevermind). He talked for most of an hour about various parts of the development process, hardware interlocks, millisecond-cutoff crash-detector watchdogs and so forth. Moderately interesting. At the end of a Q&A period, one student asked him what platform LASIK ran on -- since it had been explained that the machines had to be deployed to eye doctors' offices and be easy to use correctly and difficult to use wrongly, etc., etc. The answer, and I swear I'm not making this up, was "Windows 3.1." There was a pause while everyone in the room absorbed this, then he added "But we're considering porting it to Win95."
Useless pictures anyway, because the reviewer has apparently not learned the reason why one uses a tripod and remote shutter or timer for long-shots in the dark like this one. And in fact a crummy review; the reviewer spends more copy on his prepatory discussion than on factual recitation or summary, gives no details such as are often used in reviewing keyboards (break force, perceived resistance curve, decent travel, space between keycap edges, etc.) And I'm not sure where he got the idea, but "Natural" is a particular mark of ergo-contoured keyboard, not a description.
I'd still like to see a breakdown by state. I have a sneaking suspicion that most spam comes from sunny places -- southern California and Florida particularly.
Chinanet's attitude is utterly hostile. To the extent that one can communicate with them at all (only slightly worse than trying to communicate with any large american ISP, to be fair), they not only don't care, they will defend the spammer ("is not spam") or lie about its origins ("IP in report is wrong.") [quotes here from n.a.n-a.e] Giving them the benefit of the doubt (i.e. that they're not pernicious malevolent cretins and merely have a very different view of right and wrong in this matter), it's still impossible to deal with them on an individual basis. Maybe a government could. Or MSN, or AOL. But until that happens, all of Chinanet's known IP address blocks have a nice shiny DROP rule in my mailservers' firewalls, and any URL to a host in those blocks earns several points for spamassassin to work on.
Unfortunately for this sort of problem, there isn't an email equivalent to a Usenet Death Penalty (UDP). UDPs threatened or applied against major ISPs often tend to produce some meaningful action. Partly it works (to the extent that it does) because Usenet has a replication fabric controllable by a relatively small number of people, whereas email has no such system.
Maybe someone will stage a worm attack in the opposite direction from the usual -- writing a worm to scan the top spam sources lists and spamvertized website lists and DDoS them. It would do little for the problem directly, but it would increase the cost of doing business substantially for Chinanet and their kind. (okay, vigilante justice is usually very bad. But it's a fun fantasy.)
That does seem to be the current most typical case. Random cablemodem host acting as a zombie, pitching a website hosted by a spam-friendly ISP in China, Brazil or less commonly other places outside the US. There's still a not insignificant fraction being sent from China, Italy and Wanadoo Espana.
The tricky thing about summaries like this is that different spammers exhibit different techniques, and distributions of received spam are not at all uniform. Spammers reuse address lists, control hosts which are configured in various ways and are better or worse connected to different sections of the network, etc. So while I certainly get most of my spam from infected Comcast and similar hosts, I hestitate to say that's how it would be for, say, a user of one of the big email services, which might be attacked by spammers with different specialties.
The good news about the increased prevalence in use of compromised windows zombies as spam emitters is that it's legally more perilous to the spammer than direct-to-MX delivery. Safer in terms of improved concealment, but potentially more criminal. I say "potentially" because if there existed no provable collusion between the spammer and the virus author, and there probably wasn't, then it might legally be no worse than exploitation of an open SMTP relay, and those incidents never saw substantial prosecution. Depending on how careful the spammers are being chaining together zombies, it may be quite feasible to catch and prosecute them using honeypot zombie hosts. The DoJ just needs to take an interest. Or maybe of the cablemodem companies paying for this cost, like the negligent Spanish ISPs cited here, would be interested in backing a civil action.
While I'm not totally sold on the idea, it seemed to have enough promise to be worth trying. So here's a plugin to qpsmtpd, a replacement smtpd for qmail (it also delivers to postfix, IIRC). Implements most of the basic suggestions in SURBL's proposal.
(I'd like to be able to slap a bell and yell "first implementation!" in a childish slashdot fashion, but I'd be surprised if this really was the first, since it's easy to do a simple implementation and parallels similar DNSBLs in some respects.)
Bad webmaster. He who useth mod_rewrite to check HTTP_REFERER must also checketh it for emptiness, for lo do some persons care about their goddamn privacy a wee bit. No cookie for you.
I do like it as a partial solution (there aren't going to be any good total solutions in this affair). The benefits would probably accrue mainly to the big email services (Yahoo, Hotmail) whose domains are most often forged onto spam. Many people arbitrarily thow away mail purporting to come from there, which must be hurting them in some fashion. Since no one's going to reject mail on the basis of a missing RMX record, spammers will start forging mail from domains having no RMX records at all (or possibly a few serving 0.0.0.0/0 records). So probably not a strong benefit, but it'd help restore the viability of the major email services somewhat.
I do rather suspect that if RMX authentication were widely deployed we'll see DNS cache poisoning attacks come into vogue again. And if there's a set-in-stone system with an even larger deployed base than SMTP, it's DNS.
It's not as if the Dodo went extinct because it fell into obsolescence. It went extinct because the Dutch sailors and settlers arrived in Mauritius bringing rats and cats, then cut down half the forest and clubbed the few surviving dodos for sport. Not unlike MS' historical conduct in the software industry, come to think of it.
It's not safe to assume that at all. You can implement a HAL a number of ways, but one of the simpler, lighter-weight ones is just to use a layer of interface abstraction code in a kernel through which lowlevel driver code serves up the interface to a device through a common API -- for example, a common timer interface applied to a CPU's clock. There don't need to be any process space boundaries or linker divisions at all. There's at least one major OS using a HAL layer in this fashion -- it's a separate "component," but only to the same degree that the Linux kernel's IDE and block-layer subsystems are separate components.
Link-based licensing (compile-time or runtime) tends to get compilicated (or complicate things) in the embedded world, where many devices use single statically-linked system images. The conventional linking-based interpretation of the GPL's standalone-works stipulation (GPL section 2) is a bit awkward in that context. If you take a loose view of the link restrictions (e.g. accepting compile-time linkage), then the GPL contaminates the least part of the incorporating work that could "be reasonably considered independent and separate works" -- possibly a driver, a HAL, or the whole kernel.
Laika was, FWIW, the last animal launched by the Soviet space program with no intention of recovery; most of the subsequent animals launched were recovered, though several died in various accidents.
It wasn't that interactive of a session, but it went pretty well. The only two major reasons not to upgrade are that (1) most distros haven't adopted it as the stable-default yet, so you have to do the install by hand, and (2) using a threaded MPM you'll hit trouble if your CGIs depend on non-threadsafe libraries.
This latter is still the major obstacle, since the number of third-party libraries used by (say) PHP is pretty large. You can eliminate the threaded-MPM obstacles by using the process-based prefork MPM, but you don't get some of apache2's performance improvements, especially on operating systems with slow, expensive forks (Solaris, Win32).
Slashdot Mirror
I live in an urban area, and although we have mail slots (five feet from the street, no great trouble for the mail carriers), we have to use the blue boxes on the streetcorners for outgoing mail. The reason is straightforward -- outgoing mail gets stolen. A lot of outgoing mail is used to pay bills, and so may contain money or identifying information useful for identity/credit theft. Small-scale identity theft and meth use are trending together (it requires time and concentration, which I gather methamphetamines provide), and stealing mail is one way to go about it.
The blue boxes probably aren't hugely secure since they depend on a lock with likely little diversity in the keys, but that aspect aside they're big sturdy steel things bolted to the ground, placed in visible and generally well-lit locations. Without them, folks living in this area would have go go to an actual post office, mail things at work, or perhaps retail stores would step in to fill the gap.
It's not just supported. The grocery thing is all about Prime. It's a tool to encourage people to buy Prime memberships, and to give members a reason to order and renew.
To understand this sort of thing you have to think about three issues: supply chains, inventory management and fulfillment. They're the three biggest logistical issues in retail. Actually building stores or finding customers or selling them stuff... a bit further down the list. For a big retail company, huge amounts of money are gained or lost based on those three processes, and small changes there have a far bigger effect than anything that goes on in a store. The supply chain is about getting ahold of the stuff you're going to sell. But getting it in just the right amounts, in the right places, at the right times, with the right number of nines in the probability it'll all happen correctly and the right number of zeroes in the dollar penalty if it doesn't. A "bubble" in the supply chain, where a shipment was late, equals lots of lost revenue -- not just in the store, but in the warehousing and all the disruptive ripple effects. It doesn't take much to disrupt a supply line -- a breakdown in a loading dock, a storm that delays a cargo carrier out of China from making port in Oakland or Los Angeles. You can see why big retailers like Target, Walmart or Amazon are so union-hostile; their systems are extremely vulnerable, and the economic impact of a strike has magnified.
Then there's inventory. If you're in the business of selling stuff, inventory is bad. You have to pay for the shelf it's sitting on, you have to keep it from getting wet or dirty (if it's perishable, you have to pay to keep it cold). And it's depreciating every minute it sits on your shelf, representing a paper loss you have to explain to the shareholders. Plus, it's taxable. Remember how smaller shops used to be out of everything around the end of the fiscal year? If you asked the shop keeper, he'd look a little frazzled and mumble "inventory," 'cause he was trying to get rid of as much as possible of it before the IRS made him pay taxes on it. Big retailers don't do that anymore, because they own so little inventory it doesn't hurt them -- and often they don't own the inventory that's on their warehouse or store shelves at all. The shift in power from the manufacturers to the retailers over the last decade or so displaced the tax burden of ownership back to the manufacturers, who in turn shift it backwards to their own supplies or subsidiaries, often in Asian countries that don't tax physical assets. The ideal arrangement from a retailer's point of view would be for the warehouses to have no shelves at all, but simply to be this giant tube through which products were hurled, changing quantities or packaging a little bit in midair, and never touching the floor once before landing in a different truck on the far side of the tube.
And then, fulfillment. For Amazon, that's putting the items in a box and tossing it into the UPS truck. For a big-box retailer it's putting a pallet of them on a truck and driving it to the store. It's a difference of scale made a little earlier on, but fundamentally it's no different. Products need to be physically located near the point of sale (that's the store the customer walks into or the room their web browser was in, whichever) to get it to them cheaply. That's "near" in terms of cost, which is sort of like physical distance but not precisely. The right amounts of inventory (or better, supply chain infeeds) need to be pre-positioned on transit arteries that can reach the stores with the demand or the shipping carriers' local shipping centers as quickly and cheaply as possible. Good highways, good weather, complaint carriers, cheap labor, and union leaders run out of town by a compliant local government eager for the thousands of low-wage jobs you're promising to bring in. Costs to get the product into customer's hands need to be minimized, whether that's with an effective supply system to brick-and-mortar
It varies. Some cars are loud. Some sections of track are loud; the tunnels under SF itself tend to be louder than those in the east bay, especially the high-speed sections south of Mission. Tunnels are inherently loud places. BART cars have a sort of trademark squalling sound you hear at speed in tunnels, especially when turning. For the most part it's easy to carry on a conversation with only slightly raised voices, but occasionally it's easiest just to pause for ten seconds until you pass that stretch of track.
Already do. BART has had ads in the stations and in the cars for at least the past year, encouraging cellphone users to maintain civil volumes.
For the most part the cellphone users on BART (and there are a fair number of them) seem to be pretty decent about it. I ride BART twice a day, and encounter two or three cellphone calls per trip. Perhaps once a week the user is loud enough to be a bother.
There seems to be some variation in the use of rum; my edition of Joy of Cooking gives nearly identical formulations for grog and toddy. I've had grog made with brandy instead of rum, and it's good that way also.
To summarize: splash lemon juice, 2oz rum (or brandy), large spoonful honey in a coffee mug. Fill mug the rest of the way with boiling water. Stir until honey dissolves. Optionally add cinnamon or clove. Do not inhale the fumes until it's cooled a bit.
I'm a Debian developer, and I haven't voted -- yet. I'll cast my DPL vote towards the end of the cycle, as usual. Here's why:
Google's users are already causing plenty of headaches for the rest of Usenet. Usenet participation on Google Groups is up a good deal since they switched over to their gmail-style interface, and had been growing steadily even before that.
Problem is, the new google-groups system has a number of interface problems which cause problems for everyone else on usenet -- the most serious of which tend to cause posters to reply to random points in established threads, and to post without any quoting to supply context. The UI does have a reply feature which supplies quoting, but it's hidden inside a DHTML-popout zone, while the large obvious "Reply" link offers no quoting. Their UI flattens threads, which leads users to lose track of thread structure and reply to the wrong post, confusing everyone.
Further, because they store infinite history, Google users who search around sometimes reply to months- or years-old threads which are no longer on anyone's news server and which make no sense outside of context.
I help moderate a newsgroup, and Google's users are causing no end of frustration and annoyance. It's hard to say whether the endless-September phenomenon of Google's ill-behaved userbase is really up to the standards of 1993 -- back then the AOL influx was apalling, but we had a fairly different signal-to-noise situation then. Maybe we're all just inured to this sort of thing by now.
Yes, hence "reduce mangling," not eliminate mangling. Clean copy untouched by slashdot here.
My key is published on my account. A far more current copy is in the keyservers.
-----BEGIN PGP SIGNED MESSAGE-----
.Trash/MLNS_screensaver_en.dmg3 6b93064936c6cf .Trash/MLNS_screensaver_en.dmg
f 36b93064936c6cf Desktop/MLNS_screensaver_en.dmg
U Aq REuUfYWwCeJ4hL
- ----END PGP SIGNATURE-----
Hash: SHA1
OSX version of the screensaver downloaded on the afternoon of 26th
November, compared to download just now (second checksum for reference,
download it yourself as a hedge against a compromised server giving back
good data to hosts known to have already downloaded the file).
Lines wrapped to reduce mangling.
- -rw-r--r-- 1 aqua staff 1120108 26 Nov 14:19 \
ea8c53d0fb0f30faf
- -rw-r--r-- 1 aqua staff 1120108 1 Dec 00:41 \
Desktop/MLNS_screensaver_en.dmg
ea8c53d0fb0f30fa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBrYfGU5XKDemr/NIRApqmAKDXGuZG5gWvp/9QS7d
+fP7YMmg3DwVFCspiLqze+g=
=4LKC
Some. They still have the biggest share (31%) of the intel server market, but slipped a few percentage points during the recession, partly to Dell and IBM (disclaimer: just one source).
HP losing some market share in 2001 and offering an Opteron server in 2004 seem implausible points of causality, though. If I were to speculate, HP's high level of diversification (relative to Dell, e.g.) and participation in the non-Intel server market reduces somewhat the influence over them by the Wintel duopoly. There's definitely a market demand for a viable 64-bit PC server platform. HP is perhaps a little more able to try to sell to that demand than an OEM more dependent on the favor of Intel et al.
Not that I'm fond of them as a company or anything, but my employer buys thousands of HP's servers, and HP has been selling Opteron-based servers (e.g.) for some while now. Even if AMD never achieved sufficient penetration with ia32, there's some hope that they'll gain some of the ephermeral credibility by being first to market with a workable ia32-compatible 64-bit architecture.
I made a related waggish proposal a couple of years ago:
1. Make tarball of backup
2. Encrypt if desired
3. Encode tarball, 4-8 bytes at a time, in email addresses
4. Put email addresses on web
5. Wait for spam
Presto -- spammers now pay for your backup; anytime you have a disk failure, just wait a while and watch your spamcan or smtp log, and reconstruct your backup at will.
(Some assembly required, offer void where prohibited)
I'd prefer a hard realtime system on general principles, but the description the engineer honcho gave was based on host PC control of lasing with a hardware interlock that cut off the power to the laser if it didn't receive a signal to continue from the host PC every millisecond (he may have been approximating). That insulates the system from overlong lasings; premature cutoff owing to crash or excess latency isn't going to blind someone. The remaining software problem to cover would be a fault whereby the host kept sending stay-on signals after it shouldn't, and that issue would be found regardless of OS.
Back to the principle, though, we trust DOS frequently to run elevators, flight control systems, security systems, etc. -- partly because there's very little DOS involved in those systems, and partly because it's never permitted to be a single point of failure in a safety-critical system. Somehow trusting anything to Windows 3.1, even with hardware interlocks, gives me creepy feelings.
This is going to sound like the total slashdot linux-zealot posting; sorry, but it happened.
:P
In early 2000 the chief software engineer at LASIK came to give a talk before a Software Engineering course I was taking at Sonoma State (worthless CS program, but nevermind). He talked for most of an hour about various parts of the development process, hardware interlocks, millisecond-cutoff crash-detector watchdogs and so forth. Moderately interesting. At the end of a Q&A period, one student asked him what platform LASIK ran on -- since it had been explained that the machines had to be deployed to eye doctors' offices and be easy to use correctly and difficult to use wrongly, etc., etc. The answer, and I swear I'm not making this up, was "Windows 3.1." There was a pause while everyone in the room absorbed this, then he added "But we're considering porting it to Win95."
Hooray for hardware interlocks.
Useless pictures anyway, because the reviewer has apparently not learned the reason why one uses a tripod and remote shutter or timer for long-shots in the dark like this one. And in fact a crummy review; the reviewer spends more copy on his prepatory discussion than on factual recitation or summary, gives no details such as are often used in reviewing keyboards (break force, perceived resistance curve, decent travel, space between keycap edges, etc.) And I'm not sure where he got the idea, but "Natural" is a particular mark of ergo-contoured keyboard, not a description.
Yeesh.
I'd still like to see a breakdown by state. I have a sneaking suspicion that most spam comes from sunny places -- southern California and Florida particularly.
Chinanet's attitude is utterly hostile. To the extent that one can communicate with them at all (only slightly worse than trying to communicate with any large american ISP, to be fair), they not only don't care, they will defend the spammer ("is not spam") or lie about its origins ("IP in report is wrong.") [quotes here from n.a.n-a.e] Giving them the benefit of the doubt (i.e. that they're not pernicious malevolent cretins and merely have a very different view of right and wrong in this matter), it's still impossible to deal with them on an individual basis. Maybe a government could. Or MSN, or AOL. But until that happens, all of Chinanet's known IP address blocks have a nice shiny DROP rule in my mailservers' firewalls, and any URL to a host in those blocks earns several points for spamassassin to work on.
Unfortunately for this sort of problem, there isn't an email equivalent to a Usenet Death Penalty (UDP). UDPs threatened or applied against major ISPs often tend to produce some meaningful action. Partly it works (to the extent that it does) because Usenet has a replication fabric controllable by a relatively small number of people, whereas email has no such system.
Maybe someone will stage a worm attack in the opposite direction from the usual -- writing a worm to scan the top spam sources lists and spamvertized website lists and DDoS them. It would do little for the problem directly, but it would increase the cost of doing business substantially for Chinanet and their kind. (okay, vigilante justice is usually very bad. But it's a fun fantasy.)
That does seem to be the current most typical case. Random cablemodem host acting as a zombie, pitching a website hosted by a spam-friendly ISP in China, Brazil or less commonly other places outside the US. There's still a not insignificant fraction being sent from China, Italy and Wanadoo Espana.
The tricky thing about summaries like this is that different spammers exhibit different techniques, and distributions of received spam are not at all uniform. Spammers reuse address lists, control hosts which are configured in various ways and are better or worse connected to different sections of the network, etc. So while I certainly get most of my spam from infected Comcast and similar hosts, I hestitate to say that's how it would be for, say, a user of one of the big email services, which might be attacked by spammers with different specialties.
The good news about the increased prevalence in use of compromised windows zombies as spam emitters is that it's legally more perilous to the spammer than direct-to-MX delivery. Safer in terms of improved concealment, but potentially more criminal. I say "potentially" because if there existed no provable collusion between the spammer and the virus author, and there probably wasn't, then it might legally be no worse than exploitation of an open SMTP relay, and those incidents never saw substantial prosecution. Depending on how careful the spammers are being chaining together zombies, it may be quite feasible to catch and prosecute them using honeypot zombie hosts. The DoJ just needs to take an interest. Or maybe of the cablemodem companies paying for this cost, like the negligent Spanish ISPs cited here, would be interested in backing a civil action.
While I'm not totally sold on the idea, it seemed to have enough promise to be worth trying. So here's a plugin to qpsmtpd, a replacement smtpd for qmail (it also delivers to postfix, IIRC). Implements most of the basic suggestions in SURBL's proposal.
(I'd like to be able to slap a bell and yell "first implementation!" in a childish slashdot fashion, but I'd be surprised if this really was the first, since it's easy to do a simple implementation and parallels similar DNSBLs in some respects.)
Bad webmaster. He who useth mod_rewrite to check HTTP_REFERER must also checketh it for emptiness, for lo do some persons care about their goddamn privacy a wee bit. No cookie for you.
I do like it as a partial solution (there aren't going to be any good total solutions in this affair). The benefits would probably accrue mainly to the big email services (Yahoo, Hotmail) whose domains are most often forged onto spam. Many people arbitrarily thow away mail purporting to come from there, which must be hurting them in some fashion. Since no one's going to reject mail on the basis of a missing RMX record, spammers will start forging mail from domains having no RMX records at all (or possibly a few serving 0.0.0.0/0 records). So probably not a strong benefit, but it'd help restore the viability of the major email services somewhat.
I do rather suspect that if RMX authentication were widely deployed we'll see DNS cache poisoning attacks come into vogue again. And if there's a set-in-stone system with an even larger deployed base than SMTP, it's DNS.
It's not as if the Dodo went extinct because it fell into obsolescence. It went extinct because the Dutch sailors and settlers arrived in Mauritius bringing rats and cats, then cut down half the forest and clubbed the few surviving dodos for sport. Not unlike MS' historical conduct in the software industry, come to think of it.
Link-based licensing (compile-time or runtime) tends to get compilicated (or complicate things) in the embedded world, where many devices use single statically-linked system images. The conventional linking-based interpretation of the GPL's standalone-works stipulation (GPL section 2) is a bit awkward in that context. If you take a loose view of the link restrictions (e.g. accepting compile-time linkage), then the GPL contaminates the least part of the incorporating work that could "be reasonably considered independent and separate works" -- possibly a driver, a HAL, or the whole kernel.
(simplistic but readable discussion thereof)
This latter is still the major obstacle, since the number of third-party libraries used by (say) PHP is pretty large. You can eliminate the threaded-MPM obstacles by using the process-based prefork MPM, but you don't get some of apache2's performance improvements, especially on operating systems with slow, expensive forks (Solaris, Win32).