I don't think you quite get it. Take a look at what Objective-C does, and take a look at Common Lisp The Language, and read the section on CLOS in the appendicies.
Objective-C's ability to delegate procedures to other classes achieves a lot of the "virtual classes" concept. You can also selectively override parts of a class as he describes in virtual classes in objective-c.
The Common Lisp Object System (CLOS) and it's MetaObject Protocol (MOP) allow you to do what's described with a virtual class, and more (so much more that it's a bit intimidating to think about it).
CLOS implements object heirarchies as a list, and instead of only thinking of procedures that can be applied based on type, it has a set of rules that determines which procedure in a list (think an array of function pointers) will be applied in a given situation based on a set of rules. Sounds like C++ or Java.
The MOP, however, lets you define that behavior - you can specify that the object system will change it's behavior when you need it to.
So, it's been done and proven, but it's still "academic" from his point of view (ignoring the implementation of next/openstep, and the fact that LISP machines did do a lot of work at one point, and lisp still does stuff... it's just not mainstream. Too bad...)
Unfortunately I think you're underestimating the laziness of the american consumer. If you can make it disposable my fellow countrymen seem to go gaga over it.
I'm scared that this enormous potential waste of plastic could become popular.
I actually never played 2 - I played 1 and thought it was a much better game the doom family. But Id stayed out ahead with quake, and the rest is history.
Take a look at queso and the online OS database. Unless you actually monitor your firewall fairly closely you'll never know that you've been probed, either.
netscape 2 on an SGI is the least stable web server I've had the dubious pleasure of admin'ing. Right now the server admin is looking at a load of 666 and an equivelant number of locked netscape threads that can't be killed. The system has to reboot to be useable again.
Things like this are why SGI isn't an admin's favorite unix, and why netscape isn't a dominant server.
Ever wonder why there's an Objective-C compiler as part of gcc? It's because RMS was willing to spank Steve Jobs and the next guys for not releasing the code for it. Next wasn't willing to try and defend themselves in court, and so in the end gcc-objc became a standard part of gcc.
The FSF does chase down suspected non-compliance with the terms of the GPL, and is willing to take it to court. It's just that most companies aren't willing to try to defend a violation of the GPL in court, because it's not defensible.
Solaris' filesystem prior to the logging filesystem in 2.7 is a dog. I'd highly recommend that you benchmark your performance w/ Veritas' vxfs, or w/ solaris 7 before you buy a raid system.
Also, if you do get a RAID, I'd highly recommend a box that does not get controlled in software, i.e. Solstice DiskSuite or Veritas Volume manager (I love veritas' VM, but as a raid controller it lacks intellegence).
A good external box with hot-swappable drives and a sizeable write-back cache (w/ a battery!) is my favorite way to do this stuff.
SAN is an ill-defined acronym that everyh vendor defines differently. The idea selling SAN is that you have a large centralized storage center that offers it's disks/volumes to all connected clients w/o the hassle of administrating a disk subsystem on each server.
The problem is that each vendor implements this differently, and has a different definition of what a SAN should be. None have really addressed the complex issues, instead implementing the kind of hack you describe - NFS with a data channel over FCAL. You still have the problems of NFS to contend with (no reliable locking, consistant transactional guarantees in client and server implementations, etc.). Heck, most vendors are selling FCAL HUBS instead of SWITCHES to accomplish this storage sharing because the switches aren't prepared to do TCP/IP over fiber!
Ideally a SAN would be a well fleshed-out spec that allows massive amounts of storage to be conveniently accessed accross a network with all of the guarantees of a local disk. That's how it's being sold. However, right now it's looking like little more then a way to get NFS to run faster.
One chip to rule them all. One chip to find them. One chip to reach us all and in the darkness call us, In the land of Motorolla where travelling no longer gets you away from work.
-Peter
Re:Why do I care about 2.0?
on
Kernels Galore
·
· Score: 1
I haven't had a problem with it as a desktop or as an nfs client. As a server I haven't had crashes on 2 production servers and 1 development server under 2.2.5-22, redhat's last production patched kernel, I believe.
Also, if you read the choices next to the "preview" button when you submit a comment, you'll notice the "extrans" option. You'll like it.
Yes. PC hardware has no equivelant of, for instance, the 3x00-6x00 series of sun hardware, where you can remove processors and ram, and replace them while the system is running.
The PC world currently has no hardware that can address 16 GB of ram.
If anyone else starts doing this w/ linux, then sun will have to meet or beat the price.
IMO the real profits are always at the high end, and as long as sun and the other high-end unix vendors can make the hardware that the PC market can't match, they're the bomb.
What? freebsd doesn't exist in its own bubble. To start with, let's look at your free xBSD options and tradeoffs.
If you use freebsd, you can't run on a sparc or a sun3, or any architecture except for x86, and recently the alpha.
If you use netbsd you don't get the optimization on the intel or alpha that freebsd has, and I believe that the driver support except on those platforms is lagging. Also the number of hackers available to write drivers is far less then for freebsd.
If you use openbsd, you don't get SMP support. I don't know about drivers on other platforms, but my guess is that they and netbsd do a lot of cross-development.
Heck, if you don't use openbsd then you're constantly playing catch-up on security issues that theo and co. are keeping on top of.
Each bsd has to worry about breaking compatability with other bsds if they want to make a kernel change, or a driver interface change.
In each case you make sacrifices. If a bug is found in any of the xBSD kernels the bug then has to be cross-checked against other kernels, and coordination between groups and regression testing has to ensue. This has been pretty well done afaik, but it's still an issue that the same fix has to be applied to 3 different code bases, and regression testing done seperately (4 if you cound bsdi, which you have to pay for, but which shares code with the other 3).
This has got to be the funniest suck piece I've read in the last year!
"The fat guy down in MIS may love remote administration, but he'll end up suffering with Windows 2000 until StarOffice has that talking paper clip his users like so much."
It oversimplifies a lot of the issues (like, a lot of talented programmers getting hired by linux companies for a good wage) that people are whining about, and ignores the fact that a lot of us got the job because we got really good at linux.
In addition this tool is only good if the interface is active and has an ip address. If you're sniffing with a device that isn't bound to an address, then the "sniffer sniffer" isn't useful at all.
1) xfs and jfs are different beasts. There are, I believe, 2 jfs' also. A Journeling filesystem, I believe, usually refers to using a log for metadata only. A log-structured filesystem uses logs for both data and metadata.
2) WRT write times on a journaled files system: if you set your ext2 filesystem to running in synchronous mode, then you may be comparing apples to apples. An ext2 fs is, be defult, not synchronizing to dis, but to cache.
3) Re: fast recovery: Using a log-structured filesystem does guarantee a recovery time of less then the time needed w/o it. Because if data and metadata is written to a log and the system goes out, the OS is guaranteed to never have to evaluate more of the system status then what is contained within the log(s). As I mentioned before, JFS may only journal metadata.
4) Log-structured filesystems are extremely fast for small-file queues. Also, log-structured filesystems can easily have features built upon them like defragmentation, snapshots, resizing, etc. because there is no longer any dependancy on the physical aspects of the disk.
5) Using VxFS w/ solaris, I've never had a critical bug, and I've been able to add space to a volume used by oracle while oracle was running to add tablespace to a production database. That shit's cool. And xfs should be able to do that w/o any problems.
I believe that the GPL part of this is absolutely new. The neato part is that if this becomes an easy-to-integrate standard component, and Veritas comes out with their volume manager tools (though it would be cooler if they used the linux volume manager), then we have stock linux systems that can fail a drive, resize partitions, add disks hot (all you need is a backplane and scsi driver that lets you do this) defragment, do filesystems snapshots and other cool stuff!
Ahh! Linux as the core enterprise OS!
-Peter -Peter
Re:Huray! Now, more people use C++!!
on
GCC 2.95 Released
·
· Score: 1
AFAIK the only tool you've named that relies a lot on c++ is qt.
Yeah, this is a real filesystem issue you're running into. The time to traverse the linked list that is a directory structures is quite long when you have more then about 1024 files in a directory. The answer in the future is using a different directory structure, and in the short run is to hash things like active mail spools across multiple directories (see qmail's bigtodo patch from Russ Nelson).
FreeBSD probably would have served you better then linux in this case as well.
Question: anyone know if future filesystems will address this issue, or is this outside of the filesystem and in the kernel?
qmail uses a faster database, called cdb to do fast hashed lookups of forwarding rules. In fact, sendmail modified to use cdb files can drasticly decrease the time it takes to create alias files.
SIMS sucks, and is unnecessary and high overhead for this application. I'd chage the recommendation to using veritas filesystem and volume manager w/ a clariion (or other) array, so you get the faster filesystem (essential for mail-queue types of applications - lots of small writes and creates) and allows for live resizing of the filesystem.
Use cyrus or something else for imap. The above system, according to sun sales literature from about 1.5 years ago regarding SIMS, should support about 250 users. Plus there's no way to recover the SIMS database that I've heard of if there's corruption.
The original poster was an open source advocate. They wanted to be sure that people couldn't say that this was a notes installation or a groupwise installation that the anecdote refers to (though I've heard that these systems have their own issues).
I've mentioned this in a couple of other posts here, but since you've directly addressed the shortcoming of the standard unix mailbox format, I have to chime in that qmail's Maildir format addresses the weakness of having to read the whole mail spool, without incurring the overhead of using a remote database (development overhead, mostly, but also a lot of overhead in terms of program size and complexity).
1) syslog - for this much volume, syslog will slow your system a lot.
2) Qpopper requires a read through the entire mail file for that user each time mail is checked. For a user with a couple of megabytes of crap (think attachments) this can be a few seconds worth of activity just to get the first 5 lines of each message. Solution? Use the maildir format, which gives each message a file. Don't use MH Mail file format. Why? Because mh will do ungodly amounts of rename() calls each time the user deletes a message from the middle of their mailbox. Maildir is much more efficient.
3) Sendmail takes a lot of tuning to meet this sort of demand. Sendmail also has a large footprint. Using a mail server like qmail (my pref) or postfix (others' pref) will buy you a lot of performance for a one time learning curve of about a week's time, without having to guess at how to get high-capacity out of the system.
4) Linux is good, but unfortunately if you're going to do this on a local file system for a system with 25,000 users you need to have a lot of space. I think a Journaled (sp?) filesystem is called for here. Currently for supported tools that really means a commercial unix. I've used solaris and veritas' filesystems a lot, and I know that for a mail queue and for mail delivery veritas does amazing this. In addition, it makes recovery in the case of a system crash amazingly fast, and its snapshot facility allows you options to backup that are better then that is usually available on a mail system (i.e. minimal to no downtime to perform a backup of a stable image of the filesystem).
Anyway, hopefully I've contributed some useful thoughts to this!
Slashdot Mirror
I don't think you quite get it. Take a look at what Objective-C does, and take a look at Common Lisp The Language, and read the section on CLOS in the appendicies.
Objective-C's ability to delegate procedures to other classes achieves a lot of the "virtual classes" concept. You can also selectively override parts of a class as he describes in virtual classes in objective-c.
The Common Lisp Object System (CLOS) and it's MetaObject Protocol (MOP) allow you to do what's described with a virtual class, and more (so much more that it's a bit intimidating to think about it).
CLOS implements object heirarchies as a list, and instead of only thinking of procedures that can be applied based on type, it has a set of rules that determines which procedure in a list (think an array of function pointers) will be applied in a given situation based on a set of rules. Sounds like C++ or Java.
The MOP, however, lets you define that behavior - you can specify that the object system will change it's behavior when you need it to.
So, it's been done and proven, but it's still "academic" from his point of view (ignoring the implementation of next/openstep, and the fact that LISP machines did do a lot of work at one point, and lisp still does stuff... it's just not mainstream. Too bad...)
-Peter
Unfortunately I think you're underestimating the laziness of the american consumer. If you can make it disposable my fellow countrymen seem to go gaga over it.
I'm scared that this enormous potential waste of plastic could become popular.
-Peter
I actually never played 2 - I played 1 and thought it was a much better game the doom family. But Id stayed out ahead with quake, and the rest is history.
It's too bad bungee didn't do marathon for windows earlier. It did things that doom2 didn't, and sooner!
Real 3d, a 360 degree POV, and you could shoot the ground and watch people fly and splatter through the air!
I loved this game!
Take a look at queso and the online OS database. Unless you actually monitor your firewall fairly closely you'll never know that you've been probed, either.
http://www.apostols.org/projectz/queso/
-Peter
netscape 2 on an SGI is the least stable web server I've had the dubious pleasure of admin'ing. Right now the server admin is looking at a load of 666 and an equivelant number of locked netscape threads that can't be killed. The system has to reboot to be useable again.
Things like this are why SGI isn't an admin's favorite unix, and why netscape isn't a dominant server.
-Peter
Ever wonder why there's an Objective-C compiler as part of gcc? It's because RMS was willing to spank Steve Jobs and the next guys for not releasing the code for it. Next wasn't willing to try and defend themselves in court, and so in the end gcc-objc became a standard part of gcc.
The FSF does chase down suspected non-compliance with the terms of the GPL, and is willing to take it to court. It's just that most companies aren't willing to try to defend a violation of the GPL in court, because it's not defensible.
-Peter
Solaris' filesystem prior to the logging filesystem in 2.7 is a dog. I'd highly recommend that you benchmark your performance w/ Veritas' vxfs, or w/ solaris 7 before you buy a raid system.
Also, if you do get a RAID, I'd highly recommend a box that does not get controlled in software, i.e. Solstice DiskSuite or Veritas Volume manager (I love veritas' VM, but as a raid controller it lacks intellegence).
A good external box with hot-swappable drives and a sizeable write-back cache (w/ a battery!) is my favorite way to do this stuff.
SAN is an ill-defined acronym that everyh vendor defines differently. The idea selling SAN is that you have a large centralized storage center that offers it's disks/volumes to all connected clients w/o the hassle of administrating a disk subsystem on each server.
The problem is that each vendor implements this differently, and has a different definition of what a SAN should be. None have really addressed the complex issues, instead implementing the kind of hack you describe - NFS with a data channel over FCAL. You still have the problems of NFS to contend with (no reliable locking, consistant transactional guarantees in client and server implementations, etc.). Heck, most vendors are selling FCAL HUBS instead of SWITCHES to accomplish this storage sharing because the switches aren't prepared to do TCP/IP over fiber!
Ideally a SAN would be a well fleshed-out spec that allows massive amounts of storage to be conveniently accessed accross a network with all of the guarantees of a local disk. That's how it's being sold. However, right now it's looking like little more then a way to get NFS to run faster.
-Peter
(with apologies to Tolkein and fans)
One chip to rule them all.
One chip to find them.
One chip to reach us all
and in the darkness call us,
In the land of Motorolla where travelling no longer gets you away from work.
-Peter
I haven't had a problem with it as a desktop or as an nfs client. As a server I haven't had crashes on 2 production servers and 1 development server under 2.2.5-22, redhat's last production patched kernel, I believe.
Also, if you read the choices next to the "preview" button when you submit a comment, you'll notice the "extrans" option. You'll like it.
Yes. PC hardware has no equivelant of, for instance, the 3x00-6x00 series of sun hardware, where you can remove processors and ram, and replace them while the system is running.
The PC world currently has no hardware that can address 16 GB of ram.
If anyone else starts doing this w/ linux, then sun will have to meet or beat the price.
IMO the real profits are always at the high end, and as long as sun and the other high-end unix vendors can make the hardware that the PC market can't match, they're the bomb.
-Peter
What? freebsd doesn't exist in its own bubble. To start with, let's look at your free xBSD options and tradeoffs.
If you use freebsd, you can't run on a sparc or a sun3, or any architecture except for x86, and recently the alpha.
If you use netbsd you don't get the optimization on the intel or alpha that freebsd has, and I believe that the driver support except on those platforms is lagging. Also the number of hackers available to write drivers is far less then for freebsd.
If you use openbsd, you don't get SMP support. I don't know about drivers on other platforms, but my guess is that they and netbsd do a lot of cross-development.
Heck, if you don't use openbsd then you're constantly playing catch-up on security issues that theo and co. are keeping on top of.
Each bsd has to worry about breaking compatability with other bsds if they want to make a kernel change, or a driver interface change.
In each case you make sacrifices. If a bug is found in any of the xBSD kernels the bug then has to be cross-checked against other kernels, and coordination between groups and regression testing has to ensue. This has been pretty well done afaik, but it's still an issue that the same fix has to be applied to 3 different code bases, and regression testing done seperately (4 if you cound bsdi, which you have to pay for, but which shares code with the other 3).
-Peter
This has got to be the funniest suck piece I've read in the last year!
"The fat guy down in MIS may love remote administration, but he'll end up suffering with Windows 2000 until StarOffice has that talking paper clip his users like so much."
It oversimplifies a lot of the issues (like, a lot of talented programmers getting hired by linux companies for a good wage) that people are whining about, and ignores the fact that a lot of us got the job because we got really good at linux.
-Peter
In addition this tool is only good if the interface is active and has an ip address. If you're sniffing with a device that isn't bound to an address, then the "sniffer sniffer" isn't useful at all.
-Peter
1) xfs and jfs are different beasts. There are, I believe, 2 jfs' also. A Journeling filesystem, I believe, usually refers to using a log for metadata only. A log-structured filesystem uses logs for both data and metadata.
2) WRT write times on a journaled files system:
if you set your ext2 filesystem to running in synchronous mode, then you may be comparing apples to apples. An ext2 fs is, be defult, not synchronizing to dis, but to cache.
3) Re: fast recovery: Using a log-structured filesystem does guarantee a recovery time of less then the time needed w/o it. Because if data and metadata is written to a log and the system goes out, the OS is guaranteed to never have to evaluate more of the system status then what is contained within the log(s). As I mentioned before, JFS may only journal metadata.
4) Log-structured filesystems are extremely fast for small-file queues. Also, log-structured filesystems can easily have features built upon them like defragmentation, snapshots, resizing, etc. because there is no longer any dependancy on the physical aspects of the disk.
5) Using VxFS w/ solaris, I've never had a critical bug, and I've been able to add space to a volume used by oracle while oracle was running to add tablespace to a production database. That shit's cool. And xfs should be able to do that w/o any problems.
-Peter
I believe that the GPL part of this is absolutely new. The neato part is that if this becomes an easy-to-integrate standard component, and Veritas comes out with their volume manager tools (though it would be cooler if they used the linux volume manager), then we have stock linux systems that can fail a drive, resize partitions, add disks hot (all you need is a backplane and scsi driver that lets you do this) defragment, do filesystems snapshots and other cool stuff!
Ahh! Linux as the core enterprise OS!
-Peter
-Peter
AFAIK the only tool you've named that relies a lot on c++ is qt.
-Peter
Yeah, this is a real filesystem issue you're running into. The time to traverse the linked list that is a directory structures is quite long when you have more then about 1024 files in a directory. The answer in the future is using a different directory structure, and in the short run is to hash things like active mail spools across multiple directories (see qmail's bigtodo patch from Russ Nelson).
FreeBSD probably would have served you better then linux in this case as well.
Question: anyone know if future filesystems will address this issue, or is this outside of the filesystem and in the kernel?
-Peter
qmail uses a faster database, called cdb to do fast hashed lookups of forwarding rules. In fact, sendmail modified to use cdb files can drasticly decrease the time it takes to create alias files.
-Peter
I highly doubt that every employee at every rent-a-car location has email access or even email access.
-Peter
SIMS sucks, and is unnecessary and high overhead for this application. I'd chage the recommendation to using veritas filesystem and volume manager w/ a clariion (or other) array, so you get the faster filesystem (essential for mail-queue types of applications - lots of small writes and creates) and allows for live resizing of the filesystem.
Use cyrus or something else for imap. The above system, according to sun sales literature from about 1.5 years ago regarding SIMS, should support about 250 users. Plus there's no way to recover the SIMS database that I've heard of if there's corruption.
Good Luck!
-Peter
The original poster was an open source advocate. They wanted to be sure that people couldn't say that this was a notes installation or a groupwise installation that the anecdote refers to (though I've heard that these systems have their own issues).
-Peter
I've mentioned this in a couple of other posts here, but since you've directly addressed the shortcoming of the standard unix mailbox format, I have to chime in that qmail's Maildir format addresses the weakness of having to read the whole mail spool, without incurring the overhead of using a remote database (development overhead, mostly, but also a lot of overhead in terms of program size and complexity).
-Peter
Performance problems at the outset:
1) syslog - for this much volume, syslog will slow your system a lot.
2) Qpopper requires a read through the entire mail file for that user each time mail is checked. For a user with a couple of megabytes of crap (think attachments) this can be a few seconds worth of activity just to get the first 5 lines of each message. Solution? Use the maildir format, which gives each message a file. Don't use MH Mail file format. Why? Because mh will do ungodly amounts of rename() calls each time the user deletes a message from the middle of their mailbox. Maildir is much more efficient.
3) Sendmail takes a lot of tuning to meet this sort of demand. Sendmail also has a large footprint. Using a mail server like qmail (my pref) or postfix (others' pref) will buy you a lot of performance for a one time learning curve of about a week's time, without having to guess at how to get high-capacity out of the system.
4) Linux is good, but unfortunately if you're going to do this on a local file system for a system with 25,000 users you need to have a lot of space. I think a Journaled (sp?) filesystem is called for here. Currently for supported tools that really means a commercial unix. I've used solaris and veritas' filesystems a lot, and I know that for a mail queue and for mail delivery veritas does amazing this. In addition, it makes recovery in the case of a system crash amazingly fast, and its snapshot facility allows you options to backup that are better then that is usually available on a mail system (i.e. minimal to no downtime to perform a backup of a stable image of the filesystem).
Anyway, hopefully I've contributed some useful thoughts to this!
-Peter