drysart

All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name".

In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is really doing you a favor by hiding away the private backing field more obscurely.

I've never liked the argument that there's some imaginary line between the acceptibility of AI as a tool for creating art and Photoshop/Krita/Procreate/etc as a tool for creating art.

Rubbing a brush on a canvas was good enough for the renaissance masters, why are we collectively okay with modern "artists" using "virtual brushes" and trivializations of the expressive experience like "undo" when it's not "real art" because they're leaning so heavily on the uncaring unthinking machine and the convenience in creation it offers rather than suffering through the human limitations that the old masters did? Are photographers not artists too then, because they're not actually creating, just instead capturing a view of what's already there?

The usual response to this is some trite response about how AI is 'different' because you're 'just' throwing prompts at it and its completely creating the output itself -- as if it's inconceivable that there might be someone who doesn't just shovel out raw outputs from an AI and call it 'art' and is instead actually using it in a contributatory role on a larger composition that they, themselves, as a human, are driving and making artistic decisions on.

E33 is a perfect example here. Is the artistic merit of the overall work lessened by it having used AI in part of its creation? Does anyone really, truly believe that they abdicated their vision on the overall work to machines?

Just because someone can drag and drop to draw a circle in an image editing app instead of using their own talent and ability to freehand it instead doesn't mean what they then go on to do with that circle isn't artistic.

Falling behind on the browser core makes users leave Firefox because the one non-negotiable requirement users have is that the browser works on the websites they need it to work on. Literally nothing else Mozilla tries to do to diversify their revenue streams will matter if the browser they're trying to build it on top of is not sound and functional.

If they weren't slipping on the core browser as much as they have been, there wouldn't be nearly as many shouts as there are today when they instead spend resources on chasing the latest fad.

In many ways, yes. With guns specifically, the Supreme Court (in opinions authored by Justices Alito and Kavanaugh, believe it or not) has set a precedent that there are some government-controlled "sensitive places" within which it is reasonable and prudent to place restrictions on firearms. Legislative assemblies, courthouses, government buildings, etc.

So not even the most conservative justices buy into the idea that Americans have a right to bear arms everywhere.

There wasn't much of a window where we had the ability to reliably dynamically update webpages without a way of getting data to do it. IE4 was the first browser that had a modern dynamic DOM with CSS support -- but it was all very rudimentary. IE5 came out a little more than a year later came with MSXML 2.0 which had the Microsoft.XMLHTTP ActiveX object that could be used within the browser; so it was really only like 14 months where we had DHTML without the ability to do XML HTTP requests.

And even then, you couldn't really make use of it unless you were in the enviable position of not having to maintain Netscape compatibility, because Netscape basically had no ability to alter a page after it was loaded outside of extremely specific exceptions like being able to replace one image with another image of exactly the same size. And through the weird and broken 'layers' concept they came up with to try to rush out a response to IE's iframes.

I remember discovering Microsoft.XMLHTTP in early 1999; probably within a month of IE5 coming out, and it really was like suddenly gaining a superpower. People (rightfully) gave Internet Explorer a whole lot of crap for getting to IE6 and then stagnating for years; but so much of what we consider to be the modern web today can trace its lineage directly to the ideas Microsoft brought to the browser in IE4 and IE5. They basically reinvented what the browser could be.

What? No they didn't. They extended the deprecation timeline for Windows 2019 agents from the original EOL date of 30 June 2025 to 31 December 2025; with a well-published brownout period from 2 December to 9 December in addition to the original brownout period from 3 June to 24 June.

The initial banners and warning emails about it went out well ahead of the original EOL timeline; and again as the extended EOL drew close.

If you were caught off guard by the brownout period, it's your devops team that's to blame, not Microsoft; and Microsoft was absolutely right to blame you for not migrating sooner. They gave you an extra 6 months to do it because you should have had all this done back in the first half of the year.

(If you want to blame Microsoft for anything here, blame them for not having a comprehensive tool to identify all your windows-2019 pipelines and instead just relying on "just go look at the latest pipeline runs page and hope everything's run recently enough to be on that".)

CSS isn't the security issue here. IFrames are the security issue; and have been since the first day they were added to a browser.

"Fail open" state would have been improper here, as the system being impacted was a security-critical system: firewall rules.

