During the past week I have been spending time on getting the latest KDE Frameworks, Plasma and Applications built. The new Applications 16.12 was quite a bit of work due to the splitting of tarballs in many smaller ones. Also, the Slackware 14.2 and -current versions have now diverged sufficiently that the packages I compile on 14.2 are no longer guaranteed to work on -current, so that introduces additional work.
This effort took much longer than I am comfortable with. I do not have as much time available as I used to have due to “real life” – meaning my new job is quite a bit more demanding than my previous one.
This made it clear to me that I have to start making decisions about my Slackware activities, with more detail than what I said in the past along the lines of “updates may come less frequent”. It is obvious that I can not keep releasing a new set of ‘ktown‘ packages every month, for both 32bit and 64bit platforms, and for both Slackware 14.2 and -current. I have a few options:
- stop releasing 32bit packages for Plasma 5 (ktown repository)
- stop releasing Plasma 5 for Slackware 14.2 and start focusing on -current exclusively
I tend to lean into option (1) and therefore wrote this blog post. Who is using my Plasma5 (ktown) packages on a 32bit Slackware OS?
If there are users running a 32bit Slackware-current OS then this could mean a stop to new Plasma5 releases for Slackware 14.2. Updates to the graphical desktop does not have priority at this time in the development cycle of Slackware-current which means I will have to keep maintaining my ‘ktown’ repository for a while to come.
Bottomline: I will have to make one of the two above choices, and I will listen to you – the users of my packages – to help me make that decision.
I only use 64-bit, so my vote is Option 1.
Why not both?
32bit has probably very small userbase to begin with, and the whole purpose of stable (unlike -current) is that no new features are getting in, other then a few packages here and there and security related patches.
So 14.2 can have the latest possible KDE, where newer KDE only goes into current, and let the user decide if they want to move to -current.
both is a bit drastic,
however, option 1 should be best option to start with in my opinion
I have several 32 bit systems. I tend to want to run a release, currently 14.2. Down the road, -current may become the best choice, but I am not there yet. I would prefer that you not have to chase -current, but I certainly understand why you would. I choose not to direct your much appreciated work, but rather would like to just share with you what i am doing. (BTW, I appreciate the 32 bit 14.2 live!!!)
I’m still using 32-bit, and will continue. However, not using Plasma but XFCE, so dropping support is OK for me.
I’d vote fore keeping only 64bit, but for both – 14.2 and current – to my mind it is too challenging to have it performing well with 32 bit memory limit
(I am now trying to get used to KDE5 and find it fitting my humble needs, but do not want to switch over to current)
64-bit -current here
If Pat, push plasma5 on current ?
what are you doing ?
I do not use 32bit version 😉
i guess it makes sense to focus on -current because people who thrive for the latest Plasma should have no problem on keeping the system updated to -current.
Simplify your life, Eric!
Put down the Ugly Thing at all!
I only use 64bit 14.2 with Plasma 5 – either way, I’m grateful with whatever you decide. To be honest, I can’t remember the last time I used 32bit Slackware : )
64-bit only here. Thanks for all your effort Eric.
P.S. it’s high time that slackware-current makes the transition to Plasma 5.
sorry, forgot to add: I use -current on my two boxes so any or both of your options would be equally OK for me.
I use 64-bit on 14.2. I don’t want to move to current because my desktop needs to work and -current breaks occasionally. Ktown is much nicer than KDE4, so I’m super thankful for the packages.
Thus my vote would be drop 32-bit. Spooling up Ktown on a 4GB system probably wouldn’t be awesome anyway.
I only use 64-bit and would hate to see Plasma 5 just stop so early in 14.2 life cycle.
Drop the 32bit
Hey Eric,
I may not be the best demographic to sample here. 32bit versions of a distro in my world are mostly of the stable, point release branches, and used as purpose built servers for things like Asterisk PBXes and such.
There really haven’t been 32 bit machines manufactured in quite some time now so IMNSHO might I suggest a 32bit update every three months or so, and maybe skip the 64bit 14.2 packaging when you do that?
Also, in my universe, I really don’t even deploy much in the way of 14.2, and instead use -current in most production environments, simply choosing to carefully advance forward – rollbacks are exceedingly easy if anything breaks anyway.
Another thought, is that people who seek the latest KDE are more likely to be seeking to run the latest in other aspects of software and the OS too.
Finally, KDE has never been what I would call *light*. Were I to deploy a Slackware workstation on an archaic box I most certainly would NOT be using KDE, opting instead for perhaps Xfce – i.e., something light with appropriate utility for working in a GUI on an old lappy w/32 MBytes of RAM, etc.
I know you’re prolly wondering when you’re gonna see an actual ‘vote’ from me, but I would rather just offer my two cents since… as my father used to tell me, “Son, advice is something that people ask for when they usually have a good idea of what they’re going to do anyway.”
So I feel as if I’m contributing more by reflectiing upon what I see as the current landscape, and arming you with some tools to assist you in arriving at a decision.
By the way. You don’t get thanked enough, especially post IBM, so…
Thanks Eric, for all that you do for the community. Really, you’re a big part of why there’s still a Slackware, and certainly why we got a multi-lib and especially a 64bit spin of the best Linux distro there is. Patrick was on the fence and without you a 64bit Slackware would have been a long time coming.
Kindest regards,
Bradley D. Thornton
.
I only use 64 bit slackware anyhow. Plus I am still using KDE 4.x since I have not yet upgraded. But somone on a forum did make me a KDE2 theme for plasma 5, and I can link the old kde4 icons to plasma 5 to get rid of the grey lifeless icons that are default in v5. So I may update soon. I use Current only.
Only have mutlilib on for WINE, and I don’t use KDE these days. So whatever is fine with me. (I don’t use current, and I’m unlikely to use Plasma 5.)
And thanks for everything! (Sorry, hit return too soon.)
First thanks for you hard work Eric, my vote is for 64 bits in both current and 14.2.
First of all thanks for all you do Eric.
I run your LiveSlack Current, 64-bit KDE 5 over Plasma 5.
I am hoping that Pat will go ‘5’ in current before long so maybe he could take some of your load 🙂
And then I recently built my own Plasma 5.71 for using the SBo SlackBuild so if you were to drop Plasma 5 for 14.2 I am ok with that too.
Finally I will gladly use whatever you are able to provide.
Thanks again.
— kjh
Hello, and thanks for all your work Eric, it is really valuable.
I use Slackware for personal use at home and we have two laptops running Slackware64-current with your Plasma 5 packages. I use to update every time you release a new version of KDE5.
I’m also using your multilib in both systems, but only for wine.
I would choose 1, but for me it is ok if you continue updating only 64-current.
Regards,
Felipe.-
Darth Vader, I understand the sentiment 😉
But alas (for you) I happen to like Plasma 5 desktop environment more than any other DE, even better than KDE 4 by now.
That is why I spend all this time on maintaining these packages.
cmyster you apparently did not get the message in my post?
I do not have the time for both anymore.
I do want to stick to my monthly ‘ktown’ updates; that is important to me. From that condition, the above two choices follow.
… and thanks so far, everyone, for all your valuable opinions.
While I am waiting for more feedback, I am finalizing the ‘ktown’ build process for 64bit -current. I am only (re)compiling broken 14.2 packages on -current and the rest will be hard-linked between ‘14.2’ and ‘current’ directory structures to save storage space.
Having the opportinity to generate Live ISOs proves to be quite beneficial to the debugging & QA process.
I still use 32bit but then I am an old codger who doesn’t understand how to upgrade to 64 bit. I use current exclusively.
Eric, I vote for the 64 bit only of 14.2 and -current. i.e. option 1.
At this same time I’m wondering if you’ve considered dropping or limiting you refreshes of multilib, since those too are for 32 bit compatibility and already have a community package for making the necessary compatible packages. If you plan to drop all 32 bit versions of Plasma is it only a matter of the cycle-times and “watching output for error/warnings” or is there a lot of debugging for 32 bit. Certainly it is a different build environment and tool chain, but isn’t that true for multilib also?
Thanks for all you do and hope the new job is utilizing your RHEL certificate. Cheers, Brian
BrianA_MN I wonder what “community package” for multilib you are talking about. Maintaining multilib is hardly any work, it’s just converting a couple of Slackware 32bit packages to “compat32” format.
The only real labor is creating multilib versions of new gcc and glibc packages when those get updated in Slackware-current, and I seriously doubt that anyone besides me has been doing that kind of thing ever since the birth of Slackware64. Besides, such an event only happens a few times per year.
When I work on a new Plasma5 I do that on a 64bit OS. Usually, I need to create slack-desc files and scripts for some (r many) new packages, find solutions around or patches for compilation errors, and that costs time and requires focus. It is definitely *not* trivial to upgrade Plasma5 when the developers bump their version numbers. And sometimes the order of compilation of the packages needs to change. Also, I need to decide whether or not to upgrade any of the growing number of dependencies.
After that ground work, and after completing the 64bit packages and testing them, compiling a 32bit version of the Plasma5 package set is indeed a matter of watching the compilation output for errors. Sometimes, 32bit compilation fails where the 64bit compilation had no issues. But it is still time-consuming as I have to run the compilation in small batches and can only do that when I come home from work. The 32bit package set used to cost me one or two additional days after I had finished with the 64bit, but I have so little free time now that it will take even longer, thus delaying the release of the 64bit packages and keeping my 32bit virtual machine occupied – I can not compile anything else easily (I can, with some effort, but yeah… effort). I think that is not worth it, if there is only a fraction of users that want 32bit versus 64bit.
Want my opinion? Drop using the 32bit OS if you are running the Plasma5 desktop or any other modern desktop. The 32bit OS is fine for use on older systems. But you should not bolt a powerful desktop environment like Plasma5 onto an ageing computer. No one is going to enjoy that,
Option 1. Attempting to run Plasma 5 on my Intel Atom Netbook was a nightmarish slow software wreck. Im going to have to milk blood from turnips to get some new 64 bit hardware here soon enough, as my 10 yr old Proliant server is just barely adequate w 8 GB of DDR2 RAM and 4 cores for Plasma 5 now….
Hi,
Could be both as far as I am concerned (as in, drop 32bit and stable)
Running Plasma 5 on 32bit only machine is probably not very comfortable experience. Also, I wonder how many people experiment with Plasma5 on stable release.
Anyway, 64bit and current here.
Thanks for your work,
Krystian
Option 1. Slackware offers plenty of options in the default install and more with slackbuilds.org and other sites. I think the value of the stuff you do best serves people pushing the boundaries a bit, at least more than people who just want another option for the default install. And thank you for your work. It adds another level to the Slackware community. joe f.
Hi Eric,
I’m voting for 64bit for 14.2 and current.
As a note it might have been easier for your counting if you had asked for some kind of a fixed format for the voting.
I vote option 1.
go opt #1, pls
I use 32-bit current.
First of all, thanks for you hard work Eric! I’m using only current from a lot of time, in 64bit form, then my vote go for 64 bits in both current and 14.2.
Slackware 14.2 x86_64
Opzione 1 per me…
Grazie, ciao!
Both fit for me.
Option 1 for me as I think Plasma5 is a bit heavy for 32bit machines. Whichever option you take a number of people will miss out .
Just my opinion, go with option 1- Stop the Plasma5 for 32bit.
I have 32bit hardware w/ Slackware but its under powered I wouldn’t think of running Plasma5 (or any DE for that matter). It sits there chugging away serving to many of my other needs as a ‘headless’ server.
I understand this class of hardware is still very useful and is so with the lighter DE’s or WM’s too.
But it’s time to let development go for some of the power horse tools out there such as Plasma5. There’s only so much time and effort that people can give. Time to change focus for the future.
Thanks for your continued effort all these years Eric.
Only 64-bit. Thanks Eric for all.
Until few months ago I was using 32bit -current on one of my desktops. But, for a number of reasons, I had to convert it to 64bit. So all of my desktop systems are now on 64bit -current.
From an egoistic point of view, I can say that it’s fine to drop 32bit Plasma5 packages 🙂
In the moment when Plasma 5 should become adopted by stable Slackware, it should be decided with Pat if Plasma 5 can be made available for 32bit. Or if 32bit Slackware still comes out at all.
Unrelated with this poll, just a broader thought.
I fall into no 32bit category. So only 64bit packages looks good enough to me.
I also fall in -current category. So no 14.2 packages also looks good to me.
Almost any hardware dating from 2009 and up is 64bit capable. Yes, people using hardware predating 2009 may face some trouble as they may require 32bit yet. Even so, the user base on 64bit looks big enough to keep up the evolving pace of something like Plasma 5 support for -current.
Imho, the whole Plasma 5 thing fits pretty well with -current only packages and looks quite a natural choice. Both are experiments, both may break sometimes (although quite rare), both have the role to be a test bed for upcoming Slackware release stuff.
Trying to provide a ‘production grade’ package set can be such a time consuming effort, less for the package creation itself and more for the support tasks involved. As everything -current comes with a tech savvy requirement implied, it makes a lot of sense to provide things like KDE 5 for the -current user base only, as those users MAY require less support effort.
All that said, I stand for both options 1 and 2.
For the record, this is Slackware. There’s always a 3rd alternative, and 4th, 5th… While Eric focus on a x86_64-current ‘reference implementation’, someone in the need of the community spirit can extend Eric’s work and provide 32bit/stable packages. Am I right?
It is time to cut the cord on running cutting edge software on obsolete architecture.
Hi Eric,
first of all many thanks for your work.
I would be more comfortable with plasma 5 on both current and 14.2 64 bit (option 1).
Well, I don’t use Plasma 5. I plan to use it when it enters on a Slackware stable release. Then, both options are the same for me.
On the other hand, everybody knows that your ktown repo is a test base for new versions of KDE/Plasma before it enters in the Slackware main tree. With this in mind, I think that option 2 is the best choice, because Slackware will continue to support the 32bits architecture (I guess), and you can provide well-tested packages to Slack in this way.
Anyway, thank you for your contributions to the Slackware community. And good luck in you life!
Best regards.
To me option 2 seems most logical. Although I’m using 14.2 atm. Current wil eventually go to Plasma 5 so imho it’s best you focus on that.
Option 1 for me.
Also on a separate but related note, after clearing /tmp/ plasma 5 fails to launch. Any ideas? I get the “K” splash screen and then just a black screen with a mouse cursor. Any idea?
1
I think that option 2 (“stop releasing Plasma 5 for Slackware 14.2 and start focusing on -current exclusively”) makes the most practical sense. Abandoning 32-bit wouldn’t be in the general spirit of Slackware (which still embraces 32-bit), and it seems to me that option 1 is (and has always been) a luxury (a nice luxury for those who received it) but at the same time not critical for what is intended to be a stable release (Slackware 14.2).
When I wrote “option 1 is (and has always been) a luxury”, I meant that releasing Plasma 5 for Slackware 14.2 is (and has always been) a luxury. Sorry for this confusion.
I think you should drop 32 bit just because you are making this post about it. I guess a 32 bit version will make it in current sometime before the next release. I’m curious why its not in there at the moment since 5.8 is out. I personally think any packages that you find that take a lot of work and you don’t have time for should be dropped and people should use SBo instead for those.
Rad, did you ever see Plasma 5 framework on SlackBuilds.org? Never going to happen. You can just as easily grab the sources, scripts and patches from my server.
As stated, upgrading the graphical desktops in slackware-current (such as, replacing KDE4 with Plasma5) will probably be lower on the priority list than getting all the lower-level stuff upgraded. Which means you should not hold your breath until you see Plasma5 in -current.
Drop the 32 bit version. Plasma 5 for 14.2 and -current.
All my 5 nodes are 32 bits only and they all run plasma 5
I wouldn’t think 32 bit is worth your time supporting anymore. It’s a well and truly outdated architecture and it would make more sense for you to work on something yourself use.
I use 64bit 14.2 with plasma 5. So my vote is to support plasma in 14.2 and current. Thanks 🙂
All my systems use 64-bit only!!
Btw many thanks for all you do for Slackware!!
I vote for option 1 as I run only -current on a 64 bit machine.
All my systems run 64-Bit Slackware 🙂
Hi Eric,
I still have some 32-bit-only hardware around, mostly in schools which have a notoriously tight budget. This being said, I mostly use Xfce, and when I use KDE, I’m fine with what’s provided on the stable releases.
Cheers,
Niki
Hey Eric, first of all thanks for all you do.
I vote option 1
Hi,
First, thanks for asking 😉
Then, I just use the x64 Plasma5 -current.
Best regards.
Option 1. The only 32bit machine I have is an eee-pc 1001ha, and it runs like a snail with KDE.
More thanks to add to those you’ve already had.
All my 5 nodes are 32 bits and they all run plasma5 on current
Hi,
Although I’m only using slackware64-current, I choose the second. As for 14.2 maybe just security update (ie. an update to fix crashed app) would be enough.
And not-fully related with the topic, but since you have not wrote any blog about the latest alien kde update, I’m posting it here. Sorry. Your latest CHECKSUMS.md5 in x86_64 tree is failed the gpg check, hence I cannot use slackpkg to upgrade my installation.
14.2 stable with 64 bit here
so i vote for 1
Eric, I’m sorry I forgot that you created the compat32-tools from Fred Emmott scripts. I agree that all newer hardware (post 2006) should run 64bit and also be equipped with at least 4G of memory otherwise don’t both. Actually if anyone is still, by pure luck, still using any hardware more than a dozen years (read pre-2005) old they are operating in the high risk environment, because the electronic components (mostly capacitors) are near or already at their end-of-life due to breakdown and heat wear. At most this age hardware is a hobby and never should be used in production. But I’m getting off topic. Thanks again for your precious time in helping develop the next age of Slackware. Cheers
@BrianA_MN, just don’t forget that what you call (and I kind of agree) ‘high risk environment’ is almost the rule on many, if not most, of the developing world education system.
@Niki Kovacs has a point on this matter, and hey, the guy is in France.
Anyway, I see no reason why a school elsewhere may choose Plasma 5 (or even GNOME) as their main DE/WM specially if they are running in such an old hardware. There are plenty of lightweight choices in the wild to better fit their constraints.
@Deny Dias
Anyway, I see no reason a school anywhere may choose to use Slackware, because of the lack of a basic LinuxPAM support, which make almost impossible to use iTalk, an application heavily used on Education.
Heck, really I hope in one bright day the Slackware Team will understand that sabotage themselves the spread of Slackware, in the name of some ridiculous fanboysm…
I have just upgraded KDE to the latest found on ktown repository using slackpkg and unfortunately KDE has stopped working at all:
http://i63.tinypic.com/mufms1.jpg
How can I recover my system?
Darth Vader, if you want to see how Slackware works when you bolt PAM and Systemd on top, check out DLACKWARE, for which I just uploaded a Live ISO: http://bear.alienbase.nl/mirrors/slackware-live/latest/slackware64-live-dlack-current.iso
Thanks to bartgymnast who provided the packages and who accepted my feedback to improve the quality of these packages greatly.
Justin Case – in any case you seem to be missing the package ‘libxkbcommon’. You give no details about how you exactly performed the upgrade. What repository URL did you use? What commands did you use? Please check first whether you are missing more packages from the repository that were added.
Also, next time you want to share a picture, DO NOT USE that tinypic site again. I am pretty irritated by having to watch a thousand ads and getting popups “you may also want to see this”.
@alienbob I did understand your post as your posts are simple enough to understand 😉
I wonder though, do you have some sort of a counter for how many times a package was downloaded from unique sources? Should be simple enough to set.
If those 2 options are the only options that you considered then I would vote for option 2.
option2. if kde(plasma)5 makes it into stable, it will need 32bit and 64bit, working in current. I use kde4, on stable, but do make use of your other packages like libreoffice, java and vlc, and appreciate all the time you spend on slackware stuff. thanks
Amit, there is no mechanism through which I can track if a file of mine is downloaded from a mirror that I do not control. And for the servers that I *do* control, I see that often the complete repository is downloaded (using a mirror script probably) so even when packages are downloaded and I track those, I am still not certain which of the 32bit or 64bit packages are actually installed and used…
I know I’m late, I just wanted to say thank you Eric for all you work on Slackware and you repositories, they’re very useful!
Hi!
I use both 32biat and 64bit Slackware current.
Vote option 2.
21 months late to the party, th_r…