bobince

> Countless time wasted because the anti-virus or some other part of Windows locked a file.

And the whole edifice of “you need to reboot to update anything” is a knock-on effect of the file locking/sharing model, leading to the misery of “we forced a reboot and lost your work again, sucks to be you”.

OVH are putting up prices in the same way, with the same reasoning. (I don't know about storage, but VPS stuff I'm using is going up ~20%.)

Used to be every VPS refresh cycle you'd get more server for less money. This is miserable

Of all the things I wrote on SO, including many actually-useful detailed explanations, it was this drunken rant that stuck, for some reason.

Yes, they're originated by PayPal, but collected by a different original recipient and from there sent on to the victim. The envelope-recipient is not part of the material signed by DKIM, so the signature remains valid.

The To: header _is_ part of the signed material so will list the original recipient not the victim — but the attacker sets the recipient name/address to something misleading like “Order Received” to obscure this, and sets the store name to some long text that will be misleading when templated into the PayPal invoice request mail text.

PayPal have long had a problem with failing to make untrusted supplied text clear in their communications, but this is an unusually convincing attack.

I don't know why they always use (compromised?) onmicrosoft subdomains in particular. In the samples I've seen they're getting an SPF softfail so it doesn't seem MS's relays are passing SPF for paypal (sendgrid's might...)

Script running on usercontent.github.com:

- is allowed to set cookies scoped to *.github.com, interfering with cookie mechanisms on the parent domain and its other subdomains, potentially resulting in session fixation attacks

- will receive cookies scoped to *.github.com. In IE, cookies set from a site with address "github.com" will by default be scoped to *.github.com, resulting in session-stealing attacks. (Which is why it's traditionally a good idea to prefer keeping 'www.' as the canonical address from which apps run, if there might be any other subdomains at any point.)

So if you've any chance of giving an attacker scripting access into that origin, best it not be a subdomain of anything you care about.

Yeah it's a thin layer over MSI tables, so if you don't already know how Windows Installer works then it's not at all clear how to do many seemingly-basic installer tasks. And few people really know how Windows Installer works because that is itself obscure, poorly designed and documented.

But a thin layer over MSI is actually what you want; the commercial tools that preceded WiX and tried to abstract away what Windows Installer was actually doing were much worse. Because Windows Installer is such a mess of counterintuitive design and bugs that you are going to need to debug it.

WiX is to be saluted for greatly reducing the level of misery involved in making installers for Windows. But the level of misery is still very high indeed.

Ugh, a friend bought some similar device due to a misleading description of what the HD was. He'd tried to change the partitioning without knowing it was there; turns out if you had anything but a single Windows partition (with custom drivers injected in the right undocumented way at install-time) you ended up with a sans-optane uncached 5400rpm HDD, which even at that time was completely unfeasible as a system disc.

Absolutely horrible product. And not even cheap before having to turf it out in favour of a proper SSD.

Yeah Win32_Product is a disaster, even by WMI standards.

The proper way to enumerate the Windows Installer database should be MsiEnumProductsEx. Except. If someone has monkeyed with a product key name in the registry such that it's longer than normal(...), MsiEnumProductsEx spits ERROR_MORE_DATA for that product and all subsequent dwIndex values (so if you're waiting for ERROR_NO_MORE_ITEMS you'll have a fun hang).

(...which sounds like it shouldn't happen, but it turns out there are a bunch of users following forum post advice to hide a product by renaming it with a _Disabled suffix. oh dear)

So in reality you'll probably have to access the undocumented registry backend for the Windows Installer database, in HKLM\Software\Classes\Installer\Products, converting the weird backwards-struct form of the UUID in each key name to the real ProductCode.

Of course not all software uses MSI packages or can be found in the Windows Installer database. You can indeed go to the Add/Remove Programs database in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstaller, except that the data there is super low quality. You'll have bogus products missing name and/or version, nonsense entries for things no longer present, inconsistently named products between versions, and products with different names on different locales. Which makes it quite difficult to do anything with this data.

There isn't really a single source of truth for "what products are installed" under Windows and all options for reporting what's installed are pretty bad.

The Netscape of the 90s wasn't interested in making features ‘safe’. They were about throwing out features as quickly as possible to see what would stick.

The simplest possible syntax is to make named elements available globally, and if that clashes with future additions to the DOM API then well that's a problem for some future idiots to worry about.

as a strategy it worked pretty well, unfortunately

> So 20.04 will likely be my last ubuntu-flavored distro.

I'm hanging on with 22.04 using the mozillateam PPA to get a proper deb firefox and it's working fine for now. If they stop exposing that option I'll be off too.

I'm not religiously against snap but the experience of trying to use it has been pretty awful so far. First the process of switching firefox to a snap during release-upgrade hung and broke the upgrade. Then after clearing up the mess and uninstall/reinstalling, attempting to run Firefox silently did nothing.

The prevalent milk in Germany (originally promoted as “hält länger frisch” et al) is Extended Shelf Life (ESL). It's treated hotter than traditional (HTST) pasteurisation of the type dominant in the UK, but not as brutally treated as traditional UHT.

Personally I'm not a fan of ESL and would seek out the remaining HTST brands, but it's eminently preferable to UHT.

Flexible is a double-edged sword. `querySelector` is bringing in the added complexity of selector syntax, which is more stuff to think about that isn't relevant to what you're trying to do.

For example now you have to worry about whether there are any characters in the ID that need escaping in a selector (eg `.`), something that may not be easy to verify when formatting an ID out of variables.

So I'd suggest preferring getElementById for its directness, rather than for micro-optimisation reasons.

(In principle the same should be true for getElementsByClassName, but the live NodeLists returned by that method are a trap for the unwary, so neither option is ideal.)

The reason I run desktop Linux isn't because it has a particular feature I want. It's to get away from all the Windows features I don't want — bloat, bundleware, ads, telemetry, forced AV, forced cloud features, forced reboots...

So WSL doesn't help me, really.