What is the point of these bots endlessly trying utterly random HTTP requests?

I can't be the only one seeing this kind of garbage in my server logs:

"GET /!?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /HotelInformation/HotelInformation.aspx?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /++?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.cancel?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.specialSubmit?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /img.youtube.com?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.droppable/?asdas1230ds0a=da90sue21qh HTTP/1.1"
"POST /.droppable/ HTTP/1.1"
"GET /_isMasked/?iqi_localization_country=x27f&vst=x27f&gitlab=x27f&1111ef1ee11b=x27f&ocxlaarct7tk=x27f&gad_source=x27f&landcode=x27f&confirmPrivacyStatement=x27f&26=x27f&frm_action=x27f…"

This is just a tiny sampling of endless junk that has been going on for at least the past 2 weeks. The last example is abbreviated, it goes on like that, with exactly 100 of those random query parameters that always have the same value “x27f.” It are several bots, which according to an IP locator service come from different countries, mostly the UK and Hong Kong. However, doing a WHOIS on each of the IP addresses reveals that many of them are hosted by Contabo GmbH, a cheap VPS hosting service in Germany.

Something similar has happened years ago, and then the junk also came from Contabo-hosted addresses. The pattern was similar, but each request then looked like the last example shown above, using a ridiculous number of query parameters with different field names but all the same value “z3re”. I filed an abuse report back then, and the junk stopped for a while, but it has been sporadically returning, and now it is back in a slightly different incarnation, but it still makes no sense at all. NONE.

Often these bots will still perform requests with a ridiculous number of parameters (usually 100), but more often they look like the above: a random string with the same damn query string appended to it. I really mean the same damn string for at least 2 weeks straight, which in the above case was obviously produced by someone bashing their keyboard: “asdas1230ds0a” and “da90sue21qh”. The same bot will keep on doing requests with the same base path like “.specialSubmit” or “London” for a whole day, and then might switch to another string for the next day, if I haven't kicked its ass with an iptables DROP in the meantime. The choice of these strings generally makes no sense. Lately they have also started using random characters next to city names and domains or just random words. Most of the time, the strings don't look like anything a real web app would ever use. It is all totally random. The mind boggles.

I really don't understand what is being tried to achieve with this. It is as if they are trying to brute force the internet in the hopes of finding an exploit, but the chances of this strategy producing anything fruitful is negligibly small, especially when not even varying the query parameters. Also, they do only 1 request about every 10 minutes, maybe to try to stay under the radar of suspicious activity detectors (not mine, obviously). At such slow rate, a Monte Carlo approach is just pointless.

I truly cannot grok what could be going in in the mind of whatever crackpot implemented this piece of junk and then decided to pump Kilowatts into a server farm to unleash this nonsense across the internet. If I see this in my logs, then it probably means they do these requests non-stop on whole IP ranges or a list of domains obtained from wherever. All that electricity is wasted on total nonsense. They had better spent the effort on mining crypto. It must take a very special kind of mental deficiency to believe this strategy will yield any return on investment.

Luckily the incomprehensible act of always using the same strings in the request, makes it easy to ban these bots. The set of IP addresses they work from is also pretty stable, so firing up the firewall is a good option as well.

The Music app in Mac OS 14 Sonoma causes pauses in the whole rest of the system

TL;DR: if you encounter hiccups in the UI while playing music, close the Music app window to avoid this. OR, open any program that uses 3D acceleration of any kind, it will also make the hiccups magically vanish. And please report this through Apple feedback.

My MacBook Pro “upgraded” itself to Mac OS Sonoma during a routine reboot, without my consent. This wouldn't be that bad if this new release of the OS would not be riddled with bugs. One apparent bug was that when the Music app starts playing the next track, and the display is sleeping, there would only be an empty notification temporarily waking the screen, with nothing else in it than the Music icon and the word “Music”. In previous releases this would show full song information as expected. Eventually I figured out that this is a ‘feature’: one needs to give the Music app explicit permission to show information on a “locked” screen, even though the screen is not actually locked in my case. Why it is then still allowed to show a pointless empty notification, beats me. Apple is starting to adopt Microsoft style logic.

Anyhow, on to the true bug that is the main topic of this post, and it is a bad one. It is quite simple:

