This show has been flagged as Clean by the host.

Provide feedback on this episode.

This show has been flagged as Explicit by the host.

These are comments which have been made during the past month, either to shows released during the month or to past shows.

There are 6 comments on

There are 14 comments on 9 of this month's shows:

• hpr4546

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

• Comment 1:

The threaded discussions this month can be found here:

With the kind permission of LWN.net we are linking to

Quoting the site:

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Recorded with:

Zoom H1 Essential Microphone

Monitored with:

soundcore V20i open ear headphones

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Most software development I’ve done has been utilities for highly specific workflows. I’ve written code to ensure that metadata for a company’s custom file format gets copied along with the rest of the data when the file gets archived, code that ensures a search field doesn’t mangle input, lots of Git hooks, file converters, parsers, and of course my fair share of dirty hacks. Because most software projects I work on are designed for a specific task, very few of them have required packaging. My utilities have been either integrated into a larger code base I’m not responsible for, or else distributed across an infrastructure by an admin. It’s like a magic trick, which has made my life conveniently easier but, as magic does, it has also tricked me into thinking that my development work is done once I can prove that my code does its job. The reality is that code development isn’t actually done until you can deliver it to your users in a format they can install.

I don’t think I’m alone in forgetting that software delivery is the real final product. There are many reasons some developers stop short of providing an installable package for the code they’ve worked on for weeks or months or years. First of all, packaging is work, and after writing and troubleshooting code for months, sometimes you just want your work to be over just as soon as everything functions as expected. Secondly, there are a lot of software package formats out there, regardless of what platform you’re delivering to. However, I view packaging as part of quality assurance. There are lots of benefits you gain by packaging your code into an installer, and you don’t have to target every package format. In fact, you get the benefits of packaging by creating just one package.

When you package your code as an installable file, whether it’s an RPM file or a Bash script or a Flatpak or AppImage or EXE or MSI or anything else, you are checking your code base for consistency. Pick whatever package format you’re most comfortable with, or the one you think represents the bulk of your target audience, and you’re sure to find that the package tooling expects to be automated. Nobody wants to start packaging from scratch every time they update code, so naturally packaging tools are designed to be configured once for a specific code base and then to create updated packages each time the code base is updated. If you’re building a package for your project and discover that you have to manually intervene, then you’ve discovered a bug in your code.

Imagine that you’ve got a project repository with a name in camel-case. You hadn’t noticed before, but your code refers to itself in a mix of lowercase and camel-case. Your package build grinds to a halt because a variable used by the packaging tools suddenly can’t find your code base because it was set to a lowercase title but the archive of your code uses camel-case. If this happens to you, it’s also going to happen for every software packager trying to help you deliver your project to their users. Fix it for yourself, and you’ve fixed it for everyone.

For decades, one of the most common problems of software troubleshooting has been the phrase “well, it works on my machine.” No matter how many tools we developers have at our disposal to make it easy to build and run software on a clean system, it’s still common to accidentally deliver software with surprise dependencies. It’s easy to forget to revert to a clean snapshot in a virtual machine, or to use a container that just happens to have a more recent version of a library than you’d realised, or to get the path of an important executable wrong in a script, or to forget that not all computers ship with a thing you take for granted.

Not all packaging tools are immune to this problem, but very robust ones (like RPM and DEB, Flatpak, and AppImage) are. I can’t count the times I’ve tried to deliver an RPM only to be reminded by rpmbuild that I haven’t included the -devel version of a dependency (many Linux distributions separate development libraries from binaries.)

You may not literally fix every problem with dependency management by building a single package, but you can clearly identify what your code requires. It only takes a single warning from your packaging tool for you to add a note to other packagers about what they must include in their own builds.

As an additional bonus, it’s also a good reminder to double check the licenses your project is using. In the haze of desperate hacking to get something to just-work-already, it’s helpful to get a gentle reminder that you’ve linked to a library with a different license than everything else. Few packaging tools (if any?) detect licensing requirements directly, but sometimes all it takes is a reminder that you’re using a library that comes from a non-standard repo for you to remember to review licensing.

