Come on - they're 1.3 billion people, neighboring India with close to the same amount of people.
It's like the joke with the mathematician who gets tasked to capture a herd of sheep. He puts a small fence around himself, and declares the herd to be inside the fence (which, with the earth being round and all that, technically they are).
We westeners may well use different standards from the chinese, but is it really the chinese who are caught inside the fence?
GSM adoption was terribly slow in the U.S. (they had their own inferior but very patriotic standards and refused to let the decadent easteners (europe) dictate what to use) - but at least as far as I know, it's catching on now. Well, we have triband phones here in europe, the third band being for use in the U.S., so I guess it must be catching on. The reason? It's a good standard.
Trust me; if the chinese come up with superior standards and flood the marked with good cheap products, we will be using chinese standards faster than any trade commission can cry "unfair!".
So, EU governments want "unbreakable" encryption - this will secure the data in transit. But what good is that, when the endpoints are Exchange servers and Cisco routers (products produced by companies under control of a foreign government).
A few years ago the swedish government went ballistic when they found out that the encryption software they used (to protect the secrecy of internal swedish government documents) was produced by a US company, and someone was kind enough to tell them that since it was a closed source proprietary product, then had no way of knowing that the secrets were in fact kept secret.
Having insecure endpoints make any transport encryption pretty pointless. But I guess this is not something one can expect a politician to understand.
Yes, it does need to be released to be relevant - not to the hobby user, but the the server farm.
Woody is relevant because it has no upgrades to packages (meaning, no scripts/sql/... break because of version upgrades), it has almost instant security updates (in the form of *backports* to released software - very important!), and it's a "known good distro".
Sarge has almost daily upgrades (not updates, but upgrades - version numbers (and therefore feature-set) change!) - I am sure this is fine for the hobbyist, but it's not good enough in the server farm (if your farm is more than a handful of servers at least).
Sure, I can compile my own packages. Heck, if that's what it's all about, I could re-write most of them from scratch to get the exact features that I wanted. But this is not the issue; what I need in my server farm in order to be "effective", in order to not waste my time on things I do not need to waste my time on, I need to have instant and easy access to the required updates and I need to have a minimal (preferably zero) number of upgrades. This is what Woody has, because Woody is released. And this is what Sarge does not have, because Sarge is not released. This is why Sarge is irrelevant, as long as Sarge is not released.
I would so wish, that Debian would release Sarge within the next four to six months (as would be realistic since the only major part they need is a finished installer) - and that they would then attempt to solve these purely political issues in whatever-will-be-after-Sarge.
I'm not giving them up, but yes, fsck! this is bad.
As five minutes of CNN will show to anyone, fundamentalism in any form be it religious, political, economical or whatever, is not a very constructive thing - we live in an imperfect world where you just need to come up with and accept compromises and imperfect solutions, if you want to go anywhere.
Debian absolutely rocks as a server distribution; no updates except security updates, no version updates caused by security fixes (they are backported to the older shipped versions), generally a minimal-hassle rock-solid you-know-what-you-get distribution. I wouldn't put anything but Debian on servers I need to count on.
But I also use non-free software on my Debian servers - because in various small cases there are non-free solutions which have no reasonable equivalent in the Free software world. Debian is fine with this, and I don't expect them to ship those packages either.
But come on; removing glibc docs? What's that about? Someone put a comma in under BSD license with advertisement clause instead of GPL'ing it? Does anyone know?
re-re-rewriting the installer yet again? I was actually testing the installer betas recently, and was happy to see that there was some progress and that it generally worked well - now it needs to be "fixed" so that it can install certain parts of the kernel which are "Free" and fetch (or not fetch?) "evil" parts which are minor but somehow manages to piss off the licensing police?
Debian people; various important parts of a what we commonly know as a GNU/Linux system contain code that is not "Free" - that sucks, and it is bad, and it should be fixed. But please oh please, don't fix it in "Sarge". It wasn't fixed in "Woody", but Woody is still one of the finest server distros out there. Please allow Sarge to become the next. And *then* start fixing these problems.
There's been progress already; now there has been an amendment to the social contract which wasn't there by the time Woody was released. Attempting to solve the worlds problems before the Sarge release is not only unnecessary (Woody proves this), it is also something that will significantly harm the users of the Debian distribution *because* it will delay the release of Sarge by at least a year.
I used to download the patch clusters, but for single patches (or just few patches) that seems a little excessive.
I'm trying out PatchPro now - you can get it from Sun for free. But it's some 100MB+ java monster process, requires WBEM, and god knows what. Not exactly light weight or minimal by any means.
I was hoping for something roughly equivalent to "apt-get update; apt-get upgrade" - right now I'm at "smpatch update" which would be allright I guess if the WBEM services didn't take up half the memory in the box, all the CPU, and generally just took ages to run.
Bigadmins (with enough time on your hands to read slashdot), what do you do?
Solaris 10 contains the Trusted Solaris security features (labeled security, mandatory access controls (MAC)) which is what allows such flexible administration without the almighty root user.
I haven't run the prerelease of solaris 10 myself yet - but from what I've read, they have really taken the trusted solaris features and put them in solaris 10 - this is not just the RBAC features from solaris 9 (which would actually allow the described sub-root concepts, but not all the other goodies that come with real MAC).
This is what SELinux brings to Linux. You can run Debian stable with SELinux if you really want to. Otherwise, look for RH AS 3.0, or get to work on testing SELinux in debian unstable so that we can all get this functionality in the next debian stable.
Google around for selinux on debian and you should be able to find out how to do this.
Taking out the distribution name will *not* improve security. Do you seriously believe that a script kiddie is going to go thru all the trouble of getting headers from your server and matching them up against a "known vulnerable" list, before he runs his exploit? Well, let me tell you, they don't. And I wouldn't either.
Besides, why do you think the distribution name reveiled in the headers is the "true" distribution name? It could, after all, be that some administrators put in fake names, in the same misguided persuit of security by obscurity, as those who remove the distribution headers all together.
In other words; Headers have nothing to do with security. Attackers don't use them and they would be stupid to do so. Your IIS will still be 0wnz3d if you put Apache in its header. Your Exchange will still be 0wnz3d if you put "*****" (which seems to be common between exchange administrators) in the headers. And your old insecure Apache install is going to be rooted no matter if you disclose that it runs on RedHat 5.1 or not.
There is an obvious downside to it: it tends to discourage access to the courts by people who can't afford to lose
While that *sometimes* can be a bad thing, I believe that it will *often* be a good thing.
SCO vs. IBM
(we're broke and have no product, so give us some money)
Smokers vs. Phillip Morris
(hey, I thought smokes were good for you, I thought they had vitamin-C in 'em and stuff)
Oh, and then there's the hospitals hiring lawyers and explicitly telling *every* patient when they leave, that if the patient sues and loses, they will counter-sue. They did that to stop what became routine; that most patients did in fact sue after being treated, because there was a good chance of getting some form of compentation and no risk associated with suing.
Sure, sometimes the wrong guy loses - which is why civilized countries do not have capital punishment.
But fundamentally, I think that it is a good idea to let people/corporations who sue know, that there is a risk associated, and suing is not something you should do just for fun, or because "heck, it might work". Going to court is not a game, or at least, it ought not to be. In my humble oppinion of course.
Result: Int: 7390 ms Double: 5560 ms Long: 23070 ms Trig: 3150 ms I/O: 1420 ms
Compared to their best I/O (VC#): 9900 ms
On both their and mine systems, the file written and read is only a fraction of the size of the system memory - any decent OS will cache this file completely in memory.
I'd like to know what kind of GCC they used - is that a Cygwin version or something? Their numbers are *extremely* poor compared to my much older GCC here.
But hey, I cheated - I used an OS - probably the "OS" News people didn't think of that... Go figure;)
After all, I pay for 256/256, and if they do not want to deliver, there are plenty other providers which will be happy to make that sale to me.
If they make a deal and regret it, fair enough, there is plenty of competition. But "unacceptable use"? If they only meant to sell me 128/128 they should have said so from the beginning.
He founded the Free Software Foundation, and the ideals that lay ground to the whole movement.
He has stayed true to these ideals - as a "politician" (if you will), this is unusual, almost unheard of, and I find it highly admirable.
Not that I'm a blind follower - I develop commercial software for a living - but Richard is a person that I admire, and even if I do not agree with everything he has to say, I cannot imagine that the FSF could earn more credit by straying away from their founding ideals and replacing Richard with some more press-friendly, PR savvy, "sleek" substitute.
Richard knows what he stands for, he does not stray from his ideals.
This deserves credit and I respect him highly for that. To me, he *is* the FSF.
The dual opteron is a NUMA system - which means that the OS must *understand* that processor A has fast access to the first half of the physical memory, while processor B has fast access to the second half of the physical memory.
An OS that does not understand this, will just run applications *slow*. It is absolutely necessary to have NUMA awareness in the OS, in order to run anything fast on a NUMA system - dual opterons included.
XP does not understand NUMA and therefore XP cannot show the performance of a dual opteron.
Sure, it will not run slow - because the system is overall fast, even when you do not understand and take advantage of the memory subsystem. But it will not run *nearly* as fast as it could.
They could have booted in DOS and the benchmark would be equally relevant.
Why do these blokes not run a test that: 1) Tests the machine, not the graphics adapter 2) Runs on the operating systems that are properly supported on the platform (Linux 2.6 and MacOS X)
There are *plenty* of benchmarks that would do that (the SPEC marks, povray, linpack, spice, PostgreSQL+benchmark, you name it).
But hey, a clueless benchmark on the web, surprise!
You hit the nail on the head there - unfortunately it seems no media has even attempted to understand the basics of CC, when reporting on this...
A CC certification consists of two parts: An "assurance level", and either a "security target" or a "protection profile".
A protection profile is a sort of a "standardized security target". A description of a number of requirements that you evaluate your system against. Whereas, a "security target" is something you yourself write, if you do not want to certify your system against an existing protection profile.
NSA has submitted protection profiles that are roughly equivalent to TCSEC C2 and TCSEC B2; the CAPP and LSPP protection profiles, respectively.
SuSE got an EAL-2 certification against some security target that they themselves wrote. This means, they are "fairly" sure that their system does roughly what's in the security target (that they wrote). Had they gotten an EAL-7, it would only mean that they were "very confident" that their system did what was in their security target. It would say nothing about the completeness or even relevance of their security target.
Some newer versions of windows got an EAL-4 against the CAPP. This can be seen roughly as equivalent of the old C2 certification.
Trusted Solaris also has an EAL-4. However, they have an EAL-4 against the LSPP, which means something roughly equivalent to the TCSEC B2 certification.
People, there is a world of difference between those two EAL-4 certifications!
One should note though, that NSA writes in the LSPP that it is not intended for systems that should be used in 'hostile' environments or even with malicious users. The internet, for example, can hardly be classified as a 'friendly' environment.
This is interesting, as virtually no systems that are connected to the internet today have anything even remotely resembling the functionalities mandated by the LSPP, not to speak about assurance levels...
Avoiding frameworks and middleware can be just as important on much larger systems.
Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.
See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.
Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.
Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).
If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.
Slashdot Mirror
Come on - they're 1.3 billion people, neighboring India with close to the same amount of people.
:)
It's like the joke with the mathematician who gets tasked to capture a herd of sheep. He puts a small fence around himself, and declares the herd to be inside the fence (which, with the earth being round and all that, technically they are).
We westeners may well use different standards from the chinese, but is it really the chinese who are caught inside the fence?
GSM adoption was terribly slow in the U.S. (they had their own inferior but very patriotic standards and refused to let the decadent easteners (europe) dictate what to use) - but at least as far as I know, it's catching on now. Well, we have triband phones here in europe, the third band being for use in the U.S., so I guess it must be catching on. The reason? It's a good standard.
Trust me; if the chinese come up with superior standards and flood the marked with good cheap products, we will be using chinese standards faster than any trade commission can cry "unfair!".
Bring it on!
Come one - slashdot editors regularly seem to believe that "foot", "ounce", "gallon" and "mile" are metrics used in the modern western world.
;)
If they could start changing the little things, they can use light-year as a time measure for another year for all that I care
So, EU governments want "unbreakable" encryption - this will secure the data in transit. But what good is that, when the endpoints are Exchange servers and Cisco routers (products produced by companies under control of a foreign government).
A few years ago the swedish government went ballistic when they found out that the encryption software they used (to protect the secrecy of internal swedish government documents) was produced by a US company, and someone was kind enough to tell them that since it was a closed source proprietary product, then had no way of knowing that the secrets were in fact kept secret.
Having insecure endpoints make any transport encryption pretty pointless. But I guess this is not something one can expect a politician to understand.
Yes, it does need to be released to be relevant - not to the hobby user, but the the server farm.
Woody is relevant because it has no upgrades to packages (meaning, no scripts/sql/... break because of version upgrades), it has almost instant security updates (in the form of *backports* to released software - very important!), and it's a "known good distro".
Sarge has almost daily upgrades (not updates, but upgrades - version numbers (and therefore feature-set) change!) - I am sure this is fine for the hobbyist, but it's not good enough in the server farm (if your farm is more than a handful of servers at least).
Sure, I can compile my own packages. Heck, if that's what it's all about, I could re-write most of them from scratch to get the exact features that I wanted. But this is not the issue; what I need in my server farm in order to be "effective", in order to not waste my time on things I do not need to waste my time on, I need to have instant and easy access to the required updates and I need to have a minimal (preferably zero) number of upgrades. This is what Woody has, because Woody is released. And this is what Sarge does not have, because Sarge is not released. This is why Sarge is irrelevant, as long as Sarge is not released.
I would so wish, that Debian would release Sarge within the next four to six months (as would be realistic since the only major part they need is a finished installer) - and that they would then attempt to solve these purely political issues in whatever-will-be-after-Sarge.
I'm not giving them up, but yes, fsck! this is bad.
As five minutes of CNN will show to anyone, fundamentalism in any form be it religious, political, economical or whatever, is not a very constructive thing - we live in an imperfect world where you just need to come up with and accept compromises and imperfect solutions, if you want to go anywhere.
Debian absolutely rocks as a server distribution; no updates except security updates, no version updates caused by security fixes (they are backported to the older shipped versions), generally a minimal-hassle rock-solid you-know-what-you-get distribution. I wouldn't put anything but Debian on servers I need to count on.
But I also use non-free software on my Debian servers - because in various small cases there are non-free solutions which have no reasonable equivalent in the Free software world. Debian is fine with this, and I don't expect them to ship those packages either.
But come on; removing glibc docs? What's that about? Someone put a comma in under BSD license with advertisement clause instead of GPL'ing it? Does anyone know?
re-re-rewriting the installer yet again? I was actually testing the installer betas recently, and was happy to see that there was some progress and that it generally worked well - now it needs to be "fixed" so that it can install certain parts of the kernel which are "Free" and fetch (or not fetch?) "evil" parts which are minor but somehow manages to piss off the licensing police?
Debian people; various important parts of a what we commonly know as a GNU/Linux system contain code that is not "Free" - that sucks, and it is bad, and it should be fixed. But please oh please, don't fix it in "Sarge". It wasn't fixed in "Woody", but Woody is still one of the finest server distros out there. Please allow Sarge to become the next. And *then* start fixing these problems.
There's been progress already; now there has been an amendment to the social contract which wasn't there by the time Woody was released. Attempting to solve the worlds problems before the Sarge release is not only unnecessary (Woody proves this), it is also something that will significantly harm the users of the Debian distribution *because* it will delay the release of Sarge by at least a year.
You had the Intel386 asm document?!? You spoiled brat! :)
;)
Back in the day, I had a Soviet pirate copy (matrix printed) of a German 8086 assembly book. Based on that, I wrote my own assembler.
Now the funniest part is that it's true
But trillions of watts sounds impressive - 0.277 kilowatt hours does not.
;)
Obviously you're not a reporter
Done that. Got marked "offtopic".
Still don't see how I wasn't on topic.
Ok, something like this was bound to happen ;)
C++ bashers out there, please go read a short C++ vs. C "competition" sort-of.
It's a short explanation of some of the most common C++ vs. C misconceptions, and a funny little benchmarks (with a lot other than just hard numbers).
Just curious.
I used to download the patch clusters, but for single patches (or just few patches) that seems a little excessive.
I'm trying out PatchPro now - you can get it from Sun for free. But it's some 100MB+ java monster process, requires WBEM, and god knows what. Not exactly light weight or minimal by any means.
I was hoping for something roughly equivalent to "apt-get update; apt-get upgrade" - right now I'm at "smpatch update" which would be allright I guess if the WBEM services didn't take up half the memory in the box, all the CPU, and generally just took ages to run.
Bigadmins (with enough time on your hands to read slashdot), what do you do?
Solaris 10 contains the Trusted Solaris security features (labeled security, mandatory access controls (MAC)) which is what allows such flexible administration without the almighty root user.
I haven't run the prerelease of solaris 10 myself yet - but from what I've read, they have really taken the trusted solaris features and put them in solaris 10 - this is not just the RBAC features from solaris 9 (which would actually allow the described sub-root concepts, but not all the other goodies that come with real MAC).
This is what SELinux brings to Linux. You can run Debian stable with SELinux if you really want to. Otherwise, look for RH AS 3.0, or get to work on testing SELinux in debian unstable so that we can all get this functionality in the next debian stable.
Google around for selinux on debian and you should be able to find out how to do this.
Taking out the distribution name will *not* improve security. Do you seriously believe that a script kiddie is going to go thru all the trouble of getting headers from your server and matching them up against a "known vulnerable" list, before he runs his exploit? Well, let me tell you, they don't. And I wouldn't either.
Besides, why do you think the distribution name reveiled in the headers is the "true" distribution name? It could, after all, be that some administrators put in fake names, in the same misguided persuit of security by obscurity, as those who remove the distribution headers all together.
In other words; Headers have nothing to do with security. Attackers don't use them and they would be stupid to do so. Your IIS will still be 0wnz3d if you put Apache in its header. Your Exchange will still be 0wnz3d if you put "*****" (which seems to be common between exchange administrators) in the headers. And your old insecure Apache install is going to be rooted no matter if you disclose that it runs on RedHat 5.1 or not.
Because the author is SCO.
;)
Now how's that for a conspiracy theory
There is an obvious downside to it: it tends to discourage access to the courts by people who can't afford to lose
While that *sometimes* can be a bad thing, I believe that it will *often* be a good thing.
SCO vs. IBM
(we're broke and have no product, so give us some money)
Smokers vs. Phillip Morris
(hey, I thought smokes were good for you, I thought they had vitamin-C in 'em and stuff)
Oh, and then there's the hospitals hiring lawyers and explicitly telling *every* patient when they leave, that if the patient sues and loses, they will counter-sue. They did that to stop what became routine; that most patients did in fact sue after being treated, because there was a good chance of getting some form of compentation and no risk associated with suing.
Sure, sometimes the wrong guy loses - which is why civilized countries do not have capital punishment.
But fundamentally, I think that it is a good idea to let people/corporations who sue know, that there is a risk associated, and suing is not something you should do just for fun, or because "heck, it might work". Going to court is not a game, or at least, it ought not to be. In my humble oppinion of course.
There is an obvious downside to it: it tends to discourage access to the courts by people who can't afford to lose
Yeah; the obvious downside being that you usually don't sue unless you have a just cause and the evidence to back it up.
Oh, no, please, come on...
I suppose it will make my job more fun and my internet go faster as well, right?
That simple ending statement took all the credibility out of the release note - when will those PR droids learn not to overdo these things...
Stability... Argh! My head hurts.
Come on, that's blasphemy.
On the same machine, with no optimization at all to GCC, I get:
;)
Compilation:
gcc -O0 -o Benchmark Benchmark.c -lm
I/O: 1590 ms
Almost the same. Clearly, the thing that takes time is the system calls.
If he used Cygwin GCC it's no wonder that it sucked. But my results are still about an order of magnitude better than (optimized!) VC++ and C#.
Anyway, this comes as no surprise to me. System calls on Win32 stink - their performance as well as the raw API.
Yes, I spend too much time getting things to run fast on that platform - I have my scars - this is just an opportunity to rant about it
Same C benchmark as the OS news one, compiled with GCC 3.2.1 (older than the OS news version), run on an Athlon MP 1666 MHz:
;)
Compile options:
gcc -ffast-math -fomit-frame-pointer -march=athlon-xp -O3 -o Benchmark Benchmark.c -lm
Result:
Int: 7390 ms
Double: 5560 ms
Long: 23070 ms
Trig: 3150 ms
I/O: 1420 ms
Compared to their best I/O (VC#): 9900 ms
On both their and mine systems, the file written and read is only a fraction of the size of the system memory - any decent OS will cache this file completely in memory.
I'd like to know what kind of GCC they used - is that a Cygwin version or something? Their numbers are *extremely* poor compared to my much older GCC here.
But hey, I cheated - I used an OS - probably the "OS" News people didn't think of that... Go figure
After all, I pay for 256/256, and if they do not want to deliver, there are plenty other providers which will be happy to make that sale to me.
If they make a deal and regret it, fair enough, there is plenty of competition. But "unacceptable use"? If they only meant to sell me 128/128 they should have said so from the beginning.
Ditch them and get someone else.
Say what you want about his oppinions.
He founded the Free Software Foundation, and the ideals that lay ground to the whole movement.
He has stayed true to these ideals - as a "politician" (if you will), this is unusual, almost unheard of, and I find it highly admirable.
Not that I'm a blind follower - I develop commercial software for a living - but Richard is a person that I admire, and even if I do not agree with everything he has to say, I cannot imagine that the FSF could earn more credit by straying away from their founding ideals and replacing Richard with some more press-friendly, PR savvy, "sleek" substitute.
Richard knows what he stands for, he does not stray from his ideals.
This deserves credit and I respect him highly for that. To me, he *is* the FSF.
Not only that.
The dual opteron is a NUMA system - which means that the OS must *understand* that processor A has fast access to the first half of the physical memory, while processor B has fast access to the second half of the physical memory.
An OS that does not understand this, will just run applications *slow*. It is absolutely necessary to have NUMA awareness in the OS, in order to run anything fast on a NUMA system - dual opterons included.
XP does not understand NUMA and therefore XP cannot show the performance of a dual opteron.
Sure, it will not run slow - because the system is overall fast, even when you do not understand and take advantage of the memory subsystem. But it will not run *nearly* as fast as it could.
They could have booted in DOS and the benchmark would be equally relevant.
Why do these blokes not run a test that:
1) Tests the machine, not the graphics adapter
2) Runs on the operating systems that are properly supported on the platform (Linux 2.6 and MacOS X)
There are *plenty* of benchmarks that would do that (the SPEC marks, povray, linpack, spice, PostgreSQL+benchmark, you name it).
But hey, a clueless benchmark on the web, surprise!
You hit the nail on the head there - unfortunately it seems no media has even attempted to understand the basics of CC, when reporting on this...
A CC certification consists of two parts:
An "assurance level", and either a "security target" or a "protection profile".
A protection profile is a sort of a "standardized security target". A description of a number of requirements that you evaluate your system against. Whereas, a "security target" is something you yourself write, if you do not want to certify your system against an existing protection profile.
NSA has submitted protection profiles that are roughly equivalent to TCSEC C2 and TCSEC B2; the CAPP and LSPP protection profiles, respectively.
SuSE got an EAL-2 certification against some security target that they themselves wrote. This means, they are "fairly" sure that their system does roughly what's in the security target (that they wrote). Had they gotten an EAL-7, it would only mean that they were "very confident" that their system did what was in their security target. It would say nothing about the completeness or even relevance of their security target.
Some newer versions of windows got an EAL-4 against the CAPP. This can be seen roughly as equivalent of the old C2 certification.
Trusted Solaris also has an EAL-4. However, they have an EAL-4 against the LSPP, which means something roughly equivalent to the TCSEC B2 certification.
People, there is a world of difference between those two EAL-4 certifications!
One should note though, that NSA writes in the LSPP that it is not intended for systems that should be used in 'hostile' environments or even with malicious users. The internet, for example, can hardly be classified as a 'friendly' environment.
This is interesting, as virtually no systems that are connected to the internet today have anything even remotely resembling the functionalities mandated by the LSPP, not to speak about assurance levels...
Avoiding frameworks and middleware can be just as important on much larger systems.
Often these frameworks ("always" in the case of middleware) will add not just overhead (latency or burnt CPU cycles) to your system, it can add complexity. When given the choice of incorporating some already existing framework, or re-inventing the wheel, I often (but not always) choose to re-invent the wheel.
See, I will end up with a wheel that I know. A wheel that spins like it should, and doesn't spontaneously start brewing coffee, because someone thought that would be a great idea.
Some are religiously against re-inventing the wheel. But hey, the wheel is a well known technology, it is not necessarily very difficult to re-invent it. This amount of work, compared to the long-term implications of being dependent on something that you do not "own", make a little re-invention here and there well worth it.
Earlier on slashdot today you saw ATMs being hit by an RPC worm. Why is an ATM vulnerable to an RPC worm? Because it runs RPC. Why does it run RPC? Well, because nobody re-invented the little wheel it would have been to do a simple data transfer over a TCP connection. No, they chose either to use RPC, or to use a significant amount of middleware which did not allow them to disable RPC (otherwise, why would it have been enabled?).
If people feared re-invention a little less, and once in a while re-wrote that darn wheel instead of relying on frameworks and middleware that they cannot possibly hope to fully comprehend, you would not have ATMs being hit by RPC worms. Ximian Evolution would not take up hundreds of megabytes of memory. Web sites would not mysteriously hang if the MS ASPX interpreter got stuck. My PHP sites would not start giving load errors on every 5% of the hits after a bad call to a file load routine half a decade ago.
The world would be a better place.
Now go re-invent, please.
It is just me, or does Bill G in leather jacket look vaguely like someone from the history books?
;)
The picture: is here
If only he had a small mustache and wore jackboots
Hell, I bet he *is* wearing jackboots.