PSA: The PSF has become aware of a website advertising a "PyConf2026" event in San Francisco. This event appears to be a fake, and we advise community members to use caution.
We're also following steps as recommended by our trademark lawyer, and we have filed a report with the ticket platform.
NGL, I'm kind of glad some game studios are still out there making their own engines. I don't actually believe that every game should be written in Unreal or Unity.
Every time I play an Unreal game, I can tell it's an Unreal game. Sure, they have really great systems for allowing developers to come up with all sorts of unique battle mechanics or clever world navigation mechanics like the wall jumps in Jedi: Fallen Order. But everything else about how you interact with the world in an unreal game feels scripted.
The two biggest culprets are opening chests/doors and squeezing through tight passages. I can literally tell if it's UE5, Frostbite, or something else based on nothing but the "press X" icon and how it interacts. It's good to have standard things that game devs can just drop into their games but, after a while, it makes the world feel unnaturally limited and that's never what you want.
Give me parkour! Give me a grapple hook that lets me pull myself up onto a robot bird! Give me Skyrim's "you can walk on anything but it might not end well"! Give me Zelda's "no, seriously, you can climb anything, just not in the rain". Give me a table I can knock over and all the stuff on it falls on the floor. Those are the kinds of things that make the world feel limitless and give you the illusion that you can go anywhere and do anything. And every one of those examples was from a game with a custom engine.
It's not that technical limits are bad. Every engine has them. It's just annoying to see the same technical limits in game after game after game.
And then there's lighting. There's a particular way in which UE5's dynamic lighting fucks up when you walk from light into shadow. Again, not a deal breaker in any one game. But every time I see it, I give a little sigh and go, "Right... Unreal..."
But please don't anyone take this as a UE hate post. It really isn't. It's a love letter to the people out there still building custom engines when most of the industry is yelling at them telling them it's pointless. Users notice. We really do.
why are cyber security news article always like
"HACKERS GOT ACCESS TO / BROKE THE / HAS STOLEN THE [xyz]"
and never like
"company with severe skill issues got their public shared folder of private info surprise-backupped because their IT department consists of someone hitting 'approve' buttons until something either works or stops working"
every protocol you rely on was argued about on a mailing list by people who will never be thanked
holy f*ck, Opus 5.5 JUST REPLACED MY CAT
i told it "meow for me"
and it said
"meow"
no hesistation, no food bowl required. my mind = blown.
This is just the beginning.
Hi, if you have not done the KDE desktop icon system survey yet, please do so <3 I will be writing blogpost this friday about all the data, and then I will start planning to get rid of these bugs for once and for all!
grrrrrrr.
again: AlpineBSD is *not* related to Alpine in any way. drew has built a distribution from scratch using abuild and apk (certainly nothing wrong with this part).
but the media keeps reporting as if this is literally Alpine, but BSD instead. other than using the build scripts and package format, it has basically nothing to do with Alpine.
for example @lproven in his coverage, describes it as "Combining the NetBSD kernel with the Alpine Linux userland", which it very much is not.
i really wish drew would rename his project...
RE: https://mastodon.social/@cks/117547904775599551
if you rewrite software in rust and then deviate from how that software behaves -- you haven't actually rewritten the software in rust, you've just made an incompatible clone.
(the real security problems with sudo are related to the combinatorial complexity of the config format anyway)
Harvard researchers studied 718 companies and found AI coding agents increased lines of code by 30%, but no meaningful increase in completed tasks or projects.
Meanwhile, review time rose 49%.
Generating code faster hasnβt translated into completing more work. The bottleneck has moved to code reviews.
The solution the industry is landing on is throwing more AI at the problem. AI writes the code, AI reviews the code and no one knows how it works.
Data:
- LLMs are killing the planet
- LLMs are raising utility prices
- LLMs are raising computer prices
- LLMs give you teh dums
- LLMs show negligible increases in net productivity
- LLM costs are going up
- LLMs run on stolen content
- LLM companies keep breaking laws and saying, "Oopsie!"
Open Source maintainers for some reason:
- We are debating our AI policy, but it's a tough decision. *whines*
Dudes. WTF is wrong with you?
Anthropic Visual Studio Claude Code extension on Cursor has malware in it, which creates a remote access Trojan to desktops.
this is infuriating @nctvnl, why are security and counterterrorism swapped in your <title>?
πβ€οΈ Please support my beautiful family. π₯Ήπ· My family deserves your support and kindness. π΅πΈπ Every little help means so much to us. π€²β¨https://chuffed.org/project/208485-give-waleeds-family-a-chance-to-live
Maintainers of open source projects should be mentoring folks to become their replacements. Not just thinking this is about controlling their project.
I have learned this the hard way for gcc.
You can't just think it is your way or the highway. Also gsoc is NOT a replacement for mentoring inside the project. It should supplement the mentoring that is done, just like an internship.
Also this is not unique to gcc, it is many open source projects.
And then there is the gaming of github stats, the one or two commits in llvm and leave issue. Those are used to gain stats for a job.
Seriously open source is broken because of the gaming of the system.
Even inside companies where you have the person with the most open source commits. Or the person who opened the most issue. Or the person who reviewed the most. (What is funny is that i am that person but I am not trying to play the game of counting, I am just trying to push gcc forward).
At the same time I am mentoring folks both inside and outside of qualcomm on both gcc (and even to a less sense llvm) and performance analysis.
But going back to my original point is mentoring and maintainship overlaps. It is not one or the other but rather both in the same role.
By the time you step down you should have at least mentored a few to be able to take you from you. If you have not you partially failed a as a maintainer as the project will no longer can be maintained in the future.