Logical depends on how you look at it - the problem is that if he simply takes it down, people dont deconfigure their systems to query his map and he continues to receive a flood of DNS queries - relays.osirusoft.com was high traffic, in excess of 300 queries/sec per server (at a time when there were 6 of them).
In order to stop the traffic he has to *force* people to deconfigure.
From experience, as someone who used to submit all his spam religiously to spamcop, its a guaranteed way of getting your upstream mail servers listed on bl.spamcop.net. (esp if your ISP does any kind of internal email forwarding, not determined by MX records - eg passing mail between SMTP front and back-end servers).
unaccountable individuals to decide who has the right to communicate by e-mail!
They dont decide that at all. They simply make the information available. The people who administrate email servers and spam filters on email servers are the ones who decided to use that list for blocking email.
This is bull. relays.Osirusoft.com was mainly a composite zone - data from other sources (eg SBL, SpamHaus, SPEWS) made available via a convenient DNSbl service. Joe had little to do with the content, only with hosting it, at considerable expense to himself.
You should/not/ use the spamcop DNSBl for blocking, as Spamcop themselves state.
Spamcop list on a statistical basis, based on headers of spam reports they receive. This means they also blacklist the upstreams of regular spamcop users (because if all of spamcop user X's mail comes to him via ISP Foo, then ISP Foo's mail server will be in all of user X's spamcop reports).
Do not use spamcop DNSBl for blacklisting - use it tagging or scoring.
Dont know about IRIX (which i/think/ is based on SysVr4, at least for IRIX 6), but Tru-64 would not be encumbered by SCO as it is not based on System V. Tru-64 is actually OSF/1, a Mach based system - created when DEC, IBM and HP decided to get together and write their own UNIX to compete against AT&T and Sun's System V.
IBM obviously didnt do anything with OSF/1, as AIX is not based on it, its some kind of bastardisation of SysVr2 or 3. HP I dont think did anything with OSF/1 either, as HP-UX is a BSD4. derivative, IIRC.
Tru-64 though would be completely in the clear. (though Tru-64 does have a SysVr4 compatibility layer, licenced from AT&T / USL).
There's a unix family tree somewhere on the net that details it all, its...../me searches, aha.. here
HP-UX - SysVr4 AIX - SysVr2 IRIX - BSD4.2 (hmm.. but i thought they switched with IRIX6 to SysV?) Tru-64 - Mach (which tends to be more BSDish)
How much security is NFS supposed to have built-in? Exactly none.
(it can make use of security contexts, eg for permissions checking of file access - but establishing those security contexts is/not/ NFSes job).
So where should that security be then? RPC.
(see Solaris and most commercial Unixen also OpenBSD for implementations of the more secure types of RPCSEC than the default AUTH_UNIX. Also, Linux 2.6 should have the secure AUTH_GSSAPI RPCSEC method, hopefully.)
OpenGL... which is also network transparent. <OpenGL> obviously proves that network transparency doesn't slow you down,
Incorrect. OpenGL is an API. It is not network transparent, nor is it not network transparent - its an API. OpenGL implementations on Unix/Linux usually will support both rendering directly to framebuffer (eg DRI on Linux/XFree86) or else render over an X connection via the GLX (GL over X) extension. So:
DR (eg DRI) -> not network transparent. GLX -> network transparent. OpenGL -> API. Implementation of API can support DR and/or GLX.
Note that back in the days when 3D hardware was much slower, OpenGL rendering via GLX to another machine could be faster than rendering direct, as it meant you had 2 CPUs available for rendering the OpenGL pipeline. These days, with very higly capable 3D hardware cheaply available and CPU fill rate often the bottleneck, GLX is typically many many times slower than DR rendering on the same machine, and even slower for remote rendering.
Well, the answer is to assign the permission to a group, not to Bob directly. But, drat, then you are back to using groups.:)
The prime problem which ACLs solve or rather work-around, is that users:
- have no way to specify their own collection of users (they have to ask the admin to create a group)
AND
- a user can not chgrp a file to any group of which they are not a member (security)
ACLs provide normal users a means to assign permissions to files by arbitrary users, and (iirc) arbitrary groups. But they are, as you point out, a management nightmare - while being a feature very few people actually need.
Well, the great grandparent should no longer have his 'informative' rating once i post this. apologies, a bad mod from me - was tired.
Though, the sentiment behind his post has more than a hint of truth to it. RH are fundamentally changing their approach to their desktop distribution, they will be devolving control to some, as yet undecided, degree. So in essence, the great grandparent you refer to is correct - future desktop RH Linux will not be the RH Linux as we know it from previous distributions (structurally) - ie probably more 'RedHat backed Linux' than 'RedHat Linux'. See:
The lack of information on that site appears to reflect the current fluidity of the plans for desktop RHL. See the various rhl lists for posts from Havoc, Alan, Rik, and other RH staff, esp this thread:
Can anyone say that the world is not a better place because of it? If so, try living in Iraq for 6 months and see how well you fare under one of SH's still controlled provinces.
The irony of course is that Iraq was a far safer place/before/ the war than it is now and, most likely, will be for the immediate future.
They also had electricity, running water, etc.. The Iraqi's though are an understanding people, dont mind that at all and are grateful for being liberated. (except for a very very small number of fanatics, who we can obviously just ignore).
This isnt true. Linus made that joke in the release email for one of his 2.0 kernel's i think - but only a few years ago, certainly/long/ after the Penguin became the Linux mascot.
Larry Ewing designed the Linux Penguin mascot quite a while ago. I dont know if he thought of using a penguin or whether Linus did.
English and dutch are descended from the same language though, undoubtadly - along with modern day German. They are all Germanic languages. (and the germanic languages in themselves borrow much from the scandinavian languages). Modern day english and german have diverged the most, and i'd put dutch as half-way between the two. (weird, just like the geographical positions of the countries:) ).
In the Netherlands a lot of people are blindly using English words
Well, a lot of the english (and hence americans) are blindly using 'dutch' derived words - just the 'dutch' to english 'borrowing' happened 1k years ago, and the dutch borrowing back from english happens today. Language is a fluid thing, borrowing and mixing according to social, political and economic needs and events. The Friesians, Angles, Saxons and other germanic tribes dominated 1k years ago and brought their languages to Briton. The language of their descendants became established as the de-facto second language of most of the world due to the empire-building of these descendants, and the current economic and cultural supremacy of a former colony established by those descendants. 'Tis how language works.
simple because it is... 'vet'
but that's a dutch word:) least, the english->dutch translation of "dierenarts" makes no sense. The dutch to english translation -> "fat", and indeed that might be english slang amongst kids these days too (some very weird teenage slang in use in england these days - i could imagine kids says "thats fat!" anyway.). Actually, I'd say dutch usage predates any english usage. (ie i havnt actually heard that term used in english slang, least not in Ireland/Scotland. But i've heard the term used in NL at least several years ago.)
I suggest the English/Americans should adopt the Dutch word "gezellig", because they do'n have a decent equivalent.
Daar ben ik met je mee eens:) - the closest english translation would be "nice" with a connotation of "comfortable". (but even that doesnt really capture it, does it?:) )
But you forget.... English and Dutch are both descended from the same language(s). (that which the Angles, Saxons, Friesians and other germanic tribes collectively known as the Anglo-Saxons spoke, who invaded and took over England). Apparently the language closest to ye olde english which is still spoken today is Vries (Friesian / spoken in the Dutch province of Groningen).
Anyway: Dutch, German, English - the one family of languages really, shouldnt matter if they import words from each other (or just from english). You could even include the scandivian languages in there too - they share a lot with the germanic languages (presumably cause of the vikings). The scandinavians though are, i presume, unique in western europe in that their languages were not directly affected by Latin influences via the Romans.
Escom (defunct PC beige-box shifter) bought the commodore name somewhere around 95, indeed. They then started to slap the C= Commodore logos onto the 'higher-end' beige-box PCs they were selling, which was in late 95 or early 96 iirc.
yes, thats a really common reiserfs problem. its due to its tail packing feature. (using tails of blocks allocated to one file for storage for other files). Use the 'notail' mount option to get rid of that problem.
IME, its completely the other way around. ReiserFS is/awfully/ prone to losing data. I know of several people who have lost a lot of data due to reiserfs, and i've had it lose data too (luckily just while testing it). OTOH, i've never had problems with ext3. (NB: to protect your data you want the data=journal option. The default protects just the metadata - which is fine for spool and tmp fs'es).
The original post that started this thread (from mensa babe) stated "run 20 drives of MTBF 20 years, then one fails each year", a poster replied to say they were incorrect, it would mean drives had MTBF of 10.5 years. And I replied to say the correctee was right. (which they are).
Your example is for 1000 drives, running for 1 year, 1 failure. Going by the same math which i used to back up the aformentioned correctee, ie MTBF = Sigma(runtime)/failures, which is:
(1000 drives * 1 year)/(1 failure) = MTBF of 1000 years.
This is the text book definition of MTBF, quoted in the glossary linked to in the story. So you're still wrong... and the math still holds.
NB: this does not take lifetime into account at all (they might/all/ fail after 1.1 years). See other posters explanations for that. MTBF is a measure of failure rate observed in a sample over a given period of time rather than an actual quantitive measure of how long something will likely run for before it breaks. Hence you will get vastly different figures for different sample sets/time periods. The 2 examples in this post being prime examples of this:
20 drives, 20 years, 1 fail per year = 10.5 year MTBF
Vs
1000 drives, 1 year, 1 fail = 1000 years MTBF
These are both textbook MTBF figures.
Which demonstrates the biggest problem with MTBF: its mostly meaningless unless one knows the details of the sample set and conditions used to obtain MTBF.
Slashdot Mirror
Logical depends on how you look at it - the problem is that if he simply takes it down, people dont deconfigure their systems to query his map and he continues to receive a flood of DNS queries - relays.osirusoft.com was high traffic, in excess of 300 queries/sec per server (at a time when there were 6 of them).
In order to stop the traffic he has to *force* people to deconfigure.
Does it seem more logical now?
From experience, as someone who used to submit all his spam religiously to spamcop, its a guaranteed way of getting your upstream mail servers listed on bl.spamcop.net. (esp if your ISP does any kind of internal email forwarding, not determined by MX records - eg passing mail between SMTP front and back-end servers).
unaccountable individuals to decide who has the right to communicate by e-mail!
They dont decide that at all. They simply make the information available. The people who administrate email servers and spam filters on email servers are the ones who decided to use that list for blocking email.
This is bull. relays.Osirusoft.com was mainly a composite zone - data from other sources (eg SBL, SpamHaus, SPEWS) made available via a convenient DNSbl service. Joe had little to do with the content, only with hosting it, at considerable expense to himself.
See:
/not/ use the spamcop DNSBl for blocking, as Spamcop themselves state.
http://spamcop.net/bl.shtml
You should
Spamcop list on a statistical basis, based on headers of spam reports they receive. This means they also blacklist the upstreams of regular spamcop users (because if all of spamcop user X's mail comes to him via ISP Foo, then ISP Foo's mail server will be in all of user X's spamcop reports).
Do not use spamcop DNSBl for blacklisting - use it tagging or scoring.
How so?
If you look at the 6Bone list archives you'll see there was a recent thread on how spammers are already exploiting IPv6 open relays.
IPv6 is no panacea.
Dont know about IRIX (which i /think/ is based on SysVr4, at least for IRIX 6), but Tru-64 would not be encumbered by SCO as it is not based on System V. Tru-64 is actually OSF/1, a Mach based system - created when DEC, IBM and HP decided to get together and write their own UNIX to compete against AT&T and Sun's System V.
/me searches, aha.. here
IBM obviously didnt do anything with OSF/1, as AIX is not based on it, its some kind of bastardisation of SysVr2 or 3. HP I dont think did anything with OSF/1 either, as HP-UX is a BSD4. derivative, IIRC.
Tru-64 though would be completely in the clear. (though Tru-64 does have a SysVr4 compatibility layer, licenced from AT&T / USL).
There's a unix family tree somewhere on the net that details it all, its.....
HP-UX - SysVr4
AIX - SysVr2
IRIX - BSD4.2
(hmm.. but i thought they switched with IRIX6 to SysV?)
Tru-64 - Mach (which tends to be more BSDish)
geneology's a fascinating thing.
It is entirely possible to write APIs that are not network transparent, although I suppose that's more of an implementation detail.
err. yes. exactly.
In any event, OpenGL was designed to be network transparent, using a client/server architecture.
example?
How much security is NFS supposed to have built-in? Exactly none.
/not/ NFSes job).
(it can make use of security contexts, eg for permissions checking of file access - but establishing those security contexts is
So where should that security be then? RPC.
(see Solaris and most commercial Unixen also OpenBSD for implementations of the more secure types of RPCSEC than the default AUTH_UNIX. Also, Linux 2.6 should have the secure AUTH_GSSAPI RPCSEC method, hopefully.)
OpenGL ... which is also network transparent. <OpenGL> obviously proves that network transparency doesn't slow you down,
Incorrect. OpenGL is an API. It is not network transparent, nor is it not network transparent - its an API. OpenGL implementations on Unix/Linux usually will support both rendering directly to framebuffer (eg DRI on Linux/XFree86) or else render over an X connection via the GLX (GL over X) extension. So:
DR (eg DRI) -> not network transparent.
GLX -> network transparent.
OpenGL -> API.
Implementation of API can support DR and/or GLX.
Note that back in the days when 3D hardware was much slower, OpenGL rendering via GLX to another machine could be faster than rendering direct, as it meant you had 2 CPUs available for rendering the OpenGL pipeline. These days, with very higly capable 3D hardware cheaply available and CPU fill rate often the bottleneck, GLX is typically many many times slower than DR rendering on the same machine, and even slower for remote rendering.
Well, the answer is to assign the permission to a group, not to Bob directly. But, drat, then you are back to using groups. :)
The prime problem which ACLs solve or rather work-around, is that users:
- have no way to specify their own collection of users (they have to ask the admin to create a group)
AND
- a user can not chgrp a file to any group of which they are not a member (security)
ACLs provide normal users a means to assign permissions to files by arbitrary users, and (iirc) arbitrary groups. But they are, as you point out, a management nightmare - while being a feature very few people actually need.
Well, the great grandparent should no longer have his 'informative' rating once i post this. apologies, a bad mod from me - was tired.
s t/ 2003-August/msg00477.html
s t/ 2003-August/msg00501.html. com/archives/rhl-beta-list/ 2003-August/msg00553.html. com/archives/rhl-beta-list/ 2003-August/msg00525.html
Though, the sentiment behind his post has more than a hint of truth to it. RH are fundamentally changing their approach to their desktop distribution, they will be devolving control to some, as yet undecided, degree. So in essence, the great grandparent you refer to is correct - future desktop RH Linux will not be the RH Linux as we know it from previous distributions (structurally) - ie probably more 'RedHat backed Linux' than 'RedHat Linux'. See:
http://rhl.redhat.com/
The lack of information on that site appears to reflect the current fluidity of the plans for desktop RHL. See the various rhl lists for posts from Havoc, Alan, Rik, and other RH staff, esp this thread:
https://listman.redhat.com/archives/rhl-beta-li
Eg:
https://listman.redhat.com/archives/rhl-beta-li
https://listman.redhat
https://listman.redhat
Obviously it's the next step.
How so? The TAM-5 was not radio-controlled. It flew autonomously.
Can anyone say that the world is not a better place because of it? If so, try living in Iraq for 6 months and see how well you fare under one of SH's still controlled provinces.
/before/ the war than it is now and, most likely, will be for the immediate future.
The irony of course is that Iraq was a far safer place
They also had electricity, running water, etc.. The Iraqi's though are an understanding people, dont mind that at all and are grateful for being liberated. (except for a very very small number of fanatics, who we can obviously just ignore).
This isnt true. Linus made that joke in the release email for one of his 2.0 kernel's i think - but only a few years ago, certainly /long/ after the Penguin became the Linux mascot.
Larry Ewing designed the Linux Penguin mascot quite a while ago. I dont know if he thought of using a penguin or whether Linus did.
hmm... if xterm is the client, X is the server, what's xinit? :)
/me thinks he has found prior art for 'middleware' :) )
(hmm..
Friesland... doh, of course :)
:) ).
... 'vet'
:) least, the english->dutch translation of "dierenarts" makes no sense. The dutch to english translation -> "fat", and indeed that might be english slang amongst kids these days too (some very weird teenage slang in use in england these days - i could imagine kids says "thats fat!" anyway.). Actually, I'd say dutch usage predates any english usage. (ie i havnt actually heard that term used in english slang, least not in Ireland/Scotland. But i've heard the term used in NL at least several years ago.)
:) - the closest english translation would be "nice" with a connotation of "comfortable". (but even that doesnt really capture it, does it? :) )
English and dutch are descended from the same language though, undoubtadly - along with modern day German. They are all Germanic languages. (and the germanic languages in themselves borrow much from the scandinavian languages). Modern day english and german have diverged the most, and i'd put dutch as half-way between the two. (weird, just like the geographical positions of the countries
In the Netherlands a lot of people are blindly using English words
Well, a lot of the english (and hence americans) are blindly using 'dutch' derived words - just the 'dutch' to english 'borrowing' happened 1k years ago, and the dutch borrowing back from english happens today. Language is a fluid thing, borrowing and mixing according to social, political and economic needs and events. The Friesians, Angles, Saxons and other germanic tribes dominated 1k years ago and brought their languages to Briton. The language of their descendants became established as the de-facto second language of most of the world due to the empire-building of these descendants, and the current economic and cultural supremacy of a former colony established by those descendants. 'Tis how language works.
simple because it is
but that's a dutch word
I suggest the English/Americans should adopt the Dutch word "gezellig", because they do'n have a decent equivalent.
Daar ben ik met je mee eens
But you forget.... English and Dutch are both descended from the same language(s). (that which the Angles, Saxons, Friesians and other germanic tribes collectively known as the Anglo-Saxons spoke, who invaded and took over England). Apparently the language closest to ye olde english which is still spoken today is Vries (Friesian / spoken in the Dutch province of Groningen).
Anyway: Dutch, German, English - the one family of languages really, shouldnt matter if they import words from each other (or just from english). You could even include the scandivian languages in there too - they share a lot with the germanic languages (presumably cause of the vikings). The scandinavians though are, i presume, unique in western europe in that their languages were not directly affected by Latin influences via the Romans.
err... X11 out of the box gives you a mouse cursor and the traditional default stippled X background. Nothing else.
:)
No xterm
Escom (defunct PC beige-box shifter) bought the commodore name somewhere around 95, indeed. They then started to slap the C= Commodore logos onto the 'higher-end' beige-box PCs they were selling, which was in late 95 or early 96 iirc.
yes, thats a really common reiserfs problem. its due to its tail packing feature. (using tails of blocks allocated to one file for storage for other files). Use the 'notail' mount option to get rid of that problem.
its 1000ft per /minute/. which is reasonably sedate. (eg article quotes WWII chutes having 1800ft/min descent rates.)
IME, its completely the other way around. ReiserFS is /awfully/ prone to losing data. I know of several people who have lost a lot of data due to reiserfs, and i've had it lose data too (luckily just while testing it). OTOH, i've never had problems with ext3. (NB: to protect your data you want the data=journal option. The default protects just the metadata - which is fine for spool and tmp fs'es).
*sigh* how did you get modded as informative?
/all/ fail after 1.1 years). See other posters explanations for that. MTBF is a measure of failure rate observed in a sample over a given period of time rather than an actual quantitive measure of how long something will likely run for before it breaks. Hence you will get vastly different figures for different sample sets/time periods. The 2 examples in this post being prime examples of this:
The original post that started this thread (from mensa babe) stated "run 20 drives of MTBF 20 years, then one fails each year", a poster replied to say they were incorrect, it would mean drives had MTBF of 10.5 years. And I replied to say the correctee was right. (which they are).
Your example is for 1000 drives, running for 1 year, 1 failure. Going by the same math which i used to back up the aformentioned correctee, ie MTBF = Sigma(runtime)/failures, which is:
(1000 drives * 1 year)/(1 failure) = MTBF of 1000 years.
This is the text book definition of MTBF, quoted in the glossary linked to in the story. So you're still wrong... and the math still holds.
NB: this does not take lifetime into account at all (they might
20 drives, 20 years, 1 fail per year
= 10.5 year MTBF
Vs
1000 drives, 1 year, 1 fail
= 1000 years MTBF
These are both textbook MTBF figures.
Which demonstrates the biggest problem with MTBF: its mostly meaningless unless one knows the details of the sample set and conditions used to obtain MTBF.
if it fails after a year, and you fix it and it lasts another 19 years, MTBF is (1+19)/2 = 10. Its failed twice on you.