Language Selection

English French German Italian Portuguese Spanish

PCLinuxOS 2013--An Old Friend Revisited

Filed under
Linux

I first heard about Bill Reynolds (AKA "Texstar") when I was using Mandrake Linux 7 (later called "Mandriva") many years ago. Back then, Texstar was putting together updated KDE releases for Mandrake Linux, as Mandrake would only typically update their KDE release once or twice a year.

Texstar was fanatic about getting everything working right, and his response was rapid if you'd report any issues with KDE's operation.

Eventually, Texstar decided to gather a group together and create his own (then Mandriva derived) distribution called PCLinuxOS. Cautiously, I stayed with Mandriva as my primary distro for a few months, and then jumped ship to the new PCLinuxOS.

It was a great time--fast KDE updates, sound worked great, the latest and greatest multimedia codecs, and the nvidia drivers were great.

Then Texstar took about a year long hiatus (due, I think, to exhaustion and illness) and the distro deteriorated. I moved my primary distro to Kubuntu, and have used it for about three years now.

So, earlier this week, I saw on Distrowatch that PCLinuxOS 2013.12 has just been released, and it has KDE 4.11.3. Well, that's fairly current as KDE just released 4.11.4. This was the quarterly update release of the ISO images--so, I thought I'd give it a try.

This PCLinusOS KDE occurs in three versions: "KDE Full", "FullMonty", and "MiniMe" with all three in both 32 and 64-bit releases. In addition PCLinuxOS also has the LXDE Desktop and MATE Desktop releases.

The "FullMonty" release contains the KDE Full desktop, with a special very customized KDE desktop layout, and additional applications and drivers. Since I like to configure my own KDE, this didn't seem right for me. In addition, it's 3.8 GB in size.

The "MiniMe" release provides a basic KDE desktop and is directed for advanced users that can fine tune their own system--and no printer drivers are included. Probably a little minimalist for me.

The "KDE Full" version provides a standard KDE desktop and contains many popular applications and drivers. Like Goldilocks, I thought this version was just right. And, so I downloaded this 1.6GB version and installed it on my secondary desktop machine.

PCLinuxOS is a rolling release distribution, and I don't know how they do it with this many different versions. But I still found familiarity with it as you would greeting an old friend you haven't seen in a good while. It still uses Synaptic with RPM files for software installs and updates. The sound drivers and codecs are great, nvidia drivers are installed by default, and the "system just works".

I modified the fstab file to load my Synology NAS (Network Attached Storage) shared drive, which works well. I found all the files needed to customize the KDE desktop.

Any issues at all? Well, I still do a little programming, and I found that PCLinuxOS contains the old 1.8.7 version of the Ruby programming language--I wish it were at least Ruby 1.9.3 or later. And PCLinuxOS uses an older kernel (3.4.64).

I need to send them a donation. Welcome back, PCLinuxOS.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thank You

Thank you so much for the comment and for the donation. PCLinuxOS is a cash poor distribution like most others that do not have a millionaire benefactor. I've started saving my nickels and dimes to get a box with uefi bios and gbt in order to be able to extend PCLinuxOS on more modern hardware.

Tex

PCLinuxOS

Several years ago I installed PCLinuxOS for my father. It had a Tux Machines link built into the Web browser (Firefox).

Someone wrote to me earlier today because I posted this link to Susan's article. I had to provide some historical background and an explanation of why Susan wrote the article. Yesterday someone commented on a post of mine, highlighting the age of Linux (kernel) used in the latest PCLinuxOS.

I still keep my PCLinuxOS CDs around and I last booted PCLinuxOS a couple of months back. PCLinuxOS is a small (but also BIG) distribution that deserves everyone's support.

Posting the link above is by no means provocation against PCLinuxOS.

Mint Linux (another small team) does more to 'sell out' users (Google linkage) and nobody gets more flak for it than Ubuntu (Amazon linkage). Mozilla gets the carte blanche.

What's more terrifying to me personally are Microsoft patent deals (like Novell's/SUSE's), not privacy infringements that are less divisive and collectively detrimental.

Susan Linton Ex-Girlfriend of Texstar

Did you tell them Susan Linton is an ex-girlfriend of mine? She is apparently still mad about the breakup and has set out to damage the reputation of PCLinuxOS.

Hell hath no fury like a woman scorned!

RE: Susan Linton Ex-Girlfriend of Texstar

Don't be petty, Texstar.
Isn't she married now? Get over it dude.

The article she posted on

The article she posted on ostatic was petty and it wasn't the first time she went after my distribution. Enough is enough. Move on and be happy.

oh well

in that case, just ignore her. If you think about her, she is winning Smile

More in Tux Machines

