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”.
355 karma · joined March 20, 2015
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”.
Used to be every VPS refresh cycle you'd get more server for less money. This is miserable
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...)
- 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.
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.
Absolutely horrible product. And not even cheap before having to turf it out in favour of a proper SSD.
It's typically easier to work out a layout if you use padding in preference so you don't have to worry about them, but first you have to reset the margins the browser gives you.
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.
I use the method with `canvas.clipPath(path, stroke=False, fill=True)` on a path I've parsed manually from SVG then `canvas.linearGradient`.
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
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.
Personally I'm not a fan of ESL and would seek out the remaining HTST brands, but it's eminently preferable to UHT.
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.)
So WSL doesn't help me, really.
Instead, they kept the high nose and used the space as a trunk. After all, injuring fewer pedestrians sells no cars. Indeed, the market prefers an enormous, deliberately threatening-looking chariot that makes you feel big and virile.
Ford are behind this game in that they haven't given their truck an explicitly hostile name like “People Mulcher”.
So, sure, maybe there's a good reason to want XML-compatible syntax. But Netscape 4 users? Let's hope not!
Sure. LiveConnect was commonly used as glue to invoke and interact with applets from JS.
I wouldn't necessarily say that it enabled a virtually unlimited blah blah enterprise parp, but it had its uses. A common hack was to put some shared storage in an applet so multiple documents could use it to persist and communicate cross-document data, back before browsers could do that natively.
There was some really tedious bug in IE with the Sun VM that occasionally allowed JS events to fire concurrently whilst LiveConnect was waiting for a response from a method called on an applet, which we never quite figured out. This was one of many things that made JS+applet development unreliable and unpleasant.
> It comes down to an argument of trust - do you trust Apple is acting in your best interests
No. I mean really very obviously no.
Neither Microsoft. Nor Google. Why would I assume any company would act in my interests when they have clear incentives to increase their profits and control by acting counter to them?
It's great that the author loves to exist within the limits and restrictions imposed by Apple, but don't expect me to go along with your Stockholm Syndrome and belittle me for differing.
My mind is not app-centric. I want the shell where I'm looking at logs, the editor where I'm taking notes, the browser where I'm checking some doc. I don't care to think about which terminal application the shell is inside, select that, then find I've opened a different terminal window and have to search through the windows separately. I don't care whether the doc is loaded in Firefox or Chromium so don't ask me to choose based on that.
IMO app-centric task switching works much, much less effectively than window-centric task switching; I hate that all the major DEs have copied the same basic app-based dock design that has been failing in obvious ways since day one.
(Although Windows can at least configure grouping away, and there's the dash-to-panel extension to make GNOME tolerable again.)
I get that an app-centric view is attractive to app developers, who would love me to be engaging with their brand. And that mobile has its own reasons for putting apps in silos. Does nothing for me as a desktop user though.
There were computers dotted around the place run by enthusiastic maths, physics and design teachers, which occasionally made it into a lesson, but more commonly would be commandeered by the spoddy kids at break times, making programs to print rude words on the screen.
Our school brought in actual computing lessons a few years later, but they were "How To Do Word, You Peons" from day 1 (on the godawful slow PC-not-entirely-compatibles that somehow RM managed to trick schools into buying back then). I consider it a lucky escape I didn't have that to put me off the whole idea.
Back in the IE5 days they had similar bugs in res:// (DLL resource) pages, running in the then-highly-privileged My Computer Zone. Took years of reporting the same kind of crap before they finally deprivileged it.
New browser, new code base, new devs... all the old bugs are new again.
They've definitely crossed the line in the past.
For example around 2005 they were stealth-installing NetRatings spyware bundled with file-sharing apps.
(And similarly with comScore. It's probably best not to use these organisations as examples of good practice.)
That seems about right.
The car alarm owner is forcing an externality cost onto society; there is no incentive for an individual car alarm owner to reduce false positives so it is no surprise the products are so bad.
(Even in the true-positive case, the car alarm is extracting its value from the attention of third parties to the thievery, at no cost to the owner.)
Conclusion: every sounding of a car alarm should attract a substantial tax penalty.
(Not talking about all of Amazon, just SES - AWS for example is a different animal.)
They have an automated abuse-handling system that sends your complaint to the spammer and asks them politely to stop. This often works for small-time operation on a single IP address, and for compromised servers, but it's completely inadequate for dealing with large customers and rogue resellers spamming over large netblocks, and against darker-coloured-hat spammers engaging in reprisals.
Replying to the automated mails can get you through to a human, but their ops are stuck on a limited script so they're not really any more use than the automated systems. They have no interest in investigating wider patterns of abuse than a single spam from a single IP.
I regret having to blacklist but it's not worth the time and frustration of trying to engage with them.