A grave bug has been introduced into the "wine" package of Debian Jessie, just days before the November 5th freeze deadline. The /usr/bin/wine launch script fails with an "error: unable to find wine executable. this shouldn't happen." message.
Debian has already suffered much unrest lately over the inclusion of systemd, with threats of a fork being issued, along with the possible cancellation of the GNU/kFreeBSD port and the possible dropping of support for the SPARC architecture. After so much strife and disruption, can Debian afford to have such a serious bug affect such a critical package so soon before such a major freeze?
(Score: 2) by Arik on Saturday October 25 2014, @03:24PM
That's where you are wrong. Give it a try. It's a wonderful system and virtually anything you used on another OS that is not included in the base install is available as a slackbuild.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @03:38PM
How easy is it to keep a Slackware system up to date? It's very easy under Debian: "sudo apt-get update && sudo apt-get dist-upgrade". Is it that simple under Slackware? Are the Slackware packages kept as up to date as the Debian ones are?
(Score: 2) by arashi no garou on Saturday October 25 2014, @04:39PM
Install slackware-current, install slapt-get and configure it for slackware-current, and you have a rolling-release OS with up to date, bleeding edge packages. It's like Arch without the sado-masochistic, user hating project leaders (and no systemd! ).
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @04:50PM
I like the no systemd part, but how much effort does the rest of it actually take? Like "configure it for slackware-current", is that as simple as editing /etc/apt/sources.list is under Debian?
How frequently are the packages updated? Let's say a new version of bash or Firefox is released today. How long will it be until I can install it using the Slackware package management tools?
(Score: 2) by arashi no garou on Saturday October 25 2014, @05:12PM
Like "configure it for slackware-current", is that as simple as editing /etc/apt/sources.list is under Debian?
Pretty much, yeah. See http://software.jaos.org/git/slapt-get/plain/README [jaos.org] for details.
How frequently are the packages updated? Let's say a new version of bash or Firefox is released today. How long will it be until I can install it using the Slackware package management tools?
Even though it's fairly bleeding edge, Pat and the Slackware team still test each package before releasing it to the -current tree. So, there is some delay from source release to an official Slackware package release, even on -current. For example, take gimp-2.8.14. It was released in source format by the GIMP authors on August 26th, and the slackware-current package was released on October 25th (today), two months later. Of course, you're always free to build your own package using a Slackbuild and the most recent source, but any testing is your own responsibility in that scenario.
In my mind, that kind of thing is what makes Slackware the most versatile OS out there. Stick with the stable branch for optimum stability at the cost of current features, use the -current branch for fairly up to date packages that have been vetted by the Slackware team, or roll your own packages as the source is released for the absolute bleeding edge, warts and all.
(Score: 2) by HiThere on Saturday October 25 2014, @06:55PM
Is there a stable tree?
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by arashi no garou on Sunday October 26 2014, @08:42PM
Yes, and you can configure slapt-get to work with stable package releases just as easily. Here are the changelogs for stable 32-bit and 64-bit respectively:
ftp://ftp.osuosl.org/pub/slackware/slackware-14.1/ChangeLog.txt [osuosl.org]
ftp://ftp.osuosl.org/pub/slackware/slackware64-14.1/ChangeLog.txt [osuosl.org]
(Score: 2) by HiThere on Monday October 27 2014, @05:45PM
Nice. This is going back on my list.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by CRCulver on Saturday October 25 2014, @04:24PM
So I have to stare at compiler output for hours before I can run lots of popular Linux software on my computer, as opposed to just installing a conveniently packaged deb/rpm like on any other system? No thanks. I do like Slackware for certain niches, but the Slackbuild system makes it a pain for conventional desktop installations.
(Score: 0) by Anonymous Coward on Saturday October 25 2014, @05:13PM
Building from source isn't a problem for C code, since C code compiles really fast. But it's fucking unbearable for anything written in C++. Like if you want Firefox and KDE installed on Gentoo, be prepared to wait a week, even on expensive, fast modern workstations.
(Score: 2) by arashi no garou on Saturday October 25 2014, @06:09PM
If you don't want to wait for the source to compile to use a slackbuild, you can always use the pre-built packages available from some of the core Slackware team, like AlienBOB's packages at http://www.slackware.com/~alien/slackbuilds/ [slackware.com] or Robby Workman's at http://rlworkman.net/pkgs/ [rlworkman.net] . If you don't trust those sources (and for the record, I do but I've been using Slackware more or less since 1999, so I feel safe with them), you can always build your packages from source when you sleep. Recently I built Chromium from the slackbuild and the latest source to test a bug in the notification area (specifically, to see if it really had been fixed in the latest source release); I started it around 6pm, watched some TV and ate dinner, went to bed, and the next day it was ready.
Generally, when using slackbuilds via sbopkg, I've noticed that most simple packages compile in a matter of seconds or minutes, with some GUI apps taking about half an hour to an hour, and very few complicated packages (the aforementioned Chromium, Firefox, GIMP, etc.) taking several hours. This is on an old Core 2 Duo machine, which is my Slackware workhorse and not my main workstation, so I can afford to have it churning away at slackbuilds while I get things done on my main rig.
(Score: 2) by Arik on Saturday October 25 2014, @11:29PM
What kind of idiot stares at compiler output? Seriously, wtf?
First off, just about anything you could possibly want is already available as a binary, so if you're the type that would rather have a whopper than a filet mignon, go for it.
But if you do want to (or, much less likely, need to) compile something, you act like that's some sort of chore, so clearly you've never done it. It's no chore at all. On modern hardware it's usually something that can be done in seconds, after all. Sure, compiling something huge (like say you decide to recompile your entire KDE installation just for fun) can take some time, but it's not like you would be forced to do that (binaries for big compiles like KDE and GNOME are easily obtained) and even if you want to do it, you dont sit and stare at compiler output. You press enter and then go to sleep/lunch/the park whatever while it works. When you come back it's done.
The computer is supposed to be your servant, not your taskmaster.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Sunday October 26 2014, @01:08AM
What else is he supposed to do, use Chrome during the 8 hours it takes to compile it? Or should he use KDE during the week it takes to compile it instead, maybe? Oh, wait, none of that is possible. You can't use the software until it's done compiling!
(Score: 1) by Pino P on Monday November 24 2014, @12:48AM
Then download the binary for the generic architecture and use that in a chroot while compiling a fully optimized build.