You can always populate .init_array section with a hidden constructor. It would work just like ifunc and would always execute at shared library load time.
I think .init_array is too late in the game. ifunc lets you hijack the loader, because it is sort of like a plugin or dynamic config for the loader itself. Everything should be loaded and resolved by the point that .init_array stuff starts getting triggered, though ELF is dark and full of terrors so who knows really.
You can also use most of the core components (labels, buttons, grid views, image and media players) with LGPL in commercial apps. Only the more complex and more value-adding components like charts are GPL.
I'm not defending this but there was (or has been) enough political motivation and intentionality in GNU/Linux systems to make binary compatibility a hassle. People actually made decisions against backwards compatible APIs, intending to cause issues and forcing open-sourcing.
Binary compatibility means closed source has a chance to grow in an ecosystem. It requires "responsible" developers to put more effort into designing APIs and keeping them alive. It adds complexity that requires a more stable set of long-term developers; in contrast, the constant churn in FOSS requires lower barriers for contributions. With stable APIs/ABIs you have to live with decade-long mistakes. You cannot "just fix it" in a next major bump.
Unfortunately our economic system is a ponzi scheme that requires having children while constantly putting them into deeper and deeper debt. It will eventually collapse and take VWCE with it.
Europe is not less innovative. Many advanced machinery that makes everything else originate and get perfected in Europe.
EU is way more efficient in making citizen-friendly laws too.
The USA just likes to splurge unnecessary amount of money and call that "innovation" where there isn't any. They can do that because they have lots of money and infinite debt limit due to US Dollar's special status. This also makes everything else expensive for other players in the world. Remove the special status and see how the worlds change.
(4) Or just as the law states, you can update the regulation accordingly. There are avenues of update just in the law. The connector should be just modern enough. At the same time I do believe thermodynamics itself will be the limit and 120 W is more than enough for any phone.
Apple Silicon had a process node advantage over the Core 100 and 200 series due to having a better allocation with TSMC.
Now Intel's process node is also SOTA and on par with TSMC 2nm so they should be more or less equivalent and the only differences down to what set of compromises they make in the design of the chips.
Phones cannot have non-updated software due to another EU Regulation: Cyber Resilience Act. You need to support devices at least for 5 years starting from December 2027.
How sure are you that the vendor is actually providing device-specific updates? What about firmware updates? Outside of x86 ecosystem the whole-device-family updates in mainline Linux kernel is rare. You're probably deceiving yourself believing that your devices are up-to-date.
Most of the time laptops and many "mainline-friendly" phones stop receiving firmware updates in 2 years. By "firmware" I mean the binary blobs for the peripherals. Most of the SoCs have unified memory for the LTE and CPU modules. If a vulnerability found in the firmware of the LTE module, it can be used for data extraction.
CRA puts hard requirements on documenting and fixing vulnerabilities in device software in 5 year period. It cannot be infinite amount of years, so a reasonable update period had to be choosen. It covers everything provided by the vendor itself too. So if there are vulnerabilities in FW they have to fix it unlike the current situation.
> How sure are you that the vendor is actually providing device-specific updates?
First of all, my phone runs an FSF-endorsed operating system, so no closed drivers. Granted, not everything has been upstreamed yet, but they're working on it and I trust that it will be done soon. (They have done it with the devkit.)
Second, my phone has removable modem and removable WiFi card (no unified memory), so when the firmware can't be updated anymore, the card itself can be replaced. (They actually have already done it by releasing a new WiFi card; 5G modem is also being tested). In the worst case, the device can still be used as a pocket computer with no wireless communications.
Conda does not solve the problems of deployment and they don't have any reproducibility guarantees. That's not surprising considering how Conda binaries are built.
That's why I emphasized Pixi. With Pixi you get a per-platform lockfile that guarantees installation of the exact versions.
If what you want is to deploy a server or development environment, you already get it with Pixi. If you want a Windows installer with DLLs, you don't get. However it was never the reason.
Actually no. I use it to manage more and more non-Python dependencies like Protobuf compiler and LLVM tooling.
I am an embedded developer and we don't use Python for the main project. It is just scripting. It doesn't get rid of everything but it does make developer environment setup so easy.
When you have switches that link two nodes together, for only the duration of one-way transmission you don't need CSMA/CD. We literally have no use for it. We will never have two computers transmit onto the same Ethernet wire anymore.
WiFi is different of course. However as the author wrote, your WiFi devices always go through the access point where they use 802.11 RTS/CTS messages to request and receive permission to send packets. All nodes can see CTS being broadcasted so they know that somebody is sending something. So even CSMA/CA is getting less useful.
Yes I'm only talking about wifi networks. I get that CSMA/CD itself is getting less useful, but it's because something else is doing its job, not because what it did is useless (that's why I wrote "or something similar" when I asked). Wifi is still, necessarily, a common bus where everyone talks.
CSMA/CD - Collision Detection and CA Collision Avoidance. - FYI the article is from 2017!
for Non-WiFi, we don't use CD because all is bi-dirireactional and all communication have their own lane, no needed because there will never be a collision this is down to the port level on the switches, the algorithm might be still there but not use for it.
For WiFi, CD can never be good or work, because "Detecting" is pointless, it cannot work. we need to "Avoid" so it has functionality because is a shared lane or medium. CA is a necessity, now in 2026, we actually truly don't need it or use it as much since now WiFi and 802.11 functions as a switch with OFDM and with RF signal steering, at the PHY (physical level) the actual RF radio frequency side, it cancels out all other signals say from others devices near you and we "create" similar bi-directional lanes and functions similar as switches.
The article is good and represents how IETF operates a view (opinionated) of what happens inside. We actually need an IETF equivalent for AI. Its actually good and a meritocracy even though of late the Big companies try to corrupted or get their way, but academia is still the driver and steers it, and all votes count for when Working-Groups self organized. (my last IETF was 2018 so not sure how it is now in the 2020s)
reply