MISS SPOKE: Emacs never charged and I couldn't find the source in which I originally learned this which means I made it up from the cockles of my heart You are welcome and subscribe to me on twitch
As someone from those times, the wars were more substantive then. Machines had very limited memory and disk. vi would start up instantly and was wicked fast, but you only had access to one file at a time, practically no customization, and yeah, modal editing. vi was a huge leap beyond ed, sed, and friends, but not much. Emacs on the other hand was a luxuriant fully customizable and infinitely extensible editor in lisp, but it was a hog of memory and disk, and took forever to start up (relative to vi), and the key bindings were byzantine. Nowadays, both editors are essentially equivalent and the argument is just about the extension language or modal editing. To get the feeling of the old wars, imagine comparing nano to vim ;)
@@liegonPeter here to explain the logic: The type is AbstractChaosFactoryProviderSingleton. This means that the class instance is a singleton and provider of AbstractChaosFactories, which is perfectly valid. Abstract factories do unfortunately exist in the real world.
@@BeatsByYariand to break it down a little more. The provider would be a class most likely passed in as a parameter for dependency injection. Then the class would call the provider (singleton in this case) and create an AbstractChaosFactory. So a factory pattern is used to create many instances of something usually with varying parameters. At this point the class would most likely generate many forms of chaos cast from the abstract base class for chaos. Thusly you have a enterprise scale system capable of many types of chaos and chaos producers.
I've been worried for years about Linux burning to the ground after he dies. He rules with an iron fist, and Linux has been wonderful for me for 18 years now.
@@NGC1433dude, seriously? Maintainer has strong opinions about shit getting in _his_ code base and you have the gall to suggest sarcasm. Go take a long walk off a short pier.
I rather get the feeling Prime either is religious or really doesn't want to offend religious people. In Scandinavia (and much of the rest of the Western world) people see religion for what it is: thinly veiled dogmatism.
@@stysner4580 He is pretty religious, from time to time he talks about it on stream. > In scandinavia I guess it depends on the location, from my experience of living in Oslo for a couple years, I would say that norwegians are still pretty religious as a group.
Philosophy is dogmatic. Take one look at the political world, which is all philosophy. Bombs are dropping right now on real people over dogma between old soviet states.
@@stysner4580 "The fool has said in his heart, there is no God." Yes, that's dogmatic, but there is a sense of dogmatism that has to exist. Either God exists or He doesn't. No need to veil it.
BSD was locked into legal issues during the early 90s, UNIX was expensive and GNU Herd wasn’t ready. Linux was created during a very special five year window and it could not have succeeded five years earlier since GNU wasn’t ready yet and it would have been hard for Linux 0.1 to compete with mature BSD in the late 90s. I also think that Stallman’s philosophy was an inspiration for many young developers.
Visual Basic should be used! No type problems there! It won't accept anything bad. If you type the smallest error it gives you POP-UP errors! THAT IS BETTER THAN RUST! Have YOU seen popup-windows in Rust? I didn't think so. Therfore Visual Basic it is!
@@PalladinPoker Sure it sounds bad if you put a negative spin on it. But that goes with rust too. If you omit ANY letter in that declaration you'll get a pop-up error message! Type safety right there, and right in your face. visual basic FORCES you to acknowledge your error by you having to press the "OK" button. The vb editor also refuse to save the file before it is corrected. How in the world could an error be introduced into such a system?
I don't like the idea that C is "easy to learn". It's like saying learning to drive is easy, when what you really mean is "learning how to operate a car is easy". Like yeah, learning the absolute trivial basics of how to operate the thing IS easy, but learning how to do it safely and efficiently is most certainly not. Learning Rust is , I guess, like learning to fly: it's much harder initially, it enforces much stricter safety, and you just plain aren't allowed to do certain things or you won't even be allowed off the ground, and as a result it has a much better safety record.
Learning to program is hard. Full stop. And speaking as someone who has been programming for 40 years (yes I started when I was 10), the language is NOT what makes programming hard. It is understanding the complexity of the interfaces. Rust basically plays keep-away with everything. It's not like learning to fly is to learning to drive. It's like calling an Uber is to learning to drive.
The analogy seems better the other way around. Rust forces you to stay on the ground in order to ensure that you will be safe (e.g. not fall out of the sky). C just lets you do whatever you want, including taking to the skies. It's on you if you pancake yourself.
@@stysner4580 no its limited, so at anypoint you want to do something other than a calculator you suddenly are missing 80% of other programming languages. learning basics + doing some elementary projects isnt learning a language, that takes years, the fact that its so barebones makes it very hard to really get good at building stuff actually useful
The point of C is 'just enough abstraction of assembly languages'. I would say, C is DSL which generates assembly codes. Some people like driving MT cars while others like AT cars and that is what it is.
That doesn't bode well for C. There was a time when there were still advantages to a MT. But now, the AT is better in every way. MT exists purely for nostalgia reasons.
Kernel developers being protective and gatekeeping is good for the stability and quality of linux. They should be very skeptical and careful with everything. Linux is a core component of modern civilization.
@@CommanderRiker0They won't create their project for the same reason that rewrites of the applications don't work - the project is already mature and it is impossible to write something that will fully replace it and keep working on the original kernel. You might not like Rust but let's not get stupid - refactors are good even if they are painful
@@rmidifferent8906 Lets not get stupid while suggesting mixing two languages into the kernel. Adding complexity is for idiots. Seems like a skill issue is why we don't have a rust kernel.
you should watch what linus said from the source video when its available, reading it from someone else's words gives different interpretation to the intention behind his words.
@@tinrab C is a programming language. Rust is a damn cult. Google: Useful software written Rust. The answer: a pile of web frameworks in the Alpha stage, rewrites of simple Unix utilities (badly) and numerical analysis tools that could have just as easily been written in NumPy or Fortan. Honestly there is more justification of Python or Tcl to have a dedicated kernel module. But they don't need it because they can actually just USE the existing C APIS. Rust is a special case because the design is so broken that the ONLY way to write a potentially useful application is if your entire ecosystem is written in Rust. (And this why when you point out to a Rust Zealot that nothing of any consequence is currently written in Rust will state that "Well once we have a Rust OS..." See. It's a cult.)
I would not really say its not unhealthy discusion, sometimes you need to not think about someones feelings, but you need to dish reality check. He is a guy who manage one of the biggest projects with tons of people involved and if he does let everyone do whatever they want, you will end up with disaster. I do not envy Linus.
I like how the article mistepresented Linus but you corrected it with hos actual position without watching his full response. If only everybody had BS filter like Prime.
Miguel Ojeda did not abandon the Rust for Linux project; it was Wedson Almeida Filho. The article is incorrect. I don't know how you can confuse the names; one is Spanish and the other is Brazilian...
I work on the Tcl core. There is/was a movement to shift development to Rust from C. The issue is that the Rust people who are insisting on that change only want to dick around with memory allocators and such. When confronted with hardware interfaces, external APIs, network communications, etc. they just throw up their hands and say "Oh that's a YOU problem." As if somehow a general purpose scripting language's only job is to allocate memory and not, like INTERFACE with anything.
I find that interesting considering there is not even a standard for using different mem allocators in the Rust standard library, it has been in development for ages. It seems more like Rust people don't care about memory allocations, perhaps the story is totally flipped on the side of #[no_std]
Internal structure is where Rust works best anyway. You say dick around, but they probably just assumed a C interface with the outside world would be best to leave as-is until they fixed most of the other issues in the internals. Dealing with accidentally breaking external interfaces while you still have bugs/issues stemming from a rewrite in the core is not good.
@@stysner4580 Yeah, and they picked the least compatible 'core feature', so much so they're willing to compromise it's CORE functionality in order to do it. Sounds lazy to me.... C devs, got a great language, c, and built an OS out of it. Rust devs got a great language, and is trying to inseminate itself into every possible crevice it can. Correct me if I'm wrong, but did c try to tack onto pascal, or fortran to force some unfitting adaptation?
Seems to me that the Vi vs Emacs debate is totally different to the C vs Rust debate. In the first case every developer can use whatever editor he likes and it has no effect on any other developer. In the later case if a project adopts a new language then likely everyone has to invest much time and effort into mastering that new language. Worst still they end up having to deal with two languages all the time. I can understand why many have resistance to the demands a new language makes on them
Also since was was emacs the "big paid editor" ?? I don't think that's true at all, I think they have different licenses but I don't think emacs was ever anything more than just stallmans experiments with a lisp compiler, not a big corporate editor VScode
Watched the interview with Linus and he made a very important point: C in the Linux kernel is not standard C. It has a lot of memory safe code inside, that's (for my understanding) the reason, why he don't' want to force another language.
kernel C is not standard C, but it does not have memory safety built into the language. He said that they've worked to implement memory safety into the kernel, but it's almost impossible to guarantee it with any form of C. Additionally, Linus actively encourages development of Rust in the kernel as he doesn't want the kernel to stay stagnant with C (less and less developers are learning C as time goes on) and sees Rust as the language that most benefits the kernel if it works out due to the memory safety.... which again, Kernel C does not have.
Any example? Like meaningful one? An example of meaningful interface footgun would be struggling to effectively perform a formally called LendingIterator with the std Iterator trait. Spoilers: You can't; because the std iterator is meant to return owned values. Now, if you don't get to learn this limitation to std's Iterator trait, then you might spend hours self-hating yourself for not being able to do a simple Iterator Implementation, when the interface itself wasn't designed to behave like what you were expecting.
Using C a lot of knowledge is in the heads of developers. Rust sees this reliance on implicit knowledge as a problem and tries to embed a lot of this directly in the type system. To do this, devs not using Rust need to "externalize" some of this knowledge so that the Rust maintainers can build good Rust abstractions. Even if the C maintainers don't have to use Rust, they have to do new things that they didn't have to do earlier to satisfy the builders of the Rust type system. Some of them do not like this.
@@CommanderRiker0Yeah, after all a fully functioning kernel is something that a few guys should be able to build in a few afternoons. That's why we have so many open source kernels to choose from after all. They spring up like js frameworks
@@CommanderRiker0 Linus also suggested someone should write pure Rust kernel, and there are some, for example Redox. But the reason of introducing Rust into Linux is Linus belive the kernel may stagnate if they always doing things the same way and Rust is something that's significantly different and offers clear benifites if it works out. Also it's called an experiment for good reasons.
Sometimes mean is necessary to keep the more foolish among us from ruining it for everyone (including themselves). Note: we're all that foolish guy sometimes.
@@hungrymusicwolfare you kidding? His behaviour is completely unnecessary. If somebody bothers you just ban/block them and offer reasonable explanation..or don't. But don't act unhinged. People like you enable low moral character.
„C Developers will not just turn around and learn Rust“ but nobody is asking them to… they are asked just to talk with the people that can write Rust so the C parts and the rust parts can better work together.
That's not true. What you change, as a C programmer, abstraction on FS subsystem you need to go and ensure all places work as expected. And if the same parts are written in different languages you need to learn a new prg lang because you need to repair all the places not only the C related...
I try to get back into Rust once in a while and I drop it every time. I hate semantic bureaucracy for stuff that is simple, but Rust doesn't think it is.
@@stysner4580 this is what i think every time c programmres complain about the borrow checker & lifetimes, their code must be full of bugs if that's their gripe with rust
Zig isn’t a better choice, it’s not different enough from C. There isn’t much benefit from switching, such a big project needs a real good reason to switch to a new language.
The point for Zig that was made is that it ISN'T a direct change at all. You add in some new optional features and QoL. But you don't have to use it if you don't want to.
The problem is just like what you said, it's not a disadvantage. You don't actually need a different language, what you need is a modern C, better C. It's still the kernel world
I think one of the things that was missed on the German strings part that nobody else mentioned is that, yes, Rust makes you write more code to achieve the same "effect". But what the Rust code does by nature of you needing to write it out, and the C code almost certainly doesn't, is that you make explicit your design and assumptions. It's not truly 100 lines of Rust vs. 20 lines of C, it's that with 70 lines of explanations in C on top.
I've always understood Zig as the modern C and Rust as the modern C++ so I was super surprised when they announced they were allowing Rust in the kernel
Rust bros wanna C wizards to maintain their code. It's Microsoft's inside job to hijack Linux. Tbh Linux doesn't need rust but rust devs need some reason to exist since there's no real world rust jobs.
The behavior is defined already, you just have to read the C and possibly related parts of processor specs at worst. I think some of the Rust developers are just getting tired of reading and/or having skill issues. So they are demanding (the rust communities version of asking) that the kernel devs document it for them. The kernel devs don't want to because they don't want the constraints to be written in stone (the rust type system) and break the whole rust side every time they want to make a small change.
Whether Rust or not, it was a damn moronic decision to bring another language into the kernel. Mixing languages on a project is always a terrible idea, so yes this will fail.
Bindings are nothing new, and Rust can interface with C fairly easily. The only thing is that the developer writing the bindings needs to know both what is needed on the Rust side and the C side. And when the kernel is undocumented kernel-C (special variant of C with extra shit) that has like, 25 layers of abstraction functions before you actually see what something does... sometimes you gotta just ask somebody who knows what it does first before wasting time working it out for yourself.
No it's actually not which is why the rust developers are having issues. The only solid boundaries that exist are at userspace. Those are the only sacred boundaries. Everything else is up to be restructured as necessary. I think this is at its core why the rust developers are having so much issue. The language almost requires an unchanging set of interfaces to build upon but the kernel is always changing internally by necessity.
@@greg_land I don't understand this point. Maybe rust developers want some additional guarantees. Because I am sure that right now they also have some dependencies because in the end of the days all components need to interact somehow and communicate with each other. They can't be totally independent from each other or some kernel interfaces
@@greg_land You... literally just described the messiest system ever immediately after saying the kernel is not messy lmao. And you act like Rust can't be "fluid". The issue isn't Rust types or "hard boundaries", the issue is simply that the existing Kernel C code is hard as hell to parse manually if you're not familiar with it. Normally maintainers help people by explaining what each function does. They refuse to do that with the Rust devs, forcing the rust devs to manually parse it to write the bindings. Bindings against C code are fairly easy to write and maintain, as long as you know what data the C functions expects/returns. Keeping the bindings up to date would be trivial if the C code was documented.
Hey @ThePrimeTimeagen the article is misleading. Who left the Rust for Linux project and talked about "The Nontechnical Nonsense" was Wedson Almeida Filho (an MS engineer) but not Miguel Ojeda.
I know Rust CAN be used to program at the Kernel level but with it's verbose and arcane syntax, it's actually muddying the waters of the kernel! The benefit of C is it's barely above assembly. Keeping the abstraction small. With Rust you're abstracting too far away from the inherent danger of the kernel and adding millions of places for all kinds of problems. Maybe if Linux was built with Rust from the beginning we'd have a different story but trying to mix languages that are almost on opposite ends of the paradigm spectrum together just sounds like problems waiting to happen!
You really should learn a bit of Rust before you comment. C is great, and Kernel C (it's own variant) is even better. But Rust is nothing like what you just said. To begin with, Rust syntax is verbose, but not "arcane". In fact, it's verbosity is specifically there so that you're never confused as to what the code is doing at any point in time. Additionally, Rust doesn't have any sense of "abstraction" over C, other than not having to allocate or free your memory manually. Almost all Rust safety features happen at compile-time checking of your code, not runtime abstractions unlike something like Go with it's garbage collector. Additionally, bindings (especially against a language like C) are pretty standard things and fairly easy to maintain, as long as the functions on either side of the interface are well documented. The only issue here is that the Kernel C code is hard to read, has many layers of abstraction, and are not documented. If any of those 3 things were different, we wouldn't be hearing anything about this issue because it wouldn't be an issue.
...You do understand that kernel code doesn't use plain C though, right? There are a LOT of specific abstractions that are not compile time checks in Linux kernel code. Maintaining all of that and keeping the learning curve small is almost impossible. Maybe that's why Torvalds likes the idea of Rust in the kernel in the first place.
"arcane syntax" ? You feeling okay? Feeling a little blue pilled by Null and memory safety are we. Tony Hoare said it perfectly: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
There is one single reason why I dont want to program in rust. One single reason. And I am stubborn, and this might be stupid. But Rust is horrendously ugly. Only Visual Basic and MATLAB are more ugly, lol. Ill just wait until another language has the feautures Rust has. Btw, what about c3 lang?
Sorry, but "I still make memory problems in rust" as an argument for C is nothing but logical fallacy. You can still die in a car accident if you're wearing a seat belt, so let's ditch those, right?
You have missed the point. The Rust people want the C people to provide precise definitions for the function calls. The C people don't want to do that. I think that the Rust people are right. It's not about whether C is better than Rust.
RE: Linux competitor written in Rust taking over from Linux, no. Language a program is written in has virtually no impact on popularity. For something to overtake Linux, it needs to be better, and not just by a little, there is a threshold that is higher than "actually more for purpose", since there is a yuuuge amount of work to replace OSes, especially for early adopters that basically have to build supporting software as well.
Important correction. BSD Unix was open source/free before Linux, BUT it was mired in legal battles for a while. AT&T Unix and derivatives were not free and were not open source. Early in my career commercial Unix (Solaris, IRIX, AIX, HP-UX) dominated the landscape in the semiconductor industry and Linux didn't start to replace them until around 2005 or so.
I recommend you simply watch the interview. Linus very politely and calmly made the point that the "memory safety in Rust" versus "Unsafe C in the kernel" debate is a red herring because, as he pointed out, the "C" in the kernel is not the vanilla "C" you usually think of. The "C" in the kernel has been enhanced - especially re memory safety - in decades of work and experience so it's much "memory safer" than the vanilla C because - believe it or not - no kernel developer wants to hunt down ominous memory bugs (even though the Rust community almost gives that impression). Additionally, as Linus pointed out, the kernel gets tested very thorougly in debug builds running with tools like - for instance - Vaögrind that make the claim that the "C" in the kernel is "memory unsafe" not true. There goes your one argument for Rust.
Oh is that why we see breaches all the time?! Maybe think about why Torvalds allowed Rust in the kernel. Maybe he realized maintaining all this stuff that is still wildly unsafe under the hood isn't worth it.
I think Linus is right, it's religious undertones, not philosophical like you said. When discussions heat up and lower passions toss aside rationality, you can't have argumetns, it's just a battle of believes. And thats religious fanatism in a nutshell
For the german string example, the compiler proves more than half of the properties the implementer claims. He can alternatively malloc a Box and just transmute it to whatever he wants, which would be equivalent to what you would do in C, but the compiler would not prove anything about it.
I love Linus. Not only is he super honest and direct. But he also explained why it's not a valid bug and explains every aspect of it and how they work such as ENOENT and ioctl. That's really professional and I wish this was done more, even forcibly to explain what you don't like and what they thing is. And his last point just saying "screw it, I'll do it myself". Perfect. Makes me miss one of the old CEOs of Nintendo who personally went down and fixed the coding problems.
Regarding Anarchism vs Authoritarian. Even in the Rust community you find that drama. Like Safe Code vs Unsafe Block. I am no web dev but I came across a web crate discussed drama that even made the mainteiner quit because some wanted more safe code than umsafe blocks. I am also not a speed demon myself and more on the safe code side.
True, it seems to me that a lot of people in the rust community are so obsessed with "safety" and "correctedness" that it can get unhealthy sometimes. I feel like there are two kinds of safety, one that is proved by the compiler, and one that is proved by the developer, and it happens quite often that the compiler cannot prove that a certain behaviour is safe, but a developer can with logic, and its perfectly fine to use a safe abstraction over unsafe code in this case, ive done it myself a few times in performance critical applications even though i try to stay away from it, but a lot of people seem to get really hurt by this. maybe they think the compiler is the all knowing oracle - w - (which i wish it was due to the amount of time it takes for it to run)
The issue there is between an experienced Rust developer and an inexperienced one. For some reason, inexperienced developers have this idea that code written in an unsafe block is faster "because it's not checked" but that's not true. The checking happens at compile-time, not during runtime. Code run inside of "unsafe" is not faster, it's merely meant to do things the language would otherwise yell at you for... like creating bindings for unsafe languages like C. There should be very, very few reasons to use the unsafe block in your code unless you're interfacing with other languages.
@@Daktyl198 true. In the Rust forum one made a survey regarding who uses unsafe block for performance. It came as a shock to me that indeed few even do that for performance. But I am still rather new to Rust myself. The up coming Borrow Checker 2.0 will need even fewer unsafe blocks.
@@Daktyl198 well technically unsafe blocks do allow you to bypass some runtime checks, for example, bound checks on slice accesses, which normally would panic if theyre out of bounds, but instead with .get_unchecked results in undefined behaviour, reducing branching, but optimizations made possible by using unsafe blocks are usually not of this kind, it happened once in my case that the compiler couldnt prove the lifetimes of my *very expensive to clone* data, but i could. though, it doesnt seem right to me that even inexperienced rust devs think that the actually expensive checks are done in runtime, the whole point of the language is doing a lot of compile time safety checks
For me chaos is a place of huge potential both good and bad that is missing information, missing understanding and has mostly unpredictable outcomes. "Handling chaos" then means creating some order that works for you while leaving the biggest part still in chaos. It is a form of minimum adhoc order.
Chaos and freedom are not the same thing. Because you live in a stable environment and have technology you are free to do things you like to do. If there was chaos, you'd constantly be putting out fires without getting anything done.
Because they've experienced mentally ill, substance-abusing homeless people acting out on public transit, and don't agree that it's the nirvana that some people make it out to be.
"The most bike-shedding people possible, which is kernel developers" Have you met frontend devs????? Like they spend half their time talking which specific code of conduct to adopt. That is the epitome of bike shedding, it has absolutely nothing to do with code or code performance and guess what everyone has an opinion.
I understand the argument “haha boomer c devs too lazy to document their code”, but couldn’t the rust devs just read the implementation and grep out the call sites to see how the pointers are handled? Anything that isn’t exposed to userspace has no guarantees about stability anyway-it quite literally “just works”.
I suspect a large portion of the Rust community are web developers who are just getting into systems programming, so no they can't figure this stuff out. That last video on the Rust dev claiming he can improve the ext4 filesystem while at the same time saying he doesn't understand how it works pretty much sums up this entire debacle.
@@RustIsWinning The Linux kernel is some of the highest quality C code in the world. Anyone contributing to the kernel needs to understand the patterns and abstractions in the existing code base. And, I'm sure, most rust contributors do. I'm sure they've invested the time to do that, give them some credit.
That's literally what the Rust developers did in the end. The problem is that it takes time to do so, and these developers are paid developers. Time is money. They were simply trying to speed up the process.
helix is not a neovim successor, it can be a kakoune successor. You forgot Rust. Rust is written in Rust and it's huge. uutils is a cool project too MeiliSearch rustdesk redox
I think when you said 'you had to pay for emacs', you meant 'you had to pay for vi'. Vi was built on ed which was AT&T licensed, and it remained built on ed until Vim in the early 90s. GNU Emacs was open source from the get-go.
Ok the take at 6:50 is utter CRAP. Your philosophy is the method by which you contend with the human condition at the deepest level. Your philosophy should inform your religious views, your political views, and even the manner in which you relate to other human beings. Your philosophy dictates your deepest principles, it is how you ground out your beliefs. It is how you justify and understand your moral views. Equating philosophy with politics is absolutely disgusting.
Politics reaches deep into the human brain because we have entire sections of the brain dedicated to its practice, providing data to the rest of the brain all the time. When we imagine our own mind we use the parts of our brain trained on modeling other people's, with all the training it has experienced baked in. I'd love if your take were right, but I don't think the view that philolosophy sits at the deepest level of human experience while politics doesn't is rooted in reality. Both massively shape your deepest principals, beliefs and moral views. Considering 'who we are' is not just the mechanical logic of a brain calculating philosophy but also the mechanical process of the brain that made us social animals doing politics and the emotional processes of an animal exploring the world. Putting them in the same category when examining how people interact with each other and the different ways they approach it seems fairly reasonable.
@@fastestdraw Politics may be a more used pathway/network in the brain. I would expect as much on an average, but most people don't ground out their politics to morals and ethics to philosophy. Philosophy must be the underpinning of a thoroughly investigated worldview. It may take up less brain space, it may have less contact with your conversations, and your interactions with the world. From a reasoning perspective you politics `aught` to be derived soundly from philosophical principles. However I would say this is the case for 1-200 individuals if not less. Most people pick up policies and political alignment based on intuition, or they simply identify with an entire group or party. They align with a political party because that is who their friends and the people they look up to are aligned with. I would never expect a study on the human brain over an average population to reflect what I described above. I also role back the statement on how philosophy effects your relationships, the impact may be profound but likely because of second order effects. For example if your philosophy lead you to being an atheist while your family was very religious. This can have a major impact but again that impact isn't direct. I would also stray from saying that dedicated portions of the brain are used for politics. I think politics would occur in the same portions of the brain as most other higher order information processing. The PFC, the ACC, and a bunch of other places too. I would expect philosophy to use those exact same regions as well, except for some differences, I think philosophy would be more abstract thinking and politics would involve more social and emotional processing. In terms of brain function maybe politics would have more Amygdala use versus more DMN use for philosophy. However that is all very tentative speculation.
@@user-shilov- Agree on the brain region/function, we do have parts of our brain that seem highly correlated with imagining other minds and predicting their actions, but that is highly unlikely to be the only place in the brain that is happening or the only thing that region does. Couple with both language development and abstract thought appearing to be linked in our evolutionary history, and seperating out philosophy and politics gets even muddier, the comparison between them more apt. Most people aren't sitting around logically reasoning out a philosophy using the building blocks scholars use to describe the world- they are seeking out things and returning to raw experience to see what works - 'is an idea true when I use it in my hands.' The same process is going on with politics. This approach is both fundamentally collaborative, political, sits firmly in that second circle, and results in abstract reasoning derived soundly from the source of philosophical principal - experience. I can't argue that it isn't the practice of philosophy. It grounds out morals ethics politics and yes, philosophy, in a group basis. No man is an island, and neither is our understanding or reasoning. And most people have a deeply explored worldview that doesn't deserve dismissal or disgust because it fails to fit neatly into your world view. If only 1-200 people have done something accessable to 8 billion on the planet presently, I am inclined to think it is a sampling error. But I'm willing to hear out why this 'aught' to still be considered, compare that to my experience, and see if it seems both true and functional.
It's so funny to me. The Rust team is focusing so much on pandering to Linux devs for features, prioritizing Linux dev's requests over the other 99% of their userbase. All while Linux devs themselves can't even decide if they want to keep using Rust or not. Please, please, please just let the LInux devs fix their own shit before pandering to them...
@@monsterhunter445the Rust compiler team is focusing on features that Rust for Linux wants rather than anything else, despite Rust for Linux not even being a sure thing. It would be like gcc prioritizing the Linux kernel devs rather than just trying to be a good c compiler
@@SussyBaka-nx4ge Exactly. On Reddit a similar comment got downvoted into the ground by people that didn't know that, with multiple aggressive replies. The Rust community is getting more and more of a cesspool the last couple of years.
It is fitting that when drawing the circle of life at 7:10 C is inside god's circle and Rust is left out of the circles of life entirely. lol Jokes aside, your description of why C vs Rust is such a hot debate is flawless. The only thing is: since they are competing for the same low level code positions, I don't know that there is a nice solution to the dilemma, I think this knife fight will continue indefinitely because order vs anarchy is too fundamental.
Pretty much hit the nail on the head. C developers don't like Rust developers because they think they're coming for their jobs. If C code is replace by Rust, then the C developer has to learn Rust or they're out of a job.
@@Daktyl198 Hard disagree. Even if Rust magically replaced the codebase, you still have to talk to the outside world that's mostly C. They would lose clout and importance but not their job.
@@FathDaniel very little of the world outside of kernels and the lowest level programs use C, and even kernels and those low level programs are slowly being converted to other languages in both macOS and Windows. Linux is actually behind the curve with this, but that’s not new. Linux is ironically much slower to adopt new ideas than macOS or Windows due to its reliance on semi-religious idolatry rather than programmers just following the boss’s orders.
There was more nuance to the discussion than a rage against Rust. The subsystem maintainer in this instance was just standing up to say, "Im seeing all these new type annotations starting to pop up everywhere in the kernel because of rust... If the rust folks think they need annotations all over the place - well, I'm going to continue my development in C, and I'm sorry to say that I really am not interested in supporting those annotations. If Rust needs the annotations, then someone from the Rust community is going to have to support those annotations."
What about the previous dozens of presentations that were interrupted? Apparently this behavior goes back 20 years. Seems a lot different than a "nuanced discussion".
That is a valid concern and also a valid respond. The real issue is however with how the involved parties talk about their different opinions. Its fine for a c dev to want to continue to program in c, it is a different thing however if the rust team and the c team refuse to collaborate at a basic level when changes to the kernel are made. From what i can gather, the rust team is totally fine with supporting the annotations themselves but they at the very least would like to know when changes to the system are made. I think goes further than "i want to continue to use c" when the rust team only finds out about changes to the system when the code doesnt work anymore.
@@leonardschungel2689 this is not a refusal, C dev are more experienced and know this will not work well. In the purposed solution C dev will not be able to do development without knowing rust, any C change can break rust binding. What they should do? Pair programming? One C and one Rust? And if you think they will be able to do changes separately you are kidding yourself it will be nightmare for Rust and C devs. In order for this to work well you need clear defined boundaries between C and Rust which are not part of the solution.
I think the heart of the comment about Linux vs Unix wasn't FOSS vs Closed Source, it was more that if enough people think that it is too difficult to get the features or fixes they want for Linux through the bureaucracy of Linux, they will go and move to somewhere else where they can get those features. Whether that is true or not, remains to be seen, the friction to create a new OS kernel is obviously pretty huge, so there would need to be a lot of discontent. That being said, as Prime pointed out, with Docker and so on, its probably a lot easier to get traction now than when people had to literally install your software on a machine.
For what it's worth, around 2017/2018, Linus took a sabbatical to work on his communication style, and since then he's been much more diplomatic in his criticism! Respect where it's due, he got called out for a toxic communication style, acknowledged the issue, and then made a change!
It really isn't. C/C++ means you always have work everywhere in the world. If you want to make a lot of money you should learn some of the obscure languages that are still used for very specific things, like Erlang.
Zig doesn't provide that many improvements over kernel C, the variant of C made specifically for the Linux kernel. Linus wanted a language that was different enough, that also provided actual benefits to the kernel. Thus he allowed Rust in.
Freedom from anarchy vs Freedom from authority can be read in two totally different ways. English is just as bad as javascript; and used by about as many people.
So many libraries and techniques were already developed in the Linux code base to address unsafe scenarios in C. It would be an enormous time investment to re-write all of that and I just don’t see value add in doing so.
Culture doesn't flow from the top. It evolves over time from shifts at the bottom and has done throughout history. When it comes from the top it isn't a natural culture shift, it's force and always results in massive backlash and usually a complete splitting of the community/population.
If you believe that Linux can't be displaced in 10 years as the default open source kernel or that nobody could possibly write a replacement for it in Rust in the same timeframe, just remember that it wasn't that long ago that Internet explorer had 95% market share.
“You need 100 lines of Rust to replace 4 lines of C” - sure, but those 100 lines encode all the edge-cases you need to think about like who owns the data, how long it lives for, how it has to be handled etc while in C you get none of that and you have to pray whoever wrote that code has written a 100 line comment above the structure definition
As someone who just learned C recently, I couldn't imagine moving to Rust. I went from C++ to C because of OOP. I'm done with it. I've also picked up Go because I was curious in its C-like simplicity. I love both Go and C now, and they cover so much use case it's wonderful. Too bad the Zig team can't pull their shiite together and come out with a 1.0 spec standard. I feel like Zig would have been the best compromise for the Linux Kernel moving forward.
Minor nitpick around Ladybird, while competing with Chrome is an aspect of it, another was that it was born out of Serenity OS because the guy who made Serenity wanted it to have a browser. Don't know how realistic it is to port Chrome to your personal hobby OS, but they decided not to do that (iirc, part of Serenity OS is that they make things themselves).
Pretty sure you could eat a significant chunk of Linux market share if you made an OS in a memory safe language that can run in the big clouds and can run Linux Docker containers.
Stems from the weird pushback on Rust as a whole. The more people hate on Rust as a language, the more fanatic that Rust developers feel about the language they like. If people stopped hating on Rust for literally no reason, Rust developers wouldn't be nearly so bad about it. It's a well studied behavior in a lot of groups.
@@Daktyl198 So you are saying that there are literally no reasons for anyone to dislike Rust? That's literally only an opinion that a cult-member could have about anything, ever.
@@matthewmurrian9584 Languages are tools. You may dislike writing in one, but there's no reason to then go online and seek out discussions about that language and actively hate on the language in that space. You don't see droves of people going into discussions about Go and saying "holy shit, I hate Go so much. Everything about it is bad and the people that use it are worse!". One or two weirdos, but not on the level that people that hate Rust do it. If anything, the people that hate Rust are a bigger cult than the people that like it lmao. For the record, though I like Rust I actually prefer writing in C#.
Linus gets this stigma of always being a screaming abusive maintainer, but he is not. He's not afraid of calling people out when they are continually making the same mistake, and those always make the news, but the vast majority of the time he is a pretty chill dude.
