| DistroWatch Weekly
|Linux Foundation Training
|Reader Comments • Jump to last comment
1 • LPS linux (secure bootable CD), website down? (by Jan on 2012-10-15 10:47:28 GMT from Netherlands) |
The website of LPS (from the DOD, government of US) is already unreachable for more than a week.
This seems not to be a normal site-hickup.
I considered LPS as the top secure possibility for secure internetting (for simple souls like me).
However this occasion brings the question if something is really wrong.
Does anybody know what's going on.
2 • No dependency checking (by Omari on 2012-10-15 11:08:47 GMT from United States)
Somewhere I once read a comment regarding the real expense of automatic dependency resolution and why it's a good thing Slackware does not have it. It said that the virtue of Slackware is its simplicity. Because the system is relatively simple, one person (be it the user or the creator, Pat Volkerding) can hold an accurate mental model in his or her head of how the distribution is laid out and how it works. This simplicity arises from the fact that Slackware is maintained by such a small team--if Slackware had a larger team, you would either need to make the distribution more complicated in order to maintain its stability (like Debian, which is huge, but complex and therefore takes forever to release) or you would need to compromise the stability of the distribution.
The problem with automatic dependency resolution is that it takes a lot of manpower to get it right. Debian for example does dependency tracking right. It's an enormous amount of work. Here is the Debian policy manual on shared libraries:
If you are running a Debian system (as I am) do "ls /var/lib/dpkg/info/*.symbols" and look at some of these files (they are plain text). Of course Debian has automated tools to help generate these things but this is an enormous task.
So to do dependencies right, you would need a huge team and lots of policies. That would make Slackware something fundamentally different than it is today--something that is not simple. Alternatively, you can do dependencies, but not do them right. Arch Linux is an example of this (I'm sure someone will hate me and disagree with me on this.) Arch does not have thorough policies in place for dependencies. When I ran Arch, sometimes installing a package would not pull in the needed dependencies--perhaps the packager already had those dependencies installed. More frequently, you would need to update the entire system just to install a single small new package, in order to ensure that its dependencies were up to date--and if you did not do this, installing a new package would lead to mysterious breakage, without helpful error messages. Debian does not have these issues because of the enormous work they put into getting dependencies right.
So the choice is: do dependencies right and spend a ton of work on it; do dependencies poorly, in which case they might work most of the time; or don't do them at all. Slackware chooses the last route. This does not wind up being a problem as much as you might think it is, because Slackware recommends that its users install the entire base system, which will come with the libraries needed to install most new software.
The point of all this (and I can't take credit for it; I read this somewhere else) is that automatic dependency tracking is not something that comes for free. It comes with a lot of hidden costs. Adding it would change Slackware into something that it currently is not--either something complicated, or something with a feature that is not perfectly reliable. This means Slackware is not for everyone, but there are solid reasons for things to be this way; it's not just a "get off my lawn" kind of thing.
3 • Dependency (by silent on 2012-10-15 11:46:37 GMT from Europe)
There is of course slapt-get (and the gslapt GUI) that resolves dependencies for Slackware and derivatives (like Vector). Slackware is for everyone. It offers the choice. On the other hand, dependency resolution is not an issue with the official Arch repositories (of course this may not be the case with AUR or external repos). Arch is cutting edge on a rolling basis without official support for old package versions so upstream bugs pose more of a threat.
4 • Connecting to multiple machines behind a router (by bogdan on 2012-10-15 12:15:29 GMT from Romania)
why not ssh-tunnel? You can easily install dd-wrt or openwrt on a wide range of routers and just ssh to it... after that you can tunnel to any host behind that router. the advantage here is that the tunnel works both ways...
5 • LPS website (by Jesse on 2012-10-15 12:56:27 GMT from Canada)
>> "I considered LPS as the top secure possibility for secure internetting (for simple souls like me)."
The LPS distribution isn't secure and probably shouldn't be used by anyone concerned about their security and/or privacy.
6 • latest development release makes me happy! (by happysiducer on 2012-10-15 13:02:43 GMT from Germany)
I just learned in IRC, that the siduction team has released the long-awaited flavour without X (noX) in 32 and 64 bit architectures. (a development release)
A great idea for users who don't want to use the flavours available so far, or no DE/WM at all, like me. I've been waiting for such a spin for years, sidux and aptosid wouldn't deliverâ :-(
Big thanks to siduction!
7 • Slackware. (by Graham Hamblin on 2012-10-15 13:08:52 GMT from United Kingdom)
Having run Slackware since the very first version I wholehearted agree with your take on it. In those days it got around the 640k memory limit of DOS. I does exactly what is says it will do. The problem for me, a radio amateur, it doesn't do some of the things I would like it to do!
8 • Connecting to multiple machines behind a router (by Lennart on 2012-10-15 13:10:45 GMT from Sweden)
Hi, I have for many years used a reverse proxy named "pound". It takes some effort to befriend, but after that you can't live without it. Apart from doing the obvious, it also adds to your security! You can find it at:
9 • What about Security Updates in Slackware? (by tom on 2012-10-15 14:13:07 GMT from Germany)
When I look into the security update section of the Slackware website with all these update lists, I am asking myself whether e.g. Slackware 12.1 could be considered as a "safe" distro. In my opinion a lot of updates are missing, kernel and glibc updates as well as mozilla browser updates (Firefox, Thunderbird, Seamonkey).
So is this observation right?
Or is there a Slackware update policy in place I am not aware of?
10 • Why Slackware? (by Microlinux on 2012-10-15 14:33:20 GMT from France)
Quote: "Shortly after the release of Slackware 14.0 there were the usual comments from people on tech forums wondering if Slackware really brings anything worthwhile to the Linux community, if the distribution does anything which sets it above other distributions rather than merely apart."
My company (link above) uses Slackware (currently 13.37 and 13.0) as sole base for both server and desktops solutions:
1) It's reliable and stable. You can install a Slackware file server - or a desktop - in a company and pretty much forget about it. Slackware may be a dinosaur, but the main advantage of dinosaurs is it takes at least a meteor strike to take them out. Slackware users can also be pretty sure any half-assed "technology preview" will never find its way into the distribution.
2) It's perennial. Ten-year old releases still get security updates, that's longer than every "Enterprise Class" distro can claim. And Slackware 14.0 pretty much still works like version 7.1 I had more than ten years ago.
3) It's flexible. Everything that's not included can be built from source quite simply using the SlackBuild scripts from SlackBuilds.org.
4) The Slackware community on Linuxquestions.org is extremely friendly, helpful and competent.
As a side note: Jesse, don't look for binary third party packages. When looking for software that's not included in the distro, SlackBuilds.org should be your first address.
Last but not least: Slackware's dependency resolver is `whoami` :o)
Cheers from the sunny South of France.
11 • @1, secure & private distros (by Arkanabar on 2012-10-15 14:47:25 GMT from United States)
click the "search" link at the top of this page. When the form comes up, open the "Distribution Type" popup, and select "Privacy." You'll get 5 results: TAILS (The Amnesiac Incognito Live System, based on Debian), LibertĂ© Linux (based on Gentoo), LPS (site down), Privatix (Debian, encrpted ISO), and Ubuntu Privacy Remix (a live DVD which is deliberately without networking; it's meant to keep your local data secure, not your communications). Of these, I suspect that TAILS is probably the most secure, with LibertĂ© Linux running a close second.
12 • @1, secure & private distros (by Arkanabar on 2012-10-15 14:54:06 GMT from United States)
ps -- LPS is available to me here in the US, so the issue may well be elsewhere, such as your DNS or your ISP. And Jesse, it also looks like the primary use-case for LPS is telecommuting DoD workers. As long as you have nothing to hide from the DoD, no worries, eh?
13 • Slackware (by Jesse on 2012-10-15 15:23:24 GMT from Canada)
>> "2) It's perennial. Ten-year old releases still get security updates, that's longer than every "Enterprise Class" distro can claim. "
Red Hat provides 10 years of support these days, which means its off-shoots like CentOS do too.
>> "As a side note: Jesse, don't look for binary third party packages. When looking for software that's not included in the distro, SlackBuilds.org should be your first address."
If you read the review you'll already know I did use SlackBuilds, once it caught up to the latest Slackware release. However, using SlackBuilds is inconvenient, both compared to regular binary packages and other build/ports systems. It's certainly not something I would want to use on a regular basis.
14 • sbopkg (by Pat on 2012-10-15 15:31:19 GMT from United States)
>> If you read the review you'll already know I did use SlackBuilds, once it caught up to the latest Slackware release. However, using SlackBuilds is inconvenient, both compared to regular binary packages and other build/ports systems. It's certainly not something I would want to use on a regular basis.
You're right, Slackbuilds aren't very convenient if you're using a browser to download the script and source before running the slackbuild script by hand. But that's why we have sbopkg.
If what I'm looking for can't be installed through slackpkg, then I go to sbopkg. If it isn't on sbopkg, I probably didn't need it anyway ;)
15 • @13: Slackware + sbopkg = comfort (by Microlinux on 2012-10-15 15:39:46 GMT from France)
If you're looking for convenience, then I can only recommend sbopkg. I've got my own collection of SlackBuild scripts (modified from SBo or written from scratch) in an SVN repo, but if you're only using it on one or two machines, sbopkg is defnitely the way to go.
Almost as comfortable as the Ubuntu Software Center :oD
16 • Slackware install time (by claudecat on 2012-10-15 15:47:11 GMT from United States)
I'm surprised that it took Jesse over an hour to install Slackware. I haven't actually installed 14 (I run -current, so in a way, I'm already there), but 13.37 (64-bit) took maybe 10-20 minutes on both desktop and laptop if memory serves - and that was the full install. I hope folks don't get the impression that over an hour is the norm on a reasonably modern system.
As far as security updates, Slackware had Firefox 16.01 available almost immediately - before even Arch. A regular slackpkg update and upgrade-all is all you need.
17 • Slackware (by Donnie on 2012-10-15 15:59:00 GMT from United States)
I enjoyed the review on Slackware 14, and can add only a couple of points that you haven't covered.
If you point the Slackware repository configuration file to a "current" repository, you will in effect have made Slackware into a rolling release distro. I've had mine like that since the days when Slackware came with KDE 3.5, and it's worked out quite well for me. In fact, it's worked out much better than what Arch has, even though Arch is an actual rolling release distro.
Also, if you need more applications than what Slackware natively gives you, just add in the Slackbuilds repository, and manage it with "sbopkg". Just pay attention to the dependency issues that the Slackbuilds website spells out for each application, and you'll be fine.
Now, if only Slackware would support my printer, I'd be willing to make it my main distro.
18 • Slackware review & Sbopkg (by Barnabyh on 2012-10-15 16:03:15 GMT from United Kingdom)
Very nice review Jesse, I think you did it justice.
Just one small point. Since 13.37 I installed all additional packages from Slackbuilds.org with sbopkg, and it's almost as convenient as Synaptic. It compiles automatically and installs the package for you.
The only thing one has to do is find out what the dependencies are, usually also on slackbuilds, and get the build queue right. Then hit the button and walk away or browse distrowatch while it compiles in the background.
19 • Install time (by Jesse on 2012-10-15 16:22:57 GMT from Canada)
>> "I'm surprised that it took Jesse over an hour to install Slackware.
I'm not sure why that would be surprising. As I've pointed out in the past, my installs times are generally in the range of ten minutes per GB of installed data. So a distribution which dumps 3GB of data on my drive takes around 30 minutes to install, typically. 4GB takes around 40-45 minutes. Slackware's full install places more than 6GB of data on the hard drive, so over an hour is well within the normals for my equipment.
>> " I hope folks don't get the impression that over an hour is the norm on a reasonably modern system."
Fair enough, as long as you define "modern". People often complain my laptop is too modern by their standards, others complain it's far too out of date. If you're going to post installation times I recommend also posting your system specs as different people view "modern" very differently. Saying you can install Slackware's full release in 10 minutes is only relevant with corresponding system specs.
20 • Zenwalk (by Claus Futtrup on 2012-10-15 17:15:16 GMT from Denmark)
A new Zenwalk release - YEAH!
21 • Slackware, dependencies and things.. (by buntunub on 2012-10-15 17:23:40 GMT from United States)
The last of the oldies but goodies. Why no dependency checking? No good reason. They just don't do it!
22 • Seamless Upgrade (by us64 on 2012-10-15 17:29:35 GMT from United States)
"Webconverger 15 realises a design goal to seamlessly upgrade. A feature that no other Linux distribution has."
Webconverger consists of a bare, base OS with an X server running Firefox. Seriously, what could possibly go wrong in an upgrade? If it can't get that right, then maybe there's something wrong... It's no wonder other distros (and OSes in general) often suffer from this; they offer far more than just a web browser. The biggest change is probably updating Firefox itself--and Mozilla has made sure that every major version upgrade is barely more than a point release, so changing from version 4 to 12 is really more like 4 to 4.2.12 or something.
Even then, the next best thing is just keeping your home directory on a separate partition. For most people, nothing else needs to be done; it's been "seamlessly" upgraded. For others, maybe a couple of extra packages need instead--big deal, the package manager makes quick work of this. And at the most extreme, people who run daemons and have them customized to their preferences, they'll have to either back those up to /home and copy them back over to /etc when done or just set them back up.
I don't see why "seamless upgrade" in the sense of never reinstalling matters anyway; you'll eventually run into problems no matter what OS you use. Plus, a nice, fresh, clean system just feels better. Then again, it will usually be much harder to screw up a command-line only system through upgrades, so again, it depends on one thing: complexity. Still, I'll take the clean install without touching /home route.
23 • @17 Slackware vs. printer (by Microlinux on 2012-10-15 17:45:33 GMT from France)
"Now, if only Slackware would support my printer, I'd be willing to make it my main distro."
Just out of curiosity: what model is it? Maybe I can help. Configured quite a few printers on Slackware, even those that make you jump through burning loops.
24 • Slackware and Salix (by Any on 2012-10-15 18:01:53 GMT from Spain)
The last couple of days I've tried Salix and it looks like "Slackware made easy".
Has various flavours - KDE, Mate, Lxde, XFCE, Ratpoison and Fluxbox. With Glsapt I converted in short time the Mate Live edition to LXDE edition. Then installed the pure LXDE edition. Light, fast and configurable. Also there is Sourcery SlackBuild Manager - a graphical frontend.
25 • Zenwalk review (by Roland on 2012-10-15 18:29:57 GMT from United States)
Really nice XFCE system. 2 problems:
1)lilo setup @install will only write the MBR on the first disk. Multi-disk systems are not unusual. This wouldn't be hard to fix.
2)/etc/hardwareclock says 'localtime'. This is nuts. Local Time is Just Weird. We have DST, SummerTime, DblSummerTime, NewfieTime, etc. And then there are travelers with laptops. OSes including Zenwalk have facilities to deal with this stuff. They work great when they are used. Setting the hwclock to localtime bypasses all that. For the love of sanity, keep your hwclock in UTC. Other linuxes do this.
26 • Question - anyone have a favorite distro for running as guest under VirtualBox? (by Andy Prough on 2012-10-15 18:48:13 GMT from United States)
I'm looking for a very fast, easy to install, easy to administer Linux distro for use as a VirtualBox guest on a Windows Vista computer at work. Most of my experience is with OpenSUSE, but the stock version doesn't work well under this situation. I've spun my own XFCE-only version of OpenSUSE through the SUSE studio, and this is pretty zippy on VirtualBox, but its hard for me to keep up-to-date. I would prefer a lightweight distro that plays nicely with VirtualBox and is on a good 6-month release cycle. And I don't like messing around with Enlightenment, Unity, or Gnome 3 - so no Bodhi or stock Ubuntu please. I need to stick with something I know - KDE is best (for me), XFCE is OK. If something is using a snappy version/clone of Gnome 2, I would be willing to give it a spin.
Thanks in advance!
27 • @10: "Perennial" (by tom on 2012-10-15 18:52:34 GMT from Germany)
"It's perennial. Ten-year old releases still get security updates, that's longer than every "Enterprise Class" distro can claim."
Nothing is made for eternity. :-)
Please read e.g. this:
28 • @26 (by Fe on 2012-10-15 19:03:56 GMT from Spain)
I would recommend Fedora 17 LXDE edition. Very nice, fast and stable in my VirtualBox. You know zypper so you would not have problems with yum. The release cycle is exactly how you need it.
29 • Slackware Current (by Brian on 2012-10-15 19:06:02 GMT from United States)
claudecat, you mentioned Current and rolling release.
How do you run Slackware Current?
30 • Distro hopping (by Shelley Reison on 2012-10-15 19:19:03 GMT from United States)
I loveseeing all these different distributions. A couple that I really really liked last week are OS4 Opendesktop 13, Lubuntu and I tried Fedora LXDE. So far Im mixed between OS4 and Lubuntu, Lubuntu is fast but OS4 is more unique and it just seemed faster than any XFCE distroI have ever seen. I like the Ubuntu type distriutions and Fedora just seemed like a huge learning curve. You cant go wrong with either OS4 or Lubuntu. If you want music and video out of box, go with OS4
31 • greed or am I an idiot? (by Brian on 2012-10-15 19:42:35 GMT from United States)
Just curious on other peoples thoughts on a billionaire creating a free operating system then asking for donations.
Mark Shuttleworth can literally use his worth to shuttle himself to the moon.
Mark Shuttleworth's worth can support Ubuntu for a thousands of years and he'll still have millions of dollars left over. Note* Homo sapiens live only decades.
He created a free OS from Debian. Then, routes your searches through Amazon. And, pricks our ears with, "Erm, we have root." Greedily requesting more money to further an OS where he has root on your box and if he wanted to, could support the thing forever with his billions. I guess, his heart isn't in to it anymore.
Or, am I looking like and idiot and I don't even care?
32 • Re: Greed (by Mike on 2012-10-15 20:21:55 GMT from United States)
The donations don't go to Shuttleworth, in case you didn't notice. That isn't greed. It's inspired brilliance.
33 • @26 (by Sporkman on 2012-10-15 22:15:44 GMT from United States)
I use Xubuntu in Virtualbox on Win7 - works great.
34 • @28, @33 (by Andy Prough on 2012-10-15 23:23:32 GMT from United States)
@28 - I've downloaded Fedora 17 LXDE edition - I'm on my 3rd hour now of installation and updating over 800 packages. Looks like this could easily end up being a 4 hour process, as it's still got 769 RPMs to install. Not sure if this is the best one for my purposes. Doesn't seem terribly responsive on this system either.
@33 - what's the difference between xubuntu and Linux Mint 13 XFCE? Should I expect one to run faster than the other? And what about Linux Mint "Mate" - is that Gnome 2, or is that Gnome 2-looking widgets on top of Gnome 3?
35 • Slackware Review (by Looking for basics on 2012-10-15 23:36:42 GMT from Canada)
Thank you for the detailed review of Slackware 14.0 It went a long way to answering most of my questions before trying it out. Unanswered were the following points (which hopefully, someone here can answer):
1)Slackware 14.0 now includes btrfs. I seem to recall one of the holdups with this was lack of a recovery tool for this filing system. How is that presently handled? Are there any provisos to be wary of with this filing system? (eg. limitations like maybe not installing on the first partition?)
2)The review mentioned that the distro (when in X), booted up to a lower than maximum resolution. Isn't that a GOOD thing? I absolutely hate it when live distros insist on booting up at maximum resolution. Can anyone (even with a new, hi-res lcd screen) actually read anything on a screen set at such a high resolution? Short of maybe using a CAD program to layout something like a multi-layer circuit board, WHY would you even be working at such a resolution? Guaranteed to bust your eyeballs! Bad enough we have a younger generation going deaf from wearing ipads with in-ear headphones; now we are generating a revenue stream for optometrists dispensing glasses for all the newly "near-sighted" viewers squinting at these ridiculous screen resolutions.
It would be nice if live distros ALL booted up at a sane resolution (maybe 780 x 1024?), with an default icon to change resolutions, so one doesn't have to search through menus to find the the buried tool to access this.
On a related note, when did X behaviour change? You used to be able to use xf86config to set up everything. Now X seems to use XRandr, the use of which is not so clear. What happened to being able to use ctrl-alt+ or - to zoom and change resolutions on-the-fly? And ctrl-alt-backspace is gone! I seem to recall there was info regarding this buried somewhere on the xorg site, but things worked great before. There really didn't seem to be any need to "fix" things Can anyone detail how to handle things now? Maybe this topic is worthy of a review on it's own?
3)Re Slackware now not including Flash: Lately, Adobe products have been a security nightmare of their own. I don't have ANY Adobe stuff on my systems. The odd time it's needed, youtube-dl and movgrab (especially the last movgrab 1.12) work really well.
4)Why do some live distros boot up at a sane resolution (vga=769 or normal), and then partway through bootup, switch to max res so you have to squint and use a magnifying glass to see the bootup text? Defeats the whole purpose of bootup text to troubleshoot things!
Hopefully preparers of live distros will take these factors into account?
36 • Is KDE really sluggish? (by dmatt on 2012-10-16 01:13:29 GMT from Slovakia)
"At first I found the graphical interface to be quite sluggish, but after disabling desktop effects and search indexing KDE became much more responsive."
It seems that KDE always has this problem in your reviews (just gogle word "disable" on distrowatch :) . I would like to suggest different "modus operandi" for your next KDE based distro review. Install your system, apply updates, reboot and leave the system settle without turning off anything. Then reboot again and KDE would be finally in normal working mode.
If the system is still sluggish, investigate the cause. Change QT graphics system backend to different one (XRender/Raster/OpenGL) or suspend desktop effects for fullscreen windows or limit file indexing to certain directories or even turn some feature completely off. But please only one at the time, so we know which one was the culprit of bad performance.
This way KDE gets some reasonable feedback and users are not led to false assumption that KDE is universally slow in default configuration - with desktop effects and file indexing turned on. If there is a problem, make it clear where it is and if it could be fixed. A reader who habitually turns both functions off (cough, cough) might actually try them this time and find them useful based on such review.
I would not write this if there were not lots of performance improvements, important fixes and tuning options introduced during 4.7-4.9 development to both mentioned functionalities. So the results really might differ from ones obtained one year ago.
Problematic performance of KDE in VM is also being addresssed http://blog.martin-graesslin.com/blog/2012/10/a-journey-through-virtualization/
(I would recommend this blog for everybody interested in KDE graphics performance).
My own system is 3+ year old notebook pretty similar to your testing system. Mine works fine with default KDE and I would like to read in reviews how it works for other people, given fair chance.
37 • Slackware and Podcast list (by jprzybylski on 2012-10-16 02:24:09 GMT from Canada)
I've been a Slackware user for a few years now, and I can't stop using it. I build lots of software and toy with system scripts now and again, and Slackware makes it extremely easy to do both things. Better yet, it never complains. When I use Slackware, I feel like I'm using MY system - not what somebody thinks it should be.
Looking at the podcast list, I didn't see the Linux Action Show in there. Give a quick look over at http://www.jupiterbroadcasting.com/tag/linux-action-show/ and check out a couple episodes - they like mentioning Distrowatch now and again.
38 • @19, @29 (by claudecat on 2012-10-16 02:39:34 GMT from United States)
Jesse - I should have specified my gear when I mentioned my surprise at your hour+ install time for Slackware. Desktop is a 2009 Compaq SR5510 (Athlon 64 x2 5000+) with 4GB ram and Nvidia GT240 graphics card - not exactly a screamer. Laptop is an Acer Ferrari One 200 (1.2GHz AMD Athlon 64 X2 Dual-Core L310 - 4GB ram - ATI Mobility Radeon HD 3200) - again fairly mid- to low- end by today's standards. Not having experience with Intel dual core machines, I assumed that my gear wasn't all that much more powerful than yours, if at all, hence my surprise that my install times (admittedly with the 13.37 64 DVD) were so much faster. I'm no expert on relative speeds of processors, etc. so I'm sure I'm ignorant of something here.
Brian - you can run Slackware current with a simple change to your mirrorlist. DW did a nice (if brief) synopsis of the process a few years back:
39 • IPv6 (by Joel on 2012-10-16 03:21:40 GMT from United States)
IPv6 is a great way to connect to multiple machines behind a home router. You don't even need ISP support for IPv6. You can use a tunnel broker like hurricane electric or just set up 6to4 tunneling. Might make a good howto to talk about IPv6 sometime.
Good Slackware review. I still have it on my home server. Running IPv6 of course.
40 • @35 Looking for basics (by Didier Spaier on 2012-10-16 07:46:38 GMT from France)
Here are some short answers. If you need more accurate or thorough ones, better ask on http://www.linuxquestions.org/questions/slackware-14/, please open one thread per question.
1) btrfs has its caveats. It's proposed at time of Slackware 14 installation as well as other file systems but the default still is ext4.
2) On Slackware 14 but in some cases (using proprietary drivers comes to mind) there is no need to use an X config file any more. xrandr is not really meant to replace X configuration tools anyway.
3) Flash has no future in Linux. It's included in Google Chrome though (not part of a standard Slackware installation but can be installed afterwards).
4) At time of Slackware 14 installation you can choose the resolution you prefer.
41 • KDE (by Jesse on 2012-10-16 12:31:37 GMT from Canada)
>> "It seems that KDE always has this problem in your reviews (just gogle word "disable" on distrowatch :) . I would like to suggest different "modus operandi" for your next KDE based distro review. Install your system, apply updates, reboot and leave the system settle without turning off anything. Then reboot again and KDE would be finally in normal working mode."
Two things. First, while KDE is usually sluggish on my machines with the default settings (as you correctly point out), this is not always the case. My recent review of openSUSE, for example, pointed out that the OS was quite snappy, even with all the effects and features turned on. I think this is important as it demonstrates openSUSE is doing something right with KDE that most distribution are not. For that matter, another distro I reviewed recently came with unwanted features disabled which made for a really good out-of-the-box performance. My point being that some distros manage to ship KDE implementations which work great on my hardware and I think it's important to point that out. And when distros ship KDE implementations which work poorly with my system I think it's important to point that out too.
Which brings me to my second point. I'm not going to change my work/review habits in order to cater to one project. The point of the review is to demonstrate how well a distribution works for me, not how well I can make myself conform to the quirks of a distribution. If a distro ships with poor defaults for my environment it should be told that, I shouldn't have to apply updates, reboot, walk away for half an hour while it indexes just so I can get passable performance out of my desktop. The system should work out of the box.
42 • Re: #36 and #41 (by Leo on 2012-10-16 13:10:24 GMT from United States)
I agree with Jesse, and disagree with DMatt on this one. I am an avid KDE User, with Kubuntu in two of my machines (it used to be in all of them). I basically had to spend a lot of time turning stuff off in order to have something that doesn't take too long to boot up, and doesn't slow to a crawl. I had to disable effects, disable search (nepomuk), and uninstall the whole KDEPIM in all my machines so i wouldn't have akonadi fill up my disks or make things slow.
This is just bad design on our part. Plasma should be light and flexible, so you can build on top of that, _modularly_. Then, as a user, in Dolphin, you get an option to turn indexing on, and you get warned that it could slow down your system. And so forth.
But what did we do? We built a rather monolithic piece, we tell people "no, you can't turn akonadi off", and we criticize people pointing out performance issues. This is not helping the most beautiful and functional desktop.
It took me a good long afternoon of work to move my main machine (with an account i maintained for 12+ years) to use Thunderbird instead of KMail, since the move to KMail2 would have my email freeze 2 minutes just indexing the folders. This is crazy stuff, and the only reason it hasn't killed KDE altogether is that it's still the best option in many ways. But we are definitely moving in the wrong direction.
43 • KDE (by dmatt on 2012-10-16 13:43:23 GMT from Slovakia)
Well, you dealt with all Slackware quirks quite well, if you ask me ;).
Nevermind, I like your reviews and this was only small bit which bothered me.
I wanted to get the word out. Hopefully some users would give second thought to KDE and overcome its initial setup quirks.
Btw, OpenSuse might be just plain lucky to be the first one to ship KDE4.9.2 with substantial indexing fixes http://vhanda.in/blog/2012/09/nepomuk-and-kde-4.9.1/ .
I am looking forward to future reviews :) .
44 • @34 - MInt & MATE (by Uncle Slacky on 2012-10-16 15:38:21 GMT from France)
Mint is similar to Xubuntu, but comes with all the "restricted extras" already in place, and Mint's own software centre, menu & updater.
MATE is a GNOME 2 lookalike & workalike - all the libraries and apps have been renamed and forked, so that it can cohabit (if necessary) with GNOME 3. Mint's own "reworking" of GNOME 3 is Cinnamon (which can be installed on other distros if you want to try it, e.g. Xubuntu, Fedora...).
45 • Slackware package management, here's why! (by Slacky the Penguin on 2012-10-16 15:57:08 GMT from Israel)
Slackware package management, and I mean what comes with the OS, not add ons from outside the distro that other people have mentioned in the comments above, is about packaging what *you* decide belongs on *your* system. In theory Slackware is harder to use because it doesn't track the dependencies but it allows you total control over what goes on your system. Most of the package-managed distros and the big 3 BSD (4 if you count DragonFly) offer you dependency management but they quickly get bloated. Why do you need gstreamer and gnome-vfs to run rox-filer? You don't, but the package builders have to target mainstream use and often include everything anybody might want. Personally I think it's a crisis to ./configure --help and then download a few tarballs to build an app I want. It sure beats installing a small app and dragging a dozen non-dependencies with it.
I can install a new Slackware release in about 20 minutes. It always works. It never does anything bad. My systems stay clean and lean, because *I* manage my own packages and I don't use gstreamer or gnome-vfs! Those are just examples but you get the point.
The Slackware community is another great reason we run Slackware. The people are helpful and hardly ever tell you to RTFM and they don't do the GPL idol-worship thing. It's not about religion or boredom or empty philosophies, it's about Linux and getting things done no muss no fuss! If you're a drama queen you probably want a political distro. If you're a Windows victim you probably want Ubuntu. If you just want to get on with it, you want Slackware.
46 • Arggh embarassing typo! (by Slacky the Penguin on 2012-10-16 15:58:37 GMT from Israel)
I wrote "Personally I think it's a crisis to ./configure --help" when I should have written "Personally I DON'T think it's a crisis to ./configure --help" Sorry!
47 • @45,46 (by notsure on 2012-10-16 16:52:58 GMT from United States)
Well Said. It is also trivial to change how a bundled app may behave:
ie... links on slackware does not have the -g option configured at compile time for a nice, fast graphical web browser, something i use, so i just download the source, pat v's slackbuild, change 3 things and ta-da. simple AND fun.
48 • Slackware review (by grindstone on 2012-10-16 17:47:34 GMT from United States)
I ran Slackware for quite some years and there are a couple things that I never really see mentioned. Call it full-disclosure for those who may be considering it.
After the initial setup, keeping-up with patches and upgrades is easy enough. In small bites day-in and day-out, maintaining the system was actually rewarding in the education it necessarily-provided.
It's true, the first version or even 3 of Slackware took me a long time to get installed and configured the way I wanted, but that, too, was a learning process. Many slack-folk have developed their own means (tagfiles, scripts) of more-rapidly configuring a new installation. The honest answer is that, the first time I ran Slack, it took me 6 months before I found I was no longer missing a single thing). At the end, it was 3 weekends (and because I started minimal and built a lot on a slow machine). That brings up my second point.
I never liked a recommendation of "do a full install" (to ensure you have libraries/deps for whatever may arise). The more software, the more bugs, the more exposure, the longer the seeks, blah blah. The selections of software in the installer have been a sore spot. It's true you can have 100% complete control and spend a bleery-eyed day reading each package description and choosing--and that may/not run. In that respect, VL, ZW, and some others have a considerably more convenient (and known working) selection system (while trading choice). In the old days, one could start small with ZipSlack and strip a couple things and add from there. That was a great service that Patrick performed--revising those selections as sizes increased. Starting small and adding always made more sense to me, which brings-up my third point.
Slackware is old/boring/stable/reserved/conservative. Ah, uh-uh. ./configure anyone? Really. I always ran newer application software on Slackware than on other systems because I could always just build it (and I didn't even run -current). Yes of course one can build on almost any system, but--and this is the core of the comment--Slackware, by virtue of what it does not do, _allows_ you to assume responsibility. It's built-in. It's an open-door from the very first docs. The comments in the scripts and docs are extensive, detailed & respectful if not inviting. When you first configure your machine and build whatever other "must have" software you need, well, do that enough times and some stuff sinks-in ;) Then, when you notice a revision or new update, you just do it again and suddenly you have a System and you are Empowered. It takes you from "I use the upgrade-thingy" to "I upgraded this lib because I use X & Y & Z that need it and I need that fix/capability/etc."
If you start small-ish and stay that way, these massive floods of updates such as with some of the larger rpm-based things are just inapplicable. You don't have it so you don't _have_ to patch it--and what's more, you _know_ you don't have it.
One down-side I remember was not wanting to "break" it when I first started. It seemed a completely opposite feel from say the .deb-based things which were like a candy store. In those, I remember just apt-ing up whatever and going nuts just to explore lots of software--I got more applications running in way less time by apting binaries vs. building things of course and it was great fun. Debian helped me learn which applications I liked best fast (and I both respect and love Debian as well). Then, I could go ahead and build the newer versions in Slackware confident I wouldn't have to run parallel sets of libraries and play linking games.
Well, most other things are mentioned so I'll stop there.
After you learn it, it's like your best pair of shoes--except that the shoes never wear-out & they never fail. If they break, you broke them, you instantly know exactly how, and you can unbreak them ;)
The biggest thing is that the feeling of running something for years is different than a year or two (let alone a month or two). By 2012, a lot of us have run a lot of things for quite some time. The longer I run Debian, and the longer I run Slackware, the more I appreciate both. These insights are very tough to delineate in detail.
Heck--the very fact that one _can_ run the same system and just upgrade for Years and Years _is_ a major point.
49 • Re: #45 (by Leo on 2012-10-16 17:47:57 GMT from United States)
I actually used Slack back in 1995-1997 or so. As soon as I discovered package managers I never looked back (RedHat, then Mandriva, then Kubuntu)
My problem was not so much dependencies, but really uninstalling. Of course that was a long time back. But the issue was simple and unresolved last time I checked: you could "./configure; make; make install". But you couldn't "make uninstall", and get rid of the gazillion files in /var , /usr , /etc , and so on. Have they addressed that?
At the end of the day, free software is about this. Some like Fedora, some Arch, some *buntu, some prefer Slack, there is room for everyone. It is ALL about freedom and flexibility. Gotta love it.
50 • Thanks, Jesse (also @4, @8, @39) (by AliasMarlowe on 2012-10-16 17:50:48 GMT from Finland)
Hi, Jesse, the question you answered was from me. It's good to hear that my fast-and-filthy approach is not completely insane. We're not talking high-traffic sites here, so it has been a "good enough" solution so far.
@4: My router is not supported by DD-WRT or Tomato or OpenWRT or any of the other firmware replacements. If only it were...
@8: I'll certainly look into Pound, and appreciate both your recommendation and your caveat regarding effort.
@39: Alas, my router is IPv4 only, although all of the machines behind it support IPv6 (various linux boxes). Routers priced for home use and which support IPv6 are not yet available here. I've looked briefly at 6to4 brokers like Hurricane Electric, but am reluctant to involve a third party unnecessarily in routing each packet.
51 • @48 grindstone (by Didier Spaier on 2012-10-16 20:44:27 GMT from France)
I always do a full installation of Slackware, including applications I am absolutely sure I will never use, with the only exception of the KDEI series (but the *fr* packages). Why?
(1) I doesn't hurt. I have enough room on my laptop's HDD to host all these packages and that doesn't slow down my system ain any way. I simply do not start services or daemons I don't use.
(2) I doesn't take that much time to apply security upgdates. "slackpkg update" then "slackpkg upgrade-all", et voilĂ if your are lazy. Nevertheless I always read the comments in the Changelog or the security advisories Slackware send me, just in case.
(3) I'm sure I will never miss anything, in particular any library to which some application I would install afterwards could happen to be dynamically linked to.
(4) I am a http://slackbuilds.org user and the README pages only mention dependencies not included in Slackware.
Of course I accept that other Slackware users prefer to install only what they will use. I just wouldn't recommend newbies to do that, unless their learning plan include finding the dependencies through a try and error process ;)
52 • @49 Leo about uninstalling on Slackware (by Didier Spaier on 2012-10-16 20:55:47 GMT from France)
"slackpkg remove" or "removepkg" or "pkgtool" with the "remove" option will cleanly remove any official Slackware package. In addition the two latter commands can remove any package intended for Slackware, be it an official or a third party one.
The "make uninstall" method is not recommended because:
(1) Their is no guarantee that it uninstall cleanly.
(2) Not all Makefiles include an "uninstall" target.
Using exclusively the tools included in Slackware to manage its packages will keep your system in good shape. I believe this is true for other distributions as well.
53 • Slackware 14 review (by Looking for basics on 2012-10-16 21:30:59 GMT from Canada)
40 re 35
Thanks for the reply. I want to revert back to the old xf86config way of being able to specify multiple resolutions in a virtual terminal so I can change resolutions on the fly with ctrl-alt + and ctrl-alt-. What tool (internally)is now being used to configure resolution during install? Was hoping to get an idea of how this now works before doing an actual install. Should have a chance over the next week to get access to a spare computer to try this out on before risking mucking up my main working system. The review did not touch on this aspect of the install, and I like to understand things beofre I "break" them. Oh well, at least on the backup, I can experiment and find out (hopefully) for myself.
Also, thanks for mentioning the linuxquestions site. Didn't find the answer to the above posted there, but DID find a "hack" to boot linux from a btrfs partition.
49) re uninstalling apps - I use checkinstall. This "sandboxes" the installl process, and creates a binary from the source package, which can then be installed and uninstalled with package tools (installpkg, removepkg, etc.)
Be aware there was a problem when a kernel change occured. With version 1.6.1, I have to run checkinstall --fstrans=no to avoid problems. Version 1.6.2 is supposed to fix the need to do that, but I seem to recall some other complication. You could also use version 1.5.3, but it not only creates the binary, it automatically does the install as well. With 1.6.1, it only creates the binary. Then you have to manually install the binary (which I find preferable, because I may only want to create a binary, and maybe install later/elsewhere; not necessarily install now). There are other such tools, but checkinstall is nice, because, in addition to "tarballs", you can also create rpms and debs.
Hope that helps...
54 • Slackware installer (by Nick on 2012-10-17 00:24:23 GMT from Greece)
Calling the Slackware install unfriendly is unethical at the very least.
I will be eagerly waiting about your Fedora 18 review to see what you're going to call the new Anaconda.
55 • @44 (by Andy Prough on 2012-10-17 05:33:17 GMT from United States)
Interesting - what I'm finding after going through quite a few distros is that Mint 10 LXDE is actually about as fast as I can get on VirtualBox on this computer. Anything from Mint 11, 12, or 13 or using KDE or Gnome 3 in any way shows a lot of latency, especially when streaming music. However, running Mint 10 LXDE on VirtualBox, even as a live-cd, is very smooth. Its great that Mint keeps all their older versions easily accessible for download.
What really surprised me was what a dog (pun intended) Puppy Linux was under VirtualBox on this setup. That was a complete disaster - no good way to go about resolving all the serious problems without taking a lot of hours.
56 • Re: 41 and 42 (by Pierre on 2012-10-17 09:41:09 GMT from Germany)
I agree with both, Jesse and Leo, too.
And my suggestion is:
The KDE Team or at least the distributions developers should provide a configurations screen on first boot to the new OS with some first run configurations on KDE, like 'Do you want Desktop Effects to be turned ON?' and 'Do you want File Indexing (Nepomuk) turned ON?' so that everyone could make their choice according to the system they are running the KDE distro on.
This would avoid a sluggish system on the very beginning, or everyone does it like the openSUSE Team. ;) Just release a rock solid distro that is responsive even though desktop effects and file indexing are enabled by default.
In my opinion openSUSE managed with their 12.2 release to deliver the best distro at the moment, especially when you are using KDE as desktop environment. With openSUSE 12.2 I am able to run KDE now even on my laptop without any performance problems what means a lot considering that even the KDE centric distro Chrakra failed to run responsive and stable on my Lenovo IBM ThinkPad R60 which is at least 4 years old already.
57 • Thank you #52 and #53! (by Leo on 2012-10-17 12:47:57 GMT from United States)
Awesome comments, thanks! Things have come long ways in the last ... 15 years, lol. Time flies!
I googled a bit, it seems that dependencies are not take care of, by pkgtool and installpkg, right? That would be the only missing thing? How do I know that uninstalling package A doesn't hurt Package B? (or that B needs C). Some of these can be detected automatically, I think, at compile/link time.
Anyways, it is so nice to see Slackers enjoying around! Cheers!
58 • Some thoughts about "automatic" dependency resolution (by TobiSGD on 2012-10-17 16:53:00 GMT from Germany)
Automatic dependency resolution doesn't exist. Dependency resolution always has to be done by humans. The question is who does it. In the case of distros with "automatic" dependency resolution the information which packages are dependencies for this one package is gathered by the package maintainer. This is in fact convenient for people who don't want to bother with things like that, nothing wrong with that.
The downside of this approach is that it is totally ignoring the fact that a lot of software can be compiled with optional dependencies. many packages on distros with "automatic" dependency resolving are compiled with some of those optional dependencies and this is in fact removing their optional status. They simply aren't optional anymore, since the package manager will complain and often refuse to work if those formerly optional dependencies aren't installed. You have to use what the package maintainer things is the right package for you.
This is different on Slackware. Because there is no such thing like an automatic dependency resolver (in the standard install) you have to take care of that by yourself. but you also have the freedom to decide which optional dependencies you need and which not. So you are not a mere "human dependency resolver", but you are your own personal package maintainer, and luckily this is made so easy by Slackware's straightforward package design, the set of tools that come for this purpose pre-installed and the easily alterable scripts from SlackBuilds.org that it is actually a no-brainer to maintain your packages.
May be this can be better shown by a cooking analogy: Distros with automatic dependency resolvers are like getting a frozen pizza from the supermarket. You don't have much choice what is on the pizza, the manufacturer decided that. You may be able to put some cheese or other things on it (like Firefox plugins or GStreamer codec packages), but that's it. On Slackware you are given a nice kitchen with nice tools, but you have to make the pizza yourself, which of course gives you the freedom to make any pizza you want.
You have to decide which one you prefer.
I choose the kitchen for my main systems and some frozen pizza (Salix) for systems I don't want to bother with.
59 • Dependency (by Jesse on 2012-10-18 00:07:38 GMT from Canada)
>> "Automatic dependency resolution doesn't exist. Dependency resolution always has to be done by humans. "
It's quite often true that humans are involved in the dependency resolution process, but it isn't always the case. There are packaging systems which will automatically track dependencies without human interaction. In fact, a while back DWW featured a tutorial on building packages with fully automated dependency resolution. You might find it interesting. http://distrowatch.com/weekly.php?issue=20100531&m#qa
60 • Slackware 14.0 review (by Alex on 2012-10-18 00:27:01 GMT from Germany)
Fair review, I'd say. I just want to add, that the well-known slapt-get mentioned in the article is just the oldest, but not the only one 3rd party tool helping with package management.
A very helpful tool is the (n)curses based sbopkg, that makes installing packages, for which there are build scripts available at SlackBuilds.org, a breeze. See here: http://sbopkg.org/.
Another amazing tool is src2pkg, which helps to create Slackware packages from source tar balls and foreign package formats, such as RPM or DPKG. See here: http://www.src2pkg.net/
My final tip is slackyd. It's an alternative to slapt-get, available from the excellent repository of the Italian Slackware community. The tool cannot not only be used to install packages from http://slacky.eu/, but also to check for updates from Slackware.com, unresolved package dependencies, missing files and libraries. While it can resolve package dependencies, when they are maintained, it still complies with the Slackware philosophy, that control as well as responsibility is fully in the hand of the user (administrator). It doesn't resolve any dependencies and install additional software without asking the user, first. Personally, I prefer slackyd over slapt-get, although I must admit, that I haven't tried the latter for several years (since I found slackyd).
Regarding the topic of dependencies and how they should be dealt with, I found that one of the reason why so little ever goes wrong is exactly, that Slackware doesn't try to automize what cannot be automized without making assumptions about the target system and its users. So it's not actually the technical mechanism of resolving dependencies, that causes trouble, it's the fact, that the definition and maintenance of dependencies is based on assumptions made by the respective maintainer, which may be more or less correct for a given target environment, but not for all possible target environments.
The typical package maintainer tends to define all libraries and applications as mandatory dependencies required to use all the functionality of a given program. However, the user might only need a fraction of this. In an RPM or DPKG based distro, the application cannot be installed without all the other stuff. In Slackware, just the stuff wanted can be installed, while unneeded and unwanted stuff can be kept out.
Yes, of course, I know, dependencies can be defined as being optional, but the problem is, that this is a decision to be made by the package maintainer, whose ideas are based on what he wants to do himself and maybe on statistical evaluation of user feedback.
Don't get me wrong: I am not saying, that there is anything wrong with other distros using dependency resolving package management. I have been using (and still use occasionally) OpenSUSE, and the package management works remarkably well, and it has become incredibly fast in recent releases. But I have never managed to upgrade any system with a dependency resolving package management more than twice without doing a fresh install. Last time I ran into trouble with a box that was initially installed with OpenSUSE 11.2. The upgrades for 11.3 and 11.4 went smooth, but after upgrading to 12.1 there were unresolvably conflicts: Akonadi was claimed to need a less recent MySQL client than the one included with 12.1, and my attempts to remove Akonadi, then upgrade MySQL and then to re-install Akonadi, also failed.
I just say, that this is not the only way to do things, and that there are good reasons for the way it's done in Slackware. One of these reasons is, that less assumptions about target environments are required for package management.
But as I said: Overall, a fair review!
61 • @59, automatic dependency resolver (by TobiSGD on 2012-10-18 10:07:59 GMT from Germany)
In that article it is only mentioned that one can auto-populate the library-folder.
I would like to know how this program handles optional dependencies. Sadly, this program seems to be obsolete and the howto linked from their site gives a 404 error.
62 • Slackware Dependencies (by William Barath on 2012-10-18 15:17:03 GMT from Canada)
Slackware's lack of dependency checking never once bothered me when I was using it. Sure, you install a package, run it, and see it fail due to missing a library, then install the library, then repeat the process until it runs. Or you install a daemon and it fails to start, then do the same process via "/etc/init.d/[daemon] start" or in the very worst case you run an app and it silently fails to fork a process because another package isn't installed, but generally you find that dependency very quickly via the README or via "strace -vf &>wtf.log" by running the app, killing it with xkill immediately after it silently fails to do something, then reading the tail of the log.
But - I have to do those things on OpenSuSE, Fedora, and Debian too. Not often. Usually in conjunction with 3rd party repos. And lets face it - we need those 3rd party repos to do many of the things we want to do.
If I'd never run Slack I would never have learned how to do manual dependency resolution. If I'd learned to drive on a Mercedes with auto-everything I'd be helpless to drive any other car on the road.
Do you want to be helpless? If so, never run an SLS or Slack-based distro. ;-)
Now on the other hand, automatic dependency resolution can be a serious PITA. Much like an automatic transmission can be. I'm in a corner at 80MPH, near the apex, wheels chirping, and worried I'm going to oversteer so I back off the accelerator a bit. With an automatic transmission it's probably going to shift up on me, which is bad for several reasons - 1) it's going to rock the car while I'm close to sliding, by dropping the engine RPM sharply, perhaps making me roll or slip. 2) it's going to cut power to the wheels then suddenly provide a short burst of power as the torque converter engages the higher gear, perhaps causing my drive wheels to spin/slip. 3) it's putting me in the wrong gear to accelerate out of the corner. With the auto you are at the whim of something which has the IQ of ... well... a gearbox.
Apt-get is really great, but like with the automatic transmission you are at the whim of the package maintainers' notions of what a 'dependency' is when you install a package with it. dpkg on the other hand has no such notions. It will warn you but it won't pull in various and sundry. Various and sundry aren't really a problem for a desktop user - most of the time. For a server administrator though every extra package is a possible security problem, or a possible configuration mangler. And the package maintainers are not God. They don't know whether version X of Y library will satisfy the needs of Z app, especially when Z app was released before X library was built. They don't know whether you will use all the features of Z app. Often they assume incorrectly that everyone will, and make something which could have been a 'recommends' into a 'dependency'. gvfs and gstreamer are good examples. I never want them, yet inevitably they get installed on every dependency-tracked OS I've installed.
Where OpenSuSE, Fedora, and Debian (and their ilk) really shine is in auto-configuration of their installed apps. Again, if you don't mind being helpless, in exchange for some Daimler-style hand-holding.
I am the first to admit that after the first 2.5 years using Slackware, I was pleased to find out how productive I could be within an hour of installing a Debian-based distro, whereas with Slackware I was still fiddling with config files a week later. That's changed... now I'm fiddling for a week with the app selection and the desktop environment instead, lol, and the choice of distro... meh... hardly matters.
63 • Dependencies discussion (by Leo on 2012-10-18 15:50:41 GMT from United States)
Thank you all for the contributions, they were pretty informative and a great read. I do wonder how does this approach differ from the "source" distro's like gentoo. Any thoughts, is any of our slacker friends also a Gentooer, and they would perhaps shed some light? Cheers!
64 • Re: #64 â€˘ ubuntu 12.10 (colin) (by Leo on 2012-10-18 18:56:15 GMT from United States)
My boot times went down, though I am using razor-qt as the desktop on my atom netbook+ssd, and overall it went from ~18 to ~14 sec for a full desktop login.
Sandybridge doesn't seem to have improved much:
But I would expect much better support for very recent (ivy bridge) processors/APUs.
65 • Xubuntu 12.10 PAE kernel (by Alessandro di Roma on 2012-10-19 07:45:07 GMT from Italy)
Xubuntu 12.10 has a PAE kernel? I'm sorry for Xubuntu 12.10! My Acer non-PAE laptop works very well with Xubuntu 12.04 LTS. At 12.04 end-of-life (april 2015) I'll look around for another distribution...
66 • PAE kernel (by @65 on 2012-10-19 11:42:51 GMT from United States)
You should be able to "sudo do-release-upgrade" to Quantal and still keep using the non-PAE kernel.
67 • ownCloud Article in DWW Issue 475 (2012-09-24) by Jesse Smith (by Pierre on 2012-10-19 15:26:46 GMT from Germany)
I am aware that the article I am referring to is a few weeks old already but I just read it today and the comments section of that older DWW Issue is closed so I just thought that I should post my comment here.
Jesse did well with the article, but I have found one sentence that needs - in my opinion - some correction.
Jesse wrote: "One drawback of using the web interface is that file uploads are limited in size to 2MB."
This is actually false because the 2 MB limit of file size for uploads is not something that the ownCloud developers did implement but is a configuration issue coming from the php.ini where the maximum size of file uploads is defined. So it seems that Ubuntu sets it to 2 MB by default, but you can easily edit the php.ini in /etc/php5/apache2/ and set it to what ever you want and consider right - for me I have a 1 GB limit set, even thought hardly anyone of my friends will be so crazy to upload such a big file with the poor upload most of them have. :)
So, just wanted to see mentioned that it's just about configuration, even an php configuration, and has nothing directly to do with ownCloud itself.
And another thing: Setting up ownCloud is not only straightforward on Ubuntu or if it's installable out of the distributions repository. Apache HTTP Server, MySQL database and PHP installed and configured, ownCloud files downloaded, extracted to the HTTP Server's document root, maybe change the owner to the distribution's webserver user and you can already access it on localhost/ownCloud/. All that's left to be done is setting up it's admin account and the access to the MySQL database and you are done.
If that is not enough there is a short but good enough documentation on how to set up owncloud on the project's websites. :)
Greetings from Germany!
68 • @65 Xubuntu 12.10 PAE kernel (by Shelly Reison on 2012-10-21 00:09:47 GMT from United States)
OS4 OpenDesktop 13 which is a derivative of Xubuntu and one of the better ones still uses the non-PAE kernel. The more I play around with this distro the more I like it.
69 • @ 36 KDE (by Blue Knight on 2012-10-21 19:28:11 GMT from France)
> This way KDE gets some reasonable feedback and users are not led to false assumption that KDE is universally slow in default configuration - with desktop effects and file indexing turned on.
Are you kidding? In your post, precisely you give recipes for making KDE less slow and so, this is no longer its default state...
Personally, I confirm KDE has some problem for instance with this stupid thing which is the indexing tool. I always stop this useless crap.
70 • LPS (by Herbert Thornton on 2012-10-21 18:32:11 GMT from Canada)
I've found I can download LPS here, but it's an earlier version -
I've also discovered that 2 versions of MacPup - (MacPup 528 and MacPup 529) - will do a very similar job to LPS - i.e. they will work on a computer that has no hard drive.
One of them (MacPup 528) is running on an old computer with no hard drive right now & I'm using it to send this. Both MacPup versions use Firefox, but I like version 528 better because I prefer its earlier version of Firefox.
71 • latest LPS (by james c on 2012-10-21 19:40:41 GMT from United States)
The latest version of LPS (Sept. 14) is available from http://www.spi.dod.mil/docs/LPS-1.3.6_public.iso
72 • LPS now USA only ? (by Jan on 2012-10-21 20:56:54 GMT from Netherlands)
It seems that LPS is now only available within the USA.
Number of Comments: 72
Display mode: DWW Only • Comments Only • Both DWW and Comments
|• Issue 843 (2019-12-02): Obarun 2019.11.02, Bluestar 5.3.6, using special characters on the command line, Fedora plans to disable empty passwords, FreeBSD's quarterly status report|
|• Issue 842 (2019-11-25): SolydXK 10, System Adminstration Ethics book review, Debian continues init diversity debate, Google upstreaming Android kernel patches|
|• Issue 841 (2019-11-18): Emmabuntus DE3-1.00, changing keys in a keyboard layout, Debian phasing out Python 2 and voting on init diversity, Slackware gets unofficial updated live media|
|• Issue 840 (2019-11-11): Fedora 31, monitoring user activity, Fedora working to improve Python performance, FreeBSD gets faster networking|
|• Issue 839 (2019-11-04): MX 19, manipulating PDFs, Ubuntu plans features for 20.04, Fedora 29 nears EOL, Netrunner drops Manjaro-based edition|
|• Issue 838 (2019-10-28): Xubuntu 19.10, how init and service managers work together, DragonFly BSD provides emergency mode for HAMMER, Xfce team plans 4.16|
|• Issue 837 (2019-10-21): CentOS 8.0-1905, Trident finds a new base, Debian plans firewall changes, 15 years of Fedora, how to merge directories|
|• Issue 836 (2019-10-14): Archman 2019.09, Haiku improves ARM support, Project Trident shifting base OS, Unix turns 50|
|• Issue 835 (2019-10-07): Isotop, Mazon OS and, KduxOS, examples of using the find command, Mint's System Reports becomes proactive, Solus updates its desktops|
|• Issue 834 (2019-09-30): FreedomBox "Buster", CentOS gains a rolling release, Librem 5 phones shipping, Redcore updates its package manager|
|• Issue 833 (2019-09-23): Redcore Linux 1908, why Linux distros are free, Ubuntu making list of 32-bit software to keep, Richard M Stallman steps down from FSF leadership|
|• Issue 832 (2019-09-16): BlackWeb 1.2, checking for Wayland session and applications, Fedora to use nftables in firewalld, OpenBSD disables DoH in Firefox|
|• Issue 831 (2019-09-09): AdĂ©lie Linux 1.0 beta, using ffmpeg, awk and renice, Mint and elementary improvements, PureOS and Manjaro updates|
|• Issue 930 (2019-09-02): deepin 15.11, working with AppArmor profiles, elementary OS gets new greeter, exFAT support coming to Linux kernel|
|• Issue 829 (2019-08-26): EndeavourOS 2019.07.15, Drauger OS 7.4.1, finding the licenses of kernel modules, NetBSD gets Wayland application, GhostBSD changes base repo|
|• Issue 828 (2019-08-19): AcademiX 2.2, concerns with non-free firmware, UBports working on Unity8, Fedora unveils new EPEL channel, FreeBSD phasing out GCC|
|• Issue 827 (2019-08-12): Q4OS, finding files on the disk, Ubuntu works on ZFS, Haiku improves performance, OSDisc shutting down|
|• Issue 826 (2019-08-05): Quick looks at Resilient, PrimeOS, and BlueLight, flagship distros for desktops,Manjaro introduces new package manager|
|• Issue 825 (2019-07-29): Endless OS 3.6, UBports 16.04, gNewSense maintainer stepping down, Fedora developrs discuss optimizations, Project Trident launches stable branch|
|• Issue 824 (2019-07-22): Hexagon OS 1.0, Mageia publishes updated media, Fedora unveils Fedora CoreOS, managing disk usage with quotas|
|• Issue 823 (2019-07-15): Debian 10, finding 32-bit packages on a 64-bit system, Will Cooke discusses Ubuntu's desktop, IBM finalizes purchase of Red Hat|
|• Issue 822 (2019-07-08): Mageia 7, running development branches of distros, Mint team considers Snap, UBports to address Google account access|
|• Issue 821 (2019-07-01): OpenMandriva 4.0, Ubuntu's plan for 32-bit packages, Fedora Workstation improvements, DragonFly BSD's smaller kernel memory|
|• Issue 820 (2019-06-24): Clear Linux and Guix System 1.0.1, running Android applications using Anbox, Zorin partners with Star Labs, Red Hat explains networking bug, Ubuntu considers no longer updating 32-bit packages|
|• Issue 819 (2019-06-17): OS108 and Venom, renaming multiple files, checking live USB integrity, working with Fedora's Modularity, Ubuntu replacing Chromium package with snap|
|• Issue 818 (2019-06-10): openSUSE 15.1, improving boot times, FreeBSD's status report, DragonFly BSD reduces install media size|
|• Issue 817 (2019-06-03): Manjaro 18.0.4, Ubuntu Security Podcast, new Linux laptops from Dell and System76, Entroware Apollo|
|• Issue 816 (2019-05-27): Red Hat Enterprise Linux 8.0, creating firewall rules, Antergos shuts down, Matthew Miller answers questions about Fedora|
|• Issue 815 (2019-05-20): Sabayon 19.03, Clear Linux's developer features, Red Hat explains MDS flaws, an overview of mobile distro options|
|• Issue 814 (2019-05-13): Fedora 30, distributions publish Firefox fixes, CentOS publishes roadmap to 8.0, Debian plans to use Wayland by default|
|• Issue 813 (2019-05-06): ROSA R11, MX seeks help with systemd-shim, FreeBSD tests unified package management, interview with Gael Duval|
|• Issue 812 (2019-04-29): Ubuntu MATE 19.04, setting up a SOCKS web proxy, Scientific Linux discontinued, Red Hat takes over Java LTS support|
|• Issue 811 (2019-04-22): Alpine 3.9.2, rsync examples, Ubuntu working on ZFS support, Debian elects new Project Leader, Obarun releases S6 tools|
|• Issue 810 (2019-04-15): SolydXK 201902, Bedrock Linux 0.7.2, Fedora phasing out Python 2, NetBSD gets virtual machine monitor|
|• Issue 809 (2019-04-08): PCLinuxOS 2019.02, installing Falkon and problems with portable packages, Mint offers daily build previews, Ubuntu speeds up Snap packages|
|• Issue 808 (2019-04-01): Solus 4.0, security benefits and drawbacks to using a live distro, Gentoo gets GNOME ports working without systemd, Redox OS update|
|• Issue 807 (2019-03-25): Pardus 17.5, finding out which user changed a file, new Budgie features, a tool for browsing FreeBSD's sysctl values|
|• Issue 806 (2019-03-18): Kubuntu vs KDE neon, Nitrux's znx, notes on Debian's election, SUSE becomes an independent entity|
|• Issue 805 (2019-03-11): EasyOS 1.0, managing background services, Devuan team debates machine ID file, Ubuntu Studio works to remain an Ubuntu Community Edition|
|• Issue 804 (2019-03-04): Condres OS 19.02, securely erasing hard drives, new UBports devices coming in 2019, Devuan to host first conference|
|• Issue 803 (2019-02-25): Septor 2019, preventing windows from stealing focus, NetBSD and Nitrux experiment with virtual machines, pfSense upgrading to FreeBSD 12 base|
|• Issue 802 (2019-02-18): Slontoo 18.07.1, NetBSD tests newer compiler, Fedora packaging Deepin desktop, changes in Ubuntu Studio|
|• Issue 801 (2019-02-11): Project Trident 18.12, the meaning of status symbols in top, FreeBSD Foundation lists ongoing projects, Plasma Mobile team answers questions|
|• Issue 800 (2019-02-04): FreeNAS 11.2, using Ubuntu Studio software as an add-on, Nitrux developing znx, matching operating systems to file systems|
|• Issue 799 (2019-01-28): KaOS 2018.12, Linux Basics For Hackers, Debian 10 enters freeze, Ubuntu publishes new version for IoT devices|
|• Issue 798 (2019-01-21): Sculpt OS 18.09, picking a location for swap space, Solus team plans ahead, Fedora trying to get a better user count|
|• Issue 797 (2019-01-14): Reborn OS 2018.11.28, TinyPaw-Linux 1.3, dealing with processes which make the desktop unresponsive, Debian testing Secure Boot support|
|• Issue 796 (2019-01-07): FreeBSD 12.0, Peppermint releases ISO update, picking the best distro of 2018, roundtable interview with Debian, Fedora and elementary developers|
|• Issue 795 (2018-12-24): Running a Pinebook, interview with Bedrock founder, Alpine being ported to RISC-V, Librem 5 dev-kits shipped|
|• Issue 794 (2018-12-17): Void 20181111, avoiding software bloat, improvements to HAMMER2, getting application overview in GNOME Shell|
|• Issue 793 (2018-12-10): openSUSE Tumbleweed, finding non-free packages, Debian migrates to usrmerge, Hyperbola gets FSF approval|
|• Issue 792 (2018-1203): GhostBSD 18.10, when to use swap space, DragonFly BSD's wireless support, Fedora planning to pause development schedule|
|• Issue 791 (2018-11-26): Haiku R1 Beta1, default passwords on live media, Slax and Kodachi update their media, dual booting DragonFly BSD on EFI|
|• Full list of all issues|
Star Labs - Laptops built for Linux.
View our range including the Star Lite, Star LabTop and more. Available with a choice of Ubuntu, Linux Mint or Zorin OS pre-installed with many more distributions supported. Visit Star Labs for information, to buy and get support.
|Random Distribution |
LGIS GNU/Linux was a modified version of Red Hat Linux with Ximian Desktop 2, Ximian Evolution mail client, Ximian Red Carpet software management tool and OpenOffice.org office suite. It was primarily designed for desktop use.