It's possible their communication happened before that, and it just took a while to write and post OP post. 16 days is not that long or delayed. I haven't checked the dates of the commits in question though.
Unfortunately, I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.
After opening with a need to be open-minded, this seems quite close-minded. Sure, it's their article. Still, I was hoping for a more neutral and substantiated advocating and description.
I certainly didn't feel like it answered [all] my questions and concerns in multiple sections.
I somewhat like the idea of being able to submit issues via email directly. It does cost on spam classification and prevention, though. An account is easily classifiable as an additional confidence metric. E-Mail, not so much, or with significantly more complexity in relating data and ensuring continuity of source.
An account is a very obvious way to build a reputation. If you see a new GitHub account submitting a PR vs someone having contributed for a long time and significant projects in the same technology, you may approach the reviews quite differently. It is, at least, a very useful and simple way to classify authors and patch submitters.
What does SourceHut provide in this aspect? To what degree does it verify incoming emails authenticity, sender source, and continuity of source hoster? To what degree does it relate information by email address? I assume it does not.
Supporting soft subs is a complex topic though. Three formats, font embedding, positioning and animations. It's a ton of effort, and anything less than "full featureset support" will mean they don't render how you design them in your full-set editor and local media play. And there will be differences and bugs, at least for a while. I suspect font rendering with various fonts in a media render context will have it's own set of issues.
I also think it'd be nice, but I can totally see how it may not make sense technically (complexity with its burdens vs need) or economically.
Browsers are already absurdly complex though so… maybe? :P
RE: phabricator…I don’t know what that service is or is for, so I can’t comment if there’s any proof therein.
The how to submit a patch section documents that that's where they accept patches. And they do their reviews and change iterations there. By necessity, that also means hosting/having the repos.
That's confusing to me.
They only accept patches on Phabricator, have the sources there, but suggest using GitHub, but afterwards Phabricator to submit the changes?
I can only imagine it's to lower barrier to entry because GitHub is more well known. But this just seems like a confusing mess to me, without clear wording of intentions and separation of concerns [in their docs, not your post or comment here].
These changes will apply to operations like cloning repositories over HTTPS, anonymously interacting with our REST APIs, and downloading files from raw.githubusercontent.com.
Lenard Flören, a Germany-based art director at an advertising agency, said he quickly realized that trying to create his dream fitness app with one lengthy prompt would lead to a plethora of bugs that “neither ChatGPT nor my clueless self had any chance of solving.”
If everyone can create programs, and everyone fails, maybe it'll bring increased appreciation to development and good development and products? One could hope. I guess the worst offenders won't even try themselves either way. The services are not that accessible.
You tell the AI the "vibe" of what you want the result to have, and it does that - but of course it's not necessarily that simple. You may end up doing prompt engineering, multiple iterations, trial and error, etc
When we tried a product at my workplace generating a web app prototype in react seemed viable and reasonable, possibly good for prototyping and demonstrating. We also tried a Blazor app, and it utterly failed. I suspect because of less training on it and much more complex mixture of technologies.
, but it works reliably well. It takes a second or two to be redirected to the site you’re visiting.
Do you mean it works reliably well in letting users through, or in blocking AI?
Do you have sources or more information about the effectiveness of it in blocking AI? What else it blocks as collateral damage would also be interesting.
/edit: Clicking through some links (specifically canine.tools) I have to say - it may also be effective in annoying me personally, and eventually exiting those websites. Similar to consent dialogs you could go into settings for and save with opt-outs. But it's a barrier and user-opposing functionality.
I certainly don't see it as a simply or only good and effective thing.
It doesn't open with a summary or overview but dives right in to exploration, but I think the point comes across:
The copy and paste key codes, which have no physical keys anymore, are - to a degree - supported in software. Their claim is that those key codes are the tool for universal copy and paste, and then it's the input interpretations job (key and combination mapping) to offer bindings to those key codes.
GTK added support the copy and paste keyboards in January 2025. QT also added support for copy and paste key codes the same month. I'm not sure of the first released version of the GTK toolkit that will contain the fix. For QT, it will be QT 6.10, scheduled for release in September 2025. Together, this will cover many apps built for Gnome and KDE as well as others that use the same toolkits.
… followed by some more "current state of support for those key codes".
Unfortunately, that poisons not only the AI.