This isn't really news -- except to the majority of people who listen to the ecological ideologues rather than checking out the actual data. It's been known for thirty or forty years that places with high background radiation (like Colorado, especially Pueblo and Grand Junction) have suspiciously low cancer rates, and that these cancer rates absolutely contradicted the EPA's most common assumption, of a completely linear dose-response rate. (That is, what is called the "conservative assumption" is that the response to low doses of radiation is linear because at doses above about 30 roentgen the response is linear.)
One interesting thing about this is that, if hormesis is true, as it appeaers, then all those people who have spent a small fortune clearing radon out of their basemants may have actually increased their chances of cancer.
Absolutely correct. You can still simulate this by having a group of "readers" and "writers" -- in fact, you can simulate any ACL by making a group for each possible combination of read, write and execute access to each file being managed -- but pretty quickly you're down to a group for each person in the project... which is the limiting case of using groups to simulate ACLs.
Never actually worked in an environment with confidentiality requirements, have you, bubba?
Let's assume that you want to eliminate ACLs but still need to implement fine-grained access control (like, you want to give Ann access to payroll records, but not to bank records, while giving Barry access to the bank records but keeping him out of the payroll.) You can do it in Linux without using ACLs: you simply set up a bunch of groups for things like 'payroll' and put Ann in payroll, but not Barry, etc. If you want to make it finer-grained, you could give Ann access to payroll for hourly and Amy could have access to payroll for exempt -- you now need groups 'payroll-hourly' and 'payroll-exempt'.
Pretty quick, you have something like
file group user
pay-hr.xls payroll-hourly Ann pay-ex.xls payroll-exempt Amy bank.xls banking Barry ...
in which every file has with it a group, and each group has the name of the user permitted access. In fact, since it's usually a few people, not just one, who has access, you will end up with a list of people who have controlled access.
And all without access control lists. Except for the lists of people who are allowed access.
Nice bit of dancing, but you said "is horrible in it's own way." And, unfortunately, the horror or war is pretty much the same: wounds, burns, agony, disease, death and putrefaction. The difference between someone machine-gunned in a trench in WWI and a tunnel rat shot underground in Viet Nam is primarily tactical.
I'm Vietnam-age. My father was WWII-age. My friends have children in the Middle East theatre. My grandfather was crippled in WWI. I lost ancestors on both sides of the Indian Wars, and one of my admired adults when I was child fought among Pancho Villa's insurgents and lost an eye.
The point: wars happen. Every generation. Viet Nam was no different. None. People die. Even civilians (when there's a realistic distinction: Sand Creek proves it wasn't considered much in the indian Wars.) No one expects considering the historical consequences of Castle Wolfenstein, WWI aerial combat, or the Punic Wars. Expecting a first-person shoot'em-up in Viet Nam to "consider the historical context" is idiotic.
I think you may actually be onto something: consider that their claim against IBM is not one of copyright infringement, but rather one of violation of a contract that gives SCO (via USL by transitivity) the right to control the dissemenation of code IBM wrote for AIX. So the underlying legal theory may come down to a claim that since IBM code is in Linux, they therefore have a claim to ALL of Linux.
This would also fit with something else that they've seemed to suggest, ie, that the fact that the various shells and command-line programs simulate UNIX means that SCO owns them too: that is, that the use of 'ls -l' to list a directory in long format itself infringes SCO's intellectual property.
I think what they're up to may still be an attempt to get bought out, or to get some deep-pockets Linux contributor like IBM to buy out their supposed claim. If so, it might be that what's going on is an attempt to keep blowing up those claims in the hope that they will eventually look so big that IBM (or someone similar) will decide to buy them out.
"The moutains have labored, and brought forth a ridiculous mouse."-- Virgil
You-all will have to listen to me tell stories about the Old Days, with punched cards and 256K of RAM in a cabinet the size of a refrigerator, for a lot loner.
There is really no reason to use anythingelse,[but Windows] unless you need a truly high-performance computing system such as IBM's proprietary OS/390 or HP's OpenVMS.
Or you want reliability, availability, security, or immunity from the plague of Windows-overrun exploits and attachment viruses.
You're also on pretty shaky ground in the claim that Windows doesn't push the line with patents or other intellectual property (viz. Stac.)
I'm hardly saying the pyramids aren't remarkable. I'm just saying that the pyramids are made of identifiable limestone blocks, carved out of an identifiable quarry, with identifiable tool marks. This ruins the cool theory, because they're not any kind of concrete, they're limestone blocks.
When I worke at Sun (a couple of eyars ago now) it was absolutely forbidden to hook Windows boxes to Sun's network.
(Unless, of course, you had permission: we were in consulting, our customers wanted Office documents, wqe eventually got permission to dual-boot our laptops with Solaris and Windows. Which meant, in practice, most people used Windows.)
In any case, it does not require special permission to put a Mac on the internal network, so I see real advantages there. It's entirely possible Macs are more and more widely used within Sun.
(Another point: James Gosling said he was going Mac some years ago because he didn't want to cope with MS's license policy, and I wouldn't be surprised if many followed his lead.)
More seriously, I'm nnot sure what you mean by "decent performance", but as I recall the SLIC layer was supported on other 32-bit CPUs back then (say, 92-93) so I don't find anything too astounding about it being on x86 chips. There's a natural SMP approach, so it might perform all right.
The other rumor I heard years later was that IBM had a version of SLIC that made the Java instruction set "native" to AS/400 -- or at least as native as anything else. I don't recall ever hearing anything formal about it though -- maybe our Rochester informant can follow up?
(1) I said Mach predated C++, not vice versa, and I'll stand by that modulo age-related memory loss. But I'm pretty sure Mach was around when I started grad school in '83, while Bjarne sent me a tape of cfront 1.1 in something like '86.
(2) Mach was a project at Carnegie-Mellon, not MIT.
Well, that's why I said "as far as I know"... but thinking about it, I was pretty certain that the Mach kernel was straight C. At least to my aged and fuddled memory, it seems to me Mach predates C++ and is architected around ADTs rather than full objects.
An AS/400 would be kinda fun, but it is in no way a mainframe. In fact, as AS/400 is an emulator for a lovely machine of immensely weird architecture called the System/38 -- it had a "tagged" architecture, which means that it's essentially object-oriented hardware. It also has a 120-bit address space, in which all devices (memory, disk, tapes, floppies, networks etc) simply occupy parts of the address space. The emulator makes this rather baroque instruction set run on RISC-y underlying processors, and makes the processors transparent to the rest of the system: user software doesn't even know it's on PowerPC or something weird else. (There was even some discussion of doing VLIW processors, although I don't know what ever came of it.)
The other amazing thing is that OS/400 as of V3R6 has the whole bottom layer implemented in C++ from bare silicon on up. So far as I know, it's the only commerical OS that was actually implemented from using C++ and object-oriented all the way. (I participated in teaching the folks at IBM the C++ they needed to do this.)
The point is, though, that the IBM/360 series of mainframes are not the same.
Slashdot Mirror
Sadly, you need ionizing radiation, so you're gonna have to turn up the gain on the electron guns.
This isn't really news -- except to the majority of people who listen to the ecological ideologues rather than checking out the actual data. It's been known for thirty or forty years that places with high background radiation (like Colorado, especially Pueblo and Grand Junction) have suspiciously low cancer rates, and that these cancer rates absolutely contradicted the EPA's most common assumption, of a completely linear dose-response rate. (That is, what is called the "conservative assumption" is that the response to low doses of radiation is linear because at doses above about 30 roentgen the response is linear.)
One interesting thing about this is that, if hormesis is true, as it appeaers, then all those people who have spent a small fortune clearing radon out of their basemants may have actually increased their chances of cancer.
Here's another link, this from Discover magazine.
Absolutely correct. You can still simulate this by having a group of "readers" and "writers" -- in fact, you can simulate any ACL by making a group for each possible combination of read, write and execute access to each file being managed -- but pretty quickly you're down to a group for each person in the project... which is the limiting case of using groups to simulate ACLs.
Let's assume that you want to eliminate ACLs but still need to implement fine-grained access control (like, you want to give Ann access to payroll records, but not to bank records, while giving Barry access to the bank records but keeping him out of the payroll.) You can do it in Linux without using ACLs: you simply set up a bunch of groups for things like 'payroll' and put Ann in payroll, but not Barry, etc. If you want to make it finer-grained, you could give Ann access to payroll for hourly and Amy could have access to payroll for exempt -- you now need groups 'payroll-hourly' and 'payroll-exempt'.
Pretty quick, you have something like
in which every file has with it a group, and each group has the name of the user permitted access. In fact, since it's usually a few people, not just one, who has access, you will end up with a list of people who have controlled access.And all without access control lists. Except for the lists of people who are allowed access.
What an advantage!
I read the article before I posted.
No you didn't.
My post was in reply to your post, which was speculating on whether or not the employees at most Chinese restaurants are of Vietnamese decent.
Okay, maybe you just didn't read my article before you posted.
Nice bit of dancing, but you said "is horrible in it's own way." And, unfortunately, the horror or war is pretty much the same: wounds, burns, agony, disease, death and putrefaction. The difference between someone machine-gunned in a trench in WWI and a tunnel rat shot underground in Viet Nam is primarily tactical.
Every war is horrible in it's [sic] own unique way.
That has to count among the stupidest things I've ever seen someone write.
Read the article, moron. He specifically said they were Vietnamese.
Oh, and that's spelled "restaurant".
Odds are excellent that the people in your Chinese restaurant are most disturbed by the fact that we lost. Why do you think they're here?
Get a grip, guys.
I'm Vietnam-age. My father was WWII-age. My friends have children in the Middle East theatre. My grandfather was crippled in WWI. I lost ancestors on both sides of the Indian Wars, and one of my admired adults when I was child fought among Pancho Villa's insurgents and lost an eye.
The point: wars happen. Every generation. Viet Nam was no different. None. People die. Even civilians (when there's a realistic distinction: Sand Creek proves it wasn't considered much in the indian Wars.) No one expects considering the historical consequences of Castle Wolfenstein, WWI aerial combat, or the Punic Wars. Expecting a first-person shoot'em-up in Viet Nam to "consider the historical context" is idiotic.
I think you may actually be onto something: consider that their claim against IBM is not one of copyright infringement, but rather one of violation of a contract that gives SCO (via USL by transitivity) the right to control the dissemenation of code IBM wrote for AIX. So the underlying legal theory may come down to a claim that since IBM code is in Linux, they therefore have a claim to ALL of Linux.
This would also fit with something else that they've seemed to suggest, ie, that the fact that the various shells and command-line programs simulate UNIX means that SCO owns them too: that is, that the use of 'ls -l' to list a directory in long format itself infringes SCO's intellectual property.
I think what they're up to may still be an attempt to get bought out, or to get some deep-pockets Linux contributor like IBM to buy out their supposed claim. If so, it might be that what's going on is an attempt to keep blowing up those claims in the hope that they will eventually look so big that IBM (or someone similar) will decide to buy them out.
"The moutains have labored, and brought forth a ridiculous mouse."-- Virgil
1) Never underestimate the power of human stupidity.
2) Never ascribe to malice that which can be explained by stupidity.
You-all will have to listen to me tell stories about the Old Days, with punched cards and 256K of RAM in a cabinet the size of a refrigerator, for a lot loner.
To be more explicit: Linux has what it needs to protect itself. The courts are just doing a bad job of enforcing the rules.
Lovely thought. Really dumb, but lovely.
There is really no reason to use anythingelse,[but Windows] unless you need a truly high-performance computing system such as IBM's proprietary OS/390 or HP's OpenVMS.
Or you want reliability, availability, security, or immunity from the plague of Windows-overrun exploits and attachment viruses.
You're also on pretty shaky ground in the claim that Windows doesn't push the line with patents or other intellectual property (viz. Stac.)
Linux's legal defences are adequate; our country's implementation of them is not.
Are you under the impression this sentence meant something?
Try cert@cert.org -- they commonly act as honest brokers on this kind of thing.
I'm hardly saying the pyramids aren't remarkable. I'm just saying that the pyramids are made of identifiable limestone blocks, carved out of an identifiable quarry, with identifiable tool marks. This ruins the cool theory, because they're not any kind of concrete, they're limestone blocks.
When I worke at Sun (a couple of eyars ago now) it was absolutely forbidden to hook Windows boxes to Sun's network.
(Unless, of course, you had permission: we were in consulting, our customers wanted Office documents, wqe eventually got permission to dual-boot our laptops with Solaris and Windows. Which meant, in practice, most people used Windows.)
In any case, it does not require special permission to put a Mac on the internal network, so I see real advantages there. It's entirely possible Macs are more and more widely used within Sun.
(Another point: James Gosling said he was going Mac some years ago because he didn't want to cope with MS's license policy, and I wouldn't be surprised if many followed his lead.)
More seriously, I'm nnot sure what you mean by "decent performance", but as I recall the SLIC layer was supported on other 32-bit CPUs back then (say, 92-93) so I don't find anything too astounding about it being on x86 chips. There's a natural SMP approach, so it might perform all right.
The other rumor I heard years later was that IBM had a version of SLIC that made the Java instruction set "native" to AS/400 -- or at least as native as anything else. I don't recall ever hearing anything formal about it though -- maybe our Rochester informant can follow up?
He hinted?
(1) I said Mach predated C++, not vice versa, and I'll stand by that modulo age-related memory loss. But I'm pretty sure Mach was around when I started grad school in '83, while Bjarne sent me a tape of cfront 1.1 in something like '86.
(2) Mach was a project at Carnegie-Mellon, not MIT.
Very nifty.
;-)
Thank you.
Cool! And how *are* things in Rochester?
Well, that's why I said "as far as I know" ... but thinking about it, I was pretty certain that the Mach kernel was straight C. At least to my aged and fuddled memory, it seems to me Mach predates C++ and is architected around ADTs rather than full objects.
An AS/400 would be kinda fun, but it is in no way a mainframe. In fact, as AS/400 is an emulator for a lovely machine of immensely weird architecture called the System/38 -- it had a "tagged" architecture, which means that it's essentially object-oriented hardware. It also has a 120-bit address space, in which all devices (memory, disk, tapes, floppies, networks etc) simply occupy parts of the address space. The emulator makes this rather baroque instruction set run on RISC-y underlying processors, and makes the processors transparent to the rest of the system: user software doesn't even know it's on PowerPC or something weird else. (There was even some discussion of doing VLIW processors, although I don't know what ever came of it.)
The other amazing thing is that OS/400 as of V3R6 has the whole bottom layer implemented in C++ from bare silicon on up. So far as I know, it's the only commerical OS that was actually implemented from using C++ and object-oriented all the way. (I participated in teaching the folks at IBM the C++ they needed to do this.)
The point is, though, that the IBM/360 series of mainframes are not the same.