It's interesting to see that the UX issues that are annoying me when using Azure DevOps are finding their way into GitHub.

In case they are truly chasing Azure DevOps level UX, I would recommend they implement an HTML editor for issues that, depending on whether the user has dark mode or light mode enabled, saves some CSS of the respective mode and makes it unreadable if read within the other mode.

I'm using KDE as my daily driver and haven't noticed any ads so far. Where can I find these pester-ads?

The notification only exists since Plasma 6.2 (august 2024) [1]. Maybe some Linux distribution disable it?

[1] https://pointieststick.com/2024/08/28/asking-for-donations-i...

Ah, thanks for the link.

While I don't remember seeing the notification, I think a yearly (!) system notification doesn't exactly qualify as pestering.

I guess they mean this https://invent.kde.org/plasma/plasma-workspace/-/merge_reque...

And the naming restrictions and maximum name lengths are all over the place: https://learn.microsoft.com/en-us/azure/azure-resource-manag...

Storage accounts are one of the worst offenders here. I would really like to know what kind of internal shenanigans are going on there that prevent dashes to be used within storage account names.

I wonder if it's related to the fact that Windows as such weird rules about allowed file names. Like not directly obviously, more like culturally inside microsoft.

I’m pretty sure Azure was built out with Hyper-V, which was built into the Windows kernel. So everything that relied on virtualization would’ve had bizarre case insensitivity and naming rules.

I’ve lost track of servers in Azure because the name suddenly changed to all uppercase ave their search is case sensitive but whatever back-end isn’t.

Isn't case insensitivity a Win32 thing only? I would not expect it to impact stuff in Hyper-V or the windows kernel. AFAIK for example NTFS is case-sensitive.

NTFS supports case-sensitivity, but if you have case-sensitive distinctions in a directory that's marked case-insensitive, bad things happen. (Those bad things are probably entirely deterministic, theoretically-predictable, and documented in one of Raymond Chen's big books of Windows sadness, but that doesn't mean I want to deal with them as a mere mortal.)

I would not dismiss something like that directly being the cause. Not the reason you can't name a file "CON" on Windows, but it's very likely some weird ass thing they were stringing together with Windows Server and Hyper-V and SMB backed them into the corner we're all in now

> If I read it correctly (but could be mistaken), it runs with setuid root

I am certain you are mistaken. I couldn't find anything that hints at notepad running with elevated privileges.

People very often run notepad as administrator (anything launched from administrative powershell instances will run like this).

In fact, if you enabled developer mode on your computer there's a registry key that gets set to run notepad as admin, it's: `runas /savecred /user:PC-NAME\Administrator “notepad %1”` in HKEY_CLASSES_ROOT-> * -> shell -> runas (new folder) -> (Default)

And, if I'm not totally mistaken, notepad also has the ability to reopen files as administrator, but I don't remember how to invoke it.

Regardless, notepad is a very trusted application and is often run as Administrator. Often it's more trusted than any other utility to modify system files.

> And, if I'm not totally mistaken, notepad also has the ability to reopen files as administrator, but I don't remember how to invoke it.

I think that's a notepad plus plus feature. I had it offer to reopen itself as administrator when editing system files like HOSTS.

> Regardless, notepad is a very trusted application and is often run as Administrator.

Sorry to say this, but Notepad was a very trusted application now. I cannot believe that such a core utility has a 8.8 CVE, it sounds like a joke tbh.

A totally valid modification to the statement I made.

These are sad times.

I wouldn't say that multiple implementations are duplicating the attack surface since most users will not end up running them in parallel.

I meant at a global level (think as if you're attacking all wireguard users, not a single one)

The increased attack surface mostly only affects that one particular implementation though. So, yes, twice as many implementations that may contain exploitable bugs, but each new implementation could only be used to exploit a fraction of the total user base

> could only be used to exploit a fraction

If anything this is a even a good thing, since it means that each individual vulnerability an attacker finds is less valuable to them.

The debian security announcement for stretch says

> For the oldstable distribution (jessie), this problem will be fixed in a separate update.

You can check https://security-tracker.debian.org/tracker/CVE-2017-5754 whether the KPTI patch has been released for jessie.