• Playing local M4A or MP3 files will cause the whole system UI to freeze during about 1 second, approximately every 7 seconds. EXCEPT the Music app itself, which somehow remains immune against theze hiccups. Otherwise you will notice this by things momentarily hanging while scrolling, typing, or doing anything else that requires smooth updating of the screen (even video playback will stutter).
• Playing an internet radio stream will cause same UI freezes, but only when the metadata in the stream causes the status display in the Music app to change. For instance, if the stream contains artist and title information, you can expect everything to choke at the start of every new song. Somehow I have a knack for finding these weird correlations, I don't know why, but it only took about 4 occurrences to figure this out, then I confirmed it by doing some explicit tests.
• These nuisances only occur if the Music app window is open. Close it and the hiccups no longer occur. Of course I mean closing only the window, not quitting the whole app (which would obviously fix any problems caused by the app running).

I don't even know what could cause this. The days when playing an MP3 file required almost all CPU resources of a machine, are way behind us (I still remember one of my friends boasting about this with his 4/86). This seems like some kind of real-time priorities problem, or some UI rendering bug. The 14.3 update mentioned something about a performance problem with UI rendering, but alas, it definitely did not fix this bug because I still encounter it in Sonoma 14.3.1.
I bet it has something to do with all the unwanted security and privacy junk that is being poured into the OS, I wish there was just a big master toggle switch in the control panel “I am not an idiot, don't lock down my computer” to disable all this stuff.

How this kind of bug can have slipped through QA, is beyond me. I guess they don't really test playing local files anymore, assuming everyone will be happy to move to stupid streaming services that produce a steady revenue and that can be manipulated at leisure. However, I find reports in many places of Sonoma being sluggish and unresponsive, and I suspect that the Music app is not the only one causing this. It must be some deeper-level problem of which this is only one manifestation.

Update 2024/03/23: this is definitely some kind of rendering problem.

After some more experimenting, I found out that leaving certain other apps open, will also avoid the problem, even if the Music app window is visible while it is playing music. The magic apps that avoid the problem, are the ones that use OpenGL or some other kind of 3D acceleration. For instance Blender or OpenSCAD will do the trick, and even SheepShaver because it also relies on OpenGL as far as I can remember from when I was remotely involved in its development. Now I can only hope someone at Apple reads this and it gives them a clue about how to fix it…

HDR photos with a smartphone, built-in versus my own method

On this blog, I have published some examples of HDR photos before, which I created manually by relying on auto-bracketing features in digital cameras and combining the multiple exposure photos using Luminance HDR. One could argue that this is obsolete because pretty much every smartphone camera app nowadays has a HDR feature built-in. As I will show below however, this often leaves much to be desired and it still makes a lot of sense to produce HDR photos the manual way, be it with the smartphone camera or a ‘real’ camera.

My most recent smartphone is a OnePlus Nord, but its built-in HDR is a general nuisance. It only engages when it believes there to be a need for it according to some vague heuristic. Even when it claims to be enabled, sometimes the result shows no HDR at all, probably because it failed to find matches between the images. The latter usually happens when HDR is most needed, when taking photos of sunsets that result in high contrast.

This made me look for an alternative camera app that offers exposure bracketing, such that not only could I make HDR photos when I want to, I can also make them the way I want instead of having to rely on the half-baked algorithm built into the native camera app. I found Open Camera, which proved a great solution.

