The license better be open - as in, "everyone" can use it. Not just open source projects.
Sure, if open source projects can't use it freely, it's stillborn. But it's almost equally important that ISVs can adopt it as well, without paying MS patent tax.
E-mail is such a fundamental part of what we do with the internet nowadays, that even if MS themselves and all open source projects can use this, it will still hurt an absolutely enormous amount of products and companies, if the license is not truly "open" (free for use, for any purpose what so ever, no strings attached).
Hmm... Somehow I just doubt that this is what the OSI or MS wants;)
Yep, might be offtopic, but while we're at it let me give my point of view:
No, I'm not a GNU/Linux naming Nazi, but when people start doing this BSD/X/GNU/Linux extrapolation I can't help but think that it's silly. BSD and X are licenses in that context, GNU is not - and nobody suggested naming it GPL/Linux - the idiocy in the licensing argument against the GNU/Linux name should be pretty obvious, but for some reason it's not.
It makes sense to write GNU/Linux, not because of licensing, but because of history.
We would not have had Linux (at least not in remotely the form or shape that the kernels and distributions are in today), nor would the (free-/net-/open-)BSDs have been where they are today, if it was not for gcc and other early GNU projects.
Yes, plenty of other projects use BSD or other non-GPL licenses. But a very large number of them, and certainly a *very* big portion of what makes up a modern "Linux distribution" today, owes a lot to the early GNU projects.
You mean, the distro that ships a 2.2 kernel by default, a broken 2.4 as an option, and has a package management system that leaves half-installed packages around when it encounters errors?
No, I don't think they are big enough either.
(yes, I use Debian on everything I have that is important - because they're the best, and the significant downsides are either acceptable or can be worked around - but they're not perfect either).
Well, several of the ext3 people are employed by RedHat - it makes sense that they don't want to work with Reiser but rather spend time on ext3.
As a company, when you have good employees who like to do A and don't want to do B, you can either force them to do B and deal with the possible consequences, or simply prioritize B lower and be happy with A.
I'm not surprised that RedHat did what they did - it's the problem of limited ressources.
And no, I don't mean to bash RedHat - no distributor is big enough to do everything 100%.
Come on Hans, give us what you know we slashdot junkies want!
How are we supposed to take a filesystem serious if there are no screenshots!?
8)
Making it small is the trick
on
Latest SP2 News
·
· Score: 5, Informative
What you do when you want a large system to be secure:
You implement a very small "core" or "security kernel" or "call it what you like". It is called a "reference monitor" in TCSEC. It is a piece of code that will be asked "can subject X do operation Y on object Z", whenever a user or program attempts any operation on any object (like a file or a network connection). This piece of code is so small and simple that you can inspect it and possibly even formally *prove* it to be correct.
The operating system kernel will then guarantee that the reference monitor is consulted on all such operations. This is, after all, what operating system kernels do, among other things.
Now; you can write a simple security policy for each subsystem in your operating system. One policy for your browser, one for your word processor, one for your regular secretaries, one for your accountants, etc. (a real OS with these features will of course have the majority of all policies set up and ready by default).
The system will now enforce the security policies on everything that goes on in the system. Because the OS is enforcing these policies, and because the subsystems cannot magially change the security policies set up for them, this is called "Mandatory Access Controls", or MAC for short.
MAC ensures that a bug in, say, your browser, cannot be exploited to, say, go thru your documents and harvest e-mail addresses. Simply because the system policy does not allow a browser with internet access to access local documents. Just an example.
This is how secure systems are built. This is what SELinux is trying to do, and this is what Trusted Solaris has done for a while. This is what is required if you want a TCSEC certification in the B (or A) class, not the kindergarten-security of the C class.
Or, under the common criteria, this is what you need to get certification against the LSPP (as Trusted Solaris has), instead of the kindergarten-security CAPP (as Win2000 can have in certain restricted setups), or even the home-grown "security targets" (which SuSE got).
This is old and well known technology. Too bad big businesses and governments never put pressure on the vendors to actually have real security built in.
Good to see SELinux coming along nicely, and Sun moving Trusted Solaris features into Solaris 10.
All is not lost - but trust me, they will be selling snow-cones in hell before you see MAC in Windows.
You may have a local CERT office to which you can report these incidents. I guess that's what you "should" do.
However, in my experience that's a complete waste of time. CERT (both national and international) have proven themselves to me to be a bunch of flaming morons and pacifist hippies, either ignorant or afraid of their own shadows - well, maybe unless you're Raytheon or someone else who has friends that fund CERT...
What you can do, however, is to set up firewalling. Make it annoying - use "drop" rules instead of "reject" - so that SSH connections like you are seeing, made from "unwanted" IP addresses will simply hang for a small eternity before they time out, rather than giving the k!dd13 a login prompt right away.
Filtering out ICMP ECHO REQUEST message might be a good idea - nmap with default options will not portscan a machine if it can't ping it - so while this of course doesn't buy you any security in any way what so ever, it may lessen the number of attempted intrusions. First firewalling advise still stands though; set up rules to waste as much as as possible of the wannabe intruder.
Last but not least - make damn sure your systems are secure. (this implies; running a GNU/Linux distribution you can reliably keep up to date, or running some other OS you can reliably keep up to date)
I have no problem with distinguishing between a country and a continent (or union of countries if you will) - but I just read the original comment as implying "UK not having any connection what so ever to Europe".
I thought that was funny.
But hey, never mind - if it weren't for the French, the US would still be a British colony, and who's talking about that nowadays;)
Anyway, if these guys had any clue about what they were working with, a lot of things would have been different: *) They would not have benched a low-end desktop CPU against the highest-end (still unavailable) server CPU *) They would have used optimization options with the compiler *) They would not have used synthetic benchmarks - and if they had, it would only have been as a "curiosity" not as results you could draw any meaning from
I mean, come on, they wonder how HT can slow the system down... They think it is *strange*... Yes, why on earth would two cache-thrashing MySQL threads competing for the same cache run slower concurrently, than one at a time - makes you think.
And they can't test SMP with POVRAY because it is not threaded - oh, come on, how about rendering *two* scenes concurrently? I guess that's just a too far fetched idea for these kings of benchmarks and queens of numbers.
Now that I'm at it; how about a "make -j1" versus "make -j3" versus "make -j20" on a plain kernel.org source tree - that's integer and memory performance as well as SMP (or NUMA actually, in the AMD case) scalability testing for you, with a very real-world benchmark.
I lose nothing by running Seti@HOME, and I have nothing (or at least little) to gain. Let's say that my computer is the one that finds the "alien signal" paving way to a real sustainable contact, visits, technology exchange and what have you with an alien civilization. I'd be lucky to end up in a history book.
Similarly, the research groups working on the signal processing, detection, filtering and what have you, will freely share information - again because they have nothing to gain by refraining therefrom.
But financial markets? If my computer can detect that in a few weeks General Electric's shares will plummet - why would I want to give that information away? Would I get a reward from the research group (at a financial institution somewhere most likely) that could (and of course would) benefit from this information?
Would the algorithms even be developed? Why would one group (at Citibank for example) share their information with another group (at GE Capital or whatever)?
There would not be sharing of knowledge. There would not be sharing of results. Simply because the potential gain you have by keeping the information confined is too great.
If you could forecast financial markets reliably on a large scale, imagine how powerful you could become. You could buy the planet.
And this, ladies and gentlemen, is why shit like this won't happen. Not as long as financial markets deal in things that have material value.
Security updates are almost instant - not only in becoming available, but also when you look at the timeframe from when it becomes available till I actually have it running on critical production systems.
This is possible, because I know that I won't have to worry about some PostgreSQL feature changing, some weird Apache module configuration file format change, or what have you... I know that I can safely install security upgrades *immediately*, because I know that the package as such is not upgraded, the security fix is instead *backported* to the (outdated, but more than adequate) subsystem that had the security vulnerability.
Other admins I know will wait until the weekend before they apply updates, because experience has taught them that security fixes break things every now and then. Just not so on Woody.
And face it; how bad is Apache 1.3.X, how bad is PostgreSQL 7.2.X ? It's not all that bad. Sure, it's "outdated" compared to the bleeding edge, but they worked a few years ago, and with security updates backported, they still work very well. And I haven't had a single service "dropout" because of security updates (or anything else for that matter).
I think the most serious service dropout I encountered was a kernel update - due to errors on my side, I waited for a minute long than I had to after the machine came up before I started Apache (requires passphrase for SSL certificate). So, the most serious service dropout I've experienced thru my time with Debian was a two-minute web-server downtime. Because of a kernel update (requiring reboot) and my own stupidity in combination:) This is over a period of a few years now.
For things that absolutely need to stay up and running, I haven't seen anything approaching Debian/Stable.
Of course, my days with debian on the desktop are over (at least for now). Different requirements, different distributions (or even different operating systems).
Re:Heavy Metal, why am I not surprised?
on
IT's Musical Habits
·
· Score: 4, Insightful
Ever occurred to you that we could be into music played on real instruments simply because of the technology *not* involved in making it?
When you code 10-14 hours a day, I find it's nice to listen to something *not* coming out of a computer (well, ok, the sound *is* coming out of a computer, but way back once it actually came out of an analog instrument).
The beat is set by a human being, an undertuned 8-string guitar roars thru the distorted tube amplifier (ok and then it all goes into a 12-bit ADC, back and forth between different media and in the end comes out of speakers attached to a computer - but never mind the last part.) - see, that is the kind of music that gets me thru the day in front of the 22" CRT:)
In the example with two data disks and a parity disk (this is really RAID-4, but the principle is the same as for RAID-5, except in RAID-5 the parity blocks are distributed among the disks instead of being located on one disk), the parity is computed as "parity = data_1 (xor) data_2"
Now, because exclusive-or works the way it does, the following holds:
parity = data_1 (xor) data_2
data_1 = parity (xor) data_2
data_2 = parity (xor) data_1
So, you run this algorithm over every bit on your disks, and you end up with parity information that will allow you to "regenerate" the information on any of the two data disks, regardless of which one is lost.
Example:
disk 1, disk 2, parity disk
0 0 0
0 1 1
1 0 1
1 1 0
Now imagine we lose disk 2:
disk 1, parity disk, d_1 xor p
0 0 0
0 1 1
1 1 0
1 0 1
Voila! By computing the XOR of the data on disk 1 and the parity data, we can magically reconstruct what was on disk 2 before it crashed.
The same will work if disk 1 or the parity disk was corrupted.
If you try and write this down on paper, you will see that the scheme also easily extends to any larger number of disks. Pure genius:)
Hardware controllers with batter backed RAM (note; not all controllers have this), will have an edge over software solutions on ALL writes - no matter which RAID level you use.
Don't even bother trying to do RAID 5 in software
SW RAID is usually a lot faster than HW RAID solutions, when you factor out the battery-backed RAM part. Any HW RAID controller with battery backed memory will lose big-time to SW RAID on even moderately faster CPUs (like 500MHz P-IIIs), especially on RAID-5 which is compute intensive, an even more on RAID-6 which is also compute intensive but not XOR based.
Modern HW RAID controllers have reasonably fast CPUs with XOR accelerators built in - therefore they can do RAID-5 as fast as the pure SW solution. But this is not the case with older controllers.
I know of people who use 3ware cards for large RAID-5 servers, but only use the 3ware cards as "dumb" IDE controllers, and leave the RAID-5 handling to SW-RAID. The reason? Their benchmarks indicate that this is significantly faster.
And when you think about it, it makes sense. Nobody puts a GHz processor on a RAID controller. Even a slow-by-todays-standards P-III is able to XOR more than a gigabyte of data per second - much much more than anything you put thru most file servers out there.
So, the "HW RAID is faster than SW RAID" is true in one scenario only; when you have write-intensive workloads and a HW RAID controller with battery backed cache.
In *all* other cases, SW RAID will be a win, performance wise.
For a personal file server, I wouldn't hesitate to run RAID-5 in plain software. It's as fast or faster than any HW RAID controller in the sub-$3K price range, it's reliable, and the flexibility beats the heck out of any HW based solution out there (mixing IDE/SCSI, allowing a cryptographic layer between the RAID layer and the physical disks, etc. etc...)
In C++ you do not have a complex numbers in the language - but they are available in a library. Thus, you can write
std::complex<double> a, b, c; ...
a = b + 2 * c;
You can write your own 'std::complex' alike templates for matrix arithmetic or whatever - or use some of the template libraries already available to do this. What you are asking for, is simply already available, and has been so for quite some time.
I wrote a fuzzy-logic boolean type once, where I could write
fuzzbool a, b, c; ...
if (a && b || c)...;
the statement would be 'true' even if a was 'not completely true' and c was 'definitely false', if only b was 'very true'. Fuzzy logic with familiar syntax. All transformed into efficient simple machine code by the wonders of the compiler internals.
Yet, even something as simple as this is not well understood by most programmers out there. I sincerely doubt that more of this transformation madness is going to solve any significant problems - what we should be worrying about, is to educate people to begin using what is already available.
Then, in a few decades when we have experience with the technologies from the last decade, let's talk about extending on that or re-doing things.
compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications
Uh? My compiler acts as a "plugin" via. make, which is called from emacs. If I want another compiler, I tell make, and voila' it's "plugged in". Welcome to the world of 'NIX Mr. Wilson.
What is worse, every tool's command-line mini-language is different from every other's
But this is their strength! Different tools solve different problems - and they use different languages to describe what they do, because they are *fundamentally* different (awk is not sed is not grep is not ls). How would you possibly write up a single language to describe what both sed and awk does, without poorly re-creating perl?
Attempts to stick to simple on-or-off options lead to monsters like gcc, which now has so many flags that programmers are using genetic algorithms to explore them
Most CS majors will know that modern CPU architectures are complex beasts, and that it is pretty hard to come up with which combination of optimization methods will yield the best performance on some particular revision of some particular CPU on some particular hardware configuration. Nothing mysterious about that. I completely fail to see what that has to do with command line options.
And instead of squeezing their intentions through the narrow filter of command-line mini-languages, programmers can specify their desires using loops, conditionals, method calls, and all the other features of familiar languages
Instead of squeezing my intentions thru the narrow filter of command-line mini-languages, I can specify my desires using what a standard shell (like bash) has to offer. Ladies and gentlemen of the jury, this is not making sense!
The result is that today's Windows developers can write programs in Visual Basic, C++, or Python that use Visual Studio to compile and run a program, Excel to analyze its performance, and Word to check the spelling of the final report.
Oh come on, please... So if I develop on windows, I can use VB, C++ and Python. How is this relevant? There are more useful languages available on the dreaded "command line systems" ('NIX), but let's just agree that there are plenty of languages available on most OS'es out there - regardless of the windowiness or commandlineness of the system.
Using VS to compile and run the application? Well, if your command line absolutely sucks, they I can imagine why you would want to launch your app from your editor - a matter of taste too maybe. But relevant? How?
Somehow I need COM in order to put numbers into Excel? Ever heard of CSV? You know, new-line terminated lines of T-E-X-T which can be processed by these little all-different tools, like, for example, Excel.
The part about Word and spell-checking of a final report... What? What's your point? If I use COM for developing software, I can spell-check in Word? If I use a command line, I cannot spell check a report that I write about it in Word?
A similar API allows the popular memory-checking tool Purify to be used in place of Visual Studio's own debugger, and so on.
Absolutely! Plusings make perfect sense certain places. Dude - GUD is written in Emacs LISP, it's a plugin for GDB. You could write an elisp file for Purify as well - in fact, Intel actually ships an elisp file for their debugger, even on Windows... Plugins make sense some places, other places they don't. Which, lo and behold, is why they are used certain places and not others.
One of the great ironies of the early 21st Century is that the programmers who build component systems for others are strangely reluctant to componentize their own tools. Compilers and linkers are still monolithic command-line applications: files go in, files come out
Why does he not see what he's writing?!? A compiler reads a number of input files and generate an output file - this is a perfect match for a command-line too
Slashdot Mirror
If only there was a "+6 Unbelievably funny"...
;)
Thanks! You made my day
The license better be open - as in, "everyone" can use it. Not just open source projects.
;)
Sure, if open source projects can't use it freely, it's stillborn. But it's almost equally important that ISVs can adopt it as well, without paying MS patent tax.
E-mail is such a fundamental part of what we do with the internet nowadays, that even if MS themselves and all open source projects can use this, it will still hurt an absolutely enormous amount of products and companies, if the license is not truly "open" (free for use, for any purpose what so ever, no strings attached).
Hmm... Somehow I just doubt that this is what the OSI or MS wants
Yep, might be offtopic, but while we're at it let me give my point of view:
No, I'm not a GNU/Linux naming Nazi, but when people start doing this BSD/X/GNU/Linux extrapolation I can't help but think that it's silly. BSD and X are licenses in that context, GNU is not - and nobody suggested naming it GPL/Linux - the idiocy in the licensing argument against the GNU/Linux name should be pretty obvious, but for some reason it's not.
It makes sense to write GNU/Linux, not because of licensing, but because of history.
We would not have had Linux (at least not in remotely the form or shape that the kernels and distributions are in today), nor would the (free-/net-/open-)BSDs have been where they are today, if it was not for gcc and other early GNU projects.
Yes, plenty of other projects use BSD or other non-GPL licenses. But a very large number of them, and certainly a *very* big portion of what makes up a modern "Linux distribution" today, owes a lot to the early GNU projects.
You mean, the distro that ships a 2.2 kernel by default, a broken 2.4 as an option, and has a package management system that leaves half-installed packages around when it encounters errors?
No, I don't think they are big enough either.
(yes, I use Debian on everything I have that is important - because they're the best, and the significant downsides are either acceptable or can be worked around - but they're not perfect either).
Well, several of the ext3 people are employed by RedHat - it makes sense that they don't want to work with Reiser but rather spend time on ext3.
As a company, when you have good employees who like to do A and don't want to do B, you can either force them to do B and deal with the possible consequences, or simply prioritize B lower and be happy with A.
I'm not surprised that RedHat did what they did - it's the problem of limited ressources.
And no, I don't mean to bash RedHat - no distributor is big enough to do everything 100%.
What?!?
Come on Hans, give us what you know we slashdot junkies want!
How are we supposed to take a filesystem serious if there are no screenshots!?
8)
What you do when you want a large system to be secure:
You implement a very small "core" or "security kernel" or "call it what you like". It is called a "reference monitor" in TCSEC. It is a piece of code that will be asked "can subject X do operation Y on object Z", whenever a user or program attempts any operation on any object (like a file or a network connection). This piece of code is so small and simple that you can inspect it and possibly even formally *prove* it to be correct.
The operating system kernel will then guarantee that the reference monitor is consulted on all such operations. This is, after all, what operating system kernels do, among other things.
Now; you can write a simple security policy for each subsystem in your operating system. One policy for your browser, one for your word processor, one for your regular secretaries, one for your accountants, etc. (a real OS with these features will of course have the majority of all policies set up and ready by default).
The system will now enforce the security policies on everything that goes on in the system. Because the OS is enforcing these policies, and because the subsystems cannot magially change the security policies set up for them, this is called "Mandatory Access Controls", or MAC for short.
MAC ensures that a bug in, say, your browser, cannot be exploited to, say, go thru your documents and harvest e-mail addresses. Simply because the system policy does not allow a browser with internet access to access local documents. Just an example.
This is how secure systems are built. This is what SELinux is trying to do, and this is what Trusted Solaris has done for a while. This is what is required if you want a TCSEC certification in the B (or A) class, not the kindergarten-security of the C class.
Or, under the common criteria, this is what you need to get certification against the LSPP (as Trusted Solaris has), instead of the kindergarten-security CAPP (as Win2000 can have in certain restricted setups), or even the home-grown "security targets" (which SuSE got).
This is old and well known technology. Too bad big businesses and governments never put pressure on the vendors to actually have real security built in.
Good to see SELinux coming along nicely, and Sun moving Trusted Solaris features into Solaris 10.
All is not lost - but trust me, they will be selling snow-cones in hell before you see MAC in Windows.
You may have a local CERT office to which you can report these incidents. I guess that's what you "should" do.
However, in my experience that's a complete waste of time. CERT (both national and international) have proven themselves to me to be a bunch of flaming morons and pacifist hippies, either ignorant or afraid of their own shadows - well, maybe unless you're Raytheon or someone else who has friends that fund CERT...
What you can do, however, is to set up firewalling. Make it annoying - use "drop" rules instead of "reject" - so that SSH connections like you are seeing, made from "unwanted" IP addresses will simply hang for a small eternity before they time out, rather than giving the k!dd13 a login prompt right away.
Filtering out ICMP ECHO REQUEST message might be a good idea - nmap with default options will not portscan a machine if it can't ping it - so while this of course doesn't buy you any security in any way what so ever, it may lessen the number of attempted intrusions. First firewalling advise still stands though; set up rules to waste as much as as possible of the wannabe intruder.
Last but not least - make damn sure your systems are secure. (this implies; running a GNU/Linux distribution you can reliably keep up to date, or running some other OS you can reliably keep up to date)
Attracting women to computer science
:)
Or
Attracting women that are into computer science
You choose. Personally, I find the latter to be the most difficult by far
Hehe ;)
;)
I have no problem with distinguishing between a country and a continent (or union of countries if you will) - but I just read the original comment as implying "UK not having any connection what so ever to Europe".
I thought that was funny.
But hey, never mind - if it weren't for the French, the US would still be a British colony, and who's talking about that nowadays
You know, I was going to make a joke about UK versus Europe (your post sounds like you're not aware that the UK is in Europe).
:)
But who here on Slashdot would have even gotten the point?
Well, you're in CS not Geography - no harm done.
Absolutely correct.
Anyway, if these guys had any clue about what they were working with, a lot of things would have been different:
*) They would not have benched a low-end desktop CPU against the highest-end (still unavailable) server CPU
*) They would have used optimization options with the compiler
*) They would not have used synthetic benchmarks - and if they had, it would only have been as a "curiosity" not as results you could draw any meaning from
I mean, come on, they wonder how HT can slow the system down... They think it is *strange*... Yes, why on earth would two cache-thrashing MySQL threads competing for the same cache run slower concurrently, than one at a time - makes you think.
And they can't test SMP with POVRAY because it is not threaded - oh, come on, how about rendering *two* scenes concurrently? I guess that's just a too far fetched idea for these kings of benchmarks and queens of numbers.
Now that I'm at it; how about a "make -j1" versus "make -j3" versus "make -j20" on a plain kernel.org source tree - that's integer and memory performance as well as SMP (or NUMA actually, in the AMD case) scalability testing for you, with a very real-world benchmark.
It's sad. Plain sad.
I lose nothing by running Seti@HOME, and I have nothing (or at least little) to gain. Let's say that my computer is the one that finds the "alien signal" paving way to a real sustainable contact, visits, technology exchange and what have you with an alien civilization. I'd be lucky to end up in a history book.
Similarly, the research groups working on the signal processing, detection, filtering and what have you, will freely share information - again because they have nothing to gain by refraining therefrom.
But financial markets? If my computer can detect that in a few weeks General Electric's shares will plummet - why would I want to give that information away? Would I get a reward from the research group (at a financial institution somewhere most likely) that could (and of course would) benefit from this information?
Would the algorithms even be developed? Why would one group (at Citibank for example) share their information with another group (at GE Capital or whatever)?
There would not be sharing of knowledge. There would not be sharing of results. Simply because the potential gain you have by keeping the information confined is too great.
If you could forecast financial markets reliably on a large scale, imagine how powerful you could become. You could buy the planet.
And this, ladies and gentlemen, is why shit like this won't happen. Not as long as financial markets deal in things that have material value.
You said it.
:) This is over a period of a few years now.
Security updates are almost instant - not only in becoming available, but also when you look at the timeframe from when it becomes available till I actually have it running on critical production systems.
This is possible, because I know that I won't have to worry about some PostgreSQL feature changing, some weird Apache module configuration file format change, or what have you... I know that I can safely install security upgrades *immediately*, because I know that the package as such is not upgraded, the security fix is instead *backported* to the (outdated, but more than adequate) subsystem that had the security vulnerability.
Other admins I know will wait until the weekend before they apply updates, because experience has taught them that security fixes break things every now and then. Just not so on Woody.
And face it; how bad is Apache 1.3.X, how bad is PostgreSQL 7.2.X ? It's not all that bad. Sure, it's "outdated" compared to the bleeding edge, but they worked a few years ago, and with security updates backported, they still work very well. And I haven't had a single service "dropout" because of security updates (or anything else for that matter).
I think the most serious service dropout I encountered was a kernel update - due to errors on my side, I waited for a minute long than I had to after the machine came up before I started Apache (requires passphrase for SSL certificate). So, the most serious service dropout I've experienced thru my time with Debian was a two-minute web-server downtime. Because of a kernel update (requiring reboot) and my own stupidity in combination
For things that absolutely need to stay up and running, I haven't seen anything approaching Debian/Stable.
Of course, my days with debian on the desktop are over (at least for now). Different requirements, different distributions (or even different operating systems).
Ever occurred to you that we could be into music played on real instruments simply because of the technology *not* involved in making it?
:)
When you code 10-14 hours a day, I find it's nice to listen to something *not* coming out of a computer (well, ok, the sound *is* coming out of a computer, but way back once it actually came out of an analog instrument).
The beat is set by a human being, an undertuned 8-string guitar roars thru the distorted tube amplifier (ok and then it all goes into a 12-bit ADC, back and forth between different media and in the end comes out of speakers attached to a computer - but never mind the last part.) - see, that is the kind of music that gets me thru the day in front of the 22" CRT
Fiat and Windows.
Any one of those is a disaster in itself - now mix them and add wireless.
Uhh.... Scary.
...that my mother has been running Gentoo on her desktop machine for three weeks now.
Just yet another "security" problem than I won't have to care about. Ahhhh.
I was eating!
:)
You insensitive clod.
Now, because exclusive-or works the way it does, the following holds:
parity = data_1 (xor) data_2
data_1 = parity (xor) data_2
data_2 = parity (xor) data_1
So, you run this algorithm over every bit on your disks, and you end up with parity information that will allow you to "regenerate" the information on any of the two data disks, regardless of which one is lost.
Example:Now imagine we lose disk 2:Voila! By computing the XOR of the data on disk 1 and the parity data, we can magically reconstruct what was on disk 2 before it crashed.
The same will work if disk 1 or the parity disk was corrupted.
If you try and write this down on paper, you will see that the scheme also easily extends to any larger number of disks. Pure genius
Oops - one correction to the above:
Any HW RAID controller with battery backed memory will lose big-time to SW RAID
That of course should read "without battery backed memory"
If it's just a mirror, writes are slowed slightly
Hardware controllers with batter backed RAM (note; not all controllers have this), will have an edge over software solutions on ALL writes - no matter which RAID level you use.
Don't even bother trying to do RAID 5 in software
SW RAID is usually a lot faster than HW RAID solutions, when you factor out the battery-backed RAM part. Any HW RAID controller with battery backed memory will lose big-time to SW RAID on even moderately faster CPUs (like 500MHz P-IIIs), especially on RAID-5 which is compute intensive, an even more on RAID-6 which is also compute intensive but not XOR based.
Modern HW RAID controllers have reasonably fast CPUs with XOR accelerators built in - therefore they can do RAID-5 as fast as the pure SW solution. But this is not the case with older controllers.
I know of people who use 3ware cards for large RAID-5 servers, but only use the 3ware cards as "dumb" IDE controllers, and leave the RAID-5 handling to SW-RAID. The reason? Their benchmarks indicate that this is significantly faster.
And when you think about it, it makes sense. Nobody puts a GHz processor on a RAID controller. Even a slow-by-todays-standards P-III is able to XOR more than a gigabyte of data per second - much much more than anything you put thru most file servers out there.
So, the "HW RAID is faster than SW RAID" is true in one scenario only; when you have write-intensive workloads and a HW RAID controller with battery backed cache.
In *all* other cases, SW RAID will be a win, performance wise.
For a personal file server, I wouldn't hesitate to run RAID-5 in plain software. It's as fast or faster than any HW RAID controller in the sub-$3K price range, it's reliable, and the flexibility beats the heck out of any HW based solution out there (mixing IDE/SCSI, allowing a cryptographic layer between the RAID layer and the physical disks, etc. etc...)
That is only true if you decide not to install the OS on your array.
But there's not reason not to. In fact, you just mentioned the good reason why you should in fact install on the array.
This is possible, and with some linux distros it's even easier than installing the OS outside of the array.
RTFM: http://unthought.net/Software-RAID.HOWTO/
What, you guys still have dialup ? :)
I wrote a fuzzy-logic boolean type once, where I could writethe statement would be 'true' even if a was 'not completely true' and c was 'definitely false', if only b was 'very true'. Fuzzy logic with familiar syntax. All transformed into efficient simple machine code by the wonders of the compiler internals.
Yet, even something as simple as this is not well understood by most programmers out there. I sincerely doubt that more of this transformation madness is going to solve any significant problems - what we should be worrying about, is to educate people to begin using what is already available.
Then, in a few decades when we have experience with the technologies from the last decade, let's talk about extending on that or re-doing things.
compilers, linkers, debuggers, and other tools will be plugin frameworks, rather than monolithic applications
Uh? My compiler acts as a "plugin" via. make, which is called from emacs. If I want another compiler, I tell make, and voila' it's "plugged in". Welcome to the world of 'NIX Mr. Wilson.
What is worse, every tool's command-line mini-language is different from every other's
But this is their strength! Different tools solve different problems - and they use different languages to describe what they do, because they are *fundamentally* different (awk is not sed is not grep is not ls). How would you possibly write up a single language to describe what both sed and awk does, without poorly re-creating perl?
Attempts to stick to simple on-or-off options lead to monsters like gcc, which now has so many flags that programmers are using genetic algorithms to explore them
Most CS majors will know that modern CPU architectures are complex beasts, and that it is pretty hard to come up with which combination of optimization methods will yield the best performance on some particular revision of some particular CPU on some particular hardware configuration. Nothing mysterious about that. I completely fail to see what that has to do with command line options.
And instead of squeezing their intentions through the narrow filter of command-line mini-languages, programmers can specify their desires using loops, conditionals, method calls, and all the other features of familiar languages
Instead of squeezing my intentions thru the narrow filter of command-line mini-languages, I can specify my desires using what a standard shell (like bash) has to offer. Ladies and gentlemen of the jury, this is not making sense!
The result is that today's Windows developers can write programs in Visual Basic, C++, or Python that use Visual Studio to compile and run a program, Excel to analyze its performance, and Word to check the spelling of the final report.
Oh come on, please... So if I develop on windows, I can use VB, C++ and Python. How is this relevant? There are more useful languages available on the dreaded "command line systems" ('NIX), but let's just agree that there are plenty of languages available on most OS'es out there - regardless of the windowiness or commandlineness of the system.
Using VS to compile and run the application? Well, if your command line absolutely sucks, they I can imagine why you would want to launch your app from your editor - a matter of taste too maybe. But relevant? How?
Somehow I need COM in order to put numbers into Excel? Ever heard of CSV? You know, new-line terminated lines of T-E-X-T which can be processed by these little all-different tools, like, for example, Excel.
The part about Word and spell-checking of a final report... What? What's your point? If I use COM for developing software, I can spell-check in Word? If I use a command line, I cannot spell check a report that I write about it in Word?
A similar API allows the popular memory-checking tool Purify to be used in place of Visual Studio's own debugger, and so on.
Absolutely! Plusings make perfect sense certain places. Dude - GUD is written in Emacs LISP, it's a plugin for GDB. You could write an elisp file for Purify as well - in fact, Intel actually ships an elisp file for their debugger, even on Windows... Plugins make sense some places, other places they don't. Which, lo and behold, is why they are used certain places and not others.
One of the great ironies of the early 21st Century is that the programmers who build component systems for others are strangely reluctant to componentize their own tools. Compilers and linkers are still monolithic command-line applications: files go in, files come out
Why does he not see what he's writing?!? A compiler reads a number of input files and generate an output file - this is a perfect match for a command-line too