Comment Re:That library file limit (Score 1) 7
Nope. That's why I changed all my players to BlueOS.
Nope. That's why I changed all my players to BlueOS.
I replaced all my SONOS connects with BlueSound node Nano devices. A pricey replacement, but worth it.
As a bonus I was now able to turn off SMB1 on my home Samba server !
The biggest problem are the platform ABIs that are not expressive enough for either rust or C++. That means both sides do tricks to smuggle extra information through the C-compatible platform ABIs -- or to pass constructs entirely around that ABI. E.g. name mangling is used to smuggle function overloading through the C ABI by encoding type information into the symbol name which is just a string.
Things going around the ABI is all the stuff that C++ requires to always be in a header file. Those headers get directly included into the user of a library, going around the ABI layer completely.
The challenge for interoperability is to extract all the necessary information from one language and make that available in the other. Gathering that information without some defined ABI means extracting it from the source code of the language itself. That is damn hard, especially if one side is C++ that needs heuristics to even get parsed.
Meanwhile Rust-inspired safety principles and constructs are being added to C++ right now in the form of Circle C++ and an enhanced libstdc++, and in the near future in the C++ standard. The future for C++ is quite bright and will allow more cost-effective ways of retrofitting safety onto existing C++ code.
There is a proposal to have Rust semantics in C++. Nothing more. It will take decades to get that through the committee, with prominent members already having said that all other venues need to be explored before this proposal can be considered.
Sean having suggested to not have a new C++ standard library (but to use rusts instead) is not going to help find support inside the committee.
So the problem is that you got devs that are unwilling or unable to learn new things? That's indeed a problem...
They will suck out the will to live from any fresh blood that joines their team. Your product is stuck in the past forever, behind a strong waöl of "we never did that before".
You should write correct code everywhere.
Yeap, but humans just can not do that. We need tools to help us.
C++ isn't Rust. Are you now suggesting that C++ adopt implementation details of Rust to solve a problem?
... and yet that is exactly what the "Safe C++" proposal is that has hit the committee recently.
"The responsibility is on our ecosystem, not the developer"
This is false. You need to train your developers (unless they're already skilled).
We are pretty much the only industry that thinks like that. There is no contradiction between "improve eco system" and "train developers". All the other industries around us do both.
We are also pretty unique as an industry in that we watch our products fail and then go "there is nothing we can do about that, sucks that random people were too stupid to write proper code". We urgently need to improve, or we need regulators to step in to make us improve. Code is just getting too important to continue with our attitude.
What do you mean with secure? Secure as not attackable, or secure as not crashing, aka having memory bugs?
Memory issues are used to attack your software. Them causing crashes is the lucky case...
True, but those languages make sure you do not need to worry about the entire class of bugs that are related to memory management.
That frees up resources to think harder about all the other issues your code might have.
These days, security problems stemming from unsafe memory are not even the majority of issues.
Rust has proven that you can eliminate these issues without runtime overhead. So fixing these issues is now considered by governments to be low-hanging fruit.
> Every large NAS vendor (Synology, QNAP, etc) has their own SMB server they wrote themserlves
That's untrue. Both Synology and QNAP use Samba. QNAP contributes code and bugfixes back to samba.org (Hi Jones !).
The upstream Linux kernel doesn't differentiate between security bugs and "normal" bug fixes. So the new kernel.org CNA just assigns CVE's to all fixes. They don't score them.
Look at the numbers from the whitepaper:
"In March 2024 there were 270 new CVEs created for the stable Linux kernel. So far in April 2024 there are 342 new CVEs:"
Yes ! That's exactly the point. Trying to curate and select patches for a "frozen" kernel fails due to the firehose of fixes going in upstream.
And in the kernel many of these could be security bugs. No one is doing evaluation on that, there are simply too many fixes in such a complex code base to check.
Oh that's really sad. I hope they use a more up to date version of Samba
I don't see that argument in the blog or paper.
Did you read them ?
There are many more unfixed bugs in vendor kernels than in upstream. That's what the data shows.
FORTUNE'S FUN FACTS TO KNOW AND TELL: A giant panda bear is really a member of the racoon family.