I don't think it's wise to use it for anything. Even when chatting with an LLM you would have to check everything yourself which nobody would truly do. The generated code can't be really trusted (and nobody will review everything, quite the opposite). It can also have copyright issues.
People are allergic to articles and documentation generated/processed by LLM.
You're switching from an active role to a passive one, meaning your skill will suffer over the time. There is a huge difference between doing the things and thinking you know what it's doing. It's harder to review bad generated code because how polished it looks, compared to code made by humans where the difference is much more obvious.
Code assistants seem to work great when dealing with boilerplate, but wouldn't be better to get rid of the need for the boilerplate in the first place?
Thanks, it might be useful for macOS support of non-native widgets in my GUI library. I did some parsing but got stuck at some point.
Seems a better choice to just parse the files than using private APIs as I couldn't see much of the documentation for them (or rather reversed APIs in various projects) + image handling is weirdly complicated in macOS generally so I want to avoid that.
Currently I've experimented by just recreating the graphics from scratch using vector rendering but it's quite cumbersome.
Other libraries, such as Qt, try to draw the native widgets into offscreen image but it's extremely hacky way prone to GUI breaking with any OS update. Java has their own Apple blessed way, but seems quite limited to me and don't want to depend on that either.
Interestingly I've never used Visual Studio on Windows (only for a brief time for ARM based PDAs where I could experience the infamous MFC which was okay to me despite the hate).
I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.
Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.
Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.
The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.
Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.
I think the issues you're referring to are related to C++ ABI which is inherently incompatible between different compilers (and sometimes versions). This can be sometimes issue for plugins, though sane programs always use C wrappers.
I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.
But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad.
A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs.
I don't understand how open source projects can insist on requiring a proprietary compiler.
I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000.
Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
Clearing of the secrets is a separate issue from memory allocation mechanism. It must be done all the way from the encryption layer to the program to avoid the leaks.
This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).
On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).
You can do it with HW accelerated emulation like Apple did with M1 CPUs. They implemented x86 compatible behavior in HW so the emulation has very good performance.
Another approach was Transmeta where the target ISA was microcoded, therefore done in "software".
In my case, as a developer of a programming language that can compile to all supported platforms from any platform the signing (and notarization) is simply incompatible with the process.
Not only is such signing all about control (the Epic case is a great example of misuse and a reminder that anyone can be blocked by Apple) it is also anti-competitive to other programming languages.
I treat each platform as open only when it allows running unsigned binaries in a reasonable way (or self-signed, though that already has some baggage of needing to maintain the key). When it doesn't I simply don't support such platform.
Some closed platforms (iOS and Android[1]) can be still supported pretty well using PWAs because the apps are fullscreen and self-contained unlike the desktop.
[1] depending on if Google will provide a reasonable way to run self-signed apps, but the trust that it will remain open in the future is already severely damaged
I would say quite a lot of users because even the previous simple method of right clicking wasn't that known even by power users. Lot of them just selected "allow applications from anyone" in the settings (most likely just temporarily).
In one application I also offered an alternative by using a web app in case they were not comfortable with any of the option.
Also it's presented in a .dmg file where you have two icons, the app and the "How to install". I would say that's quite inviting for investigation :)
Try "killall -STOP photoanalysisd", this will pause the process instead of killing it (which would result in restarting it by launchd). You can unpause it by using "-CONT".
We've had a small amount (just 3) with plenty of space and it was fun to observe them, all sort of interesting behaviors.
My favorite thing is them cooperating against a common enemy (a dog that was eating their food sometimes, which we've tried to mitigate but not being much successful).
Then once they had a discussion in the opposite corner about the problem and launched a stealth attack, covering themselves behind the trees while approaching the dog without the dog knowing it. Then once close enough they attacked from behind, the dog squeaked, more from the surprise than pain and since then the dog never touched their food again and avoided them.
Chickens are very intelligent, it just happens that most people ever see chickens in overcrowded small spaces where they behave idiotically. So would you if you would be in the same situation.
That exists and it's called web apps. For native apps you need the exact opposite, access to everything otherwise it can't do the useful integrations and provide the best experience for the user, which is the point of native apps.
You have to trust native apps, as it always was the case. You can't just install random apps. You can delegate the trust to a curated lists of apps that you trust.
Or you can just use the web apps, but then you have to trust them too (so they don't misuse information about you or your data for example). But then it can't integrate with anything and many features are simply not available.
As for your example, a photo editor could need a network connection when it contains collaborative features. Or an auto-update system. Or downloading of assets on demand. Or cloud AI feature. Or list of add-ons to install. Or for license checks. Or online help/docs. Or whatever.
Unfortunatelly DMA is the reason Google is doing this. It allowed Apple to require notarization for "security". Google is just copying the same approach as it's now clear what the requirements by the governments are.
Before it was unclear so it was better to allow installation of apps without any verification to appear as more open.
Remember any regulation/law has unintended consequences. At one point Apple decided that PWAs would no longer be supported in EU so they don't have to provide equal capabilities to implement them in alternative web browsers, fortunatelly they changed their mind by obtaining an exception. PWAs is the only alternative choice for making "proper" apps on iOS (no hacky sideloading methods).
I think overally DMA is more a loss than a win (good on paper, terrible in practice). It codified worse things. The EU app stores are still fully controlled by Apple (harder to install, they can just decline or drag notarization of any apps or revoke your license to dev tools, you need to still pay them, etc.).
For various apps the EU market is too small (esp. for things that need to be global) to invest into the development so while you can for example theoretically develop a real alternative web browser to Safari/WebKit (forbidden by App Store rules) nobody is willing to do it.
It doesn't matter how hard it was to produce, it is still a derived work. Binary vs source code doesn't matter for copyright, it's just a different form of the same work.
It matters with patents where you can have patented stuff in the source code without a problem as long as it's not compiled into the binary. Users who are unaffected by the patents or have a license can compile it in.
Fair use is used during a trial to determine if your use case is an OK exception despite being it a copyright infringment. It's not guaranteed to go into your favor (there are a lot of nuances case by case despite of precedents) and you need to be sued to exercise it.
What you can do is to mimic the behavior and look from scratch, then it would be a separate work. The internal structure would be quite different too. Even the same logic would most likely be coded differently. And the look wouldn't be pixel-perfect just very similar looking.
> When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful.
I do this all the time (even at night without lights) with no problem at all. The key is to have properly set brightness/contrast on your monitor and gamma correction.
It can achieved by setting the brightness to a minimum (and use the contrast setting to go even lower, or even combine it with GPU settings in addition to monitor settings). It is also important to set a proper gamma correction so that darker/lighter levels don't have too big contrast.
The gamma correction needed can be measured by comparing the apparent thickness of antialiased text in black-on-white vs white-on-black color combinations that you toggle between. Once it is the same you get the right value. For example it's 1.3 on my LCD.
MacOS can run unsigned apps with GateKeeper active, no need to disable it. Attempt to run the app, then go into security settings, scroll down and click on "Open anyway". And before Sequoia a right click -> Open was sufficient.
On M1+ devices it might also need "ad-hoc signing" if the developer hasn't done it (not required for Intel binaries). This is not a true signing, it just inserts a cryptographic checksum into the binary, no actual signing is involved.
People are allergic to articles and documentation generated/processed by LLM.
You're switching from an active role to a passive one, meaning your skill will suffer over the time. There is a huge difference between doing the things and thinking you know what it's doing. It's harder to review bad generated code because how polished it looks, compared to code made by humans where the difference is much more obvious.
Code assistants seem to work great when dealing with boilerplate, but wouldn't be better to get rid of the need for the boilerplate in the first place?