Slackadelic.com

Interestingly enough I was contacted by the web master for the page in Episode 1. He contacts me and acts like “Oh, its been this way for over a year.” Like I’m freakin’ stupid.

Well, Google cache is a bitch. That was taken from May 13th 2008. You can plainly see the link at the bottom. Here is the source in pdf format. Yeah, I must be blind, stupid, deaf, and dumb.

Ok, when is it going to be enough hmm? After my recent postings, I decided to dig through a web site a bit more and found this.

Same author as Bluewhite64. Dude, come on, you are INFRINGING on someone else’s freakin’ copyright! Knock it off.

Oh, and just in case there is a change to that site, check here for a pdf copy of the site and look at the very bottom of the page. This isn’t a personal vendetta against this author, but its starting to get ridiculous. He ignores the laws of copyright and trademark for his own benefit. I hope some day it bites him in the end and Karma has the last laugh, which I’m sure it will.

Just to add to this topic.. Someone tipped me off to an article and that led to me reading comments.

Click here… classic about what I’m hitting on about.

Wikipedia defines plagiarism as:

Plagiarism is the practice of claiming or implying original authorship of (or incorporating material from) someone else’s written or creative work, in whole or in part, into one’s own without adequate acknowledgement.

Now, I’m sure most of you are wondering what in the hell I’m talking about. Well, I’m going to show you.

As most of you know, I’m an avid user and small contributor to the Slackware project. I use slackware-current quite a bit. In fact, its the main operating system I run on my laptop. Now, what does this have to do with anything you ask? Many know of the countless derivatives and cross-platform distributions out there that have taken from Slackware and created their own uniqueness in the world of Linux.

However, there are still some out there that choose to ignore the fact of credit where credit is due. I’m sure some of you will take this article to be yet another one of my so called “ramblings” about this certain distribution, but you’ll soon get over it. This isn’t a rambling; it is a statement of fact and shown proof of that fact. Either you can deal with it, see the light, and move on or you can go off and try to tag me as a vigilante with no cause for concern that is just bitching to bitch. Whatever you determine, I will be right

Now, to begin, we all know about my first run of articles concerning Bluewhite64 and many had their own opinions based on mixed information or lack there of or just plain ignorance. This article is not to “call out” anyone, but to try and help reveal what I see as a major issue.

We know that Slackware just released 12.1. Now, I follow the change logs quite religiously. I also check up on Slamd64 and Bluewhite64 quite frequently. It helps me to gauge where everything is in the development process. With that said, I started noticing down right similarities between Bluewhite64’s changelog and Slackware’s changelog.

From Bluewhite64’s 12.1 ChangeLog:

Thu May 1 23:26:52 EEST 2008
Bluewhite64 12.1 RC4. The last RC? .
A software series/kernel-huge-2.6.24.5-x86_64-2.tgz: Patched to fix a security issue in
fs/dnotify.c. The use of dnotify (largely replaced by inotify on 2.6.x
systems) could lead to a local DoS, or possibly a local root hole.
This flaw will also be addressed in the kernels for previous releases
as soon as possible. The patch itself may be found in
source/k/linux-2.6.24.5-CVE-2008-1375-patch/. For additional information
(when the CVE candidate is opened), see:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1375

