Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.
I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.
Of course they cause problems as well, you not believing it doesn't change profiler facts.
I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.
While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.
I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).
I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.
AWS Bedrock has DeepSeek models running on their infrastructure. That should be enough to prevent training on user data (there's a markup compared to DeepSeek's pricing though).
And unfortunately AWS doesn't have prepaid billing, so you can't just give the internet access to your API key without getting FinDDoS'd.
Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use.
The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
# rmmod the module of concern first, then if that exits with the correct exit code:
sysctl -w kernel.modules_disabled = 1
sysctl -w kernel.kexec_load_disabled = 1
Once activated these settings will remain immutable until reboot. These settings can break OS updates among a myriad of other things. Calculating risk requires a dungeon leader, 4d20 dice and 12 magic 8-balls to form a quorum. Probably safer to just limit access based on role and then update the OS as soon as it is feasible to do so. Leave the role based access controls in place. If anyone complains add them to the on-call rotation.
Wouldn't manually loading a module require elevated privileges? Isn't the issue they are trying to solve that completely unprivileged users can exploit the module to elevate their privileges?
Let's consider a sysadmin who says "I blacklisted this module, so we shall never see it on this system."
And then, some random service or cronjob goes down a list and "modprobes" things. Such as a vulnerability scanner.
So the kernel module got loaded by name, until the next reboot.
Yeah, it's another coincidence and another narrowing of the conditions by which this can be exploited. But it's correct to say that blacklisting modules is not the panacea or a 100% airtight solution.
I just tried it on Ubuntu 24.04. Blacklisting algif_aead does not prevent the module from getting loaded by `nobody` using the unprivileged AF_ALG API.
So this project literally does nothing except spew some vibe coded slop across your cluster. Please just upgrade your kernel packages, it's way safer.
I don't know a good solution for this. 99% of websites asking for this hypothetical permission would not deserve it. Users (rightfully) don't expect that uploading a photo leaks their location.
Element (the matrix client) used to not strip geolocation metadata for the longest time. I don't know if they fixed that yet.
Yes, so they collected emails from users of one product and are now spamming marketing emails about a fundraising campaign for a different product.
That's at least two steps removed from being merely questionable. I'm really struggling to understand how they imagined that this wouldn't end up being blocked.
It's too late already. We live in a post-trust society now.