BlueWhite64 - The Distro and its Creator
Bluewhite64 is a port of the world famous Slackware Linux distribution built and optimized for the x86_64 architecture. When I first heard of bluewhite64 I was quite anxious to test it. With the release of pre-11.0-beta on July 3rd and the recent communication with lead developer Attila Craciun, this seemed like the perfect time.
I said "lead developer" in my introduction, but actually "only developer" would have been more accurate. As a one-man-team, Arny has managed to port if not all, then almost the full Slackware distro to the 64-bit arch in a matter of months. Less than two months to be more exact as the process began on May 22. Arny, as he is known, states, "I spent 3 days reading documentations about how to port on 64-bit architecture and on 25 May I compiled the first package."
Now today, not even two months later, we have a complete 64-bit system consisting of the Linux 2.6.16.22 kernel with support for IDE, SATA, SCSI and RAID controller, gcc 3.4.6, Xorg 6.9.0, KDE 3.5.3 and XFce 4.2.3.2.
Cracuin's original project was an easy email server installer named qinstall. His site states, "qinstall is a precompiled packages collection along with a powerful installer for Slackware Linux. It helps administrators to install and run an out-of-the box powerful, secure, scalable and reliable e-mail server, along with all the programs required to run properly.The final result being a functional feature rich e-mail server in 2 minutes !" This laid the ground work and furthered his experience with Slackware.
Romanian born and bred, Arny is a 29-year-old resident of the mountainous Baia Mare, located in the north-west of Romania about 500 kms from Bucuresti, where he splits his time now between working full-time on BlueWhite64 and his long-term girlfriend. Arny states he started this port because of his long-time use and love of Slackware and felt it needed a 64-bit port.
I was curious as to the origins of this distro's unique naming convention. From where did that name come I asked? Arny stated, "Since Slackware is in black and white, why not a blue and white distro ?
The slackware Logo http://www.slackware.com/~msimons/slackware/grfx/shared/bluepiSW.jpg is blue and have some white but the official Slackware CD`s have blue and white colors .. so from there is come
"
How does Patrick feel about your project?
Arny quotes Mr. Volkerding as saying,
I'm glad to see efforts are going towards Slackware-like work on x86-64 since it's something I'd like to work on eventually myself, and when the time for this comes the more pre-qualified helpers there are out there the easier the official port will be.
Please respect this one instruction, which is that Slackware is a trademark that I've put a great deal of effort into establishing (hopefully) goodwill for, and recognition of. Unless given explicit permission from me, please do not use "Slackware" in the name of your project or in a registered domain name; and I would also prefer that you not use "Slack" either (or close sound-alikes), as it is so strongly associated with Slackware that many people say "Slack" or "Slack Linux" and it is generally understood what they are referring to. Sort of like the "Crappy Tires" up in Canada.
My primary concern here is that people don't mistakenly believe that a fork or an unofficial port is officially sanctioned by the Slackware Project, or is Slackware, if it is not. As the information included with Slackware says, once you change any part of it on your own then the derivative OS is no longer officially "Slackware".
Beyond that, do as you like and try to have fun doing it. If the work is done well, I hope I'll be able to merge some of it in back here later on.
With Patrick's greenlight, the stage was set. BlueWhite64 was born, and betas released. Announcements were made, and the news circulated around the net. There was quite a bit of attention paid to the initial beta release and tuxmachines is very proud to present our results of testing BlueWhite64 Linux pre-11.0-beta.
As stated, pre-11.0-beta was available at the time of our testing and downloading was swift. md5sums checked out and the install went well. The installer is the exact same installer found in Slackware as far as I can see. There may have been some differences in the available packages, but otherwise it contained the same steps presented in the familiar Slackware installer. It does stop during package install and ask for the 2nd cd, then precedes.
First boot went like clockwork as well. The only errors listed were insignificant or concerning extraneous aspects, such as chown /proc/usb/001/002 fails because it didn't exist. I say insignificant because the usb peripherals worked fine. An xorg configuration file is present, if a bit on the conservative side, and a "startx" brings up the KDE 3.5.3 desktop (if chosen as default during install).
The KDE 3.5.3 desktop is a complete but default environment. It sits in xorg 6.9.0 and comes with gcc 3.4.6 and all the KDE applications available from the KDE developers. They are listed as per usual in KDE structured menus. Every application tested seemed to function as designed here except krita that was listed in the menu but would not open. Kooka did fine with my detected and autoconfigured scanner. Also among the full compliment of Kapps is The GIMP.
Arny informed me of a kernel bug that affects sound and nvidia driver installation, and suggested a kernel upgrade if those were desired. For my tests, I did indeed want sound. So, I headed on over to kernel.org, downloaded linux-2.6.17.2, and built it using Bluewhite's configuration file as a starting point. Not present (or overlooked on my part) in /usr/src/linux-2.6.16.22, but found as /boot/config-generic-2.6.16.22. cp /boot/config-generic-2.6.16.22 /usr/src/linux-2.6.17.2/.config and then make menuconfig. One could probably skip the menuconfig and just do a make oldconfig if they didn't wish to take out a lot of the support developers include for a wider user-base. Kernel configurations can be a bit scary to a new user, but as you go through the menus, you know your sound card or graphics chip. My advice in this case to new users is to not mess with the filesystems, net stuff, block devices, or anything that sounds greek to you. But there's no reason you can uncheck all the hardware you know you don't have. After the configuration (menuconfig), just type make. Next, type make modules_install. The next step might require some thought, but most people can just type make install and boot their new kernel.
At that point I had working sound and not only did arts stop complaining, but my multimedia applications blared to life. BlueWhite64 comes with Juk, Amarok, and KsCD for your musical inclinations as well as gxine, noatun, and kaboodle for your viewing pleasure. It also has KAudioCreator for cdripping. I had no trouble with audio cds, avis, or mpegs.
Browsing can be handled through Seamonkey 1.0.2, Firefox 1.5.0.4, or Konqueror 3.5.3. Also included, but perhaps not seen in the menu are lynx and links. The browsers function really well and the fonts look good, but there is no flash or java included. Other net apps include gaim, Pan, Thunderbird, NmapFE, gFTP, and XChat.
Office applications are handled in the most part by Koffice.
If KDE is not your favorite, you also have the choice of xfce4 4.2.3.2. Like KDE it is found in almost its default configuration.
All in all it was a good system. It was an easy install and required no configuration (subsequent releases will probably not need the user to upgrade the kernel), although I did tweak my xorg.conf. My usb devices worked out of the box and sound came right up after the kernel upgrade without further configuration. The included apps make for a wonderful foundation and most are of the latest release. The stability wasn't compromised for these bleeding edge improvements. No application or system crashes occurred. However, I didn't notice an amazing speed increase. It seemed to be a bit faster, but not as I imagined. This may be in part to my choice of filesystem. I chose ext3 while the installer seemed to want to default to xfs. Perhaps choosing reiserfs or xfs would have made a difference. Don't get me wrong, there was no delay in any menu operations or window repainting and apps opened promptly enough. It just didn't leave any burn marks as experienced with kubuntu.
It was quite an amazing system if you'll remember that we are talking about one man's efforts. When asked what was the most challenging aspect of this conversion, Arny stated, "I think porting D and L software series. It was difficult until I set up a development environment on which I can port the other software series." As you might know, D is the developmental applications and L is the libraries.
What's in store for Arny and BlueWhite64? Well, Arny doesn't like to make even short term plans as something seems to always come up. However, he can't help but hope that someday his system will become, if not in whole at least in part, an official x86_64 port of Slackware Linux. So, we'll keep our eyes and ears open for the next release and keep you posted. We can expect things to only get better from this talented young developer. Don't forget we are dealing with a pre-beta of a distro less than 2 months old. At this time it is still on Distrowatch's waiting list.
If you'd like to try BlueWhite64, it can be downloaded from one of the mirrors listed here. You can keep abreast of developments at BlueWhite64's homepage here. If you are a fan of Slackware and have a 64 bit machine, you owe it to yourself to give Bluewhite64 a try. And if you do, feel free to share your findings with us here at Tuxmachines.
re: Dishonest
tm: did you start with slackware or slamd64?
arny: The D and L series was compiled on slamd64 and the rest on the resulting environment.
And why is so important what build environement I used ?
tm: did you recompile all the packages solely from slackware 32bit sources?
arny: Yes!
----
You talk the talk, but do you waddle the waddle?
Inacurracies
1) The D and L series do not give you an environment suitable for this - D and parts of A or busybox do
2) There are some cases where slamd64 and bluewhite64 have a .SlackBuild script, and slackware just has a .build script - ignoring this, if it was the case that just slackware 32-bit sources were used, why is Fred thanked if none of his work were used?
Example
Slackware - note no .SlackBuild, and a .build
http://ftp.heanet.ie/pub/slackware/pub/slackware/slackware-current/source/l/lesstif/
Slamd64
http://ftp.heanet.ie/pub/slamd64/slamd64-current/source/l/lesstif/lesstif.SlackBuild
Compared to:
BlueWhite64
ftp://mirror.inode.at/bluewhite64/bluewhite64-current/source/l/lesstiff/lesstif.Slackbuild
Just libdir changes in bluewhite64, and a change in the build machine type for some reason.
re: Inacurracies
I guess I'll just pull the story.
----
You talk the talk, but do you waddle the waddle?
Indeed, the contents of this
Indeed, the contents of this article are rather shocking.
re: shocking
When asked to respond, Mr. Craciun states,
You may notice at
http://bluewhite64.com/news.php the latest news, at the endThanks to:
Frederick Emmott - various patches for the x86_64 architecture
Virgil Moldoveanu - for all tests and reports
freerock - for the emacs.Slackbuild script
crazy|| - for the PNG-Gimp patchI used some patches.
----
You talk the talk, but do you waddle the waddle?
re: Dishonest
I apologize for my part in this. If these allegations are true, it was not disclosed to me. I submitted about 5 or 6 questions to the developer when I heard of this new distro. He wrote back and these are his answers. Slamd64 wasn't mentioned at all. Again, I apologize if this is true, but perhaps we should ask for proof? It falling under the gpl makes it perfectly legal to do, however, it's rude not give credit to those whose work you may have borrowed.
I'm sorry, I just don't know what to say. Of course I'm wondering if I should pull the story or modify it. I think it would have been handled more appropriately privately first, perhaps giving Mr. Craciun a chance to respond and tuxmachines a chance to make corrections if needed.
Again, I apologize if my story omitted any facts or proliferated any untruths. At this point, all I can do is solicit a response from Attila Craciun.
----
You talk the talk, but do you waddle the waddle?
Can we have ONE review without an Ubuntu reference?
In any case... when I upgrade my lappy to a Turion, I'm definitely doing this. Hopefully, I can finally create that 64-bit Slackware-based livecd I've been talking about.
re: ubuntu reference
<scoffs> Why Noooo! You should know better than that. Silly you! 
----
You talk the talk, but do you waddle the waddle?

