Its a just quid-pro-quo, which I imagine works a bit like this:
The MPAA gets to show its member organisations that it's working, and is handed a propaganda victory in the copyfight.
Bram Cohen's startup gets some much-needed press, which keeps the VC's happy and attracts traffic, and (bonus!) isn't sued by the MPAA.
I can't say I blame him. He's never condoned piracy, there's no reason for him to start now, and it's not as if he's talking about the protocol, just his search engine - which is a whole other subject.
Yep, that's because companies spend too much time and money on border security (company firewalls, email filters etc.), while creating SPOF's in trying to minimize maintenence and admin budgets while forgetting that defense in depth is far, far more effective.
Given that users today like to use a variety of tools that use far more ports than just 80 and 25, it's more sensible to have protection at multiple levels: vlan, proxy, mail server, software firewalls, and AV/IDS from top to bottom, updated in as close to real-time as you can get.
The architecture proposed in this article goes to the opposite extreme, eliminating the DMZ and striving to minimize the need for a corporate firewall. I think it goes a little too far, but he's definitely got some good ideas.
(Also, in their defense, the road warriors are normally the salesmen keeping the company afloat:-)
I mean, 'cybersecurity' bigheads are all worried about Terrorists disabling our Internet Infostructure etc., but in real life it turns out that any vulnerabilities that could be used to break into (e.g.) the JPL, White Sands, the DoD etc. have already been exploited by petulant teenagers.
So in this sense, the script kiddies of the Internet are kinda like an early warning system: it's almost certain that before someone with serious intentions finds a nasty flaw and uses it, it'll be discovered by some kid who will promptly boast about it on IRC.
How lucky we are that terrorists find themselves vastly outnumbered by people with too much free time on their hands!
I have one of them, the 20Gb version. Plays any and all MP3, as nice as you'd expect. As one of my friends once said, it truly looks like a pre-perestroika iPod from the USSR.
Curiosities: hidden games of mine-sweeper and sobokan. 5v charger, which is difficult to replace. (4.5: yes. 6: yes. 5: no.) The only annoying things are the USB1 interface, which is dog slow, and the inability to get songs off the thing.
Also the strange lineage. Digital Labs came up with it, and Compaq had it sold to a Korean company that didn't do squat with it.
Right now it's sitting unused with 15Gb of music on it, for want of a charger and a new battery. MP3 blogs and Internet radio have taken over my soundscape. Still, I got four years of good use out of the thing.
Heh, I had the exact same thought. I've done a basic prototype called Gradient. The next version uses a much nicer integration model than the first one. Put simply, loaded documents become nodes on an XMPP network, able to communicate with each other, receive broadcasts, etc.
At the moment, the concept is demonstrated with an SVG browser in Java. Once the semantics of the idea are ironed out I'll move over to HTML and Firefox.
That's a good point. It is important that basic data entry entry should be possible from lynx, and that's why most of the markup I crank out today is semantic HTML.
It seems like iframes and XmlHTTPRequest are only just starting to be used seriously on the public web, and new patterns and models have yet to solidify around them. And since they're relatively shiny, there's a danger of overkill - using them when normal forms should do, as you said.
That said, the new techniques are good ways to enhance the usability of the web in modern browsers, so I guess it's one more tool in the toolbox. Speaking of which: is your generalised JScript library proprietary, or on the web somewhere? It sounds interesting.
You're right, the expected client is JavaScript, inside a browser. The frontend UI is typically in HTML (or SVG), but the client-side logic is written in JavaScript. In this case, the request/response happens within a web-page, between the browser and the web server.
HTML forms are one mechanism for client-server data transfer in a browser, but posting them necessitates reloading the entire web-page, or an iframe, which is not seamless for interfaces like Google Suggest, and may be overkill if you're only making small changes. In addition, a pure POST of form parameters can't transfer the same level of structural detail as XML or JSON without writing your own custom parser/serializer in JavaScript. Since JSON/is/ JavaScript to all intents and purposes, no extra parser is needed.
Well, JSON is a subset of JavaScript object notation, so people who know JavaScript already know this. It's basically a way of transfering structured data between browser and server that is less verbose than XML, and can be eval()ed straight into javacript itself.
Of course, any server receiving this stuff via POST should do the same validity checks it does on anything else it gets from the wire. On the client, IIRC you can only use XMLHttpRequest with the server the document originated from, and neither should you be able to execute script across domains, even within iframes, so the existing browser security model should be sufficient to prevent additional security problems, bugs and exploits notwithstanding...
The term "lazy" here doesn't refer to the qualities of the tagger, but to the way in which it is done.
In coding, you have "lazy initialisation", which is to declare a variable (reserve space for it) and then only fill it with the proper data at the very last minute, just before you use it.
Here, it means that tags are created on an ad hoc basis as you use them to classify something.
I'm doing my own thing with SVG & the newly-RFC'd XMPP - Gradient is about doing server->client broadcast document modification, and turning the JavaScript DOM into a P2P network node by adding XMPP-related functions and events.
The current release doesn't reflect my latest take on the idea, I'm working on changing that.
WHAT THIS MEANS is that I get to visit space in my lifetime, for the cost of a nice round the world cruise.
Was watching the live webcast, and there was a point during the ascent where SpaceShipOne went into a series of barrel rolls on the way up - and it looked (to my uneducated eyes) like the pilot lost control of the craft for a bit.
In the descent SpaceShipOne was rolling left to right quite a bit, and there was vibration clearly visible in the winglets when it went into shuttlecock mode.
I'm watching to see how the landing goes. Fingers crossed none of the landing gear was damaged.
If you want to build an IDE for PHP, you could do worse than build something on top of Eclipse. It's not just a Java tool, it's been done for Python, and the plugin architecture is pretty sweet.
Two things here: firstly, I put in a real address (mailinator, or my spam acct), but fake the rest of it.
Secondly, the 15-20% figure is for the validity of email addresses only. The rest of the info is probably even more innacurate.
An interesting question: is it more damaging to input obviously fake data, such as the 110-year-old brain surgeon, or to distort their demographics by entering in plausible but fake data? I tell the WaPo and the NYT that I'm a 30-year old consultant earning >300,000 a year living in zip 10001 (the Empire State Building) - I figure that if they sell this demographic to advertisers, the best thing to do is to raise the price advertisers have to pay, therefore reducing the number of potential advertisers.
The intention is, once they figure out that even the plausible-sounding demographic they derive from their DB is trash, maybe they'll stop asking for the info.
One thing is that if you want to screen based on the caller having his modem hooked up, then you have to provide some verification of the presence of the callers modem via the 'net, which is difficult unless you actually use the hardware, i.e. call someone with his modem.
Even if you did this, assuming the software got popular, someone would eventually make a patched/hacked version of it that let you use other peoples lines even if you didn't have a modem hooked up to your own PC.
You're right that given the presence of free lines, eventually the users who charge for access would stop being used, again assuming the software existed and that it took off. At this point you might find area-code micro-cartels popping up to artifically raise prices:-)
Finally, your idea is not just a gimmick, it's a lot more than that. If it's feasible, it could end up as a decentralised grass-roots/P2P alternative to the VoIP solutions from Vonage, Net2Phone etc., and it would be totally impossible for the FCC or anyone else to regulate it. In addition, because it lets you get around paying long distance, you're hitting the big telcos where it hurts, which is always cool. And the end result is that you allow people to talk long-distance/transnational longer for less money and that's fundamentally a Good Thing.
That's pretty interesting, but as another reply said, local calls aren't free in many places. That's related to the biggest hurdle: there's no incentive for people to hook up a modem to their broadband-equipped PC in the first place.
What could possibly work is wiring the VoIP<-->POTS software bridge with a built-in micropayment infrastructre, e.g. using the PayPal web interface, ignoring for the moment the PayPal-being-evil issue.
That way, people could charge for the use of their POTS line, and might even make money off their software - and there'd be nothing wrong with that since they're still saving the caller some cash.
Yours is a really interesting idea, and if you follow through at all with it I'd be interested in knowing about it - my email is this nickname at gmx dot net.
I think what's scary is that they've developed a treatment that spreads itself just like a virus, along with HIV. What that means is that once it's in the wild, it's gonna spread like any other virus and, probably, mutate like any other virus.
That's an ethical conundrum from hell - is it moral to infect people with a virus of unknown long-term effects that cures a known killer disease?
... anyone else looking forward to the day when SCO's ''office'' is just a smoking field of rubble, their execs are all in jail, and anyone who had their fingers in this pie is up to their necks in subpoenas and/or SEC/FTC probes?
I can imagine IBM wanting to make that happen. Sorta the corporate equivalent of hanging corpses outside of a medieval town as a warning to others.
This was brought up on a K5 article by Rusty at some point, think about it:
Buy goods and/or currency with dirty money
Once in the game, give the goods and/or currency to your 'clean' character, OR do this through a coupla layers of intermediaries or sock puppets.
Sell the goods at a place like this for clean money.
The only problem is that your ''dirty'' money has to be in a bank account to start with. Normally it's in cash, unless you have a serious sum that needs washing, in which case you'd risk distorting the online markets you washed your money through.
<disclaimer>I haven't tried this myself, and I don't suggest other people do either. But if anyone does, let me know how it goes:-)</disclaimer>
Slashdot Mirror
Its a just quid-pro-quo, which I imagine works a bit like this:
I can't say I blame him. He's never condoned piracy, there's no reason for him to start now, and it's not as if he's talking about the protocol, just his search engine - which is a whole other subject.
Yep, that's because companies spend too much time and money on border security (company firewalls, email filters etc.), while creating SPOF's in trying to minimize maintenence and admin budgets while forgetting that defense in depth is far, far more effective.
Given that users today like to use a variety of tools that use far more ports than just 80 and 25, it's more sensible to have protection at multiple levels: vlan, proxy, mail server, software firewalls, and AV/IDS from top to bottom, updated in as close to real-time as you can get.
The architecture proposed in this article goes to the opposite extreme, eliminating the DMZ and striving to minimize the need for a corporate firewall. I think it goes a little too far, but he's definitely got some good ideas.
(Also, in their defense, the road warriors are normally the salesmen keeping the company afloat :-)
I mean, 'cybersecurity' bigheads are all worried about Terrorists disabling our Internet Infostructure etc., but in real life it turns out that any vulnerabilities that could be used to break into (e.g.) the JPL, White Sands, the DoD etc. have already been exploited by petulant teenagers.
So in this sense, the script kiddies of the Internet are kinda like an early warning system: it's almost certain that before someone with serious intentions finds a nasty flaw and uses it, it'll be discovered by some kid who will promptly boast about it on IRC.
How lucky we are that terrorists find themselves vastly outnumbered by people with too much free time on their hands!
I have one of them, the 20Gb version. Plays any and all MP3, as nice as you'd expect. As one of my friends once said, it truly looks like a pre-perestroika iPod from the USSR.
Curiosities: hidden games of mine-sweeper and sobokan. 5v charger, which is difficult to replace. (4.5: yes. 6: yes. 5: no.) The only annoying things are the USB1 interface, which is dog slow, and the inability to get songs off the thing.
Also the strange lineage. Digital Labs came up with it, and Compaq had it sold to a Korean company that didn't do squat with it.
Right now it's sitting unused with 15Gb of music on it, for want of a charger and a new battery. MP3 blogs and Internet radio have taken over my soundscape. Still, I got four years of good use out of the thing.
Heh, I recognise the statue in the first photo - I have lunch in that park with friends most days when it's that sunny :-)
Heh, I had the exact same thought. I've done a basic prototype called Gradient. The next version uses a much nicer integration model than the first one. Put simply, loaded documents become nodes on an XMPP network, able to communicate with each other, receive broadcasts, etc.
At the moment, the concept is demonstrated with an SVG browser in Java. Once the semantics of the idea are ironed out I'll move over to HTML and Firefox.
That's a good point. It is important that basic data entry entry should be possible from lynx, and that's why most of the markup I crank out today is semantic HTML.
It seems like iframes and XmlHTTPRequest are only just starting to be used seriously on the public web, and new patterns and models have yet to solidify around them. And since they're relatively shiny, there's a danger of overkill - using them when normal forms should do, as you said.
That said, the new techniques are good ways to enhance the usability of the web in modern browsers, so I guess it's one more tool in the toolbox. Speaking of which: is your generalised JScript library proprietary, or on the web somewhere? It sounds interesting.
You're right, the expected client is JavaScript, inside a browser. The frontend UI is typically in HTML (or SVG), but the client-side logic is written in JavaScript. In this case, the request/response happens within a web-page, between the browser and the web server.
HTML forms are one mechanism for client-server data transfer in a browser, but posting them necessitates reloading the entire web-page, or an iframe, which is not seamless for interfaces like Google Suggest, and may be overkill if you're only making small changes. In addition, a pure POST of form parameters can't transfer the same level of structural detail as XML or JSON without writing your own custom parser/serializer in JavaScript. Since JSON /is/ JavaScript to all intents and purposes, no extra parser is needed.
Well, JSON is a subset of JavaScript object notation, so people who know JavaScript already know this. It's basically a way of transfering structured data between browser and server that is less verbose than XML, and can be eval()ed straight into javacript itself.
Of course, any server receiving this stuff via POST should do the same validity checks it does on anything else it gets from the wire. On the client, IIRC you can only use XMLHttpRequest with the server the document originated from, and neither should you be able to execute script across domains, even within iframes, so the existing browser security model should be sufficient to prevent additional security problems, bugs and exploits notwithstanding...
The term "lazy" here doesn't refer to the qualities of the tagger, but to the way in which it is done.
In coding, you have "lazy initialisation", which is to declare a variable (reserve space for it) and then only fill it with the proper data at the very last minute, just before you use it.
Here, it means that tags are created on an ad hoc basis as you use them to classify something.
LiveJournal lets you have a private blog.
Hey, good answer.
I'm doing my own thing with SVG & the newly-RFC'd XMPP - Gradient is about doing server->client broadcast document modification, and turning the JavaScript DOM into a P2P network node by adding XMPP-related functions and events.
The current release doesn't reflect my latest take on the idea, I'm working on changing that.
Hey, much as I like SVG (for some things), would you mind explaining why supporting SVG will allow Firefox to win the enterprise space?
WHAT THIS MEANS is that I get to visit space in my lifetime, for the cost of a nice round the world cruise.
Was watching the live webcast, and there was a point during the ascent where SpaceShipOne went into a series of barrel rolls on the way up - and it looked (to my uneducated eyes) like the pilot lost control of the craft for a bit.
In the descent SpaceShipOne was rolling left to right quite a bit, and there was vibration clearly visible in the winglets when it went into shuttlecock mode.
I'm watching to see how the landing goes. Fingers crossed none of the landing gear was damaged.
If you want to build an IDE for PHP, you could do worse than build something on top of Eclipse. It's not just a Java tool, it's been done for Python, and the plugin architecture is pretty sweet.
Or if you drop it from the top of a very tall building.
If a heatsink is attached then it might classify as a WMD :-)
I know you're kidding, but the answer is not zero.
Two things here: firstly, I put in a real address (mailinator, or my spam acct), but fake the rest of it.
Secondly, the 15-20% figure is for the validity of email addresses only. The rest of the info is probably even more innacurate.
An interesting question: is it more damaging to input obviously fake data, such as the 110-year-old brain surgeon, or to distort their demographics by entering in plausible but fake data? I tell the WaPo and the NYT that I'm a 30-year old consultant earning >300,000 a year living in zip 10001 (the Empire State Building) - I figure that if they sell this demographic to advertisers, the best thing to do is to raise the price advertisers have to pay, therefore reducing the number of potential advertisers.
The intention is, once they figure out that even the plausible-sounding demographic they derive from their DB is trash, maybe they'll stop asking for the info.
One thing is that if you want to screen based on the caller having his modem hooked up, then you have to provide some verification of the presence of the callers modem via the 'net, which is difficult unless you actually use the hardware, i.e. call someone with his modem.
Even if you did this, assuming the software got popular, someone would eventually make a patched/hacked version of it that let you use other peoples lines even if you didn't have a modem hooked up to your own PC.
You're right that given the presence of free lines, eventually the users who charge for access would stop being used, again assuming the software existed and that it took off. At this point you might find area-code micro-cartels popping up to artifically raise prices :-)
Finally, your idea is not just a gimmick, it's a lot more than that. If it's feasible, it could end up as a decentralised grass-roots/P2P alternative to the VoIP solutions from Vonage, Net2Phone etc., and it would be totally impossible for the FCC or anyone else to regulate it. In addition, because it lets you get around paying long distance, you're hitting the big telcos where it hurts, which is always cool. And the end result is that you allow people to talk long-distance/transnational longer for less money and that's fundamentally a Good Thing.
That's pretty interesting, but as another reply said, local calls aren't free in many places. That's related to the biggest hurdle: there's no incentive for people to hook up a modem to their broadband-equipped PC in the first place.
What could possibly work is wiring the VoIP<-->POTS software bridge with a built-in micropayment infrastructre, e.g. using the PayPal web interface, ignoring for the moment the PayPal-being-evil issue.
That way, people could charge for the use of their POTS line, and might even make money off their software - and there'd be nothing wrong with that since they're still saving the caller some cash.
Yours is a really interesting idea, and if you follow through at all with it I'd be interested in knowing about it - my email is this nickname at gmx dot net.
I think what's scary is that they've developed a treatment that spreads itself just like a virus, along with HIV. What that means is that once it's in the wild, it's gonna spread like any other virus and, probably, mutate like any other virus.
That's an ethical conundrum from hell - is it moral to infect people with a virus of unknown long-term effects that cures a known killer disease?
... anyone else looking forward to the day when SCO's ''office'' is just a smoking field of rubble, their execs are all in jail, and anyone who had their fingers in this pie is up to their necks in subpoenas and/or SEC/FTC probes?
I can imagine IBM wanting to make that happen. Sorta the corporate equivalent of hanging corpses outside of a medieval town as a warning to others.
For the Attrition case, this page tells the whole story. Put simply, Mastercard ends up looking stupid.
The lumber cartel strikes again :-)
This was brought up on a K5 article by Rusty at some point, think about it:
The only problem is that your ''dirty'' money has to be in a bank account to start with. Normally it's in cash, unless you have a serious sum that needs washing, in which case you'd risk distorting the online markets you washed your money through.
<disclaimer>I haven't tried this myself, and I don't suggest other people do either. But if anyone does, let me know how it goes :-)</disclaimer>