My experiences with Alphas were universally bad. The Unix they ran was a flaky bitch, and in any given cluster you were guaranteed to have a few of the machine go during a long computation. Then again, they were expensive.
As long as DNS root servers are unsigned, how can the regular DNS servers start to implement that? Sweden and Puerto Rico???
In the ideal world, to verify that a DNS answer is correct, you start the chain of trust at the root, then follow to a top-level domain (TLD), and continue on down the tree until you get to your final answer.
If at any point a zone does not have a DS record pointing to it, then the chain of trust is broken, and the ultimate answer will be unsecured. But this follows the usual DNS hierarchy... if your parent provides DNSSEC, then you have the option to secure your zone.
But since the root is not signed, you cannot start the chain of trust at the root. A resolver needs to have the public key configured for each of the zones that it knows are secured... these zones are called "trust anchors".
The problem with this is that there are hundreds of zones in the root. Finding the public key for each zone is a very heavy administrative task, as is getting new keys when the old ones expire. Going further down in the tree makes things even worse.
One proposed solution, designed as a temporary measure until the root is signed, is DLV. With DLV, you use normal DNSSEC, but if you don't find a trust anchor anywhere in the tree, then you look at another special tree.
So, say you were looking for "www.mydomain.example.com", and there was no trust anchor. You would then look in a DLV server for "www.mydomain.example.com", then "mydomain.example.com", then "example.com", and finally ".com". If at any point a DLV entry was found, you would follow that chain of trust.
What DLV does is basically create a "second root" just for securing DNS. It's not a good solution, but it is better than nothing. The main goal is to allow people to use DNSSEC easily while waiting for ICANN to sign the root.
<full_disclosure> The DLV solution is being pushed by my company, ISC. We run a DLV registry, which is free for all to both publish data in and query. </full_disclosure>
..but I do not see some sort of market here that is willing to pay the implementation/deployment of DNSSEC.
As I see it, security is like insurance. It's a cost that gives you nothing... until after you've had a problem.
Maybe the costs of DNSSEC outweigh the benefits. I think that's probably true today... for lower-level domains at least. For organizations who's main job is providing DNS (like the root servers, ccTLDs, and so on) then the cost is not so high and the potential risks are great.
The costs of DNSSEC will start to decrease as the technology gets more mature. It's currently moving from bleeding-edge to cutting-edge.:)
But nobody (or not many people) use DNSSEC to encrypt zone transfers, and almost everybody hits a recursive nameserver run by your ISP or perhaps local to your company's network, which means that the end-user is never going to know whether the DNS query they issued returned a signed response or was forged from the authoritative DNS server.
First, lets clear up some misconceptions here.
DNSSEC never encrypts transfers, whether zone transfers or other queries. One of the design decisions (documented in the 1990s) is that DNS is a public protocol. So there is no provision to hide data. DNSSEC rather allows cryptographically signed responses, so you can authenticate that the information came from the right place.
Also, the attack you describe (giving bogus data to secondaries) is exactly one of the problems DNSSEC is designed to protect against. With DNSSEC queries (NSEC or NSEC3), it is not possible to spoof queries merely by sending secondaries bad data via a zone transfer (AXFR or IXFR). Like all public key cryptography, it is not possible to sign a DNS record without the private key. The client can check to verify that replies have been signed by the holder of the private key for the zone.
Also, when people talk about using DNSSEC for zone transfers, they really mean using TSIG. Unlike NSEC or NSEC3, which uses public key, TSIG uses a shared key. In this way, it's basically a password that the primary and secondary servers agree on. It's much simpler to understand and implement than NSEC/NSEC3, because the problem is simpler.
As for your claim that nobody uses DNSSEC for zone transfers, I think this is not true. TSIG has been around for a long time, and is easy to use. Sites that host large numbers of DNS zones, either as primary or secondary, often require TSIG (or at least strongly encourage it). Also, a lot of people who run their own primary/secondary infrastructure use it between servers (this is of course easier if you control all servers for a zone).
As to what percentage of zone transfers are TSIG protected... this is an impossible number to get. So I propose the further discussion needs to be held over beers at a pub somewhere, since there is no actual data.;)
The Linux man page for pthread_join() hints at the answer to your question:
The pthread_join() function is a convenience that has proven useful in
multi-threaded applications. It is true that a programmer could simulate this function if it were not provided by passing extra state as
part of the argument to the start_routine(). The terminating thread
would set a flag to indicate termination and broadcast a condition that
is part of that state; a joining thread would wait on that condition
variable. While such a technique would allow a thread to wait on more
complex conditions (for example, waiting for multiple threads to terminate), waiting on individual thread termination is considered widely
useful. Also, including the pthread_join() function in no way precludes
a programmer from coding such complex waits. Thus, while not a primitive, including pthread_join() in this volume of IEEE Std 1003.1-2001
was considered valuable.
That's about 40 locations. Now, each of which has a couple of servers, a management box, and a couple of routers, so yeah something like 200 machines total.
I've never had good IT support for software, except from MySQL. It was still a bit painful to get to the engineer who could actually make the code changes to fix the problems, but it did happen, and the problems were fixed.
It is similar to what happens in countries like the Netherlands (or other nordic countries) where people *avoid* pay rises because sometimes having a rise of 10% they have to pay more taxes and end earning less than what they earned before the "raise".
In the 6 years that I've been in the Netherlands (3 as a manager), I've never known anyone to turn down a pay raise. (If you know such people, please let me know... we might want to hire them.) The system does not work as you describe. Making more money always gives you more money.
There may be other reasons to worry about a high income, such as being forced to leave rent controlled housing, but this is not tax related.
I think what drinkypoo is trying to say is simply that there is no right to make money at any particular activity.
There are tons of professions and industries that have disappeared or been relegated to fringe activities... coopers, glassblowers, phrenologists, jesters, scribes; the list goes on and on and on.
Would society really be better off if we were required to use wooden barrels crafted by masters to store liquids?
Should psychologists be required to have a professional read the bumps on someone's head before making a diagnosis?
Perhaps we should all pay a "scribe tax" on every photocopy we make?
The point is, times change, and sometimes professions and entire industries just become... obsolete. It sucks for people who earn their living that way, or who have a romantic attachment (think of the mystique around "the age of sail"), but overall it's okay. Life goes on. People find new ways to live, and new ways to express themselves and interact with each other.
Digital media and the Internet may have made big production movies and TV and platinum albums a thing of the past. A pity if you like Cecil B. Demille, not such a shame if you like live jazz.:)
Buried deep down in TFA (okay, in the first paragraph):
By improving our analysis of the link structure of the web, Google has begun minimizing the impact of many Googlebombs. Now we will typically return commentary, discussions, and articles about the Googlebombs instead.
In Greg Bear's book Eon, one of the ideas is building with geometry. A mathematician investigating one such structure asked some engineers to build a pi-meter to use when she was exploring. I wondered what such a thing could mean, and indeed how one would build such a device...
Mysql has a GPL/Commercial dual licensing model. And because connection to mysql means linking to the client, which is "derivative work" in terms of the GPL, you can only use GPL'ed software with mysql. Unless you pay them to use their commercial license of course.
Well, that's GPL. You appear to be arguing that GPL is only "semi-free" (your own words).
But if you don't like GPL, MySQL allows you to use any of the following licenses with clients:
It sounds like you just don't know how to deal with FreeBSD. That would explain the poor performance you experienced, and how it is completely contrary to what we've found.
For the heavest application at my last job, the load pattern was very query heavy, although the application stored intermediate results in temporary tables. This application is heavily threaded, creating two threads per user connection, plus the MySQL thread, so we're talking like 150 threads created & destroyed per second.
Our original platform was Solaris, and performance was excellent (well, excellent considering the dog-slow CPUs that Sun makes).
We eventually migrated to Linux, but this was possible only after the new thread libraries (well, new at the time). Performance then was quite good.
We found MySQL under FreeBSD basically unusable under heavy loads.
We never tweaked any of the systems. We did try a few thread libraries under FreeBSD, but they all sucked.
But after a few years I realised that my worldview is more similar to the country I live in (the Netherlands) than the country I'm from (the USA).
Why should I try to convince 300 million Americans to have the life that I enjoy, when I have found 16 million people who already do? Americans like their country the way it is.
Holland is crowded, expensive, and the weather sucks. But it's got way more actual freedom than the US, there is almost no poverty, violence is low, and people care way more about enjoying life than working. It works for me.
One of my friends just returned from the USA, and he misses it. He misses his cars, the hundreds of channels on the TV, the cheap food with good service. He misses being able to pay money to have his problems go away. He misses people who are excited about starting businesses. These things matter to him, so I expect he'll be back sooner or later.
No country is perfect. I don't think it's so bad to want to move to a place where life is more like you want it to be.
As an American living in Europe, I don't think that the problem is "drunks". By American standards, almost everyone in Europe is an alcoholic, yet no other country has the the same kind of savage violence that the UK sees. Scandinavian countries have hard-core binge drinkers, and both Germany and Ireland have a higher per-capita beer consumption.
Clearly the problem is cultural. It seems to me that a reasonable approach might be to try to change the culture to be a bit more like places where you don't have to be scared of looking people in the eye lest it start a fight, or where the police don't show up in riot vans every weekend to control the carnage.
But, like almost everyone, the Brits love their culture, and are loathe to change even the ugly bits. So, instead they get cameras and fingerprint readers. It might work, but I'm still going be very, very careful in pubs there...
The thing is; it's a pretty big ADSL supplier in Holland and he's not the only one in this situation.
I live in Holland and have a pretty large choice of ADSL providers, or I can get broadband from the cable company. In a pinch, use one of the 3 or 4 open wireless in the neighborhood.
If by "Holland" you actually mean "the Netherlands" then perhaps you are right and he only has one option, if he's in Gelderland or Friesland or some other barely civilized area.;)
Slashdot Mirror
Low Slashdot-ID? That whippersnapper? Kids today!
My experiences with Alphas were universally bad. The Unix they ran was a flaky bitch, and in any given cluster you were guaranteed to have a few of the machine go during a long computation. Then again, they were expensive.
They were quite zippy though.
As long as DNS root servers are unsigned, how can the regular DNS servers start to implement that? Sweden and Puerto Rico???
In the ideal world, to verify that a DNS answer is correct, you start the chain of trust at the root, then follow to a top-level domain (TLD), and continue on down the tree until you get to your final answer.
If at any point a zone does not have a DS record pointing to it, then the chain of trust is broken, and the ultimate answer will be unsecured. But this follows the usual DNS hierarchy... if your parent provides DNSSEC, then you have the option to secure your zone.
But since the root is not signed, you cannot start the chain of trust at the root. A resolver needs to have the public key configured for each of the zones that it knows are secured... these zones are called "trust anchors".
The problem with this is that there are hundreds of zones in the root. Finding the public key for each zone is a very heavy administrative task, as is getting new keys when the old ones expire. Going further down in the tree makes things even worse.
One proposed solution, designed as a temporary measure until the root is signed, is DLV. With DLV, you use normal DNSSEC, but if you don't find a trust anchor anywhere in the tree, then you look at another special tree.
So, say you were looking for "www.mydomain.example.com", and there was no trust anchor. You would then look in a DLV server for "www.mydomain.example.com", then "mydomain.example.com", then "example.com", and finally ".com". If at any point a DLV entry was found, you would follow that chain of trust.
What DLV does is basically create a "second root" just for securing DNS. It's not a good solution, but it is better than nothing. The main goal is to allow people to use DNSSEC easily while waiting for ICANN to sign the root.
<full_disclosure>
The DLV solution is being pushed by my company, ISC. We run a DLV registry, which is free for all to both publish data in and query.
</full_disclosure>
..but I do not see some sort of market here that is willing to pay the implementation/deployment of DNSSEC.
:)
As I see it, security is like insurance. It's a cost that gives you nothing... until after you've had a problem.
Maybe the costs of DNSSEC outweigh the benefits. I think that's probably true today... for lower-level domains at least. For organizations who's main job is providing DNS (like the root servers, ccTLDs, and so on) then the cost is not so high and the potential risks are great.
The costs of DNSSEC will start to decrease as the technology gets more mature. It's currently moving from bleeding-edge to cutting-edge.
But nobody (or not many people) use DNSSEC to encrypt zone transfers, and almost everybody hits a recursive nameserver run by your ISP or perhaps local to your company's network, which means that the end-user is never going to know whether the DNS query they issued returned a signed response or was forged from the authoritative DNS server.
;)
First, lets clear up some misconceptions here.
DNSSEC never encrypts transfers, whether zone transfers or other queries. One of the design decisions (documented in the 1990s) is that DNS is a public protocol. So there is no provision to hide data. DNSSEC rather allows cryptographically signed responses, so you can authenticate that the information came from the right place.
Also, the attack you describe (giving bogus data to secondaries) is exactly one of the problems DNSSEC is designed to protect against. With DNSSEC queries (NSEC or NSEC3), it is not possible to spoof queries merely by sending secondaries bad data via a zone transfer (AXFR or IXFR). Like all public key cryptography, it is not possible to sign a DNS record without the private key. The client can check to verify that replies have been signed by the holder of the private key for the zone.
Also, when people talk about using DNSSEC for zone transfers, they really mean using TSIG. Unlike NSEC or NSEC3, which uses public key, TSIG uses a shared key. In this way, it's basically a password that the primary and secondary servers agree on. It's much simpler to understand and implement than NSEC/NSEC3, because the problem is simpler.
As for your claim that nobody uses DNSSEC for zone transfers, I think this is not true. TSIG has been around for a long time, and is easy to use. Sites that host large numbers of DNS zones, either as primary or secondary, often require TSIG (or at least strongly encourage it). Also, a lot of people who run their own primary/secondary infrastructure use it between servers (this is of course easier if you control all servers for a zone).
As to what percentage of zone transfers are TSIG protected... this is an impossible number to get. So I propose the further discussion needs to be held over beers at a pub somewhere, since there is no actual data.
I use OpenOffice, mostly under Linux, so I see where you're coming from. But, honestly, the laziness that you are implying is just too fucking much.
The first hit after googling for "windows pdf" is PDFCreator, a GPL program that lets you make PDFs from any Windows program.
Sorry that you weren't willing to spend 60 seconds on this... you must be really, really, REALLY busy. Too busy to read this comment, of course!
You can see the list of sites for F here:
http://www.isc.org/index.pl?/ops/f-root/sites.php
That's about 40 locations. Now, each of which has a couple of servers, a management box, and a couple of routers, so yeah something like 200 machines total.
I know you were joking, but actually removing inline functions can make the kernel faster in some cases, and the effect on kernel size is dramatic:
:)
http://lwn.net/Articles/82495/
http://lwn.net/Articles/166172/
And let me say, LWN kicks ass.
I second this comment.
I've never had good IT support for software, except from MySQL. It was still a bit painful to get to the engineer who could actually make the code changes to fix the problems, but it did happen, and the problems were fixed.
if Linux is going to become a viable alternative for the girlfriend
Dude, don't get me wrong, I think Linux is sexy. But not that sexy.
It is similar to what happens in countries like the Netherlands (or other nordic countries) where people *avoid* pay rises because sometimes having a rise of 10% they have to pay more taxes and end earning less than what they earned before the "raise".
In the 6 years that I've been in the Netherlands (3 as a manager), I've never known anyone to turn down a pay raise. (If you know such people, please let me know... we might want to hire them.) The system does not work as you describe. Making more money always gives you more money.
There may be other reasons to worry about a high income, such as being forced to leave rent controlled housing, but this is not tax related.
I think what drinkypoo is trying to say is simply that there is no right to make money at any particular activity.
:)
There are tons of professions and industries that have disappeared or been relegated to fringe activities... coopers, glassblowers, phrenologists, jesters, scribes; the list goes on and on and on.
Would society really be better off if we were required to use wooden barrels crafted by masters to store liquids?
Should psychologists be required to have a professional read the bumps on someone's head before making a diagnosis?
Perhaps we should all pay a "scribe tax" on every photocopy we make?
The point is, times change, and sometimes professions and entire industries just become... obsolete. It sucks for people who earn their living that way, or who have a romantic attachment (think of the mystique around "the age of sail"), but overall it's okay. Life goes on. People find new ways to live, and new ways to express themselves and interact with each other.
Digital media and the Internet may have made big production movies and TV and platinum albums a thing of the past. A pity if you like Cecil B. Demille, not such a shame if you like live jazz.
Buried deep down in TFA (okay, in the first paragraph):
By improving our analysis of the link structure of the web, Google has begun minimizing the impact of many Googlebombs. Now we will typically return commentary, discussions, and articles about the Googlebombs instead.
So, yes, it worked.
In Greg Bear's book Eon, one of the ideas is building with geometry. A mathematician investigating one such structure asked some engineers to build a pi-meter to use when she was exploring. I wondered what such a thing could mean, and indeed how one would build such a device...
Mysql has a GPL/Commercial dual licensing model. And because connection to mysql means linking to the client, which is "derivative work" in terms of the GPL, you can only use GPL'ed software with mysql. Unless you pay them to use their commercial license of course.
- exception.html
Well, that's GPL. You appear to be arguing that GPL is only "semi-free" (your own words).
But if you don't like GPL, MySQL allows you to use any of the following licenses with clients:
http://www.mysql.com/company/legal/licensing/foss
Not to mention the semi-free open-source license of mysql.
GPL?
It sounds like you just don't know how to deal with FreeBSD. That would explain the poor performance you experienced, and how it is completely contrary to what we've found.
For the heavest application at my last job, the load pattern was very query heavy, although the application stored intermediate results in temporary tables. This application is heavily threaded, creating two threads per user connection, plus the MySQL thread, so we're talking like 150 threads created & destroyed per second.
Our original platform was Solaris, and performance was excellent (well, excellent considering the dog-slow CPUs that Sun makes).
We eventually migrated to Linux, but this was possible only after the new thread libraries (well, new at the time). Performance then was quite good.
We found MySQL under FreeBSD basically unusable under heavy loads.
We never tweaked any of the systems. We did try a few thread libraries under FreeBSD, but they all sucked.
"the tubes" in London
I assure you cannot pay for a ticket on the Tube with a $20 bill.
Hemingway's story's in the first sentence.
I moved away, just to live abroad for a bit.
But after a few years I realised that my worldview is more similar to the country I live in (the Netherlands) than the country I'm from (the USA).
Why should I try to convince 300 million Americans to have the life that I enjoy, when I have found 16 million people who already do? Americans like their country the way it is.
Holland is crowded, expensive, and the weather sucks. But it's got way more actual freedom than the US, there is almost no poverty, violence is low, and people care way more about enjoying life than working. It works for me.
One of my friends just returned from the USA, and he misses it. He misses his cars, the hundreds of channels on the TV, the cheap food with good service. He misses being able to pay money to have his problems go away. He misses people who are excited about starting businesses. These things matter to him, so I expect he'll be back sooner or later.
No country is perfect. I don't think it's so bad to want to move to a place where life is more like you want it to be.
A lot of experienced programmers do that too.
As an American living in Europe, I don't think that the problem is "drunks". By American standards, almost everyone in Europe is an alcoholic, yet no other country has the the same kind of savage violence that the UK sees. Scandinavian countries have hard-core binge drinkers, and both Germany and Ireland have a higher per-capita beer consumption.
Clearly the problem is cultural. It seems to me that a reasonable approach might be to try to change the culture to be a bit more like places where you don't have to be scared of looking people in the eye lest it start a fight, or where the police don't show up in riot vans every weekend to control the carnage.
But, like almost everyone, the Brits love their culture, and are loathe to change even the ugly bits. So, instead they get cameras and fingerprint readers. It might work, but I'm still going be very, very careful in pubs there...
So you're a Nethack developer then?
I have an iPod, and can't utilize iTunes.
But then, I run Linux. As far as I can tell, Apple's attitude towards Linux is "thinly veiled hostility".
The thing is; it's a pretty big ADSL supplier in Holland and he's not the only one in this situation.
;)
I live in Holland and have a pretty large choice of ADSL providers, or I can get broadband from the cable company. In a pinch, use one of the 3 or 4 open wireless in the neighborhood.
If by "Holland" you actually mean "the Netherlands" then perhaps you are right and he only has one option, if he's in Gelderland or Friesland or some other barely civilized area.