If Amazon implements something like this, I'm not going to shop there out of principle.
Oh please. Every brick-and-mortar you do business with does the same thing. It's the expected norm. Don't believe me? Pick a locally-owned restaurant small enough to actually care about customer service. Go there often enough to become a regular. Notice that sometimes you get magically promoted to the front of the "waiting to be seated" list, and maybe get drink refills a little more promptly than other tables on busy nights.
Now, one could argue that you should give preferential treatment to first-time customers because the regulars obviously already like you. One could also go out of business as they see their sales being sucked away by competitors that understand human psychology.
It's stupid for Amazon to patent this, but it's just plain good business to be doing it in the first place.
It requires you to sync with a bloated media application that chokes on large media libraries and only supports DRM'd content from a single music store.
That's stupid. First, iPods work great in UMS mode. That's how we sync my wife's 4GB Nano because we didn't like the job iTunes was doing of managing it on its own. Second, I'm fine with the idea that iPods only support one kind of DRM infection. Since I'll never be using any such tainted files, might as well keep the firmware overhead to a minimum.
I actually prefer my Sansa e280, but I still think the iPods are slick little devices.
Yes, in the same way that a Honda is more functional than an F1 Ferrari. The Formula car can do things that the family sedan simply can't, but Joe Average can hop in a Honda and figure out how to use it without going through a training course. The iPod is targetted at "normal" people who haven't heard of OGGs and just want to drag-and-drop music into a playlist. Apple nailed that one solidly and their sales figures prove it.
Exhibit A: Cute, functional, the industry standard. Everyone knows what it is. Comes in gift-friendly colors. A status symbol.
Exhibit B: Volvo-esque, crippled, and ignored by accessory manufacturers. No one outside Slashdot and the Black Friday Loss Leader Bin has heard of it. Comes in brown. Also a status symbol (but of an undesirable status).
I don't like automated "helper" systems like this that can't be overridden. It's my nature to try to come up with a situation where they'll do more harm than good. My pet anti-favorite is always-on headlights on cars. I imagine a scenario where you're in the middle of nowhere and trying to get away from the bad guys before they can find you. You ease the keys into the ignition of your silent-running electric car, take a deep breath, and turn it on - only to see your lights^Wbeacons come on. The bad guys jump out and shoot you.
Safety features are great, but they must be overrideable.
If it would be only a *tiny* amount of performance difference, there would not be alot of people in the forum mentioning that they prefer Gnome over KDE cuz Gnome runs faster.
And if Mustangs were really faster than Accents, you'd never see whale tails on a neonned Hyundai.
They are red herrings. You obviously have a grudge against djb based on your posting history.
I don't know the guy, don't have anything against him, and wouldn't recognize him if he walked up and bit me. It's just that every time DNS, SMTP, or NTP comes up, a legion of DJB fanbois appears and rants at everyone who doesn't love his software. Maybe DJB is fine; I just can't stand his followers.
Well sure djbdns is not perfect for all scenarios, i never said it was
Noted and I see what you're saying.
Dynamic dns clients are not a good idea, letting your dhcp clients set arbitrary dns records is a horrible thing to do...
Why? In BIND9 you can write rules like "the client with this TSIG key can change this set of values". Saying that DDNS isn't good if left wide open is like saying that SMTP isn't good because of open relays. When done right, DDNS and SMTP can both be useful.:-)
As for having to use rsync/ssh, is that really necessary?
If you're doing pull-only, then DDNS moves from "maybe not a good idea" to "pretty much impossible". Also, even in the case of an SSL-ized HTTP server (which is a clever idea, BTW), that still means that you'd have to run an HTTP daemon on the nameserver. It's just one more thing that has to be gotten right.
I haven't used PowerDNS but it has enough fans that it must be doing something right. If we ever needed to migrate off BIND9 for some reason, that's probably where I'd look first.
Of course, djbdns could come with some special scripts to implement well-tested solutions.
Won't happen. djbdns is proprietary and hasn't been updated since 2001-02-11, so the best you can hope for is a generally agreed upon best practice.
The Windows admins I've encountered are hopeless when it comes to DNS (blaming every strange issue they encounter on DNS, for example). Best current practice over here is to never have Active Directory and public DNS interact.
We isolate the two by creating a zone for AD to screw around with. The company has example.com, and AD controls lan.example.com. Nothing "important" is inside that subdomain so if it breaks horribly we can still get work done.
In that case, djbdns would be a good solution. Are you suggesting that we switch to BIND?
No. I am suggesting that you research djbdns's criticisms, though. For starters, it's not F/OSS so expect a fair amount of installation pain and a small (although devout) pool of people who can help you with it. Furthermore, DJB tends to fancy himself an expert in areas where he has no experience, such as time synchronization and email system design (not to be confused with mail server writing). I'm not saying he's not smart, but he has a bad case of foot-in-mouth-philia.
I personally like BIND9 and use it on the servers I control, but PowerDNS and MaraDNS also get mentioned a lot when the subject comes up.
I was soliciting input from people who know what they are talking about, not from today's lets-bash-x crowd.
I don't like djbdns - I've never tried to hide that - but these are factual, documented problems and not just something I'm inventing to bash on it.
SSH supports binding a key to a command in.ssh/authorized_keys. Also supports IP matching too.
But again, you the sysadmin have to set this up correctly on every machine you touch. If you're configuring BIND9 and TSIG and screw up, then the worst case scenario is that that it's buggy or you screw it up and an attacker can fiddle with your DNS data. If you're configure djbdns + SSH, then the worst case scenario is that sshd or tcpwrappers has a bug or you screw it up and that gives attackers access to your entire host, including the DNS data.
Looks like you can get djbdns to do AXFR, too.
IXFR != AXFR. IXFR (incremental transfer) is for when you have 10,000 dynamic DNS clients making changes to your zone file, and you need to propagate those changes to your slaves in realtime. Ideally, this won't require sending the whole zone file each time or wiring a trigger to fire off rsync every time an update is made. This is used very commonly in corporate setups where DHCP gives out IPs and hostnames to clients, or at least that's how we use it in conjunction with Active Directory.
One of the problems I have is that it doesn't spin down the drives after inactivity.
I bought a My Book Premium for my wife's iMac to use as the boot drive and it works great, except that I can't get it to not spin down. Every now and then she'll ask me why her computer's not working, and I'll have to powercycle the drive (and the iMac) to get her boot partition to come back online. I just flashed a new BIOS onto it last week so maybe the problem's fixed by now.
Your concerns are valid, but how many DNS servers lack ssh access in the real world?
How many DNS servers lack SSH set up for unattended connections to remote servers, either by using password authentication, passwordless RSA keys, or ssh-agent? Hopefully all of them. Well, except for the ones running djbdns.
But going purely on vulnerabilities, we should probably all be running djbdns.
No way. djbdns doesn't even support IXFR, so instead of configuring a TSIG key for your master and slave servers and being done with it, you instead have to roll your own secure incremental filecopy implementation. Maybe you didn't want to run sshd or rsyncd on your slaves. Doesn't matter - now you have to because djbdns can't be bothered to handle it for you.
So, is djbdns more secure than BIND9 in the functionality it actually provides? Maybe. But if you want to actually use it, you have to set up a bunch of parallel systems that have much more dire failure modes, such as giving a cracker a shell login or accidentally exposing your whole filesystem to them via rsync. That, to me, makes it less secure in practice.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software. This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Actually, their wording really sucks and has a million loopholes. Note that it doesn't say "transmitted from a network server". I could say "send me a disk and I'll make you a copy of the source from our networked Subversion server. Because of their sloppiness here, all I have to do is make sure that the machine I use to store my local copy of the code is networked to another computer somewhere.
I'm talking about ISPs who take it upon themselves to filter the email to their own users based on criteria the users have no say over and probably zero knowledge of.
My favorite related personal anecdote:
My ISP acquired some new netblocks and was migrating customers into them. When they moved my/28 and I had problems, I tried to email them but it bounced: my new netblock was on a RBL that their server used to reject messages.
One quick phone call and all was resolved, but it was annoying (and amusing) for a day or two.
BTW, there are two ISPs in my city and this was the good one. My alternatives for getting "better" access consisted solely of moving to another town. My wife was less willing to consider the option than I might have been.
You seem to be overlooking the fact that your so called internal algorithms are actually derivative works.
Umm, no, they're not. I'm not talking about taking a CMS and adding a new module to it. I'm talking about using an application server to display the output of a 20-year-old internally-developed application we've written. It's no more a derived work than if running it as a GUI exported over Citrix would make it a derived work of Citrix.
Fortunately, Zope is licensed under the GPL-compatible ZPL so we don't have to deal with any of this anti-Free Software stupidity.
The spirit of the GPL was that if you modify code, you share it.
I'm sorry, but that's bullshit. The spirit of Free Software was always that if you distribute modified code, then you distribute the modifications as well. It was never about making you share undistributed modifications. The difference isn't that subtle and it's hugely important. Basically, the FSF is now saying through the AGPL that you're not free to modify software at all, even just to run internally, unless you make those changes available.
Slashdot Mirror
Oh please. Every brick-and-mortar you do business with does the same thing. It's the expected norm. Don't believe me? Pick a locally-owned restaurant small enough to actually care about customer service. Go there often enough to become a regular. Notice that sometimes you get magically promoted to the front of the "waiting to be seated" list, and maybe get drink refills a little more promptly than other tables on busy nights.
Now, one could argue that you should give preferential treatment to first-time customers because the regulars obviously already like you. One could also go out of business as they see their sales being sucked away by competitors that understand human psychology.
It's stupid for Amazon to patent this, but it's just plain good business to be doing it in the first place.
That's stupid. First, iPods work great in UMS mode. That's how we sync my wife's 4GB Nano because we didn't like the job iTunes was doing of managing it on its own. Second, I'm fine with the idea that iPods only support one kind of DRM infection. Since I'll never be using any such tainted files, might as well keep the firmware overhead to a minimum.
I actually prefer my Sansa e280, but I still think the iPods are slick little devices.
Yes, in the same way that a Honda is more functional than an F1 Ferrari. The Formula car can do things that the family sedan simply can't, but Joe Average can hop in a Honda and figure out how to use it without going through a training course. The iPod is targetted at "normal" people who haven't heard of OGGs and just want to drag-and-drop music into a playlist. Apple nailed that one solidly and their sales figures prove it.
The mice are gonna be pissed.
You may not damage the universe, but I suggest you have your vision checked regularly.
Exhibit A: Cute, functional, the industry standard. Everyone knows what it is. Comes in gift-friendly colors. A status symbol.
Exhibit B: Volvo-esque, crippled, and ignored by accessory manufacturers. No one outside Slashdot and the Black Friday Loss Leader Bin has heard of it. Comes in brown. Also a status symbol (but of an undesirable status).
Don't try to overthink it.
Any chance you can bump that up to 12MB? That'll get you OpenBSD 4.2, although it probably won't be a screamer.
Well, unless you activate it.
Planned obsolescence crap like that makes me glad I'm not on the Windows treadmill.
I don't like automated "helper" systems like this that can't be overridden. It's my nature to try to come up with a situation where they'll do more harm than good. My pet anti-favorite is always-on headlights on cars. I imagine a scenario where you're in the middle of nowhere and trying to get away from the bad guys before they can find you. You ease the keys into the ignition of your silent-running electric car, take a deep breath, and turn it on - only to see your lights^Wbeacons come on. The bad guys jump out and shoot you.
Safety features are great, but they must be overrideable.
And if Mustangs were really faster than Accents, you'd never see whale tails on a neonned Hyundai.
I don't know the guy, don't have anything against him, and wouldn't recognize him if he walked up and bit me. It's just that every time DNS, SMTP, or NTP comes up, a legion of DJB fanbois appears and rants at everyone who doesn't love his software. Maybe DJB is fine; I just can't stand his followers.
Noted and I see what you're saying.
Dynamic dns clients are not a good idea, letting your dhcp clients set arbitrary dns records is a horrible thing to do...Why? In BIND9 you can write rules like "the client with this TSIG key can change this set of values". Saying that DDNS isn't good if left wide open is like saying that SMTP isn't good because of open relays. When done right, DDNS and SMTP can both be useful. :-)
As for having to use rsync/ssh, is that really necessary?If you're doing pull-only, then DDNS moves from "maybe not a good idea" to "pretty much impossible". Also, even in the case of an SSL-ized HTTP server (which is a clever idea, BTW), that still means that you'd have to run an HTTP daemon on the nameserver. It's just one more thing that has to be gotten right.
I haven't used PowerDNS but it has enough fans that it must be doing something right. If we ever needed to migrate off BIND9 for some reason, that's probably where I'd look first.
Won't happen. djbdns is proprietary and hasn't been updated since 2001-02-11, so the best you can hope for is a generally agreed upon best practice.
The Windows admins I've encountered are hopeless when it comes to DNS (blaming every strange issue they encounter on DNS, for example). Best current practice over here is to never have Active Directory and public DNS interact.We isolate the two by creating a zone for AD to screw around with. The company has example.com, and AD controls lan.example.com. Nothing "important" is inside that subdomain so if it breaks horribly we can still get work done.
In that case, djbdns would be a good solution. Are you suggesting that we switch to BIND?No. I am suggesting that you research djbdns's criticisms, though. For starters, it's not F/OSS so expect a fair amount of installation pain and a small (although devout) pool of people who can help you with it. Furthermore, DJB tends to fancy himself an expert in areas where he has no experience, such as time synchronization and email system design (not to be confused with mail server writing). I'm not saying he's not smart, but he has a bad case of foot-in-mouth-philia.
I personally like BIND9 and use it on the servers I control, but PowerDNS and MaraDNS also get mentioned a lot when the subject comes up.
I don't like djbdns - I've never tried to hide that - but these are factual, documented problems and not just something I'm inventing to bash on it.
SSH supports binding a key to a command inBut again, you the sysadmin have to set this up correctly on every machine you touch. If you're configuring BIND9 and TSIG and screw up, then the worst case scenario is that that it's buggy or you screw it up and an attacker can fiddle with your DNS data. If you're configure djbdns + SSH, then the worst case scenario is that sshd or tcpwrappers has a bug or you screw it up and that gives attackers access to your entire host, including the DNS data.
Looks like you can get djbdns to do AXFR, too.IXFR != AXFR. IXFR (incremental transfer) is for when you have 10,000 dynamic DNS clients making changes to your zone file, and you need to propagate those changes to your slaves in realtime. Ideally, this won't require sending the whole zone file each time or wiring a trigger to fire off rsync every time an update is made. This is used very commonly in corporate setups where DHCP gives out IPs and hostnames to clients, or at least that's how we use it in conjunction with Active Directory.
I bought a My Book Premium for my wife's iMac to use as the boot drive and it works great, except that I can't get it to not spin down. Every now and then she'll ask me why her computer's not working, and I'll have to powercycle the drive (and the iMac) to get her boot partition to come back online. I just flashed a new BIOS onto it last week so maybe the problem's fixed by now.
How many DNS servers lack SSH set up for unattended connections to remote servers, either by using password authentication, passwordless RSA keys, or ssh-agent? Hopefully all of them. Well, except for the ones running djbdns.
No way. djbdns doesn't even support IXFR, so instead of configuring a TSIG key for your master and slave servers and being done with it, you instead have to roll your own secure incremental filecopy implementation. Maybe you didn't want to run sshd or rsyncd on your slaves. Doesn't matter - now you have to because djbdns can't be bothered to handle it for you.
So, is djbdns more secure than BIND9 in the functionality it actually provides? Maybe. But if you want to actually use it, you have to set up a bunch of parallel systems that have much more dire failure modes, such as giving a cracker a shell login or accidentally exposing your whole filesystem to them via rsync. That, to me, makes it less secure in practice.
Yep:
Actually, their wording really sucks and has a million loopholes. Note that it doesn't say "transmitted from a network server". I could say "send me a disk and I'll make you a copy of the source from our networked Subversion server. Because of their sloppiness here, all I have to do is make sure that the machine I use to store my local copy of the code is networked to another computer somewhere.
My favorite related personal anecdote:
My ISP acquired some new netblocks and was migrating customers into them. When they moved my /28 and I had problems, I tried to email them but it bounced: my new netblock was on a RBL that their server used to reject messages.
One quick phone call and all was resolved, but it was annoying (and amusing) for a day or two.
BTW, there are two ISPs in my city and this was the good one. My alternatives for getting "better" access consisted solely of moving to another town. My wife was less willing to consider the option than I might have been.
I will shoot the first pedantic bastard that refers to your bedtime as a kibisecond.
When was the last time you drove down a road where a single flaw in a lone molecule would render the entire 1,000 mile stretch impassible?
Umm, no, they're not. I'm not talking about taking a CMS and adding a new module to it. I'm talking about using an application server to display the output of a 20-year-old internally-developed application we've written. It's no more a derived work than if running it as a GUI exported over Citrix would make it a derived work of Citrix.
Fortunately, Zope is licensed under the GPL-compatible ZPL so we don't have to deal with any of this anti-Free Software stupidity.
Turn that around: what are the reasons for not leaving it running? If it was well-behaved, then there'd never be a reason to close it.
Good thing GCC isn't AGPL'ed then, if we're now saying that a program's output is bound by the same license as the program itself.
I'm sorry, but that's bullshit. The spirit of Free Software was always that if you distribute modified code, then you distribute the modifications as well. It was never about making you share undistributed modifications. The difference isn't that subtle and it's hugely important. Basically, the FSF is now saying through the AGPL that you're not free to modify software at all, even just to run internally, unless you make those changes available.