They really are, though. Security is all-encompassing, including not just programming languages, libraries, programs, but also systems, humans and their processes. Don't forget physical security either.
There are no silver bullets, and if the Rust Hype Squad told you there were and all you had to do was buy their product, they were just bamboozling you to push adoption of their pet language.
Write in whichever language you like. Including Rust. Including C. Even PHP. You can write secure software if you put your mind to it.
That's not a great analogy. There are no pick-proof locks (...that are mechanically operated and admit keys; I'm presuming you didn't mean "pick-proof" in that there is no keyhole to pick but is defeated some other way, e.g. a keypad, you meant maximally pick-resistant in contrast to "easily picked")
And honestly? No! If someone can kick your door down, don't waste your money on a super-secure lock, they will just kick your door down. And if you're having your door kicked down on the regular, don't even focus on bolstering the door (they'll either start using power tools or take some other tact like smashing your windows or drilling through the floor or roof). Leave the door open if you like, but move whatever's attracting the attention of intruders somewhere more defensible. Focusing on the securing the wrong thing is also a security flaw!
Most processors support both "interrupts" (an external peripheral is banging on the CPU's interrupt pins... but also invocable from software; software interrupts; SWIs; INT instruction on x86) and "exceptions" (e.g. divide by zero, bus error, illegal instruction). Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Other uses for interrupt/exception/trap vectors include hardware breakpoints: don't try and single-step the CPU, overwrite the code with an illegal instruction and control will flow to the illegal instruction handler where you can see all the registers then execute the real instruction that was meant to be there and return to where you left off. Some CPUs have a formal "BKPT" type instruction for that.
One other use on the 68000 is that any unrecognised instruction that started $Fxxx triggered the F-line handler; all the floating point instructions were in the form $Fxxx, so if you didn't have an FPU, you could put a software emulator for the FPU instructions in the F-line handler and software wouldn't know the difference. Traps/exceptions don't have to be a jump from unprivileged to privileged, they can just be utilitarian.
> Depending on the processor, accessing the "privileged" mode can be done either by software interrupts, exceptions, or both. An operating system should pick one and stick with it.
Practically most will support access via both, but for different reasons. For example, page faults (which the software cannot possibly predict) are going to be exception-mediated, but syscalls (which the software asks for) are triggered via an interrupt.
I worked for a payment processor in Europe, we provided SEPA and some other payments, but not card payments (so there could be some difference).
Difference is in fees and licenses. Payment processors that process high risk payments (adult industry, gambling, etc...) have higher fees and need license from governing body (usually a national bank in country where the payment processor is registered). So if you process high risk payments as low risk you will get a fine from governing body and you risk to lose your license. And if you don't have a license for high risk payments you cannot process them.
I don't work there anymore, but I heard they lost SEPA license a couple of years ago because of risky transactions.
Now I am not sure if Visa and Master are forcing payment providers to give up high risk transactions or if they are forcing them to classify all transactions as low/high risk.
The pressure comes down through processors from Visa/MC. The new processor you sign up for gets the same phone call and give into the same set of demands, like a clockwork. The alternative has to be something that consumers of your product can handle that don't go through the CC infra, one that this caller don't have the numbers for.
It could be through vouchers sold at gas stations, bank transfers, QR payment apps, etc. But CC has by far the best penetration and most alternatives are weak at best.
If you do figure out the alternative payment or distribution strategy immune to pressure through CC, then it changes targets to legal systems and NGOs. You'd want couples of congresspeople or to push back on that front.
There are none that are reliably usable by actual porn companies at this moment. Check pornhub, you can only subscribe to them via bitcoin and direct bank payments.
> Question: what prevents an organisation like Kickstarter from using more than one payment processor, including the ones used by actual porn companies?
The way the policies work, they would either have to use the latter processor for all transactions (which would be prohibitively expensive) or relegate all "adult" content to a completely separate company and domain, which would be a huge pain and expense to operate for something that constitutes a relatively small fraction of their business.
Nothing prevents them, and some companies that want to support both adult and non-adult content do. But it's also reasonable for Kickstarter to decide that adult content is not so important to them that they want to jump through hoops to dodge Stripe's rules.
What I have heard before is that the processors don’t want to be associated with the sites at all, even indirectly, so unless the content is banned from the site entirely they will pull service.
It's more of a good thing that, in most cases, it's on devices that won't send it any packets unless a client first authenticates to a Wi-Fi station or physically plugs into an Ethernet port.
They're objecting to use of their cloud service, and they're also disabling local-only mode thus forcing use of their cloud service, and their software is required to be AGPL (because that's how they themselves received it) so they're required to allow you to clone it and modify it but they just don't want you to.
It's "I would like to take this free software so I don't have to write it, oh and by the way I want to make everyone dependent on me now for enshittification reasons, so kindly fuck off and let me use this software just by myself. I take, you no take. Understand?"
It's already gone. This whole issue kicked off in January 2025: https://ghostarchive.org/archive/qwL63 - your only options were to stay on older firmware (and even then, the T&C's are sketchy, it worries owners there's no guarantee Bambu won't change their mind) or, if you upgrade, you push everything through Bambu's cloud services forevermore, and no backsies. Only a handful of operations can then be done by directly talking to the device, from that point on it only speaks to its real owner, Bambu.
Bambu's blog mentions LAN Mode. What they fail to mention is that LAN Mode still requires their cloud service for authentication, i.e. they get to cut you off any time they want. They also removed the ability for third party software to talk directly to the printer, it instead has to go through their closed-source "Bambu Connect" handler running on the same computer, with very limited functionality, and only if Bambu Connect chooses to pass on the message.
If investors invest heavily in lemon juice, then go around hyping it and selling it with the promise it makes you invisible to cameras (which it doesn't), it doesn't matter how stupid and gullible the rubes who fall for that are, the investors bear the responsibility for giving them that idea, when people start attempting to rob banks with lemon juice on their faces.
Hype is bad. Unwarranted hype is worse. Enabling people who can't do a thing to do what they think the thing is, but isn't, because they don't know any better, is inflicting a pox upon the world.
Well.. it was ~6 years and ~10 billion payments ago, the clients have been fixed but the "hack" is still there, it has caused no harm as far as I can tell. Worst case scenario it's useless, best case scenario it prevents regressions.
The issue with things that client must not do is that they might still do them, and users don't care whose fault it is. It's important to have auxilliary mechanisms to mitigate these.
That it may be there or not doesn't mean it "caused no harm". It sounds like yet another carbuncle added in haste and then never fixed properly, leading to 6 years of fear of touching it.
If it's truly intended, it needs to be part of the official spec, with a robust justification of why it's there at all. Neither server nor client ought to have unnecessary and undocumented things "just in case", because that breeds a culture of uncertainty.
If you fear client regressions, make it a mandatory part of the client's test suite. You control the client, right?
https://archive.org/details/flash_allyourbase
reply