Podcasts about freeciv

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. Let me start by admitting that I've never actually seen the film referenced in the episode title, but I couldn't resist using it anyway. If you've used the UNIX command line to any extent, chances are good that you are familiar with the kill command. A common use is to terminate a misbehaving program. But there is more behind how kill works, including a curio you might not know about. The kill utility works by sending a "signal" to the targeted process. This signal is selected from a pre-defined list, and triggers the process to interrupt its normal flow and handle the signal before potentially returning back to its work. This "signal handler" can do whatever activities are written in its code, but typically it will take actions connected to the purpose of the specific signal received. One option is for the process not to have a signal handler at all; in that case, there is a default action that the operating system will take on behalf of the process, depending on what the signal is. The possible default actions are to terminate the process, take some implementation-defined action (usually writing a core file to disk) and then terminate the process, stop (pause) execution of the process, continue execution of a stopped process, or ignore the signal. By default, kill sends the TERM signal to the process, an indicator that it should terminate. Each signal has a name and a number assigned to it; SIGTERM is the name of the "terminate" signal. You can use the -s option with the name to choose which signal to send. The 'kill' command is specified to take these names without the SIG prefix, though some implementations will accept them either way. Also, kill is supposed to be case-insensitive when it comes to these names, but the convention is to write them in all upper case. The assigned numbers for signals can vary depending on the operating system, and on Linux, depending on what processor architecture you're on. However, there is a short list of signals 1 that have a stable number assigned to them. Despite this, I recommend using the signal name in your scripts to make them clearer and to ensure maximum portability to different systems. Well-behaved programs will have a signal handler that responds to the TERM signal by stopping what they are doing, cleaning up any open resources like temporary files, and promptly exiting. However, not every program behaves well, so sometimes it becomes necessary to send them the KILL signal. This one is special and cannot be handled or ignored by the program 2 ; the operating system will immediately terminate the program, possibly leaving a mess behind. Two other signals that can come in handy sometimes are STOP and CONT. As you might expect, STOP forces a process to pause in the middle of whatever it was doing. Its counterpart, CONT (short for "continue"), causes it to resume execution. This can be useful if a program consumes CPU time when not actually doing anything worthwhile—sending it the STOP signal will end that, and when you're ready to use it again, CONT will cause it to pick up right where it left off. Like the KILL signal, STOP cannot be handled or ignored by the program. I have used this to pause the game FreeCiv when I wanted to break away to do something else, but didn't want to have to deal with exiting my current game and having to reload it later. Take note, though, that the program might get confused if it expects the system clock not to suddenly jump forward, as that is exactly how the situation will appear to it. Network connections or other resources the process is using that change while it is stopped are other potential trouble spots. Also be aware that a stopped graphical program will not update its window, so I find it best to minimize the window before stopping it and then continuing the process before trying to raise the window again. Programs are not necessarily required to interpret signals in the way they are described. For example, the HUP signal was originally intended to be sent when a modem or serial connection hang-up occurred. Today, some daemons use it for other purposes and take a specific action in response. For example, the Apache web server will restart 3 , and NetworkManager will reload its configuration 4 . These uses of signals are usually described in the daemon's manual page, often in a separate section dedicated to signals. While all this background might be interesting (or maybe not), it's pretty commonly known, so isn't really a curio. Our UNIX Curio for today is the "0" signal. This is actually not a signal at all; instead, it tells the kill utility to just check for the existence of a process. If the process exists, kill will exit with a status of 0. If it doesn't exist, the exit status will be greater than 0. This provides a handy way to check whether a particular process is still around. A shell command can use this exit status with its control structures like if to take a particular action depending on whether a particular process exists. Somewhat oddly, "0" is both the number and the name of this pseudo-signal. Why would you want to do this? I have used it for a script to analyze log files that runs daily on a web server. Depending on how much traffic the site is getting, the log files can grow to the point where it takes longer than a day for the script to get through them. If a second instance of the script is started while one is still running, it will slow down both and if more keep being added, eventually the machine will run out of memory. My solution was to create a .pid file containing the process ID number of the running script. You might see examples of these if you look in /run or /var/run on your system. The script creates a file named something like "myscript.pid" in this directory containing its own process ID, which can be accessed in the shell with the variable $$ . When my script starts, it checks to see whether this file exists. If so, it uses kill -s 0 $(cat /run/myscript.pid) to see if the previous process still exists. If the process is no longer around, that's a sign that it exited abnormally before it had the chance to delete the .pid file, so the script removes the abandoned .pid file, replaces it with a new one containing the current process ID, and continues with its work. If the previous process is still around, my script exits with a message to that effect. This way, I can be sure that only one instance of the script will ever be running at one time. Be aware that the kill utility might also return a non-zero exit status if the user running it does not have privileges to send a signal to the process with the specified ID. This is not a concern if you are running a script as the root user, but could be if you are not. This can occur even if you aren't actually sending a signal, just using the "0" pseudo-signal to check if a process exists. There is a weakness in this method. UNIX-like systems generally have a limit to the quantity of process ID numbers that can be issued, so they are reused over time. (However, there will never be two processes with the same ID number running at the same time.) Typically, the first process that is run on start-up will be given the ID number 1, and each subsequent process will get the next higher number. Once the maximum is reached, the system starts again at the beginning with the lowest number not in use. It is possible for the script to crash and leave behind the .pid file, then the same process ID could be recycled and actively used for another program, causing a new instance of the script to give up. The chances of this are small enough that for my purposes, it's not worth worrying about. But you should be aware that it could happen. I should also note that it's not strictly necessary to use kill for the purpose I described. The ps utility can also be given a process ID with the -p option; if the process exists, the exit status will be 0, otherwise it will be greater than 0. In this case, you could also use the output to check that the name of the command matches what you expect, helping avoid the problem of a recycled process ID. In addition, ps doesn't concern itself with permissions for sending signals, so it will report on the existence of a process no matter what user you are running it as. From an efficiency standpoint, kill generally requires fewer resources to run (in fact, it is built in to some shells), but functionally ps can also do the job. So keep in mind that kill is capable of doing more than just killing off programs—maybe you can put it to one of these uses for your needs. References: Kill specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/kill.html signal.h specification https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html Stopping and Restarting Apache HTTP Server https://httpd.apache.org/docs/2.4/stopping.html#hup NetworkManager: Signals https://networkmanager.dev/docs/api/latest/NetworkManager.html#id-1.2.2.9 Appendix 1 - example script: #!/bin/sh # Use your own unique name here - be sure you can write to this location pidfile="/var/run/myscript.pid" # Exit if previous run hasn't completed yet if [ -f "$pidfile" ] ; then oldpid=$(cat "$pidfile") if kill -s 0 $oldpid ; then echo "${0}: Not running script, older process $oldpid still active" exit 1 else echo "${0}: Removing old pidfile from nonexistent process $oldpid" rm -f "$pidfile" fi fi # Create pidfile echo $$ > "$pidfile" ## Insert commands to do the actual work of the script here # Remove pidfile rm -f "$pidfile" Appendix 2 - another version of the script using ps instead of kill , checking that an existing process ID is actually the same command, and with extra validation of the contents of the pidfile; perhaps better for use by a non-root user: #!/bin/sh # Use your own unique name here - be sure you can write to this location pidfile="$HOME/myscript.pid" # Exit if previous run hasn't completed yet if [ -f "$pidfile" ] ; then oldpid=$(( 1 * $(cat "$pidfile") )) if [ -n "$oldpid" ] && [ "$oldpid" -gt 1 ] ; then : else echo "${0}: Not running script, $pidfile contents invalid" exit 1 fi # Test if old process ID exists if oldcmd="$( ps -o comm= -p $oldpid )" && # Also test if command name of old process is same as current script [ "$oldcmd" = "${0##*/}" ] ; then echo "${0}: Not running script, older process $oldpid still active" exit 1 else echo "${0}: Removing old pidfile from nonexistent process $oldpid" rm -f "$pidfile" fi fi # Create pidfile echo $$ > "$pidfile" ## Insert commands to do the actual work of the script here # Remove pidfile rm -f "$pidfile" Provide feedback on this episode.

