[HN Gopher] Greg K-H: "Writing new code in Rust is a win for all...
___________________________________________________________________
Greg K-H: "Writing new code in Rust is a win for all of us"
Author : mustache_kimono
Score : 245 points
Date : 2025-02-19 12:12 UTC (1 days ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| mustache_kimono wrote:
| But for new code / drivers, writing them in Rust where these
| types of bugs just can't happen (or happen much much less) is a
| win for all of us, why wouldn't we do this? -- greg k-h
| uecker wrote:
| The question is to what extend this is true - given that Rust
| programmers also make stupid mistakes (e.g.
| https://rustsec.org/advisories/RUSTSEC-2023-0080.html) that
| look exactly like C bugs. Not that I think Rust does not have
| advantages in terms of safety, but probably not as much as some
| people seem to believe when making such arguments. The other
| question is at what cost it comes.
| pajko wrote:
| https://www.cve.org/CVERecord/SearchResults?query=rust
| steveklabnik wrote:
| Some of these CVEs only exist because Rust takes security
| seriously. There was a filesystem bug: https://blog.rust-
| lang.org/2022/01/20/cve-2022-21658.html
|
| This impacted C++'s standard library as well, but since the
| standard says it's undefined behavior, they said "not a
| bug" and didn't file CVEs.
|
| Nobody believes that Rust programs will have zero bugs or
| zero security vulnerabilities. It's that it can
| significantly reduce them.
| orf wrote:
| Christoph Hellwig seems fun to interact with. He drive-by posts
| the same, repeated points and seemingly refuses to engage with
| any replies.
| rendaw wrote:
| AFAICT his only response in that thread:
|
| > Right now the rules is Linus can force you whatever he wants
| (it's his project obviously) and I think he needs to spell that
| out including the expectations for contributors very clearly.
|
| >
|
| > For myself I can and do deal with Rust itself fine, I'd love
| bringing the kernel into a more memory safe world, but dealing
| with an uncontrolled multi-language codebase is a pretty sure
| way to get me to spend my spare time on something else. I've
| heard a few other folks mumble something similar, but not
| everyone is quite as outspoken.
|
| He gets villianized and I don't think all his interactions were
| great, but this seems pretty reasonable and more or less in
| line with what other people were asking for (clearer direction
| from Linus).
|
| That said, I don't know, maybe Linus's position was already
| clear...
| buttercraft wrote:
| Maybe, but "spreads like cancer" is not part of a well-
| reasoned technical discussion, but of an emotional one.
| sph wrote:
| In many languages, like Italian which I am a native speaker
| of, to "spread like a cancer" doesn't have the negative
| subtext of the English idiom. It just means it spreads,
| wildly, uncontrollable. In English it gets muddled with the
| very negative idiom of "being a cancer", i.e. being very
| bad if not fatal.
| indrora wrote:
| I think it's because in English-speaking places (I'll say
| "The US and some rounding errors" to be explicit) the
| fact is that for a long time, cancer was a death
| sentence. This led to anything that is hard to kill as
| being called cancerous and the avoidance of such things
| is important (yes, this is where you chuckle and mime
| smoking a cigarette. There's still a population of the US
| that believes "smoking causes cancer" is a conspiracy by
| Big Pharma to push more cancer treatments or some
| bullshit like that.)
|
| Calling something "cancerous" is to say it was an
| incurable disease that unless stamped out with some
| amount of precision will continue to cause rot and decay.
| Be it correct or not, saying "The cancer that is killing
| HN" is pointing a finger at a problem and scapegoating
| all the other problems onto it.
| TheFuzzball wrote:
| You're confusing language that causes a strong emotional
| response within you, with language that was written by a
| person experiencing strong emotion.
|
| It's colourful language for sure, but gimme a break.
| Dylan16807 wrote:
| Building part of an "emotional discussion" doesn't
| require the author to be experiencing particularly strong
| emotions as they write it.
|
| Not that you have evidence of the author's state of mind?
|
| I don't think the confusion you describe is happening.
| hitekker wrote:
| That's a good distinction, and it pretty much captures
| the exchange. Both sides felt quite strongly; Helwig used
| strong words. But that doesn't mean either side was
| unreasonable, despite some of us commenters being
| discomforted.
| dang wrote:
| Please don't cross into personal attack in HN threads.
|
| I'm not saying it's never accurate*, it's just that, if you
| evaluate them through the site guidelines, the cost/benefit is
| negative.
|
| https://news.ycombinator.com/newsguidelines.html
|
| * (not a comment on this or any person)
| MalseMattie wrote:
| This statement was sorely needed for this discussion to move
| forward. Hopefully the last section fills the needed parties with
| resolve
| dfawcus wrote:
| The impression I get from simply reading these various
| discussions, is that some folks are not convinced that the pain
| from accepting Rust is worth the gain.
|
| Possibly also that a significant portion of the suggested gain
| may be achievable via other means.
|
| i.e. bounds checking and some simple (RAII-like)
| allocation/freeing simplifications may be possible without rust,
| and that those are (from the various papers arguing for Rust /
| memory safety elsewhere) the larger proportion of the safety bugs
| which Rust catches.
|
| Possibly just making clang the required compiler, and adopting
| these extension may give an easier bang-for-buck:
| https://clang.llvm.org/docs/BoundsSafety.html
|
| Over and above that, there seem to be various complaints about
| the readability and aesthetics of Rust code, and a desire not to
| be subjected to such.
| mustache_kimono wrote:
| > The impression I get from simply reading these various
| discussions, is that some folks are not convinced that the pain
| from accepting Rust is worth the gain.
|
| Read the above email. Greg KH is pretty certain it is worth the
| gain.
|
| > Possibly also that a significant portion of the suggested
| gain may be achievable via other means.
|
| I think this is a valid POV, if someone shows up and does the
| work. And I don't mean 3 years ago. I mean -- now is as good a
| time as any to fix C code, right? If you have some big fixes,
| it's not like the market won't reward you for them.
|
| It's very, very tempting to think there is some other
| putatively simpler solution on the horizon, but we haven't seen
| one.
|
| > Over and above that, there seem to be various complaints
| about the readability and aesthetics of Rust code, and a desire
| not to be subjected to such.
|
| No accounting for taste, but I don't think C is beautiful! Rust
| feels very understandable and explicit to my eye, whereas C
| feels very implicit and sometimes inscrutable.
| 0x457 wrote:
| I think it's because C devs often think that they never make a
| mistake, so they see rust bringing on value.
|
| I had an argument about rust with a freebsd developer that had
| the same "I never make a mistake" attitude. I've made a PR to
| his project that fixes bugs that weren't possible in rust to
| being with. Not out of petty, but because his library was
| crashing my application. In fact, he tried to blame my rust
| wrapper for it when I raised an issue.
| mimd wrote:
| If you look at the CVE lists, about 70-80% of all c memory bugs
| are related to OOB Read and Write. Additionally, like rust,
| fbounds-safety can remove redundant checks if it can determine
| the bounds. My question is how likely can it be adopted in the
| kernel (likely high).
|
| I will need to read their conversations more to see if it's the
| underlying fear, but formalization makes refactoring hard and
| code brittle (ie. having to start from scratch on a formal
| proof after substantially changing a subsystem). One of the key
| benefits of C/Kernel have been their malleability to new
| hardware and requirements.
| whytevuhuni wrote:
| > My question is how likely can it be adopted in the kernel
| (likely high).
|
| My guess is, it cannot. The way -fbounds-safety works, as far
| as I understand, is that it aborts the program in case of an
| out-of-bounds read or write. This is similar to a Rust panic.
|
| Aborting or panicking the kernel is absolutely not a better
| alternative to simply allowing the read/write to happen, even
| if it results in a memory vulnerability.
|
| Turning people's computer off whenever a driver stumbles on a
| bug is not acceptable. Most people cannot debug a kernel
| panic, and won't even have a way to see it.
|
| Rust can side-step this with its `.get()` (which returns an
| Option, which can be converted to an error value), and with
| iterators, which often bypass the need for indexing in the
| first place.
|
| Unfortunately, Rust can still panic in case of a normal
| indexing operation that does OOB access; my guess is that the
| index operation will quickly be fixed to be completely
| disallowed in the kernel as soon as the first such bug hits
| production servers and desktop PCs.
|
| Alternatively, it might be changed to always do buf[i %
| buf.size()], so that it gives the wrong answer, but stays
| within bounds (making it similar to other logic errors, as
| opposed to a memory corruption error).
| mimd wrote:
| Yes, panicking in kernels is bad. I've followed the whole
| R4L fight about working around it.
|
| https://github.com/apple-oss-
| distributions/xnu/blob/main/doc...
|
| https://github.com/apple-oss-
| distributions/xnu/blob/main/doc...
|
| Upstream fbounds in xnu has options for controlling if it
| panics or is just a telemetry event. They are in a kernel
| situation and have the exact same considerations on trying
| to keep the kernel alive.
| whytevuhuni wrote:
| Ah, thank you. If it can just do the equivalent of
| WARN_ON_ONCE(...) and continue, and the check wouldn't be
| slow enough to make people disable it, then yeah, that
| sounds really good.
| mimd wrote:
| https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-
| May11/...
|
| Supposedly ~5% (1-29%), but I'm testing my own projects
| to verify (my guess is higher at 10-20%, but will depend
| on the code). Supposedly it's to land in gcc at some
| point but I dunno the time table.
| uecker wrote:
| For GCC I have a patch (maybe 10 lines of code) that emits
| a warning whenever the compiler inserts a trap. You could
| use a sanitizer, i.e. bounds checking or signed overflow,
| add code that turns the warning into an error, and so
| ensure that your code does not have a signed overflow or
| OOB.
| viraptor wrote:
| > Possibly also that a significant portion of the suggested
| gain may be achievable via other means.
|
| Things like that have been said many times, even before Rust
| came around. You can do static analysis, you can put in
| asserts, you can use this restricted C dialect, you can...
|
| But this never gets wider usage. Even if the tools are there,
| people are going to ignore them.
| https://en.wikipedia.org/wiki/Cyclone_(programming_language)
| started 23 years ago...
|
| It took us decades to get to non executable stack and W^X and
| there are still occasional issues with that.
| stpedgwdgfhgdd wrote:
| No pain, no gain
| anonnon wrote:
| > > > > > David Howells did a patch set in 2018 (I believe) to
| clean up the C code in the kernel so it could be compiled with
| either C or C++; the patchset wasn't particularly big and mostly
| mechanical in nature, something that would be impossible with
| Rust. Even without moving away from the common subset of C and
| C++ we would immediately gain things like type safe linkage.
|
| > > >
|
| > > > That is great, but that does not give you memory safety and
| everyone
|
| > > > would still need to learn C++.
|
| > >
|
| > > The point is that C++ is a superset of C, and we would use a
| subset of C++
|
| > > that is more "C+"-style. That is, most changes would occur in
| header files,
|
| > > especially early on. Since the kernel uses a _lot_ of inlines
| and macros,
|
| > > the improvements would still affect most of the _existing_
| kernel code,
|
| > > something you simply can't do with Rust.
|
| I have yet to see a compelling argument for allowing a completely
| new language with a completely different compiler and toolchain
| into the kernel while continuing to bar C++ entirely, when even
| just a restricted subset could bring safety- and maintainability-
| enhancing features _today_ , such as RAII, smart pointers,
| overloadable functions, namespaces, and templates, and do so
| using the existing GCC toolchain, which supports even recent
| vintages of C++ (e.g., C++20) on Linux's targeted platforms.
|
| Greg's response:
|
| > But for new code / drivers, writing them in rust where these
| types of bugs just can't happen (or happen much much less) is a
| win for all of us, why wouldn't we do this? C++ isn't going to
| give us any of that any decade soon, and the C++ language
| committee issues seem to be pointing out that everyone better be
| abandoning that language as soon as possible if they wish to have
| any codebase that can be maintained for any length of time.
|
| side-steps this. Even if Rust is "better," it's much easier to
| address at least some of C's shortcomings with C++, and it can be
| done without significantly rewriting existing code, sacrificing
| platform support, or the incorporation of a new toolchain.
|
| For example, as pointed out (and as Greg ignored), the kernel is
| replete with macros--a poor substitute for genuine generic
| programming that offers no type safety and the ever-present
| possibility for unintended side effects due to repeated
| evaluation of the arguments, e.g.:
|
| #define MAX(x, y) (((x) > (y)) ? (x) : (y))
|
| One need only be bitten by this kind of bug once to have it color
| your perception of C, permanently.
| bsder wrote:
| > For example, as pointed out (and as Greg ignored), the kernel
| is replete with macros--a poor substitute for genuine generic
| programming that offers no type safety and the ever-present
| possibility for unintended side effects
|
| I never thought I would say that C++ would be an improvement,
| but I really have to agree with that.
|
| Simply adopting the generic programming bits with type safety
| without even objects, exceptions, smart pointers, etc. would be
| a huge step forward and a lot less disruptive than a full step
| towards Rust.
| rincebrain wrote:
| At this point, I think that would be a misstep.
|
| I'm not sure I have an informed enough opinion of the
| original C++ debate, but I don't think stepping to a C++
| subset while also exploring Rust is a net gain on the
| situation, and has the same kinds of caveats as people who
| are upset at R4L complain about muddling the waters, while
| also being almost entirely new and untested if introduced
| now[1].
|
| [1] - I'm pretty sure some of the closed drivers that do the
| equivalent of shipping a .o and a shim layer compiled have
| C++ in them somewhere sometimes, but that's a rounding error
| in terms of complexity testing compared to the entire tree.
| mustache_kimono wrote:
| > Even if Rust is "better," it's much easier to address at
| least some of C's shortcomings with C++
|
| This simply forgets all the problems C++ has as a kernel
| language. It's really an "adopt a subset of C++" argument, but
| even that has its flaws. For instance, no one wants exceptions
| in the Linux kernel and for good reason, and exceptions are,
| for better or worse, what C++ provides for error handling.
| anonnon wrote:
| > It's really an "adopt a subset of C++" argument, but even
| that has its flaws. For instance, no one wants exceptions in
| the Linux kernel and for good reason
|
| Plenty of C++ codebases don't use exceptions at all,
| especially in the video game industry. Build with GCC's -fno-
| exceptions option.
|
| > and exceptions are, for better or worse, what C++ provides
| for error handling.
|
| You can use error codes instead; many libraries, especially
| from Google, do just that. And there are more modern
| approaches, like std::optional and std::expected:
|
| https://en.cppreference.com/w/cpp/utility/optional
|
| https://en.cppreference.com/w/cpp/utility/expected
| mustache_kimono wrote:
| > You can use error codes instead; many libraries,
| especially from Google, do just that. And there are more
| modern approaches, like std::optional and std::expected:
|
| Even if we are to accept this, we'd be back to an "adopt a
| subset of C++" argument.
|
| You're right in one sense -- these _are_ more modern
| approaches to errors, which were adopted in 2017 and 2023
| respectively (with years for compilers to implement...).
| But FWIW we should note that these aren 't really idiomatic
| C++, whereas algebraic data types is a baked in, 1.0,
| feature of Rust.
|
| So -- you really don't want to adopt C++. You want to adopt
| a dialect of C++ (perhaps the very abstract notion of
| "modern C++"). But your argument is much more like "C++ has
| lambdas too!" than you may care to admit. Because of course
| it does. C++ is the kitchen sink. And that's the problem.
| You may want the smaller language inside of C++ that's
| dying to get out, but C++'s engineering values are actually
| "we are the kitchen sink!". TBF Rust's values are sometimes
| distinct too, but I'm not sure you've really examined just
| how different C++'s values are from kernel C, and why the
| kitchen sink might be a problem for the Linux kernel.
|
| You say:
|
| > RAII, smart pointers, overloadable functions, namespaces,
| and templates, and do so using the existing GCC toolchain
|
| _" Modern C++" simply doesn't solve the problem_. Google
| has been very clear Rust + C++ codebases have worked well.
| But the places where it sees new vulnerabilities are mostly
| in new memory unsafe (read C++) code.
|
| See: https://security.googleblog.com/2024/09/eliminating-
| memory-s...
| 112233 wrote:
| And -fno-exceptions, while being de-facto standard e.g. in
| gamedev, still is not standard C++ (just look how much STL
| stuff in n4950.pdf is specified as throwing, most of those
| required for freestanding too (16.4.2.5)).
|
| And you cannot just roll your own library in a standard
| compliant way, because it contains secret compiler juice
| for, e.g. initializer_list or coroutines.
|
| And once you use your own language dialect (with -fno-
| exceptions), who is to stop you from "customizing" other
| stuff, too?
| mimd wrote:
| Isn't this a bait and switch, that all the c kernel devs were
| complaining about? That it wouldn't be just drivers but also all
| new kernel code? The lack of candor over the goal of R4L and
| downplaying of other potential solutions should give any
| maintainer (including potential rust ones) pause.
|
| Anyway, why just stop at rust? If we really care about safety,
| lets drop the act and go make everyone do formal methods. Frama-C
| is at least C, has a richer contract language, has heavy static
| analysis tools before having to go to proofs, is much more
| proven, and the list goes on. Or, why not add Spark to the
| codebase if we are okay with mixing langs in the codebase? Its
| very safe.
| AlotOfReading wrote:
| Frama-C doesn't actually prove memory safety and has a huge
| proof hole due to the nature of UB. It gives weaker guarantees
| than Rust in many cases. It's also _far_ more of a pain to
| write. The Frama-C folks have been using the kernel as a
| testbed for years and contributing small patches back. The
| analysis just doesn 't scale well enough to involve other
| people.
|
| Spark doesn't have an active community willing to support its
| integration into the kernel _and_ has actually been taking
| inspiration from Rust for access types. If you want to rustle
| up a community, go ahead I guess?
| gizmondo wrote:
| For it to be bait and switch someone should've said "Rust will
| forever be only for drivers". Has anyone from the Linux
| leadership or R4L people done that? To my knowledge it has
| always been "for now".
| mimd wrote:
| "But for new code / drivers..." encompasses more than just
| "drivers" and refers to all new code. I doubt it's a mistake
| either due to the way the rest of the email is written. And
| Greg said "no one sane ever thought that (force anyone to
| learn rust)" just 5 months ago
| (https://lkml.org/lkml/2024/8/29/312). But he is now telling
| his C devs they will need to learn and code rust to make new
| code in the kernel.
| p_ing wrote:
| > the C++ language committee issues seem to be pointing out that
| everyone better be abandoning that language as soon as possible
|
| What is he referring to?
| jcranmer wrote:
| I can think of several issues with the C++ committee that
| people can reasonably point to (some of them mutually
| contradictory even!), but I have no idea which of them is being
| referred to. It's possible he's referring to profiles, which is
| one of those cases where there's mutually contradictory
| criticisms that can be leveled against it so I have no idea in
| that case if he thinks they're a good or a bad thing.
|
| Personally, the biggest issue that gives me fear for C++'s
| future is that the committee seems to have more or less stopped
| listening to implementer feedback and concerns.
| chris_wot wrote:
| "he C++ language committee issues seem to be pointing out that
| everyone better be abandoning that language as soon as possible
| if they wish to have any codebase that can be maintained for any
| length of time."
|
| I'd love to know where he got this impression. The new C++
| features go a long way to helping make the language easier, and
| safer, to use.
| chris_wot wrote:
| "Rust also gives us the ability to define our in-kernel apis in
| ways that make them almost impossible to get wrong when using
| them. We have way too many difficult/tricky apis that require way
| too much maintainer review just to "ensure that you got this
| right" that is a combination of both how our apis have evolved
| over the years"
|
| Funny, that's not Theodore T'so's position. The Rust guys tried
| to ask about interface semantics and he yelled at them:
|
| https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s
| darksaints wrote:
| I've been using Linux since 2005, and I've loved it in almost
| every circumstance. But the drama over the last couple of years
| surrounding Rust in the kernel has really soured me on it, and
| I'm now very pessimistic about its future. But I think beyond the
| emotional outbursts of various personalities, I don't think that
| the problem is which side is "right". Both sides have extremely
| valid points. I don't think the problem is actually solvable,
| because managing a 40M+ SLoC codebase is barely tenable in
| general, and super duper untenable for something that we rely on
| for security while running in ring 0.
|
| My best hope is for replacement. I think we've finally hit the
| ceiling of where monolithic kernels can take us. The Linux kernel
| will continue to make extremely slow progress while it deals with
| internal politics fighting against an architecture that can only
| get bigger and less secure over time.
|
| But what could be the replacement? There's a handful of fairly
| mature microkernels out there, each with extremely immature
| userspaces. There doesn't seem to be any concerted efforts behind
| any of them. I have a lot of hope for SeL4, but progress there
| seems to be slow mostly because the security model has poor
| ergonomics. I'd love to see some sort of breakout here.
| bigfatkitten wrote:
| > I have a lot of hope for SeL4, but progress there seems to be
| slow mostly because the security model has poor ergonomics.
|
| seL4 has its place, but that place is not as a Linux
| replacement.
|
| Modern general purpose computers (both their hardware, and
| their userspace ecosystems) have too much unverifiable
| complexity for a formally verified microkernel to be really
| worthwhile.
| darksaints wrote:
| I agree that SeL4 won't replace Linux anytime soon, but I beg
| to differ on the benefits of a microkernel, formally verified
| or not.
|
| Any ordinary well-designed microkernel gives you a huge
| benefit: process isolation of core services and drivers. That
| means that even in the case of an insecure and unverified
| driver, you still have reasonable expectations of security.
| There was an analysis of Linux CVE's a while back and the
| vast majority of critical Linux CVEs to that date would
| either be eliminated or mitigated below critical level just
| by using a _basic microkernel architecture_ (not even a
| verified microkernel). Only 4% would have remained critical.
|
| https://microkerneldude.org/2018/08/23/microkernels-
| really-d...
|
| The benefit of a verified microkernel like SeL4 is merely an
| incremental one over a basic microkernel like L4, capable of
| capturing that last 4% and further mitigating others. You get
| more reliable guarantees regarding process isolation, but
| architecturally it's not much different from L4. There's a
| little bit of clunkiness for writing userpace drivers for
| SeL4 that you wouldn't have for L4. That's what the LionsOS
| project is aiming to fix.
| zozbot234 wrote:
| Process isolation of drivers is just not very useful when
| the driver is interfacing with a device that has full
| access to system memory. Which is the case for many devices
| today unless you use IOMMU to prevent this.
| darksaints wrote:
| The SeL4 microkernel specification assumes the use of a
| memory management unit, and is required by default.
|
| https://docs.sel4.systems/projects/sel4/frequently-asked-
| que...
| yencabulator wrote:
| Oh don't worry, seL4 isn't formally proven on any multicore
| computer anyway.
|
| And the seL4 core architecture is fundamentally "one single
| big lock" and won't scale at all to modern machines. The
| intended design is that each core runs its own kernel with no
| coordination (multicore, a la Barrelfish) -- none of which is
| implemented.
|
| So as far as any computer with >4 cores is concerned, seL4 is
| not relevant at this time, and if you wish for that to happen
| your choice is really either funding the seL4 people or
| getting someone else to make a different microkernel (with
| hopefully a lot less CAmkES "all the world is C" mess).
| raspyberr wrote:
| GNU Mach! GNU Mach! GNU Mach! GNU Mach! GNU Mach! GNU Mach!
| infogulch wrote:
| The actual project is "lets modernize the internal kernel api
| surface", and "how tolerable is it to write against this api in
| rust" is just the best metric at hand to measure the progress.
|
| This is the correct frame for RFL proponents. You're welcome.
| lousken wrote:
| I wonder how Microsoft implements rust in their kernel.
|
| As for this issue, it's just a nature of any project, people will
| come and go regardless, so why not let those C developers leave
| and keep the rust folks instead? At some point you have to steer
| the ship and there will always be a group of people unhappy about
| the course
| 000ooo000 wrote:
| MBA moment
| bigfatkitten wrote:
| Alternatively, there's nothing preventing the Rust folks
| building their own kernel from the ground up.
| voidr wrote:
| We should have seen this post before Hector Martin got so fed up
| that he decided to resign(to be fair, he probably had other
| issues as well that contributed).
|
| I was very confused by the lack of an actual response from Linus,
| he only said that social media brigading is bad, but he didn't
| give clarity on what would be the way forward on that DMA issue.
|
| I have worked in a similar situation and it was the worst
| experience of my work life. Being stonewalled is incredibly
| painful and having weak ambiguous leadership enhances that pain.
|
| If I were a R4L developer, I would stop contributing until Linus
| codifies the rules around Rust that all maintainers would have to
| adhere to because it's incredibly frustrating to put a lot of
| effort into something and to be shut down with no technical
| justification.
| daft_pink wrote:
| It's hard. Most people agree it should have memory safety, but
| also I'm not looking to become a full scale maintainer either.
___________________________________________________________________
(page generated 2025-02-20 23:00 UTC)