All the kernel packages below should also be considered security fixes.
[*** Security fix ***]
A software series/kernel-test-huge-2.6.25-x86_64-2.tgz: Patched and recompiled.
A software series/kernel-modules-2.6.24.5-x86_64-2.tgz: Patched and recompiled.
A software series/kernel-test-modules-2.6.25-x86_64-2.tgz: Patched and recompiled.
D software series/kernel-headers-2.6.24.5-x86_64-2.tgz: Rebuilt from a patched source tree.
K software series/kernel-source-2.6.24.5-noarch-2.tgz: Patched (leaving dnotify.c.orig
for comparison and/or reverting to patch up to a newer kernel later).
L software series/svgalib_helper-1.9.25_2.6.24.5-x86_64-2.tgz: Recompiled.
EXTRA software/slackpkg/slackpkg-2.70.3-noarch-1.tgz: Upgraded to
slackpkg-2.70.3-noarch-1 (release ready). Thanks to Piter Punk! -:)
TESTING/packages/kernel-test/kernel-test-headers-2.6.25-x86_64-2.tgz:
Rebuilt from a patched source tree.
TESTING/packages/kernel-test/kernel-test-source-2.6.25-noarch-2.tgz: Patched (leaving
dnotify.c.orig for comparison and/or reverting to patch up to a newer kernel later).
kernels/huge.s/*: Patched and recompiled.
kernels/test.s/*: Patched and recompiled.
isolinux/initrd.img: Rebuilt with newly compiled kernel modules.
usb-and-pxe-installers/: Rebuilt usbboot.img with newly compiled kernel modules.

From Slackware’s 12.1 ChangeLog:

Wed Apr 30 20:36:48 CDT 2008
12.1 RC4. We think this should be the last one.
a/kernel-generic-2.6.24.5-i486-2.tgz: Patched to fix a security issue in
fs/dnotify.c. The use of dnotify (largely replaced by inotify on 2.6.x
systems) could lead to a local DoS, or possibly a local root hole. We said
we wouldn’t make changes now unless something was “critical” — and it seems
we got what we wished for. This flaw will also be addressed in the
kernels for previous releases as soon as possible. The patch itself may be
found in source/k/linux-2.6.24.5-CVE-2008-1375-patch/.
For additional information (when the CVE candidate is opened), see:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1375

All the kernel packages below should also be considered security fixes.
(* Security fix *)
a/kernel-generic-smp-2.6.24.5_smp-i686-2.tgz: Patched and recompiled.
a/kernel-huge-2.6.24.5-i486-2.tgz: Patched and recompiled.
a/kernel-huge-smp-2.6.24.5_smp-i686-2.tgz: Patched and recompiled.
a/kernel-modules-2.6.24.5-i486-2.tgz: Patched and recompiled.
a/kernel-modules-smp-2.6.24.5_smp-i686-2.tgz: Patched and recompiled.
d/kernel-headers-2.6.24.5_smp-x86-2.tgz: Rebuilt from a patched source tree.
k/kernel-source-2.6.24.5_smp-noarch-2.tgz: Patched (leaving dnotify.c.orig
for comparison and/or reverting to patch up to a newer kernel later).
l/svgalib_helper-1.9.25_2.6.24.5-i486-2.tgz: Recompiled.
extra/linux-2.6.24.5-nosmp-sdk/: Updated SMP to no-SMP kernel source patch.
extra/slackpkg/slackpkg-2.70.3-noarch-1.tgz: Upgraded to
slackpkg-2.70.3-noarch-1 (release ready). Thanks to Piter Punk! -:)
kernels/huge.s/*: Patched and recompiled.
kernels/hugesmp.s/*: Patched and recompiled.
kernels/speakup.s/*: Patched and recompiled.
isolinux/initrd.img: Rebuilt with newly compiled kernel modules.
usb-and-pxe-installers/: Rebuilt usbboot.img with newly compiled
kernel modules.

With this section, you can see the direct copy and paste of the Slackware Changelog into Bluewhite64’s Changelog. Now, this may not seem to be a big deal to most, but to me this is someone being very very lazy. You didn’t do any of the work stated in that log. That was Pat. Piter Punkt didn’t help YOU with anything; it was Slackware. See where I’m going with this?

Lets move on to some more examples.

From Bluewhite64’s 12.1 Changelog:

Tue Apr 29 13:47:34 EEST 2008
This is Bluewhite64 12.1-RC3, no ISO for this time . Enjoy!
A software series/cups-1.3.7-x86_64-2.tgz: Applied patch str2790 to fix crash bugs in the PNG
image filter. The issues are not believed to be capable of either a DoS (at
worst, it simply crashes the filter processing the current job and does not
crash the scheduler daemon, which just moves on to the next job in the print
queue), nor arbitrary code execution (data from the image is never stored in
the affected tile array). Still, it seems to be worth fixing here just in
case. The CUPS bug report may be found here:

http://www.cups.org/str.php?L2790

AP software series/mysql-5.0.51b-x86_64-1.tgz: Upgraded to mysql-5.0.51b (which appears to be
nothing more than a version bump…)
L software series/imlib-1.9.15-x86_64-6.tgz: Patched to fix rendering issues on Intel and
possibly other graphics chipsets.
L software series/libmtp-0.2.6.1-x86_64-1.tgz: Upgraded to libmtp-0.2.6.1.
The udev rules are now sed processed during build.
L software series/libpng-1.2.27-x86_64-1.tgz: Upgraded to libpng-1.2.27.
This fixes various bugs, the most important of which have to do with the
handling of unknown chunks containing zero-length data. Processing a PNG
image that contains these could cause the application using libpng to crash
(possibly resulting in a denial of service), could potentially expose the
contents of uninitialized memory, or could cause the execution of arbitrary
code as the user running libpng (though it would probably be quite difficult
to cause the execution of attacker-chosen code). We recommend upgrading the
package as soon as possible.
For more information, see:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382

ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.2.27-README.txt
[*** Security fix ***]
X software series/xf86-input-joystick-1.3.2-x86_64-1.tgz: Upgraded to xf86-input-joystick-1.3.2.
X software series/xf86-video-vmware-10.16.1-x86_64-1.tgz: Upgraded to xf86-video-vmware-10.16.1.
XAP software series/mozilla-firefox-2.0.0.14-x86_64-2.tgz: Added the distribution
name and version to the User Agent (UA).
XAP software series/seamonkey-1.1.9-x86_64-1.tgz:Added the distribution
name and version to the User Agent (UA).
isolinux/initrd.img: Fixed minimum RAM amount in /etc/issue, and made some
edits to other documentation within the installer.
usb-and-pxe-installers/: In usbboot.img, fixed minimum RAM amount in
/etc/issue, and made some edits to other documentation within the installer.

From Slackware’s 12.1 Changelog:

Mon Apr 28 23:43:55 CDT 2008
We’ll call this Slackware 12.1 RC3, and freeze the tree for anything that
isn’t critical. Things seem very stable, so it’s probably a good idea to
save any further upgrades and additions until -current restarts.
a/cups-1.3.7-i486-2.tgz: Applied patch str2790 to fix crash bugs in the PNG
image filter. The issues are not believed to be capable of either a DoS (at
worst, it simply crashes the filter processing the current job and does not
crash the scheduler daemon, which just moves on to the next job in the print
queue), nor arbitrary code execution (data from the image is never stored in
the affected tile array). Still, it seems to be worth fixing here just in
case. The CUPS bug report may be found here:

http://www.cups.org/str.php?L2790

ap/mysql-5.0.51b-i486-1.tgz: Upgraded to mysql-5.0.51b (which appears to be
nothing more than a version bump…)
l/imlib-1.9.15-i486-3.tgz: Patched to fix rendering issues on Intel and
possibly other graphics chipsets. Thanks to Iain Paton.
l/libmtp-0.2.6.1-i486-1.tgz: Upgraded to libmtp-0.2.6.1. The udev rules are
now sed processed during build. Thanks much to Joerg Germeroth.
l/libpng-1.2.27-i486-1.tgz:
Upgraded to libpng-1.2.27.
This fixes various bugs, the most important of which have to do with the
handling of unknown chunks containing zero-length data. Processing a PNG
image that contains these could cause the application using libpng to crash
(possibly resulting in a denial of service), could potentially expose the
contents of uninitialized memory, or could cause the execution of arbitrary
code as the user running libpng (though it would probably be quite difficult
to cause the execution of attacker-chosen code). We recommend upgrading the
package as soon as possible.
For more information, see:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382

ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.2.27-README.txt
(* Security fix *)
x/xf86-input-joystick-1.3.2-i486-1.tgz: Upgraded to xf86-input-joystick-1.3.2.
x/xf86-video-radeonhd-1.2.1-i486-1.tgz: Upgraded to xf86-video-radeonhd-1.2.1.
x/xf86-video-vmware-10.16.1-i486-1.tgz: Upgraded to xf86-video-vmware-10.16.1.
isolinux/initrd.img: Fixed minimum RAM amount in /etc/issue, and made some
edits to other documentation within the installer.
usb-and-pxe-installers/: In usbboot.img, fixed minimum RAM amount in
/etc/issue, and made some edits to other documentation within the installer.

I don’t think I even have to explain this section. If you can’t see the direct copy and paste.. get to the eye doctor.. get an examination, get glasses, then hit yourself on the head with a baseball bat because you are blind as a bat and dumber than a box of rocks.

The examples continue the entire length of the change log. I can post them all, but why? I’m posting this to bring an issue into the public eye that needs to be addressed. Yes, that is my opinion, that it needs addressed. Why? If you have to ask why, then you obviously do not understand the time and effort that the folks at Slackware put into a release. Yes, even maintaining the change logs is a full time job and takes time to write.

Once again, the display of no credit where credit is due is proven. Its in black and white. On a web page. Publicly available for all to see. Just in case something changes between now and when you read this, we know the Slackware change log will stay as-is. However, I’ve provided a pdf print out of the Bluewhite64 change log for 12.1 release as-is from the date of this post.

One more point to hit on. The release announcements.

From Bluewhite64’s release announcement for 12.1:

Among the many program updates and distribution enhancements, you’ll find better support for RAID, LVM, and cryptsetup; a network capable (FTP and HTTP, not only NFS) installer; two of the most advanced desktop environments available today: KDE 3.5.9, the latest version of the award-winning K Desktop Environment, and Xfce 4.4.2, a fast and lightweight but visually appealing and easy to use desktop environment; SMP Linux Kernel 2.6.24.5 and 2.6.25.1 (for testing) with advanced features and performance; Fuse 2.7.3 and ntfs-3g 1.2310 read/write NTFS driver; SCIM 1.4.7 (Smart Common Input Method); an updated IA32 Emulation (run 32-bit programs) in the EXTRA software series, and may more improved and upgraded packages. Read the Official Announcement for more details.

From Slackware’s release announcement for 12.1:

Well folks, it’s that time to announce a new stable Slackware release again. So, without further ado, announcing Slackware version 12.1! Since we’ve moved to supporting the 2.6 kernel series exclusively (and fine-tuned the system to get the most out of it), we feel that Slackware 12.1 has many improvements over our last release (Slackware 12.0) and is a must-have upgrade for any Slackware user.

Among the many program updates and distribution enhancements, you’ll find better support for RAID, LVM, and cryptsetup; a network capable (FTP and HTTP, not only NFS) installer; and two of the most advanced desktop environments available today: Xfce 4.4.2, a fast, lightweight, and visually appealing desktop environment, and KDE 3.5.9, the latest 3.x version of the full-featured K Desktop Environment.

The official announcement has more details. Also please consider helping to support the project financially at http://store.slackware.com (the CD set and DVD are off to replication, but pre-orders are being taken now). Your kind support and the help of many volunteers is what makes this project possible. Huge thanks are due to everybody who pitched in and helped with bug reports, patches, testing, suggestions, other comments, and everything else. Without this valuable input, Slackware would be nowhere near what it is today. Special thanks to the CREW, to the people developing and testing for slackbuilds.org (where many of Slackware’s future additions are first built and tested), and to everyone on linuxquestions.org, various #slackware or ##slackware IRC channels, other Slackware related web sites, and other places where the community shares their needs and concerns with the team. On behalf of everyone here, thanks. We think you’ll enjoy this new release, and hope that you’ll find it to be much more than 0.1 better than Slackware 12.0.

Have fun!

Pat and the Slackware team

From what you can see, a good portion of it is copy and paste… lazy… lazy… lazy….

I rest my case.

In an attempted spin to turn my own wits against me the developer of Bluewhite64 has tried to turn my article against me. The funny thing is that if I were you, I would’ve admitted my wrong doing by now and moved on. However, you still want to banter on about how it is possible to port an entire distro in 4 weeks, when in the tuxmachines.org article you told the author it was 3 months.

Well, Dominian cannot handle the truth that Bluewhite64 is better than Slamd64 and instead of doing something useful, like helping Fred to maintain, develop and release Slamd64 at the same time like Slackware, he prefer to spread FUD. Anyway, I’m not interested in his opinions. I prefer to work and keep the Slackware line and offer the same user experience on a 64-bit environment.

I already noticed in the original review how I have created Bluewhite64, just read the comments. Also, I already thanked Fred for patches and scripts that I used. So, saying the same things twice is pointless.

Dominian, have you ever tried to port Slackware? Did you know that is possible to do it from scratch in 4 weeks if you work at least ~14 -15 hours/day including Sundays? Well, I have spend these hours when I started the work. Anyway I prefer to work instead of reading “hilarious” blogs.

Lets take this in stride. Most of those who read my blog and talk to me in person on a day-to-day basis know I’m not one to hold back on admitting my faults nor mistakes, but you seem adamant to attempt to tarnish me. Hehe, good luck. Lets take your comments and see what we get out of them…

Well, Dominian cannot handle the truth that Bluewhite64 is better than Slamd64 and instead of doing something useful, like helping Fred to maintain, develop and release Slamd64 at the same time like Slackware, he prefer to spread FUD. Anyway, I’m not interested in his opinions. I prefer to work and keep the Slackware line and offer the same user experience on a 64-bit environment.

Better? Your ego precedes you. The maintainer of Slamd64 has never once come out and said that he was “better” than anyone else nor made himself some kind of deity when it came to developing a distribution. He is a user who happens to compile a distro. He’s one of us. THAT, in my mind, is what makes Slamd64 better.

instead of doing something useful, like helping Fred to maintain, develop and release Slamd64 at the same time like Slackware, he prefer to spread FUD.

Fred like Pat is a one-man team. He has his dedicated user base to do the testing, bug reporting, and occasionally, we will submit fixes or patches that we have either found or written ourselves. Other than that, its Fred’s final say. Period.

I already noticed in the original review how I have created Bluewhite64, just read the comments. Also, I already thanked Fred for patches and scripts that I used

What does the review have anything to do with your dishonest way of claiming the work of another user as your own? I mean, if I took nearly a year to invent something and someone came along and took the same idea and the same work I had already done and then released their own “invention” I’d be a bit pissed. Not only would I want credit, but I would also want you to admit in public what you had done. Which at this point, I don’t think will ever happen. There are MORE than just the patches and scripts that you used. I remember the “knowledge” you had about trying to compile even a damn kernel and you were in an irc channel basically saying, this doesn’t work; how do I fix it? So spare me the BS of how you have done this all on your own with only using a few scripts and patches provided by Fred.

Dominian, have you ever tried to port Slackware? Did you know that is possible to do it from scratch in 4 weeks if you work at least ~14 -15 hours/day including Sundays? Well, I have spend these hours when I started the work. Anyway I prefer to work instead of reading “hilarious” blogs.

Yes, I have tried to port Slackware about the same time that Fred started and when I found out he was doing it, I stopped. I’m not a programmer; I’m an administrator, but I know enough that I can make patches/scripts to help out from time to time. I stopped because it was pointless. Here was Fred an accomplished programmer and student striving his way towards a technology degree. The project of taking on porting a distribution to an entirely new architecture is an amazing project for him both in learning more about his chosen field and in a test of will power on those late ass nights I remember him having. You on the other hand, “oh I’ll install this.. then just remove /usr/lib64 and recompile it and release it as another distribution.” Wow.. that’s.. hard.. work.

And yes, my blog is hilarious.

Yes, that is a direct quote from a forum speaking of my article You can’t handle the truth. Laws? Laws support truth, not lies and deception. Certainly not one who calls the work of someone else their own. I say face up to reality, admit what you did, apologize to the people who you owe it to, and move on with your life. That is, if it isn’t so tarnished from the spewing of nonsensical, idiotic crap that you have issues even getting a job flippin’ a burger…

It seems that a few people over at the Bluewhite64 project seem to think that my article “I can’t take it anymore” is a troll on that distribution. In fact, it is a personal opinion that has come from definite evidence that Bluewhite64 is a complete rip off of Slamd64 and its maintainer’s work.

This all started when this article (original text) was found on Tux Machines. Now, if you didn’t read close enough it states “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.” Months? Months?!? You’ve got to be kidding me. This is where everything stemmed with my disgust at Bluewhite64. I’m sure its a great distribution. You know why? Because the work Arny supposedly did was the work Fred Emmott had already accomplished. There has never been an acknowledgment from the maintainer of Bluewhite64 of Fred Emmott’s work. Until that day comes, Bluewhite64 will continue to make me utterly sick.

Arny used Slamd64’s earlier versions to base his work for Bluewhite64. The only thing he did was 1) install Slamd64 2) rebuild all the packages but omitting /usr/lib64 and keeping all libraries in /usr/lib and 3) 64bit only support with no 32bit compatibility. Now, would you call this a new distribution? No, I would call it a fork of the original work.

These aren’t the only issues. I and Fred have both sat in irc channels and Arny come and ask for help to get something working. Funny thing is, it seemed to happen every time -current of Slamd64 was updated and something was broken in the tree which was still being worked on. Odd eh?

Not to mention the fact that, well, there are still comments in Bluewhite64 slackbuilds that were in Slamd64.

Interesting. So, speak of a troll as you may. Slamd64 release cycle is a bit slow at this time and if you paid attention to the Slamd64 site you would see why. The developer is working on the KDE4 project and quite a few other things.

So, Bluewhite64, get off your high horse, admit what you did, and we’ll all move on. You still, till this day will not acknowledge the work of Fred Emmott and the fact you FORKED his distribution and didn’t port Slackware yourself.

Decided to try and login to the forums to see what else was being posted and I could answer to. Hmm… Interesting… My account has been removed! Surprised? I THINK NOT!

Little conversation he had with me, or so he thought, as I was idle` on irc.

16:52 arny`: Hi there
17:25 Dominian: what
17:37 arny`: why are you still misinforming people ?
17:38 arny`: when i started BW64, slamd64 was far away from the slackware line, using programs that are not included
in slackware
17:38 arny`: i will appreciate if you let the community decide what is the best port
17:47 arny`: and when you post somethig, make sure that you have proof
17:48 arny`: Thank you for your time.

Ok, I’m finally fed up with this crap with Bluewhite64. I’ve followed the forums there for quite sometime and the “author” is still coming out like he’s the man who ported slackware. Well, I made a post and I’m curious what will happen now. Here’s the post link: Click Here
Just in case he decides to delete the post; here is the original text:

Ok, I can’t take this anymore. I’m going to post here this one time and one time only. Those of you who think that bluewhite64 is the end-all-be-all of slackware ports to 64bit.. you are sadly mistaken. Bluewhite64 was actually spawned out of Slamd64 (http://www.slamd64.com). Everything I’ve seen on these forums that are “bugs” or “features” you want.. are fixed or included in slamd64. Arny will more than likely blow this post away and delete my account.. which is fine. But understand this, Fred Emmott ported slackware to amd64 BEFORE bluewhite64 was even thought of. Arny then used slamd64 as his ‘base’ and outright lied to tuxmachines.org about how he got everything going in less than 3 months. So, you go on and continue what you will, but this crap has got to stop and the real kudos need to go to Fred Emmott for his hard work of actually porting an entire 32bit Slackware distribution to run on x86_64 architecture.