Skip to main content

(Link) A History of Rock Music in 500 Songs

I don't remember exactly how I came across this podcast, but it should have been through somebody in my mastodon circle: https://500songs.com/

Anyways, I've now listened to two episodes (spread over a few sessions) and I'm blown away by the sheer amount of detail that you get to discover about the covered artist or song. And that explains why each episode is rather long, I think the two I listened to are over 2h each.

Music has always been an important part of my life and knowing trivia or facts about a certain artist, album or song has always been meaningful to me, in order to better appreciate the music and augment the listening experience.
If you feel the same you won't regret diving into this podcast.

The two episodes I listened to so far are:

https://500songs.com/podcast/episode-163-sittin-on-the-dock-of-the-bay-by-otis-redding/

I chose this one as incidentally I was listening to Otis Blue at the same time. I was amazed that the whole album was recorded in just 28 hours straight, with only a 4h break so that some musicians could perform their nightly gigs, and then back into studio again at 2AM.
I am again reminded of how much we owe to black musician and the absolutely incredible impact they have had on the music of the last 100 years. There's a book that covers that too, but I cannot recall its title right now.

The other one is https://500songs.com/podcast/episode-171-hey-jude-by-the-beatles/ as some kind of reparation to the Beatles (ironic, huh?). I've never felt a connection to the Beatles and I've never owned any record by them, and, feeling guilty of that, I wanted to give me a chance to better learn about them. Have to say I came out of the listening with a desire to give the white album a full listen, which I am now half-way through. Have to say, I'm really impressed by how clear it sounds on my (modest) system.

Labels:

Comments

Post a Comment

Popular posts from this blog

Mirth: recover space when mirthdb grows out of control

I was recently asked to recover a mirth instance whose embedded database had grown to fill all available space so this is just a note-to-self kind of post. Btw: the recovery, depending on db size and disk speed, is going to take long. The problem A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk. The SO is linux. The solution First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking. Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in
Post a Comment
Read more

From 0 to ZFS replication in 5m with syncoid

The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.
1 comment
Read more

How to automatically import a ZFS pool built on top of iSCSI devices with systemd

When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import. This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname> after boot, either manually or from cron. A better, more elegant solution is instead to hook into systemd events and trigger zpool import as soon as the devices are created.
Post a Comment
Read more