Having written the Classical CD Ripper, a command-line way to rip audio CDs accurately and with appropriate naming and tagging, it seemed appropriate to write a sister application that finishes off the tagging job at the command-line, too. Thus is born the Classical CD Tagger.
It's just a Bash script and it doesn't do much that you couldn't equally well do in Easytag or Puddletag: indeed, it even invokes one or other of those tools (if they're installed on your PC) when it's finished so you can check its work and refine it as necessary.
Truth be told, using a graphical tagger is going to be a lot easier for most people …but I have my own way of working and, once at the command line, I tend to want to stay there! So, for me, ccdt.sh is going to be a better way of working and a time-saver overall.
Software dependencies are minimal: metaflac is about the only one that's a show-stopper.
Since the CD ripper has already tagged up your music with Composer, Artist and Album metadata, the tagger is there to flesh out the missing details: performers, track titles and album art. You get to choose which of these bits of metadata you want to supply, or any combination of them, or all of them at once: it's entirely up to you. Any information supplied is written into proper Vorbis Tags (because in these parts, we don't believe in ripping to MP3, so the use of ID3 tags is inappropriate).
Make of it what use you will… The download is available in the Software Section, as usual
To go with my new desktop, how about a new wallpaper (see right, which should open when clicked to a 5504×3096 JPEG file)?
We had a spot of heavy rain yesterday and I happened to look up through the car's sunroof to see this taking place, backed by a typically lovely grey English sky-scape! My phone was handy, so the image quality is maybe not entirely the best, but I think it looks OK!
A quick recap: I spent most of 2018 running Manjaro as my main desktop's operating system quite happily until, around Christmas, one software update too many borked the entire system and lead me to install a brand new distro from scratch. Finding a suitable distro was problematic, however. I dabbled very briefly with Ubuntu MATE, before ditching it as too archaic to be a pleasure to use. I then had a few weeks with OpenSuse, before running into a bug which slowed the system down to a crawl for no obvious reason. After a day with Debian Testing, which kept crashing, I then tried Fedora 29 -until it started crashing repeatedly, too; at which point I discovered that the crashes were the fault of my graphics card not liking Nouveau open source video drivers and instead needing proprietary Nvidia ones. The Fedora installation thus survived (two whole months!): I even managed to do an in-place upgrade to Fedora 30 with hardly any dramas at all.
But Fedora also has a few issues, the most problematic of which is when I try to copy a large file from my desktop to my server, via a gigabit Ethernet link. After one or two such transfers without incident, the file copying will apparently grind to a halt; the Dolphin file manager will become completely unresponsive; and then the entire graphics stack seems to lock up, preventing me from switching to other programs, launching new ones or, basically, doing anything useful with my PC at all. Give it long enough and the file copying completes in the background and everything springs back to life -but it's disconcerting to have to put up with unpredictable 'lock ups' like this.
So I began looking around for yet another desktop O/S to look into.
Recently, I had also upgraded a couple of my servers and doing nicely fresh FreeBSD installs with them. That got me wondering whether FreeBSD+KDE might not be a suitable desktop operating system -and I got so enamoured of the idea that I even wrote up how you might go about doing it in a short article and implemented it on a couple of spare laptops I had lying about the place. However, I noted that after some use, this particular OS+Desktop Environment combo was a bit too unstable to be a daily driver. Things would crash unexpectedly, or the entire OS would become unresponsive without warning, for example. So I figured that FreeBSD was not destined for my main desktop any time soon (though I'd unhesitatingly recommend it for server duties).
But as I got familiar once more with FreeBSD, I was increasingly impressed with the concept of a really small, coherent, operating system on top of which you could layer anything you fancied by way of 'userland'. It got me thinking: what Linux distro was similar compact, tightly-written and left the business of userland to you as a post-installation activity?
The answer, of course, is Arch.
Arch is really very small: the installation ISO is just 609MB small, so fits comfortably on ye olde compact disc. The reason it's so small, of course, is because there's hardly anything to it! You get a Linux kernel, plus a bunch of GNU utilities, and that's about it: you end up, once the installation is complete, at a command prompt with absolutely nothing GUI in the vicinity to help you out at all!
Naturally, there's a lot of advice out there on how you take that base, command-line only, installation and turn it into a completely GUI operating system with fancy desktop environments and a stack of application software. I've done it myself a few times …though the results have always put me in mind of a tower of blancmange, wobbling dangerously and likely to fall over in a bout of rapid, unscheduled destruction if you so much as breath too hard in its general direction! I have not, therefore, been keen to adopt the blancmange tower approach to Linux on my main desktop
Naturally, some distros have stepped into this gap to make your life easier: Manjaro, for example, is an Arch-based distro that gives you a full desktop, GUI experience immediately post-install (and I thoroughly enjoyed my time with it in 2018 as a result). Antergos is a similar sort of disro -and one I've enjoyed using in the past, particularly when I used to get Oracle databases running on various obscure and non-mainstream distros.
Unfortunately, earlier this week, Antergos announced its own demise. The developers have no time to spare any longer and will move on to other things. Antergos thus dies and it gets just a little harder to find a distro which gives you a good Arch underpinning with a flexible userland automatically layered on top. However, I noticed in various forum comments about Antergos' discontinuation that several users were rather enamoured of ArcoLinux as a suitable replacement. I'd never heard of it before, but the user recommendations were such that I felt I should check it out.
I discovered a very interesting project, which releases three basic flavours of disto:
They are all essentially the same distro, just with a different mix of 'userland' applied on top of the fundamental Arch O/S underpinning. The range is from 'none at all' (ArcolinuxD); via choose-your-userland (ArcolinuxB); to 'have our choice of 3 different userlands and switch between them as you like' (Arcolinux). I think the naming of the different 'flavours' of distro is a bit confusing (what happened to Arcolinuxes A and C, for example!), but the idea behind the variety available is a sound one.
I wasn't particularly keen on vanilla Arcolinux: there's little point in me installing a distro that comes with three different windowing environments, only one of which I'll actually use regularly, and two of which I can't stand anyway!
ArcolinuxD was also not really a serious option: I don't need a graphical Arch installer. If I wanted to end up with nothing more than pretty much vanilla Arch, I could cope with Arch's native command-line installer and achieve the same outcome without needing to rely on a third party at all. Which is not to say ArcolinuxD is pointless: I think it's an excellent thing to make the Arch installation look and feel like most other distros' installations. It might help bring Arch itself to a slightly wider audience, which is a net positive.
So that left me wondering which of the 13 separate flavours of ArcoLinuxB I'd be interested in: there is one for Plasma, for example, which means, basically, Arch-plus-KDE5 is a possibility -and that would have been the obvious choice to make, given my recent distro experiences. But my recent experimentation with the minimalism that is FreeBSD, plus my relatively poor and bug-laden recent experience of KDE Plasma-based distros, made me think that now might be a time for a bit of minimalist Linux experimentation. I therefore decided to install ArcoLinuxB - OpenBox.
Actually, what you end up with is an XFCE Desktop Environment which uses OpenBox as its windowing manager, but that's minimalist enough for my current tastes! You get a good-looking environment (which needs a bit of tweaking, but not much), with menus appearing readily to hand whenever you right-click the desktop. You don't get fancy graphical effects (such as desktop cubes and wobbly windows), which is taking me a bit of time to get used to! But I think the loss of those fripperies is probably better for overall stability (and productivity!), if I'm being honest.
The change of environment, plus my recent spell of FreeBSD dabbling, has also made me re-think some of my software choices. For example, I've long been using Clementine as my KDE-based music player and manager of choice, but now I'm trying not to go heavy on the KDE front, what other options are there? Arcolinux comes with Pragha pre-installed: I've never heard of it before and didn't much like it within 3 minutes of trying it out, as it seems incapable of scrobbling tracks played to my Last.fm account, for example. After some rapid experimentation, I settled on DeadBeef, which is perhaps the closest thing Linux has to a native port of Window's excellent Foobar2000. Like Foobar2000 (F2K), DeadBeef comes with a very minimalist layout fresh from the install, but stands a lot of re-configuring and tweaking, with the result that you can end up with a really decent classical music player/manager that makes a good deal of sense and is comfortable to use long-term.
For similar reasons, I've stopped using Kwrite as my text editor of choice and have instead embraced notepaddqq, which feels very much like a Linux port of Windows' Notepad++ (and is accordingly strongly recommended!). Konsole, KDE's terminal emulator, also gets the chop and in comes Termite. It's extremely minimalist -not having tabs out-of-the-box, for example- and I think it may take a while to get entirely comfortable with it, but on the whole it feels fresh, snappy and workable.
Perhaps my biggest single problem with Arcolinux was wondering why all my carefully-constructed crontab entries never got run! The reason is straightfoward and presumably obvious to any long-standing Arch users out there: Arch (and hence Arcolinux) doesn't use Cron by default, but instead uses the Timer functionality built in to the all-new, all-singing-and-dancing systemd, which works in a completely different way. Fortunately, a quick pacman -S cronie, followed by a systemctl enable cronie and systemctl start cronie soon got that sorted; after which pretty much everything else has been plain sailing.
My biggest criticism of Arcolinux (or, at least, the Openbox flavour of it that I installed) is that it ships with an unregistered copy of Sublime as its default text editor. I don't have a problem with its functionality: it seems, on every level, to be a thoroughly decent text editor. But it's not supposed to be used long-term without ponying up for a proper license …and at US$80 a pop, that's not happening in these parts any time soon! It seems odd to me to supply a closed-source, license-required text editor as a default feature when something like opensource, entirely zero-cost, notepadqq is just as readily available. But it's a choice soon remedied by a sudo pacman -R sublime-text-dev followed by a sudo pacman -S notepadqq, so it's not exactly a show-stopper!
Other minor criticisms are just those that come through inexperience: the default application icon scheme, for example, is one I've never come across before and therefore hardly any of the icons make a lot of sense to me or give me a clue as to what they will launch when clicked! Would you, for example, know that this…
…launched Gimp if I hadn't told you?! If you think about it, and know the Wilber icon that is usually associated with the Gimp, then it will make sense… but it doesn't the first day you install the system. Not for this old-timer it didn't, anyway!
Because it's Arch at heart, Arcolinux ships with very up-to-date versions of most programs. Almost all of the applications I need are straightforward 'pacman' installations from the standard respositories; for one or two curly things, I had to resort to installing from the AUR -but that's not really very difficult to do, either.
So, as we approach the half-way point of 2019, I'm freshly on to my fifth distro of the year. I'm hoping this one will last to at least Christmas: I'd like it to, as it feels fresh and fast -and I'm enjoying having to learn new ways of doing things that don't rely on a do-everything-if-you're-lucky Desktop Environment. We shall see… In the meantime, I shall be putting together a set of articles about how to install, tweak and configure Arcolinux into something that's extremely usable. They will be available in the next few weeks in the usual place.
Update May 29th: The basic installation/configuration article is now available.
Back in about 2015 or so, I bought two of these:
It's an HP Proliant Microserver, Generation 8. From memory, they cost me about AU$360 a piece, which seemed pretty cheap at the time for a “proper” server, capable of using up to 32GB of ECC RAM and running a 4-disk multi-Terabyte storage array, constantly and reliably. (For the record, you can now get Generation 10 equivalents, which I don't own personally; but having installed one for the local church Parish Office, I can attest that they are excellent, too).
One of the reasons I got the servers so cheap was that I bought the base model -they each shipped with a 2-core Celeron G1610T processor, for example. Since the servers just sat there running ZFS and providing bulk storage to the other PCs around the house, that level of CPU was more than sufficient.
But never one to let things run unchanged for long, I have recently been thinking that it would be quite nice to upgrade both servers with rather more capable Xeon CPUs. You can buy suitable models on Ebay for quite reasonable sums it turns out, and I therefore rapidly acquired a Xeon E3-1260L (for around £45) and a slightly more powerful Xeon E3-1230 V2 (for £60). Both are socket LGA 1155 processors, so slot in perfectly to where the Celerons used to sit!
Both new CPUs are 4-core with hyperthreading, so 8-thread parts (as compared to the Celeron's 2-cores, 2-threads). Moreover, the Celerons only ran at 2.3GHz with no turbo; the E3-1230 runs at 3.3GHz with a 3.7GHz turbo, and the E3-1260L runs at 2.40GHz with a 3.3GHz turbo. So, four times the threads and with the possibility in turbo mode of an approximately 33% boost in processor speed: what's not to like?!
Well: there is one problem. The original Celerons were 35W parts, and the passive heat sink the HP Microservers ship with are rated for 35W, so are a nice match. But the E3-1260L is a 45W part and the E3-1230 runs at a whopping 65W. More watts equals more heat, especially with a heatsink rated way below what each of the new processors can output. Space is incredibly tight within the server chassis, though, so there is no way to buy a thunking great cooling fan and sticking it onto the original heatsink: there just isn't enough clearance, as this photo shows:
It doesn't help, either, that the original heatsink is attached by a rather unique rectangular arrangement of screws; your standard, square cooling fans and alternative passive heatsinks are not going to fit.
As it turns out, the 45W CPU is almost 35W, enough so anyway that when I checked the CPU temperatures under load, the temperatures were not outrageous: I forgot to take a detailed note, but from memory, I was pegging around 58°C after 30 minutes of 100% CPU utilisation for all 8 threads, which compared relatively favourably to the original Celeron's approximately 46°C. Clearly the extra wattage of the new CPU results in a hefty temperature rise of around 12°C, but the result is not anywhere near toasty temperature levels that would cause real concern. So the 45W CPU can run as it is, with no further concerns or consideration.
But the E3-1230 V2 was another matter. After its 30 minutes of 100% utilisation, that CPU was clocked at a rather scary 86°C, which is a degree or so above the point where it's automatically throttled back to lower, slower speeds (ambient temperature in my study, where I tested these things, was always around 22°C, by the way). It is true that I don't ever expect these servers to be continually stressed like that in day-to-day operation; nevertheless such a high operating temperature under load seemed to me a problem I'd like to avoid if at all possible.
So I visited Amazon and bought two of these things:
It's a tiny -and I mean that's it's only about as big as the first joint of your thumb, so really very petite- 12 volt fan. It is fairly quiet in operation and pushes a reasonable amount of air around. I glued both of them to the passive heatsink, like so:
…and wired them into the existing tangle of molex cables, making sure that they blew air towards the back of the case, where the giant built-in fan is waiting to expell it all into the great outdoors! After another 30 minutes at 100% utilisation, I was recording temperatures of around 80°C, which wasn't a spectacular improvement, but 6°C means the CPU wasn't being throttled any more and was a temperature I could (just about) live with.
But whilst the HP BIOS on this server is configured to run the main system fan in 'optimal mode' by default (which means it just purrs quietly in the background!), there is an option to bump that up to 'Increased' or 'Maximum Cooling'. I therefore decided to go all-in and switched on 'Maximum Cooling' mode and re-ran my temperature tests. The gentle purr of optimal cooling gave way to a server-room-like roar in maximum mode, but I ended up with temperatures of around 71°C, which is an excellent result. Presumably, without the little fans mounted on the CPU, I might have been able to achieve 77°C or so anyway, just by bumping up the built-in fan capabilities, but the extra 6°C from the purchased micro-fans is appreciated anyway.
Happily, as this screenshot shows, with 100% CPU utilisation on all four cores (and all 8 threads), the CPU temperatures not only topped off at around the 70°C mark, but the CPU frequency easily maintained an un-throttled 3.5GHz:
Incidentially, the new roar of the built-in fan won't be a problem for me once these servers are returned to their normal hiding place: in the loft, where ambient temperatures are usually significantly cooler than those found in my study, which can only help matters further!
My two old servers are now both more than capable of running as my ZFS storage servers and as virtual machine hosts, increasing their utility to me significantly. For a relatively small outlay on new CPUs and an enjoyable day or two of tinkering with thermal paste application and micro-fan gluing, I've extended the useful life of these workhorses with minimal effort. Recommended!
Fedora released version 30 of their distro the other day. Since I was already running version 29, I thought I'd give the in-place distro upgrade mechanism a workout:
sudo dnf upgrade --refresh sudo dnf install dnf-plugin-system-upgrade sudo dnf system-upgrade download --releasever=30 sudo dnf system-upgrade reboot
For the most part, it was plain sailing and no trouble at all -except that the third command produced an error, indicating that something called “mscore” couldn't be upgraded and, therefore, that nothing at all would be upgraded.
That's a bit sad, since “mscore” is actually MuseScore, a music notation program I use quite a lot. Permanently losing it would not be acceptable, but a temporary loss of it can be coped with. Thus a simple sudo dnf remove musescore was issued, and that allowed a subsequent attempt to run the third command above without drama.
The actual upgrade process takes place after the reboot command; some 4700+ applications needed to be upgraded, which took a fair amount of time. However, after no more than (I would guess!) 15 minutes, the PC was back in working order and sporting the new version:
[[email protected] ~]$ cat /etc/redhat-release Fedora release 30 (Thirty)
It is, of course, still Musescore-less, but that will hopefully be rectified soon enough.
I keep looking around for an alternative distro I can live with and like rather more than Fedora, but not much is coming up on my distro-radar right now. In a virtual machine, I am trying to learn to love Manjaro OpenBox, but it's definitely not love at first sight! Meanwhile, a somewhat fresh Fedora does all I could ask for (apart from run Musescore!!)
Update: One other minor problem arising: there's no version 30 repository for VirtualBox as yet, so all attempts to do a 'dnf update' generate the error:
Fedora 30 - x86_64 - VirtualBox 2.2 kB/s | 6.9 kB 00:03 Failed to synchronize cache for repo 'virtualbox' Ignoring repositories: virtualbox
The problem is found in /etc/yum.repos.d/virtualbox.repo, which contains the line:
Of course, that “$releasever” variable gets turned into “30” after you upgrade to Fedora 30 -and no such sub-directory exists on the Oracle/VirtualBox end of things as yet. So, for now, the workaround is to change that line to read:
That is, you're basically hard-coding 'use version 29's software' for now, and that makes the earlier error message disappear. Eventually, one assumes, there will be a version 30 directory at VirtualBox, and when that happens, it will be fine to change back to '$releasever'. Meantime, the hard-coded '29' will ensure your VirtualBox installation remains current and properly patched regardless.
Update #2: It's now May 5th, so a couple of days after writing the main article: MuseScore is back and working fine. It's in the main repositories and no addition of slightly-suspect 'copr' repositories is required to get it working. Nice work, developers!