Friendly reminder that if you download software updates for Fedora or AlmaLinux from London, there's good odds that your software updates are coming from an HP thin client sitting in a road box in Surrey.
This is perfectly fine, and how free software / the Internet actually works.
IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.
Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".
(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau and NVK to GL 4.6 conformance.)
I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...
WTAF. The more and more I learn about kernel devs, the more I equate them to the vocal minority of the larger Linux community: toxic, entitled, gatekeepery, smarmy assholes.
yeah.. we really need to focus more on getting stuff merged and I'd love for nova and asahi to work together on the bindings/abstractions so we can finally get things going here. And there are people more involved and knowledgeable with drm/kms working on nova, so I'm pretty confident that we can make this work.
And if it means we use a new drm_scheduler written in rust so be it.
@Sobex @karolherbst Probably not easily if written in idiomatic Rust with stuff like generics. I certainly don't plan to spend time thinking about that right now. It'd just be part of the driver, and if Nova wants to share it we'll move it to common Rust code.
Though you can always make wrappers work some way, so perhaps we could task the C people with writing C abstractions to the Rust scheduler if they really want to use it. Let them suffer the cross-language adaptation pain for once...
@Sobex in theory yes. With rust you can specify the calling convention and every rust function can be compiled with the C one for compatibility.
And then you have "cbindgen" as a project to generate a C header file you simply include and link against.
The really nice think about rust is, that you don't need any kind of FFI code to call C or vice versa. Rust wrappers are really only about writing good abstractions, not about making it possible to use C code in rust or vice versa.
@karolherbst @Sobex You can write Rust that can be called from C, but you have to do that explicitly. The situation doing idiomatic Rust to C abstractions is actually worse than the other way around, because while Rust can support concepts like C struct embedding etc. (just unsafely), there is absolutely no way for C to directly interact with concepts like Rust generics. You'd have to introduce more explicit layers of abstraction in some cases with extra allocations and things like that.
And maybe that's a good thing. If we end up having high quality native Rust code in the kernel and C ends up being a second class citizen if it wants to use it, maybe that'll help convince the C people to learn Rust. We're certainly not going to degrade Rust code to C standards and design just so C people can interact with it in a C way.
@Sobex oh sure, you can't map everything, but if you e.g. have a C API, you can implement that in rust just fine. And then C code can just call into rust code, which might be a better approach here than using cbindgen.
@karolherbst @Sobex can you start with gccrust with the same architectural coverage? I still have phantom pains from projects stopping working because someone pulled in a dependency that wouldn't compile on perfectly capable machines, and it's starting anew with Python's Rust frenzy
As an Asahi Linux user, thank you for your work. It is very much appreciated. I'm regularly stunned by how good the Asahi Linux experience is on my little old M1 Mac. Thank you.
And distro rust maintainers like myself (opensuse, suse) have worked with the kernel rust folk to address all the backporting and version stability concerns. Seems a lot more like kernel devs acting like this when faced with the prospect of change:
An angle I haven't seen mentioned is: where will all the new blood for the Linux kernel come from? I speculate that the average age amongst the Rust fans is lower than that of the C die-hards. If the Ted and friends are driving away the Rust people then Linux will suffer long-term.
@awoo I'm learning Rust because it is, in my view, the successor to C/C++ that isn't tied to a major corporation, has a good community ecosystem, and is syntactically efficient, with a lot of extras that the old compilers don't have
some people do amazing stuff and can still be blinded by their bias and obsession with a favourite tool. You do amazing stuff too and there are a lot of us with macs wishing to high five the skin of your palms.
block all attempts at merging useful Rust code in the kernel -> claim that all Rust kernel projects are unmerged so the situation is a failure. Makes perfect sense.
I love how he keeps on bringing up RHEL but Asahi *is* the reason why Fedora is turning on Rust in distro kernels now. I'm pretty sure that's doing more to push RHEL to do that eventually than anything else.
Also there are literally companies investing in Asahi these days, just not ones who care about RHEL. But I guess he thinks only RHEL matters and anything else is "a toy" even though one such company has roughly ~the same market cap as RH did before the IBM acquisition today.
I have been bothered by people revising history before ("nobody expected this" while I loudly expected it), but this is a revising of the present. I wish you strength!
Oh, that explains the "merging Rust will risk my NVidia investment!1" thing we saw on reddit.
Matrix Multiplications should be incredibly simple to abstract, yet NVidia's AI hype reduces to "the unmatched software quality" (lol yes but $3T market cap can't lie) that nobody else can deliver.
Now you threaten that ecosystem by creating _toys_ that work better than any commercial driver.
Yes, with that I would be very concerned about any NVidia investments.
Yeh; although tbf I think Jason is from the RDMA side of things, which would have been Mellanox which Nvidia bought a few years back; I don't know if they speak to the GPU lot.
The work you do on AGX is fucking AMAZING, beyond impressive. And I say that as someone who is usually on the "worried by rust" team, since I am quite fond of the more obscure architectures , which will probably never be supported by rustc. There seems to be a problem in attitude in *some* of the commercial kernel contributors, who think the linux kernel only exists to serve their bottom line, everything else is "toy projects" and "toy architectures" to them.
Extrapolating one developer's words into "this is what kernel maintainers think" is an obvious logical failure and is not the way to advance the Rust cause. The fact that several kernel maintainers spoke out against the "unmerged toy" description makes it clear that it is not a majority opinion. There are a lot of people in the kernel community who support this work.
@corbet The problem is that as people in the Rust for Linux project we get to write all the abstractions to make things work, and that means interacting with many/all subsystem maintainers and therefore just one or two hostile maintainers can successfully derail the whole effort.
I'm already making a mental list of people to attempt to design around and avoid interacting with, and sometimes it's not even possible.
If you approach a large city with a plan to install a shiny new utility system, you will quickly find yourself dealing with a whole range of bureaucrats, some of whom will be more helpful than others. The kernel project resembles that large city in a number of ways. I don't say this is a good thing, but it is a thing.
I believe that the Rust for Linux project is succeeding. Yes, it is slow and painful, but the people pushing this work are doing the right things and making progress.
The city council (the maintainers summit) is meeting on September 17. Rust will be on the agenda, and there should be a couple of Rust for Linux developers there. That would be a good time to have a well-thought-out proposal for process changes that you would like to see.
@corbet The difference is that people planning shiny new utility systems are probably on someone's payroll and still being paid regardless of how long the bureaucracy drags on or not, so at least they are getting some benefit (money) out of the painful process.
That doesn't really work like that in FOSS, especially not with non-commercial projects like Linux on M1. What that bureaucracy culture does is heavily benefit and prioritize the people employed to work on Linux and paid to deal with the red tape, and hurts people who are not and are just doing it for fun or to push the community forward, or as a side project and not their main employment.
The endgame is that you end up with a bunch of bitter people employed at big companies who do the work for the money, and have no interest in helping onboard new blood or support those who aren't motivated by a big paycheck to fight the community.
Obviously this doesn't describe the entire kernel community and there are good people working at big companies and still fighting the good fight... but I think it does describe how things are shifting overall, and how we're ending up here.
I was actually trying to convince our IT staff to support Asahi running on company MacBooks. I'll give it another shot soon. We're not a huge company by any means, but if you name a helpful / non trivial (CAD or USD) dollar amount, I'll see what I can do.
please don’t equate what one random maintainer says to what “this is what all kernel maintainers think”. I’m a daily user of this work and have been extolling its virtues whenever I’ve chatted to people about it. Let’s not turn this into anymore of a rust vs the kernel slander fest than it already is.
The problem is that when the Rust project needs to interact with a wide range of subsystem maintainers to put together usable Rust abstractions, just one or two acting in bad faith (or even simply not up to the task) can successfully derail the whole thing. We need active support from those who do want to see Rust happen... but we're not getting enough.
@corbet The problem is that as people in the Rust for Linux project we get to write all the abstractions to make things work, and that means interacting with many/all subsystem maintainers and therefore just one or two hostile maintainers can successfully derail the whole effort.
I'm already making a mental list of people to attempt to design around and avoid interacting with, and sometimes it's not even possible.
I'm no programmer, but it should be that any open source code that benefits the user is good code, regardless of programming language used. (Bonus points if it's well optimized too, lol)
@stormy178 Playing the devil's advocate here: Some people I know are afraid it will affect the complexity to compile Linux and also how much time it takes to compile it.
@MadMike77 @stormy178 The Rust kernel core stuff compiles in almost no time. My driver takes a bit longer but that's because there's a lot of macro magic and it's compiling almost 5 different copies of the whole driver (for different GPU/firmware combinations). It's still an insignificant part of the complete kernel compile time.
here I am reviewing Rust patches for Zephyr thinking Linux already had all of the political stuff sorted out 😂
If it makes a difference, I 💯 support what has been done in Linux with Rust.
There will always be resistance to change. Hopefully the resistance is less aggressive in the future. It sometimes takes thick skin.
I still strongly believe that Rust will reduce many of the common pitfalls hit by C developers (old and new), and that our systems will be more reliable as a result.
We define several techniques to extend gradual typing with semantic subtyping, specifically targeting dynamic languages. Focusing on the Elixir programming language, we provide the theoretical foundations for its type system.
Ah, auto battlers, at one point they seemed like they would be all the rage, but most quickly moved on. Mechabellum thankfully, feels a bit different, and quickly became a real favourite and it's set to leave Early Access on September 26.
Valve's latest game Deadlock continues rising up the most-played games ranking on Steam, despite it being invite-only and the developers continue expanding it.
But: I am a little bit sick of kiddy friendly colorful non-sensical games. It's the Fortnite-ism of the gaming industry, imho. Driven by greed.
Best example: Call of Duty.
It's called "Modern Warfare" or "Black Ops" and it sounds serious. But then multiplayer is hysterical as shit and has nothing to do with war scenarios any longer.
Recently, Valve put some new rules in place for Steam pages, because they were getting a bit messy with some publishers using them like pure advertising boards for other games. Now though, Valve have announced more changes.
Bazzite, the Fedora-based version of Linux that's designed for the "next generation of Linux gaming" has a fresh release out with some great improvements, especially for gaming handhelds like the Steam Deck OLED, Lenovo Legion Go, ASUS ROG Ally and o…
We would like to introduce the next evolution of the Cascadia font family, Cascadia Next. Our talented typographer @aaronbell has created three variants of Cascadia Next for SC (Simplified Chinese)...
A recent change was proposed last month to implement an on-by-default KDED (KDE Daemon) module that will gently ask you to Donate to KDE as a pop-up on your notification system inside the KDE Plasma desktop, planned for version 6.2.
There is one thing that’s a bit unclear to me: is a KDE OS an agreed upon KDE initiative, or a Nate Graham thing? When i read Nate’s post I was under the impression it was just something he personally wanted for the future.
We're starting to publish the talks from Flock 2024! State of Fedora by Project Leader @mattdm is a great place to start. Good high level view of the project.
Which talk was your favorite, or which are you hoping to catch now?
Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
Really great to see bigger developers actually start to properly take note of the Steam Deck since it's selling so well. Now we have The Elder Scrolls Online from ZeniMax Online Studios and Bethesda Softworks getting improvements.
The team behind EmuDeck, a project that started off to provide easy emulation on Steam Deck / SteamOS have announced their own hardware with the Bazzite Linux powered EmuDeck Machines.
The goal seems really low to me, for getting injection-molded cases and two different motherboards manufactured in a custom form-factor to match. I've worked for places that spent a lot more on building a lot less. I wonder if this is an existing product that they're going to rebrand? If they're starting from scratch, I don't think $70k is going to be enough to get the job done.
Necrosoft Games and Ysbryd Games have announced their stylish tactics RPG with hints of Persona, Shin Megami Tensei, and Italian horror cinema Demonschool has been delayed.
A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.
When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.
That simple concept only recently finally got merged, over one year later.
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".
My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".
Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.
One C driver works, so Rust drivers must work the same way.
Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).
To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.
The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.
If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?
Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.
Because I wrote it in Rust.
But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.
There is a *fuckton* of pride at stake among C (and C++) developers.
"C(++) is a perfectly good language, just write your code correctly from the start and never make mistakes" is a statement I hear with almost frightening regularity. Of course that usually also correlates with said people being rather found dead than admitting they may have made bad design decisions in the past (or worse, mistakes while implementing said designs).
I just wish there were fewer people that go religious crazy about such things and more people trying to argue on well researched and as objective as possible facts..
saddest problem is that these things tend to spark some form of "war" where it is one group against the other.. can't we just get along?
Even Linus himself recently pointed his own finger directly at memory management issues in Linux, and yet this perennial resistance to change persists:
"You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
In a wide-ranging conversation with Verizon open-source officer Dirk Hohndel, 'plodding engineer' Linus Torvalds discussed where Linux is today and where it may go tomorrow.
imagine having the biggest open source operating system in the world and get along with each other when comes to choices and preferences.
Shame that in the end many great programmers have their ego that high so they are toxic. This reminds me of Hyprland dev: blog.vaxry.net/articles/2024-o…
@charadon The kernel didn't even support any C compilers other than GCC for a very, very long time... so I don't think this is really an issue in practice. Rust is widely used and well established, rustc isn't going anywhere.
It's not so much i'm afraid of it going anywhere, but more that one organization controls the whole standard. In java's case, oracle abused that fact and did a lot of shit since they *were* java.
Would this happen with the rust foundation? Probably not. Though with the whole branding debacle a while back, it does show how easy it is for an organization to screw up, and how bad it can be when they're the only ones in a space, beit malice or no. (In this case, I don't think it was malice.)
C's type system doesn't express much and docs are of course sometimes lacking (not only in open source prjs, sorry! I have some experience with a C# CAD toolkit and the documentation is mostly just the class / method signature...).
I don't understand why some long time pro kernel devs are so completely obstructive against Rust. It solves real problems and is the only lang that does so in such a comprehensive way (Zig doesn't at that level).
"design your driver like amdgpu to make it work, or else"
Which is concerning, because the amdgpu driver isn't even that good. I can't tell you how many times back when I had an AMD gpu I got a system lockup because of Ring Timeouts. Meanwhile on my Intel Arc, I haven't had a *single* gpu driver crash since I got it, while with AMD it was a weekly occurance
a few weeks ago I considered rewriting atcphy in rust because that would’ve been more fun but then stumbled across exactly that: it’s been over a year and there still wasn’t any platform device binding upstream. I would’ve been fine writing phy bindings but there‘s still a lot of infrastructure missing unfortunately :(
(Not that it matters much for atcphy: the driver doesn’t gain anything from rust since it’s fairly simple and doesn’t even need any memory allocation outside of probe. It just would’ve been more fun than rewriting the current C version to me)
@sven Yeah... I've been waiting for someone else to figure that out because the whole device probe design goes over my head... but with how long it took to even get struct device in, I don't know how long that is going to take...
@sven it's going to be interesting in regards to nova and how much it can push maintainers here.
At least "we don't want to spend more time on the old nouveau driver, so if you want to have support for new nvidia GPUs, it's gonna be a rust driver" isn't something you can simply ignore.
People can go "macs? why do I care", but doing the same for Nvidia GPUs?
That can lead to quite some discussions upstream if people keep blocking work.
A solid tenth of the amdgpu mailing list is randomly moving fences around playing whackamole and hoping they'll finally get it not to hang; being forced to copy them is scary.
@Lun I wonder if they've figured this one out yet? I'm pretty sure it can cause random crashes in all drivers using drm_sched with certain kernel builds...
I'm too tired of this code to come up with a proper fix and send it upstream though, I don't want to deal with that guy any more... I'll probably end up writing a Rust scheduler anyway so...
Every time I am forced to look at a large C codebase I see not only a gigantic pile of nightmares, I see a gigantic pile of nightmares created by people that refuse to accept the flaws of their tools and refuse attempts to change them.
To hear that Linux is the same is unsurprising but saddening at the same time.
Wanting the "perfect API" is the trick these anti-Rust people use to stall things... ;;
Like they think it's the Rust team's job to fix the existing lifetime/recounting messes of the kernel before they're allowed to introduce safe APIs... even though an imperfect Rust abstraction that leaks some unsoundness in corner cases (due to underlying C problems or design) is still better than literally no Rust code at all and writing more C code...
re: last RT -- we have to be careful as open source projects to accept new ideas and include them, especially when people do the work to go through the process. New is scary, but running away anyone else who can help improve it is way, way scarier to me.
As a MacPorts maintainer and a FreeBSD sysadmin, I run into two problems with rust: 1) It is unwieldy to maintain rust and cargo, so both are often out of date on MacPorts. 2) On FreeBSD some random library (e.g. librsvg) that depends on rust/cargo causes Poudriere to rebuild rust every time some build dependency is updated. This usually takes several hours on my build machine. For this reason, and that it adds a lot of extra packages, MacPorts still doesn't use librsvg built using rust.
@schamschula Every modern Linux distro has already figured out Rust packaging since it's required for a lot of modern packages, so I don't think that's a concern...
Chuckles, I only use Linux on Raspberry Pis. And yes, I could wait to download the packages from FreeBSD's build/package system but I prefer to keep my systems more current, and hence run Poudriere.
that video linked in Wedson's retirement mail is... damning, to say the least. Wow. And the fact that this is apparently just acceptable behavior in that community...
@delroth what is it with prominent C developers insisting that there is no reason to learn anything new and that C is the only good way to write software? It isn't just kernel people, this is a huge issue on the userland side of open source too. This gatekeeping is super toxic, and leads to dramatically worse software overall.
this brings back memories of a couple of us early Rust netdev folks trying to push for a branch where we would be allowed to experiment and share abstractions that just did not have any user yet, but could be improved and reworked by people who eventually picked them up for use. It took multiple hours-long meetings to finally ending up agreeing that we would just all share links to our respective code and pray that anymore who wasn't aware of it wouldn't have to reinvent the wheel again abstraction-wise.
I don't want to fall into tribalism, or paint all C (or even netdev) developers as stuck-up assh*les, far from that, but it's clear that the requirements imposed on Rust developers to adhere to the way things have always been done in C, and effectively considering Rust as a guest who should be grateful to be in the project, rather than a system capable of making informed decisions about other systems*, places a ton of constraints that just make our development harder and slows down the inertia to get the project to mature. Meanwhile, a lot of time has to be spent by the heads of the project (bless them) doing diplomacy because otherwise patches don't get reviewed, and C devs don't see our point.
Plus the random stubborn and very opinionated dude every now and then of course, but it's the linux dev community, ofc it'll happen.
(eg. Rust being used must not motivate large changes on the C side, Rust has to reproduce the way things are done in C however bad they are etc)
@SharpLimefox Isn’t there a Rust-in-Linux GitHub repo, that could serve as a central point to keep track of all those abstraction and shared work ? (Possibly with more experimental branches).
@Sobex there is a repo, it's where the previous work resides in the rust branch from before the merge in 6.1. That was where we would have wanted a branch, but review rules are what they are and we would have needed to go through LKMLs with netdev people and netdev people will not review code that is not aiming to be merged (which i understand, but then why force us through LKMLs?)
And it was all just diplomacy and sticking to how things are done
The kernel dev model is very hostile to major changes like this, because the upstream devs refuse to review anything out of tree but then expect submissions to always come with users. That's why I had to submit my DRM abstractions with one huge commit at the end of the series adding my whole GPU driver, even though as expected that got zero reviews...
It causes a lot of friction any time we need to touch any core code because "show us how you're going to use it in the series" is a very effective stalling tactic when that means adding 50 patches of extra stuff just to get to the point where you can merge the intended user...
@Sobex the current model is fine for C developers trying to add simple things or fix bugs and so on, but when large architectural changes are needed (aka you welcome a new language in the codebase) it's definitely a major point of friction and literal slowdown
Regarding reviews, IIRC, the first time a network driver was sent to netdev, the first reply arrived 48h later at least and it was an apology that nobody was reviewing (i could pull the exact lore links when i'm back at a computer): there was just nobody available to review Rust. Concurring with that (and I'm sorry i'm putting my academic hat on because this is exactly what I'm focused on atm), Hongyu Li et al0 found that "RFL is bottlenecked by code review but not by code development" (insight 3), and it's pretty easy to see anytime you get an actual driver sent to the LKMLs for reviews, which is somewhat rare these days
i remember seeing your patchsets dying and your presence in the LKMLs diminishing, and it was quite sad, because of all the work put in it :( i'm also very interested in making abstractions, but finding an end user without paying for obscure or brand new hardware is so hard in net, so i just can't contribute anything, and i'm not alone...
Hopefully things fare better in the future but it's going to need a lot of change of mind from a lot of people..
Honestly the thing that has burned me out the most has been the scheduler saga and seeing how slow the core Device/platform driver stuff (+ the device ID pain) is moving (due to pushback from upstream mostly). I don't want to take on that work myself because I didn't write the original code and I don't fully understand the nuances of the device binding cycle/lifetimes and how that was originally designed for the Rust abstractions (+ my GPU driver literally can't support rebind due to firmware limitations so it's a terrible test/demo case of how to do all that properly). But I depend on that to get anything done...
Once platform devices are supported I'll go back to sending my stuff and I hope it'll be a lot less blocked after that. For better or worse the approach ends up being "don't depend on subsystems where upstream doesn't want to cooperate and will stall, if you can help it"... I think I have a pretty good idea of what those are so things should move forward. I hope...
It's possible in some cases, not others. You can't avoid the subsystems "above" you providing your services (DRM for me) and "below" you interacting with other devices, but you can avoid "helper" subsystems and parts of them.
The DRM scheduler is a helper. The other thing I'm going to RiiR is the GPU page table management, which is currently using the IOMMU page table helpers (both because the maintainer stopped replying to my emails... and because since the original submission my needs have diverged enough from the standard code that I think it stopped making sense to reuse it and try to fight to shoehorn those features in).
@Sobex IMO regardless of subsystem you'll have to endure the structural issues plaguing RFL, but a subsystem full of people willing and motivated to help should alleviate those significantly
And there's also the problem that if your interest is in a specific area of kernel dev (drm, net, whatever), you've only got so much wiggle room to avoid maintainers unwilling to help more.
Someone i talked about this with mentioned forking as well, but that comes with the human cost of maintaining the upstream source (mainline), people having to decide whether to leave the main project, stay, or invest twice as much energy, and the risk that nobody will really use your fork (Asahi Linux being the huge exception for that point lmao)
@SharpLimefox @Sobex Hard forks aren't sustainable. Asahi Linux tracks upstream and with that comes a maintenance cost proportional to how much it diverges. The plan was always to upstream almost everything... the project doesn't have a long term future if we get stuck maintaining large amounts out of tree forever (a few patches is OK and we already have a couple "upstream is never going to take this and that's fine, we can live with that" cases... but it can't grow without bound)
@Sobex @SharpLimefox TSO support for fast x86 emulation and the M1 cpuidle driver, both are NAKed by all the ARM employees (for politics reasons) and they own the arm64 platform subsystem.
The actual patches are pretty small and not intrusive though so it's not a big maintenance burden.
In theory the cpuidle stuff is supposed to be replaced by some PSCI transport alternative that doesn't exist, but that idea has been floated for years now and not gone anywhere...
@Sobex @SharpLimefox For TSO they fear "fragmentation" as in developers using TSO to work around arm64 porting issues instead of fixing the code, even though there is no evidence of anyone ever even thinking to do that.
For cpuidle, the maintainers want PSCI (a firmware interface) to be the only cpuidle driver to avoid driver proliferation. Unfortunately the PSCI spec was written with assumptions about the platform that make it impossible to implement on Apple Silicon despite it being a conformant arm64 implementation (they require optional features).
This makes me wonder, how does the future actually look like for your driver? Will the M1 GPU driver just always live out-of-tree because upstream is institutionally incapable of accepting GPU drivers written in Rust? Or are there signs of progress?
(Also, thank you for all your work, I'm a happy user of your driver and it has been nothing but great for me :3)
@mort The DRM people are actually very nice in general except for that one scheduler guy. So I don't expect any major trouble merging the driver itself once the dependencies are in. ^^ (and I might seriously just rewrite the scheduler in Rust as driver-internal code just so I don't have to deal with that guy and that mess of buggy C code... it's not just the lifetime stuff, I keep finding outright memory safety bugs.)
The good news is Nova (the new Nvidia driver) is also written in Rust with the same abstractions, so now we have two GPU drivers to put some pressure on the people blocking things...
I made the mistake of reading the phoronix comments about this news, won't be going there again. On average people are way too protective of how things have always been done. I know perfectly well from my career that "C is perfectly safe if you use it correctly" is just stupid gatekeeping that doesn't even work. I make mistakes as well and I want to be warned as early as possible without needing to add on additional static analysers (which still can't check everything).
@argv_minus_one @raulinbonn This is solved in kernel code by disallowing those methods that abort. That was decided early on. The approach has changed a few times but fallible allocation was pretty much always banned.
@argv_minus_one @raulinbonn The Linux kernel uses no_std. Until recently there was an internal fork of the alloc crate with those fallible constructors outright gated off. Now things are switching to custom allocators where the Box types (there are several to allow for different allocators in the kernel) are outright always fallible with the standard constructors.
I saw the video, ideals and opinions brought forth on the open. I don't have too keen an understanding, but I can definitely see how change can be difficult. Hopefully that bridge to communication is improved to be able to move forward, taking the concerns of both parties into account.
the guy in the linked video is absolutely insane. pretending to be an "engineer" while at the same time being the only one to talk about "religion" when it comes to Rust. it's actual madness.
Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
I'm not going to touch the existing DRM scheduler, I'm just going to write my own that is part of the driver. If Nova wants to use it we'll figure out how to make it common Rust code. C drivers can continue to use the broken C one that's already there, and fight the brokenness themselves.
The DRM scheduler is helper code, it's not a core part of the DRM subsystem. You can simply choose not to use it and roll your own. Half of DRM is like this.
(Nova is the new Nvidia driver, and yes, it's written in Rust, so Rust will be mandatory for open source upstream support of new Nvidia GPUs. That's already decided.)
@mawei You're completely misunderstanding what I tried to do... I just tried to fix what arguably are bugs in drm_sched, which didn't change the API at all, they only made it reasonable to use by turning some usages from a crash to handled gracefully. And the maintainer rejected that. Because the only driver he cares about doesn't run into this issue, so he thinks it shouldn't be fixed.
I have seen the same situation in fs realms too, some "not-so-polite" MM guys want to improve their work and pushing new interfaces to fses.
But the main objective of the maintainer for any fs, is to keep their fs working without regression. So migrating to newer interface is not the priority and will only happen gradually.
It wasn't even BUG_ON, it would outright crash and oops... the maintainer said I was using the API wrong, but enforcing using it "right" by his definition without fixing this would require reimplementing half the logic in the scheduler outside of it just to duplicate its functionality enough to track and avoid the problem case. It's nuts. The problem could be easily fixed within the scheduler, it was just a non-intrusive change to one function to correctly handle a particular case.
Reading through the discussion in LWN, I see reasonable arguments as to why there are problems. See e.g. lwn.net/Articles/987817/ (a subthread in that discussion).
@tzafrir I don't think I can take seriously someone who is arguing that my GPU driver which is used by thousands of users and is the backend for the world's first and only OpenGL and Vulkan conformant Apple Silicon driver and also the first FOSS fully reverse engineered GPU driver to achieve OpenGL 4.6 conformance is "an unmerged toy project".
It smacks of what I experienced as a heavy fabrication welder fitter turner. All over again. Old farts refuse to adopt newer safer practices because “we’ve always done it this way and it’s worked for us why do we need to change”.
Aestik from Hooded Traveler Games looks absolutely gorgeous, with some clear Hollow Knight inspiration and may be a good one to play through while you wait for Silksong.
Inspired by Bookworm Adventures, developer Balthazar and publisher 2 Left Thumbs are working on the roguelite word puzzle RPG Sternly Worded Adventures and there's a demo available.
The demo looks very promising! Surprisingly in-depth gameplay, and the interface is extremely customizable. Too bad the "Arachnophobia/-philia" slider is only able to be dragged towards the arachnophobia side for now. I was dying to see what putting it on max arachnophilia would do.
“I have long been struck,” he writes, “by the ingenuity and thoroughness with which wheeled traffic was excluded” from cities such as Rome and Pompeii.
“The entire system of mainly one-way streets, blocked streets, closed streets ... show that traffic flow was not unrestricted,”
These carriages, driven poorly, could also be deadly, another reason for restricting their passage.
แมวเต้ย
in reply to SukinoVERSE • • •SukinoVERSE
in reply to แมวเต้ย • • •