Unreal Tournament 2004 now FREE! Linux support included!

UT2004

UT2004 is now free, easily installable on Linux Mac and Windows thanks to OldUnreal! This is even officially endorsed by Epic, so totally legit.

I just ran through the Linux install in less than 2 minutes. The download was very fast, no issues encountered.

You can use the install script here: https://raw.githubusercontent.com/OldUnreal/FullGameInstallers/master/Linux/install-ut2004.sh

Just mark it executable, and run with ./install-ut2004.sh -d /path/to/install (wherever you want)

UT99 (Game of the Year Edition aka GOTY), the original UnrealTournament is also available and has been for a little while.

https://github.com/OldUnreal/FullGameInstallers/tree/master/Linux

This is very exciting, and incredibly cool to see. I bought the Editor’s Choice box set back in the day and this was one of the first big box games I owned with native Linux support.

Linux Can Tell You All About Your SFP Modules

SFP+ Module

To start things off, I’d just finished switching everything over to the new Ryzen 5500–based server I built. Originally this box was using an Intel X540-T2 NIC, which has dual 10Gb RJ45 (10GBase-T) ports. If you’ve ever run 10 gig over twisted pair, you already know those things run hot. Really hot.

I had another NIC kicking around that uses SFP+, and figured if I could find some cheap fiber transceivers it might be a better way to link this machine up to my switch — especially from a heat and power perspective.

I ended up grabbing a pair of Avago-branded SFP+ transceivers and a fiber patch cable for $12.95 shipped on fleabay. Hard to argue with that. They’ve been working great so far, and they run MUCH cooler than the 10GBase-T setup. Like… not even close.

Out of curiosity, I plugged my cheap-o 4x 2.5Gb / 2x 10Gb switch into a Kill-A-Watt to see what was happening. One of the fiber SFP+ modules adds a little over a watt. The 10GBase-T SFP+ module I have? More like 3–4 watts, and that’s just sitting there at idle. Multiply that across ports and uptime and it adds up fast. No wonder 10GBase-T gear runs warm.

Anyway, here’s something neat I didn’t know before today: Linux can tell you all about your installed SFP modules. And not just basic info — actual live diagnostics.

In my case:

sudo ethtool -m enp3s0f0 — See the output of this @ the end of this post.

That command dumps the module’s EEPROM and diagnostic data. You get vendor info, part number, serial number, connector type, supported link modes, wavelength, and cable distance ratings. But you also get live telemetry.

Things like:
Module temperature
Supply voltage
Laser bias current
TX optical power
RX optical power
Alarm and warning thresholds

Which means you can answer questions like:

Is my transceiver overheating?
Is the RX light level getting too low (dirty fiber, bad patch cable, failing optic)?
Is the laser bias current unusually high?
Is anything drifting toward its warning thresholds?

I know very little about fiber compared to twisted pair, but this was pretty eye-opening. From that single command I learned my modules use LC connectors, I’m running 10GBase-SR with an 850 nm wavelength laser, and the link is rated for up to 300 meters on OM3, 80 meters on OM2, and 30 meters on OM1. In other words, short-range multimode optics — not single-mode.

And I can see that mine are currently sitting around 35°C, well under the 80°C warning threshold, with healthy TX/RX power levels and no alarms triggered.

That’s honestly pretty awesome.

I always assumed optics were black boxes. Turns out you can actually get a lot of data from them!
Continue reading “Linux Can Tell You All About Your SFP Modules”

Preventing accidental shutdowns when SSH’d into your server…

Because? People are stupid, we’re stupid sometimes…

If you’re like me, you probably SSH into a server occasionally and forget that it isn’t the local machine’s console when tabbing back to it after some time. This can really shoot you in the foot! Here are some ways to mitigate against accidental shutdowns which you can use on any server which is always-on. TLDR: Method #1 is probably the BEST.

NOTE: The systemd mask method would interrupt safe shutdown from say, your UPS telling the machine the battery is about to die. This is bad, so don’t create that situation. Unsafe shutdowns can lead to data loss!

Method #1 — Via the sudoers file. Never log into a server as root to monkey around. If you need root, it is best to su in, and exit out as soon as your task is done. This in and of itself is why sudo and doas are better options.

Here is how I can ensure that while logged in as “ben”, I won’t accidently fall victim to my sudo poweroff or sudo reboot stupidity.

visudo

This is on debian. Use whereis (command-nameto find the actual paths on your specific system. That won’t protect me if I’m logged in as root, but it will if I am logged in as ben. That is good enough for me, 99% of the time.

Method #2 — .bashrc of the user you normally use. This is not really effective, because if you prepend sudo to the command, it is going to run anyway!! This will however atleast remind you that you tried to do something dumb, and turn off the wrong machine. And yes, $SSH_CONNECTION is an environment variable you can use.

.bashrc

Method #3 — This is the only method that will truly stop the machine from shutting it down. If you’re using systemd, you can mask the commands and the system will not run them untill you re-enable them.

systemd

Probably not the best idea, because if say the power goes out now your machine won’t let the UPS trigger a safe shutdown. For now, I’ll move forward with the first two methods used together.

Moral of the story? Don’t do normal casual userspace work on the server! Just spin up a VM. Old habbits die hard, but this is definitely one I need to kill.

 

Writing a Better DD Wrapper GUI

Back in September last year, I was working on some kind of a wrapper for dd… Just for my own personal needs, nothing too fancy.

I got a little more ambitious, and was happy enough with the results to share it with anyone interested. Use at your own risk, of course.

What is it? It is a GUI front-end to dd. It is dependant on the GNU version of dd. Written in Python, uses QT toolkit.

GitHub: https://github.com/HarderLemonade/ddwrap/

Screenshot of DDWrap

© 2025 LostGeek.NET - All Rights Reserved. Powered by ClassicPress, NGINX, Debian GNU/Linux.