Slashdot Mirror

When [Perl 6] is done and there's a Python and a Ruby port to it, you'll be able to mix and match CPAN with RubyGems with whatever the Python thing is and everybody can work together using their favorite languages.

This works today in Parrot. See Parrot Speaks Your Language.

I wonder if they need money.

We need more contributors. Money helps only if it enables people to devote more time to the project. (Money doesn't help me.)

Ext3 uses as much disk space as any other traditional filesystem, as far as I know ReiserFS is the exception to the rule as long as you don't mount it with notail since the layout it uses enables it to store many small files in a single block. Tail packing increases external fragmentation and introduces a speed hit for an, on average, 5% increase in storage copacity when compared with ext2 (And I would presume ext3 since ext3 is simply a journal on top). ReiserFS may be good at fileserving, but the fact of the matter is it's best when dealing with tons of small files a lot of the time for maximum throughput, mailservers. I have never seen anyone argue that ReiserFS is not ideal for mailservers. Ext3 mounted in writeback mode is dangerous for poorly written programs but delivers solid performance in a lot of scenarios. Guru Labs tests

In any case, for what it's worth I use ext3 in journaled mode and it performs quite fast enough for my needs and I don't see "so much disk activity" but then again I'm using the system as a desktop/wanna-server, I'm not running benchmarks on it all the time simulating rediculous scenarios. I don't trust XFS because of how it aggressively makes use of RAM and a poorly designed program runs a good chance of losing data in the event of a power outage, and JFS is great for saving CPU cycles but it's throughput and latency isn't the best, though it's probably my second favorite journalled FS after ext3. Ext3 is reliable for me and when using dir_index and journalled data mode it does alright by me in terms of performance, and I enjoy the security of having full data and metadata journalling, which AFAIK ext3 is the only one that provides.

This same question was recently asked on the local Linux User Group mailing list with lots of postive feedback of Guru Labs Linux Training.

Here is the start of the thread:

http://www.sllug.org/pipermail/sllug-members/2006- July/008043.html

I attented a class there and was very impressed by their extremely in-depth lab exercises (in many classes the labs are utter junk) and their excellent manuals. The instructors I met at Guru Labs are all extremely hard core and are contributers to many projects.

The best IT training I've ever had in 15+ years of taking a couple classes a year from various vendors.

For a quick benchmark between ext3 with different 'data' options and reiserfs you can look here

We had about 15 assorted raq, raq2's, and raq3's that were serving email, web, and some ftp sites. Since sun appeared to have no intention of putting out patches for the various vulnerabilities in both ssh and the httpd services on the boxes, we had to look at other options. Getting one of the newer cobalts wasn't appealling since a company that does this once, is just going to do it again, when they decide they don't want to support the newest.

We ended up converting all our mail off onto an Imail setup (though I think we are going to ditch that since we already have to buffer incoming and outgoing mail with frontend postfix boxes; might as well start going all out open source, but we had to do something quickly and Imail was a quick fix for us). Ie, we pretty much went with custom solutions on a mix of beefier open source boxes and M$ based systems. The hard part was doing it without the customers knowing (which pretty much involved a small cluster of stage 1 built gentoo boxes all john the rippering passwords for us).


Now, all that is minorly interesting (maybe using john to help with a smooth transition), but this gem on getting Redhat installed on a cobalt is just *asking* to be tried out on some of the spares I've got laying about.


But, our take on the whole thing was, 'better to upgrade to our own systems and sell the appliances for 100-200 a pop on ebay'.

At .3MP (640x480) it won't be replacing my 5MP Canon G5, but having it be an integrated feature is pretty cool. You can snap a picture and email to anybody within 20 seconds.

The pictures aren't bad if there is enough light. I just took these two pictures.

• Picture 1
• Picture 2

Guru Labs - High Quality Linux Training

At .3MP (640x480) it won't be replacing my 5MP Canon G5, but having it be an integrated feature is pretty cool. You can snap a picture and email to anybody within 20 seconds.

The pictures aren't bad if there is enough light. I just took these two pictures.

• Picture 1
• Picture 2

Guru Labs - High Quality Linux Training

At .3MP (640x480) it won't be replacing my 5MP Canon G5, but having it be an integrated feature is pretty cool. You can snap a picture and email to anybody within 20 seconds.

The pictures aren't bad if there is enough light. I just took these two pictures.

• Picture 1
• Picture 2

Guru Labs - High Quality Linux Training

I've since patched (only a very small change required) the 2.4 and 2.6 kernel module to support the Treo 600 and submitted the patches upstream to Linus and Marcelo. Linus said he will accept it for the 2.6.0-test8 kernel. I haven't heard back from Marcelo on the 2.4 kernel, but I'm sure it will be accepted.

With that done, kpilot works great with no changes. I had to patch gnome-pilot, to get the Treo 600 support in it however.

On my laptop, Evolution is happily syncing with my Treo 600 now. Woot!

I'm submitting the gnome-pilot patch upstream later today as well.

This phone/pda is simply amazing! Slips into my pants pocket easily and doesn't look geeky when you have it up to your face.

BTW, did you know that when you register the Treo 600 with Handspring that you can download the full version of Pocket Tunes? Pocket Tunes supports MP3 and OGG/Vorbis!!!

Slap a SD card (currenly 512MB cards are the largest made) into the Treo 600 and now you have a :

• Cell Phone
• PalmOS 5.2 PDA
• MP3/OGG Music player

Dax Kelson

Guru Labs

Red Hat Linux 9 Technical Changes (or when the RELEASE-NOTES are just not enough) by Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Intro Over the past eight years or so, I've been excited each time a new version of Red Hat Linux gets released. During the past few years, people have even been writing reviews of each release. As a general rule, I've been dissatisfied by the superficialities, inaccuracies, and irrelevancies in the reviews often times performed by someone who does not have intimate knowledge of Red Hat Linux. A systems administrator needs an in-depth review that covers relative to the previous release:

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports

Red Hat Linux 9 Technical Changes (or when the RELEASE-NOTES are just not enough) by Dax.Kelson@GuruLabs.com
Copyright 2003 Guru Labs, L.C.
Intro Over the past eight years or so, I've been excited each time a new version of Red Hat Linux gets released. During the past few years, people have even been writing reviews of each release. As a general rule, I've been dissatisfied by the superficialities, inaccuracies, and irrelevancies in the reviews often times performed by someone who does not have intimate knowledge of Red Hat Linux. A systems administrator needs an in-depth review that covers relative to the previous release:

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports ACLs and EA

• Architectural & behavioral changes
• Installer changes
• Changes to included software packages

Normally, with each new release of Red Hat Linux, someone here at Guru Labs combs through it looking for the above changes to update the Guru Labs Linux courses. This time it was my turn, and I decided to simultaneously write a technical review for the system administrators out there. I hope that the results are satisfactory.

Abbreviation notes:
RHL = Red Hat Linux
RH = Red Hat Inc.
Architectural & behavioral changes There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant. Kernel 2.4.20-8 The kernel in RHL8.0 was based on the 2.4.18 kernel. Despite the name, the RHL 2.4.20-8 kernel is based on 2.4.20 plus bug fixes identified up through 2.4.21-pre4-ac4. During the past couple years, the RHL kernels have included back ported functionality from development kernels that has proven stable. The new RHL9 kernel is no exception. Major changes since RHL8.0 include:

• Addition of Native POSIX Thread Library (NPTL) for standards based threading support with impressive performance. This is definitely a nice addition, however, I anticipate that sys admins who add patches on-top-of the RHL kernel from 3rd party (UML, FreeSWAN, etc) sources will have a more difficult time getting the patches to apply and work cleanly. Presumably when the 2.6 kernel comes out, the divergence of the RHL kernel will drop substantially.
• • Certain applications using the old LinuxThreads API in a certain manner may no longer work (was that vague enough?)
  • In particular if using Java, update to the latest version from Sun at:
  • http://java.sun.com/j2se/1.4.1/download.html
  • The WIN32 API translation software, WINE, suffers from this problem. Proper fixes are in the works, however, workarounds exist.
  • Installing and running Oracle 9i R2 has major issues since it includes two different older embedded Java JVMs that don't work with NPTL. The solution is stick with RHL8.0 or the officially supported Red Hat Linux AS edition.

ACPI support appeared in a beta (as well as in a 8.0 beta), but was removed for the final shipping kernel.

Filesystem ACL and EA support appeared in the betas, but was pulled for the final shipping kernel. I was really looking forward to ACLs and EAs support in RHL (Solaris had support since 2.5.1), maybe an errata kernel will re-add the feature.

• To see what software specifically supports ACLs and EA

I written up a close examination of Red Hat Linux 9. The review covers
three main categories:

* Architectural & behavioral changes
* Installer changes
* Changes to included software packages

This is a NOT a fluff ("the fonts are as pretty as Windows") review.
This document is meant for system administrators.

You can find the review at:

http://www.GuruLabs.com/RedHatLinux9-review.html

Comments and feedback welcome.

Dax Kelson
Guru Labs

The snags with using the "one download and spread it to all the others" are:

• You can only handle one OS release that way. Have 7.3 and 8.0 on your network ? You'll need to register 2 machines (yep, time to dig out your Webmail accounts if you're still a cheapskate) - one for 7.3 and another for 8.0.

