Nope, but a 4 year old is a hell of a lot less likely (or motivated) to see porn than a 13 year old if you put a filter on the computer. It's not putting your kid in a straight jacket. Guess what? Healthy 4 year olds don't want to see porn! Do you take your toddlers to see gore movies, too? It's not hard to accept that letting a little kid see a scary movie is a mean and careless thing to do, because it will give them nightmares and make them cry. Do you think porn is any different or easier for them to handle?

With Debian and its kin, not only can you house all of those on a single system, you can easily define which is the default firefox by way of a symlink or dpkg alternative.

KDE basically already does what you're asking it to.

KWin supports tiling, and various window-switching options, including clones of all those available on Windows and OSX.

Krunner is an excellent launcher. If you're a touch-typist and you know what app you want by name, path or function you can launch it without looking.

You can also set arbitrary keyboard shortcuts to launch programs, run scripts, or even make DBUS calls. You can also change/assign KWin's shortcuts, generally or according to different rules based off of the app in question, or any window property.

FWIW, I'm a KDE user who doesn't like menus or icons either. My desktop doesn't have either, and I have no problem launching and managing my applications. I haven't even taken advantage of most of the customizations I've talked about, either.

Exactly what are you missing?

I've generally found Kubuntu's package delineation to be more modular than Chakra's, and I think the package names make more sense in that they don't include the category to which the package belongs.

The faults of Kubuntu are mostly related to maintaining parity with Ubuntu in terms of special extensions and customizations. Occasionally there's an art update that Ubuntu receives but Kubuntu doesn't; KDE's interfaces for NetworkManager don't work as well as their Gnome counterparts, but Kubuntu still ships with NetworkManager; the Ubuntu one interface for KDE is unstable/doesn't exist; Canonical hasn't commissioned an Amarok plugin for the Ubuntu One music store like they made for Rhythmbox.

To me, though, I just want functional KDE & Qt packages with tastefully/conservatively applied downstream patches, in a timely manner.

Because of that, I've actually been wondering if I wouldn't be happier on Debian unstable, since it would be more or less the same but I'd be free of the 6-month release cycle.

However, I don't think the Kubuntu guys do a bad job at all, and when people repeat that whole "the KDE devs are good and the Kubuntu devs just come in and mess everything up", I feel the need to push back because I know it's unfair and untrue.

To illustrate: Jonathan Riddell seems to me to be the most prominent Kubuntu developer; whenever I go to modify a KDE package I see his name in the changelog. But Riddell isn't just a Kubuntu developer, but also a KDE developer! He contributes code to KDE, and he is an active member of the community as well.

I don't think any of the Kubuntu devs are incompetent. Kubuntu just isn't the focus of Canonical, while resources are limited and their overall desktop design needs to be unified. So if you want a distro as committed to two DE's as, say, OpenSUSE, those expectations won't be met. But in terms of _distributing_ KDE, they do a fine job.

I don't really even think of Kubuntu as a distribution in its own right. That's just a LiveCD installer with particular defaults. I'm a KDE user on Ubuntu. So maybe that explains why I feel my needs are being met when others don't, and why my stance is different. And I just want to repeat that Kubuntu contributes to KDE upstream, and using a schizophrenic view to blame the Kubuntu developers and absolve the KDE project is a cop-out to commenting on a more nuanced reality.

Although it's more or less off-topic at this point, I'd like to hear what you like about Arch vs Ubuntu. I wrote rather... um, enthusiastically about my formation of the opposite opinion here. I'm definitely interested in your differing experience if you're willing to share it.

I've run all of the above distros at different times within the past five years, and today I'm running Kubuntu because I prefer it. I use the Kubuntu Team's update and backport PPAs to keep up with the latest KDE packages, which usually come out soon after the source release (same day) and work just fine. In fact, last year I remember upgrading to some newer release of KDE on my laptop, with Kubuntu, and having to wait for those same updates on my desktop, running Chakra. There are other, more meaningful technical reasons I prefer Kubuntu over Chakra (and its formerly-parent distro, Arch), OpenSUSE and Mandriva. But I don't feel like announcing my preferences as gospel at the moment, so I'll just say this:

I've been disappointed in Kubuntu in the past, and that's part of why I used various other distros during that time. But today it's working fine for me, as it has for some time, and with no signs of stopping. This undeserved Kubuntu hate is getting old.

Can you even name a place that rents PC games?

There are actually some old Model M keyboards with built-in trackpoints and mouse buttons. I happen to have one downstairs, and it's pretty well executed. The trackpoint doesn't get in the way at all. With that thing, you never have to take your hands off the keyboard at all.

The Model M I'm typing on was made in 1988, before I was born. Maybe this keyboard will be around after I'm gone, too.