Lords: Andrew https://kittenm4ster.neocities.org/ Aubrianne Topics: Reading every Hugo-award-winning novel I accidentally made Frog Fractions 2.5 before knowing what a frog fractions was https://www.lexaloffle.com/bbs/?pid=40777 I've discovered the perfect video game genre https://mastodon.social/@mogwai_poet/116072652112241644 When I Heard the Learn'd Astronomer, by Walt Whitman https://www.poetryfoundation.org/poems/45479/when-i-heard-the-learnd-astronomer Software Toolworks Multimedia Encyclopedia CD from 1992 https://archive.org/details/the-software-toolworks-multimedia-encyclopedia-1.5-1992-12-english-cd I fixed my slow computer with time travel https://github.com/grassmunk/Chicago95 Microtopics: Plugging moving. Apps that don't do things or have functionality. Wearing one of those blood pressure cuffs all day. The treadmill hacking into your heart rate monitor. Getting your heart rate up by being aggravated at terrible exercise apps. Video games that only work with first party controllers because they patch the controller firmware. The only team that was permitted to alter the microcode on the Nintendo 64's GPU. Reading every Hugo award winning novel. Sci-fi authors in the 50s being obsessed with advancements in psychiatry. What if there was an empire that spanned a continent. Drinking a potion every morning to address your ADHD. Dissolving your gummy vitamin in liquid nitrogen and/or Looking forward to the next time you get sick so you can take NyQuil again. The Snow Queen by Joan D. Vinge. Why they let women write books now. Advantages of AuDHD. The Hugo award, invented by the protagonist of Hugo's House of Horrors. Knock-off Sierra games. Feed the Ducks. The one with the Spider-Bat. Stealth plugging a classic Pico-8 game. Independently inventing Frog Fractions. Not-Vector Art. Making games that don't have a secret thing in them. Making Pizza Panda without ever telling anyone what you're working on. Picking up a mouse with hats. Just make a dumb thing that's silly and you can make fun gifs of it. Splore 'em if you got 'em. XAMWWSKH, or "Exam Whiskey" Curses, or ncurses. Walking around this maze and running into this guy and suddenly you're playing a minigame. Whether weird shit keeps happening in Pac-Man, or happens only once. Why wait at all? Just wake up each day and be surprised. Aren't we all just building mazes for ourselves? Why sports games still exist. Why do people play sports video games when they could play sports in real life? Snapping your fingers in order to better internalize the poem. What have you over-intellectualized in your life? Your particular brainotype. Learning about muscles, joints and physiology. A bicycle reflector they put on the moon so they could shoot lasers at it. Measuring diagrams during your lecture. The astronomer who lost his nose. Revealing that you've drawn a moustache on Orion's Belt. Learning to read words by looking at a spectrogram. Who knows what the Danes are up to? Things that are not widely known but can be described. Looking at really old computer stuff because that's fun. Beautiful art that nobody made on purpose. Getting actors together in a room to read a scene together before discovering that that's exactly the wrong way to do video game voice acting. Aphantasia but for audiation. Inability to audiate at different volumes or on the stereo spectrum. Focusing really hard to fall asleep. Kick-starting your hypnagogic hallucination dream state. Rolling that sleep boulder up the hill every day. Retheming your 2026 Linux computer to look like Windows 95. Downloading 20 years of email history. Playing Hunt the Wumpus on your dad's SIM-1. What game developers say now that "AI" means something else. What "drone" used to mean, and also what it meant before that. OpenRCT2 and FreeCiv. Making your customers less nauseous before they sit on a bench. Not having any restaurants at your theme park so that nobody throws up on your roller coaster. Being unable to A/B test your brain because you only have one brain. Having a variety of weirdos on Jorts dot horse.

