So the packager have to do something special to generate MD5 sums? What if he forgets to do it? What if his script is not correct? RPM does this for you automatically.
Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg[...]
No. RPM's debuginfo packages are created for every package automatically. So you can have debugging symbols for just any package you want. Not only libraries. When some customer (or user) have a problem with your package, you can tell him to install the debug informations and the n to send you the output of GDB or so. The point is that you have the debugging symbols created, but not installed by default (since they take the disk space). And again, the main advantage is that RPM does this for all packages.
>No rebuilding from a taball with.spec (or what) file included
Not sure what you mean by this.
With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta.tar.gz". If this tarball contains the.spec file, the binary RPMs will be built (so you don't need to distribute a separate tar.gz and src.rpm files when you are both maintainer of the project itself and its RPM packaging).
The Debian package format provides all the stuff you list as being specific to RPM
Last time I have checked DEB packages weren't GPG signed and did not contain MD5 sums of every file in the package (altough I think I have heard that the package format supports this; it is just not widely used in Debian distro). There were no debuginfo packages. No rebuilding from a taball with.spec (or what) file included. No triggers.
Are you really sure everything I have mentioned is really in Debian/dpkg too?
I can throw some more features in, when I remember - e.g. what about the "Nosource" directive (i.e. make the.src.rpm without including the source tarball itself, maybe for licensing reasons)?
RPM has {pre,post}{inst,un} scripts, which are called when the package is installed/upgraded/removed. Triggers for a package is a script which is called when some other package is installed/upgraded/removed. Think adding your daemon to some startup script of another package.
Just FWIW, RPM has "conflicts" (with anything you want), "replaces" (obsoletes), "provides", "--simulate" (--test, actually). Source selection, automatic dependency satisfying, dist-upgrade, and probably others belong to a higher level than the package manager itself (yum, apt, up2date). The "recommends", "suggests" , and install-time config are deliberately missing, because RPMs are meant to be installable without an user attention.
RPM has triggers (script executed when other package gets installed/upgraded), %verify script, %changelog, automatically generated debuginfo packages, etc. Every file is MD5summed, package has MD5 sum, RPM supports GPG signature (and this feature is actively used by distros).
RPM has better source rebuild than DEB. It supports conditional compile (%ifarch, %if, etc.), so you can rebuild RPMs for several versions of a distro from one source package. It has a "BuildPrereq" dependencies. You can have more than one source file and more than one patch file, RPM makes sure you are compiling exactly along the lines written in the.spec file (so you actually get working and rebuildable source RPM, no manual editing/hacks behind the RPM's back). The build process automatically uses a subdirectory for installing files (so non-root rebuilds are possible). It warns you when you forget to package some file from the build root. You can even use a tarball instead of the source RPM, provided that the tarball contains the.spec file.
There is still one problem with using RPM: distro-specific macros. Last time I have checked, Mandrake uses %make macro, so you cannot take MDK source RPM and --rebuild it on Fedora, because you get "%make undefined" error.
DEC's contribution was at most a technical contribution to a narrow part of the system. I do not find this comparable to the FSF contribution. [...] While the Linux kernel may be substitutable, I have never found the GPL, GNU utilities and other things as substitutable.
Yes, DEC's contribution is probably smaller. But: GNU project is far away from providing a complete system (no web browser, ssh server, init, windowing interface, RDBMS, desktop [yes, GNOME is far from a complete desktop]). So I do not buy an argument that GNU project provides complete system. This project provided a significant part of the system I use (and the licenses for even bigger part of my system), but I think it is still not enough to name the whole thing (including X11-licensed x.org, dual-licensed Perl, MPL-licensed Gecko, etc) GNU/Linux.
As for the second sentence I have quoted, I agree that GPL is very important contribution of FSF and is not substituable (except the dangerous "or (at your option) any later version" clause, which I deleted from GPL text for every software I wrote). However, I think all of the other GNU work is substituable - just look at *BSD - the only part of the GNU project they use is GCC compiler. And even that can be replaced (but GCC is still superior, which is the reason they use it, not because of its license). And as I said before, the credits for the current state of GCC does not go to FSF, but to the egcs team.
Back to the "GNU/Linux" debate: I used to live in a communist regime (which is hopefully gone forever now). Because of that I surely value every single freedom I have (including the freedom of using, modifying and distributing the GPL-licensed software). I just hope the freedom of naming the system I use as I want and the freedom of choosing the license of my code as I want are among those freedoms. I got very nervous when somebody tries to order me what names should I use or generally how should I speak/what should I think.
His desire to attach the GNU name is, again, the desire to teach about the free software nature of some basic building blocks there, which he consideres the most significant aspect of the software.
I do not deny big RMS and FSF contributions to GCC, glibc, and of course the GPL. Yes, they get (part of) the ball rolling. But this does not justify their requests to use the term "GNU/Linux". DEC's (and X Consortium) contribution was of the same magnitude, because without the good graphical interface Linux (and any of *BSDs) would be nowhere near the current state. Yet they do not demand the term "xc/Linux" should be used.
If they recognize the changes as good and accept them back into their code base, that is their right, and that is how free software projects work.
In fact this is precisely the way Open source projects work. I.e. judging the code by its quality instead of some "political" reasons.
Do not get me wrong - I consider freedoms I have from using (and writing) the GPL-licensed code to be very valuable. Let me repeat that: I agree that without RMS (and FSF) we would be nowhere near the current state. But this is about as true for RMS/FSF/GNU as is for Linus Torvalds, Alan Cox et al./Linux, Jim Gettys et al./DEC/X Consortium, */Apache project, and many others (Ken Thompson and Dennis Ritchie did not contribute much of the code for my system, but they created an excellent API and design; the same for Internet protocol authors, and so on). But nobody except RMS does request that I use the term their project name/Linux. And, unfortunately, the present FSF efforts with respect to GCC and glibc looks less than nice to me.
Currently I can switch the kernel I use for something else (*BSD, may be even HURD) the same way as I can switch my glibc (to dietlibc, for example), and GCC (to Intel CC or lcc). I use Linux, GCC, glibc, Perl, xorg/X11, etc., because they best fit my needs. GNU project is nothing special in this.
As I wrote in the comment to another KernelTrap story, using the term "GNU/Linux" (referring to the GCC and glibc essential role in the system) is totally misleading.
Both GCC and glibc are in the current state despite the RMS and FSF efforts. For GCC, remember the situation from the 2.8 times, when an independent team (egcs) had to fork GCC, because the FSF-managed development of GCC was dead. In the same way remember years of work that H.J.Lu invested in Linux libc, because GNU libc was unmaintained and unusable. And of course the work of Ulrich Drepper, who took GNU libc2 and developed it into a form usable in Linux-based system. Ulrich considers none of his work on glibc to be a part of a GNU project (details here, see the bottom part of the text).
And it looks like even the present situation in the GCC development is the same (anonymous comment at KernelTrap).
So I can say run GCC/glibc/perl/X.org/TeX/etc/Linux system, but it has nothing special to do with GNU and FSF, and I just prefer the short name "Linux" (named after a single biggest, always-running, and essential component of the system).
... which is pretty much what everyone but IBM and Fujitsu do.
I don't know about IBM, but I used to have a Fujitsu-Siemens Lifebook C1020, and I've once met a guy with exactly same laptop from Acer - the configuration was the same, case was the same (altough Acer was black while my C1020 was grey), the connectors were at the same place, etc. I did not disassemble it, though. So think even Fujitsu-Siemens uses some external sources for manufacturing laptops.
My home directory varies on different hosts, but I usually have the ~/tmp subdir for all the thrash (untarred packages of software, temporary scripts, etc). Then there is ~/public_html with my home page, and ~/bin (added to my $PATH) with various scripts and locally installed programs. On most hosts I also have ~/tex, ~/txt, ~/audio and ~/video subdirs as well. My primary mail host has ~/Mail with inboxes subdir. That's all (and bits of random crap here and there).
Now the server is somewhere near saturation, but still not maxed out: 440 FTP users, 350-400Mbit/s outgoing traffic, load average around 15-20. Server statistics are here. The server is 2x Opteron 244, Tyan S2882, 4GB RAM, 4x 120GB and 4x 180GB HDD (to be upgraded to 8x 250GB soon).
The usual (non-release-day) load is 30-100Mbit/s, ~150 FTP users.
Usually the first day downloaders have faster lines, so the second or third day the server might be fully loaded even at lower outgoing speed, because the read-ahead will not matter anymore.
If you are in Europe and looking for a fast mirror, try this one (i386; x86_64 is here). 80 minutes after the release and my bandwidth and HDD speed is still not maxed out...
Random access speed will be improved (provided that you are not doing serialized random access, i.e. you run more processes reading data, not a single process; see my other note on sinlge process usage).
The warranty depends on where you live. I've just ordered two 400GB ATA Hitachi drives with 3 years warranty. And most servers are due to upgrade after 3 years anyway. In EU you cannot have less than 2 years warranty anyway (not counting things like food, etc.).
it makes far more sense to put in 15 73gbyte3 SCSI drives (10K RPM, 15K RPM) than it does to use 4 300 GB IDE drives (7.2K RPM).
Wrong. You can easily get 30 300GB 7.2kRPM drives for the same or lower price than 15 73GB 15kRPM SCSI drives. Now run the IDE/SATA drives in RAID 1+0 configuration (versus RAID-0 over SCSI drives), and you get:
2x the avaliable storage capacity even with RAID 1+0
fault-tolerace because of RAID 1+0 in IDE/SATA setup
about the same power consumption (15kRPM drives are power hungry)
a bit better total read/write speed (7.2kRPM IDE/SATA do about 45MB/s, 15kRPM SCSI about 80MB/s).
worse single-process read/write speed (but hey, do you buy some 9 TB of storage for one process only?).
about the same random access speed (7.2kRPM drives have the access time almost twice as big as good 15kRPM drives, but you have 30 heads instead of 15).
Most of the above holds even for 15x 300GB 7.2kRPM in RAID 1+0 versus 15x 73GB 15kRPM drives raw, if you are limited by the space or power outlets.
know I can run software RAID across the disks, but I'm still more comfortable with h/w solutions - I've tried s/w raid (and it has failed, bigtime) in the past, and getting past the psychological barrier to try it again is hard
Actually, Linux software RAID is way faster than any commodity HW RAID solution I have seen so far. It is because Linux can use all RAM for cache and can do RAID checksums almost at the speed of available RAM (around 6 GB/s). Your typical fileserver has the CPU idle all the time (with good enough disc controller and ethernet interface), so why not waste extra CPU cycles doing RAID checksums.
The only problem is that the data go over the bus more times (4 times in case of RAID-5 write), but your drives usually cannot saturate a 32bit/33MHz PCI bus for random access at all, so with 64/66 or 64/100 controller this is not a problem.
I have 3ware 7506-8 controller (8x P-ATA), and I have measured that the writes can be ~30% faster over SW RAID-5 across 8 disks than the HW RAID-5 case. This is because of faster CPU and bigger cache (=RAM) - so the elevator can do better work for random access writes. The test server was dual Athlon MP-2000+, but even with this test the CPUs were almost idle (
But, do I want to continue to self-organize my data? Hell, no! There's just too much information stored on my computer, and on my network, these days. And, considering that much of my data has multiple relationships, the hierarchical model is growing a bit long in the tooth. Many of my documents belong in multiple hierarchies.
That's why God^WKen Thompson gave us hardlinks (and symlinks too).
For instance, the Itanium (with a bit of help from SGI) can scale into the hundreads of processors and still be able to run a single kernel image. Right now, that isn't exactly doable with the Opteron.
This (SGI Altixes) is not a feature of Itanium, but rather of the proprietary S-HUB chips and NUMAlink. Opteron can scale easily as well, provided that you accompany it with a right chipset (as opposed to 1-4 CPU Opteron boxes which can live without an external northbridge).
Just take alook at Cray XD-1 - they are doing the same for Opterons as SGI does for Itaniums.
Nonetheless, Itanium2 still has a FP performance superior to Opteron.
I live in a country where there is no RIAA or MPAA, and where you can download anything you want (fair use). You of course cannot distribute (i.e. upload or share) anything copyrighted, if you do not have license explicitly permitting you to distribute this material.
And when the wireless client is behind the firewall which permits HTTP only and does N:1 NAT (masquerade), it is difficult to share any illegal content.
I have intentionally left WEP off on my AP at home. I use ssh or https for anything sensitive, but I want my visitors to be able to connect via my home network without sophisticated configuration on their side (and of course, without telling them my WEP password).
My home network is connected via Linux firewall, so I can cut the access or install traffic shaping when the problem occurs.
Do not use 3ware 7506 with tyan boards - they are not compatible (details at http://www.3ware.com/KB/article.aspx?id=10964).
I have two Tyan S2882 (K8Spro)-based computers, and the 3ware 7506-8 works only in slot 3 (PCI-X bus A, IIRC), thus degrading the whole bus A (including two on-board gigabit NICs) to the 66MHz. After ordering a 3ware-recommended riser card it works in PCI-X bus B, and now I have 3ware board on one bus and two gigabit NICs on the other one, running at 100MHz.
Be sure to check Tyan and 3ware compatibility lists.
Other than that, 3ware is a great board, just make sure you run a Linux software RAID on top of it - it is faster (with more of RAM you can do more optimizations than the 3ware CPU wit 32MB of RAM).
And if you want an Opteron box, Tyan Thunders are excellent choice (their BIOS can even be managed via serial line!). Not sure about workstation use, though:-)
You cannot order the bigger L2 cache (Itanium2 can have 6MB).
For "randomly branched" code you need as short pipeline as possible. This is the reason Athlon outperformed PentiumIV at the same clock speed. Now Itanium2 has 6-stage pipeline, while Opteron has 20-stage, IIRC.
OTOH, for full performance you need _much_ finely-tuned compiler for VLIW CPUs such as Itanium2 than for a generic CISC or RISC CPU.
I use Jabber client on PalmOS without problems. There are at least two clients, one of which is open source. The specification of the protocol is open, and the system is distributed. Why use AIM or ICQ, when there is Jabber?:-)
And has SysV or any version of UnixWare / OpenUnix had a NUMA implementation?
Of course no, but I think in this case SCO is referring to the Project Monterrey, which was an attempt to build UNIX for the ia64 platform. Both IBM and SCO participated in this project, and nobody
knows what their legal agreements concerning this project were. So SCO actually may have some valid argument against IBM (but not against Linux, of course).
Slashdot Mirror
So the packager have to do something special to generate MD5 sums? What if he forgets to do it? What if his script is not correct? RPM does this for you automatically.
Packages with debugging symbols? There are plenty; look for, eg, libc6-dbg[...]
No. RPM's debuginfo packages are created for every package automatically. So you can have debugging symbols for just any package you want. Not only libraries. When some customer (or user) have a problem with your package, you can tell him to install the debug informations and the n to send you the output of GDB or so. The point is that you have the debugging symbols created, but not installed by default (since they take the disk space). And again, the main advantage is that RPM does this for all packages.
>No rebuilding from a taball with .spec (or what) file included
Not sure what you mean by this.
With RPM, you can download the tar.gz file from the upstream site, and run "rpmbuild -ta .tar.gz". If this tarball contains the .spec file, the binary RPMs will be built (so you don't need to distribute a separate tar.gz and src.rpm files when you are both maintainer of the project itself and its RPM packaging).
Last time I have checked DEB packages weren't GPG signed and did not contain MD5 sums of every file in the package (altough I think I have heard that the package format supports this; it is just not widely used in Debian distro). There were no debuginfo packages. No rebuilding from a taball with .spec (or what) file included. No triggers.
Are you really sure everything I have mentioned is really in Debian/dpkg too?
I can throw some more features in, when I remember - e.g. what about the "Nosource" directive (i.e. make the .src.rpm without including the source tarball itself, maybe for licensing reasons)?
RPM has {pre,post}{inst,un} scripts, which are called when the package is installed/upgraded/removed. Triggers for a package is a script which is called when some other package is installed/upgraded/removed. Think adding your daemon to some startup script of another package.
RPM has triggers (script executed when other package gets installed/upgraded), %verify script, %changelog, automatically generated debuginfo packages, etc. Every file is MD5summed, package has MD5 sum, RPM supports GPG signature (and this feature is actively used by distros).
RPM has better source rebuild than DEB. It supports conditional compile (%ifarch, %if, etc.), so you can rebuild RPMs for several versions of a distro from one source package. It has a "BuildPrereq" dependencies. You can have more than one source file and more than one patch file, RPM makes sure you are compiling exactly along the lines written in the .spec file (so you actually get working and rebuildable source RPM, no manual editing/hacks behind the RPM's back). The build process automatically uses a subdirectory for installing files (so non-root rebuilds are possible). It warns you when you forget to package some file from the build root. You can even use a tarball instead of the source RPM, provided that the tarball contains the .spec file.
There is still one problem with using RPM: distro-specific macros. Last time I have checked, Mandrake uses %make macro, so you cannot take MDK source RPM and --rebuild it on Fedora, because you get "%make undefined" error.
Yes, DEC's contribution is probably smaller. But: GNU project is far away from providing a complete system (no web browser, ssh server, init, windowing interface, RDBMS, desktop [yes, GNOME is far from a complete desktop]). So I do not buy an argument that GNU project provides complete system. This project provided a significant part of the system I use (and the licenses for even bigger part of my system), but I think it is still not enough to name the whole thing (including X11-licensed x.org, dual-licensed Perl, MPL-licensed Gecko, etc) GNU/Linux.
As for the second sentence I have quoted, I agree that GPL is very important contribution of FSF and is not substituable (except the dangerous "or (at your option) any later version" clause, which I deleted from GPL text for every software I wrote). However, I think all of the other GNU work is substituable - just look at *BSD - the only part of the GNU project they use is GCC compiler. And even that can be replaced (but GCC is still superior, which is the reason they use it, not because of its license). And as I said before, the credits for the current state of GCC does not go to FSF, but to the egcs team.
Back to the "GNU/Linux" debate: I used to live in a communist regime (which is hopefully gone forever now). Because of that I surely value every single freedom I have (including the freedom of using, modifying and distributing the GPL-licensed software). I just hope the freedom of naming the system I use as I want and the freedom of choosing the license of my code as I want are among those freedoms. I got very nervous when somebody tries to order me what names should I use or generally how should I speak/what should I think.
I do not deny big RMS and FSF contributions to GCC, glibc, and of course the GPL. Yes, they get (part of) the ball rolling. But this does not justify their requests to use the term "GNU/Linux". DEC's (and X Consortium) contribution was of the same magnitude, because without the good graphical interface Linux (and any of *BSDs) would be nowhere near the current state. Yet they do not demand the term "xc/Linux" should be used.
If they recognize the changes as good and accept them back into their code base, that is their right, and that is how free software projects work.
In fact this is precisely the way Open source projects work. I.e. judging the code by its quality instead of some "political" reasons.
Do not get me wrong - I consider freedoms I have from using (and writing) the GPL-licensed code to be very valuable. Let me repeat that: I agree that without RMS (and FSF) we would be nowhere near the current state. But this is about as true for RMS/FSF/GNU as is for Linus Torvalds, Alan Cox et al./Linux, Jim Gettys et al./DEC/X Consortium, */Apache project, and many others (Ken Thompson and Dennis Ritchie did not contribute much of the code for my system, but they created an excellent API and design; the same for Internet protocol authors, and so on). But nobody except RMS does request that I use the term their project name/Linux. And, unfortunately, the present FSF efforts with respect to GCC and glibc looks less than nice to me.
Currently I can switch the kernel I use for something else (*BSD, may be even HURD) the same way as I can switch my glibc (to dietlibc, for example), and GCC (to Intel CC or lcc). I use Linux, GCC, glibc, Perl, xorg/X11, etc., because they best fit my needs. GNU project is nothing special in this.
Do not confuse the words "part of glibc" with "part of the GNU project".
As I wrote in the comment to another KernelTrap story, using the term "GNU/Linux" (referring to the GCC and glibc essential role in the system) is totally misleading.
Both GCC and glibc are in the current state despite the RMS and FSF efforts. For GCC, remember the situation from the 2.8 times, when an independent team (egcs) had to fork GCC, because the FSF-managed development of GCC was dead. In the same way remember years of work that H.J.Lu invested in Linux libc, because GNU libc was unmaintained and unusable. And of course the work of Ulrich Drepper, who took GNU libc2 and developed it into a form usable in Linux-based system. Ulrich considers none of his work on glibc to be a part of a GNU project (details here, see the bottom part of the text). And it looks like even the present situation in the GCC development is the same (anonymous comment at KernelTrap).
So I can say run GCC/glibc/perl/X.org/TeX/etc/Linux system, but it has nothing special to do with GNU and FSF, and I just prefer the short name "Linux" (named after a single biggest, always-running, and essential component of the system).
I don't know about IBM, but I used to have a Fujitsu-Siemens Lifebook C1020, and I've once met a guy with exactly same laptop from Acer - the configuration was the same, case was the same (altough Acer was black while my C1020 was grey), the connectors were at the same place, etc. I did not disassemble it, though. So think even Fujitsu-Siemens uses some external sources for manufacturing laptops.
My home directory varies on different hosts, but I usually have the ~/tmp subdir for all the thrash (untarred packages of software, temporary scripts, etc). Then there is ~/public_html with my home page, and ~/bin (added to my $PATH) with various scripts and locally installed programs. On most hosts I also have ~/tex, ~/txt, ~/audio and ~/video subdirs as well. My primary mail host has ~/Mail with inboxes subdir. That's all (and bits of random crap here and there).
350-400Mbit/s outgoing traffic, load average around 15-20. Server statistics are here. The server is 2x Opteron 244, Tyan S2882, 4GB RAM, 4x 120GB and 4x 180GB HDD (to be upgraded to 8x 250GB soon).
The usual (non-release-day) load is 30-100Mbit/s, ~150 FTP users.
Usually the first day downloaders have faster lines, so the second or third day the server might be fully loaded even at lower outgoing speed, because the read-ahead will not matter anymore.
If you are in Europe and looking for a fast mirror, try this one (i386; x86_64 is here).
80 minutes after the release and my bandwidth and HDD speed is still not maxed out
(IAAAOTS - I am an administrator of this server).
The warranty depends on where you live. I've just ordered two 400GB ATA Hitachi drives with 3 years warranty. And most servers are due to upgrade after 3 years anyway. In EU you cannot have less than 2 years warranty anyway (not counting things like food, etc.).
Wrong. You can easily get 30 300GB 7.2kRPM drives for the same or lower price than 15 73GB 15kRPM SCSI drives. Now run the IDE/SATA drives in RAID 1+0 configuration (versus RAID-0 over SCSI drives), and you get:
- 2x the avaliable storage capacity even with RAID 1+0
- fault-tolerace because of RAID 1+0 in IDE/SATA setup
- about the same power consumption (15kRPM drives are power hungry)
- a bit better total read/write speed (7.2kRPM IDE/SATA do about 45MB/s, 15kRPM SCSI about 80MB/s).
- worse single-process read/write speed (but hey, do you buy some 9 TB of storage for one process only?).
- about the same random access speed (7.2kRPM drives have the access time almost twice as big as good 15kRPM drives, but you have 30 heads instead of 15).
Most of the above holds even for 15x 300GB 7.2kRPM in RAID 1+0 versus 15x 73GB 15kRPM drives raw, if you are limited by the space or power outlets.Actually, Linux software RAID is way faster than any commodity HW RAID solution I have seen so far. It is because Linux can use all RAM for cache and can do RAID checksums almost at the speed of available RAM (around 6 GB/s). Your typical fileserver has the CPU idle all the time (with good enough disc controller and ethernet interface), so why not waste extra CPU cycles doing RAID checksums. The only problem is that the data go over the bus more times (4 times in case of RAID-5 write), but your drives usually cannot saturate a 32bit/33MHz PCI bus for random access at all, so with 64/66 or 64/100 controller this is not a problem.
I have 3ware 7506-8 controller (8x P-ATA), and I have measured that the writes can be ~30% faster over SW RAID-5 across 8 disks than the HW RAID-5 case. This is because of faster CPU and bigger cache (=RAM) - so the elevator can do better work for random access writes. The test server was dual Athlon MP-2000+, but even with this test the CPUs were almost idle (
That's why God^WKen Thompson gave us hardlinks (and symlinks too).
This (SGI Altixes) is not a feature of Itanium, but rather of the proprietary S-HUB chips and NUMAlink. Opteron can scale easily as well, provided that you accompany it with a right chipset (as opposed to 1-4 CPU Opteron boxes which can live without an external northbridge).
Just take alook at Cray XD-1 - they are doing the same for Opterons as SGI does for Itaniums.
Nonetheless, Itanium2 still has a FP performance superior to Opteron.
And when the wireless client is behind the firewall which permits HTTP only and does N:1 NAT (masquerade), it is difficult to share any illegal content.
I have intentionally left WEP off on my AP at home. I use ssh or https for anything sensitive, but I want my visitors to be able to connect via my home
network without sophisticated configuration on their side (and of course, without telling them my WEP password).
My home network is connected via Linux firewall, so I can cut the access or install traffic shaping when the problem occurs.
Do not use 3ware 7506 with tyan boards - they are not compatible (details at http://www.3ware.com/KB/article.aspx?id=10964).
:-)
I have two Tyan S2882 (K8Spro)-based computers, and the 3ware 7506-8 works only in slot 3 (PCI-X bus A, IIRC), thus degrading the whole bus A (including two on-board gigabit NICs) to the 66MHz. After ordering a 3ware-recommended riser card it works in PCI-X bus B, and now I have 3ware board on one bus and two gigabit NICs on the other one, running at 100MHz.
Be sure to check Tyan and 3ware compatibility lists.
Other than that, 3ware is a great board, just make sure you run a Linux software RAID on top of it - it is faster (with more of RAM you can do more optimizations than the 3ware CPU wit 32MB of RAM).
And if you want an Opteron box, Tyan Thunders are excellent choice (their BIOS can even be managed via serial line!). Not sure about workstation use, though
-Yenya
- You cannot order the bigger L2 cache (Itanium2 can have 6MB).
- For "randomly branched" code you need as short pipeline as possible. This is the reason Athlon outperformed PentiumIV at the same clock speed. Now Itanium2 has 6-stage pipeline, while Opteron has 20-stage, IIRC.
OTOH, for full performance you need _much_ finely-tuned compiler for VLIW CPUs such as Itanium2 than for a generic CISC or RISC CPU.I use Jabber client on PalmOS without problems. There are at least two clients, one of which is open source. The specification of the protocol is open, and the system is distributed. Why use AIM or ICQ, when there is Jabber? :-)
Hope this helps,
Of course no, but I think in this case SCO is referring to the Project Monterrey, which was an attempt to build UNIX for the ia64 platform. Both IBM and SCO participated in this project, and nobody knows what their legal agreements concerning this project were. So SCO actually may have some valid argument against IBM (but not against Linux, of course).