• You need a way to "override" the Red Hat versions of some packages easily (I figured a way to do that with my script without having to hack around with the up2date config) - e.g. the infamous xmms without MP3 support RPMs in 8.0 - you want the MP3-enabled ones from Guru Labs of course.

• You need to obsolete superseded RPMs automatically in your download filestore (again, I worked that out myself).

• You need a way to distribute "local" RPMs (i.e. stuff that doesn't come with the RH CDs or with the up2date stuff, e.g. Opera, Java and so on) - I worked out how to do that as well :-) Mind you, even with multiple RHN subs, there's still no easy way to do this (RHN should allow you specify additional "local" RPMs on your filestore that are installed on all registered machines).

• If you didn't pay, you'll need a cron job to download the RHN RPMs at 4.00am or so, otherwise you probably won't get connected during the day.

My solution used an NFS directory to store the downloaded RPMs (but an rsync to local filestore on each slave machine would be equally good) and there's also some gotchas to work out (like creating soft-links in the master machine's /var/spool/up2date dir to link across each RPM there to your downloaded central copy [to fool up2date into thinking it's downloaded it already], plus remembering to do "up2date --nox --packages" on your master machine after installing the downloaded RPMs on it, so that RHN know about your updated RPM setup).

My older brother took a class direct from Red Hat, and when was looking at my Guru Labs manual, he said my manual was much better and offered to buy it off of me.

GuruLabs

-Derek

I believe someone on slashdot posted this link to the XMMS MP3 Plugin for Red Hat 8.0 a couple days ago. I guess some of ya'll aren't paying attention. :)

GO HERE

I'm one of those guys that just can't resist installing a fresh new copy of the latest version of RH the day after is is released. With all the hype surrounding 8.0, I was stoked to start running this OS. Truthfully, I was less interested in the GUI and more focused on the integration of Apache 2.0, gcc 3.2..etc. The install was quick, AND painless. BUT, the damn installer would not allow me to "deselect" the base DBMSs and install MYSQL alone unless I "selected all packages individually".

Seems ODD to me....

Other than that...the only problems I had was with my own PHP code being incompatible with the latest version of PHP 4.2.x (which also annoys me). Oh, and P.S. don't try to "dump your data" out of your old phpMyAdmin, and try to import it in to the new version. IT NADA WORK.

But I must say, RH 8.0's interface is perty. Sucks there is no MP3 support..Unless you go HERE

MP3 Support for XMMS

This RPM, created at Guru Labs, provides the two files:

* /usr/lib/xmms/Input/libmpg123.la
* /usr/lib/xmms/Input/libmpg123.so

Also provided is the SRPM from which the binary RPM was built. The SRPM is identical to the XMMS SRPM shipped with Red Hat Linux 8.0 except that it uses the pristine XMMS source (ie, has MP3 support), and the SPEC file was modified to create the xmms-mp3 sub package.

ftp://ftp.gurulabs.com/pub/gnome/updates/

1.0.40 RPM's aren't there yet, but my guess is that they will be soon.