Kernel Coverage at LWN (Outside Paywall Now)

  • XArray and the mainline
    The XArray data structure was the topic of the final filesystem track session at the 2018 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM). XArray is a new API for the kernel's radix-tree data structure; the session was led by Matthew Wilcox, who created XArray. When asked by Dave Chinner if the session was intended to be a live review of the patches, Wilcox admitted with a grin that it might be "the only way to get a review on this damn patch set". In fact, the session was about the status of the patch set and its progress toward the mainline. Andrew Morton has taken the first eight cleanup patches, Wilcox said, which is great because there was a lot of churn there. The next set has a lot of churn as well, mostly due to renaming. The 15 patches after that actually implement XArray and apply it to the page cache. Those could be buggy, but they pass the radix-tree tests so, if they are, more tests are needed, he said.
  • Filesystem test suites
    While the 2018 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM) filesystem track session was advertised as being a filesystem test suite "bakeoff", it actually focused on how to make the existing test suites more accessible. Kent Overstreet said that he has learned over the years that various filesystem developers have their own scripts for testing using QEMU and other tools. He and Ted Ts'o put the session together to try to share some of that information (and code) more widely. Most of the scripts and other code has not been polished or turned into a project, Overstreet continued. Bringing new people up to speed on the tests and how they are run takes time, but developers want to know how to run the tests before they send code to the maintainer.
  • Messiness in removing directories
    In the filesystem track at the 2018 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM), Al Viro discussed some problems he has recently spotted in the implementation of rmdir(). He covered some of the history of that implementation and how things got to where they are now. He also described areas that needed to be checked because the problem may be present in different places in multiple filesystems. The fundamental problem is a race condition where operations can end up being performed on directories that have already been removed, which can lead to some rather "unpleasant" outcomes, Viro said. One warning, however: it was a difficult session to follow, with lots of gory details from deep inside the VFS, so it is quite possible that I have some (many?) of the details wrong here. Since LSFMM there has been no real discussion of the problem and its solution on the mailing lists that I have found.
  • Handling I/O errors in the kernel
    The kernel's handling of I/O errors was the topic of a discussion led by Matthew Wilcox at the 2018 Linux Storage, Filesystem, and Memory-Management Summit (LSFMM) in a combined storage and filesystem track session. At the start, he asked: "how is our error handling and what do we plan to do about it?" That led to a discussion between the developers present on the kinds of errors that can occur and on ways to handle them. Jeff Layton said that one basic problem occurs when there is an error during writeback; an application can read the block where the error occurred and get the old data without any kind of error. If the error was transient, data is lost. And if it is a permanent error, different filesystems handle it differently, which he thinks is a problem. Dave Chinner said that in order to have consistent behavior across filesystems, there needs to be a definition of what that behavior should be. There is a need to distinguish between transient and permanent failures and to create a taxonomy of how to deal with each type.
  • 4.18 Merge window, part 1
    As of this writing, 7,515 non-merge changesets have been pulled into the mainline repository for the 4.18 merge window. Things are clearly off to a strong start. The changes pulled this time around include more than the usual number of interesting new features; read on for the details.
  • Year-2038 work in 4.18
    We now have less than 20 years to wait until the time_t value used on 32-bit systems will overflow and create time-related mayhem across the planet. The grand plan for solving this problem was posted over three years ago now; progress since then has seemed slow. But quite a bit of work has happened deep inside the kernel and, in 4.18, some of the first work that will be visible to user space has been merged. The year-2038 problem is not yet solved, but things are moving in that direction. If 32-bit systems are to be able to handle times after January 2038, they will need to switch to a 64-bit version of the time_t type; the kernel will obviously need to support applications using that new type. Doing so in a way that doesn't break existing applications is going to require some careful work, though. In particular, the kernel must be able to successfully run a system where applications have been rebuilt to use a 64-bit time_t, but ancient binaries stuck on 32-bit time_t still exist; both applications should continue to work (though the old code may fail to handle times correctly). The first step is to recognize that most architectures already have support for applications running in both 64-bit and 32-bit modes in the form of the compatibility code used to run 32-bit applications on 64-bit systems. At some point, all systems will be 64-bit systems when it comes to time handling, so it makes sense to use the compatibility calls for older applications even on 32-bit systems. To that end, with 4.18, work has been done to allow both 32-bit and 64-bit versions of the time-related system calls to be built on all architectures. The CONFIG_64BIT_TIME configuration symbol controls the building of the 64-bit versions on 32-bit systems, while CONFIG_COMPAT_32BIT_TIME controls the 32-bit versions.

today's leftovers

GNOME 3.29.3 Released

  • GNOME 3.29.3 released
    GNOME 3.29.3 is now available. This release is primarily notable in that all modules are buildable in this release, which is historically very rare for our development releases. This is an accomplishment! I hope we can keep this up going forward.
  • GNOME 3.29.3 Released As The Latest Step Towards GNOME 3.30
    GNOME 3.29.3 is out today as the latest development release in the road to this September's GNOME 3.30 desktop update. Highlights of the incorporated GNOME changes over the past few weeks include: - Epiphany 3.29.3 and its many notable improvements already covered on Phoronix from a reader mode to disabling NPAPI plugins by default.

Android Leftovers