Interesting stuff in this week's DistroWatch Weekly.
First, a nice review by Jesse Smith of Linux Mint Debian Edition. As I looked over this review, I could see some good reasons why some people would prefer to use LMDE instead of Debian Testing, which LMDE is based on. LMDE is certainly quicker and easier to install, and Smith had some very positive things to say about LMDE's graphical installer, including this:
"The installer is fairly novice-friendly and I didn't encounter any problems while using it. I'm hoping other Debian-based distributions consider adopting Mint's installer. There are a lot of Debian derivative projects out there and many of them lack a nice, graphical installer."
Smith liked LMDE's "Device Driver Manager":
"This program attempts to detect hardware on our system which may not be well supported by our existing kernel or drivers. The Manager will assist us in detecting wireless cards, video cards and our CPU and offer to fetch packages which may give us better hardware support."
Despite all this, Smith said that he was unable to get LMDE to run on his desktop pc, although it worked fine on his laptop and in VirtualBox.
Also, LMDE comes with the Cinnamon and MATE desktop environments, which some users may prefer over the selection of DEs and WMs (including GNOME 3 with GNOME Shell) that "straight" Debian offers.
More comments from Smith's review that show how LMDE differs from Debian Testing:
"This Debian-based flavour of Mint uses software packages from Debian's Testing branch. To counter the potential stability problems caused by using a rolling release repository the Mint team maintains a series of upgrade packs which are tested prior to being released to the community. This places a safety valve between possible software regressions and the community of Mint users."
But, here's an important point brought up by "FSFer" in the DW Weekly comments section:
"The problem with LMDE doesn't become apparent until [the user has had LMDE] running for some months, ie the update packs only are released every few months. Therefore to get timely updates, you have to change repos to the standard testing ( or sid) negating the proposed advantage of the update packs."
That's something I've seen mentioned many times at the Mint forums...
Besides the Mint Debian review, some other nice tidbits in this week's DW Weekly include some items in the "DistroWatch.com News" section.
They've added a "Random Distribution" button to the site's navigation bar. Clicking on it will take the user to a random active distribution's page on DistroWatch. Nice.
Another addition to the front page: a new filter option "to display news about stable distribution releases ONLY (i.e. hide all news items that deal with development, alphas, betas, release candidate, milestones, etc.)."
Then, there's this:
We have removed Pisi Linux from DistroWatch. This is a distribution that intends to succeed the "old" Pardus Linux (when it was an independent distribution with its own package management called "Pisi", rather than the current Debian-based variant). Unfortunately, we have found the project still rather immature at this stage - it has changed name three times already and the communication with the distribution developers have been rather unpleasant, with many conflicting requests and confusing emails. Also, the project's SourceForge page continues to claim that "as of 2013-03-14, this project is no longer under active development," which has been denied by the project's official website. All in all, adding Pisi Linux to DistroWatch so early was perhaps a little premature so we would like to give it a bit more time to mature and settle down. We'll revisit the decision in the future once things start to improve - until that happens we are sorry to say that you won't see any announcements on DistroWatch.
Ouch. Not a good start for Pisi.
Monday, April 8, 2013
Sunday, April 7, 2013
acc
They probably won't be calling the Big Ten the best conference for college basketball for very long (if it really is that now -- that case can be made if Michigan wins the national title tonight). With Syracuse, Pittsburgh, Notre Dame, and Louisville joining up, the ACC is gonna be tough to challenge.
Of the schools on this map, of course Maryland is moving to the Big Ten. But the ACC, already a great conference for hoop, looks to become even better:
Of the schools on this map, of course Maryland is moving to the Big Ten. But the ACC, already a great conference for hoop, looks to become even better:
my bridge/arch experiment
I'm convinced, more than ever, that going with Bridge Linux instead of installing "straight" Arch is the way to go for someone like me. If I had any reason to do a fresh installation, I'd go with Bridge again.
Arch recently came out with a new Pacman version (Pacman 4.1.0 -- see this Softpedia article and the announcement at pacman.git for more info); after pulling that in today, I asked a couple of questions at the Bridge forums and at the Bruno's All Things Linux forums, edited my /etc/pacman.conf file a little bit, and that was pretty much it.
Everything I've seen so far leads me to conclude that the repos and config files I'm using for Bridge Xfce are pretty much the same as what I'd end up with if I installed "straight" Arch and went with Xfce. I don't get bragging rights, since I didn't "build the house from the ground up," but my ego remains intact.
Bridge Xfce is great to use, but the best parts about this "experiment" are getting to see how Pacman works and getting a feel for Arch Linux. I really like Pacman; as for Arch, time will tell. Things look good so far. I can't tell if it's any more or less "unstable" than Debian Unstable or the latest Fedora, or if running it is any more or less of a hassle than running either of those. I think I get more out of running Fedora and Bridge/Arch than I'd get from running Sid, though, because they force me to look at things from outside of my Debian "comfort zone."
Arch recently came out with a new Pacman version (Pacman 4.1.0 -- see this Softpedia article and the announcement at pacman.git for more info); after pulling that in today, I asked a couple of questions at the Bridge forums and at the Bruno's All Things Linux forums, edited my /etc/pacman.conf file a little bit, and that was pretty much it.
Everything I've seen so far leads me to conclude that the repos and config files I'm using for Bridge Xfce are pretty much the same as what I'd end up with if I installed "straight" Arch and went with Xfce. I don't get bragging rights, since I didn't "build the house from the ground up," but my ego remains intact.
Bridge Xfce is great to use, but the best parts about this "experiment" are getting to see how Pacman works and getting a feel for Arch Linux. I really like Pacman; as for Arch, time will tell. Things look good so far. I can't tell if it's any more or less "unstable" than Debian Unstable or the latest Fedora, or if running it is any more or less of a hassle than running either of those. I think I get more out of running Fedora and Bridge/Arch than I'd get from running Sid, though, because they force me to look at things from outside of my Debian "comfort zone."
Monday, March 25, 2013
there's a trick to it
Jesse Smith's review of openSUSE 12.3 in this week's DistroWatch Weekly mentioned some installation difficulties that he encountered. In the DW comments section, "Andy Prough" posted the following:
One trick to installing openSUSE is to always try to download and install from the full DVD if possible. This distro doesn't seem to do near as well as Ubuntu and Mint at shoving everything you need into a smaller Live CD/DVD version. I've recommended that they stop producing the Live CD/DVD's if they aren't going to be able to control the quality of installation, or that they at least post a strong warning to avoid installing from that media. I think this may have contributed to the installation problems Jesse ran into as well.
If you go to the openSUSE forums, you'll find that most of the long-time users refuse to install from the live media or the Net install - they only use the full DVD. Although it takes longer to download, you get the added advantage of having a full repair disk plus an emergency off-line repository with thousands of software packages.
That's probably a good point; for my opensSUSE installations (12.1, 12.2, and 12.3 -- on a couple of different computers), I've used the KDE live disk each time. While I've managed to get each release installed, and each installation seemed easier than the previous one, my impression has been that openSUSE isn't the easiest distro to install. However, I figured that any difficulties I've had were the result of my not being familiar with the distro combined with the fact that I was adding them to my multi-boot set-ups.
Next time around, I may just do what was mentioned above -- go with the full DVD.
One trick to installing openSUSE is to always try to download and install from the full DVD if possible. This distro doesn't seem to do near as well as Ubuntu and Mint at shoving everything you need into a smaller Live CD/DVD version. I've recommended that they stop producing the Live CD/DVD's if they aren't going to be able to control the quality of installation, or that they at least post a strong warning to avoid installing from that media. I think this may have contributed to the installation problems Jesse ran into as well.
If you go to the openSUSE forums, you'll find that most of the long-time users refuse to install from the live media or the Net install - they only use the full DVD. Although it takes longer to download, you get the added advantage of having a full repair disk plus an emergency off-line repository with thousands of software packages.
That's probably a good point; for my opensSUSE installations (12.1, 12.2, and 12.3 -- on a couple of different computers), I've used the KDE live disk each time. While I've managed to get each release installed, and each installation seemed easier than the previous one, my impression has been that openSUSE isn't the easiest distro to install. However, I figured that any difficulties I've had were the result of my not being familiar with the distro combined with the fact that I was adding them to my multi-boot set-ups.
Next time around, I may just do what was mentioned above -- go with the full DVD.
Saturday, March 23, 2013
kde's date and time
Configuring the KDE4 panel's digital clock is sort of a pain, mainly because settings aren't all in one place. Not a problem if you know what you're doing. If you don't... good luck. Prepare to spend a lot of time floundering.
I've finally gotten to the point where it takes me only a few minutes to get things tweaked to my satisfaction. Here's a look at how I did things in Fedora 17, with KDE 4.10.1.
Right-click on the clock and click on "Digital Clock Settings." The default settings look something like this:
Under "Appearance," the "Font" section controls the time's font, but not the date's font. I changed the Font to "Bold." In the "Information" section, I changed the Date format from "No date" to "Short date":
To tweak the date, first I clicked on the "wrench" button that sits to the right of the Date format. That opened up the "Country/Region & Language - KDE Control Module" window. I clicked on the "Date & Time" tab. The two fields I'm concerned with here are the "Time format" field and the "Short date format" field. With the cursor hovering inside one of the fields, suggestions show up, providing some helpful hints:
There's also a drop-down list that shows some strings you can use in the field.
In the "Time format" field, I used HH:MM to give me a 24-hour clock. In the the "Short date format" field, I used SHORTWEEKDAY SHORTMONTH dD. Those text strings are defined in the pop-up that appears when the cursor is hovering inside the field.
Finally, I clicked on "Apply" and closed the window. Back in "Digital Clock Settings" window, I clicked on "Apply" and closed that window, too.
At this point, the font for the time was in bold, but the font for the date was too small, and not in bold. To adjust the date's font: System Settings > Application Appearance > Fonts. The "Small" font setting is the one that is used for the the date.
The "Choose..." button brings up the following window:
A strange thing here is that the size of the time's and date's fonts are sorta connected. If you make the date's font larger, the time's font will shrink. I wanted to keep the date's font smaller than the time's font, but in the end the date's font was still a bit too small for my old eyes. This was remedied by increasing the height of the panel itself.
After all that, I had things the way I wanted them.
It's unfortunate that the KDE devs still haven't found a way to make all this much simpler, but with a little practice, the user can make short work of it.
I've finally gotten to the point where it takes me only a few minutes to get things tweaked to my satisfaction. Here's a look at how I did things in Fedora 17, with KDE 4.10.1.
Right-click on the clock and click on "Digital Clock Settings." The default settings look something like this:
Under "Appearance," the "Font" section controls the time's font, but not the date's font. I changed the Font to "Bold." In the "Information" section, I changed the Date format from "No date" to "Short date":
To tweak the date, first I clicked on the "wrench" button that sits to the right of the Date format. That opened up the "Country/Region & Language - KDE Control Module" window. I clicked on the "Date & Time" tab. The two fields I'm concerned with here are the "Time format" field and the "Short date format" field. With the cursor hovering inside one of the fields, suggestions show up, providing some helpful hints:
There's also a drop-down list that shows some strings you can use in the field.
In the "Time format" field, I used HH:MM to give me a 24-hour clock. In the the "Short date format" field, I used SHORTWEEKDAY SHORTMONTH dD. Those text strings are defined in the pop-up that appears when the cursor is hovering inside the field.
Finally, I clicked on "Apply" and closed the window. Back in "Digital Clock Settings" window, I clicked on "Apply" and closed that window, too.
At this point, the font for the time was in bold, but the font for the date was too small, and not in bold. To adjust the date's font: System Settings > Application Appearance > Fonts. The "Small" font setting is the one that is used for the the date.
The "Choose..." button brings up the following window:
A strange thing here is that the size of the time's and date's fonts are sorta connected. If you make the date's font larger, the time's font will shrink. I wanted to keep the date's font smaller than the time's font, but in the end the date's font was still a bit too small for my old eyes. This was remedied by increasing the height of the panel itself.
After all that, I had things the way I wanted them.
It's unfortunate that the KDE devs still haven't found a way to make all this much simpler, but with a little practice, the user can make short work of it.
Friday, March 22, 2013
four point ten
I've been using KDE 4.10 in Chakra for about a month and in Sabayon for a little more than a week. Yesterday, I was surprised to see updates available in Fedora 17 for KDE 4.10.1, so I brought 'em in.
KDE4 is looking very good these days, and 4.10 seems like a very nice step forward from what's come before -- more polished, and faster.
Looks like Debian Wheezy will have KDE 4.8.4 when it finally becomes Debian Stable; Mepis will probably stick with what's in the Wheezy repos. I think that'll be fine for most Mepis users; I'm still using KDE 4.8.5 in openSUSE 12.2, with no complaints. But most distros are more up-to-date with KDE than Debian is, so the next Mepis release might be a tough sell for KDE-lovers -- unless rock-solid, Debian-ish stability is a primary concern, or unless the user is a devoted Mepis fan already. KDE 4.10 is already available via PPAs in Kubuntu, and the next Kubuntu release (in April) will come with it by default. openSUSE 12.3 comes with 4.10.0. Even PCLinuxOS is already at 4.9.5, I think.
But whether it's 4.8.x or 4.10.x, good times for KDE users.
KDE4 is looking very good these days, and 4.10 seems like a very nice step forward from what's come before -- more polished, and faster.Looks like Debian Wheezy will have KDE 4.8.4 when it finally becomes Debian Stable; Mepis will probably stick with what's in the Wheezy repos. I think that'll be fine for most Mepis users; I'm still using KDE 4.8.5 in openSUSE 12.2, with no complaints. But most distros are more up-to-date with KDE than Debian is, so the next Mepis release might be a tough sell for KDE-lovers -- unless rock-solid, Debian-ish stability is a primary concern, or unless the user is a devoted Mepis fan already. KDE 4.10 is already available via PPAs in Kubuntu, and the next Kubuntu release (in April) will come with it by default. openSUSE 12.3 comes with 4.10.0. Even PCLinuxOS is already at 4.9.5, I think.
But whether it's 4.8.x or 4.10.x, good times for KDE users.
Tuesday, March 19, 2013
a very good distro
While I'm looking forward to installing openSUSE 12.3 here, I haven't been in a hurry to do so, and I keep finding other things to do that seem more important at the moment. I'm typing this from openSUSE 12.2 (KDE), which has been so good that it's kinda hard to find a reason to move on to the next release.
The openSUSE releases go like this, according to their "Lifetime" page:
openSUSE releases have a lifetime of 2 releases + 2 months overlap. With a release cycle of 8 months this makes it 18 months.
So, the 12.2 release, which came out in September 2012, will be supported until around January 2014. I've got plenty of time. It might even be more intersting to ride with 12.2 until its end-of-life ("EOL"), just to see how things go; but, I'm pretty sure that I'll get bored one day and want to install the "current" release, or else I'll read about something that'll make me want to try it out.
Running openSUSE is not totally unlike running Debian Stable, in that you've got a long support cycle (although Debian's is longer -- over three years, something like that, depending on how things go), and a solid, stable system (if you run YaST to receive only security updates, mainly). Dependable; everything just works, no worries. Definitely one of the best distros I've ever run here.
The openSUSE releases go like this, according to their "Lifetime" page:
openSUSE releases have a lifetime of 2 releases + 2 months overlap. With a release cycle of 8 months this makes it 18 months.
So, the 12.2 release, which came out in September 2012, will be supported until around January 2014. I've got plenty of time. It might even be more intersting to ride with 12.2 until its end-of-life ("EOL"), just to see how things go; but, I'm pretty sure that I'll get bored one day and want to install the "current" release, or else I'll read about something that'll make me want to try it out.
Running openSUSE is not totally unlike running Debian Stable, in that you've got a long support cycle (although Debian's is longer -- over three years, something like that, depending on how things go), and a solid, stable system (if you run YaST to receive only security updates, mainly). Dependable; everything just works, no worries. Definitely one of the best distros I've ever run here.
Subscribe to:
Posts (Atom)
