Your graph also cuts out early. Eventually you want to get performance gains with multi-threading and concurrency, and then the line drops all the way into hell.
I'm not saying you can't do multi-threading or concurrency in C++. The problem is that it's far too easy to get data races or deadlocks by making subtle syntactical mistakes that the compiler doesn't catch. pthreads does nothing to help with that.
If you don't need to share any data across threads then sure, everything is easy, but I've never seen such a simple use case in my entire professional career.
All these people talking about "C++ is easy, just don't use pointers!" must be writing the easiest applications of all time and also producing code that's so inefficient they'd probably get performance gains by switching to Python.
There's a difference between "You have to decide when to synchronize your state" and "If you make any very small mistake that appears to be perfectly fine in the absence of extremely rigorous scrutiny then this code block will cause a crash or some other incomprehensible undefined behavior 1/10000 times that it gets run, leaving you with no indication of what went wrong or where the problem is."
I use thread sanitizer and address sanitizer in my CI, and they have certainly helped in some cases, but they don't catch everything. In fact it's the cases that they miss which are by far the most subtle instances of undefined behavior of all.
They also slow down execution so severely that I can't use them when trying to recreate issues that occur in production.
Craig Doty II, a Tesla owner, narrowly avoided a collision after his vehicle, in Full Self-Driving (FSD) mode, allegedly steered towards an oncoming train....
Weird how this notion of "personal responsibility" applies to every person except for those people who choose to intentionally misrepresenting the product by branding it in ways that are misleading. The people running this company aren't responsible for their role in misleading the public, just because the fine print happens to indicate that the product isn't actually what it's marketed as?
Now you'll probably say something to the effect of "I never said that! You're putting words in my mouth!" except what other motivation can you have to jump to the defense of the liar and blame people for being misled, except that you want to put all the responsibility on individuals for being misled and not on the company that is systematically and intentionally misleading them? Maybe you just manage to derive a smug sense of superiority thinking of yourself as someone who is invulnerable to this kind of tactic so blaming the victims lets you feel good about yourself.
The Federal Trade Commission's Office of Technology has issued a warning to automakers that sell connected cars. Companies that offer such products "do not have the free license to monetize people’s information beyond purposes needed to provide their requested product or service," it wrote in a blog post on Tuesday. Just...
You oppose veganism from a moral standpoint...? You think it's immoral to subsist without needlessly torturing animals, or is there some other agrobusiness propaganda wedged in your brain that you haven't taken the time to debunk yet?
Because you don't like seeing people promote lifestyles that are objectively necessary for human life to be sustained on this planet in the long term?
Or because you don't have the discipline to overcome the upbringing that conditioned you to feel addicted to meat consumption, and you subconsciously realize that veg*nism is the morally and ecologically superior lifestyle and that leaves you with an inferiority complex that makes you lash out at others like an upset child?
I find that meat eaters' reactionary indignation to the facts of the harm caused by eating meat is way more aggressive than veg_ns trying to point out to people that we're literally killing ourselves as a species.
It's somehow even stupider when people who are veg_n like yourself act like it's offensive to promote the importance of veg_nism to a world that will otherwise die.
I really don't care how many people like me when it comes at the cost of the continued existence of humanity. I have no remorse about shoving an uncomfortable message into the faces of people who need to hear it.
I'm eager to acknowledge the systemic challenges of being veg_n since those were barriers for me in the past myself. I'm privileged to not have those issues anymore, but I still recognize the premium that I pay to be veg_n (my partner and I refer to it as "the vegetarian tax").
I harbor no animosity towards people who can acknowledge the sustainability crisis of the meat industry but aren't in a position to personally separate from it. The expectation that I have for decent and informed people, in order from the bare minimum to the absolute most is:
Don't pointlessly disparage veg_ns or spread misinformed agrobusiness propaganda. This in fact takes negative effort.
Occasionally examine whether you have any opportunities to reduce your meat consumption.
Talk to people you personally know about the sustainability crisis and see if you can find others in your circle who are interested in reducing their meat consumption. Work together to figure out effective strategies for doing so in your situation.
I mean scientists tried being polite and give gentle nudges with the climate crisis for decades and look where it got us. Civilization is driving towards a cliff and we've thrown away the steering wheel.
When I was younger I used to think that being nice to people and engaging them on their own terms is the best way to win people over to your cause, but at the end of the day people don't actually bother to change unless they realize that they need to for their own survival. So I'm done putting all my eggs into the respectability politics basket, and I'm not going beat around the bush on what a fucking cataclysmic crisis we're being faced with.
I certainly won't win anyone's affection, but if I can get at least one person to pause and ask themselves "..Am I in danger..?" then I'll take that as a win. If others think they can win people over with kindness, they're welcome to try.
You're thinking of faculty. This is referring to administrators. If you don't know the difference then you know nothing about how institutes of higher education function.
Next year Windows 10 goes End of Life. Microsoft will undoubtedly push windows 11 hard, but a lot of machines won’t support it leading to a few economic points of interest:...
If the issue exists in the standard library of every language that provides this capability and Rust's standard library is the first to fix it, how is it a Rust issue?
It would be more accurate to say that it's an issue in almost every language EXCEPT Rust at this point.
The only reason it isn't being called a C or C++ issue is because their standard libraries don't even attempt to offer this capability. But you can bet that all sorts of C/C++ libraries that do offer this, like Qt, will also be having this issue.
Because this is the status of the bug across the standard libraries of various languages, per this article and others:
Erlang (documentation update)
Go (documentation update)
Haskell (patch available)
Java (won’t fix)
Node.js (patch will be available)
PHP (patch will be available)
Python (documentation update)
Ruby (documentation update)
Notably C and C++ are missing from this list because their standard libraries don't even offer this capability. Half of these standard libraries are responding to the issue by just warning you about it in the function documentation. Rust is one of the few that actually prevents the attack from happening.
The original BatBadBut bug report used JavaScript to illustrate the vulnerability.
Except it's actually an "Every language and library that provides this feature" problem because literally no one was aware that this sanitization problem even existed, and Rust is among the first to actually fix it.
Funny how the headline makes it sound like a Rust specific problem, as if the Rust language is unsafe or the core team was incompetent, but then other affected language standard libraries include
Erlang (documentation update)
Go (documentation update)
Haskell (patch available)
Java (won’t fix)
Node.js (patch will be available)
PHP (patch will be available)
Python (documentation update)
Ruby (documentation update)
So actually this is a vulnerability that originates in Windows, and Rust and Haskell are the only languages that are actually protecting users from it as of right now, with Node.js and PHP to follow.
You're making a logical fallacy called affirming the consequent where you're assuming that just because the backdoor was caught under these particular conditions, these are the only conditions under which it would've been caught.
Suppose the bad actor had not been sloppy; it would still be entirely possible that the backdoor gets identified and fixed during a security audit performed by an enterprise grade Linux distribution.
In this case it was caught especially early because the bad actor did not cover their tracks very well, but now that that has occurred, it cannot necessarily be proven one way or the other whether the backdoor would have been caught by other means.
That link doesn't prove whatever you think it's proving.
The open source ecosystem does not rely (exclusively) on project maintainers to ensure security. Security audits are also done by major enterprise-grade distribution providers like Red Hat Enterprise. There are other stakeholders in the community as well who have a vested interest in security, including users in military, government, finance, health care, and academic research, who will periodically audit open source code that they're using.
When those organizations do their audits, they will typically report issues they find through appropriate channels which may include maintainers, distributors, and the MITRE Corporation, depending on the nature of the issue. Then remedial actions will be taken that depend on the details of the situation.
In the worst case scenario if an issue exists in an open source project that has an unresponsive or unhelpful maintainer (which I assume is what you were suggesting by providing that link), then there are several possible courses of action:
Distribution providers will roll back the package to an earlier compatible version that doesn't have the vulnerability if possible
Someone will fork the project and patch the fix (if the license allows), and distribution providers will switch to the fork
In the worst case scenario if neither of the above are possible, distribution providers will purge the vulnerable package from their distributions along with any packages that transitively depend on it (this is almost never necessary except as a short-term measure, and even then is extremely rare)
The point being, the ecosystem is NOT strictly relying on the cooperation of package maintainers to ensure security. It's certainly helpful and makes everything go much smoother for everyone if they do cooperate, but the vulnerability can still be identified and remedied even if they don't cooperate.
As for the original link, I think the correct takeaway from that is: If you have a vested or commercial interest in ensuring that the open source packages you use are secure from day zero, then you should really consider ways to support the open source projects you depend on, either through monetary contributions or through reviews and code contributions.
And if there's something you don't like about that arrangement, then please consider paying for licenses on closed-source software which will provide you with the very reassuring "security by sticking your head in the sand", because absolutely no one outside the corporation has any opportunity to audit the security of the software that you're using.
Security does not depend entirely on the maintainer, and there is recourse even in the worst case scenario of an uncooperative or malicious maintainer.
The maintainer you quoted said he would be open to complying with requests if the requesters were willing to provide monetary support. You are intentionally misrepresenting their position.
The alternative of closed source software doesn't actually protect you from security issues, it just makes it impossible for any users to know if the software has been compromised. For all you know, a closed source software product could be using one of the hypothetical compromised open source software project that you're so afraid of, and you would never actually know.
If you're willing to pay a license for a private corporation's closed source software so you get the pleasure of never being able to know your security posture, then why would you be unwilling to financially support open source developers so they have the resources they need to have the level of security that you'd like from them?
You're either intentionally misrepresenting the post or you failed to understand them correctly. I'll let you take your pick for which is less embarrassing for you.
The key sentence in the post you linked which constituted more than 50% of the words being stated by the poster and yet you somehow conveniently missed which completely negates the whole narrative that you're trying to promote:
Speaking as an open source maintainer, if a tech company would like to pay me to do ~anything for my open source project, we can sit down and talk about my rates.
Which means this person is NOT simply a volunteer as you insinuated here:
When someone suggested a level of effort to be put on code checked in to prevent security issues from happening, the maintainer pushed back, stating that they will decide what level of effort they'll put in, because they're doing the work on a volunteer basis.
but in fact is available to be paid a fair rate for the labor they perform. In fact your entire description of the post is mischaracterizing what is being said in the post.
I don't know how you could have accidentally missed or misinterpreted one of the two sentences being said by the poster, and the longer of the two sentences at that. It was also the first sentence in the poster's statement. It seems more likely to me that you missed that on purpose rather than by accident. Maybe you're just so eager to find evidence to match your narrative that your brain registered the entire point of the post incorrectly. Allow me to reframe what's being said to simplify the matter:
As a self-employed contractor, if you demand that I perform free labor for you, I will decline that request.
Now just add a much more frustrated tone to the above and you get the post you linked.
(On a more serious note, if this is happening to you then you're not following the instructions to clean the device and replace the filter once a month.)
JavaScript ( sh.itjust.works )
C++
Self-Driving Tesla Nearly Hits Oncoming Train, Raises New Concern On Car's Safety ( lemmy.zip )
Craig Doty II, a Tesla owner, narrowly avoided a collision after his vehicle, in Full Self-Driving (FSD) mode, allegedly steered towards an oncoming train....
Connected cars’ illegal data collection and use now on FTC’s “radar” ( arstechnica.com )
The Federal Trade Commission's Office of Technology has issued a warning to automakers that sell connected cars. Companies that offer such products "do not have the free license to monetize people’s information beyond purposes needed to provide their requested product or service," it wrote in a blog post on Tuesday. Just...
The signs are aligned. ( lemmy.world )
Is Boeing in big trouble? World's largest aerospace firm faces 10 more whistleblowers after sudden death of two ( www.hindustantimes.com )
Rule ( lemmy.world )
Are you prepared for the ramifications of windows 10 EoL?
Next year Windows 10 goes End of Life. Microsoft will undoubtedly push windows 11 hard, but a lot of machines won’t support it leading to a few economic points of interest:...
only two options ( i.imgur.com )
Critical 'BatBadBut' Rust Vulnerability Exposes Windows Systems to Attacks ( thehackernews.com )
Critical Rust flaw enables Windows command injection attacks ( www.bleepingcomputer.com )
Backdoor found in widely used Linux utility breaks encrypted SSH connections ( arstechnica.com )
The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project....
dog ( lemmy.zip )