skrrtww
I'm not sure this is true anymore.
"Cloudflare successfully deployed multiple mitigations for all its customers while the vulnerability was leaked before the official release date and we observed attack traffic targeting our customers."
If that's not an in-the-wild exploit, it literally couldn't have been further away than one or two more iterations.
It has headers like AI blogposts, and features a lot of parallel structure like AI blogposts ("there's no <blank>. you <blank>"), but if you actually read it none of it reads like slop. To me anyway.
I have a local collection of over 30,000 mp3s, about half of which is not 'matched', and a sizable chunk of which is not available on streaming anywhere, and I have it on all my devices seamlessly, included with the price of an Apple Music subscription. (which I also use for convenience for listening to things I don't have my own copy of yet).
Pikmin.
I'd say the correct approach is to include all your top level files (i.e. CMakeLists.txt, .gitignore, etc.) but also your top-level *directories*, i.e. `/renderer`, `/UI`, `/tools`, whatever.
Then, crucially, your build system must also prohibit in-source builds and require a dedicated build directory.
This way, it's presumed that everything in your source tree is pristine and correct, and can host a variety of file types depending on your needs (realistically, source trees can contain lots of things; data, json, images, text, etc.) while you also shouldn't have to worry about polluting it accidentally.
But yeah, essentially the whole port is done with binary patches to the original executable.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
I have no doubt GitLab has too many employees and can benefit from being a more focused company, but it's tiring reading these layoff posts so chock full of buzzwords. I guess they're desperately hoping if they prognosticate about AI enough it will placate the investors.
Don't install invasive "helpers" or login items in weird locations; don't ask for huge amounts of system permissions without an appropriate introductory flow for your application, explaining what it needs to do before trying to install or get permission for something.
Bundle your dependencies appropriately; don't go fetch weird stuff post-install, the application should be designed so that everything is already there in the bundle.
Put application data in the idiomatic locations; ~/Library/Application Support, ~/Library/Preferences, etc.
Carefully consider what keyboard shortcuts your application uses; if you use the Escape key for something, or modifier keys, make sure it does something that makes sense on the platform and doesn't conflict with other shortcuts.
Don't bundle Chromium.
Generally: Respect the user as much as possible. Things should "just work." If there's a situation where it doesn't or something feels "odd", you should do whatever you reasonably can to fix that.
And yes, if we make OSS just about hosting the code, things are much simpler. If you're a piece of desktop software though, and you have users, they'll typically (and reasonably) want auditable signed binaries on all the platforms you support, which requires multiplatform CI.
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
Or, if you were slightly older, you might call them UMS, as they were in Starcraft. Short for "Use Map Settings", indicating that the game logic should come from the scripts and triggers in the map file rather than the built-in logic for ladder games.
It's disgusting that this has become a casual attitude and admission by the tech worker class. No one should be getting this free pass.
"I am actively harming children and society with my livelihood (except my own, because I am so smart). Here I am proudly and smugly stating this in a news article."
I'm no expert, but Google having designed AV1, I can certainly imagine a world where the codec infringes upon HEVC just enough that the lawsuit fees would come out in the wash.
The dependency list is also...something: https://github.com/J-x-Z/cocoa-way/tree/main/vendor
People in the U.S. are simply constructed differently, and as a result I think are unfortunately immune to a lot of the subtle forces that generally help to improve safety in other civilized societies.
Why can't we adjust the order of photos in a Shared Photos album?
I can't help but feel that Swift will ultimately be the "slow and steady wins the race" safe language of the future. Swift steadily working "first" on both tooling and cohabitability with existing ecosystems is a huge boon for adoption. It understands what an ABI is! If I were doing a greenfield cross platform application I think Swift would be the first thing I reach for now.
The qualms I have with Swift are mostly some of the more recent complex language features that can make Swift code much harder to understand and read, as well as the brainpower required to use Swift concurrency. That and some performance concerns, though many of those seem like they may be solvable with optimizations in LLVM.