I've personally found that one of the biggest advantages of taking a course at a community college vs a big university is that there are more people 30+ years old. In every class, there is a time almost daily that one of these students has insight to offer that they've gained from the professional world (eg. working in the healthcare industry) or their personal lives (having kids makes you a valuable asset to any psychology class :-). There are a lot of things I'd never get to hear or understand if I was just in a classroom full of my peers (college-age kids).

In a non-academic context, I've always been fascinated by the stories I've heard from old folks. It's almost unbelievable the amount of jobs and cities and roles that can be crammed into one person's life. So I imagine I'd see the same principle, but to a greater effect in a class with a few elders in it. I would love to see seniors come to study at my university simply because of how much I think it would benefit _me_.

It's sad to say, but I probably couldn't care less about the licenses of those games. The platforms they run on are all generally so closed down that whether or not you're legally allowed to modify them barely matters.

The other thing is that big, famous games tend to either continue or start franchises. Branding is a huge thing in gaming, much more than in other software, IMO. Even if there were a mechanically adequate replacement for any of these, it wouldn't necessarily satisfy.

Releasing the source code (of at least the game client), and allowing re-use and remixing of skins and models, etc. of a game would be a relatively safe move for games whose revenue are based on subscriptions. For other games, I don't know that releasing them as open source from day one is as reasonable of an option. I think, though, that we can do a lot better in terms of openness than we generally are doing in gaming.

To return to the phrase you pulled from my post: when good F/OSS alternatives to a piece of software don't exist, that would fall into the "unusual" category, where I don't make recommendations. I phrased it that way because I know that sometimes there are no viable alternatives.

My desire to see more F/OSS in games isn't based solely in principle. Besides fulfilling a moral obligation not to eternally hoard information and culture from society, F/OSS games have allowed for some of the coolest mods around. I'm very into that, and I've had a lot of fun playing games that are largely based on the code of their predecessors. In the absence of the ideal licensing scheme, well documented APIs and the allowance of modifications in general has a similar effect.

Allowing (some form of) derivative works is the driving force behind a lot of the value in games and series like Warcraft, Starcraft, Diablo, The Elder Scrolls, Neverwinter Nights, Half-Life, and recently/famously Minecraft. I've enjoyed modability in the handful of console games I've played that allow it as well. I dig SSMB:B's level editor, and you can bet that I've got my Wii rigged up to run the homebrew BalancedBrawl mod.

Allowing members of the public to build upon your creative and technical works fosters the creation of some really cool shit. To do so in the form of giving them source-level access to your material necessarily allows them to do even cooler shit.

It's not about the inherent value of any particular license. Freedom to derive is the thing I'm after, and I'll encourage that in whatever form it comes, be it powerful in-game scripting engines, feature complete level-editors, an API suitable for total conversion mods and entirely new games, or ideally, the raw source code itself.

You definitely don't have dependency hell in a high-level package manager like Synaptic, or its CLI brethren, apt and aptitude. Unless your distribution is broken (and most aren't), your end-user package manager will handle the dependencies for you automatically.

As for browsing packages in a hierarchy, I think you have a point there. Viewing the repository as a dependency tree should be possible, and, if implemented correctly, quite elegant as well. There may already be some package managers that do this.

The granularity thing is a lame complaint, IMO. Without that granularity, installs would always be huge, and tweaks to small portions of a suite of apps would require large downloads and recompilations. What you really need is something that hides much of that complexity for you. In that case, using Synaptic is looking in the wrong place. Try the Ubuntu Software Centre, which is designed to do what you want Synaptic to do.

Two-part installs for games do suck. But lawmakers and lawyers would be better people to brainstorm with about this than developers.

The main default edition is Linux Mint Gnome 32-bit edition. Linux Mint is a dolled up Ubuntu re-spin, and as such I'd say it probably emphasizes the same release as its parent distro.

In any case, they should all generally work equally well. Instead of looking for an official endorsement, glance through a handful of screenshots and pick whichever one feels best to you.

When there's an expectation for "default", or "official" versions of anything, its easy for us to become worried when we don't see that. But even in the absence of canonical guidance, choice doesn't have to be hard.

If you need assurance, then let me assure you that you'll be happy with whatever choice of desktop environment you make. And why not? You're the one choosing! ;-)

I believe all software should be free (as in freedom).

Do I avoid software that isn't released as F/OSS? Yes.
Would I criticize that software, and/or recommend alternatives to others? Yes, usually.
Would I seek to punish or rebuke companies who release their software as F/OSS only after a few years waiting period? No.

I might want more community accessibility than Id's model allows, but I'm supportive of anyone who "comes to the light". I want (and advocate!) for bolder licensing schemes on the part of companies that approach F/OSS with hesitation. But at the end of the day, something is better than nothing. As long as the contribution isn't a disingenuous one (as indicated by things like TiVo-ization and patent encumbrance), I'm glad to have it.

