Cool.

Well, sort of. Debian has a tool 'debsums' to check package checksums and thus installed package integrity. (You'll likely want to run 'debsums -s' to report only errors.) However this isn't installed by default, nor is it commonly discussed or advertised, whereas the equivalent for rpm, 'rpm -Va', typically is. So it's not that there isn't a tool to do the same job, it's just that it's not as well known. Likewise with dependencies; if one uses 'atptitude' you can get both forward and reverse dependency lists, and with 'deborphan' you can find orphaned packages that can be removed. [As you can probably tell, I'm more comfortable with these tools than with the RPM counterparts.]

I don't personally see major speed improvements in RPM (yum/rpm on Fedora) over DEB; and if install speed were important, Arch is clearly fastest from what I've seen. ;-) If zypper/rpm on OpenSuSE is faster than DEB I wouldn't doubt it, but that wouldn't be a motivator (for me) to switch distros.

:-( Yeah... it's a lot easier to "explain away" issues than actually try to help with them. From the point of view of the person "helping", it "solves" the problem. I see this kind of thinking a lot on LUG mailing lists -- it's frustrating.

Most hardware these says comes with UEFI (or soon will), but more to the point you cannot guarantee that you will be able to know whether the hardware comes with UEFI or not. And regardless, you own that hardware now, so telling you to buy new hardware isn't reasonable. I forget if FreeBSD requires a different solution than the Grub2 shim, but hopefully there's a solution for it soon too.

I read about it before running into install trouble because of it, but all that does is remove the surprise factor. ;-)

Took me a bit to figure out that LMDE = Linux Mint Debian.
During the "top 25 distribution" tryouts I had I tried it, and admittedly I like LMDE more than the Ubuntu-based Linux Mint. However as jimshatt pointed out, that will not solve the social problems that Debian has, because both Mint and Ubuntu want packages to go through Debian first... so as a package maintainer you end up being in exactly the same position as you were before.

:-( Secure boot is a nightmare. On top of some UEFI bioses not having the option to disable it, another option is required to enable "legacy boot" mode; where "legacy" in this case means "anything other than Windows 8". Some bioses allow disabling Secure Boot, yet still don't have a "legacy boot" option. :-/

What I'm really dissappointed by is that some manufacturers (Lenovo, for one) don't seem to include anything about UEFI bios settings in their documentation for laptops they sell. I recently had to do an install on a Lenovo P500, and on this box getting into the UEFI bios requires pressing a separate tiny button on the side of the laptop while the laptop is off. See the text on Page 20 and the diagram on Page 5 of the following document (which doesn't ship with the laptop):

      http://download.lenovo.com/consumer/mobiles_pub/ideapad_z500p500_ug_v1.0_july_2012_english.pdf

Matthew Garrett has a signed "shim" for Grub which the other distributions which will let them boot even when the "secure boot" option is enabled; so OpenSuSE will have this solved soon. Hopefully Debian soon will as well.

      http://mjg59.dreamwidth.org/20522.html

I started with Slackware, then switched to Debian in late 1999 and have been using it since. However I recently tried a bunch of distros, one of which was OpenSuSE (12.1) with KDE4 and I was surprised at how much I liked it. If I ever switch away from Debian, OpenSuSE would be one of my top choices. I also liked Arch (super-fast package installs, but there's no graphical installer) and Vector Linux (based on Slackware but with package management). I also liked Fedora 17, but for obvious reasons I don't currently consider it a condender. :-/

Concerning RPM-based distros I'm assuming you're referring to the improvements via YUM rather than RPM internals. (Correct me if this isn't the case.) Debian has actually improved on some of the DEB packaging tools; it isn't obvious because the development of DEB tools starts from the source package side first. I mostly like the Debian packaging system -- it's still the best package management system that I know of -- except that it's a bit complicated to create source packages, especially if you want to use Git while doing so. If I were to complain about Debian and reasoning for leaving it, it would be more along the lines of social problems within the Debian community rather than technical issues.

Actually my favorite of Gerry Anderson's work was the TV series UFO https://en.wikipedia.org/wiki/UFO_(TV_series)
Space 1999 was good when I was a kid, but when I re-watched it as an adult I found it terrible -- the show needed better writing. [A few of the episodes are still good though.]

She speaks informally, but I don't think that denotes anything about her intelligence.

I've met her in person; she's previously spoken about Debian at NYLUG and spoke during DebConf10. During her speeches at DebConf10 she used a bunch of 'lolcats' pictures in the slides; it wasn't just to be cute, it was for effect and to hold everybody's attention, and it worked. I believe this is a matter of choosing her presentation and her words to fit her audience.

Regardless that Einstein didn't do this, when I saw Jeff Goldboom's character do this in The Fly, I thought it was a good idea. (Imitating Chris Rock): "Yeah, that's right I said it! Right here on Slashdot I said that shit." ;-)

As long as the clothes chosen beforehand look fine or fit the person's particular style, I don't see anything wrong with planning ahead concerning what you're going to wear for the rest of the week.

I'll have to look for that; thanks.

Unfortunately after having a look at it, I agree. That said, I consider Gnome 3 to be a usability disaster, so there are good reasons why people are trying to get back the functionality they had with Gnome 2. Cinnamon is 3D only and Mate works in 2D. My choice as a fallback is Xfce. [I primarily use KDE 4, with Nepomuk and Strigi (in "Desktop Search") turned completely off.]

A couple of notes concerning Mate, Cinnamon, Xfce, and KDE 4. Note that I'm writing this from a "Debian point of view" rather than it being Ubuntu-specific, simply because I don't run Ubuntu (for a bunch of reasons).

I've recently tried Mate and Cinnamon, and they have a common problem: they don't seem to respect the "Debian menu". i.e. there are normal menu items that don't show up and instead you get the menu that Mate or Cinnamon wants to show you. My experience (in testing Ubuntu-based distros in VMs) is that Mate works in 2D, but Cinnamon is 3D-only, so it sucks to run Cinnamon in a VM. Mate hasn't been accepted into Debian, so it's not even an option for me to run right now. There are DDs that don't want it to be included, partly because it (supposedly) depends on old Gnome 2 libs, and partly because they'd rather see more effort put into Gnome 3 (which I cannot stand using). Cinnamon isn't in Debian either, probably for similar reasons. I've looked at both the Mate and Cinnamon packages available in the upstream repositories and both seemed to need work and didn't appear to be stable yet, and installing them via the external repositories looked troublesome.

Xfce is great, and what I generally recommend today, especially on low-end systems. Users I've given it to seem to like it too. The only thing I don't like (which is not really a problem with Xfce itself) is that Debian has changed the default network manager used for the Xfce task from wicd to network-manager, but this is is fixable because the package is a Recommends rather than Depends, so this is a minor complaint. I think the reason for the default change is that network-manager is IPv6 enabled where wicd is not. I've had several problems with network-manager that I don't have with wicd though, which is why I stick with wicd.

KDE 4 is good, but only if you turn off Nepomuk and Strigi file indexing, otherwise it runs terribly. [I'm primarily a KDE 4 user and love it otherwise.] These settings are in K->Settings->System Settings within Workspace Appearance and Behavior -> Destkop Search. It isn't easy to figure out what you'll be giving up by turning these features off, but thankfully someone has come up with a web page and document that explains these features. https://kdenepomukmanual.wordpress.com/2012/02/06/detailed-kde-nepomuk-manual/ One additional interesting thing to note about KDE 4 is that it can do compositing (or not, your choice, easily switchable via Alt+Shift+F12) without using compiz -- instead it's built-in. KDE 4 also has several rendering engines for both raster and OpenGL, so it works on both 2D-only and 3D enabled systems.

As for Unity -- no. 3D only so it sucks to run in a VM, and it interferes too much with how I work. Also I'm told that Unity is an add-on to compiz, and that systems that run for days get slower over time and eventually compiz crashes requiring a restart of X.

I'll mention this because it's what I'm doing and I haven't seen anyone else suggest it yet.

What I personally do for remote help is to use SSH with X forwarding directly, without using anything like VNC. I always set up SSH servers on non-default ports and also install fail2ban "just in case" a remote attacker actually finds the SSH servers and tries to brute-force them -- of which no attempt has ever been made so far. [And I can say that because I also set up 'logcheck', tweak logcheck to filter out noise so that it only reports actual issues, and then I actually read the resulting emails it sends.] In addition I also set up a "pre-shared" ssh key with no password and copy the key to the remote router so that the password to log into the router is not passed over the 'net, and also disable root logins. (Okay -- call me paranoid. :-P)

One place I've found with simple instructions for setting up pre-shared ssh keys:
    http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/internet/node31.html

And although I know I could do the same thing to log into the user's box through the router via pre-shared keys and ssh-agent forwarding:
      http://unixwiz.net/techtips/ssh-agent-forwarding.html
instead I don't actually bother to do so, and just use a normal ssh password login to the user's box.

Login steps to get to user's box:
      - log in via SSH to the remote router, with X fowarding
          ssh -l (normal_user_username) -X -p (port) (remote_router) # ex: ssh -l mooha -X -p 1022 router.mydomain.com
      - log in via SSH (as a normal user) to the user's box, with X forwarding
      - su to root on user's box
      - su to that user
      - tell the user to quit the program they're having a problem with
      - run the specific program they're having a problem with myself and have a look

Upsides:
    - secure
    - gives user some privacy (can't see their screen)
    - never "take over" the user's mouse
Downsides:
    - can't see the user's screen
    - need to know the actual program name to run, rather than using the menus in the window manager
    - difficult to have a look at "non-application" programs such as desktop widgets (which is usually not a problem)

I'm running KDE 4.8.4, which is what is in Debian Unstable. Before a presentation I did on KDE4 for my local lug I tried Strigi/Nepomuk features again in KDE4.8 and performance was again terrible -- many hours of 100% CPU time during the indexing process. [IIRC on the same P4 system this process took somewhere between 14 to 18 hours to index a home directory with 30 GB of stuff in it, and I think the resulting Virtuoso database was about 1 GB.] The reason is that Nepomuk/Strigi uses several "ontologies" run as separate background processes to do the indexing -- one "ontology" for each type of indexing being done -- file names, pictures, audio files, etc -- so you'd think this would be a single background process searching the disk, but no it's like 5 or 6. And the thing is, I have no reason to use either of these services. To even find out what these services can do isn't easy, because the documentation for them in the KDE manual is terrible. However if you search around the 'net you'll eventually find this:

      https://kdenepomukmanual.wordpress.com/2012/02/06/detailed-kde-nepomuk-manual/

As you read the above document here's some details to keep in mind: I use Krusader as my chosen file manager, not Dolphin. I don't use DigiKam or Gwenview (I use Geeqie as my chosen picture viewer). I never use the Alt-F2 Krunner menu, and I never give files tags or comments to them. Therefore Nepomuk as it stands today is totally doesn't serve a purpose for me.

But above all else, I don't want KDE4 choosing on its own when to run a super I/O intensive indexing process just to create a *cache* of things it finds and hold all of that in a huge database. To me that harks back to the 'mlocate' package -- if you've ever been working on a server that suddenly ran like shit and you found an 'updatedb' process running when you viewed the output of 'top', that's the package that did that. But unlike the mlocate package that called the updatedb process via cron, there's no way to tell KDE4 when to allow it to do the indexing or to limit CPU or I/O -- the only thing you can limit is how much RAM is used, which doesn't address this problem. The indexing starts by default, immediately after your very first login, causing the computer to run like utter shit, and your only choice to stop it is to immediately go to System Settings -> Workspace Appearance and Behavior -> Desktop Search and turn these features off . And that's only if you know where to go and what to do. This is why many users that try KDE4 for the first time say "I can't use this, it makes my computer run like shit." And unfortunately, by the default settings KDE4 gives you, they're right.

There are many other levels of FAIL here, too -- the listing of Control Center modules in the KDE Help are not even in alphabetical order, so even if you somehow know that settings for Nepomuk are in the "Desktop Search" section, it's still an effort to find in the list. Then once you look through the help for the Desktop Search, the documentation that is there is simplistic and doesn't even tell you how you can use it, and doesn't give you any warning whatsoever of the performance impact these services have. [I discussed the lack of performance warning with the KDE4 developers at the time, and they were again unsympathetic. After about a week of arguing and "talk to the hand", they told me to create a KDE account and to propose wording myself, which they'd then review and consider. The problem with this suggestion is that they had already made it quite clear that they were not going to take it seriously.] And the way you get into trying to fix the performance disaster is finding several 'nepomuk' processes, so you try to find out how to turn it off in the KDE4 Help, and the Nepomuk entry in the Alphabetical listing doesn't even mention the "Desktop Search" area, so you end up having to search the internet for answers.

As you can probably tell -- I very much love KDE 4.8, which is why this particular subject makes me seethe. KDE4 shines today without these services active, so it really bothers me that the KDE developers make this performance hog active by default, because it's turning people away that would otherwise be able to enjoy KDE4. :-(

Huh! No I haven't -- first I've heard of Razor-qt. Unfortunately it's packaged specifically for Ubuntu but not Debian. I had a look at the packages for Precise, but the dependencies are specific to Ubuntu Qt versions and so I can't load these on Debian.

      http://ppa.launchpad.net/razor-qt/ppa/ubuntu/pool/main/r/razorqt/

When I find a way, I'll try to check out Razor-qt. Thanks for letting me know about it.

As much as I love KDE4 of today, I agre with you concerning how they treated the transition period during the time of KDE4.2. Nepomuk was my biggest problem at the time -- after I gave it time to index files, trying to selecting 100 files in Krusader would make a P4 machine unusuable for 30 seconds -- and that's just for the select operation. [And I really mean 30 actual seconds.] By the time 30 seconds had gone by I had clicked somewhere else thinking I had done something wrong, whereby that click was remembered and all of the files were de-selected, then I'd have to go through that whole 30-second wait for the select process again. The Virtuoso index database that Strigi/Nepomuk had created was > 2GB, which in itself was rediculous and was why the select operation was taking so long. I had not changed any Nepomuk settings BTW -- they were the default.

I finally figured that out that Strigi/Nepomuk was the problem and wrote the KDE4 developers to describe the issue, and none seemed sympathetic. Either they argued that a P4 machine was too old to matter, didn't believe my report, or made unhelpful statements such as "Nepomuk is not going away". Basically the answers I got amounted to "talk to the hand." [And by the way that same P4 machine runs just fine with KDE4 today as long as Strigi and Nepomuk are fully turned off.]

Nepomuk today remains my biggest complaint with KDE4, and so I always advice turning both it and Strigi indexing fully off. Once that's done KDE4 is very enjoyable to use, so it's still my daily default.

I don't use Gnome3 -- I tried it for a few minutes and found it frustrating. Same goes for Unity. MATE and Cinnamon both seem fine, and I like Xfce. GNOME has long had issues with listening to user desires, so I'm really not surprised about this issue.

Heh.. I loved the movie Demolition Man.