No idea about the Lemmy hosting bit, but I highly doubt that .com you got will renew at $1 going forward. Judging by this list it’ll most likely be $9+ after the first year.
At $1/year, the registrar you used is taking a loss because they pay more than that to the registry for it. They might be fine with that for the first year to get you in the door, but they’d presumably prefer to be profitable in the long term.
Clearly he’s actually the BBEG lich in disguise. Time for a phylactery hunt! ;)
Have you also enabled Bot Fight Mode? (There’s a setting to “Block AI bots” that seems useful in your situation)
Try exiting it and then make sure no tmux process is still running, by for example running ps -aux | grep tmux.
For future reference: the command to kill the tmux daemon (and as a side-effect, all other running tmux processes connected to it) is tmux kill-server (or in tmux, typing <prefix> :kill-server, assuming default keybindings).
C and C++?
You don’t actually have to set all the modification dates to now, you can pick any other timestamp you want. So to preserve the order of the files, you could just have the script sort the list of files by date, then update the modification date of the oldest file to some fixed time ago, the second-oldest to a bit later, and so on.
You could even exclude recently-edited files because the real modification dates are probably more relevant for those. For example, if you only process files older than 3 months, and update those starting from "6 months old"1, that just leaves remembering to run that script at least once a year or so. Just pick a date and put a recurring reminder in your calendar.
1: I picked 6 months there to leave some slack, in case you procrastinate your next run or it’s otherwise delayed because you’re out sick or on vacation or something.
If you don’t mind using a gibberish .xyz domain, why not an 1.111B class? ([6-9 digits].xyz for $0.99/year)
Any chance you’ve defined the new networks as “internal”? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).
Because the symptoms you’re describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn’t realize what that option does…
It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.
For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.
This StackOverflow thread shows how to set that up for a few different reverse proxies.
I may have slightly misremembered the license text (subsection 4c):
You must cause any modified files to carry prominent notices stating that You changed the files;
So I guess technically you only need to indicate that you have changed the files, not what you’ve changed in them. I suppose that’s less burdensome because it only needs to be done once per file at most.
I don’t think so, no.
Leaving aside the fact that I don’t want to do that:
They’ve quite sensibly vendored my library, so I’d have to hope they pull in updates without checking the code changes: since it’s such a tiny library (excluding tests but including fairly extensive comments, it’s less than 100 lines of quite readable code) I don’t think it’d be easy to get it past their code review system if I tried to sneak in enough code to take down entire companies.
Also, my GitHub account is tied to my real-world identity, so I’d probably be in a lot of trouble if I somehow succeeded.
For MIT, why do you care? That’s perfectly fine and explicitly allowed by the license. Same for Apache, but with a few extra requirements (like keeping a list of changes in the source code and preserving licensing information etc.).
As for how I know big corporations are using my code: the fact that a prominent project (publicly used by several tech giants) took a dependency on one of my tiny (permissively licensed) library packages is probably a clue.
I added paragraph breaks after every newline:
I originally told the story over on the other site, but I thought I’d share it here. With a bonus!
I was working on a hardware accessory for the OG iPad. The accessory connected to the iPad over USB and provided MIDI in/out and audio in/out appropriate for a musician trying to lay down some tracks in Garage Band.
It was a winner of a product because at its core, it was based on a USB product we had already been making for PCs for almost a decade. All we needed was a little microcontroller to put the iPad into USB host mode (this was in the 30-pin connector days), and then allow it to connect to what was basically a finished product.
This product was so old in fact that nobody knew how to compile the source code. When it came time to get it working, someone had to edit the binaries to change the USB descriptors to reflect the new product name and that it drew <10mA from the iPad’s USB port (the original device was port-powered, but the iPad would get angry if you requested more than 10mA even if you were self-powered). This was especially silly because the original product had a 4-character name, but the new product had a 7-character name. We couldn’t make room for the extra bytes, so we had to truncate the name to fit it into the binary without breaking anything.
Anyway, product ships and we notice a problem. Every once in a while, a MIDI message is missed. For those of you not familiar, MIDI is used to transmit musical notes that can be later turned into audio by whatever processor/voice you want. A typical message contains the note (A, B, F-sharp, etc), a velocity (how hard you hit the key), and whether it’s a key on or key off. So pressing and releasing a piano key generate two separate messages.
Missing the occasional note message wouldn’t typically be a big deal except for instrument voices with infinite sustain like a pipe organ. If you had the pipe organ voice selected when using our device, it’s possible that it would receive a key on, but not a key off. This would result in the iPad assuming that you were holding the key down indefinitely.
There isn’t an official spec for what to do if you receive another key-on of the same note without a key-off in between, but Apple handled this in the worst way possible. The iPad would only consider the key released if the number of key-ons and key-offs matched. So the only way to release this pipe organ key was to hope for it to skip a subsequent key-on message for the same key and then finally receive the key-off. The odds of this happening are approximately 0%, so most users had to resort to force quitting the app.
Rumors flooded the customer message boards about what could cause this behavior, maybe it was the new iOS update? Maybe you had to close all your other apps? There was a ton of hairbrained theories floating around, but nobody had any definitive explanation.
Well I was new to the company and fresh out of college, so I was tasked with figuring this one out.
First step was finding a way to generate the bug. I wrote a python script that would hammer scales into our product and just listened for a key to get stuck. I can still recall the cacophony of what amounted to an elephant on cocaine slamming on a keyboard for hours on end.
Eventually, I could reproduce the bug about every 10 minutes. One thing I noticed is that it only happened if multiple keys were pressed simultaneously. Pressing one key at a time would never produce the issue.
Using a fancy cable that is only available to Apple hardware developers, I was able to interrogate the USB traffic going between our product and the iPad. After a loooot of hunting (the USB debugger could only sample a small portion, so I had to hit the trigger right when I heard the stuck note), I was able to show that the offending note-off event was never making it to the iPad. So Apple was not to blame; our firmware was randomly not passing MIDI messages along.
Next step was getting the source to compile. I don’t remember a lot of the details, but it depended on “hex3bin” which I assume was some neckbeard’s version of hex2bin that was “better” for some reasons. I also ended up needing to find a Perl script that was buried deep in some university website. I assume that these tools were widely available when the firmware was written 7 years prior, but they took some digging. I still don’t know anything about Perl, but I got it to run.
With firmware compiling, I was able to insert instructions to blink certain LEDs (the device had a few debug LEDs inside that weren’t visible to the user) at certain points in the firmware. There was no live debugger available for the simple 8-bit processor on this thing, so that’s all I had.
What it came down to was a timing issue. The processor needed to handle audio traffic as well as MIDI traffic. It would pause whatever it was doing while handling the audio packets.
The MIDI traffic was buffered, so if a key-on or key-off came in while the audio was being handled, it would be addressed immediately after the audio was done.
But it was only single buffered. So if a second MIDI message came in while audio was being handled, the second note would overwrite the first, and that first note would be forever lost. There is a limit to how fast MIDI notes can come in over USB, and it was just barely faster than it took to process the audio. So if the first note came in just after the processor cut to handling audio, the next note could potentially come in just before the processor cut back.
Now for the solution. Knowing very little about USB audio processing, but having cut my teeth in college on 8-bit 8051 processors, I knew what kind of functions tended to be slow. I did a Ctrl+F for “%” and found a 16-bit modulo right in the audio processing code.
This 16-bit modulo was just a final check that the correct number of bytes or bits were being sent (expecting remainder zero), so the denominator was going to be the same every time. The way it was written, the compiler assumed that the denominator could be different every time, so in the background it included an entire function for handling 16-bit modulos on an 8-bit processor.
I googled “optimize modulo,” and quickly learned that given a fixed denominator, any 16-bit modulo can be rewritten as three 8-bit modulos.
I tried implementing this single-line change, and the audio processor quickly dropped from 90us per packet to like 20us per packet. This 100% fixed the bug.
Unfortunately, there was no way to field-upgrade the firmware, so that was still a headache for customer service.
As to why this bug never showed up in the preceding 7 years that the USB version of the product was being sold, it was likely because most users only used the device as an audio recorder or MIDI recorder. With only MIDI enabled, no audio is processed, and the bug wouldn’t happen. The iPad however enabled every feature all the time. So the bug was always there. It’s just that nobody noticed it. Edit: also, many MIDI apps don’t do what Apple does and require matching key on/key off events. So if a key gets stuck, pressing it again will unstick it.
So three months of listening to Satan banging his fists on a pipe organ lead to a single line change to fix a seven year old bug.
TL;DR: 16-bit modulo on an 8-bit processor is slow and caused packets to get dropped.
The bonus is at 4:40 in this video https://youtu.be/DBfojDxpZLY?si=oCUlFY0YrruiUeQq
And MATLAB appears to produce 51, wtf idk
The numeric value of the ‘1’ character (the ASCII code / Unicode code point representing the digit) is 49. Add 2 to it and you get 51.
C (and several related languages) will do the same if you evaluate '1' + 2.
I’ve never used Rust or Zig, but for Go: (disclaimer: this is all from memory, so there may be inaccuracies or out-of-date information here)
Go does not allow circular references between modules. That restriction allows the compiler, when compiling a module, to not only put the compiled machine code in the resulting object file for that module but also the information that in C would be required to be in a header file (i.e. type definitions, function signatures, and even complete functions if they’re considered candidates for inlining, etc.). When compiling a module that imports others, the compiler reads that stuff back out of those files. Essentially a compiled Go library has it’s auto-generated “header file” baked-in.
In older versions this was actually human-readable: an early part of the object file would essentially look like trimmed-down Go when opened in a text editor. IIRC they’ve switched to a binary serialization format for this some years back, but AFAIK it still essentially works the same.
I guess when comparing to C or C++, you could compare this to automatically generating pre-compiled headers for every module, except the headers themselves are also auto-generated (as you alluded to in your post).
If by “shared library” you mean a dynamically linked one: IIRC Go does allow shared libraries to be used, but by default all Go code is linked statically (though libraries written in other languages may be dynamically linked by default, if you import a module that requires it).