I actually kind of like the idea of a licensing scheme that progressively gives up more rights to the public. I think having "all rights reserved", then allowing non-commercial derivative works, then allowing non-commercial reproduction/redistribution, and finally complete freedom (a la public domain) is a graceful way to fulfill of the original spirit of copyright-as-monopoly. But of course, as a card-carrying FSF member, I'm even happier about works (of software and culture) that begin as free, open community projects.

If you're willing to be pushy about it and it really matters to you, take advantage of the accessibility of F/OSS and learn about Plone setup and configuration over a couple weekends on your own. Go to your boss and tell him that if he's dead set on some other solution, you can do it, but there's no good reason not to use Plone; you're already competent with managing it, you know the features it has, you've set it up before, and if he okays it you can have the system deployed at no cost out of his pocket in a short period of time.

Again, this is a pushy way of handling things. Some bosses might not like it; some might see it as taking initiative. It would also feel like a pretty crappy investment of your time if it didn't work out, or you didn't learn the system as well as you claimed to have done. But I think the "I can already do it (for free) and I know it's good enough" is the strongest pragmatic argument you can possibly make.

IMHO, Arch Linux is only good for those with very shallow technical inclinations. For all of my significantly technical use cases, Arch felt like a sham to me.

Off the top of my head, here are some of the things that drove me crazy about Arch.

Up until very recently, Arch Linux had no proper "multilib" support. This meant that in order to compile 32-bit packages on my 64-bit host, I had to recompile GCC. There was a package for this with AUR, but it broke regularly and had to be recompiled, sometimes with patches applied by hand, and with other hacks. This is a problem for me because I like to run a custom Wine, which has only a (useful) 32-bit version. Very recently, the Arch devs put out an official "multilib" repository, which brings them up to par with every other distro I've used. Maybe now their 64-bit updates will stop being days or weeks behind their 32-bit updates.

Speaking of AUR: it sucks. For the uninitiated, the Arch User Repository is an unofficial, source-only repository of supplementary Arch packages. Cool, right? Except that the official package manager (pacman) can't access AUR. Instead, users choose from a set of independent pacman wrapper scripts which download the source packages from AUR, build them, and call pacman to install the newly-built packages. Cool, right? Except that what is by far the most common of the wrapper scripts (yaourt) has been basically unmaintained for years. To top it off, these wrappers are always slow at grabbing AUR packages, because standard procedure is apparently to re-index/re-cache the repository every time its searched. Okay, okay... but these are all *extra* packages anyway, so quit fussing! Except that many, many packages which are available for other distros are only available to Arch users through AUR. As salt in the wound, many AUR packages are "built" by downloading DEB and RPM files, extracting the binaries, moving them, and relinking them. The pattern is vaguely prevalent throughout AUR, but there's no definite procedure for doing this. It's just up to the package's "build" script.

AUR aside, the official package manager, pacman, is pretty unimpressive itself. It doesn't use an indexed cache for fast searching (one AUR/pacman wrapper called tupac does, but pacman doesn't know anything about the tupac cache, so you have to use tupac exclusively for it to help you). It doesn't have a feature for removing obsolete packages, but there are a few different sort-of solutions on the wiki that use existing pacman features and bash hackery to emulate the functionality of things like aptitude or apt-get autoremove. Get this: you can't replace one package with another that "provides" it from a local package on the command line, even though you can with packages installed from an external repository. This applies regardless of the package file itself! In the case of replacing/superseding old packages with others (like forks, compatibility layers, or wrappers), Arch Linux will refuse to install if ANY of the files in the package exist on the system. Standard behavior, but often, the "conflicting file" is a symbolic link used to choose between two versions of a library (eg. the NVIDIA GL.so vs the MESA GL.so), or a sample config file (eg. /etc/samba/smb.conf.example).

Some more minor gripes:
-More than a few official Arch Linux packages install things to /opt and /usr/local for no reason apparent to me.
-Despite Arch's "minimalist" philosophy, their packages are generally less granular than those of a "bloated" distro like Ubuntu. Google "KDEMOD" for a historical, infamous example of this

I already know how to make my own Debian packages; Arch's simple binary package system's offer of easy recompilation means little to me. I've also spent some time with Gentoo, which made AUR seem like a cheap, ugly ripoff. Even with custom-built versions of the standard packages, I found myself disappointed with Arch's ripoff of revdep-rebuild for finding and packages that needed recompiling afterwards. Arch doesn't even offer me anything unique by "combining" the source-based and binary elements; Sabayon Linux does a much better job of it by drawing on the entirety of Gentoo in the place of AUR. Calling AUR "gigantic" in front of someone who's used Gentoo is laughable, especially considering that Gentoo's packages are signed and maintained officially. And you can be _damn_ sure that those packages won't be some kid's weekend experiment with wget and alien.

Arch Linux isn't totally horrible, and it has a decent community. But if you expect a wide range of official packages, or the robustness of apt or yum, it feels like a dirty trick when you test Arch's promise of customization and experimentation. As a highly technical user, I'm much happier on (K)ubuntu, despite the stereotypes regarding both distros.