Question: What applications are available for Ubuntu MATE? Answer: Thousands. We discuss a few of them by category. Episode Time Stamps 00:00 Going Linux #440 · Welcome to Linux! Pt 9 - Software Choices 00:58 Larry tries Ubuntu Cinnamon 22.04 (ahead of the official flavor) 12:23 Your software choices in Ubuntu MATE 13:32 How many software applications are available? 14:04 Browsers: Mozilla Firefox, Chromium, Google Chrome, Brave, Opera, SeaMonkey, Vivaldi, Tor, LYNX, Microsoft Edge 14:48 Email clients: Thunderbird, Evolution, Geary, Mutt, Claws Mail 16:26 Office Suites: WPS Office for Linux, LibreOffice, ONLYOFFICE 21:35 Note taking: Joplin, RedNoteBook, Zim, Simplenote 25:37 Music Players: Lollypop, Clementine, Audacious, DeaDBeeF, Rhythmbox, VLC, Amarok, Musique 30:15 Video Players: VLC, SMPlayer, Miro, MPV Player, Gnome Videos, Dragon Player, Xine Multimedia Engine, Deepin Movie 32:51 Recording audio: Audacity, Recorder, Sound Recorder, Ardour, MusE 35:43 Recording video: OBS Studio, Shotcut 38:37 Games: Xonotic, Warsow, SuperTuxCart, Assault Cube, 0 A.D., The Battle for Wesnoth, Dota 2(requires Steam), Team Fortress 2(requires Steam), FreeCiv, Alien Arena 43:47 What is YOUR favorite application? 44:34 Software recommendation: Discord 47:54 goinglinux.com, goinglinux@gmail.com, +1-904-468-7889, @goinglinux, feedback, listen, subscribe 49:13 End

