One site covering this noted plans to 'stay up to date with the most recent bug fixes' of the hosted libraries -- this sounds like blindly upgrading the hosted libraries to new versions, which is a very bad idea.
As a commenter there noted, it's a much better idea to use version-specific URIs, allowing users to choose the versions they wish to use -- otherwise version mismatches will occur between user apps and the Google-hosted libs, creating bugs and the classic 'dependency hell' that would be familiar to anyone who remembers the days of 'DLL hell'.
fwiw, I ported some QNX code to Linux a few years back, and wrote my own version of MsgSend()/MsgRecv() in a single.c file using UNIX-domain sockets. it's extremely simple, as long as you adopt the same limitations on portability (ie. writing raw C structs to the wire), lack of network support, and concurrency as the QNX message-passing has.
QNX message-passing is nothing that can't be easily rewritten.
I've been dealing with this a lot recently -- I just wrote up a short howto doc
over on my blog yesterday,
in fact, using Postfix on the MX to catch most of the bounces, with SpamAssassin to filter out the remainder.
'The cars honked at you because they thought you were a bum? Don't you think that's a bit of a stretch? In truth, they honked at you either because they wanted to startle you (because many people are assholes), or because you were walking down a road without adequate pedestrian space, placing yourself and the drivers at risk.'
no, they probably *were* honking because they thought he was a bum, or just because they think it's humourous to honk at a foot-borne 'loser'. I've lived in Orange County for 3 years, and ran into this bizarre phenomenon repeatedly there.;)
Most cell phones are not really sub-$100 devices. Their true cost of a web-enabled phone is often well over $100, but the true cost is hidden somewhere in the 1 to 2 year contract with the provider.
Well, this isn't a sub-$100 device, either, really.
The $100 price point for this device is based on unrealistic volume assumptions, in my opinion -- Ethan notes that it'll likely start off at $130 to $150 'not including any distribution costs, marketing, or any digital content that comes pre-installed on the box' assuming 5 countries sign up for a million laptops each.
IMO those are pretty optimistic prices. Having worked on a low-cost laptop-like device in the past, in our experience we found that the normal fluctuations of the component market can cause the price point to swing wildly.
Having said that, I wish them luck! Being Irish, I can tell you that adoption of high tech really can bring major benefits to a society...
BTW the worldchanging link seems slashdotted -- try Ethan's weblog post here: http://www.ethanzuckerman.com/blog/?p=241 . (and subscribe to his weblog while you're at it -- he regularly posts excellent insights into the meeting point of tech and the developing world. strongly recommended.)
Hell, here's the weblog post to mirror it...
'I took a day off from this years Pop!Tech conference to hang out with some friends in Portland. But before driving from Camden to Portland, I dropped into the Opera House to check email and bumped into Nicholas Negroponte, whod given a talk the day before on his work to produce a laptop that costs less than a hundred dollars.
Negroponte was an advisor to Geekcorps and was extremely helpful to me as we figured out whether the organization would be supported by corporate sponsorship, foundations or government largesse. So he knows about my long-standing interest in technology in the developing world. He asked whether I was interested in coming over to the lab and seeing a demo of the machine, and talking about strategies for deployment.
Hell yeah.
The demo was yesterday afternoon, and while it didnt include a functioning prototype, I learned a great deal more about machine than I have from previous articles, or Negropontes talk at Pop!Tech. He was able to answer a whole set of questions for me, and raise an entire set of new ones, which, I suspect, will take a number of years to answer accurately.
First, the name. Id been calling the project the sub-hundred dollar laptop the acronym of which is the unfortunate SHiL. Negropontes now calling the project OLPC - One Laptop Per Child. It does a better job of defining the project, I think - not taking the bottom out of the consumer laptop market, but providing a learning tool for students around the world.
On to the machine. While the actual prototype is being actively banged on (in preparation for a live, but tethered, demo at WSIS on November 16th), Negroponte keeps a cardboard mockup of the machine on the conference table in his office. Its a clever little thing - I had a hard time putting it down after picking it up. You can see a design close to the prototype I saw on the front page of Design Continuums site - theyre evidently doing the case design for the machine and, actually, pretty far from the design reported on in the AP story about the project.
The mockup I saw was about the size of a large paperback book. Theres a stiff rubber gasket around the edge of the machine, which can double as a stand. The keyboard on the
Kevin Drum recently quoted a study which re-iterated that there's no "real" advantage to buying a hybrid. It's only just as convenient - so if you're driving a hybrid, you're doing it for some other reason than financial incentive.
That made me think: what a perfect example of just how fucking useless as a society we've become. We can't even bring ourselves to do the right thing when it's only JUST as convenient as doing the wrong thing. And that's not even considered odd. Even sadder.
I've had the honour of sharing a small longtail speedboat with 2 of these giant catfish, live, 6 feet long, and wriggling. Not that I particularly wanted to -- our driver had a thriving sideline in selling live animals up and down the river while he was operating his ferry service;)
They're called "pla beuk" in Laos, FWIW.
Reportedly, the Mekong river is lower in level in places than it used to be. This also meant that much of the river is less navigable during less of the year now, and travelling by these speedboats is more dangerous. This lowering was apparently caused by damming upriver. I wouldn't be surprised if the lower level of the river has had an effect on the population of these fish and other freshwater aquatic wildlife, such as the pink river dolphins and the giant stingrays, for obvious reasons. It's a shame -- like other major world rivers, the Mekong has a unique ecosystem.
hmm. What's the relationship between the user 'Steve Linford, Spamh' (who's never made any comments before this story) and 'Steve Linford' (comments made back in 2001)?
Like many schemes that reject mail during the SMTP phase, this talks about false positives, but with little idea about the true rate. This can be dangerous.
For example, http://www.acme.com/mail_filtering/blackmilter_fra meset.html discusses "Wormy", an 'early & cheap blacklist that is still accurate.' It works by grepping out IPs of hosts that delivered mail that ClamAV said was malware, and then turning those IPs into a blacklist for "a day or two".
This initially seems to work, but if you try it out and *measure it with real mail, including ham*, what you'll discover is that large ISP mail gateways show up on the list very quickly. I know of other occasions where it's been tried, and abandoned, due to this issue.
However, Blackmilter, the component that uses Wormy, is listed as having "low" false positives in this document.
"Spammer" is vulnerable to the same problem.
"Persistent" will additionally have a similar problem, in that if you measure spam volume without also measuring overall (ham+spam) volume, you'll unfairly penalise hosts that send a lot of mail in general -- even if only 0.5% of that is spam.
In general, I think jef is probably justified in taking a hardline approach at those volumes -- but if you're thinking of trying out some of these approaches, be sure to apply a pinch of NaCl.
In the past 5 years, I've spent quite a lot of time in both Australia and the US as a new arrival, and had to set up broadband internet connections in both (naturally!). I've encountered:
line faults (yes, even in the US! duh)
places where various vendor's packages are unavailable due to lack of coverage
$500 deposits required, and faxed proof of income, because I have no local credit rating
long waits because a social security number is required, and it takes 3 months to get that issued
and yes, culture shock. for example, you quickly learn to pronounce a wide "R", because the round "R" used in the UK and Ireland is incomprehensible to USian phone operators;)
The author is naive. I suspect he's spent a lot of time in a nice high-tech hotspot like Silicon Valley, where everything on offer is oriented around his kind of needs -- much of the rest of the world, and indeed much of the US, isn't like that.
Anyway, it's a learning process. Next time he moves somewhere, he'll know to do a bit more research and not expect it to be just like the US. Good for him;) In the meantime, the article's a waste of front page space.
how much publicly-funded researchers should be required to disclose
- should they be allowed to generate 'closed-source' solutions at the
taxpayers' expense?
It's worth noting that, while it makes sense that taxpayer-funded research should generate 'open-source' solutions, federal law dictates otherwise.
The Bayh-Dole Act was passed 25 years ago, which dictates:
Universities were encouraged to collaborate commercial concerns to promote the utilization of inventions arising from federal funding.
It was clearly stated that universities may elect to retain title to inventions developer through government funding.
Universities must file patents on inventions they elect to own.
So in other words the government has dictated since 1980 that government-funded research should not produce open-source solutions, necessarily, as the results of research are to be considered private-sector profit-generating centers for the host universities. (The implications for the 'next BSD4.3 TCP/IP stack', or similar advanced research, are obvious.)
Anyway, regarding the 'hockey stick' controversy, Tim Lambert's weblog is worth a read.
'A lawyer who would probably not want to be identified with the large patent-holder (and lawsuit target) for which he works recommended that programmers *not* read patents. The implication was that "ignorance of the law" mitigated damages.'
Well, more correctly, if you're ever accused of infringement, awareness of the contents of the patent will greatly increase your damages. I've also heard this, from several different lawyers, including lawyers who were expert in US patent law. It certainly seems to be the prevailing point of view.
'Why not "read and avoid?" The lawyer didn't say, but I'd guess that it's hopeless.'
What I was told is that you may think you've written the software in such a way that you can avoid the patent, but unless you're a patent lawyer, you aren't qualified to be able to make an accurate assessment of your status.
So I guess that means that we need to get the lawyers writing the software nowadays. This is, of course, an absurd situation. People in Europe: fight the software patent directive. People in the US: hope that your absurd patent system is reformed soon....
'Canadian scientists Stephen McIntyre and Ross McKitrick have uncovered a fundamental mathematical flaw in the computer program that was used to produce the hockey-stick.'
Since this is still in the application stage, some good instances of prior art can invalidate, or severely restrict, the final patient. More details here.
'@Once has big-name clients who don't want to be thought of as spammers, so the company puts amazing resources into reply handling and unsubscribe systems that actually work. I know, I worked my ass off keeping them running.
Of course, if those addresses initially came from bad sources, such as list vendors selling web- or whois-scraped address lists, then it doesn't matter how clean the opt-out process is -- it's still unsolicited bulk email, or spam.
It was a stark contrast to what a real "spammer" is, at least in my imagination.'
maybe a stark contrast to the kind of slime sending Rolex-watch spam. But still well into the spammy range of the spectrum; even Scott Richter claims not to use badly-sourced addresses these days...
'Recent research pointed out that the majority of domainkey users so far have been spammers'
Got a link for that? It's news to me, and I'm one of the SpamAssassin development team. I think you're confusing DK with SPF.
Either way, it's an irrelevant point. Sure, spammers can tie themselves down to one IP by using SPF, or tie themselves to a domain by using DK -- and we then have removed a layer of their anonymity and given ourselves a new tool in our armoury against them. *THAT* is the point.
So, care to back up that scaremongering with some stats on how long those operations take in the US? I'll bet they're on the order of one to two weeks, same as.ca.
'Costs are high because of several factors, first is the medical billing system.... Second is malpractice insurance.'
So I hear. However, to my mind that doesn't explain one thing my GF
experienced in the US healthcare system recently: nearly having to pay nearly
$100 for a a simple blood test. In this case, since she's performed the test
herself in the past, she knows the materials involved cost under 1 cent, and
the test would have been performed by 2 people: a nurse to extract the blood,
and a technician with a microscope to stain it, put it on a slide, and look at
it.
Malpractice insurance doesn't explain a 1 million percent markup, in my opinion.
Seriously, he should have gone to Bangkok. Last time I visited, I met an Aussie who'd retired to Thailand for the cheap healthcare, and heard of several "surgery tourists" who also did the same. Reportedly the hospitals (at least the ones a paying tourist would use) are spotless, with english-speaking nurses and excellent care.
On a less serious level, it's long been a well-known spot for budget travellers to get some dental work done, or pick up new glasses, cheap, safely and reliably.
It's even (IMO) a nicer place to visit. Sorry Indian readers;)
It's important that the input and output of these processes are structures (actually, objects, but I don't want to tickle anyone's prejudices about OOP).
Sounds like you need to look into XMLStarlet or one of the other XML-grokking command-line filter tools.
Structured pipe data has been around for a while, and XML's a natural format for that.
I certainly don't see a need to drop in a.Net dependency where XML will do. (Note that I would welcome an XML output mode from ps, though;)
Also, re: piping binary data about: see netpbm, a graphics toolkit built around pipes.
Producing a paper-based VVAT is half the problem. The next step is, what
data source is considered authoritative in the event of a recount or a detected
problem?
In other words, what happens when the paper trail disagrees with the electronic record?
Logically, the paper trail is the authoritative record.
But this needs to be explicitly specified as such, otherwise
vote administrators may choose to take the easy way out and perform an
"electronic recount" -- in other words, simply recomputing the existing, bad, electronic voting
record and calling that a recount.
The Belgian idea was to make a full recount and compare the result. The
law said: "Manual count rule in case of discrepency". The expert choosed
(sic)
to say: "Since we believe the paper result are not reliable, we took the
electronic result as the valid one."
Slashdot Mirror
One site covering this noted plans to 'stay up to date with the most recent bug fixes' of the hosted libraries -- this sounds like blindly upgrading the hosted libraries to new versions, which is a very bad idea.
As a commenter there noted, it's a much better idea to use version-specific URIs, allowing users to choose the versions they wish to use -- otherwise version mismatches will occur between user apps and the Google-hosted libs, creating bugs and the classic 'dependency hell' that would be familiar to anyone who remembers the days of 'DLL hell'.
fwiw, I ported some QNX code to Linux a few years back, and wrote my own version of MsgSend()/MsgRecv() in a single .c file using UNIX-domain sockets. it's extremely simple, as long as you adopt the same limitations on portability (ie. writing raw C structs to the wire), lack of network support, and concurrency as the QNX message-passing has.
QNX message-passing is nothing that can't be easily rewritten.
I've been dealing with this a lot recently -- I just wrote up a short howto doc over on my blog yesterday, in fact, using Postfix on the MX to catch most of the bounces, with SpamAssassin to filter out the remainder.
'The cars honked at you because they thought you were a bum? Don't you think that's a bit of a stretch? In truth, they honked at you either because they wanted to startle you (because many people are assholes), or because you were walking down a road without adequate pedestrian space, placing yourself and the drivers at risk.'
;)
no, they probably *were* honking because they thought he was a bum, or just because they think it's humourous to honk at a foot-borne 'loser'. I've lived in Orange County for 3 years, and ran into this bizarre phenomenon repeatedly there.
Well, this isn't a sub-$100 device, either, really.
The $100 price point for this device is based on unrealistic volume assumptions, in my opinion -- Ethan notes that it'll likely start off at $130 to $150 'not including any distribution costs, marketing, or any digital content that comes pre-installed on the box' assuming 5 countries sign up for a million laptops each.
IMO those are pretty optimistic prices. Having worked on a low-cost laptop-like device in the past, in our experience we found that the normal fluctuations of the component market can cause the price point to swing wildly.
Having said that, I wish them luck! Being Irish, I can tell you that adoption of high tech really can bring major benefits to a society...
BTW the worldchanging link seems slashdotted -- try Ethan's weblog post here: http://www.ethanzuckerman.com/blog/?p=241 . (and subscribe to his weblog while you're at it -- he regularly posts excellent insights into the meeting point of tech and the developing world. strongly recommended.)
Hell, here's the weblog post to mirror it...
'I took a day off from this years Pop!Tech conference to hang out with some friends in Portland. But before driving from Camden to Portland, I dropped into the Opera House to check email and bumped into Nicholas Negroponte, whod given a talk the day before on his work to produce a laptop that costs less than a hundred dollars.
Negroponte was an advisor to Geekcorps and was extremely helpful to me as we figured out whether the organization would be supported by corporate sponsorship, foundations or government largesse. So he knows about my long-standing interest in technology in the developing world. He asked whether I was interested in coming over to the lab and seeing a demo of the machine, and talking about strategies for deployment.
Hell yeah.
The demo was yesterday afternoon, and while it didnt include a functioning prototype, I learned a great deal more about machine than I have from previous articles, or Negropontes talk at Pop!Tech. He was able to answer a whole set of questions for me, and raise an entire set of new ones, which, I suspect, will take a number of years to answer accurately.
First, the name. Id been calling the project the sub-hundred dollar laptop the acronym of which is the unfortunate SHiL. Negropontes now calling the project OLPC - One Laptop Per Child. It does a better job of defining the project, I think - not taking the bottom out of the consumer laptop market, but providing a learning tool for students around the world.
On to the machine. While the actual prototype is being actively banged on (in preparation for a live, but tethered, demo at WSIS on November 16th), Negroponte keeps a cardboard mockup of the machine on the conference table in his office. Its a clever little thing - I had a hard time putting it down after picking it up. You can see a design close to the prototype I saw on the front page of Design Continuums site - theyre evidently doing the case design for the machine and, actually, pretty far from the design reported on in the AP story about the project.
The mockup I saw was about the size of a large paperback book. Theres a stiff rubber gasket around the edge of the machine, which can double as a stand. The keyboard on the
a Kung Fu Monkey blog entry from a month ago said this:
As a (strongly pro-peace-process) Dubliner, I find that ignorance disappointing -- one of those bombs nearly killed my father-in-law.
Mind you, I agree with you on most of the rest of your comments ;)
They're called "pla beuk" in Laos, FWIW.
Reportedly, the Mekong river is lower in level in places than it used to be. This also meant that much of the river is less navigable during less of the year now, and travelling by these speedboats is more dangerous. This lowering was apparently caused by damming upriver. I wouldn't be surprised if the lower level of the river has had an effect on the population of these fish and other freshwater aquatic wildlife, such as the pink river dolphins and the giant stingrays, for obvious reasons. It's a shame -- like other major world rivers, the Mekong has a unique ecosystem.
hmm. What's the relationship between the user 'Steve Linford, Spamh' (who's never made any comments before this story) and 'Steve Linford' (comments made back in 2001)?
Like many schemes that reject mail during the SMTP phase, this talks about false positives, but with little idea about the true rate. This can be dangerous.
a meset.html discusses "Wormy", an 'early & cheap blacklist that is still accurate.' It works by grepping out IPs of hosts that delivered mail that ClamAV said was malware, and then turning those IPs into a blacklist for "a day or two".
For example, http://www.acme.com/mail_filtering/blackmilter_fr
This initially seems to work, but if you try it out and *measure it with real mail, including ham*, what you'll discover is that large ISP mail gateways show up on the list very quickly. I know of other occasions where it's been tried, and abandoned, due to this issue.
However, Blackmilter, the component that uses Wormy, is listed as having "low" false positives in this document.
"Spammer" is vulnerable to the same problem.
"Persistent" will additionally have a similar problem, in that if you measure spam volume without also measuring overall (ham+spam) volume, you'll unfairly penalise hosts that send a lot of mail in general -- even if only 0.5% of that is spam.
In general, I think jef is probably justified in taking a hardline approach at those volumes -- but if you're thinking of trying out some of these approaches, be sure to apply a pinch of NaCl.
The author is naive. I suspect he's spent a lot of time in a nice high-tech hotspot like Silicon Valley, where everything on offer is oriented around his kind of needs -- much of the rest of the world, and indeed much of the US, isn't like that.
Anyway, it's a learning process. Next time he moves somewhere, he'll know to do a bit more research and not expect it to be just like the US. Good for him ;) In the meantime, the article's a waste of front page space.
It's worth noting that, while it makes sense that taxpayer-funded research should generate 'open-source' solutions, federal law dictates otherwise.
The Bayh-Dole Act was passed 25 years ago, which dictates:
So in other words the government has dictated since 1980 that government-funded research should not produce open-source solutions, necessarily, as the results of research are to be considered private-sector profit-generating centers for the host universities. (The implications for the 'next BSD4.3 TCP/IP stack', or similar advanced research, are obvious.)
Anyway, regarding the 'hockey stick' controversy, Tim Lambert's weblog is worth a read.
'A lawyer who would probably not want to be identified with the large patent-holder (and lawsuit target) for which he works recommended that programmers *not* read patents. The implication was that "ignorance of the law" mitigated damages.'
Well, more correctly, if you're ever accused of infringement, awareness of the contents of the patent will greatly increase your damages. I've also heard this, from several different lawyers, including lawyers who were expert in US patent law. It certainly seems to be the prevailing point of view.
'Why not "read and avoid?" The lawyer didn't say, but I'd guess that it's hopeless.'
What I was told is that you may think you've written the software in such a way that you can avoid the patent, but unless you're a patent lawyer, you aren't qualified to be able to make an accurate assessment of your status.
So I guess that means that we need to get the lawyers writing the software nowadays. This is, of course, an absurd situation. People in Europe: fight the software patent directive. People in the US: hope that your absurd patent system is reformed soon....
or maybe they didn't, and the anti-climate-change astroturf operation is in full force, in turn ignoring McIntyre and McKitrick's statistical errors -- like not understanding the difference between degrees and radians.
I'll stick with the real scientists, thanks.
Since this is still in the application stage, some good instances of prior art can invalidate, or severely restrict, the final patient. More details here.
Actually, it appears likely that the article is getting the wrong end of the stick entirely, confusing WHOIS and DNS. more details...
maybe a stark contrast to the kind of slime sending Rolex-watch spam. But still well into the spammy range of the spectrum; even Scott Richter claims not to use badly-sourced addresses these days...
it's kind of the same thing...
'His home is one of the newer ones in the neighborhood and is furnished casually, with a few pieces in Danish modern.'
;)
Does that mean IKEA?
'Recent research pointed out that the majority of domainkey users so far have been spammers'
Got a link for that? It's news to me, and I'm one of the SpamAssassin development team. I think you're confusing DK with SPF.
Either way, it's an irrelevant point. Sure, spammers can tie themselves down to one IP by using SPF, or tie themselves to a domain by using DK -- and we then have removed a layer of their anonymity and given ourselves a new tool in our armoury against them. *THAT* is the point.
So, care to back up that scaremongering with some stats on how long those operations take in the US? I'll bet they're on the order of one to two weeks, same as .ca.
So I hear. However, to my mind that doesn't explain one thing my GF experienced in the US healthcare system recently: nearly having to pay nearly $100 for a a simple blood test. In this case, since she's performed the test herself in the past, she knows the materials involved cost under 1 cent, and the test would have been performed by 2 people: a nurse to extract the blood, and a technician with a microscope to stain it, put it on a slide, and look at it.
Malpractice insurance doesn't explain a 1 million percent markup, in my opinion.
Seriously, he should have gone to Bangkok. Last time I visited, I met an Aussie who'd retired to Thailand for the cheap healthcare, and heard of several "surgery tourists" who also did the same. Reportedly the hospitals (at least the ones a paying tourist would use) are spotless, with english-speaking nurses and excellent care.
;)
On a less serious level, it's long been a well-known spot for budget travellers to get some dental work done, or pick up new glasses, cheap, safely and reliably.
It's even (IMO) a nicer place to visit. Sorry Indian readers
Structured pipe data has been around for a while, and XML's a natural format for that. I certainly don't see a need to drop in a .Net dependency where XML will do. (Note that I would welcome an XML output mode from ps, though ;)
Also, re: piping binary data about: see netpbm, a graphics toolkit built around pipes.
Producing a paper-based VVAT is half the problem. The next step is, what data source is considered authoritative in the event of a recount or a detected problem? In other words, what happens when the paper trail disagrees with the electronic record?
Logically, the paper trail is the authoritative record. But this needs to be explicitly specified as such, otherwise vote administrators may choose to take the easy way out and perform an "electronic recount" -- in other words, simply recomputing the existing, bad, electronic voting record and calling that a recount.
This message from David Glaude of PourEva notes that this has already happened in Belgium: