they try really hard to make developers like them, and I dont know why but it triggers alarm bells in my head. I dont want to become dependent on a single company for the rest of my career
I love rust but honestly I am more scared about supply chain attacks through cargo than memory corruption bugs. The reason being that supply chain attacks are probably way cheaper to pull off than finding these bugs
But this is irrelevant. If you're afraid of third-party code, you can just... choose not to use third-party code? Meanwhile, if I'm afraid of memory corruption in C, I cannot just choose not to have memory corruption; I must instead simply choose not to use C. Meanwhile, Chromium uses tons of third-party Rust code, and has thereby judged the risk differently.
Maybe it's more complicated than that? With allocate/delete discipline, C can be fairly safe memory-wise (written a million lines of code in C). But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for. By that point of view, we reverse the conclusion.
>can be fairly safe memory-wise (written a million lines of code in C)
We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.
>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.
Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.
Yet so many language features that 'help' with this issue, end up not helping. Null pointers are endemic in Java, as well as leaks. Heap fragmentation becomes difficult to address when the language hides it under layers of helpful abstraction.
In the end, discipline of some kind is needed. C is no different.
If you can bring in 3rd party libraries, you can be hit with a supply chain attack. C and C++ aren't immune, it's just harder to pull off due to dependency management being more complex (meaning you'll work with less dependencies naturally).
It's not more complex in C or C++, you just have less of a culture of buying into a whole eco-system. C and C++ play nice with the build system that you bring, rather than that you are forced into a particular way of working.
It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository.
That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane.
Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it.
You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of deps, including one to check that something is executable.
You also won’t typically find C/C++ developers blinding yolo’ing the latest version of a dependency from the Internet into their CI/CD pipeline.
They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat.
yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though
> both of these are not the case in practice though
No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compiler.
I know it's a sensitive topic for a lot of people, but as I said, I love rust. I don't know a lot of rust projects though that don't use any dependencies. In my humble opinion, disregarding the risks of such supply chain attacks is at least as bad as people disregarding the risk of memory unsafe code. But keep in mind, I'm not saying don't use rust.
And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.
And every instance of unsafe that I could find (except one, in test-only code) was a call to libc with a clarifying comment on why this particular use was safe. That is, all (or at least, all of it that I could find) was wrapping an unsafe API with documented (and usually straightforward and local) invariants that maintain safety, such that the calling code is safe.
I'd say that the fact that miri's trophy-shelf[0] has 39 entries and is 7 years old and still regularly updated is a pretty good indicator that memory bugs are sufficiently rare in rust so as to be notable. That is the opposite of "regular"
> A comment does not automatically make code safe. What even is that argument? There have directly been examples of Rust code with SAFETY comments that later were found to be memory unsafe.
I did not make this argument. I encourage you to reread my comment and do so with the HN guidelines in mind!
The vast majority of Rust code out there doesn't use the `unsafe` keyword at all, and the vastly smaller amount of unsafe code that exists allows for focused and precise testing and verification. You really have no idea what you're talking about if you're trying to say that Rust is anywhere in the ballpark of C or C++ here.
One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc).
I would argue that almost all major rust projects use dependencies. Checking the dependencies for vulnerabilities might be just as difficult as checking C code for memory safety, maybe even worse, because dependencies have dependencies and the amount of code to be checked can easily sky rocket. The problem gets even worse if you consider that not all rust code is safe, and that C libraries can be included and so on
Yes, but I believe that results in a cost/benefit analysis. If there are readily available rust crates that do something you need, and the cost of a possible vulnerability is not huge, most projects might decide (right or wrong) that it is worth it. It's an interesting question why projects tend to make different decisions in different languages, but it does not necessarily mean that you have to make the same decisions.
My point is that if you put a very high emphasis on avoiding vulnerabilities, you can either write the code in C with no/limited dependencies (and still risk memory safety bugs), or write the code in Rust with no/limited dependencies and no/limited unsafe code, and get much stronger guarantees for the same/less effort.
Fair, you see the perspective from someone writing the software and it makes sense. But when I see it though the lenses of someone choosing software to run, I would rather choose a C program with potential memory bugs than a rust program with a lot of dependencies - because I am more scared about supply chain attacks than someone being able to exploit a memory bug. But then again, this obviously changes if the rust program has no dependencies.
That being said as many above have pointed out you can choose not to bring in dependencies. The Chrome team already does this with the font parser library they limit dependencies to 1 or 2 trusted ones with little to no transitive dependencies. Let's not pretend C / C++ is immune to this we had the xz vuln not too long ago. C / C++ has the benefit of the culture not using as many dependencies but this is still a problem that exists. With the increase of code in the world due to ai this is a problem we're going to need to fix sooner rather than later.
I don't think the supply chain should be a blocker for using rust especially when once of the best C++ teams in the world with good funding struggles to always write perfect code. The chrome team has shown precedent for moving to rust safely and avoiding dependency hell, they'll just need to do it again.
They have hundreds of engineers many of which are very gifted, hell they can write their own dependencies!
Yeah I am not saying don't use rust. But the average amount of dependencies used by a dependency makes a big difference in my opinion. The reality is, most people will use wast amounts of dependencies - especially in vibe coded environments, where LLMs try to save a few tokens.
The problem exists in C/C++ too, but the depth of dependencies are much smaller though, making the attack surface smaller, and damage gets spread to fewer products.
If I personally had to choose between a product written in C without dependencies to run on openbsd versus the same product written in rust with a few dependencies I would probably choose the C implementation. Even if there is a memory bug, if the underlying system is right they are extremely difficult/expensive to exploit. Abusing a supply chain on the other hand is very easy
But the thing is these DO get exploited in the wild we see that again and again in high value targets like operating systems. That's why apple and google go to such high extremes to work in things like bounds checking. ROP JOB chains have gotten good and LLMS are even able to help these days (if you have the bankroll)
It's a culture problem and I still have hope we can change that. My big hope is that as more big players get into it, windows, linux, android, chome, we'll get high quality stand alone packages. Many of these products have to reach certain standards. We saw this recently with JPEGXL. It got accepted into chromium and they've been diligent as to not bring in additional external dependencies.
Projects like sudo-rs take the same approach. As always good engineers will make good code as more of a niche for rust gets carved out I belive we'll see an ecosystem more like c / cpp and less like nodejs (of course this is just my sepeculation)
> But the thing is these DO get exploited in the wild we see that again and again in high value targets like operating systems.
Yes but so do supply chain attacks. I mean we both know there's never a way to be absolutely secure and it's all just about probability. The question is how to determine what product may have better chances. All I am saying is that I personally prioritize fewer dependencies over memory safety.
I like your optimism, which I unfortunately struggle to share. I believe the quality of code will go down, there will be a lot of vibe code, and in general inexperienced people who don't put in the cognitive effort to pay attention to it. As software gets cheaper with AI, it will also become increasingly difficult to find the good things in a sea of slop. A good time for all the security engineers though ;)
right but these differ drastically, one is writing perfect code which is quite difficult the other is opting not to take a dependency. One is much more realistic.
I agree on software quality going down, I'm looking very closely at foundational software being written in rust (mostly in the kernel) and it seems to be okay for now.
The other hope is that maybe one day rust will get a fatter standard lib. I understand the opposition to this but I really want a series of crates tied strongly to the ecosystem and funded and audited by the foundation. I think this is the way they were going with offering the foundation maintainer fund.
Personally I'm thinking about moving my career into embedded to escape the massive dependencies and learn more about how computers really work without all the slop on top.
The statistics we have on real world security exploits proves that most security exploits are not coming from supply chain attacks though.
Memory safety related security exploits happen in a steady stream in basically all non-trivial C projects, but supply chain attacks, while possible, are much more rare.
I'm not saying we shouldn't care about both issues, but the idea is to fix the low hanging fruit and common cases before optimizing for things that aren't in practice that big of a deal.
Also, C is not inherently invulnerable to supply chain attacks either!
Nothing eliminates the risk but it is basically a best-in-class solution. If your primary concern is supply chain risk, there you go, best in class defense against it.
If anything, what are you doing about supply chain for the existing code base? How is cargo worse here when cargo-vet exists and is actively maintained by Google, Mozilla, and others?
true, but rusts success in creating an easy to use dependency manager is the curse. In general rust software seems to use a larger amount of dependencies than c/c++ due to that, where each is at risk of becoming an attack vector. my prediction is that we will see some abuse of this in future, similar to what npm experienced
All mainstream package managers are built with zero forethought into security, as far as I can tell. I don't think any of them are any good at it at all, otherwise they wouldn't give arbitrary code execution with literally zero restrictions, ability to audit, etc.
That said, `cargo-vet` is easily the best tool for mitigating this that I am aware of and it exists for Rust and is actively maintained by Google, Mozilla, and many others. I think it's fine to say "Rust encourages using more dependencies" but it has to be acknowledged that Rust also brings with it the best in class tool for supply chain security.
Could it be better? Absolutely. God yes. Why is cargo giving access to `~/.ssh/` for every `build.sh`? Why do package managers not make any effort to sandbox? But that's life today.
Free speech for the individuals is needed, in terms of people should not be punished for what they say. But social media platforms owned by foreign countries is a danger for any democracy. There's a reason the US wants to capture Tiktok, Iran is shutting down the internet, and China has The Great Firewall.
Since the US is turning away from Europe's interests, it's just logical that American platforms will be restricted in one way or another. I don't see any way around it.
There is a big difference between danger for democracy because of these addiction farming Social media platforms with propaganda and something like piracy as well though.
I tried to find something in the article that bothered me, but I don’t find it very convincing. Points like "someone can forward your email unencrypted after they decrypt it" are just... well, yeah - that can happen no matter what method you choose. It feels like GPG gets hate for reasons other than what’s actually mentioned, and I'm completely oblivious to what those reasons might be.
It's not that someone can forward your mail unencrypted. It's that in the normal operation of the system, someone taking the natural next step in a conversation (replying) can --- and, in the experience of everyone I've talked to who has used PGP in anger for any extended period of time, inevitably does --- destroy the security of the entire conversation by accidentally replying in plaintext.
That can't happen in any modern encrypted messenger. It does happen routinely with encrypted email.
pgp as a tool could integrate with that, but in practice fails for... many reasons, the above included. All the other key exchange / etc issues as well.
well that's fair, but sounds more like a email client issue than an actual issue with gpg/pgp. My client shows pretty clearly when it gets encrypted. But maybe I am oblivious.
I agree that it's an email problem, which is why I wrote a whole article about why email can't be made secure with any reasonable client. But email is overwhelmingly the messaging channel PGP users use; in fact, it's a common-cited reason why people continue to use PGP (because it allows them to encrypt email).
A protocol that doesn’t enforce security and relies on clients to choose to implement it is a broken protocol, from a security standpoint.
Even if secure email clients exist that always make right choices, because you can’t know what client all your recipients are using, all it takes is one person with a “bad” client (which, keep in mind, is a client that accurately implements the protocol but doesn’t enforce additional security rules on top) to ruin things.
Some Ukrainians may regret that the followed the Signal marketing. I have never heard of a real world exploit that has actually been used like that against gpg.
Those people shouldn't be, and thankfully aren't, using PGP. Nobody is suppressing this report on phishing attacks against Signal users; it's just not as big a deal as what's wrong with PGP.
Accidentally replying in plaintext is a user error, scanning a QR code is a user error.
Yet one system is declared secure (Signal), the other is declared insecure. Despite the fact that the QR code issue happened in a war zone, whereas I have not heard of a similar PGP fail in the real world.
First of all, accidentally replying in plaintext is hardly the only problem with PGP, just the most obvious one. Secondly, it's not user error: modern messaging cryptography is designed not to allow it to happen.
Modern cryptography should also not allow users to activate a sketchy linked device feature by scanning a QR code:
"Because linking an additional device typically requires scanning a quick-response (QR) code, threat actors have resorted to crafting malicious QR codes that, when scanned, will link a victim's account to an actor-controlled Signal instance."
This is a complete failure of the cryptosystem, worse than the issue of responding in plaintext. You can at least design an email client that simply refuses to send plaintext messages because PGP is modular.
there are at least two reasons trump is pushing for oil:
1) the US has lots of oil reserves, which would lose lots of value if everybody was using renewables
2) oil is the main driver for dollar demand, as oil is paid in dollar, allowing the US to have lots of debt relatively cheaply
That's also the reason why he wants to tell Europe to stop using renewables, and that's the reason why he is threatening Venezuela - because they have the biggest oil reserve and started selling it in different currencies.
Now whether that whole genius strategy to gain wealth through geopolitics is worth an extinction event is a different story.
> That's also the reason why he wants to tell Europe to stop using renewables, and that's the reason why he is threatening Venezuela - because they have the biggest oil reserve and started selling them not in USD.
What's interesting is that the strategy you suggest (tell Europe to stop using renewables, attack nations that compete with US oil sales) only motivates other nations to move away from oil. It's a terrible strategy if the intent is to sell more US oil. Renewables are far more sustainable in many regards, and bolster national energy security while remaining on fossil fuels leaves them weak wrt energy security.
it could very well be that it backfires. I guess time will tell. A lot of his actions seem to be trimmed into this direction, and it's not a new one. He left the paris climate agreement quite a while back as far as I remember. blocking offshore wind construction just fits this agenda, as supporting companies to manufacture these windmills would just make everything cheaper (more demand, rising production capacity etc.) and demonstrate actual use of it.
It's kind of hard to see the strategy you outlined as doing anything other than backfiring. Oil and other fossil fuels are consumables. Once burned, they're gone. For strategic reasons, most nations with any sense and the economic ability to do so are turning away from fossil fuels precisely due to this fact. European nations are not exceptional here, the US is actually the outlier.
Your suggested strategy is that the US wants European nations to buy more US oil, and in order to motivate them the US is demonstrating how bad oil dependence is. See Cuba (they depend on Venezuelan oil there).
How could a demonstration of the flaws of oil dependency possibly motivate the sale of US oil rather than hasten the move towards solar, wind, and other power sources?
This is why I said it's a terrible strategy. Only the non-thinking would go for it.
You could be right. I try to abstain from making any predictions, because I see the world is such a complicated mess where even stupid decisions could get a positive outcome due to unforeseeable events. (a new pandemic? a war breaks out? someone decided to retaliate? the suez canal gets occupied? a volcano erupts?)
That being said, he is obviously aware that Europe is planning on greener energy. This administration also tries to break down the EU by pulling out countries like Italy and Poland. They are clearly promoting right wing parties all over Europe which align more with his agenda and are more EU sceptic. They might try to use social media for propaganda. The goal is divide and conquer. Europe has to pay attention to this and be aware of the risk. The strategy may seem stupid, but it would be even more stupid to ignore it and not make sure it fails.
I know plenty of people personally who can rant about energy prices being high while somehow finding room in the same breath to demonize wind and solar energy and even namedrop whichever foul devil bogeyman it is this week that is said to be the cause of this disjointed trauma that they find so overwhelming.
In the next breath, they pick something else from the deck to be upset about: These days, that's usually brown people, emails, laptops, the American cities that people in frog costumes burn to the ground every night, brown people, guns, laptops, and Hillary.
Sometimes, they then take a break to hear themselves talk about baseball, praise the president for getting so much done that he doesn't even have time to sleep, or to complain about the plot from the episode of The Dukes of Hazard -- from 1983 -- that they watched for the 14th time last night on Pluto.
After the break, it's time for them to complain about how they can't afford visit a doctor or buy eyeglasses, but they sure as hell don't want them any of those librawls to take any of their hard-earned money so everyone can go to the doctor.
Then things shift back to being weirder again: Schools turning boys into girls, kids using litter boxes in the classroom, men wearing dresses, God's Perfect Plan, guns, brown people, groceries, brown people, and blue hair dye.
This tiresome process repeats until I manage to escape, or I tell them very pointedly to shut the fuck up (hints don't work).
None of the people I know who act this way seem to be particularly bright, but I know them anyway.
"while somehow finding room in the same breath to demonize wind and solar energy "
Did you ever consider that all the money spent on expensive renewables is money not spent on cheaper forms of power? Did you ever consider that they are correct and that spending on renewables drives up power costs? Because that's what the data says is happening. Now, I am aware that the amount of FUD on this topic is very different to get through. But if you learn about the differences between capacity and utilization costs and the other accounting games that are played with energy costs, you will learn how to see through the FUD. But I'm sure it is more psychologically comforting to just look down on them which is what you are actually doing.
I consider that I'm intertwined in the evolution of a very different friend's very local efforts, with their own hybrid battery-backed grid-tied offline-capable solar power system.
That rig is pretty sweet.
It pays for itself, and in present form and with their present use (wherein: they're not trying to live particularly-efficiently) it is almost entirely capable of keeping them with power even if the grid goes down for an indefinite period.
But, sure: We can talk about games, instead, if what you want to chat about is just games.
"entirely capable of keeping them with power even if the grid goes down for an indefinite period."
You do know that batteries have a capacity right? And powerplants have something called a capacity factor. That means for a given amount of capacity, you generate on average a certain amount of power. For nuclear that factor is .9. For renewables its .1. So 1 watt of nuclear provides the same power as 9 watts of renewables. That's why when you say that renewables have 1/3 the capacity cost, it really means its 3x more expensive than nuclear. That means higher bills for people, which is what we mean when we say utilization cost. That's the real cost that people pay and actually counts. And all this is before we talk about siting issues with renewables. Fun fact, most PV is sites (located) somewhere with an albino factor of less than .25. But since you connected a battery terminal to a PV panel, you must know what that means. Seriously, you are just spreading misinformation that transfers cost from the rich to the poor, such a hero you are.
Most grown men are influenced by this. The patriachy is strongggg.
Just like you can manipulate women en-masse by appealing to patriarchal attitudes around femininity and beauty, maybe by talking about weight or hair, you can influence men by appealing to patriachal attitudes around masculinity.
I mean, you can convince the average American man to drop an extra 20K on a truck he doesn't need and a multiply his gas cost by 2x just by convincing him it's manly. You can discourage men from drinking cosmopolitans and instead have them drink the equivalent of cat piss by telling him it's unmanly.
“Last week, Trump Media, the parent company of Truth Social that is majority-owned by the president, said it was getting into the energy business, announcing a merger with a fusion firm TAE Technologies.”
I am quite convinced a lot of open source is not open for ideology reasons but rather are a result of competition and the market itself.
When the competition publishes its software for no price, the next way to make it even better is by improving the license. And if thats not enough you can even pay users to use your software, just like brave does (or did) through ads.
Now theres software which has less competition. Usually this is software that requires large amounts of investments, often coupled with hardware. Smartphones are the perfect example for this.
Also, software which is tied to hardware that you have to buy has less pressure, because there's a price anyway for the hardware. So you wont suddenly have some competition offering the same thing for free.
I genuinely don't like the concept of the keyboard interaction in helix and kakoune, selecting things to modify them. I don't know what it is, but it somehow just feels much less satisfactory to me personally compared to the vim way.
The biggest benefit is multiple cursors. The helix and kakoune multiple cursor implementation are probably the best in any editor. It just goes hand in hand with selection first.
The problem with that editing model for me is that it makes text objects much more cumbersome.
In Vim you can for example do "dap" to delete around a paragraph, but you cannot easily invert it ("pad") because 'p' is too common and is already bound.
You can also easily do the "select first" in Vim by first pressing 'v' to start a visual selection, so I just don't see the point.
This bugged me for reasons I can’t quite explain. I think it’s that I can write and edit the command before making the modification and the ease of going back and reusing a historic search and replace relatively easily.
I spent about a month trying to get used to Kakoune. It never clicked with me and I went back to vim.
My biggest beef with Kakoune’s editing philosophy is that it seems to emphasize “editing in the large” as its preferred mode of interaction. This is totally backwards to me. Editing in the large (making multiple identical edits throughout a buffer) is a rarity. Most edits in day to day use are single edits. So the fact that Kakoune likes to leave a bunch of extra cursors in your wake (like a trail of breadcrumbs) as you jump around a file to make single edits is extremely infuriating to me, like it’s trying too hard to be helpful.
The irony of Kakoune using a clippy-style contextual help window is not lost on me!
I voted no in this, but I was on the fence. In my experience people are smarter than they get credit for and the decisions made in these votes are often quite good. There was more to consider than privacy, it's also about the fact that most countries will implement something like this as it is pushed by the UN. So it might become required for some things in the future. Then we currently don't have a whole lot of ways to distinguish AI from people anymore, which will only get worse. Propaganda bots are real and we don't know how that will evolve. It will make a lot of the processes easier as you can do them from home, which is especially useful for disabled people that can not easily appear physically. Plus, it's more or less optional to have one for now.
And yet, I am still kinda disappointed it passed. We will see how it evolves.
Unfortunately they also passed a law for age checks in order "to protect children", which is supposed to block porn unless you show your E-ID. While a referendum was initialized it sadly didn't gain enough media attention to actually make it to a vote.