In this blog post I will compare some HDR photos taken with both the OnePlus camera app (and one with Open Camera's HDR), and HDR photos of the same scene produced with my own workflow, as explained in the article on my website which I recently updated.

Example 1: OnePlus' HDR versus mine. As usual with the built-in HDR tonemapping in smartphones, it tries hard to show details everywhere by pretty much steamrollering the intensities into one flat dull result. The overall image is too bright, lacks saturation, and does not represent the scene how I experienced it. My HDR image might look a bit dark in comparison, but it much better represents the sensation of the actual scene when viewed in its own on a big screen.

Example 2: again, the OnePlus HDR makes things too bright and it looks more like a daytime shot with some colour filter than a shot taken at sunset.

Example 3: same remarks as above.

Example 4: again, the OnePlus HDR makes the sky a dull mess, while all the interesting things are happening there.

Example 5: this time, the OnePlus HDR has roughly the same overall brightness as mine, but local details are lacking, especially in the darker areas where everything is just clipped to black.

Example 6: here I first show the result from the OnePlus camera app, then the built-in HDR of the Open Camera app, and finally my own HDR. The first 2 are similar although the Open Camera result has some artefacts that I sometimes also experience with Luminance HDR when I didn't use a sufficiently large range of exposures to capture all intensities in the scene. But again, the automated HDRs are too bright and have a yellowish tint that does not correspond with how I experienced the scene.

Example 7: again OnePlus versus mine, and again the colours in the OnePlus image are washed out and despite its overall higher brightness, details in the darker areas are lacking compared to my image.

Example 8: (added 2022/08/14) this was a particularly challenging image due to the enormous dynamic range. Obviously, the OnePlus app only takes 2 or maybe 3 photos with a rather limited exposure range, and lost the subtleties in the sky colours. The result looks harsh and overly bright. I switched OpenCamera to 5 shots with an exposure range of ±3 stops, which allowed to capture the scene as it was. I had to tweak saturaton more than usual to end up with a result that matches how I experienced this scene in the real world.

Conclusion

Again, if you want to make HDR photos the same way as I do, check out the article on my website. One of the things that makes it fun to process one's own HDR photos, is the fact that it brings back a bit of the magic that used to be experienced when taking photos on film, and only seeing the results later on when the film had been developed. It is not exactly the same thing, but producing the HDR image from the raw bracketed photos does have a bit of a feel of “developing” the images.

Making G'MIC Qt GIMP plug-in work in the 2.10.30 Mac version

If you are using the G'MIC-Qt plug-in for GIMP on Mac OS, especially the one from aferrero2707, you may have encountered this error after upgrading to a recent GIMP build:

GIMP says: “Plug-in crashed: "gmic_gimp_qt",” and warns about the dying plug-in possibly messing up GIMP's internal state.

Running GIMP from the Terminal yields a bit more information:

dyld: Library not loaded: @rpath/libintl.9.dylib

  Referenced from: /Users/username/Library/Application Support/GIMP/2.10/plug-ins/gmic_gimp_qt

  Reason: image not found

The Resynthesizer plug-in build from the same author suffers from the same problem.

It seems that these builds of the plug-ins rely on the presence of a dynamic library file ‘libintl.9.dylib,’ most likely in the GIMP application bundle itself. But, my current build of GIMP only includes libintl.8.dylib. Judging from a related issue report on GitLab, there never has been a true version 9 of this library and the number 9 was due to a mistake in the gettext library, which explains why the version number seemingly decreased.

Until someone creates a new build of the plug-ins, there is a relatively straightforward workaround: shove a copy of the libintl file into the G'MIC and Resynthesizer plug-in library folders, and give it the expected name. This ensures the plug-ins will always find this library regardless of what is in the particular build of GIMP.

There are 2 ways to obtain the dylib file:

1. [Slightly harder for those unfamiliar with low-level workings of Mac OS]
   Open your GIMP application bundle (either by right-clicking the app icon, or by using the Terminal), and find the libintl.8.dylib file, normally in Contents/Resources/lib/.
   Copy this file and rename the copy to libintl.9.dylib.
   This works because there is no significant difference between the version 8 and purported version 9 of the file.
2. [Easier but not that safe]
   Directly download it from wherever you find it on the web, and hope it is trustworthy. (This particular one works for me, it is 77584 bytes in size and has an MD5sum of 2a88ed7a2d8901fd0e75401e761b24d2.)

Place the libintl.9.dylib file inside the GMIC/lib folder where you installed the G'MIC plug-in, most likely ~/Library/Application Support/GIMP/2.10/plug-ins/GMIC/lib/, then restart GIMP and it might work.
Same for ResynthesizerPlugin/lib/.

Black & Decker 90515265 blade clamp can be used on the POW 1004

In a nutshell: you can use the Black & Decker 90515265 blade clamp as a spare part for the Powerplus (Varo) POW 1004 jigsaw.

This blade clamp on my old POW 1004 crumbled into pieces when I tried to use the saw after it had been sitting idle for many years. The part is made from the typical cheap metal alloy that is often used for casted parts. I don't know what metal this is, but it is like the equivalent of papier mâché and it seems to degrade over the years.

I was about to toss the whole saw because it was very cheap anyway, but I did a quick search for spare parts anyhow. I didn't find any spares for it, but this 90515265 Black & Decker part kept popping up amidst the results and it looked awfully similar in shape. I took the gamble and ordered two. Lo and behold: it just fits. It has an extra protrusion that makes it a tight fit and I milled just a tiny bit off the saw's body just to be sure, but this is not actually necessary.

I guess the reason why this fits is because many of these cheaper saws use the same internal components from some generic Chinese manufacturer. Not sure if this poorly made clamp part is a case of planned obsolescence or just poor design, but anyhow now we know how to avoid another piece of e-waste.

The B&D part looks much better designed with some extra reinforcements, but I still recommend not to overdo the tightening of the saw.

(and now in Dutch…)

B&D 90515265 zaagklem past op de POW 1004

In een notendop: u kan de Black & Decker 90515265 klem voor zaagblad gebruiken als vervangstuk voor de Powerplus (Varo) POW 1004 decoupeerzaag.

Deze klem op mijn oude POW 1004 verbrokkelde totaal toen ik de zaag probeerde te gebruiken nadat hij een paar jaar ongebruikt was gebleven. Dit onderdeel is gemaakt van de typische goedkope metaallegering die vaak gebruikt wordt om gegoten vormen te maken. Geen idee wat voor metaal het is, maar het lijkt het equivalent van papier-maché en schijnt bros te worden over de jaren.

Ik stond op het punt de ganse zaag weg te smijten omdat hij toch goedkoop was, maar ik besloot desalniettemin een snelle zoektocht te doen naar reserve-onderdelen. Ik vond niks voor dit model, maar dat 90515265 Black & Decker onderdeel bleef terugkeren in de resultaten en leek wel heel hard in vorm op het kapotte deel. Ik deed de gok en bestelde er twee. En kijk eens aan: het past gewoon. Er is een extra uitstulping waardoor het erg dicht bij de behuizing komt, en voor de zekerheid heb ik een klein beetje van de plastiek weggedremeld, maar dat was eigenlijk niet nodig.

Ik denk dat dit past omdat veel van deze goedkope toestellen dezelfde ingewanden gebruiken van een of andere generieke Chinese fabrikant. Ik kan niet zeggen of deze slechte klem een geval is van geplande veroudering, dan wel of het gewoon een slecht ontwerp is, maar nu weten we in elk geval hoe we nog een stuk e-afval kunnen vermijden.

Het B&D onderdeel lijkt veel beter ontworpen met extra verstevigingen, maar ik raad toch aan om het niet te hard aan te vijzen.

Apple made system calls horribly slow in the 10.14.6 update. Thank you, Apple!

After installing the Mac OS 10.14.6 update from the end of September 2020, I noticed something wasn't right. A simple Perl script that scanned a directory for all files and that invoked the stat system command for every file, had become way slower than before. I'm not sure if the same would have happened if it had relied on Perl's own stat() call, but this script needed the shell command because it can offer information that Perl's own stat couldn't provide.

Also when running a homebrew update, it seemed way slower than usual. It looks like Apple had messed something up w.r.t. system calls from within scripts, and perhaps other programs as well, although I didn't notice anything in regular apps. I knew this was likely to be reported by a gazillion developers and fixed soon, so I didn't bother. That horribly slow script of mine was annoying though, so I started seeing if it couldn't be improved.

The problem here was that the Perl script did the obvious thing of invoking a new instance of stat through backticks, for every single file it encountered. That's a lot of overhead. Until now the overhead wasn't bad enough for me to be sufficiently annoyed, but Apple's “update” had now pushed this way into the zone of bad words and gnashing teeth. The solution was pretty obvious: reduce the overhead by reducing the number of system commands. Luckily this could be done: the stat command does accept multiple files as argument, and returns the results as multiple lines in the same order as the arguments.

So, all I had to do was postpone the invocation of `stat` and build a queue of file paths, and execute the aggregated system command whenever it reached a certain size. In theory I could wait until the command line was about to exceed 262144 bytes (minus some margin to allow environment handling), which is the maximum system command length as reported by “getconf ARG_MAX.” In practice, I used a lower limit of 16 kBytes because above a certain threshold, the gain becomes pretty negligible anyway.

The result was that for a particular run, the script went from a 120 second runtime to 3 seconds. After Apple fixed the performance issue in a supplemental 10.14.6 update, the runtime became sub-second. So in the end I guess I should thank Apple for forcing me to refactor my script and making it way more efficient. Maybe every operating system should now and then introduce a temporary penalty on certain operations, or a limit on resources, just to force developers to be less lazy and actually improve their software instead of writing sloppy code and letting the machine just brute force it…

Cosmic Frontier: Override, a remaster of Escape Velocity: Override

A year ago I posted how it is still possible to enter your registration code in EV Nova, by jumping through some hoops. If you want to play the previous instalment of Escape Velocity however, Escape Velocity: Override, maybe this will soon be possible again without any need for special magic, in a brand new reincarnation of the game.

A Kickstarter campaign has been launched to rebuild the EV: Override game engine for current operating systems. Due to legal reasons, the game will have a different name: Cosmic Frontier: Override. One of the persons on the team for this Kickstarter is Peter Cartwright, who was the scenario designer for the original EV Override game.

The remaster will feature the original scenario, augmented with new content like new ship types and new mission strings. Depending on your backer level, you can influence this extra content, like having your own starport bar or ship variant. At the time of this writing, the campaign is just beyond its 50% funding mark, with 19 days to go. I'd really like to see this succeed, so if you are a fan of games like Escape Velocity and you have about $10 (or more) to spare, head over to the Kickstarter page and make your contribution.