This week we talk to Chris Boos, the man who trained a robot to beat humans at FreeCiv.

This week we talk to Chris Boos, the man who trained a robot to beat humans at FreeCiv.

Hey this is our Podcast! December 11th 2016 Episode 2 We talk about Dota 2, Factorio, Freeciv, and Scyth. With a little bit more focus! Song Credits at the end of the Podcast email us at circlestrafepodcast@gmail.com twitch at twitch.tv/circlestrafepodcast

Horst JENS und Gregor PRIDUN plaudern über freie Software und andere Nerd-Themen. Shownotes auf http://goo.gl/zA0xjB oder http://biertaucher.at

This week: Print your own firearms! We spoil Iron Man 3. EA controls Star Wars games' destiny. Rut Roh. Nintendo owns all of your ad revenue. FreeCiv will eat your FreeTime! Agents of S.H.I.E.L.D. baybee! Warner to take a stab at a D&D movie...maybe. Dragon Age 3 may not suck! All of this, plus the TV and movie franchises that you all hate, on this episode of Casually Hardcore! Show notes and Research Thread available here: http://media.vtwproductions.com/forum/index.php?board=40.0

In this episode: an overview of a few games for adults and kids alike that work great in Linux: Quake 2, Quake 3, OpenArena, Unreal Tournament, Return to Castle Wolfenstein, FreeCiv, LinCity, LinCity-NG, Micropolis, OpenTTD, Frozen-Bubble, Enigma, Fillets-NG, Pingus, Neverball, Neverputt, Supertux, Abe's Amazing Adventure, Secret Maryo Chronicles, Barbie's Seahorse Adventures, Trip on the Funnyboat, Moonlander, TuxKart, SuperTuxKart, Armagetron, GLTron, Tuxracer, PlanetPenguin Racer, Extreme Tux Racer, Battle for Wesnoth.