No, we send them to secret torture prisons to avoid US laws and throw out habeas corpus and the Geneva Convention on a new made-up class of people, "enemy non-combatants".
Hey, I'll be employed as the "last guy in the country who actually knows how the silly thing really works". I make a fairly decent living showing youngsters how to really make it work, and the foreign high-tech people are often easier to impress: they're not used to disbelieving what the textbook said.
Someone who can afford it? At that corporate level, he's certainly pulling down several hundred thousand dollars a year, especially including stock options.
No, I'm afraid it's nuts. A minor ruling by a local court would then outweigh the ability of the US Supreme Court to rule on the constitutionality of a law itself. The ability to appeal is vital to prevent a badly handled first trial from ruining a person's life, or destroying an otherwise fine institution. And the court hierarchies exist for a reason.
Mind you, they're badly abused by people who spend their way out of suffering consequences for crimes. But I don't want to see some corrupt judge running for re-election rule without any check on their authority when the government is involved.
Well, if you admit that there was also a much larger chance of being lynched, being murdered for escaping slavery, that beating or raping your wife was legal, that you could sell your children into bondage, and that debtors rotted to death in Newgate Prison, that children were branded, etc., then I guess you have a point.
You also couldn't compile the Sun Java: the RPM installers, for example, were simply wrappers and the binary blobs from Sun. Didn't we have that argument about the NVidia and other binary blob installers?
Now go look at the SRPM for those jpackage releases. It's fairly nasty to build, and the SRPM's hide a lot of the nastiness. The naming and numbering schemes alone for the different versons of JDK, I mean SDK, I mean "whatever the heck it's called this week" is extremely painful and leads to serious issues with systems that requie two distinct versions of Java for different applications.
You can work around this with wrappers, but the Sun installation practices make the whole deal pretty painful to deal with.
Think again. Do your own research on the wholesale theft of VMS technologies for NT, and of the Microsoft Mouse as classic examples. Those were well justified lawsuits: while Microsoft might have used their patents defensively in those cases, it's ore like a car thief wearing a bullet proof vest in case they get caught.
Then try attending a meeting with a hardware manufacturer with Microsoft lawyers in the room, who "explain" the risks of using non-Microsoft operating systems, and the risk of IP lawsu8its. It's much like having two large gentlemen explaining what a good idea it would be for your shop to use only union labor, and how unfortunate that warehouse fire a few weeks ago across town was, and how they're quite sure it would never have occurred with union electricians. It's quite frightening to watch, and matches Steve Ballmers documented claims without proof of Linux kernel violations of Microsoft intellectual property. It's nasty, it's real, and it's quite difficult to get proof of that will stand up in court.
It's been going on in the fileserver world for years, especially for small storage appliances (who've faced enormous pressure to use WindowsCE instead of Linux for those little boxes) and particularly against Samba developers. It's also deeply intertwined in the Novell/Microsoft deal.
I agree with you that many companies use the patent, and its related cousin the software copyright sytem, to armor themselves against accusations. But you're making an unwarranted assumption that the patents involved are "meaningless". If you go to a non-disclusure-agreement covered meeting with Microsoft, you had better make sure you don't actually mention any technologies they'd prefer to sell themselves, because they do steal, and they've been caught at it.
For what you describe, I'd use a remote console, not an auto-restart. But as long as the notification is included, I can see where a restart is reasonable. But if that auto-restart simply grunds the spilled entrails of the failed service deeper into the system, I'm extremely unhappy with such assertive auto-restart sytems as Mr. Bernstein's daemontools.
It depends on the service and the response time. If a daemon like SSHD fails, for example, I want to know why it happened before I restart that daemon. Same for MySQL or Postgres: I want to know what slapped them down before I restart that service, because restarting it may corrupt data even worse. Similarly, for DNS, I want changes to show up for new clients when I tell it to reload, not when the next client connects.
For some lightweight or only occasionally necessry processes with other built-in redundancies and fallback states, such as SMTP, it can make more sense to have them inetd managed. But then you can use xinetd for most of those, which Dan apparently dislikes.
The PDF is very interesting. I agree with many of its hard-won lessons. But like Linus Pauling becoming hung up on vitamin C, Dan's obsessions interfere with using his other work.
I usually prefer to let it stay failed until an admin can find what broke it, especially with a good quality monitoring system in place. But that particular behavior of Dan's is not one I fault him for.
Now, *that* is an interesting cite. But I suspect that he's going to redefine "public domain" the same way he seems to define "security hole", by limiting it so severely that it's not what other people mean by it.
Have you looked carefully at that documentation? Without actually spending hours reading the source code, and deducing its layout, it's hopeless because it's either too casual, or at too deep a level that's simply not useful to installers. Worse, it's in an odd enough "man" format that it spews ""Esc" all over its output without serious re-editing, which is prevented by Dan's unique licensing model. To quote:
You may distribute a precompiled package if installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above;
Ooops! Repairing the man pages is forbidden for compiled binaries! Frankly, I don't count that mess as documentation. Would you?
Second, while his web page on his licensing is clear, the implications are not, and it's not in the tarball. Oops! Once again, you have to go searching for how to fix it, and can't distribute a patch inside the tarball. And you say it's in the public domain? Read the PDF again. The PDF is public domain, Qmail most certainly is not.
Last, you have a point about/var/qmail/bin and/var/qmail/spool. But the Linux and UNIX filesystem hierarchies clearly state that the binaries should be over in/usr./usr/lib/qmail would be appropriate for these, but once again, Dan's precious and unique licensing interferes.
It's *possible* to refuse it in the first place, and better to refuse it earlier in the process, I agree. (That's part of why I like classic SPF: break the connection when they forge the sending address, even before they get to the recipient's email address.) I thought you were suggesting that the MTA drop the message, rather than bouncing it, and I've seen that sort of policy done. I take it that dropping it on the floor is not what you meant?
And yes, Barracudas are their own bit of fun to administer.
And refuses to document it. Don't forget that DJB's infamous "LOC" or lines of code tends to leave out things like documentation, configuration examples, software installers that put things in the right places, or his other bugaboo, "parsers" to pre-test the configuration files and make sure they're valid.
Also note: bouncing undeliverable email is part of the specification for SMTP, because mis-addressed or randomly guessed email is indistinguishable from temporarily undeliverable email. If you don't bounce it, the sender (who may be legitimate!) has no way to know it hasn't arrived. Dropping it on the floor becomes a real problem.
What you've described as an open relay really isn't: it's a "Joe Job", a forgery pretending to be from somewhere else, exactly what SPF was designed to block. Now, *throttling* such connections seems completely reasonable, but as someone who's run SMTP servers, I submit to you that discarding the messages silently is not.
And if you don't bother to install an HTTP daemon, then I get to take it away from you and you have to break mine to get your port back. That's too awkward to manage.
Oh, that's "outside the scope" of the Qmail security, just like what chunk of the filesystem software lives on is "outside the scope" of any of Dan Bernstein's packages. By focusing on a particular, small, tractable problem, and then stomping on everyone else's conventions, he makes very "secure" packages that leave the other problems "to the reader".
Bernstein doesn't want to play there, and doesn't allow repackaging, so he will never have to.
Slashdot Mirror
No, we send them to secret torture prisons to avoid US laws and throw out habeas corpus and the Geneva Convention on a new made-up class of people, "enemy non-combatants".
The comparison has a sound basis.
There was Lincoln, for getting us into a civil war by refusing to let the Southern states secede as was their constitutional right.
Hey, I'll be employed as the "last guy in the country who actually knows how the silly thing really works". I make a fairly decent living showing youngsters how to really make it work, and the foreign high-tech people are often easier to impress: they're not used to disbelieving what the textbook said.
For a network probing tool or a debugging workstation, it's ideal in a whole lot of ways.
Someone who can afford it? At that corporate level, he's certainly pulling down several hundred thousand dollars a year, especially including stock options.
Got caught putting Superglue on Ballmer's chair to keep him from throwing it?
Got convicted of stealing office supplies for turning off Clippy?
Got caught actually following an ISO without commoditizing it?
Got caught following an NDA instead of stealing the ideas for pre-release by Microsoft before their partner?
We could go on all day on this one.
No, I'm afraid it's nuts. A minor ruling by a local court would then outweigh the ability of the US Supreme Court to rule on the constitutionality of a law itself. The ability to appeal is vital to prevent a badly handled first trial from ruining a person's life, or destroying an otherwise fine institution. And the court hierarchies exist for a reason.
Mind you, they're badly abused by people who spend their way out of suffering consequences for crimes. But I don't want to see some corrupt judge running for re-election rule without any check on their authority when the government is involved.
Well, if you admit that there was also a much larger chance of being lynched, being murdered for escaping slavery, that beating or raping your wife was legal, that you could sell your children into bondage, and that debtors rotted to death in Newgate Prison, that children were branded, etc., then I guess you have a point.
Let's not romanticize the justice of the time.
Could I hire you to rewrite the US tax code?
You also couldn't compile the Sun Java: the RPM installers, for example, were simply wrappers and the binary blobs from Sun. Didn't we have that argument about the NVidia and other binary blob installers?
Oh my stars and garters. Editing bashrc directly is begging to break other apps. These modifications should be in /etc/profile.d/jre-[version].sh
That sort of abuse of the system default settings is another reason I detest the Sun installers.
Now go look at the SRPM for those jpackage releases. It's fairly nasty to build, and the SRPM's hide a lot of the nastiness. The naming and numbering schemes alone for the different versons of JDK, I mean SDK, I mean "whatever the heck it's called this week" is extremely painful and leads to serious issues with systems that requie two distinct versions of Java for different applications.
You can work around this with wrappers, but the Sun installation practices make the whole deal pretty painful to deal with.
Think again. Do your own research on the wholesale theft of VMS technologies for NT, and of the Microsoft Mouse as classic examples. Those were well justified lawsuits: while Microsoft might have used their patents defensively in those cases, it's ore like a car thief wearing a bullet proof vest in case they get caught.
Then try attending a meeting with a hardware manufacturer with Microsoft lawyers in the room, who "explain" the risks of using non-Microsoft operating systems, and the risk of IP lawsu8its. It's much like having two large gentlemen explaining what a good idea it would be for your shop to use only union labor, and how unfortunate that warehouse fire a few weeks ago across town was, and how they're quite sure it would never have occurred with union electricians. It's quite frightening to watch, and matches Steve Ballmers documented claims without proof of Linux kernel violations of Microsoft intellectual property. It's nasty, it's real, and it's quite difficult to get proof of that will stand up in court.
It's been going on in the fileserver world for years, especially for small storage appliances (who've faced enormous pressure to use WindowsCE instead of Linux for those little boxes) and particularly against Samba developers. It's also deeply intertwined in the Novell/Microsoft deal.
I agree with you that many companies use the patent, and its related cousin the software copyright sytem, to armor themselves against accusations. But you're making an unwarranted assumption that the patents involved are "meaningless". If you go to a non-disclusure-agreement covered meeting with Microsoft, you had better make sure you don't actually mention any technologies they'd prefer to sell themselves, because they do steal, and they've been caught at it.
For what you describe, I'd use a remote console, not an auto-restart. But as long as the notification is included, I can see where a restart is reasonable. But if that auto-restart simply grunds the spilled entrails of the failed service deeper into the system, I'm extremely unhappy with such assertive auto-restart sytems as Mr. Bernstein's daemontools.
It depends on the service and the response time. If a daemon like SSHD fails, for example, I want to know why it happened before I restart that daemon. Same for MySQL or Postgres: I want to know what slapped them down before I restart that service, because restarting it may corrupt data even worse. Similarly, for DNS, I want changes to show up for new clients when I tell it to reload, not when the next client connects.
For some lightweight or only occasionally necessry processes with other built-in redundancies and fallback states, such as SMTP, it can make more sense to have them inetd managed. But then you can use xinetd for most of those, which Dan apparently dislikes.
The PDF is very interesting. I agree with many of its hard-won lessons. But like Linus Pauling becoming hung up on vitamin C, Dan's obsessions interfere with using his other work.
I usually prefer to let it stay failed until an admin can find what broke it, especially with a good quality monitoring system in place. But that particular behavior of Dan's is not one I fault him for.
Now, *that* is an interesting cite. But I suspect that he's going to redefine "public domain" the same way he seems to define "security hole", by limiting it so severely that it's not what other people mean by it.
Have you looked carefully at that documentation? Without actually spending hours reading the source code, and deducing its layout, it's hopeless because it's either too casual, or at too deep a level that's simply not useful to installers. Worse, it's in an odd enough "man" format that it spews ""Esc" all over its output without serious re-editing, which is prevented by Dan's unique licensing model. To quote:
/var/qmail/bin and /var/qmail/spool. But the Linux and UNIX filesystem hierarchies clearly state that the binaries should be over in /usr. /usr/lib/qmail would be appropriate for these, but once again, Dan's precious and unique licensing interferes.
You may distribute a precompiled package if installing your package produces exactly the same files, in exactly the same locations, that a user would obtain by installing one of my packages listed above;
Ooops! Repairing the man pages is forbidden for compiled binaries! Frankly, I don't count that mess as documentation. Would you?
Second, while his web page on his licensing is clear, the implications are not, and it's not in the tarball. Oops! Once again, you have to go searching for how to fix it, and can't distribute a patch inside the tarball. And you say it's in the public domain? Read the PDF again. The PDF is public domain, Qmail most certainly is not.
Last, you have a point about
It's *possible* to refuse it in the first place, and better to refuse it earlier in the process, I agree. (That's part of why I like classic SPF: break the connection when they forge the sending address, even before they get to the recipient's email address.) I thought you were suggesting that the MTA drop the message, rather than bouncing it, and I've seen that sort of policy done. I take it that dropping it on the floor is not what you meant?
And yes, Barracudas are their own bit of fun to administer.
And refuses to document it. Don't forget that DJB's infamous "LOC" or lines of code tends to leave out things like documentation, configuration examples, software installers that put things in the right places, or his other bugaboo, "parsers" to pre-test the configuration files and make sure they're valid.
Also note: bouncing undeliverable email is part of the specification for SMTP, because mis-addressed or randomly guessed email is indistinguishable from temporarily undeliverable email. If you don't bounce it, the sender (who may be legitimate!) has no way to know it hasn't arrived. Dropping it on the floor becomes a real problem.
What you've described as an open relay really isn't: it's a "Joe Job", a forgery pretending to be from somewhere else, exactly what SPF was designed to block. Now, *throttling* such connections seems completely reasonable, but as someone who's run SMTP servers, I submit to you that discarding the messages silently is not.
And if you don't bother to install an HTTP daemon, then I get to take it away from you and you have to break mine to get your port back. That's too awkward to manage.
Oh, that's "outside the scope" of the Qmail security, just like what chunk of the filesystem software lives on is "outside the scope" of any of Dan Bernstein's packages. By focusing on a particular, small, tractable problem, and then stomping on everyone else's conventions, he makes very "secure" packages that leave the other problems "to the reader". Bernstein doesn't want to play there, and doesn't allow repackaging, so he will never have to.
You mean they might pry the installer out of Sun's hands? Great!