Once you’ve packaged your code once, you create an example for everyone coming to your project to turn it into a package of their own. It doesn’t matter whether your example package is an RPM or a DEB or just a TGZ for a front-end like SlackBuild or Arch’s AUR, it’s the interaction between a packaging system and the input script that counts. Even a novice package maintainer is likely to be able to reverse engineer a packaging script enough to reuse the same logic for their own package.

Here’s the build and install section of the RPM for GNU Hello:

Here’s the GNU Hello build script for Arch Linux:

There are differences, but you can see the shared logic. There are macros or functions that abstract some common steps of the build process, there are variables to ensure consistency, and they both benefit from using automake as provided by the source code. Armed with these examples, you could probably write a DEB package or Flatpak ref for GNU Hello in an afternoon.

Packaging is quality assurance. Even though a packaging system is really just a front-end for whatever build system your code uses anyway, the rigour of creating a repeatable and automated process for delivering your project is a helpful exercise. It benefits your project, and it benefits the people eager to deliver your project to other users. Software development isn’t over until it’s packaged.

Shownotes taken from https://www.both.org/?p=13264

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Provide feedback on this episode.

This show has been flagged as Clean by the host.

This brings us to a look at some of Arthur C. Clarke's other stories, A Time Odyssey (1951), Tales From the White Hart (1957), The Nine Billion Names of God (1954), The Star (1955), Dolphin Island (1964), and A Meeting With Medusa (1971. These stories will wrap up our look at Clarke's Science Fiction and we have seen a lot of good stuff here. And as a final note, we cover CLarke's Three Laws.

A collaboration between two of science fiction’s best authors: what could possibly go wrong? Well, something went wrong. This series is not bad, but I hesitate to describe it as good. This series was described by Clarke as neither a prequel nor a sequel, but an “orthoquel”, a name coined from “orthogonal”, which means something roughly like “at right angles”, though it is also used in statistics to denote events that are independent and do not influence each other. And in relativity theory Time is orthogonal to Space. And in multi-dimensional geometry we can talk about axes in each dimension as orthogonal to all of the others. It is something I can’t picture, being pretty much limited to three dimensions, but it can be described mathematically.

It is sort of like the 2001 series, but not really. It has globes instead of monoliths. And the spheres have a circumference and volume that is related to their radius not by the usual pi, but by exactly three. Just what this means I am not sure, other than they are not sphere’s in any usual sense of the word. In this story these spheres seem to be gathering people from various eras and bringing them to some other planet which gets christened “Mir”, though not in any way to the Russian Space Station. It is a Russian word that can mean “peace”, “world”, or “village”. I have seen it used a lot to refer to a village in my studies of Russian history. Anyway, the inhabitants include two hominids, a mother and daughter, a group of British Redcoats, Mongols from the Genghis Khan era, a UN Peacekeeper helicopter, a Russian space capsule, an unknown Rudyard Kipling, the army of Alexander The Great… Well at least they have lots of characters to throw around. They end up taking sides and fighting each other. In the end several of the people are returned to Earth in their own time.

But the joke is on them. The beings behind the spheres are call themselves The Firstborn because they were the first to achieve sentience. They figure that best way for them to remain safe is to wipe out any other race that achieves sentience, making them to polar opposite of the beings behind the monoliths in 2001, for whom the mind is sacred. Anyway, the Firstborn have arranged for a massive solar flare that will wipe out all life on Earth and completely sterilize the planet, but conveniently it will happen in 5 years, leaving time for plot development. Of course the people of Earth will try to protect themselves. Then in the third book of the series an ominous object enters the solar system. This is of course a callback to the Rama object. It is like they wanted to take everything from the Rama series and twist it.

While I love a lot of Clarke’s work and some of Baxter’s as well, I think this is eminently skippable. The two of them also collaborated on the final White Hart story, which isn’t bad

This collection of short stories has a unity of the setting, a pub called White Hart, where a character tells outrageous stories. Other characters are thinly disguised science fiction authors, including Clarke himself. Clarke mentions that he was inspired to do this by the Jorkens stories of Lord Dunsany, which are also outrageous tall tales, but lacking the science fictions aspects of Clarke’s stories. Of course this type of story has a long history, in which we would do well to mention the stories of Baron Munchausen, and of course the stories of L. Sprague de Camp and Fletcher Pratt as found in Tales from Gavagan’s Bar. And Spider Robinson would take this basic idea and turn it into a series of books about Callahan’s Place. Stories of this type are at least as much Fantasy as anything, but quite enjoyable, and I think I can recommend all of these as worth the time to while away a cold winter’s evening while sitting by a warm fire with a beverage of choice.