It is absolutely the wrong approach to "fail open" when you can't run security-critical operations.

Then even in the worst case scenario, they were addressing this issue two days after it was publicly disclosed. So this wasn't a "rush to fix the zero day ASAP" scenario, which makes it harder to justify ignoring errors that started occuring in a small scale rollout.

> The only thing I'm not sure about is why they decided to reopen it.

It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.

Notarization doesn't involve any sort of editorial control. It's just a virus scanner that's run up front and then stapling an attestation to your application that it passed the scan. It does not involve looking at the content of your app and making any value judgements about it; it's purely an automated static analysis system checking your application for known malicious code.

Azure Trusted Signing is a crapshoot. If you can get running, it's easy and fast and great. But if you run into any problems at all during the setup process (and you very well might since their onboarding process is held together with duct tape and twine), you're basically left for dead and unless you're on an enterprise support plan, you're not going to get any help from them at all.

The length of time notarization takes depends primarily upon how large and complicated your app is, and how different is from previous versions of the same application you've previously notarized. The system seems to recognize large blocks of code that it's already analyzed and cleared and doesn't need to re-analyze. How much your binary churns between builds can greatly influence how fast your subsequent notarizations are.

A brand new developer account submitting a brand new application for notarization for the first time can expect the process might take a few days; and it's widely believed that first time notarizations require human confirmation because they do definitely take longer if submitted on a weekend or on a holiday. This is true even for extremely small, trivial applications. (Though I can tell you from personal experience that whatever human confirmation they're doing isn't very deep, because I've had first time notarizations on brand new developer accounts get approved even when notarizing a broken binary that doesn't actually launch.)

And of course sometimes their servers just go to shit and notarizations across the board all take significantly longer than normal, and it's not your fault at all. Apple's developer tooling support is kinda garbage.

Notarization doesn't blanket block all access to private APIs; but the notarization process may look for and block certain known accesses in certain cases. This is because notarization is not intended to be an Apple policy enforcement mechanism. It's intended to block malicious software.

So in other words, using private APIs in and of itself isn't an issue. Neither is it an issue if your application is one that serves up adult content, or is an alternate App Store, or anything else that Apple might reject from its own App Store for policy reasons. It's basically doing what you might expect a virus scanner to do.

There's a significant difference between a site being useless because it just doesn't have the breadth yet to cover the topic you're looking for (as in early Wikipedia); versus a site being useless by not actually having facts about the topic you're looking for, yet spouting out authoritative-looking nonsense anyway.

PROD isn't capitalized because it's an initialism. It's capitalized because the machine is screaming at you that this is production, be careful. ;)

That's a truism in general. If you're liberal in what you accept, then the allowances you make effectively become part of your protocol specification; and if you hope for interoperability, then everyone has to be follow the same protocol specification which now has to include all of those unofficial allowances you (and other implementors) have paved the road to hell with. If that's not the case, then you don't really have compatible services, you just have services that coincidentally happen to work the same way sometimes, and fail other times in possibly spectacular ways.

I have always been a proponent for the exact opposite of Postel's law: If it's important for a service to be accommodating in what it accepts, then those accommodations should be explicit in the written spec. Services MUST NOT be liberal in what they accept; they should start from the position of accepting nothing at all, and then only begrudgingly accept inputs the spec tells them they have to, and never more than that.

HTML eventually found its way there after wandering blindly in the wilderness for a decade and dragging all of us behind it kicking and screaming the entire time; but at least it got there in the end.

Which do you consider as being under better control: a technology that we exhaustively create reports on even in the face of incidents like this where the only real chance of harm was that the guy couldn't swim and might have drowned; or a technology where we don't report on anything at all whatsoever and thus have no idea what's actually going on?

Reports don't mean danger, and they don't mean lack of control. Reports are information.

I guarantee you there's 'a measurable amount of radiation' in your hair right now. Unless you're bald, I suppose.

I can guarantee you there will be a proper investigation and steps taken to avoid this in the future. The non-emergency classification here applies solely to the notification that the contamination was transported off-site. Not to the fact that the incident occurred. Every accidental incident that occurs within the controlled area of a nuclear facility is investigated and evaluated for necessary policy changes.

