I'll agree that São Paulo has good pizza, but there's some place in New Orleans that has better. Sadly, I can't recall the name of either establishment
The Democrats and Republicans are only different with respect to how *far* they want to crawl up your ass and what they want to do once they get there.
Gee, who gives a rat's ass. If popularity was worth a tinker's damn, then we'd all just use Windows.
If you want a distribution who enjoys being the Keeper of the Toilet Paper, then fine - use it - but leave the rest of us alone.
I won't say this for sure, but my first reaction is "YDIW." If one follows the instructions for upgrading from one release to the next, there won't be an "critically damag[ed] libraries" or "reinstall[ing] from scratch" at all. Granted, the docs are generally better since the 11.0 days (sorry, I have to toot my own horn with that), but even before then, they were good enough.
Heh, maybe I'm being dense (perhaps that's excusable after the last few weeks), but I'm not convinced that you're disagreeing with me. Anyone who is familiar with unix/linux at all, or is looking to switch to unix/linux, will immediately recognize Slackware as a linux-based operating system. Perhaps I wasn't clear about it, but my main point was "If grandma doesn't recognize Slackware as being a unix-like OS, then grandma doesn't need to know."
Quite frankly, if you don't know what it is, then you're not ready for it, so it doesn't matter.
Agreed on moneydance - I've been using it since 2004. It's a java app, but it doesn't seem "heavy" at all, and the great benefit here is that I can run it on my linux machines, my wife can run it on her Windows machine, and we can both use the same data file (which is on the home network file server).
http://slackware.osuosl.org/slackware-8.1/ChangeLog.txt -- last update was 20 February 2009
This isn't definitive, but lots of "patches" aren't patches -- they're upgrades to later releases due to upstream not providing actual patches. Sometimes that's not a problem (the new release actually is ABI-stable with the older one, or the fix is easy to backport), but in other cases, the choice is either to "fix" the security problem (which often isn't *much* of a problem anyway) or to *break* the application/library (or something else that uses it).
Generally speaking, if a security issue is serious *and* it affects a network-facing service *and* it's feasible to fix, then it's fixed in $release/patches/
Nah, there's not really a policy, and I'm not sure I can even put the decision making process into words
Ah, an old-timer who still keeps up with us; I like that three-digit id.
Just FYI, slackpkg is now in the main tree (AP series).
How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say "I told you so" when it doesn't work.