I find that hard to believe. Every creative professional that I know shares this sentiment. That’s several graphic designers at big tech companies, one person in print media, and one visual effects artist in the film industry. And once you include many of their professional colleagues that becomes a decent sample size.

Graphic design is a completely different kettle of fish. Comparing it to academic paper writing is disingenuous.

The thread is about not knowing anyone at all who thinks AI is plagiarizing.

Yes, plagiarising text based content. No one in this thread meant graphics.

If you mean true 4x4, there are none. Sprinter went AWD a few years ago.

But I believe most vans on the market have an AWD option. Ford Transit and Volkswagen IDBuzz both offer AWD. Toyota’s Sienna is (only?) AWD with a silly lifted trim for the off-roading soccer mom market. Chrysler’s van is AWD.

That leaves the ProMaster as the only two wheeler I’m certain about. Mazda and Kia also have vans, unsure about their drivetrain options. Did I leave anyone out?

This is only applies to App Store published .app bundles. Does not apply to binaries you compile yourself or non-app binaries like cli tools

Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?

No, sorry. That's not what I'm saying.

If you compile hello-world.c into a binary then it will have a placeholder (ad-hoc) signature that was signed by an "empty" key that can never expire. The Go compiler isn't doing anything special. By default all binaries are signed this way unless they were compiled with the explicit intention of App Store distribution.

And the above does not apply to .app bundles.

Yes of course apps will continue to operate after the signing cert expires, and this is documented by Apple in several places. It would be absolutely insane if apps stopped working, because all Developer ID signing certs expire after 5 years.

The valid dates for code signing certificates apply, naturally, to signing. You can't sign an app anymore with an expired certificate, but if an old app was signed with a cert that was valid at the time of signing, then the app will continue functioning forever.

This issue was just a dumb screwup by Logitech. If apps stopped functioning when the signing cert expired, you'd see Mac apps dying all the time.

This only applies to distribution certificate signed apps, not true in the general sense.

> not true in the general sense.

What does that even mean? What exactly are you saying is not true?

It's not at all helpful or informative to keep saying "does not apply," as if that meant anything by itself.

OP said something confusing about the Go compiler, so I was only added clarification for that one statement.

You walked by half listening to a conversation, stuck your head in the room and said something tangentially related but more confusing.

There are distribution and development certificates that can all be used for signing a binary. Different rules for each, and there's also auto-signed (com.apple.provenance). It's all documented on Apple's website if you want to read more about it. But I suspect you already know this and are just trying to pick a fight.

This is a gross mischaracterization of the thread. I replied to spondyl, not to you. Then you replied to me, so if anyone was "trying to pick a fight" involving me, it was you.

The crucial point is this: there are no builds that expire on macOS. Developer ID signed builds do not expire. Ad hoc signed builds do not expire. When the Developer ID code signing certificate expires, it cannot be used to sign new builds, but the old builds last forever. Build expiration is not a thing in any case.

So when spondryl asked, "Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?" and you responded "No, sorry. That's not what I'm saying." that was actually confusing, not what I said.

The only reason the Logitech software died is that Logitech itself was doing some custom and badly designed validation above and beyond anything that macOS itself does. Your mention of App Store apps and CLI tools was itself a tangent and completely irrelevant to the issue.

So what happens when I codesign with the the --expires flag?

Do you? Does anyone? I see that the flag exists, but I've never seen anyone use it. That would seem a bit insane.

Yeah, it’s used for dog fooding or private distribution. It’s also used on iOS side-loading and test flight builds.

If you’re including these assets as UI elements, they would be rasterized anyway and copied to a GPU bound buffer for the frame blit. Doing so at compile time increases runtime performance.

You can of course override this behavior and redraw your vector every 8.3 ms if you want, but I promise you that this is not faster. For sparse pyramid-tiled vector images like Google/Apple maps, this is a two step process using the latter method followed by the former.

> Want to delete a song?

Swipe left on the song to reveal the delete button.

> Want to scroll to the middle of a song?

Does dragging the scrubber not work for you? Can also be dragged in the control center.

Would love to know what happens in perf review for MSFT employees that flip this switch.

Nothing. This isn't something that is even tracked. AI usage is obviously encouraged but HR has far better things to do than go gather this kind of data.

Internally, depending on what product is being worked on teams will have different development flows and different usage points of AI. For things like VSCode, teams have freedom on how they use it completely.

This is not true company wide. I’ve personally been reprimanded for low GitHub copilot usage by my orgs leadership, not HR.

Probably using the compiler flags directly? I’ve never heard of a Bazel dependency in Swift, and precompiled c++ was a huge pain in SwiftPM a year ago. I work on ObjC++/Swift/Metal as my day job and just use a Makefile because it’s easier

Heavy metals are a big problem, especially from cheap brass fittings common in outdoor water hoses. Indoor plumbing, by contrast, uses copper and/or plex tubing and so there’s near zero risk of metal poisoning (caveat on cheap plex fittings- don’t do that.)

Disagree. This is the default in Objective-C & Swift, and it’s great. You have to explicitly annotate when discards are allowed. It’s probably my all time favorite compiler warning in terms of accidental-bugs-caught-early, because asking the deeper question about why a function returns useless noise invites deep introspection.

Try to use an LLM to a solve a novel problem or within a domain that can’t easily be googled.

It will just spew over-confident sycophantic vomit. There is no attempt to reason. It’s all worthless nonsense.

It’s a fancy regurgitation machine and that will go completely off the rails when it steps outside of it’s training area. That’s it.

I’ve seen it solve a complex domain specific problem and build a basis of code in 10 minutes what took a year for a human to do. And it did it better.

I’ve also seen it fuck up in the same way you describe. So do I weigh and balance these two pieces of contrasting evidence to form a logical conclusion? Or do I pick and choose one of pieces of evidence that is convenient to my world view? What should I do? Actually why don’t you tell me what you ended up doing?