Actually all the money transfer services I know of guarantee loss. That is, they all charge a fee for the service, generally a percentage of the transaction amount. Bitcoins turn that guaranteed loss into an unpredictable loss or gain, where you bet on market movements. You would have to track the market movements over time to generate the statistic of if this is better or not, but I suspect that it is overall provided you get into and out of the bitcoins in short order.
Basically, if I want to send you money and I turn $10 in to bit coins right now and e-mail them to you, and you within an hour turn it back into USD, there's a very good chance you get a full $10. You might get $10.10. You might get $9.90. Western Unions minimum transfer fee appears to be $5, so you would only get $5 if I sent it to you that way.
Money transfer services hate small amounts. Bitcoins don't.
I don't think I'd count a $40k car as being rich man's territory. There are plenty of working class guys who drive F-250's with diesel engines for their work, and those are $40k+. A BMW M3, their best selling car in the US, can approach $45k with all the options.
A $40,000 car, financed for 5 years, at 4% interest with a $5,000 trade is $645 a month. About $7700 per year.
Totally doable on the median household income in the US of $45,000 per year. Wise? A different story, but it's not like you have to be a millionaire to buy one.
There are a lot of more complex cases. Consider nissan.com, where you can go and read all about the lawsuit.
Expecting brandname.com to work is foolish. For every unusual word, say, ikea.com, there is a very common one, say Apple.com (and the fun they had with Apple Corps, of the Beatles fame over the years). While not a domain name, there was a more humorous case lately of name space collision where Merck Germany, and Merck US fought over the Facebook URL Facebook.com/Merck. Brand names are not in any sense unique.
It's one of those unexpected consequences of the domain name system. Users expect brandname.com to work, but don't realize that's impossible for millions of businesses that share a name with a different business in another state, country, etc.
While there are services, like DynDNS with proprietary interfaces the reality is that dynamic DNS has a standard interface. RFC 2136 style updates should work with any provider, allowing equipment makers to support everyone. While DynDNS has supported people well, I hope this move makes end users demand RFC standard support in devices so that ANY dynamic DNS provider can be used. There are choices other than DynDNS, they have maintained their lead only via a proprietary interface and a market lead.
I'm not with most IT management on this one, but I always thought the best metric was customer satisfaction. For instance every time I open a ticket with Cisco I get a survey at the end of like 5 questions. Was my problem resolved, was the person polite, etc.
The other metrics suggested are things to graph and look at trends. Are repair times getting worse or better? Is the average time per ticket going up or down? They are great int he aggregate. They break down quickly when divided. Only one guy on your team knows network devices, so he gets all the network devices which include the 8 hour fiber cuts, so his times always are worse than the guys fixing printer problems, as an example. You have to be very careful as you start to divide them up.
At the end of the day though you're trying to make the customer happy. Track it, and see how your staff is doing. If people are happy with their IT support, your department will be seen in a more positive light.
Leaving aside the possibility of people acquiring the video without paying for it, he had $300,000 of costs (they don't indicate where the other $100,000 went, maybe the $202,000 figure mentioned was the up front cost and the next $98,000 was distribution). Sure, he could have perhaps found a lower cost way to distribute it but it's still $170,000 in production costs. Part of the deal with publishers of any kind is that they're taking on the risk of producing it. If it doesn't sell it's them who will be losing money, not the author or act or band, etc. In this case, Louis CK put himself in a position where he would potentially lose $170,000 at the minimum. It's only established acts who have the opportunity to take that sort of risk.
The costs you site are at best loosely coupled to the price of the show, and in many cases not coupled at all.
Round numbers, let's say there was $300k of costs and $200k of profit. In this case Louis took on all the costs, and took home all the profit.
He could have gone to some finance person (anyone from a bank to a full blown producer, and lots of folks in the middle) and cut a deal like perhaps, finance person puts up $300k, Louis and Finance person split the profits 50/50. Now finance person is out the $300k, ends up making $100k (33% ROI in 6-12 months, not bad, check out t-bills these days), and Louis nets $100k. Of course he never had to come up with the $300k.
Thing is, this is the same $500k. Same sales price, same distribution method, same no-DRM, same folks buying. The fact that the production deal changed didn't change the sales price or gross revenue. There's still room for producers and financiers, they just need to stop thinking that the fact they brought $300k to the table means they can dictate to the end consumer DRM, or double the price.
When you give consumers a product that they want, at a price they find fair, in a form factor (format) that is convenient for them, in a location that is convenient for them, they are happy to pay for it!
When I was at a University known for Computer Science in the early 1990's the CS department had zero to do with running campus services. When you have 70,000 users (we had more like 40k) IT is a large function, and not something done in the CS department's spare time. IIRC the Computing Services group had a budget of like $50 million back then, doing mail, dial up, ethernet to the dorms and offices, running the large payroll printers, keeping the mainframes that scheduled and did grade tracking up, running the phone system etc. It is a big job at a university that size, and a key to making the institution work.
1) We didn't size the system large enough to handle the possible outages.
2) The outage we didn't size for happened, basically taking everything down.
3) My team is now working on a band-aid solution, which basically involves hobbling the application.
4) Since we're incompetent, we're going to outsource this next year.
I mean, if I was the CIO's boss I would have fired him on the spot. Maybe outsourcing is a better answer than putting in place a proper system and looking at that analysis could be interesting. I see no indication any of that was done here, basically the CIO gave the Barbie response, "Mail is hard, let's go shopping." If he doesn't understand how to do it in house, he won't understand how to arrive at a good outsourcing agreement.
Which means this pretty much sums up everything that is wrong with large org IT today.
The problem with your chart is that it is only federal dollars, not state and local dollars.
Airports are generally financed with almost entirely local money. Interstates are a split between the states and the feds, and the percentage varies depending on who wants the route.
Rail is unique in America where it is a federally funded endeavor. Some states do pony up some money for commuter rail service, but most of Amtrak is federal dollars.
Come back with a graph that shows federal + state + local monies, and I'm relatively positive highways will be on top by a large margin.
I see plenty of comments on how reasonable or unreasonable the price is, and they are interesting. I generally agree it doesn't seem that out of whack price wise for a working application supported for some time period.
What I find more interesting is this story is being posted all over the web all of the sudden:
Hitting that range of sites (and more) with this sort of non-story story trying to push a narrative of the government is wasting your money? Someone behind the scenes is pushing this narrative, I suspect. Not news for nerds, but manufactured political outrage.
Ubiquiti has some very cool products and customer support, you might want to look into their gear.
If you can get line of site from the remote sites back to the central site you should use 5Ghz for the backhaul, and 2.4Ghz for the client side radio. This will reduce your interference. Also, the backhaul should use _very_ directional antennas since the two endpoints are known. This will also prevent interference. It doesn't sound like any of your distances are enough to require a multi-wireless hop, although your sight lines may require it. Avoiding a double hop will increase performance.
You'll also want some intelligent QoS on both the WiFi and cable modem side. You don't want one user to be able to make the experience really bad for all the other users. For instance, if you had a 20Mbps cable modem you might want to limit any one IP/MAC to 5Mbps, or so. WRED or similar can also be your friend. Make sure there is a good local DNS server, as well
I'm confused why BIND would be more critical than Apache (to use your example).
DNS is, from the start, a robust, distributed system. If you have 4-6 name servers for your domain (as you should) and one is down for any reason (network unreachable, server dead, BIND crashed, whatever) users _should not notice_. Caching resolvers will automatically query other name servers, life will move on. Compare with widely used software such as Apache, Sendmail, Firefox, when those fail typically a user notices.
Indeed, I would recommend anyone with _mission critical_ DNS needs operate multiple name servers _and use multiple software packages_. For instance the root servers are mix of BIND and NSD. Every software can have a bug, having ecosystem diversity is a good hedge, particularly when the protocol is already designed to deal with multiple servers.
I admit BIND9 could do a lot better. It was conceived in the late 1990's, and written in the early 2000's. Computer Science evolves quickly, and there have been a lot of advancements since that time and BIND9 has not kept up. But that is why there is a BIND10 project now. If you have input I strongly suggest you contribute to it as it's a much more open development model than BIND9.
The only bright line I want to draw is behind BIND 4/8 and BIND 9/10. It's actually sad they all have the same name. BIND 4 and 8 are junk, and gave BIND a very bad reputation that continues to this day. They are a major reason some of the competitive products exist. BIND9 was a clean start to change the gap, and hopefully BIND10 will be a quantum leap forward. Painting them all with the same brush is wrong.
There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.
As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.
BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.
I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.
I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.
If you go back to ISC's Software Support page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went out in all forums pretty much at the same time due to the severity, but lesser issues may be released in a staged fashion.
This particular vulnerability applies only to BIND9 operating as a recursive resolver. BIND9 operating in authoritative mode, similar to how TinyDNS operates, is unaffected. Had you properly deployed BIND9 for the same purposes you are using TinyDNS you would not had been impacted by this issue.
BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on/. who are not familiar with these two ISC's will get them confused.
The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.
Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.
This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.
Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via/. look into a support contract so you get them directly from the vendor.
The International Traffic in Arms Regulation are a Waste Of Fucking Time And Money.
There's this crazy notion that we can keep technology from folks by not selling it to them. Yet there is a thousand ways for folks to get the same technology, from paying a middle man, to sending people here to use it and recreate it. The absolute best case is delaying, by a small amount of time, how long before they get the technology.
It's also quite hypocritical that this technology is A-Ok for US companies to use on US citizens working for them....but somehow if Syria uses it to determine what Syrians see it's evil. That really doesn't make any sense.
They should call up the people at CSI. They already have the tech, you put a fuzzy picture on the computer screen, say "Enhance" to it, and it shows you the original document. They just need to use whatever software those TV folks are using.
SSD's have been gaining on hard drives for some time for a number of reasons, but price has been the primary area where HDD's could compete. With this event causing HDD's to be more expensive, is it finally the tipping point to SSD for most consumer products?
Apple pretty much is never the first company to do something.
What Apple is famous for (in recent times) is being the first to do something _well_. They don't ride the bleeding edge, but rather take the bleeding edge tech and polish and hone it until they have something an average Joe would use.
The world hasn't had enough time with iOS 5 Siri yet. I expect it will be much more polished than anything you mention, but it's simply too soon to tell. Also, I found it telling Apple calls this "Beta" technology which is rather rare for them. That tells me they expect rapid, and significant improvements. That level of attention could make this a much better product very quickly.
A good touch typer can accurately do 60 wpm (http://en.wikipedia.org/wiki/Touch_typing). I've seen ones that can come close to 100 wpm with relatively few errors, at least in short bursts.
Typical speech rates are 140-200 wpm, depending on the subject and the speakers mood (http://itre.cis.upenn.edu/~myl/languagelog/archives/005018.html). Pretty much everyone can speak and comprehend 300 wpm (http://en.wikipedia.org/wiki/Words_per_minute), and some people can speak as high has 500 wpm. You can read around 300 wpm.
I suspect the reality is you type at somewhere between 25-50% of the speed you can talk, and that's for ordinary words. Throw in special characters that require you to do complex keystrokes and your typing will tank, but your speech will not. For instance, check your words per minute typing something like this vrs reading it (assuming you have a standard US keyboard).
Please tell Mr Muños that it is £200 or ¥20,000; and Mr Schröder would like a response immediately.
I bet you can say that as fast as any other sentence, but typing it will require you to look up a character or two unless you type international stuff a lot.
It is possible to configure your mailer to require all sorts of things, like rDNS. If you configure all of them you will get almost no spam, but you'll also not get 50% of your legitimate e-mail. Perhaps that's ok with you, you're willing to only talk to the "clueful".
Most people though want to get mail. The old Internet axiom "Be conservative with what you send, be liberal with what you accept" applies. WIth spam fighting this generally means use every mechanism at your disposal (including rDNS existence, or matching with forward DNS); but use it only to affect the score of a message. That way the guy who doesn't have rDNS right, but does everything else right will still get through.
Slashdot Mirror
Actually all the money transfer services I know of guarantee loss. That is, they all charge a fee for the service, generally a percentage of the transaction amount. Bitcoins turn that guaranteed loss into an unpredictable loss or gain, where you bet on market movements. You would have to track the market movements over time to generate the statistic of if this is better or not, but I suspect that it is overall provided you get into and out of the bitcoins in short order.
Basically, if I want to send you money and I turn $10 in to bit coins right now and e-mail them to you, and you within an hour turn it back into USD, there's a very good chance you get a full $10. You might get $10.10. You might get $9.90. Western Unions minimum transfer fee appears to be $5, so you would only get $5 if I sent it to you that way.
Money transfer services hate small amounts. Bitcoins don't.
I don't think I'd count a $40k car as being rich man's territory. There are plenty of working class guys who drive F-250's with diesel engines for their work, and those are $40k+. A BMW M3, their best selling car in the US, can approach $45k with all the options.
A $40,000 car, financed for 5 years, at 4% interest with a $5,000 trade is $645 a month. About $7700 per year.
Totally doable on the median household income in the US of $45,000 per year. Wise? A different story, but it's not like you have to be a millionaire to buy one.
There are a lot of more complex cases. Consider nissan.com, where you can go and read all about the lawsuit.
Expecting brandname.com to work is foolish. For every unusual word, say, ikea.com, there is a very common one, say Apple.com (and the fun they had with Apple Corps, of the Beatles fame over the years). While not a domain name, there was a more humorous case lately of name space collision where Merck Germany, and Merck US fought over the Facebook URL Facebook.com/Merck. Brand names are not in any sense unique.
It's one of those unexpected consequences of the domain name system. Users expect brandname.com to work, but don't realize that's impossible for millions of businesses that share a name with a different business in another state, country, etc.
While there are services, like DynDNS with proprietary interfaces the reality is that dynamic DNS has a standard interface. RFC 2136 style updates should work with any provider, allowing equipment makers to support everyone. While DynDNS has supported people well, I hope this move makes end users demand RFC standard support in devices so that ANY dynamic DNS provider can be used. There are choices other than DynDNS, they have maintained their lead only via a proprietary interface and a market lead.
I'm not with most IT management on this one, but I always thought the best metric was customer satisfaction. For instance every time I open a ticket with Cisco I get a survey at the end of like 5 questions. Was my problem resolved, was the person polite, etc.
The other metrics suggested are things to graph and look at trends. Are repair times getting worse or better? Is the average time per ticket going up or down? They are great int he aggregate. They break down quickly when divided. Only one guy on your team knows network devices, so he gets all the network devices which include the 8 hour fiber cuts, so his times always are worse than the guys fixing printer problems, as an example. You have to be very careful as you start to divide them up.
At the end of the day though you're trying to make the customer happy. Track it, and see how your staff is doing. If people are happy with their IT support, your department will be seen in a more positive light.
Leaving aside the possibility of people acquiring the video without paying for it, he had $300,000 of costs (they don't indicate where the other $100,000 went, maybe the $202,000 figure mentioned was the up front cost and the next $98,000 was distribution). Sure, he could have perhaps found a lower cost way to distribute it but it's still $170,000 in production costs. Part of the deal with publishers of any kind is that they're taking on the risk of producing it. If it doesn't sell it's them who will be losing money, not the author or act or band, etc. In this case, Louis CK put himself in a position where he would potentially lose $170,000 at the minimum. It's only established acts who have the opportunity to take that sort of risk.
The costs you site are at best loosely coupled to the price of the show, and in many cases not coupled at all.
Round numbers, let's say there was $300k of costs and $200k of profit. In this case Louis took on all the costs, and took home all the profit.
He could have gone to some finance person (anyone from a bank to a full blown producer, and lots of folks in the middle) and cut a deal like perhaps, finance person puts up $300k, Louis and Finance person split the profits 50/50. Now finance person is out the $300k, ends up making $100k (33% ROI in 6-12 months, not bad, check out t-bills these days), and Louis nets $100k. Of course he never had to come up with the $300k.
Thing is, this is the same $500k. Same sales price, same distribution method, same no-DRM, same folks buying. The fact that the production deal changed didn't change the sales price or gross revenue. There's still room for producers and financiers, they just need to stop thinking that the fact they brought $300k to the table means they can dictate to the end consumer DRM, or double the price.
When you give consumers a product that they want, at a price they find fair, in a form factor (format) that is convenient for them, in a location that is convenient for them, they are happy to pay for it!
There are 4 boxes to protect your democracy.
Soap box, ballot box, jury box, and ammo box.
Please use them in that order.
When I was at a University known for Computer Science in the early 1990's the CS department had zero to do with running campus services. When you have 70,000 users (we had more like 40k) IT is a large function, and not something done in the CS department's spare time. IIRC the Computing Services group had a budget of like $50 million back then, doing mail, dial up, ethernet to the dorms and offices, running the large payroll printers, keeping the mainframes that scheduled and did grade tracking up, running the phone system etc. It is a big job at a university that size, and a key to making the institution work.
The press pretty much reads like this to me:
1) We didn't size the system large enough to handle the possible outages.
2) The outage we didn't size for happened, basically taking everything down.
3) My team is now working on a band-aid solution, which basically involves hobbling the application.
4) Since we're incompetent, we're going to outsource this next year.
I mean, if I was the CIO's boss I would have fired him on the spot. Maybe outsourcing is a better answer than putting in place a proper system and looking at that analysis could be interesting. I see no indication any of that was done here, basically the CIO gave the Barbie response, "Mail is hard, let's go shopping." If he doesn't understand how to do it in house, he won't understand how to arrive at a good outsourcing agreement.
Which means this pretty much sums up everything that is wrong with large org IT today.
The problem with your chart is that it is only federal dollars, not state and local dollars.
Airports are generally financed with almost entirely local money. Interstates are a split between the states and the feds, and the percentage varies depending on who wants the route.
Rail is unique in America where it is a federally funded endeavor. Some states do pony up some money for commuter rail service, but most of Amtrak is federal dollars.
Come back with a graph that shows federal + state + local monies, and I'm relatively positive highways will be on top by a large margin.
I see plenty of comments on how reasonable or unreasonable the price is, and they are interesting. I generally agree it doesn't seem that out of whack price wise for a working application supported for some time period.
What I find more interesting is this story is being posted all over the web all of the sudden:
And of course here on /.
Hitting that range of sites (and more) with this sort of non-story story trying to push a narrative of the government is wasting your money? Someone behind the scenes is pushing this narrative, I suspect. Not news for nerds, but manufactured political outrage.
Ubiquiti has some very cool products and customer support, you might want to look into their gear.
If you can get line of site from the remote sites back to the central site you should use 5Ghz for the backhaul, and 2.4Ghz for the client side radio. This will reduce your interference. Also, the backhaul should use _very_ directional antennas since the two endpoints are known. This will also prevent interference. It doesn't sound like any of your distances are enough to require a multi-wireless hop, although your sight lines may require it. Avoiding a double hop will increase performance.
You'll also want some intelligent QoS on both the WiFi and cable modem side. You don't want one user to be able to make the experience really bad for all the other users. For instance, if you had a 20Mbps cable modem you might want to limit any one IP/MAC to 5Mbps, or so. WRED or similar can also be your friend. Make sure there is a good local DNS server, as well
I'm confused why BIND would be more critical than Apache (to use your example).
DNS is, from the start, a robust, distributed system. If you have 4-6 name servers for your domain (as you should) and one is down for any reason (network unreachable, server dead, BIND crashed, whatever) users _should not notice_. Caching resolvers will automatically query other name servers, life will move on. Compare with widely used software such as Apache, Sendmail, Firefox, when those fail typically a user notices.
Indeed, I would recommend anyone with _mission critical_ DNS needs operate multiple name servers _and use multiple software packages_. For instance the root servers are mix of BIND and NSD. Every software can have a bug, having ecosystem diversity is a good hedge, particularly when the protocol is already designed to deal with multiple servers.
I admit BIND9 could do a lot better. It was conceived in the late 1990's, and written in the early 2000's. Computer Science evolves quickly, and there have been a lot of advancements since that time and BIND9 has not kept up. But that is why there is a BIND10 project now. If you have input I strongly suggest you contribute to it as it's a much more open development model than BIND9.
The only bright line I want to draw is behind BIND 4/8 and BIND 9/10. It's actually sad they all have the same name. BIND 4 and 8 are junk, and gave BIND a very bad reputation that continues to this day. They are a major reason some of the competitive products exist. BIND9 was a clean start to change the gap, and hopefully BIND10 will be a quantum leap forward. Painting them all with the same brush is wrong.
There has not been a single remote-root exploit in BIND9 since it was offered up to the world circa 2001. It was a complete rewrite with new goals, so taking BIND 4.x or BIND 8.x as examples isn't really relevant.
ISC is also completely open about security issues, listing them all on the web site and registering them with the CVE Registry.
As I stated in another post, the goal of BIND9 was use use various constructs (like assertions) to check data integrity, where possible on the fly and where not practical in a way that causes a core dump. That to fail safe was the best option, and crashing in a way the bug could be fixed was a positive. If you view the advisories against BIND9 you'll see that strategy has worked very well. Of course there's no reason not to lock any application in a VM, jail, chroot or whatever to get additional security, but I think the track record of BIND9 compared to most other major open source software is decent.
BIND is also "full featured". Many of the folks here reference alternatives like NSD, tinyDNS, or Unbound which provide limited functionality compared to BIND. Obviously if you're willing to limit the functionality you limit the bug exposure, but that's true both if you use software that doesn't include the functionality but also if you disable that functionality in BIND. For instance the bug in question affects recursive resolvers only, if your BIND9 instance is an authority only configuration there is no exposure.
I'm afraid most of BIND's bad reputation comes from BIND 4.x and BIND 8.x, both of which were quite bad (for different reasons). BIND9 was a departure, and now ISC is working on BIND 10, which should be yet another large leap forward.
I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.
If you go back to ISC's Software Support page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went out in all forums pretty much at the same time due to the severity, but lesser issues may be released in a staged fashion.
This particular vulnerability applies only to BIND9 operating as a recursive resolver. BIND9 operating in authoritative mode, similar to how TinyDNS operates, is unaffected. Had you properly deployed BIND9 for the same purposes you are using TinyDNS you would not had been impacted by this issue.
BIND is written by Internet Systems Consortium aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center aka ISC, a project of the SANS Technology Institute. There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.
The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313.
I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.
Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.
This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.
Internet Software Consortium also offers support for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.
The International Traffic in Arms Regulation are a Waste Of Fucking Time And Money.
There's this crazy notion that we can keep technology from folks by not selling it to them. Yet there is a thousand ways for folks to get the same technology, from paying a middle man, to sending people here to use it and recreate it. The absolute best case is delaying, by a small amount of time, how long before they get the technology.
It's also quite hypocritical that this technology is A-Ok for US companies to use on US citizens working for them....but somehow if Syria uses it to determine what Syrians see it's evil. That really doesn't make any sense.
They should call up the people at CSI. They already have the tech, you put a fuzzy picture on the computer screen, say "Enhance" to it, and it shows you the original document. They just need to use whatever software those TV folks are using.
Free and open huh? So you can just download and install Ice Cream Sandwich on all those phones they say don't support it, I guess.
Oh, you can't? So perhaps not so free and open...
SSD's have been gaining on hard drives for some time for a number of reasons, but price has been the primary area where HDD's could compete. With this event causing HDD's to be more expensive, is it finally the tipping point to SSD for most consumer products?
Apple pretty much is never the first company to do something.
What Apple is famous for (in recent times) is being the first to do something _well_. They don't ride the bleeding edge, but rather take the bleeding edge tech and polish and hone it until they have something an average Joe would use.
The world hasn't had enough time with iOS 5 Siri yet. I expect it will be much more polished than anything you mention, but it's simply too soon to tell. Also, I found it telling Apple calls this "Beta" technology which is rather rare for them. That tells me they expect rapid, and significant improvements. That level of attention could make this a much better product very quickly.
A good touch typer can accurately do 60 wpm (http://en.wikipedia.org/wiki/Touch_typing). I've seen ones that can come close to 100 wpm with relatively few errors, at least in short bursts.
Typical speech rates are 140-200 wpm, depending on the subject and the speakers mood (http://itre.cis.upenn.edu/~myl/languagelog/archives/005018.html). Pretty much everyone can speak and comprehend 300 wpm (http://en.wikipedia.org/wiki/Words_per_minute), and some people can speak as high has 500 wpm. You can read around 300 wpm.
I suspect the reality is you type at somewhere between 25-50% of the speed you can talk, and that's for ordinary words. Throw in special characters that require you to do complex keystrokes and your typing will tank, but your speech will not. For instance, check your words per minute typing something like this vrs reading it (assuming you have a standard US keyboard).
Please tell Mr Muños that it is £200 or ¥20,000; and Mr Schröder would like a response immediately.
I bet you can say that as fast as any other sentence, but typing it will require you to look up a character or two unless you type international stuff a lot.
It is possible to configure your mailer to require all sorts of things, like rDNS. If you configure all of them you will get almost no spam, but you'll also not get 50% of your legitimate e-mail. Perhaps that's ok with you, you're willing to only talk to the "clueful".
Most people though want to get mail. The old Internet axiom "Be conservative with what you send, be liberal with what you accept" applies. WIth spam fighting this generally means use every mechanism at your disposal (including rDNS existence, or matching with forward DNS); but use it only to affect the score of a message. That way the guy who doesn't have rDNS right, but does everything else right will still get through.