"what qualifications do you have in the field of software design and verification testing, PigleT?"
What does it matter to you?
As it happens, I have worked in the software testing arena - and I got out pretty fast when I realised it hinges all around the same idea, `official support (with a view to us employing idiots and making lots of money)' rather than clueful knowlege.
FWIW the company for whom I worked in the testing department "supported RH5.2+6.0", and even then they only "supported" Gnome, not KDE, for the front-end GUIs.
"Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat."
In nearly 2 years of tracking Debian unstable, I've never yet once had to ask for help in tracking a break, and have no intention of doing so yet. ~Tim
-- .|` Clouds cross the black moonlight,
"You need to make a cut at some point. For us, that's "when it's ready". "
I don't disagree with the kernel team having the same viewpoint, either.
"If someone calls support..."
I expect people to know how to debug a problem, not to fall back on such stupidity as `approved' and `tested'. That way "just reinstall it" lies, and other such crap. ~Tim
-- .|` Clouds cross the black moonlight,
"We're not using 2.4.3 because it was released way too late."
Bullshit. How the heck can a kernel be released `late'??
If it disagrees with your marketing deadlines, well that's your problem. Me, I'd prefer to sit on my chair for another week waiting for it than to have to go down the shops to buy yet another vesion.
As it is, 2.4.3 has been around since Mar 30; I don't see why one package can't get a proper testing in that amount of time.
And I'm pretty sure it won't be that long before 2.4.4 is released, either, at which point 2.4.2 will be OldHat.
" but we don't officially support anything that hasn't passed our QA."
Here real linux meets corporate idiocy in one line. ~Tim
-- .|` Clouds cross the black moonlight,
I absolutely despise this attitude. `Intersection of bash, tcsh and ksh', my arse! Learn each of them for what they're worth and then you'll have grounds to hold an opinion. Anything else is "it might not work in this shell so I won't bother". Well breathing underwater might not work either, but you're welcome to try. ~Tim
-- .|` Clouds cross the black moonlight,
You're right, but it's not only the linux arena in which software versions exist.
The whole commercial `venduh' world has thrived off it, or rather off victims' laziness, for decades now; updatability is something that comes with all software, but awareness of the need for updatability is particularly prevalent in the open-source world.
It's the "release" phenomenon that I've been harping on against for the last couple of years now; all software gets improved over time (and occasionally forked): all a distribution does is to slice specific versions of the software, compile the lot together, do some testing and say "this works".
This is why unsubstantiated talk like "RH7.0 is unstable, it's a 7-point-0 release, I'm going to avoid it" is bogus: the release is as good as any other and in terms of upgrading from there to the current bleeding edge, you've got less far to go than if you start from 6.2. ~Tim
-- .|` Clouds cross the black moonlight,
"Thake the installation procedure for instance. Sometimes it's a tarball, then an rpm, then is a
binary with an install script allways assuming a different configuration (read: distubution)"
This is why installing binary-only packages is a bad idea. Ultimately the nature of glibc and gcc is to lead the field forwards in their own sweet way. If "your" distro chops a basline saying "we shall use glibc-2.0.7 for OurDistro-6.0" then that's its problem for quantizing the evolution process. What's even more silly is producing binaries that will only work on a few such versions: specifically, I'm thinking SuSE-5.2 and 6.0, RH 6.0, 6.2 and 7.0; they all use different glibc2 versions, 2.0.7, 2.1.x, 2.2.2 (oh woops, that's Debian Unstable, never mind, it'll be 2.2.3 before you can blink). Any company producing a binary-only package "for SuSE" for, as is rather more frequently encountered, "for RH" is screwing their business model over badly because I just simply won't be able to install it - and around here, what I have installed here wins over what you might be able to provide.
Oh yeah. Now what was that about commercial distributions? What about the real linux distro? ~Tim
-- .|` Clouds cross the black moonlight,
"Making it easier to run Linux binaries on BSD systems makes it that much less likely for software vendors to produce native BSD binaries. "
And this is somehow bad? Gordon Bennet, "software vendors", can we not let them take over the linux luser-marketplace and keep the *BSDs Free instead? I *hate* this "software vendor" sponge ethic! ~Tim
-- .|` Clouds cross the black moonlight,
Well, it's not our fault if ICQ requires other things. But why not either
a) read through the list of requirements first so you're not stopping & starting to install icq?
b) use apt-get (or Debian altogether) where these dependencies will resolve themselves?
c) admit that things on Windoze also suffer from dependencies: "and then I installed OutlookExpress 98 and that didn't work either, but going to...". ~Tim
-- .|` Clouds cross the black moonlight,
"Why is this, other than a cool factor like IP over carrier pigeons, so terribly neat? "
It's so you can crack terrible puns about there being too much traffic on the 'Net, or using round-robin DNS, or having a token-ring LAN. ~Tim
-- .|` Clouds cross the black moonlight,
"The number one complaint about linux focuses on how usable, or not, it is for people who have less technical backgrounds then most slashdot readers."
Er, that is possible?;)
I'm not particularly impressed with that as a complaint. I prefer the `so go get a clue' answer infinitely more than "oooh sorry, I'll make it all so much easier for you". Grrrr!
"We need something"...
We already have rpm, RPM, and apt-get and dpkg. At least with apt, if you read the article you'd have read the bit about "stay with stable". What he didn't do was to name `testing' per se, but that's a reasonable idea anyway.
What RPM needs is the ability to grok package pools/repositories. Apt doesn't need anything, that I can see. ~Tim
-- .|` Clouds cross the black moonlight,
I think you know the answer to that. The way Deja treated the articles was as source to stick hilights to products in. "Documents", don't kid yourself.
Why doesn't someone with more Gbs than common sense just mirror the blighter when it comes back anyway? Could presumably be possible to write a suitable bot - heck, we could even have a distributed project to do it for us!
A use for Freenet, anyone? ~Tim
-- .|` Clouds cross the black moonlight,
In that case, a move to purge old buggy browsers that can't grok standards-compliant source is probably a good thing - make a clean start, that's fine by me.
Doesn't mean I can see it happening any time soon, though. People will still be idiots, but at least toughening up webmasters' jobs so they can more safely say "it's your browser's fault - you moron" is a good move. ~Tim
-- .|` Clouds cross the black moonlight,
The WWW is not about technology. The standards & specifications for HTML and XML are moving ever more forwards in backwards-compatible ways.
Ultimately, if your page is designed "for <foo> browser", don't expect me to visit it ever, I'm just not interested. I live with javascript disabled, and quite often disable pictures as well. Reason? I quite often surf from a PDA over a mobile link at 1K/s and don't want extra junk. If your site doesn't look good on that, it's crap.
But more to the point, the HTML standard bends over backwards to be portable and backwards-compatible. Really. The rules are simple:
a) write compliant HTML and anything else is a browser's fault
b) write a browser to parse as much as it can, not mix tags in with content, and discard everything else
and you can't go wrong.
As soon as you start catering for browser-specific behaviour, you're being a fuckhead who should really stop polluting the Web altogether. ~Tim
-- .|` Clouds cross the black moonlight,
"No ISP should be displaying obviously morally-wrong material."
For whose values of "morally wrong"? And what values of "displaying"?
Has nobody realised yet that usenet doesn't work by what the servers do, but by what people post to them?
"(I could be wrong, there could be people who believe it is not wrong). "
I'm prepared to consider that it might not be. I don't know about `believe', that's my opinion and I reserve the right for it to differ. But it needs an occasional return to brass tacks to ask why kiddie-pr0n *is* wrong. And why it's illegal, and whether "wrong" & "illegal" are related in some way.
"ISPs who ban child pornography should be commended for fighting against obvious morally-wrong materials."
I think you'll find the vast majority do explicitly ban just about everything interesting you could ever want to do, in their T&Cs. And that's where this sort of thing should be left, between the user & the ISP.
I don't see how an ISP can be held liable for content. If you don't *like* content, that's your bad look-out. If you have a sociological problem, deal with it sociologically, don't sit there making up silly rules and having potentially devastating precedent-setting cases with all the force of the law behind it. ~Tim
-- .|` Clouds cross the black moonlight,
"Write and link your application and pay attention to the very few caveats revealed by the GNU glibc team, and your app will run well on many different versions of glibc. Ignore the prophecies of the GNU glibc team, and you may be assured that your app will go down in flames. "
Yep, agreed there. Or alternatively, "just compile it statically". I'd love to see what gzexe would make of soffice.bin if that were done;) ~Tim
-- .|` Clouds cross the black moonlight,
"The problem that Linux Distributions are so different is another. But that's not glibc's fault."
Quite so.
So what if I have a better version of glibc as provided by debian unstable than yours provided by RH7.0? That's not an issue in the slightest, you can always upgrade, I can do so easier...;)
The "problem" arises when you expect to compile something "for linux" without releasing any source. In that case you have to support every distro, every version of kernel, every version of every dependent library... but that's your choice for being binary-only.
Me, if it can't come from `apt-get -b source foo' then it doesn't get installed. ~Tim
-- .|` Clouds cross the black moonlight,
1) If you didn't want people to hack on the code, why did you initially release it under a license that allowed that? It can't be retroactively retracted, y'know...
2) The OpenSSH team doesn't need your approval; you in effect gave them your approval when you licensed it as you did (see 1). </i>
Here here! Exactly what I was thinking of saying, couldn't agree more.
Me, I don't see why there should be any confusion regarding `SSH' and `OpenSSH': I spell them differently, what more could you ask for?
As far as the commandname goes, it implements a secure shell - so `ssh' is a perfectly reasonable abbreviation, to me.
If you don't go round putting `(R)' after everything, you won't have a trademark problem. And while I'm passing by that, what was that I saw about "pending"? Get a trademark properly registered, *then* come moaning, or better still, do neither.
To me, Tatu's mail sounds like he's regretting the fact that openssh is moving ahead faster and with better publicity than the commercial one. Well, that's what you get for expecting to make money in the wrong arena, tough cheese.
Me, I've just installed a new RH6.2 box to be colocated in the next couple of days, and for remote access, I've put openssh on it. The non-free sshd quite simply doesn't get a look in, the license is too confusing. ~Tim
-- .|` Clouds cross the black moonlight,
Despite this story's spiel to the contrary, experience is definitely proportional to age (well, given a linear offset).
It's just that the constant of proportionality varies from person to person - you could call it "how fast you learn" which would be fairly accurate; the problems arise from applying the same constant to multiple people.
Sure, there are 20-yo sysadmins out & about, I don't doubt it. I'm not that much older, myself. But I do look back to the days when I first read O'Reilly `Essential Unix System Administration' and had some admiration for the old beardies, not arrogance, nor a rebellious feeling that the world owed me one, but rather an "I want to do something like that" with mucho respect.
First you have to experience what it's like to be unsubscribe@, webmaster@, root@, postmaster@, and to receive multitudinous "you wanker! you're going in ORBS, the DUL, the RBL, you asshole!" complaints, then you have the beginnings of experience. Then you get on with something constructive like building a VLAN between 4 sites, rolling firewalls, kernel and software updates across dozens of servers, and you're beginning to be in the right playground. ~Tim
-- .|` Clouds cross the black moonlight,
"Surely the problem is not with HTML or Javascript in emails at all - its more to do with the fact that email browsers have a poor (if any) security model."
Surely the problem is with your "neighbour" who can forward anything he likes to whosoever he likes, not with the "technology" at all?
This is what GPG is about: you have a trust model that you can use to pin folks down more responsibly to what they send where, and when you no longer trust someone as much as before, you have the means to say so - making the incentive for them not to do nasty things to your private mails. In that regard, this is nothing new - pass on, nothing to see here. ~Tim
-- .|` Clouds cross the black moonlight,
" Do you realize that kinetic energy is
proportional to the *square* of speed?"
Square of the velocity, actually. Direction is an important consideration. And you need to demonstrate that KE is the important relevant factor in an accident rather than, for example, change in momentum over surface area of impact. ~Tim
-- .|` Clouds cross the black moonlight,
"Having bind run as a non-priviledged user would have greatly minimized the security
breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design. "
So why not stick `-u named' on the end of the command?
Chrooting *is* a jolly good idea for all daemons you're going to be running. But bear in mind that you can break out of a chroot jail, even easier still if you're running as root within it. (I've not read so much about it, but look into shared library requirements and that sort of thing.)
Also remember that prior to 2.2.16, any process calling setuid() could return to being running as root by breaking capabilities, anyway.
Slashdot Mirror
"what qualifications do you have in the field of software design and verification testing, PigleT?"
.|` Clouds cross the black moonlight,
What does it matter to you?
As it happens, I have worked in the software testing arena - and I got out pretty fast when I realised it hinges all around the same idea, `official support (with a view to us employing idiots and making lots of money)' rather than clueful knowlege.
FWIW the company for whom I worked in the testing department "supported RH5.2+6.0", and even then they only "supported" Gnome, not KDE, for the front-end GUIs.
"Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat."
In nearly 2 years of tracking Debian unstable, I've never yet once had to ask for help in tracking a break, and have no intention of doing so yet.
~Tim
--
"You need to make a cut at some point. For us, that's "when it's ready". "
.|` Clouds cross the black moonlight,
I don't disagree with the kernel team having the same viewpoint, either.
"If someone calls support..."
I expect people to know how to debug a problem, not to fall back on such stupidity as `approved' and `tested'. That way "just reinstall it" lies, and other such crap.
~Tim
--
"We're not using 2.4.3 because it was released way too late."
.|` Clouds cross the black moonlight,
Bullshit. How the heck can a kernel be released `late'??
If it disagrees with your marketing deadlines, well that's your problem. Me, I'd prefer to sit on my chair for another week waiting for it than to have to go down the shops to buy yet another vesion.
As it is, 2.4.3 has been around since Mar 30; I don't see why one package can't get a proper testing in that amount of time.
And I'm pretty sure it won't be that long before 2.4.4 is released, either, at which point 2.4.2 will be OldHat.
" but we don't officially support anything that hasn't passed our QA."
Here real linux meets corporate idiocy in one line.
~Tim
--
I absolutely despise this attitude. `Intersection of bash, tcsh and ksh', my arse! Learn each of them for what they're worth and then you'll have grounds to hold an opinion. Anything else is "it might not work in this shell so I won't bother". Well breathing underwater might not work either, but you're welcome to try.
.|` Clouds cross the black moonlight,
~Tim
--
You're right, but it's not only the linux arena in which software versions exist.
.|` Clouds cross the black moonlight,
The whole commercial `venduh' world has thrived off it, or rather off victims' laziness, for decades now; updatability is something that comes with all software, but awareness of the need for updatability is particularly prevalent in the open-source world.
It's the "release" phenomenon that I've been harping on against for the last couple of years now; all software gets improved over time (and occasionally forked): all a distribution does is to slice specific versions of the software, compile the lot together, do some testing and say "this works".
This is why unsubstantiated talk like "RH7.0 is unstable, it's a 7-point-0 release, I'm going to avoid it" is bogus: the release is as good as any other and in terms of upgrading from there to the current bleeding edge, you've got less far to go than if you start from 6.2.
~Tim
--
"Thake the installation procedure for instance. Sometimes it's a tarball, then an rpm, then is a
.|` Clouds cross the black moonlight,
binary with an install script allways assuming a different configuration (read: distubution)"
This is why installing binary-only packages is a bad idea. Ultimately the nature of glibc and gcc is to lead the field forwards in their own sweet way. If "your" distro chops a basline saying "we shall use glibc-2.0.7 for OurDistro-6.0" then that's its problem for quantizing the evolution process. What's even more silly is producing binaries that will only work on a few such versions: specifically, I'm thinking SuSE-5.2 and 6.0, RH 6.0, 6.2 and 7.0; they all use different glibc2 versions, 2.0.7, 2.1.x, 2.2.2 (oh woops, that's Debian Unstable, never mind, it'll be 2.2.3 before you can blink). Any company producing a binary-only package "for SuSE" for, as is rather more frequently encountered, "for RH" is screwing their business model over badly because I just simply won't be able to install it - and around here, what I have installed here wins over what you might be able to provide.
Oh yeah. Now what was that about commercial distributions? What about the real linux distro?
~Tim
--
"Honestly, what is Jamie expecting? That the police will say, "Oh, a Perl error! We'll shred all the files and pretend this never happened?"
.|` Clouds cross the black moonlight,
How about `oh, it was a quote without attribution, fine'?
D'UH!!!
What the FUCK is wrong with talk about shotguns? Blimey. Some people are just too sensitive.
Remember: any society that can't cope with arbitrary choices of content has problems.
~Tim
--
"Making it easier to run Linux binaries on BSD systems makes it that much less likely for software vendors to produce native BSD binaries. "
.|` Clouds cross the black moonlight,
And this is somehow bad? Gordon Bennet, "software vendors", can we not let them take over the linux luser-marketplace and keep the *BSDs Free instead? I *hate* this "software vendor" sponge ethic!
~Tim
--
Agreed.
.|` Clouds cross the black moonlight,
The TRCM was the first website I ever visited in 1993. Using Mosaic. In Edinburgh.
That was fun.
~Tim
--
Well, it's not our fault if ICQ requires other things. But why not either
.|` Clouds cross the black moonlight,
a) read through the list of requirements first so you're not stopping & starting to install icq?
b) use apt-get (or Debian altogether) where these dependencies will resolve themselves?
c) admit that things on Windoze also suffer from dependencies: "and then I installed OutlookExpress 98 and that didn't work either, but going to...".
~Tim
--
"Why is this, other than a cool factor like IP over carrier pigeons, so terribly neat? "
.|` Clouds cross the black moonlight,
It's so you can crack terrible puns about there being too much traffic on the 'Net, or using round-robin DNS, or having a token-ring LAN.
~Tim
--
You seem to think installing stuff on Windoze is easy? Ever tried Oracle, or debugging various different versions of MSSQL & ODBC drivers?
.|` Clouds cross the black moonlight,
Real software takes a while to install. The trouble is with people who expect otherwise.
~Tim
--
"The number one complaint about linux focuses on how usable, or not, it is for people who have less technical backgrounds then most slashdot readers."
;)
.|` Clouds cross the black moonlight,
Er, that is possible?
I'm not particularly impressed with that as a complaint. I prefer the `so go get a clue' answer infinitely more than "oooh sorry, I'll make it all so much easier for you". Grrrr!
"We need something"...
We already have rpm, RPM, and apt-get and dpkg. At least with apt, if you read the article you'd have read the bit about "stay with stable". What he didn't do was to name `testing' per se, but that's a reasonable idea anyway.
What RPM needs is the ability to grok package pools/repositories. Apt doesn't need anything, that I can see.
~Tim
--
I think you know the answer to that. The way Deja treated the articles was as source to stick hilights to products in. "Documents", don't kid yourself.
.|` Clouds cross the black moonlight,
Why doesn't someone with more Gbs than common sense just mirror the blighter when it comes back anyway? Could presumably be possible to write a suitable bot - heck, we could even have a distributed project to do it for us!
A use for Freenet, anyone?
~Tim
--
In that case, a move to purge old buggy browsers that can't grok standards-compliant source is probably a good thing - make a clean start, that's fine by me.
.|` Clouds cross the black moonlight,
Doesn't mean I can see it happening any time soon, though. People will still be idiots, but at least toughening up webmasters' jobs so they can more safely say "it's your browser's fault - you moron" is a good move.
~Tim
--
The WWW is not about technology. The standards & specifications for HTML and XML are moving ever more forwards in backwards-compatible ways.
.|` Clouds cross the black moonlight,
Ultimately, if your page is designed "for <foo> browser", don't expect me to visit it ever, I'm just not interested. I live with javascript disabled, and quite often disable pictures as well. Reason? I quite often surf from a PDA over a mobile link at 1K/s and don't want extra junk. If your site doesn't look good on that, it's crap.
But more to the point, the HTML standard bends over backwards to be portable and backwards-compatible. Really. The rules are simple:
a) write compliant HTML and anything else is a browser's fault
b) write a browser to parse as much as it can, not mix tags in with content, and discard everything else
and you can't go wrong.
As soon as you start catering for browser-specific behaviour, you're being a fuckhead who should really stop polluting the Web altogether.
~Tim
--
"No ISP should be displaying obviously morally-wrong material."
.|` Clouds cross the black moonlight,
For whose values of "morally wrong"? And what values of "displaying"?
Has nobody realised yet that usenet doesn't work by what the servers do, but by what people post to them?
"(I could be wrong, there could be people who believe it is not wrong). "
I'm prepared to consider that it might not be. I don't know about `believe', that's my opinion and I reserve the right for it to differ. But it needs an occasional return to brass tacks to ask why kiddie-pr0n *is* wrong. And why it's illegal, and whether "wrong" & "illegal" are related in some way.
"ISPs who ban child pornography should be commended for fighting against obvious morally-wrong materials."
I think you'll find the vast majority do explicitly ban just about everything interesting you could ever want to do, in their T&Cs. And that's where this sort of thing should be left, between the user & the ISP.
I don't see how an ISP can be held liable for content. If you don't *like* content, that's your bad look-out. If you have a sociological problem, deal with it sociologically, don't sit there making up silly rules and having potentially devastating precedent-setting cases with all the force of the law behind it.
~Tim
--
"Write and link your application and pay attention to the very few caveats revealed by the GNU glibc team, and your app will run well on many different versions of glibc. Ignore the prophecies of the GNU glibc team, and you may be assured that your app will go down in flames. "
;)
.|` Clouds cross the black moonlight,
Yep, agreed there. Or alternatively, "just compile it statically". I'd love to see what gzexe would make of soffice.bin if that were done
~Tim
--
"The problem that Linux Distributions are so different is another. But that's not glibc's fault."
;)
.|` Clouds cross the black moonlight,
Quite so.
So what if I have a better version of glibc as provided by debian unstable than yours provided by RH7.0? That's not an issue in the slightest, you can always upgrade, I can do so easier...
The "problem" arises when you expect to compile something "for linux" without releasing any source. In that case you have to support every distro, every version of kernel, every version of every dependent library... but that's your choice for being binary-only.
Me, if it can't come from `apt-get -b source foo' then it doesn't get installed.
~Tim
--
1) If you didn't want people to hack on the code, why did you initially release it under a license that allowed that? It can't be retroactively retracted, y'know...
.|` Clouds cross the black moonlight,
2) The OpenSSH team doesn't need your approval; you in effect gave them your approval when you licensed it as you did (see 1). </i>
Here here! Exactly what I was thinking of saying, couldn't agree more.
Me, I don't see why there should be any confusion regarding `SSH' and `OpenSSH': I spell them differently, what more could you ask for?
As far as the commandname goes, it implements a secure shell - so `ssh' is a perfectly reasonable abbreviation, to me.
If you don't go round putting `(R)' after everything, you won't have a trademark problem. And while I'm passing by that, what was that I saw about "pending"? Get a trademark properly registered, *then* come moaning, or better still, do neither.
To me, Tatu's mail sounds like he's regretting the fact that openssh is moving ahead faster and with better publicity than the commercial one. Well, that's what you get for expecting to make money in the wrong arena, tough cheese.
Me, I've just installed a new RH6.2 box to be colocated in the next couple of days, and for remote access, I've put openssh on it. The non-free sshd quite simply doesn't get a look in, the license is too confusing.
~Tim
--
You seem to have confused `Linux' with `Linus'.
.|` Clouds cross the black moonlight,
~Tim
--
Despite this story's spiel to the contrary, experience is definitely proportional to age (well, given a linear offset).
.|` Clouds cross the black moonlight,
It's just that the constant of proportionality varies from person to person - you could call it "how fast you learn" which would be fairly accurate; the problems arise from applying the same constant to multiple people.
Sure, there are 20-yo sysadmins out & about, I don't doubt it. I'm not that much older, myself. But I do look back to the days when I first read O'Reilly `Essential Unix System Administration' and had some admiration for the old beardies, not arrogance, nor a rebellious feeling that the world owed me one, but rather an "I want to do something like that" with mucho respect.
First you have to experience what it's like to be unsubscribe@, webmaster@, root@, postmaster@, and to receive multitudinous "you wanker! you're going in ORBS, the DUL, the RBL, you asshole!" complaints, then you have the beginnings of experience. Then you get on with something constructive like building a VLAN between 4 sites, rolling firewalls, kernel and software updates across dozens of servers, and you're beginning to be in the right playground.
~Tim
--
"Surely the problem is not with HTML or Javascript in emails at all - its more to do with the fact that email browsers have a poor (if any) security model."
.|` Clouds cross the black moonlight,
Surely the problem is with your "neighbour" who can forward anything he likes to whosoever he likes, not with the "technology" at all?
This is what GPG is about: you have a trust model that you can use to pin folks down more responsibly to what they send where, and when you no longer trust someone as much as before, you have the means to say so - making the incentive for them not to do nasty things to your private mails. In that regard, this is nothing new - pass on, nothing to see here.
~Tim
--
" Do you realize that kinetic energy is
.|` Clouds cross the black moonlight,
proportional to the *square* of speed?"
Square of the velocity, actually. Direction is an important consideration. And you need to demonstrate that KE is the important relevant factor in an accident rather than, for example, change in momentum over surface area of impact.
~Tim
--
"Having bind run as a non-priviledged user would have greatly minimized the security
.|` Clouds cross the black moonlight,
breach. The very fact that bind doesn't do that leads me to believe that it is insecure by design. "
So why not stick `-u named' on the end of the command?
Chrooting *is* a jolly good idea for all daemons you're going to be running. But bear in mind that you can break out of a chroot jail, even easier still if you're running as root within it. (I've not read so much about it, but look into shared library requirements and that sort of thing.)
Also remember that prior to 2.2.16, any process calling setuid() could return to being running as root by breaking capabilities, anyway.
~Tim
--