And the reason the contamination transport off-site was classified as non-emergency was because even though the amount of radiation detected on the guy is less than he'd have gotten from flying in an airplane; nuclear safety standards are so unbelievably rigorous and strict that even that small of an incident needs to be reported; even if it presents absolutely no danger to anyone anywhere (not even the guy that was contaminated) and hence is classified as a non-emergency notification.

So you'd be okay then with your engineers taking home copies of company projects so they'll be able to show their work to future employers?

It's worth noting that Article V, Section 5 doesn't prohibit itself from being amended away. So you just need the constitutional convention to refer two new amendments: the first one stripping the restriction itself, and the second one to do what the restriction prohibited being done.

On Windows they are significantly different; it's not just a matter of sharing a page of memory (though you certainly can do that if you want), because on Windows basically every kernel-provided cross-process object must be a fully securable kernel object that you can attach ACLs to, and the kernel has to be in the middle of operations to enforce those access controls (in order to conform to the old DoD TCSEC orange book requirements for mandatory access security).

Oh they know about multithreading. The problem is Microsoft's commitment to backward compatibility -- the Explorer COM interfaces that third-parties can build shell extensions on are all old enough to be from an era when 99% of users never used Explorer to browse anything on a network so their being synchronous didn't matter, and also from an era when asynchronicity wasn't common and was poorly supported by compilers and when PCs had low enough specs that it didn't make sense to spend the resources to provide asynchronous shell APIs.

And because Explorer continues to support those interfaces today, that means if anything integrates with the shell via those interfaces, Explorer ends up with lots of operations that are forced into being synchronous. You can avoid some of it by being extremely selective about what sorts of shell extensions you let be installed.

That's what I got from reading the article; the takeaway is that all its doing to solve the types of problems V8 has is by shifting the complications beneath another layer. All the problems and challenges and potential for mistakes still exist, they're just within GraalVM now.

Which is not without real benefit, of course; it's a lot easier to build and secure one genericized VM runtime toolkit than it is to rebuild everything from scratch for every single language runtime like V8 that might need to exist. It's far better to competently solve the difficult problem once than to try to competently solve it over and over and over.

Yeah I'll definitely chalk this up to my not having more than a very very passing idea of the API surface of your library based on a quick read over just the blog post.

On a little less trivial skim over it looks like the intention here isn't to map property-level subsets returned data (e.g., only getting the `FirstName` and `LastName` properties of a larger object); as much as it is to do joins and it's not data entities being provided to the mapping function but RpcPromises so individual property values aren't even available anyway.

So I guess I might argue that map() isn't a good name for the function because it immediately made me think it's for doing a mapping transformation and not for basically just specifying a join (since you can't really transform the data) since that's what map() can do everywhere else in Javascript. But for all I know that's more clear when you're actually using the library, so take what I think with a heaping grain of salt. ;)

There are inherent limitations with the "execute it once and see what happens" approach; namely that any conditional logic that might be in the mapping function is going to silently get ignored. For example, `db.people.map(p => p.IsPerson ? (p.FirstName + ' ' + p.LastName) : p.EntityName)` would either be seen as reading `(IsPerson, FirstName, LastName)` or `(p.IsPerson, p.EntityName)` depending on the specific behavior of the placeholder value ... and neither of those sets is fully correct.

I wonder why they don't just do `.toString()` on the mapping function and then parse the resulting Javascript into an AST and figure out property accesses from that. At the very least, that'd allow the code to properly throw an error in the event the callback contains any forbidden or unsupported constructs.

Nineteen eighty twelve.

Browser are much better, but directly manipulating the DOM is still extremely slow compared to manipulating Javascript objects; and perhaps even more now than a decade ago it's fraught with performance traps that differ from browser to browser and even between successive versions of the same browser.

That hasn't changed in the past decade, and it's not going to change in the next decade either because the DOM has to make certain API guarantees that simply can't be optimized away. It'd take a significant change in how the DOM API works to even get close to achieve performance parity with a virtual DOM. (Like being able to tell the DOM to completely defer layout until you tell it that it's okay to continue.)

It's simply much more reliably performant to have all your DOM touching be done in a single batch during a virtual DOM diff resolution than it is to touch it and update it piecemeal as your application's components all mutate their own elements on their own schedules.

That's why it's the developer's responsibility to do it. Because the user won't.