That's not exactly true; SNI allows for HTTPS multihoming, and it's supported by the HTTPS on pretty much every modern platform, *except* for Windows XP. Browsers that use Window's HTTPS code (most of them, IIRC) can't cope with SNI on XP, so no one actually uses it anywhere yet.
I work for Google, and there *are* some people who work insane hours every days, but that's not really typical. In Mountain View, a large percentage of the population leaves around 5 or 6. Sure, some people work late every day, but they're usually the same people who arrive late every day. Google isn't really the sort of place that values Spending A Lot Of Time At The Office. People are judged by what they've accomplished, not how many hours they were around looking busy.
If anything, the problem with Google is that there's *so* much cool stuff going on--you know, if you have a bit of free time, then the temptation to work on cool project AAA or BBB can be hard to resist:-).
Most of my Microsoft friends work longer hours then I do, but I can't claim that they're a representative sample.
As for the Seattle vs The Bay Area debate--you do know that both companies have offices practically right next to each other in both areas, don't you? MS's Silicon Valley campus is under 3 minutes from Google, and our Kirkland office is probably only 5 minutes from MS on a good traffic day. I work in Kirkland, it's a nice office, and we have a lot of fresh college grads from around the country. If location matters, then talk to your recruiter (for either company), and I suspect they can work something out.
All things considered, I suspect that the original poster would be happier at Google, but I'm kind of biased.
Let's see--it's an article on how RSS is the future of business communication, hosted on a site that sells business RSS services, written by the site's owner, and submitted to Slashdot by the author.
Then fed to me via Slashdot's RSS feed.
Yep, that's the future of advertising via RSS if I ever saw it.
My personal guess is that it's a timing attack based on CPU performance counters--both threads can read the performance-counting data for the CPU, so they'll have access to a ton of details data. This includes things like branch prediction, which may be enough to *slowly* reconstruct all of the bits in an RSA key that's used over and over.
Re:Direct link to file in a Linux-playable format.
on
Donald Knuth On NPR
·
· Score: 1
Okay, how about a different approach: I'd love to have this in a format that I can stick on an iPod or burn onto a CD so I can listen to it in my car. I don't really care about open source players, but open *formats* are really important.
While Google may or may not be working on a calendar, his "evidence" is lacking. Basically, he's saying that Google is walking his calendar a lot, and using that as evidence that Google is building itself a calendar. There's a much simpler explanation: Google goes nuts when it runs into PHP iCalendar. It sees every link as a new page to look at, and after a few runs by googlebot, it's trying to index the daily calendar page for every day within a decade of today. I've been dealing with this today, adding robots.txt entries to keep it away from PHP iCalendar, because Googlebot is generating thousands of hits per day on my little site.
So, just because Googlebot and PHP iCalendar don't get along, that doesn't mean that Google is busy building up a monster searchable calendar.
Having said that, I'd love to see a gmail calendar component that you could access via WebDAV. I don't see how they'd make money on it, though.
You're about 10 years too late for this discussion. CSS has been a part of the standards landscape for around a decade now, and it's been bog-common for at least a few years.
"Why do we even have that button?" Because it's basically required by law. Covering them with a plastic cover doesn't seem to help either--Internap did that the *last* time someone hit the EPO button in this datacenter.
Yeah, but it's not just for the fire department--by the time they got there, the tech'd be dead. As I understand it, it's really for local staff so they can kill the power if there's an imminent danger to another tech's life. The canonical example is an IBM tech with his tie stuck in a herking huge printer--either hit the EPO button or watch him get line-fed through the thing. While this exact example my not apply in colo spaces (I've never seen any big mechanical devices in any of the ones that I've been in), it's still important for electrical fires. Presumably, that's the main reason that we're required to put the damn things in.
A couple points. First, there's *nothing* that you can do about the "idiot hit the big red button" problem--you're required by law to have the button, because it's a safety issue. It has to be accessible--you can't lock it in a closet. And everyone knows that if you put a big red button on a wall, sooner or later someone's going to hit it.
I don't know what happened this time, but the ~2002 Internap Seattle outage was caused by an idiot Speakeasy tech who couldn't figure out how to use the exit door, so hit hit the Big Red Button instead.
I worked for Internap at the time, and I spent weeks stuck inside that colo facility. It was basically the only "dot-com" grade thing that Internap built (they were usually somewhat thrifty, at least pre-2001). It sparkled. Everything was over-engineered. You had to go through multiple rounds of security to get access to anything.
The last I heard last night, no one quite knew what'd happened yet. Apparently, multiple redundant power systems all failed at the same time. This facility was designed by a company that already had ~5 years experience running high-end colo facilities, and it was designed as the flagship facility for showing off to potential customers. This isn't a hole-in-the-wall hosting place, it's more of a bunker hiding in the shadow of the Space Needle. So, frankly, it'll be very interesting to see what happened, because no money was spared to keep this sort of thing from happening.
(Disclaimer: I haven't worked for Internap since 2002. I still own a bit of stock, because it's not worth the hassle of selling it for what little it's worth. It's not really the same company now that it was when I started in '98, and only a handful of my former coworkers are still with the company. I'm not even going to *start* with my opinion of the current management.)
Well, look at things this way: ENUM has been around for *years*, yet there's still no official ENUM tree. There's no way for VoIP carriers like Vonage to publish SIP addresses for the PSTN numbers that they service.
Why? Because of political squabbling by telcos, verisign, and the like. Whoever controls the ENUM tree will be able to control the future of telecommunications. That means money and power, and that's why there's no progress occuring--all of the usual players are jockeying for position, and will be for years.
Since ENUM is really just a DNS tree, that hasn't stopped people from producing their own ENUM trees (e164.org, etc), but there's nothing particularly official about any of them. They're all interim solutions, and none of them are big enough to be able to make a difference on their own.
There are a couple differences with DUNDi. First, it's *designed* to be decentralized, without a single point of control (or toll collection). There's an open-source implementation right out of the gate. It at least pays lip service to spam and telemarketing issues. As long as you sign the agreement, it *should* be possible for anyone to participate. And, it already has several mid-sized providers involved.
In short, right out of the gate, DUNDi is already ahead of ENUM, because it's already usable, while ENUM still doesn't have any way to publish numbers in the "official" e164.arpa tree. DUNDi doesn't have room for Verisign-style toll collection, while the official ENUM tree almost requires it.
We'll see how it goes. If Vonage joins up, then DUNDi has probably won and ENUM will end up being irrelevant, because the network effect will strongly favor DUNDi.
I think everyone's spinning it wrong. The most useful thing you can do with lots of positrons would be to build an antimater-catalyzed nuclear pulse propulsion engine. With a good source for lots of positrons, you should be able to build nukes small enough to be useful.
This sort of thing doesn't surprise me at all; it's a normal part of the growth path for tech companies. At the beginning, you're swimming in techies and the company's choices reflect it. Since they have smart people but (usually) not a lot of cash, you choose products based on a combination of price and technical merit. Linux (or *BSD) on PCs usually works quite nicely. They develop innovative in-house solutions for the problems that they face. The company is successful because they're faster and more flexible and generally *smarter* then the competition.
The problem is that eventually the company will grow up. The smart people will leave for new startups, and the management will be replaced with bean-counters. The technical staff will become mostly middle-rung support people without a lot of design experience, and the cool, fast, cost-effective stuff that the founders build won't make any sense to the new folks. They won't know how to manage it, and the very concept doesn't fit into their mental model. If it breaks, who do they call for support?
At this point, the company no longer sees itself as "cutting edge" or even particularly high-tech. It sees itself as part of a stable industry and starts trying to look just like all of the other companies in the industry.
So what happens? They end up swapping all of those "hard to use" Linux systems for a big pile of Windows (or Sun, or maybe AIX) boxes, and they pay a fleet of consultants to keep things running. They pay Oracle or Peoplesoft or SAP or someone $5m for software to manage their business, and then they spend another $15m on hardware and consultants to get it up and running. And, generally, it takes them years to actually get it to work as well as the home-grown stuff that it replaced. But hey, they have someone to yell at, so they're happy.
It doesn't always go like this, but I've seen enough of it.
So, don't take Linux to Windows migrations as any sort of statement about Linux. Read them as a statement about the company doing the transition, and how they view their relationship with technology.
If you can find a Linksys PAP2-NA (around $50), then that'll give you two SIP FXS that you can use with Asterisk. There are a number of availability issues with this model (not available until early this week, now apparently either discontinued or difficult to order except through specific resellers), but they'll get sorted out in another week or two.
Well, Asterisk already lets you send voicemail via email, with the message attached as a WAV file. It can suck its VM config out of MySQL or Postgres, or it can use text files. It'll also send mail to a pager email address; I get a SMS message on my cell phone whenever I get new voicemail at home. The message includes the caller ID information as well, which makes it a snap to return calls.
There's a patch out there somewhere to tie Asterisk into Request Tracker. Done properly, you could build a really interesting support phone system--it'd record calls, stick them into the ticket queue as needed, and give you a great way to keep track of who's bugging you the most.
In many ways, Asterisk reminds me of Sendmail, circa 1996 or so. It's complex, it's sort of hard to configure (although Asterisk doesn't use line noise for config files, unlike Sendmail), but it's insanely flexible. In the early and mid 90s, you needed the flexibility, because email standards were in flux. SMTP was common, but so was UUCP and BITNET and a handful of other protocols. Gateways into non-RFC822 systems were all over the place. You needed a mail program that could handle all sorts of weird issues or you'd never be able to hack together a config that could handle your weird mail needs.
Asterisk is similar. It's complex because it's designed to be able to tie together clumps of incompatible phone systems and act in all sorts of ways that the programmers didn't really intend. You can use it as a pure VoIP system, a gateway between different VoIP systems, a plain PBX with analog phones, a VoIP extension for an existing PBX, a voice-mail system for a PBX, a dialer for a call center, or a centrex-style virtual PBX for multiple companies. It's flexible enough to let you configure it to be any of these and a thousand other things. And today, we need the flexibility because we have so many weird little phone systems that we need to tie together.
For email, things eventually changed. SMTP is king, and RFC 822 is the gold standard for email formats. Modern mailers are a lot less complex because they *CAN* be. Will the future hold something similar for telephone service? Who knows. Check back in a decade, but for now, use Asterisk.
The Polycom IP300/IP500/IP600 line seems to be the best combination of price and performance right now, at least for a business environment. You can get cheap phones (the Grandstream Budgetone is around $70), but they're cheap and missing some features.
Asterisk doesn't have native LDAP support, but it's not very hard to write a script that produces a set of Asterisk config files out of LDAP data. With a bit more work, you could script Asterisk to do LDAP lookups, but it'll take too much work to be worth it for small (100 users) sites.
Ignoring the free iPod issue, this is free software (GPL, even) that we're talking about. It's not v1.0 of some random commercial program. It's v1.0 of the premier Linux VoIP package. That makes it news.
It depends on your needs. There have been suggestions that some CLECs are using Asterisk internally, and there are certainly a ton of VoIP startups using it. The general impression that I get is that you don't want to run more then 100 simultaneous connections through a single Asterisk server. If you want more, then add more servers and share the load. If you're doing a lot of compression on the server, the number may drop below 100.
Fortunately, Asterisk does a decent job of sharing information between multiple servers, but setting up a large multi-system PBX still isn't going to be trivial.
If you're using VoIP phones (Cisco, Polycom, etc), then there's no real limit to how many employees you can service with a single server. If you're using analog phones, then you should probably limit yourself to around 4 T1s worth of phones per server.
Go read Charlie Stross's "Antibodies." It's a fascinating SF short story that starts out with a proof of P=NP and goes off from there. To the best of my knowledge, it's not available online anywhere, but it's not too hard to track down on paper.
Or, for that matter, go read anything of his. It's pretty much all good.
Exactly. There are a *ton* of perfectly legitimate uses for this.
Simple example: a "follow-me" phone number that will automatically forward calls to my home phone, cell phone, office phone, or wherever I am. It's trivial to set up Asterisk to take incoming calls and then dial back out to some other number and tie the two calls together. It's like 2 config lines. If you can set your own caller ID, then you'll see who's actually calling on the forwarded call. If you can't set the caller ID, then you'll see the number of your forwarding service, which is kind of useless.
In corporate contexts, it's sometimes useful to have outgoing calls set the caller ID to the user's DID number. That's essentially the same thing, although *sometimes* telcos will filter the allowed caller ID numbers and only let you use valid DID numbers. If you want unfiltered caller ID, then you generally have to negotiate for it, or you'll probably be screwed in the end. I mean, that's what telcos do, right?
One final point, you can usually only set the caller ID number. The caller ID name comes from a central database and is produced via a database lookup over SS7.
Slashdot Mirror
That's not exactly true; SNI allows for HTTPS multihoming, and it's supported by the HTTPS on pretty much every modern platform, *except* for Windows XP. Browsers that use Window's HTTPS code (most of them, IIRC) can't cope with SNI on XP, so no one actually uses it anywhere yet.
I work for Google, and there *are* some people who work insane hours every days, but that's not really typical. In Mountain View, a large percentage of the population leaves around 5 or 6. Sure, some people work late every day, but they're usually the same people who arrive late every day. Google isn't really the sort of place that values Spending A Lot Of Time At The Office. People are judged by what they've accomplished, not how many hours they were around looking busy.
:-).
If anything, the problem with Google is that there's *so* much cool stuff going on--you know, if you have a bit of free time, then the temptation to work on cool project AAA or BBB can be hard to resist
Most of my Microsoft friends work longer hours then I do, but I can't claim that they're a representative sample.
As for the Seattle vs The Bay Area debate--you do know that both companies have offices practically right next to each other in both areas, don't you? MS's Silicon Valley campus is under 3 minutes from Google, and our Kirkland office is probably only 5 minutes from MS on a good traffic day. I work in Kirkland, it's a nice office, and we have a lot of fresh college grads from around the country. If location matters, then talk to your recruiter (for either company), and I suspect they can work something out.
All things considered, I suspect that the original poster would be happier at Google, but I'm kind of biased.
Let's see--it's an article on how RSS is the future of business communication, hosted on a site that sells business RSS services, written by the site's owner, and submitted to Slashdot by the author.
Then fed to me via Slashdot's RSS feed.
Yep, that's the future of advertising via RSS if I ever saw it.
Yeah, they haven't used SSNs for student IDs for at least 15 years.
Yeah, but that'd be a visible CPU bug, and it wouldn't have made it past Intel's validation in the first place.
My personal guess is that it's a timing attack based on CPU performance counters--both threads can read the performance-counting data for the CPU, so they'll have access to a ton of details data. This includes things like branch prediction, which may be enough to *slowly* reconstruct all of the bits in an RSA key that's used over and over.
Okay, how about a different approach: I'd love to have this in a format that I can stick on an iPod or burn onto a CD so I can listen to it in my car. I don't really care about open source players, but open *formats* are really important.
Sheesh, he's been using the G5 for over a year now.
While Google may or may not be working on a calendar, his "evidence" is lacking. Basically, he's saying that Google is walking his calendar a lot, and using that as evidence that Google is building itself a calendar. There's a much simpler explanation: Google goes nuts when it runs into PHP iCalendar. It sees every link as a new page to look at, and after a few runs by googlebot, it's trying to index the daily calendar page for every day within a decade of today. I've been dealing with this today, adding robots.txt entries to keep it away from PHP iCalendar, because Googlebot is generating thousands of hits per day on my little site.
So, just because Googlebot and PHP iCalendar don't get along, that doesn't mean that Google is busy building up a monster searchable calendar.
Having said that, I'd love to see a gmail calendar component that you could access via WebDAV. I don't see how they'd make money on it, though.
You're about 10 years too late for this discussion. CSS has been a part of the standards landscape for around a decade now, and it's been bog-common for at least a few years.
"Why do we even have that button?" Because it's basically required by law. Covering them with a plastic cover doesn't seem to help either--Internap did that the *last* time someone hit the EPO button in this datacenter.
Yeah, but it's not just for the fire department--by the time they got there, the tech'd be dead. As I understand it, it's really for local staff so they can kill the power if there's an imminent danger to another tech's life. The canonical example is an IBM tech with his tie stuck in a herking huge printer--either hit the EPO button or watch him get line-fed through the thing. While this exact example my not apply in colo spaces (I've never seen any big mechanical devices in any of the ones that I've been in), it's still important for electrical fires. Presumably, that's the main reason that we're required to put the damn things in.
A couple points. First, there's *nothing* that you can do about the "idiot hit the big red button" problem--you're required by law to have the button, because it's a safety issue. It has to be accessible--you can't lock it in a closet. And everyone knows that if you put a big red button on a wall, sooner or later someone's going to hit it.
I don't know what happened this time, but the ~2002 Internap Seattle outage was caused by an idiot Speakeasy tech who couldn't figure out how to use the exit door, so hit hit the Big Red Button instead.
I worked for Internap at the time, and I spent weeks stuck inside that colo facility. It was basically the only "dot-com" grade thing that Internap built (they were usually somewhat thrifty, at least pre-2001). It sparkled. Everything was over-engineered. You had to go through multiple rounds of security to get access to anything.
The last I heard last night, no one quite knew what'd happened yet. Apparently, multiple redundant power systems all failed at the same time. This facility was designed by a company that already had ~5 years experience running high-end colo facilities, and it was designed as the flagship facility for showing off to potential customers. This isn't a hole-in-the-wall hosting place, it's more of a bunker hiding in the shadow of the Space Needle. So, frankly, it'll be very interesting to see what happened, because no money was spared to keep this sort of thing from happening.
(Disclaimer: I haven't worked for Internap since 2002. I still own a bit of stock, because it's not worth the hassle of selling it for what little it's worth. It's not really the same company now that it was when I started in '98, and only a handful of my former coworkers are still with the company. I'm not even going to *start* with my opinion of the current management.)
Well, look at things this way: ENUM has been around for *years*, yet there's still no official ENUM tree. There's no way for VoIP carriers like Vonage to publish SIP addresses for the PSTN numbers that they service.
Why? Because of political squabbling by telcos, verisign, and the like. Whoever controls the ENUM tree will be able to control the future of telecommunications. That means money and power, and that's why there's no progress occuring--all of the usual players are jockeying for position, and will be for years.
Since ENUM is really just a DNS tree, that hasn't stopped people from producing their own ENUM trees (e164.org, etc), but there's nothing particularly official about any of them. They're all interim solutions, and none of them are big enough to be able to make a difference on their own.
There are a couple differences with DUNDi. First, it's *designed* to be decentralized, without a single point of control (or toll collection). There's an open-source implementation right out of the gate. It at least pays lip service to spam and telemarketing issues. As long as you sign the agreement, it *should* be possible for anyone to participate. And, it already has several mid-sized providers involved.
In short, right out of the gate, DUNDi is already ahead of ENUM, because it's already usable, while ENUM still doesn't have any way to publish numbers in the "official" e164.arpa tree. DUNDi doesn't have room for Verisign-style toll collection, while the official ENUM tree almost requires it.
We'll see how it goes. If Vonage joins up, then DUNDi has probably won and ENUM will end up being irrelevant, because the network effect will strongly favor DUNDi.
I think everyone's spinning it wrong. The most useful thing you can do with lots of positrons would be to build an antimater-catalyzed nuclear pulse propulsion engine. With a good source for lots of positrons, you should be able to build nukes small enough to be useful.
This sort of thing doesn't surprise me at all; it's a normal part of the growth path for tech companies. At the beginning, you're swimming in techies and the company's choices reflect it. Since they have smart people but (usually) not a lot of cash, you choose products based on a combination of price and technical merit. Linux (or *BSD) on PCs usually works quite nicely. They develop innovative in-house solutions for the problems that they face. The company is successful because they're faster and more flexible and generally *smarter* then the competition.
The problem is that eventually the company will grow up. The smart people will leave for new startups, and the management will be replaced with bean-counters. The technical staff will become mostly middle-rung support people without a lot of design experience, and the cool, fast, cost-effective stuff that the founders build won't make any sense to the new folks. They won't know how to manage it, and the very concept doesn't fit into their mental model. If it breaks, who do they call for support?
At this point, the company no longer sees itself as "cutting edge" or even particularly high-tech. It sees itself as part of a stable industry and starts trying to look just like all of the other companies in the industry.
So what happens? They end up swapping all of those "hard to use" Linux systems for a big pile of Windows (or Sun, or maybe AIX) boxes, and they pay a fleet of consultants to keep things running. They pay Oracle or Peoplesoft or SAP or someone $5m for software to manage their business, and then they spend another $15m on hardware and consultants to get it up and running. And, generally, it takes them years to actually get it to work as well as the home-grown stuff that it replaced. But hey, they have someone to yell at, so they're happy.
It doesn't always go like this, but I've seen enough of it.
So, don't take Linux to Windows migrations as any sort of statement about Linux. Read them as a statement about the company doing the transition, and how they view their relationship with technology.
If you can find a Linksys PAP2-NA (around $50), then that'll give you two SIP FXS that you can use with Asterisk. There are a number of availability issues with this model (not available until early this week, now apparently either discontinued or difficult to order except through specific resellers), but they'll get sorted out in another week or two.
Well, Asterisk already lets you send voicemail via email, with the message attached as a WAV file. It can suck its VM config out of MySQL or Postgres, or it can use text files. It'll also send mail to a pager email address; I get a SMS message on my cell phone whenever I get new voicemail at home. The message includes the caller ID information as well, which makes it a snap to return calls.
There's a patch out there somewhere to tie Asterisk into Request Tracker. Done properly, you could build a really interesting support phone system--it'd record calls, stick them into the ticket queue as needed, and give you a great way to keep track of who's bugging you the most.
In many ways, Asterisk reminds me of Sendmail, circa 1996 or so. It's complex, it's sort of hard to configure (although Asterisk doesn't use line noise for config files, unlike Sendmail), but it's insanely flexible. In the early and mid 90s, you needed the flexibility, because email standards were in flux. SMTP was common, but so was UUCP and BITNET and a handful of other protocols. Gateways into non-RFC822 systems were all over the place. You needed a mail program that could handle all sorts of weird issues or you'd never be able to hack together a config that could handle your weird mail needs.
Asterisk is similar. It's complex because it's designed to be able to tie together clumps of incompatible phone systems and act in all sorts of ways that the programmers didn't really intend. You can use it as a pure VoIP system, a gateway between different VoIP systems, a plain PBX with analog phones, a VoIP extension for an existing PBX, a voice-mail system for a PBX, a dialer for a call center, or a centrex-style virtual PBX for multiple companies. It's flexible enough to let you configure it to be any of these and a thousand other things. And today, we need the flexibility because we have so many weird little phone systems that we need to tie together.
For email, things eventually changed. SMTP is king, and RFC 822 is the gold standard for email formats. Modern mailers are a lot less complex because they *CAN* be. Will the future hold something similar for telephone service? Who knows. Check back in a decade, but for now, use Asterisk.
The Polycom IP300/IP500/IP600 line seems to be the best combination of price and performance right now, at least for a business environment. You can get cheap phones (the Grandstream Budgetone is around $70), but they're cheap and missing some features.
Asterisk doesn't have native LDAP support, but it's not very hard to write a script that produces a set of Asterisk config files out of LDAP data. With a bit more work, you could script Asterisk to do LDAP lookups, but it'll take too much work to be worth it for small (100 users) sites.
Ignoring the free iPod issue, this is free software (GPL, even) that we're talking about. It's not v1.0 of some random commercial program. It's v1.0 of the premier Linux VoIP package. That makes it news.
It depends on your needs. There have been suggestions that some CLECs are using Asterisk internally, and there are certainly a ton of VoIP startups using it. The general impression that I get is that you don't want to run more then 100 simultaneous connections through a single Asterisk server. If you want more, then add more servers and share the load. If you're doing a lot of compression on the server, the number may drop below 100.
Fortunately, Asterisk does a decent job of sharing information between multiple servers, but setting up a large multi-system PBX still isn't going to be trivial.
If you're using VoIP phones (Cisco, Polycom, etc), then there's no real limit to how many employees you can service with a single server. If you're using analog phones, then you should probably limit yourself to around 4 T1s worth of phones per server.
Go read Charlie Stross's "Antibodies." It's a fascinating SF short story that starts out with a proof of P=NP and goes off from there. To the best of my knowledge, it's not available online anywhere, but it's not too hard to track down on paper.
Or, for that matter, go read anything of his. It's pretty much all good.
Exactly. There are a *ton* of perfectly legitimate uses for this.
Simple example: a "follow-me" phone number that will automatically forward calls to my home phone, cell phone, office phone, or wherever I am. It's trivial to set up Asterisk to take incoming calls and then dial back out to some other number and tie the two calls together. It's like 2 config lines. If you can set your own caller ID, then you'll see who's actually calling on the forwarded call. If you can't set the caller ID, then you'll see the number of your forwarding service, which is kind of useless.
In corporate contexts, it's sometimes useful to have outgoing calls set the caller ID to the user's DID number. That's essentially the same thing, although *sometimes* telcos will filter the allowed caller ID numbers and only let you use valid DID numbers. If you want unfiltered caller ID, then you generally have to negotiate for it, or you'll probably be screwed in the end. I mean, that's what telcos do, right?
One final point, you can usually only set the caller ID number. The caller ID name comes from a central database and is produced via a database lookup over SS7.
Neither--the same author wrote both the Slashdot writeup and the one on BoingBoing.