Dammit.

…

Shit, that’s good.

Sweet jebus. You’re jumping into one of the biggest (if not the biggest) game console libraries ever. There’s a lot to pick from, and… there’s a lot of trash too.

It may not be to everyone’s taste, but I really enjoy the Burnout series. Each title brings something new to the table, and the music and energy just don’t let up. The only problem here is the brutal load times between every level, which on emulation, probably aren’t going to be an issue for you. The licensed soundtrack is also something of a time-capsule now, so it may be worthwhile on that point alone.

There are a few Castlevania titles for the PS2 as well. These are a fun departure from the side-scrolling formula, and seem to have learned a few tricks from Devil May Cry. They deliver on mood and challenge, but I wouldn’t rank them as high as the GBA or PS1 titles. Still, they’re fun to play.

If you wind up short on recommendations, I’ll add that PS1 titles should get an honorable mention here. The PS2 is fully backwards compatible with the PS1, so those cream-of-the-crop titles kinda/sorta count. For a lot of us, that was a big part of the experience of owning one of these machines as your library just kept growing into the new console gen. But you’ve probably already heard of Metal Gear Solid, Symphony of the Night, FFVII, WipeoutXL, Tony Hawk, and so on.

My god. The bets you could win with people.

“Okay, so I’m going to eat this - what was in it again? Durian, sardines, kimchee, and muenster cheese salad? Let’s add some onion for crunch and I’m in.”

It’s been a hot minute, but here’s what I recall.

Take a look under /etc/systemd/system/ This is a good place to put custom system files.

You’ll want to add your new foobar.service file here, then run systemctl daemon-reload or systemctl reload foobar to make systemd load the new config file. Then you can run systemctl start foobar and so on.

The rest is up to you and the published docs for the system file itself. My recommendation is to also try to understand daemons you may already use like nginx, apache, postgresql, etc. Their configs can be found by first running systemctl status <servicename> and to look at the Loaded: line. Most of the packaged stuff is hanging out under /lib/systemd/system.

I appreciate that. And don’t count yourself as less advanced - a lot of folks would consider using a CM tool like Ansible to be pretty wizardly stuff.

You’re not alone. For most of my career, I’ve only used Linux to develop software and deploy that software to production. That usually means webservers, databases, iptables/netfilter, and all the other backend processes that glue that together.

Before systemd, I was using sysVInit. Let me say that systemd has been head-and-shoulders above the previous experience in a variety of ways, with a host of built-in features:

• Predictable start-up order of processes
• Configurable inter-process dependencies (for the above)
• Restart on fail
• PID management
• Socket management
• Standard config format (no more copy-pasta init scripts)
• Clearly defined filesystem areas for package managed and user-managed services
• Clearly defined layering of config areas (e.g. systemctl status <service> shows you exactly what files are loaded)
• Solid CLI experience that provides detailed information about every managed service

Bottom line: it’s dead simple to add your own stuff, and just as simple to read what packaged software is doing. I also think that using a CLI (instead of poking around /var/run and ps output) is a step up in terms of system administration, given how complex all this can get.

My only contention is the forced use of journald, where my preference would be to use the standard /var/log paradigm for all this, rather than have a doorman to a binary logging database. You can configure it to emit text logs, but that’s not the system of record for logging - just a feed.

All that said, container-based solutions have rendered both init systems irrelevant a lot of the time, with tools like Kubernetes providing just about all of the same features. Moreover, cloud solutions tend to lean into cloud-init for host startup configuration and management anyway.

On my aging laptop, the Discord app consumed RAM like Goku at an all-you-can-eat buffet. Moving back to a browser tab eliminated the overhead from Electron and was dramatically more performant as a result. This completely side-steps any upgrade and/or snap issues.

Sweet jebus, it really can do anything. Just put it in the kernel already. /s

I’ve used both. What I can tell you is that moving to WSL is like moving to Linux wholesale. Treat it like porting your toolchain.

IIRC, MinGW tools will happily take windows style paths (e.g. “C:\Users~myuser\projects”). If your tooling/scripting depends on being able to use Windows style paths, you’ll have to fix that first or you’re going to have a really bad time. There may be other small differences between MinGW tools and what ships on Ubuntu (or whatever Linux you decide to use in the WSL).

All I know is that the WSL is a massive step-up from Cygwin or Mingw32. We’ve been here before. The most recent incarnation before WSL was a klunky VirtualBox VM steered by Packer. The idea that you can mash a few buttons and get an Ubuntu VM with filesystem mapping that “just works” is a huge improvement.

Edit: I really don’t get the vitriol anyone gets for using the WSL when it’s a problem the FOSS community has tried to solve three times over in the last 25+ years or so.

Plot twist: It was INS the whole time.

Agreed, although it’s wise to have a backup option for this. It’s entirely possible that you have two solid Portal players go at this, which should be a really fun romp. However, in my experience, any skill gap between the players usually turns every stage into “how do I carry my friend through this puzzle?” An extreme version of this can be seen in Game Grumps’ playthrough.

I agree and disagree.

The premise is solid: unify config so it’s standardized and machine parse-able for better integrations like an easier-to-build UI/UX. It could even have ramifications for cloud-init and older IaC tech like Puppet.

The problem is Linux itself. Or rather, the subsystems that are cobbled together to make Linux a viable OS. You’re not going to get all the different projects to pivot to a common config scheme, so this YAML standard would need a backend to convert to/from whatever each little deamon and driver requires. This creates a few secondary problems like community backlash (see systemd), and having multiple places where config data must be actively synchronized.

I think the current crop of GUI config systems are aleady well down the most pragmatic path: each config panel touches one or more standard config files, wherever they are, and however they are structured. It’s not pretty under the hood, and it’s complicated, but it works. These tools just need a lot more polish on the frontend.

echo "text file content goes here" >> myfile.txt