Er, no. If you've read "The Structure of Scientific Revolutions", you'll see that 95% of all science is hidebound to their assumptions. Great leaps forward happen when enough young scientists (not bound to the previous theory, since they didn't build their career on it) find enough data that doesn't 'fit' with the current theory.
Once the weight of these new scientists is great enough, there is a violent 'paradigm shift' to a new theory that fits all the old data and all the new.
The fact is that it's much easier to get older PC's donated to the third world countries. Throw some nice/efficient apps on them, and they can rock and roll.
Spam, while annoying, is not the end of the world.
Maybe for you. But read the article. There are mail admins who receive more than a hundred spam requests per second from chinese ip addresses. That adds up to REAL money, really quickly. Adding the addresses to this database still costs bandwidth, since you have to receive all the headers before you can run your spam check.
Global blocking of the connecting IP range means you can do it from the first SYN packet.
First off, notice that I listed the 'destroy backwards compatability' last. It's the least important of my arguments. However, your 'transition period' requires a LOT of work on the maintainer's part.
Second, (and most important) I still claim that you're going to just move the complexity around, and not make anything really 'simpler'. You'll unify all the config files, but make it harder to find where you want to change something. You still have to fingure out what 'form data' (style and keywords) the app is willing and able to take. Which still involves looking up obscure syntax in the man pages. So no win comes of it.
All you've really done is unify what character is a comment.
Such an application would have a meta-data configuration file (say/etc/conf/meta/filter.cfg) which specifies: section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr . Now any application can access the packet filter's meta-data file, and the real configuration file (say/etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
and killed yourself. Making a configuration file system that can:
1) have enough 'primitives' to control network interfaces (cider and ipv4), gui's (resolution, dpi, mouse type, mousewheel), terminal types (delete char, color codes, color depth, escape codes, control flow), kernel config (pc-parallel port, IRDA-system), and ANYTHING ELSE THAT COMES ALONG will have even more complexity than the system already in place. You will need a lot of a priori knowledge to edit the file. You must know all the relevant primitives.
2) How on earth will you lay out the filesystem for this? Your example of/etc/conf/meta/filter.cfg you said would apply to SOME interfaces. So the control must go into that file for WHICH interfaces. This meta directory will end up with thousands upon thousands of files. How will you lay out network interfaces? and terminals? and gui's? (this is far easier to crack than the first though)
3) You also destroy backwards compatability. You could write 1 app per app to 'translate' the configs, but that's a huge chicken and egg problem. You also break the origional app, which has to be re-written to conform to this new, all singing, all dancing beast.
It's nice to proclaim 'unified config file format'. But the reality is that it would make life even harder than it is now. You end up just moving the complexities around.
Well, I know it's sun/solaris specific, but their Sun Blueprints line is rather nice. They're short, they go over some of the basics, and the break it down to 2 or 3 case studies using some of the top solutions for the given problem.
I have the one on Enterprise backup, and while it's not something that I'd give to someone who wanted to understand a specific product, it's great when you're doing product analysis.
In the line, there are "Datacenter Layout", "Enterprise Backup", "Boot disk layout", "Designing Enterprise Solutions with Sun Cluster 3.0", etc etc.
Or the developers of Konqueror [konqueror.org], who have equalled Mozilla with a twentieth of the personnel and a thousandth of the money.
All preferences asside, both are fantastic browsers, however, saying konq has equaled mozilla is like saying a pear has equaled an orange because they are both fruit. Konq has a goal of being a fantastic browser for kde. This it has done. Mozilla has a goal of being a fantastic CROSS-PLATFORM browser. This it has done. It's quite accurate to say that they arn't in the same league, so long as you realize the leagues you're talking about are the NBA and the NFL, for example
Read what the maintainer says on the slashdot article:
"I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go." --Michael
The -ac tree has moved on to the 2.5 world. He feels the need that -ac filled in the 2.4 world is still there, so he's doing something about it. This really isn't any more fragmentation than there was beforehand.
The -ac tree existed as a 2.4 (and 2.2 before it, and 2.0 before that) testbed (sort of a development kernel in the stable kernel code) that saw a decent bit of testing from developers. People could submit patches to Alan, and they had a much better chance of getting included. After they'd been tested for a few versions, and cleaned up some, and whatnot, the patch would go to Linus for inclusion in 2.4. Michael is offering his services to do the same job now that -ac has moved on to 2.5.
I would. Life would be much easier (not to mention cabling) if I could just have 1 bus that had:
1) plenty of bandwidth and low latency
2) the ability to move data from 2 devices within the bus swiftly and without contention
3) room for my hard disk, dvd, cdrw, and removable media (that's a VERY standard list).
And amazingly enough, the technology to do it has been around longer than IDE, and it's called SCSI. To bad the parts are so expensive...:( You can actually copy data from device c to device f on the same bus without killing your transfer speed... More than one device can talk at the same time...
You ever tried to stretch those silly, 18", ribbon cables from the lower edge of your motherboard to the top devices in your mid-tower case? Let alone a full tower...
Serial ATA looks nice, and I'll be happy when it arives, but it won't solve the problems I list above.
OpenBSD has a fantastic reputation for security. However, there are several side notes that probably pushed linux over the top.
1) LIDS. If they're using a 2.4 kernel, they can do LOTS of nice security things, like striping root of lots of it's dangerous abilities. Less danger if root is cracked. I don't know if LIDS is in use, but it probably should be.
2) Your 'better firewall and nat features, syntax' is highly debatable. As somone else pointed out, IPTables stateful inspection is far ahead of either ipfilter or pf. And your syntax comment is nothing more than a personal preference.
3) I don't like this reason much, but 'Linux' is much more widely recognised in the business world than 'OpenBSD'. When you come down to it, you have to be able to market this thing. Is this the way it should be? No. But it is, and we have to deal with it.
Unfortunatly, finding such hard data is almost imposible. I've been searching for years for data to back up claims of networking superiority from one camp or the other.
To give a short answer, *BSD's are all offshots of the historical 4.4BSDLite code, the final inheritance of Berkeley's system distribution. This is different from the SysV distribution, who's roots lie within ATT. Linux's philosophy has always been "That's a nifty idea... how can we do it?" so it is a hybred of BSD and SysV. (Free|Open|Net)BSD are 'true' BSD. Something like Solaris2 is going to be a more 'true' SysV. Some linux distributions are more BSD (like slackware) and some are more SysV (like Redhat and Debian).
The main, user visable, differences between SysV and BSD are in the flags that 'ps' takes.:-) There are a lot of differences at the syscall level, but most people don't see that. There are also significant differences in the boot procedure (one of the things that I prefer about SysV). BSD has one file (script) per runlevel. SysV has one script per service, organized in 1 directory per runlevel. Want to stop a service in sysv? '<service script> stop'.
The best thing you can do to learn more about it is to download it and give it a try yourself.
You said:
As it stands, you either write to an old standard OR to a particular UNIX. Neither is a good choice.
This isn't nearly the case, if the code IS DONE RIGHT, it can be compiled on all of the common unicies and a large portion of the uncommon ones. I've been reading Kernel Traffic's GNU/HURD report quite a bit recently, and to paraphrase one of the major package porters:
"Those packages that use autoconf/configure have been amazingly easy to port, usually needing a few lines of editing at most. Those that don't require enormous ammounts of effort."
You said:
Also is it legal? I could just see the FCC knocking on someone's door for this.
Also what about diameter, do you have to be in direct sight of it, or will it work though walls and if you are off to the left 50 feet?
The article goes into both of these:
1) the fcc only cares about signels over a certain strength. This lives comfortably below that threshold.
2) Yes, this must be line of site. Cringely went looking through three different telescopes to find someone to work with.
3. They only tuned the Linux, FreeBSD and Solaris setups -- they should have tuned Win2k server as well.
Well, that's not a fair assersion. They did exactly 1 modification to each unix kernel: Change the number of file handles. They set each of them to use 65536. IIRC, windows2k doesn't need this tweak due to it's internal way of record keeping.
The greatest problems with benchmarks is what tweaking to do. Out of box tests fail because "Any competent admin will use tweak foo", and tweaked tests fail because "tweak foo on os1 is vastly more potent than tweak bar on os3." (think the first mindcraft test).
Your RSS assersion isn't quite true either. Take oracle for example. Oracle maps a VERY large shared memory segment, to which all processes attach. If it's 20 megs, ALL oracle processes show up as 20 megs + internal process size. I've seen boxes with a gig of ram claiming that they had 3 gigs in RSS.
There is some truth to what top/ps tells you WRT memory, but it is normally useless. So I just call it a lie, so the non-unix savvy will ignore it.
It's free (libre and gratis) software.
It's multi platform (something konq will never be (and should never be)).
STOP COMPLAINING!
I've only tried it on this linux box (amd 700, 128 megs) but it seems really fast. After clicking around a good bit, it's using some ram, but significantly less than X (according to top, which is known to lie without shame, particularly with memory).
Try it. You'll like it. And if you don't, try konq, or better yet, help the developers make it (either one) better. Even if you just submit bug reports, it helps greatly.
There's a huge problem with this, since the SUN E220R can only take 2 cpu's, not the mentioned 4. Go to store.sun.com, click on servers, workgroup servers, then e220R servers, and finally choose model.
It'a also nice that they're using fiber for the long network runs.
Since you can upgrade either end, and keep the same fiber runs, and scale up the bandwidth that way, it stays somewhat ahead of the curve. Granted, that's theoretical, but it shouldn't be too far off. We don't know how to get a faster medium than fiber anyway.
Having read the article, I didn't get this at all. He is planning on forcing it for those who write modules and classes, but for the quick-n-dirty, it won't be forced.
And I imagine that once you get up to the level of project where you need to write your own modules, you probably would be using strict and -w anyway, for sanity sake if nothing else.
Actually, RMS has used many arguments for several pieces of software for LGPL'ing or BSD'ing code. The main one tends to be if there are other implementations that provide similar/identical functionality. If you are creating something totally new and innovative, he'd argue for a GPL so that ONLY free software could gain by it.
In this case, that implementation is MP3. However, your argument of Microsoft using a closed source ogg codec is a dangerous one. 'Embrace and Extend"
Fred Brooks in _The_Mythical_Man_Month_ (should be required reading for any software engineer) said "Plan to throw one away. You will anyway." However, he was only talking about the initial design/impliment phase.
The real trick is distinguishing between code 'that is bad', and code 'that I think is bad', usually because I'm not used to how it goes about solving the problem. Learning to figure out what someone else's code is doing is the best skill you can aquire early in your working life. You'll be doing it a lot.
Slashdot Mirror
Er, no. If you've read "The Structure of Scientific Revolutions", you'll see that 95% of all science is hidebound to their assumptions. Great leaps forward happen when enough young scientists (not bound to the previous theory, since they didn't build their career on it) find enough data that doesn't 'fit' with the current theory.
Once the weight of these new scientists is great enough, there is a violent 'paradigm shift' to a new theory that fits all the old data and all the new.
This is a very first world centric view point.
The fact is that it's much easier to get older PC's donated to the third world countries. Throw some nice/efficient apps on them, and they can rock and roll.
Be careful. Even though they have the same name, there is a wide difference between even a 'blade 100 and a 'blade 1000, let alone the 2000.
e tails.ht ml
See:
http://www.sun.com/desktop/sunblade2000/d
for more details.
Summary:
Sunblade 100:
USIIe chip, runs at 500mhz., up to 2 gig ram, 2x 20g HD.
Blade 1000:
1 or 2x USIII chip, runs at 750MHz or 900MHz. Up to 8 gig ram, and either 36 or 73 gig disks (1 or 2)
Blade 2000:
1 or 2x USIII chips, runs at 900MHz, or 1.05 GHz. Up to 8 gig ram, and 2x 73 gig FC-AL disks (fiber connected disks)
And that graphics card kicks butt. You can put up to two of them in a blade 1000 or 2000, letting you drive 4 displays.
Spam, while annoying, is not the end of the world.
Maybe for you. But read the article. There are mail admins who receive more than a hundred spam requests per second from chinese ip addresses. That adds up to REAL money, really quickly. Adding the addresses to this database still costs bandwidth, since you have to receive all the headers before you can run your spam check.
Global blocking of the connecting IP range means you can do it from the first SYN packet.
First off, notice that I listed the 'destroy backwards compatability' last. It's the least important of my arguments. However, your 'transition period' requires a LOT of work on the maintainer's part.
Second, (and most important) I still claim that you're going to just move the complexity around, and not make anything really 'simpler'. You'll unify all the config files, but make it harder to find where you want to change something. You still have to fingure out what 'form data' (style and keywords) the app is willing and able to take. Which still involves looking up obscure syntax in the man pages. So no win comes of it.
All you've really done is unify what character is a comment.
You said:
Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies: section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr . Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
and killed yourself. Making a configuration file system that can:
1) have enough 'primitives' to control network interfaces (cider and ipv4), gui's (resolution, dpi, mouse type, mousewheel), terminal types (delete char, color codes, color depth, escape codes, control flow), kernel config (pc-parallel port, IRDA-system), and ANYTHING ELSE THAT COMES ALONG will have even more complexity than the system already in place. You will need a lot of a priori knowledge to edit the file. You must know all the relevant primitives.
2) How on earth will you lay out the filesystem for this? Your example of /etc/conf/meta/filter.cfg you said would apply to SOME interfaces. So the control must go into that file for WHICH interfaces. This meta directory will end up with thousands upon thousands of files. How will you lay out network interfaces? and terminals? and gui's? (this is far easier to crack than the first though)
3) You also destroy backwards compatability. You could write 1 app per app to 'translate' the configs, but that's a huge chicken and egg problem. You also break the origional app, which has to be re-written to conform to this new, all singing, all dancing beast.
It's nice to proclaim 'unified config file format'. But the reality is that it would make life even harder than it is now. You end up just moving the complexities around.
Unfortunatly:
1) This is set in the 'classic' era. In the time between Episode IV and V. (before the invasion of Hoth)
2) You won't be able to kill NPC's, and any named character will be an NPC.
> How about a case study book?
Well, I know it's sun/solaris specific, but their Sun Blueprints line is rather nice. They're short, they go over some of the basics, and the break it down to 2 or 3 case studies using some of the top solutions for the given problem.
I have the one on Enterprise backup, and while it's not something that I'd give to someone who wanted to understand a specific product, it's great when you're doing product analysis.
In the line, there are "Datacenter Layout", "Enterprise Backup", "Boot disk layout", "Designing Enterprise Solutions with Sun Cluster 3.0", etc etc.
Webpage: http://www.sun.com/blueprints/
Some sample chapters are online as well.
Or the developers of Konqueror [konqueror.org], who have equalled Mozilla with a twentieth of the personnel and a thousandth of the money.
All preferences asside, both are fantastic browsers, however, saying konq has equaled mozilla is like saying a pear has equaled an orange because they are both fruit. Konq has a goal of being a fantastic browser for kde. This it has done. Mozilla has a goal of being a fantastic CROSS-PLATFORM browser. This it has done. It's quite accurate to say that they arn't in the same league, so long as you realize the leagues you're talking about are the NBA and the NFL, for example
Read what the maintainer says on the slashdot article:
"I feel that there's need for a rapidly developing '-ac [like]' tree, and so, here we go." --Michael
The -ac tree has moved on to the 2.5 world. He feels the need that -ac filled in the 2.4 world is still there, so he's doing something about it. This really isn't any more fragmentation than there was beforehand.
The -ac tree existed as a 2.4 (and 2.2 before it, and 2.0 before that) testbed (sort of a development kernel in the stable kernel code) that saw a decent bit of testing from developers. People could submit patches to Alan, and they had a much better chance of getting included. After they'd been tested for a few versions, and cleaned up some, and whatnot, the patch would go to Linus for inclusion in 2.4. Michael is offering his services to do the same job now that -ac has moved on to 2.5.
How on earth are they communicating with the probe if it is on the other side of the Sun?
Though that might be the source of the gravitational waves they are measuring... hrm...
I would. Life would be much easier (not to mention cabling) if I could just have 1 bus that had:
:( You can actually copy data from device c to device f on the same bus without killing your transfer speed... More than one device can talk at the same time...
1) plenty of bandwidth and low latency
2) the ability to move data from 2 devices within the bus swiftly and without contention
3) room for my hard disk, dvd, cdrw, and removable media (that's a VERY standard list).
And amazingly enough, the technology to do it has been around longer than IDE, and it's called SCSI. To bad the parts are so expensive...
You ever tried to stretch those silly, 18", ribbon cables from the lower edge of your motherboard to the top devices in your mid-tower case? Let alone a full tower...
Serial ATA looks nice, and I'll be happy when it arives, but it won't solve the problems I list above.
OpenBSD has a fantastic reputation for security. However, there are several side notes that probably pushed linux over the top.
1) LIDS. If they're using a 2.4 kernel, they can do LOTS of nice security things, like striping root of lots of it's dangerous abilities. Less danger if root is cracked. I don't know if LIDS is in use, but it probably should be.
2) Your 'better firewall and nat features, syntax' is highly debatable. As somone else pointed out, IPTables stateful inspection is far ahead of either ipfilter or pf. And your syntax comment is nothing more than a personal preference.
3) I don't like this reason much, but 'Linux' is much more widely recognised in the business world than 'OpenBSD'. When you come down to it, you have to be able to market this thing. Is this the way it should be? No. But it is, and we have to deal with it.
Unfortunatly, finding such hard data is almost imposible. I've been searching for years for data to back up claims of networking superiority from one camp or the other.
:-) There are a lot of differences at the syscall level, but most people don't see that. There are also significant differences in the boot procedure (one of the things that I prefer about SysV). BSD has one file (script) per runlevel. SysV has one script per service, organized in 1 directory per runlevel. Want to stop a service in sysv? '<service script> stop'.
To give a short answer, *BSD's are all offshots of the historical 4.4BSDLite code, the final inheritance of Berkeley's system distribution. This is different from the SysV distribution, who's roots lie within ATT. Linux's philosophy has always been "That's a nifty idea... how can we do it?" so it is a hybred of BSD and SysV. (Free|Open|Net)BSD are 'true' BSD. Something like Solaris2 is going to be a more 'true' SysV. Some linux distributions are more BSD (like slackware) and some are more SysV (like Redhat and Debian).
The main, user visable, differences between SysV and BSD are in the flags that 'ps' takes.
The best thing you can do to learn more about it is to download it and give it a try yourself.
You said:
As it stands, you either write to an old standard OR to a particular UNIX. Neither is a good choice.
This isn't nearly the case, if the code IS DONE RIGHT, it can be compiled on all of the common unicies and a large portion of the uncommon ones. I've been reading Kernel Traffic's GNU/HURD report quite a bit recently, and to paraphrase one of the major package porters:
"Those packages that use autoconf/configure have been amazingly easy to port, usually needing a few lines of editing at most. Those that don't require enormous ammounts of effort."
You said:
Also is it legal? I could just see the FCC knocking on someone's door for this.
Also what about diameter, do you have to be in direct sight of it, or will it work though walls and if you are off to the left 50 feet?
The article goes into both of these:
1) the fcc only cares about signels over a certain strength. This lives comfortably below that threshold.
2) Yes, this must be line of site. Cringely went looking through three different telescopes to find someone to work with.
You said:
3. They only tuned the Linux, FreeBSD and Solaris setups -- they should have tuned Win2k server as well.
Well, that's not a fair assersion. They did exactly 1 modification to each unix kernel: Change the number of file handles. They set each of them to use 65536. IIRC, windows2k doesn't need this tweak due to it's internal way of record keeping.
The greatest problems with benchmarks is what tweaking to do. Out of box tests fail because "Any competent admin will use tweak foo", and tweaked tests fail because "tweak foo on os1 is vastly more potent than tweak bar on os3." (think the first mindcraft test).
Your RSS assersion isn't quite true either. Take oracle for example. Oracle maps a VERY large shared memory segment, to which all processes attach. If it's 20 megs, ALL oracle processes show up as 20 megs + internal process size. I've seen boxes with a gig of ram claiming that they had 3 gigs in RSS.
There is some truth to what top/ps tells you WRT memory, but it is normally useless. So I just call it a lie, so the non-unix savvy will ignore it.
It's free (libre and gratis) software.
It's multi platform (something konq will never be (and should never be)).
STOP COMPLAINING!
I've only tried it on this linux box (amd 700, 128 megs) but it seems really fast. After clicking around a good bit, it's using some ram, but significantly less than X (according to top, which is known to lie without shame, particularly with memory).
Try it. You'll like it. And if you don't, try konq, or better yet, help the developers make it (either one) better. Even if you just submit bug reports, it helps greatly.
There's a huge problem with this, since the SUN E220R can only take 2 cpu's, not the mentioned 4. Go to store.sun.com, click on servers, workgroup servers, then e220R servers, and finally choose model.
It is nice to have money.
It'a also nice that they're using fiber for the long network runs.
Since you can upgrade either end, and keep the same fiber runs, and scale up the bandwidth that way, it stays somewhat ahead of the curve. Granted, that's theoretical, but it shouldn't be too far off. We don't know how to get a faster medium than fiber anyway.
Having read the article, I didn't get this at all. He is planning on forcing it for those who write modules and classes, but for the quick-n-dirty, it won't be forced.
And I imagine that once you get up to the level of project where you need to write your own modules, you probably would be using strict and -w anyway, for sanity sake if nothing else.
Actually, RMS has used many arguments for several pieces of software for LGPL'ing or BSD'ing code. The main one tends to be if there are other implementations that provide similar/identical functionality. If you are creating something totally new and innovative, he'd argue for a GPL so that ONLY free software could gain by it.
In this case, that implementation is MP3. However, your argument of Microsoft using a closed source ogg codec is a dangerous one. 'Embrace and Extend"
Quite true, however this would not be the case if you (and some others) would help him out...
:-) )
Which is one of the problems with starting student run IT, and then continuing it past the first generation.
(I'm one of those alumni admins...
Fred Brooks in _The_Mythical_Man_Month_ (should be required reading for any software engineer) said "Plan to throw one away. You will anyway." However, he was only talking about the initial design/impliment phase.
The real trick is distinguishing between code 'that is bad', and code 'that I think is bad', usually because I'm not used to how it goes about solving the problem. Learning to figure out what someone else's code is doing is the best skill you can aquire early in your working life. You'll be doing it a lot.