You must be a desktop user. As a sysadmin, I really don't give a shit if my server boot takes an extra minute or two. Shit! The BIOS takes way longer to POST.
As is in distros will be made specifically to avoid it. Rust and Clojure are the worst things to happen to open source in a long time. There is a reason why good old C has been used for over 50 years.
The Rust language itself isnt that large of a problem, its more the implementation. The compiler / toolchain is a royal fucking pain in the ass to bootstrap. There is only one "rust", unlike C, which is a true language with multiple implementations. Rust is a full blown, in-housed ecosystem that is very complicated to move to new platforms. While there is complaints about legacy platforms not being supported, there is also issues with moving forward too. There have been countless issues with Rust compiler on ARM, and I can only imagine it getting worse as we move to other targets like RISC-V and beyond. Its "great" if you're already in the supported ecosystem (Intel CPUs), but anything else has been an absolute nightmare to support.
Well, that is a ton of exceptionally good reasons to not allow it in. I guess this will just be another meaningless stunt by the fans of a language that is not worth much at this time.
Rust is basically trying to be forced it's way into software projects that don't want it. It's like if someone wanted to put visual basic in the kernel. Any advantages are cancelled out by it's viral nature.
Just like wireguard as well. I remember a few years back on the dd-wrt forums shills from the wireguard community trying to cram that shit down the throats of dd-wrt and get it into the kernel there before they got it in the mainline kernel. Now those folks are trying to ram it down the throats of *BSD. Thankfully *BSD has pushed back calling the code experimental at best.
Just like wireguard as well. I remember a few years back on the dd-wrt forums shills from the wireguard community trying to cram that shit down the throats of dd-wrt and get it into the kernel there before they got it in the mainline kernel. Now those folks are trying to ram it down the throats of *BSD. Thankfully *BSD has pushed back calling the code experimental at best.
I am quite prepared to rewrite my software, currently in C, to use Rust. Its the best Lint facility that currently exists to help insure flawless code, particularly if you use malloc and free in complex environments.
If you do not use dynamic memory (alloc / free), then C is great as is, for development.
I can understand lauding the Rust linter, but slamming malloc / free? I *like* being in full control of memory allocation / deallocation, heck, I even use alloca in some places. There is nothing wrong with malloc / calloc / realloc or whatever flavor of heap allocation you prefer. Sure memory alignment can be a bit of a pain, but even Rust defers to alloc for that. People like to complain about C, but C does exactly what you write, nothing more If you blow off your foot, it's because you loaded the gun, aim
Looks like it. yes. Basically the people that know what they are doing are not seeing any of the claimed advantages of Rust. Hence they have to resort to "stunts" like this one. I will certainly never build parts of a kernel that are in Rust.
Clearly the single-implementation status is undesirable, don't you think? We've already had too many problems with languages defined by their implementations.
Pretty much all languages have been defined by their implementations at one time or another. Haskell used to have multiple implementations, but GHC became dominant. Languages that had a hard standard (like Scheme or ML) and multiple implementations, either never really went anywhere, or the bits that went anywhere left the standards behind (Ocaml for ML, Racket for Scheme).
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered over - as the GCC vs. LLVM issues mentioned in this post illustrate.
It easier to sell an idea that obsoletes on old one. The reality? LLVM implementations must/need to talk to GCC implementations...
"Derp! But all the security problems are from stoopid mistakes! They wouldn't be there if all the C coders had top 1% skill level!!!"
The string mistakes wouldn't be there if programmers used a better string library in C. This doesn't require top 1% skill level. The memory mistakes wouldn't be there if programmers used a better memory library in C. This also doesn't require a top 1% skill level.
It doesn't require a genius to avoid buffer overflows in C, it takes general competence. Although maybe most programmers these days don't have general competence.
That's well and good, and if I was forced to use C ever again, I'd use it if possible. (It still doesn't help with bounds checking, NULL dereferencing and other issues, though.)
However, much of the time people claim that one reason they're using C is because they can't tolerate the unpredictable pause times associated with GC.
Since C lacks any kind of automatic resource management, any "better library" still requires manual steps to do lifetime management. They do not solve the fundamental problem.
You are changing the topic. You were talking about security problems in C, and I gave you the solution. Then you changed the topic to resource management.
I think your problem is that you don't like C, which is fine, but it's not a problem for the rest of us.
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
Since you think they can, not only are you not a C wizard, but you're also dangerously incompetent. You should be restricted to coding in Java at the very most.
*Everyone* needs a language with "training wheels". Every single human being on this planet make mistakes.
Even if you use C, it is irresponsible to release a program of any importance without having at least run it through "training wheels" like Coverity and valgrind.
Some people are just too arrogant to realize this. That's one reason this world is saddled with such shitty computer security.
I can't believe how this got score 5,Insightful as it is so wrong.
By such definition, there are no competent programmers. All of us do mistakes once in a while. So, when some says that programmers need to be "competent" to program in C, they are talking about some fictitious nonexistent people. Following this thinking, you might be "competent" one minute and totally "incompetent" the next one.
I think overconfidence is a big evil and responsible for big part of software issues. Show me a "competent" programm
Just a word of advice: if you think you're competent enough to program in C, you probably aren't.
I both code and use software. As a result, I try, where possible (it's hard when most of GNU is written in it) to avoid stuff written in C, because I know it wasn't written by people who knew what they were doing.
C has its place. Hopefully not for much longer, however. I can't wait for someone to create a new Rust compiler that has a GCC back-end or something else that means it can support a ton of targets,
When someday there's a language that's as flexible, fast, and simple as C that makes my life easier I'll definitely look at it. Right now there's two choices for efficient system level programming, C and a subset of C++.
As for competency, C is a simple language. If you understand how CPUs function and how C code is turned into machine code there's not a lot of mystery there. I've be doing this stuff professionally for over 30 years, I'm pretty aware of the available pitfalls and footguns that C provide
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
And I gave you a way to deal with buffer overflows, and apparently you ignored it. Thus I can safely say that you're a troll, not someone who wants to learn.
And I gave you a way to deal with buffer overflows, and apparently you ignored it.
Did you? You just said to use a library. Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
I find it hard to believe, in the Stack Overflow/Github era, that there are people out there still wrangling their own strings if there's a commonly accepted "best" library for this kind of stuff. We still see tons of exploits of this nature.
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows, wit
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows,
ok, well it works for Java, so you need to think a little more to convince yourself. (Before you say something like, "Java has memory protection" think a little bit, because even without the memory protection, the Java string library API offers no chance to have a buffer overflow).
Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
Probably because most programmers are as crappy as you. Seriously, why don't you think a little bit before posting?
all you had to do was put a link to some library that provided any form of evidence for your claim, but you just thought you'd attack me instead - colour me surprised that someone with an attitude of "every other programmer is bad except for me" only resorts to personal attacks
(won't read any further comments from you on the issue)
But there's much more than that. The C specification as a whole is a vast minefield of gotchas and undefined behavior, well beyond just buffer management. It takes many years of experience to even be aware of most of them. How do people acquire such experience?
If you don't go out of your way to disable compiler warnings, you become aware of them the moment you attempt to compile code that would result in that behavior.
But no one is denying C has problems.
We are pointing out that your solution, replace C code written to the C specification with Rust code written to the Rust specification, isn't a solution at all. No Rust specification exists.
If you want us to change languages, you need to make sure your destination language at least exists, and at best exists and i
I do not think that C lacks bound checking. It simple does not require it. It is your C implementation which may lack bounds checking. But on GCC and clang you can get a run-time error for NULL pointer deference or bounds violation in the following example by using the right compiler flags. Instead of complaining about C as a language I would rather go to the compiler writers and request that those flags are made the default:
I do not think that C lacks bound checking. It simple does not require it. It is your C implementation which may lack bounds checking.
Since C11, the international standard for the C programming language has defined a few conditional features, such as variable-length arrays (VLAs) [wikipedia.org]. Implementations need not implement such features, but if they do, they must implement them with the specified syntax and the specified semantics. It sounds like you're making out array bounds checking to be such a conditional feature. So what's the syntax to enable it?
No, it is not an optional feature of the standard and it does not require new syntax. But a bounds violation is undefined behavior which simply means that the standard does not define semantics for it. So any compiler is free to add bounds checking. In the example above, GCC and clang will detect the out of bounds check at run-time when using certain compiler flags,.e.g. -fsanitize=undefined will cause the program to give a run-time instead of executing a out-of-bounds access. This works for both VLAs a
Hopefully slackware will avoid it as they've done with systemd thus far, but how long till all this shit get so ingrained into the kernel that you just can't make a distro without it any longer?
In context, I conclude that the following was meant:
If you administer Slackware on a desktop PC or server for a particular purpose, you're halfway towards being competent enough to administer FreeBSD for the same purpose. Why not give FreeBSD a try?
Just about every new language since C has been sold on the motto "..we don't need C anymore to do...Whatever...!", only to write code that must talk to a C running stack. Or even better some abstraction layer that separates the (app) developer from the dirty, cranky C register manipulation. You can technically "write" a driver in any language, especially one that is derived from C (most of em). Remember the *nix drivers exampled in C# in the beginning of it's deployment? I haven't been following the Rust
Can you possibly give a single good reason why someone would actually even know, let alone want to avoid, a version of the kernel that has some of the code written in Rust?
Because that's even worse ideological buffoonery than the bullshit whining about SystemD. At least you can kinda sorta make an argument that SystemD affects the end user if they want to stop and start services. But literally the only time you're going to know that, say, your Wifi stack was written in Rust is if you have to compile the
Gentoo user here. I compile all of my software from scratch, including the kernel, because Gentoo is a source-based distribution. So this does impact me. Build dependencies tend to be as tricky in my environment as runtime ones.
Having said that, I believe that the beginnings of what will likely be a decades-long effort to replace C and C++ are long overdue.
You need something low-level if you truly must directly manipulate memory or CPU registers or other hardware. Today that is almost always C or C++, b
Avoidance of software by distros is a choice by the distro developers. The fact is new languages are patched and incremented as fast as the platform they are expected to run on and almost write themselves. I like node.js as an example of this. It already having deno "the not node.js" example which is more like a fork. As far as distros not having a subsystem included, I'll have to ask why is it easier to fork a distro that fully supports a subsystem then "edit" the subsystem out than to just create your own
Rust needs a formal specification. Having a formal specification ensure that despite any future changes to the language that it will be possible to implement a compiler that can compile the code. A lot of work has been done to move toward standard C code (as well as supporting GNU C extensions in Clang) so adding code that relies on a single compiler with no formal specification would be a step in the wrong direction.
And even if it's "Whatever the compiler supports", it would be helpful for at the very least some attempt to be made to create a third party compiler. We have third party implementations of C# and Java, both arguably more complex languages. And if GNU GCC supports C++, it's highly improbable that it'd be hard to make a Rust implementation as part of the GCC suite.
The bigger problem is probably making something that fits in with the Rust infrastructure. The Rust people have insisted on control of
It also looks like inviting tool chain bloat to me. So far you need a C compiler to build the kernel, do we really need the extra dependency on a Rust compiler?
So how do you think they write the kernel if they don't use programming languages? The Linux Kernel is written in C but they have now opened up for new device drivers to be also written in Rust.
So how do you think they write the kernel if they don't use programming languages? The Linux Kernel is written in C but they have now opened up for new device drivers to be also written in Rust.
Why does the kernel need to be "opened up" to accept Rust programs? For the kernel these are just compiled binaries, why does it need to know what language it was written in?
Yes there is nothing stopping you from creating your own home-brew linker and Pascal compilter from achieving this but that is not the question that are being solved, what is being solved is the possibility to create a device driver in Rust and having that same driver being accepted upstream in the Linux kernel proper. This means that #1 the maintainers will accept that code (which they won't do with Pascal since they currently only accept code written in C and soon some new device drivers in Rust) and #2 t
Would that not be a task for the linker rather than for the compiler?
The compiler still needs to know the calling convention [wikipedia.org], meaning how to set up the stack and the registers when calling a function compiled by another compiler. Only code using compatible calling conventions can be linked together without some routine in the middle that acts as a shim to translate the calling convention. Historically, the popular Pascal compiler for a platform and the popular C compiler for the same platform have used different calling conventions.
What would stop you is the Pascal ABI is incompatible with C and there's no support in the kernel build system to compile it.
Indeed, in Pascal parameters are pushed on the stack in left-to-right order (and the callee cleans up the stack), while GCC uses right-to-left (and the caller cleans up the stack).
However, GCC supports several languages, perhaps I should have chosen gfortran as an example rather than Pascal (since the GNU Pascal front-end does not seem to be supported anymore).
Drivers needs to communicate with the internals of the kernel and until now those internals was only exported via C. For more in-depth see e.g https://lwn.net/Articles/82985... [lwn.net]
Yes, I know that, I have written an operating system in Z80 assembly, and I know 65xx, 68xx and ARM assembly languages, and also C and a bunch of other languages, but not Rust.
The kernel consists of binaries, why does it matter from which languages these binaries have been generated?
Because you need a pile of toolchain support if you add stuff built in a different language. Rust requires a pile of runtime support crap, too. It's nowhere near as lightweight as the C standard library.
Sorry, I misunderstood your question. When you said 'programming language in the kernel' I thought you were a layman who thought it was actually C in the kernel, not machine language.
Now I understand the question to be 'why does it matter from which language these binaries have been generated?' and I'll give my opinion (and it's just an opinion, not a definitive answer).
Mostly it's a question of maintenance and efficiency of the runtime. C is 'close to the metal', and you can have a pretty good idea of
Google sponsored some folks the other day to work on linux kernel security and one of them is working on llvm.
This makes sense where it's going.
Device drivers are the perfect place to start taking Rust. Hardware manufacturers are less likely to have security programming experts on hand but if they can make their hardware work with a Rust driver then people have less worry about including and shipping it. We get things like the iSCSI driver problem from the other day when we just build and include all
Peter: Let me ask you something. When you come in on Monday and you're programming in Rust, does anyone ever say to you, "Sounds like someone is a Rustacean?"
Lawrence: No. No, man. Shit, no, man. I believe you'd get your ass kicked sayin' something like that, man.
LOL, let me guess, you think the guy carrying around the Confederate flag is just celebrating his "heritage" and the guy with the swastika tattoo is just interested in promoting an open dialog!
You call someone racist when they point out femi-nazi hatred of men, and various black leaders and performers spewing white hate. You are something else.
Then you mention two random lowlifes, and make assumptions about how I feel about them as an argument?
You're pathetic and prove my point, you virtue signaling empty set.
If that even vaguely represented most feminists you might have a point. But "Feminazi" is some sort of bizarre assertion made by misogynists basically projecting their own insecurities and biases on to other people.
I really can't wait for another generation to see how history looks at the whole woke/cancel culture movement. Hopefully the next generation rebels against their "woke" parents generation the way most prior have.
Golang is trying to be a server language (or infrastructure language, since that's what people are calling servers these days). It does a good job of handling threads, and it has an efficient GC. Golang is trying to replace Java and C++ on the server.
So a database might be written in Golang, but not a kernel.
The database seems to be what most newer languages are optimized for. The server, any server it does not matter, is a feature? A convenient one to say the least...
I'm a bit worried about the ability of multinational consortiums to grow communities of users and developers around the projects that they govern. When one of those projects doesn't support certain less common use cases, often it's not only because there's less people who have the knownledge and disposition required to develop the necessary code, but also because the project maintainers are less likely to accept their contribution upstream. Also, they're less likely to allow their design choices to be put i
Ada/SPARK can do more than Rust. It is better than C++ in most instances. It could radically improve the reliability of Linux device drivers. It is also available as a commercial compiler as well as a GCC-based open source project. Memory protection is one aspect of Ada/SPARK. Range checking and other features make it ideal for operating systems and applications in general.
The big challenge these days is that Rust has mindshare. What is most surprising to me is how few Rust developers and users do not eve
Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."
What is that supposed to mean? What criteria are they thinking of applying? If the architecture is suitable to have a unix kernel on it, it might possibly end up interfaced with nearly any sort of hardware. This is a world where modern embedded microcontrollers exist that would easily kick an older desktop's ass. A world where someone made a retro C64 cartridge with an ethernet controller in it.
I've seen examples of the Linux kernel running on everything from a mainframe down to an SD card.
I'll address the parts about GitHub on the basis that obstacles to interaction with the rust-lang organization [github.com] are on-topic.
There's one part of your post that confuses me:
When logging into GitHub one day (2019), after discovering that my issues all returned "404 Not found" errors, and after being forced to enter a code sent via e-mail: "Your account has been flagged. Because of that, your profile is hidden from the public."
Probably a false alarm in GitHub's automatic spam detection. Mail GitHub support to find how to proceed. (Source: einpoklum's answer on Stack Exchange [stackexchange.com])
Recently, after Microsoft had bought GitHub, [...] they had locked me out with a message about having sent a "verification code" to the throwaway e-mail address I used when registering, obviously long since abandoned and inaccessible.
Then at what address did you receive "Your account has been flagged"? Sounds like a plot hole.
Apparently, having the right password is no longer enough to prove that you control an account.
You are correct that it isn't because of high-profile, large-scale password database breaches.
Tainting the kernel (Score:4, Funny)
I that what is called "tainting" the kernel?
Re: (Score:1)
"blessing" is the proper term
Re: (Score:1, Troll)
Re: (Score:2)
Rust is the new SystemD (Score:2, Informative)
Re: Rust is the new SystemD (Score:2)
Re: Rust is the new SystemD (Score:5, Insightful)
The Rust language itself isnt that large of a problem, its more the implementation. The compiler / toolchain is a royal fucking pain in the ass to bootstrap. There is only one "rust", unlike C, which is a true language with multiple implementations. Rust is a full blown, in-housed ecosystem that is very complicated to move to new platforms. While there is complaints about legacy platforms not being supported, there is also issues with moving forward too. There have been countless issues with Rust compiler on ARM, and I can only imagine it getting worse as we move to other targets like RISC-V and beyond. Its "great" if you're already in the supported ecosystem (Intel CPUs), but anything else has been an absolute nightmare to support.
Re: (Score:2)
Well, that is a ton of exceptionally good reasons to not allow it in. I guess this will just be another meaningless stunt by the fans of a language that is not worth much at this time.
Re: Rust is the new SystemD (Score:5, Informative)
Re: (Score:1)
Re: (Score:2)
Just like wireguard as well. I remember a few years back on the dd-wrt forums shills from the wireguard community trying to cram that shit down the throats of dd-wrt and get it into the kernel there before they got it in the mainline kernel. Now those folks are trying to ram it down the throats of *BSD. Thankfully *BSD has pushed back calling the code experimental at best.
I am quite prepared to rewrite my software, currently in C, to use Rust. Its the best Lint facility that currently exists to help insure flawless code, particularly if you use malloc and free in complex environments. If you do not use dynamic memory (alloc / free), then C is great as is, for development.
Re: (Score:2)
I can understand lauding the Rust linter, but slamming malloc / free? I *like* being in full control of memory allocation / deallocation, heck, I even use alloca in some places. There is nothing wrong with malloc / calloc / realloc or whatever flavor of heap allocation you prefer. Sure memory alignment can be a bit of a pain, but even Rust defers to alloc for that. People like to complain about C, but C does exactly what you write, nothing more If you blow off your foot, it's because you loaded the gun, aim
Re: (Score:3)
Looks like it. yes. Basically the people that know what they are doing are not seeing any of the claimed advantages of Rust. Hence they have to resort to "stunts" like this one. I will certainly never build parts of a kernel that are in Rust.
Re: Rust is the new SystemD (Score:2)
Re: (Score:2)
Re: (Score:2)
Pretty much all languages have been defined by their implementations at one time or another. Haskell used to have multiple implementations, but GHC became dominant. Languages that had a hard standard (like Scheme or ML) and multiple implementations, either never really went anywhere, or the bits that went anywhere left the standards behind (Ocaml for ML, Racket for Scheme).
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered
Re: (Score:1)
Wherever there's a standard that pretends to be independent of implementations, there's dialects and differences that need to be papered over - as the GCC vs. LLVM issues mentioned in this post illustrate.
It easier to sell an idea that obsoletes on old one. The reality? LLVM implementations must/need to talk to GCC implementations...
Re: (Score:2)
There is a reason why good old C has been used for over 50 years.
And the reason is that somebody has to provide job security for all the security hackers with hats of various colors.
"Derp! But all the security problems are from stoopid mistakes! They wouldn't be there if all the C coders had top 1% skill level!!!"
Math fail.
Re:Rust is the new SystemD (Score:5, Insightful)
"Derp! But all the security problems are from stoopid mistakes! They wouldn't be there if all the C coders had top 1% skill level!!!"
The string mistakes wouldn't be there if programmers used a better string library in C. This doesn't require top 1% skill level.
The memory mistakes wouldn't be there if programmers used a better memory library in C. This also doesn't require a top 1% skill level.
It doesn't require a genius to avoid buffer overflows in C, it takes general competence. Although maybe most programmers these days don't have general competence.
Re: (Score:3)
Re: (Score:2)
That's well and good, and if I was forced to use C ever again, I'd use it if possible. (It still doesn't help with bounds checking, NULL dereferencing and other issues, though.)
However, much of the time people claim that one reason they're using C is because they can't tolerate the unpredictable pause times associated with GC.
Re: (Score:3)
"Since C lacks any kind of automatic resource management" - Here you go: https://www.hboehm.info/gc/ [hboehm.info]
Please, please, ask Linus to include the Boehm garbage collector as an underpinning of the Linux kernel. I just want to read his response :)
Re:Rust is the new SystemD (Score:4, Informative)
Since C lacks any kind of automatic resource management, any "better library" still requires manual steps to do lifetime management. They do not solve the fundamental problem.
You are changing the topic. You were talking about security problems in C, and I gave you the solution. Then you changed the topic to resource management.
I think your problem is that you don't like C, which is fine, but it's not a problem for the rest of us.
Re: (Score:2)
Resource management IS security management in C. Haven't you ever heard of a dangling pointer?
You're not as much as a C wizard as you think you are.
Re: (Score:2)
You're not as much as a C wizard as you think you are.
I'm not a C wizard, I just know how to use libraries. If you have trouble with that, you must be really, really bad.
Re: (Score:2)
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
Since you think they can, not only are you not a C wizard, but you're also dangerously incompetent. You should be restricted to coding in Java at the very most.
Re:Rust is the new SystemD (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
*Everyone* needs a language with "training wheels". Every single human being on this planet make mistakes.
Even if you use C, it is irresponsible to release a program of any importance without having at least run it through "training wheels" like Coverity and valgrind.
Some people are just too arrogant to realize this. That's one reason this world is saddled with such shitty computer security.
Re: (Score:2)
C is the language for people who value lines of code.
Personally I prefer a language where I can automate the tooling, so I don't have to keep manually doing all the tedious, repetitive parts.
Re: (Score:2)
I can't believe how this got score 5,Insightful as it is so wrong.
By such definition, there are no competent programmers. All of us do mistakes once in a while. So, when some says that programmers need to be "competent" to program in C, they are talking about some fictitious nonexistent people. Following this thinking, you might be "competent" one minute and totally "incompetent" the next one.
I think overconfidence is a big evil and responsible for big part of software issues. Show me a "competent" programm
Re: (Score:2)
Just a word of advice: if you think you're competent enough to program in C, you probably aren't.
I both code and use software. As a result, I try, where possible (it's hard when most of GNU is written in it) to avoid stuff written in C, because I know it wasn't written by people who knew what they were doing.
C has its place. Hopefully not for much longer, however. I can't wait for someone to create a new Rust compiler that has a GCC back-end or something else that means it can support a ton of targets,
Re: (Score:2)
As for competency, C is a simple language. If you understand how CPUs function and how C code is turned into machine code there's not a lot of mystery there. I've be doing this stuff professionally for over 30 years, I'm pretty aware of the available pitfalls and footguns that C provide
Re: (Score:2)
As I've already pointed out, libraries cannot begin to fix all of the security problems with C, including buffer overflows.
And I gave you a way to deal with buffer overflows, and apparently you ignored it. Thus I can safely say that you're a troll, not someone who wants to learn.
Re: (Score:2)
Man, are you dense.
For the fifth time, your purported solution IS NOT SUFFICIENT TO DEAL WITH BUFFER OVERFLOWS.
Re: (Score:2)
And I gave you a way to deal with buffer overflows, and apparently you ignored it.
Did you? You just said to use a library. Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
I find it hard to believe, in the Stack Overflow/Github era, that there are people out there still wrangling their own strings if there's a commonly accepted "best" library for this kind of stuff. We still see tons of exploits of this nature.
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows, wit
Re: (Score:2)
So I'm not convinced "use a library" is enough of an explanation about how to deal with buffer overflows,
ok, well it works for Java, so you need to think a little more to convince yourself. (Before you say something like, "Java has memory protection" think a little bit, because even without the memory protection, the Java string library API offers no chance to have a buffer overflow).
Are there general purpose string libraries that are Good Enough for all use cases? If so, why aren't they in common use?
Probably because most programmers are as crappy as you. Seriously, why don't you think a little bit before posting?
Re: (Score:2)
For the fifth time, your purported solution IS NOT SUFFICIENT TO DEAL WITH BUFFER OVERFLOWS.
It is. There is an easy way to tell that I'm right here: the content of your post has devolved into yelling. You have no logical argument left.
Re: (Score:2)
all you had to do was put a link to some library that provided any form of evidence for your claim, but you just thought you'd attack me instead - colour me surprised that someone with an attitude of "every other programmer is bad except for me" only resorts to personal attacks
(won't read any further comments from you on the issue)
Re: (Score:1)
But there's much more than that. The C specification as a whole is a vast minefield of gotchas and undefined behavior, well beyond just buffer management. It takes many years of experience to even be aware of most of them. How do people acquire such experience?
If you don't go out of your way to disable compiler warnings, you become aware of them the moment you attempt to compile code that would result in that behavior.
But no one is denying C has problems.
We are pointing out that your solution, replace C code written to the C specification with Rust code written to the Rust specification, isn't a solution at all.
No Rust specification exists.
If you want us to change languages, you need to make sure your destination language at least exists, and at best exists and i
Re:Rust is the new SystemD (Score:4, Insightful)
Since C lacks any kind of automatic resource management,
Here is a hint: In an OS kernel that is exactly how you need it to be. Applications are a different matter.
Re: (Score:2)
void foo(int N, double (*a)[N])
{
(a*)[N] = 1;
Conditional features in C (Score:2)
I do not think that C lacks bound checking. It simple does not require it. It is your C implementation which may lack bounds checking.
Since C11, the international standard for the C programming language has defined a few conditional features, such as variable-length arrays (VLAs) [wikipedia.org]. Implementations need not implement such features, but if they do, they must implement them with the specified syntax and the specified semantics. It sounds like you're making out array bounds checking to be such a conditional feature. So what's the syntax to enable it?
Re: (Score:2)
No, it is not an optional feature of the standard and it does not require new syntax. But a bounds violation is undefined behavior which simply means that the standard does not define semantics for it. So any compiler is free to add bounds checking. In the example above, GCC and clang will detect the out of bounds check at run-time when using certain compiler flags, .e.g. -fsanitize=undefined will cause the program to give a run-time instead of executing a out-of-bounds access. This works for both VLAs a
Re: (Score:2)
Now there's an idea. Do systemd in Rust.
Once you get that working, come back and we'll give you another piece to play with.
Re: (Score:1)
Re: (Score:1)
If you're running Slackware, you're halfway towards being competent enough to run a BSD system. I like Slack, but why not make the leap?
Re: (Score:1)
If you're running Slackware, you're halfway towards being competent enough to run a BSD system. I like Slack, but why not make the leap?
Running BSD to do what? You will have to be more specific.
Re: (Score:2)
In context, I conclude that the following was meant:
If you administer Slackware on a desktop PC or server for a particular purpose, you're halfway towards being competent enough to administer FreeBSD for the same purpose. Why not give FreeBSD a try?
Re: (Score:2)
Cause *BSD are years behind Linux on any metric. And their code quality generally sucks.
Re: (Score:2)
Re: (Score:2)
Can you possibly give a single good reason why someone would actually even know, let alone want to avoid, a version of the kernel that has some of the code written in Rust?
Because that's even worse ideological buffoonery than the bullshit whining about SystemD. At least you can kinda sorta make an argument that SystemD affects the end user if they want to stop and start services. But literally the only time you're going to know that, say, your Wifi stack was written in Rust is if you have to compile the
Re: (Score:2)
Gentoo user here. I compile all of my software from scratch, including the kernel, because Gentoo is a source-based distribution. So this does impact me. Build dependencies tend to be as tricky in my environment as runtime ones.
Having said that, I believe that the beginnings of what will likely be a decades-long effort to replace C and C++ are long overdue.
You need something low-level if you truly must directly manipulate memory or CPU registers or other hardware. Today that is almost always C or C++, b
Re: (Score:1)
One real step needed: (Score:5, Insightful)
Rust needs a formal specification. Having a formal specification ensure that despite any future changes to the language that it will be possible to implement a compiler that can compile the code. A lot of work has been done to move toward standard C code (as well as supporting GNU C extensions in Clang) so adding code that relies on a single compiler with no formal specification would be a step in the wrong direction.
Re: (Score:2)
Agree.
And even if it's "Whatever the compiler supports", it would be helpful for at the very least some attempt to be made to create a third party compiler. We have third party implementations of C# and Java, both arguably more complex languages. And if GNU GCC supports C++, it's highly improbable that it'd be hard to make a Rust implementation as part of the GCC suite.
The bigger problem is probably making something that fits in with the Rust infrastructure. The Rust people have insisted on control of
Re: (Score:1)
It also looks like inviting tool chain bloat to me. So far you need a C compiler to build the kernel, do we really need the extra dependency on a Rust compiler?
Re: (Score:1)
Bloat is the word. I just lost 4 hrs of my life watching rust build under llvm on BSD. All because I wanted a new version of Firefox.
This machine is not especially small or slow (4 cores, 64 bits, 8 gigs, 3 GHz...) But it reminds me of trying to compile Open Office on a 486.
Holy shit I miss 20 yrs ago when you could configure *everything* on a RH box in minutes with plain text, some bash and C. (OK, maybe sed and awk)
Programming language in OS kernel? (Score:1)
Is this only Rust, or do we already have other programming languages on the inside of the Linux kernel?
Re: (Score:2)
Re: (Score:2)
So how do you think they write the kernel if they don't use programming languages? The Linux Kernel is written in C but they have now opened up for new device drivers to be also written in Rust.
Why does the kernel need to be "opened up" to accept Rust programs? For the kernel these are just compiled binaries, why does it need to know what language it was written in?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
even if you managed to make Pascal bind to C
Would that not be a task for the linker rather than for the compiler?
And every single attempt to merge Pascal code would be rejected by the kernel maintainers
Of course, but that is a management issue.
(I'm not trying to be obnoxious, these are genuine questions and I appreciate the answer you and others have given.)
Re: (Score:2)
Yes there is nothing stopping you from creating your own home-brew linker and Pascal compilter from achieving this but that is not the question that are being solved, what is being solved is the possibility to create a device driver in Rust and having that same driver being accepted upstream in the Linux kernel proper. This means that #1 the maintainers will accept that code (which they won't do with Pascal since they currently only accept code written in C and soon some new device drivers in Rust) and #2 t
Calling convention (Score:2)
even if you managed to make Pascal bind to C
Would that not be a task for the linker rather than for the compiler?
The compiler still needs to know the calling convention [wikipedia.org], meaning how to set up the stack and the registers when calling a function compiled by another compiler. Only code using compatible calling conventions can be linked together without some routine in the middle that acts as a shim to translate the calling convention. Historically, the popular Pascal compiler for a platform and the popular C compiler for the same platform have used different calling conventions.
Re: (Score:2)
What would stop you is the Pascal ABI is incompatible with C and there's no support in the kernel build system to compile it.
Indeed, in Pascal parameters are pushed on the stack in left-to-right order (and the callee cleans up the stack), while GCC uses right-to-left (and the caller cleans up the stack).
However, GCC supports several languages, perhaps I should have chosen gfortran as an example rather than Pascal (since the GNU Pascal front-end does not seem to be supported anymore).
Re: (Score:3)
Re: (Score:2)
The kernel consists of binaries, why does it matter from which languages these binaries have been generated?
Re: (Score:3)
Because you need a pile of toolchain support if you add stuff built in a different language. Rust requires a pile of runtime support crap, too. It's nowhere near as lightweight as the C standard library.
Re: (Score:1)
Sorry, I misunderstood your question. When you said 'programming language in the kernel' I thought you were a layman who thought it was actually C in the kernel, not machine language.
Now I understand the question to be 'why does it matter from which language these binaries have been generated?' and I'll give my opinion (and it's just an opinion, not a definitive answer).
Mostly it's a question of maintenance and efficiency of the runtime. C is 'close to the metal', and you can have a pretty good idea of
Re: (Score:2)
Rustaceans? (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
What should one call them? Rustics maybe? If somebody writes a combination of C and Rust are they Crustaceans?
Re: (Score:3)
Re: (Score:2)
I wish I had the other Funny mod point for you.
Ah, the Google news makes sense (Score:2)
Rustacean (Score:3, Funny)
Rust's big problem (Score:1)
Re: (Score:1)
Yes, what a tragedy you can't be a racist mysoginistic fay-bashing asshole on their forums.
Re: (Score:1)
The woke people by far are the real racists and misandrists, making scapegoats in denial of their own failings as humans.
Re: (Score:2)
LOL, let me guess, you think the guy carrying around the Confederate flag is just celebrating his "heritage" and the guy with the swastika tattoo is just interested in promoting an open dialog!
You racist shit-bags are something else.
Re: (Score:1)
You call someone racist when they point out femi-nazi hatred of men, and various black leaders and performers spewing white hate. You are something else.
Then you mention two random lowlifes, and make assumptions about how I feel about them as an argument?
You're pathetic and prove my point, you virtue signaling empty set.
Re: (Score:2)
If I were playing right-wing racist shitbag bingo, I'd have a coverall.
Fuck off and die, racist shitbag!
Re: (Score:1)
Look at you spewing hate and accusations of racism like a smokescreen, to cover up your lack of rational thought.
Re: (Score:2)
I really don't care what a racist shit bag thinks about me. The world will be a better place once your kind is eradicated.
Go on, now, fuck off and die like a good shit bag racist.
Re: (Score:1)
you're the one spewing rabid hatred, a typical woke snowflake triggered, can't handle reality.
Re: (Score:2)
If that even vaguely represented most feminists you might have a point. But "Feminazi" is some sort of bizarre assertion made by misogynists basically projecting their own insecurities and biases on to other people.
Re: (Score:1)
Shouldn't we wait (Score:1)
What about GOlang? (Score:1)
Re: (Score:1)
Re: (Score:2)
Golang is trying to be a server language (or infrastructure language, since that's what people are calling servers these days). It does a good job of handling threads, and it has an efficient GC. Golang is trying to replace Java and C++ on the server.
So a database might be written in Golang, but not a kernel.
Re: (Score:1)
I'm a bit paranoid (Score:1)
Ada/SPARK would be a much better choice (Score:1)
Be more specific (Score:2)
Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."
What is that supposed to mean? What criteria are they thinking of applying? If the architecture is suitable to have a unix kernel on it, it might possibly end up interfaced with nearly any sort of hardware. This is a world where modern embedded microcontrollers exist that would easily kick an older desktop's ass. A world where someone made a retro C64 cartridge with an ethernet controller in it.
I've seen examples of the Linux kernel running on everything from a mainframe down to an SD card.
GitHub plot hole (Score:2)
I'll address the parts about GitHub on the basis that obstacles to interaction with the rust-lang organization [github.com] are on-topic.
There's one part of your post that confuses me:
When logging into GitHub one day (2019), after discovering that my issues all returned "404 Not found" errors, and after being forced to enter a code sent via e-mail: "Your account has been flagged. Because of that, your profile is hidden from the public."
Probably a false alarm in GitHub's automatic spam detection. Mail GitHub support to find how to proceed. (Source: einpoklum's answer on Stack Exchange [stackexchange.com])
Recently, after Microsoft had bought GitHub, [...] they had locked me out with a message about having sent a "verification code" to the throwaway e-mail address I used when registering, obviously long since abandoned and inaccessible.
Then at what address did you receive "Your account has been flagged"? Sounds like a plot hole.
Apparently, having the right password is no longer enough to prove that you control an account.
You are correct that it isn't because of high-profile, large-scale password database breaches.