This short story won a retrospective Hugo in 2004 as being the best short story of 1954. The idea is that a group of Tibetan monks believe that the purpose of the universe is to identify the nine billion names of God, and once that has been done the universe will no longer have a purpose and will cease to exist. They have been identifying candidates and writing them down, but the work is very slow, so they decide that maybe with a little automation they can speed it up. So they get a computer (and in 1954, you should be picturing a room-sized mainframe), and then hire some Western programmers to develop the program to do this. The programmers don’t believe the monks are on to anything here, but a paycheck is a paycheck. They finish the program and start it running, but decide they don’t want to be there when the monks discover their theory doesn’t work, so they take off early without telling anyone, and head down the mountain. But on the way, they see the stars go out, one by one.

This classic short story won the Hugo for Best Short Story in 1956. The story opens with the return of an interstellar expedition that has been studying a system where the star went nova millennia ago. But the expedition’s astrophysicist, a Jesuit Priest, seems to be in a crisis of faith. And if you think it implausible that a Jesuit Priest could also be an astrophysicist, I would suggest you look into the case of the Belgian priest Georges Lemaître, who first developed the theory of the Big Bang. Anyway, in the story, they learn that this system had a planet much like Earth, and it had intelligent beings much like Earth, who were peaceful, but in a tragic turn of events they knew that their star was going to explode, but they had no capability of interstellar travel. So they created a repository on the outermost planet of the system that would survive the explosion, and left records of their civilization. And when the Jesuit astrophysicist calculated the time of the explosion and the travel time for light, he is shaken:

“[O]h God, there were so many stars you could have used. What was the need to give these people to the fire, that the symbol of their passing might shine above Bethlehem?”

This is a good Young Adult novel about the People of the Sea, who are dolphins. They save a young boy who had stowed away on a hovership that subsequently had crashed, and because no one knew about him he was left among the wreckage when the crew takes off in the life boats. And from here it is the typical Bildungsroman you find in most Young Adult novels. The dolphins bring him to an island, where he becomes involved with a research community led by a professor who is trying to communicate with dolphins. He learns various skills there, survives dangers, and in the end has to risk his life to save the people on the island. If you have a 13 year old in your house, this is worth looking for.

This won the 1972 Nebula Award for Best Novella. It concerns one Howard Falcon, who early in the story has an accident involving a helium-filled airship, is badly injured, and requires time and prosthetics to heal. But then he promotes an expedition to Jupiter that uses similar technology, a Hot-Hydrogen balloon-supported aircraft. This is to explore the upper reaches of Jupiter’s atmosphere, which is the only feasible way to explore given the intense gravity of this giant planet. Attempting to land on the solid surface would mean being crushed by the gravity and air pressure, so that is not possible. The expedition finds there is life in the upper clouds of Jupiter. Some of it is microscopic, like a kind of “air plankton” which is bio-luminescent. But there are large creatures as well, one of which is like jellyfish, but about a mile across. This is the Medusa of the title. Another is Manta-like creature, about 100 yards across, that preys on the Medusa. But when the Medusa starts to take an interest on Falcon’s craft, he decides to get out quick for safety’s sake. And we learn that because of the various prosthetics implanted after the airship accident Falcon is really a cyborg with much faster reactions than ordinary humans.

As we have discussed previously, Clarke loved the sea, and in this novella he is using what he knows in that realm to imagine a plausible ecology in the atmosphere of Jupiter. Of course when he wrote this novella no one knew about the truly frightening level of radiation around Jupiter, but then a clever science fiction writer could come up with a way to work around that.

Finally, no discussion of Arthur C. Clarke can omit his famous Three Laws. Asimov had his Three Laws of Robotics, and Clarke had his Three Laws of Technology.

This concludes our look at Arthur C. Clarke, the second of the Big Three of the Golden Age of Science Fiction. And that means we are ready to tackle the Dean of Science Fiction, Robert A. Heinlein.

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Provide feedback on this episode.

This show has been flagged as Clean by the host.

Provide feedback on this episode.