My primary concern here is that people don't mistakenly believe that a fork or an unofficial port is officially sanctioned by the Slackware Project, or is Slackware, if it is not. As the information included with Slackware says, once you change any part of it on your own then the derivative OS is no longer officially "Slackware".


Dishonest
For 3 or 4 months, Arny` has been in #slamd64 on freenode, asking how to modify slamd64 into a non-multilib system. Slamd64 is a year-old port of slackware to amd64 (http://www.slamd64.com).
Looking at the source of the distro, it is almost all copied from slamd64 with minor adjustments so as not to be a multilib system. In his latest notes, he's thanked Fred for "various patches" - however this is in no-way proportional to the amount of Fred's work he has claimed as his own. Fred has truly been doing this single handed for over a year (although as shown in the changelog, he's taken patches from other distributions, but the difference is he credits them).
Arny's admitted himself to be a slamd64 user in the channel, also given he supposedly got a first package compiled in the first day he started working on (After 3 days of reading documentation supposedly), it is highly likely that he was using slamd64 as his build environment.
What is certain is that:
- He has used slamd64
- He has asked for help in the last few months in creating a slamd64 derivative
- Almost all of the build scripts that aren't in slackware are taken from slamd64 with very minor modifications
- He doesn't acknowledge other people's work
He has however, added a few packages which aren't in slamd64.
I have not tried bluewhite64, as I refuse to install something created by someone so deceitful.