Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Linux

Greg Kroah-Hartman Supports Rust in the Kernel (phoronix.com) 82

Posted by EditorDavid from the core-issues dept.
An anonymous Slashdot reader shared this report from Phoronix: Linux's second-in-command Greg Kroah-Hartman has also been a big proponent of Rust kernel code. He's crafted another Linux kernel mailing list post [Wednesdsay] outlining the benefits of Rust and encouraging new kernel code/drivers to be in Rust rather than C. Greg KH makes the case that the majority of the kernel bugs are due to "stupid little corner cases in C that are totally gone in Rust."
"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years... and who sees EVERY kernel CVE issued, I think I can speak on this topic," Kroah-Hartman began. Here's some excerpts from his remarks. Citing corner cases like overwrites of memory, error path cleanups, use-after-free mistakes and forgetting to check error values, Kroah-Hartman says he's "all for... making these types of problems impossible to hit." That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)... [F]or 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...? Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that...?

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
Kroah-Hartman emphasized later that "a huge majority of the stupid things we do in C just don't happen in the same code implemented in Rust (i.e. memory leaks, error path cleanups, return value checking, etc.) "

The complete thread contains over 140 messages — including Linus Torvalds' observation that " #pragma is complete garbage and should never be used."
This discussion has been archived. No new comments can be posted.

Greg Kroah-Hartman Supports Rust in the Kernel More

Greg Kroah-Hartman Supports Rust in the Kernel

Comments Filter:

  • One of the strongest temptations... (Score:5, Insightful)

    by MpVpRb ( 1423381 ) on Sunday February 23, 2025 @01:57PM (#65189189)

    ...among programmers is to rip it out and start over. I've done this many times, often achieving success
    Problem is that old, crufty code works. It may be imperfect and ugly, but it works and has stood the test of time
    Ripping it out and starting over is always harder than it appears, often a lot harder
    It may fix some old bugs but it often introduces new ones and loses old functionality

    • Re:One of the strongest temptations... (Score:4, Informative)

      by Un-Thesis ( 700342 ) on Sunday February 23, 2025 @02:11PM (#65189235) Homepage

      They are griping about adding a new ABI system that would allow new code to be written in Rust and it just working with the C code.

      C coders are scared that as more and more new code and modules are written in Rust that they will have to be forced to write in a new language, and they're also scared that Rust magic (their words) will do incorrect things and crash every Linux system, open up boxes to hackers, etc.

      • Well, programmers like that should not work on kernels.
        I fooled around with probably a few hundred programming languages in my life.

        I never programmed in Rust, only looked at the documentation. From a syntax point of view it is actually a kind of elegant language, if you can say that for languages that heavily use { } :P

        If I was in a C project and my boss wanted me to switch to Rust for my code, I would do it instantly.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          The main push for Rust is really coming from the Asahi Linux project. Most of their drivers (to support the Apple Mx CPU) are written in Rust.

          The developers of Asahi claim Rust lowers their maintenance overhead of drivers. They're also the originators of the controversial DMA code that created a brouhaha the past few weeks.

          The main reason to keep an open mind is Linux is over 35 years old. It's resisted attempts to have C++ added to it - there have been numerous attempts at doing C++ drivers, but it's never

          • Your points are more or less my points.

            Rust is not as complicated as C++, is not even "really object oriented".

            But it adds nice features, called traits, and removes the need of the new keyword, you just call constructors. That makes GUI code look pretty much more pleasant. It has List and Hash/Set literals, which is pretty convenient, too.

            A programmer who is not interested in looking into "other programming languages" is imho not a programmer.

            Syntax wise it is like C. So, it is not Ada - or Fortran (or Ratf

      • Re: (Score:2)

        by Bert64 ( 520050 )

        One problem with rust is that right now it simply doesn't support all of the platforms that Linux, and by extension gcc/C does.
        You'll be losing support for several niche architectures, and creating a barrier to support for any new architecture.

        • For those systems, you turn off Rust in menuconfig before you compile it.

          Rust isn't part of the core kernel, it's for drivers.

          It does mean *new* drivers being written in rust won't work on old/niche systems

          Not much of a problem.

          • Re: (Score:2)

            by Bert64 ( 520050 )

            Even legacy systems can support modern peripherals, for instance there are numerous USB controllers for the Amiga and for PCI based systems which are still fully compatible with today's USB devices.

            • If only Rust supported the Amiga.
              Oh, it does support the m68k processor, so yes.
              There's also MIPS, RISC V, PPC, Loongarch, s390, and SPARC

              I believe the compiler itself supports anything that LLVM does. The above list is ports of the standard library for each architecture.

        • This is one of the reasons that Rust is being trialed out for drivers where full platform support isn't so relevant. It is also the reason for gcc-rs project which is added a Rust front end to GCC.

      • hey are griping about adding a new ABI system that would allow new code to be written in Rust and it just working with the C code.

        Hm...

        I had thought that the ABI was dynamic to prevent commercial software from relying on a static ABI... and now Rust will force a static ABI?

        Conspiracy theories flow...

    • Re:One of the strongest temptations... (Score:5, Insightful)

      by Gollum ( 35049 ) on Sunday February 23, 2025 @02:19PM (#65189247)

      ...among programmers is to rip it out and start over. I've done this many times, often achieving success
      Problem is that old, crufty code works. It may be imperfect and ugly, but it works and has stood the test of time
      Ripping it out and starting over is always harder than it appears, often a lot harder
      It may fix some old bugs but it often introduces new ones and loses old functionality

      This is not ripping anything out, though. This is allowing simultaneous development in both C and Rust, in order to evaluate the benefits of Rust over C in a real-world project. And, based on the progress so far, both Linus and Greg K-H are seeing benefits, or at the very least, wish for the evaluation to continue. It's a bit hard to argue against the people who are arguably doing the largest amount of work on the kernel, and see all the areas that are or could be affected by it.

      And yes, in the future there may be incremental migration of functionality into Rust code vs C code. It's certainly not going to be soon, and I seriously doubt that it will be rushed. From everything I have seen, the only way it will happen is from the outside in. Code on the periphery will be implemented in Rust, talking to a C/Rust interface to core C code. Slowly, as C clients of the core C code are replaced with equivalent Rust code, that core C code can be migrated to Rust.

      • Re: (Score:2, Interesting)

        by Anonymous Coward
        This is allowing simultaneous development in both C and Rust

        Which requires both C and Rust developers to work together, simultaneously. There's some kind of political element with Rust developers that make this functionally incompatible.

        It was just last week we had a story about a Rust developer rage-quite on LKML from an issue regarding a police force in a country this developer doesn't even live in. Totally unrelated to kernel development and a massive distraction.

        • The developer in this case maintained the noveau drivers. Implemented in C. Likewise, the other developer who quit, main contributions in C. Both developers said that they have been thinking about it for a while, both noted a number of issues.

          This "Rust is all political" stuff just doesn't hold water. If you go onto the Rust language forums, you will see a very helpful environment which is prepared to give people detailed technical explanations. It is one of the kinder and nicer corners of the internet. Eve

          • I honestly don't know why. GO doesn't get it, nor zig; well maybe not yet.

            It probably stems from the Rust code of conduct. The first item is about gender/sexuality etc. so places itself firmly in the political realm. That said, Go and Zig are similar, but maybe came later so didn't capture the social media reaction frenzy in the same way.

            Ultimately Rust is a programming language. You certainly need mores around the community that uses a language, but there seems no need to discuss politics and I'd expect the forums to be 99% technical topics.

            • Oh no, you can't be racist or sexist if you want to be a part of the Rust Foundation community.

              Rust Foundation Code of Conduct:

              We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic. Consequently, we will not tolerate bullying or harassment of anyone, in any form, anywhere within the Foundation’s activities. This Code of Conduct sets out our policy and tells you where you can report violations.

              Linux Kernel Contributor Covenant of Conduct

              In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

              Pretty much the same, huh? Does this mean Linux Kernel is firmly in the political realm too?

              • Pretty much the same, huh? Does this mean Linux Kernel is firmly in the political realm too?

                Right, maybe it doesn't explain it. Note the Linux covenant is a relatively new change, replacing the original "expect criticism but you shouldn't be threatened" with the "protected class" identifiers, and did receive some of the same criticsm. Why do you think Rust gets singled out for this, simple social media irrationality?

                • I honestly have no idea why it creates so much fuss. I think a part of it is just reinforcement. People see others get angry and so also get angry. We have seen this with systemd also. And outside of Linux, putting a picture of a wind turbine seems to likewise cause a vast amount of fuss.

                • It's really just a more explicit version of the original

                  If however, anyone feels personally abused, threatened, or otherwise uncomfortable due to this process, that is not acceptable.

        • Re: (Score:2)

          by _merlin ( 160982 )

          There seems to be at least as much of an attitude issue with the C developers, e.g. see the recent story about Christoph Hellwig throwing a fit because Rust wrappers for the DMA API were being added. He was being completely disingenuous, too. He said that people developing in languages other than C need to deal with the "impedance mismatch" themselves, while blocking their attempt to do just that by adding a proverbial impedance matching transformer.

      • And yes, in the future there may be incremental migration of functionality into Rust code vs C code.

        I'd say incremental migration is where we are now. Drivers are being rewritten in Rust. I expect it will stay in drivers only for a while, though it will probably include some storage and memory-related "drivers" that are very generic and needed by basically every platform.

    • Problem is that old, crufty code works.

      Leaving aside the fact that no one is ripping or replacing anything, your general complaint here is worth digging into? Define "works".
      Do you mean it executes? What if it doesn't tomorrow? Cruft means there's extra complexity and effort which goes into maintaining code in what is objectively an ever changing world.
      Do you mean it is bug free? That's the core of the rust debate here. C has loads of edge cases creating bugs that may go undetected for years, the move to memory safe languages in this sense means

      • One also has to keep in mind that the Linux kernal is a portable piece of software, that runs on hundreds of different hardware architectures.

        In C that means a mace of processor/architecture specific #includes and #ifdefs
        I guess the current limitations off Rust is only the question if it supports that old MIPS processor on my old Palm "clone".

    • Ripping it out and starting over is always harder than it appears, often a lot harder It may fix some old bugs but it often introduces new ones and loses old functionality.

      The current situation is Linux supports Rust drivers. The Linux kernel itself does not have Rust code. So "rippling it out and starting over" does not accurately reflect what is happening. Some existing drivers might be converting to Rust. Some new drivers may start with Rust and not C.

  • Does it have to be Rust? (Score:3)

    by haruchai ( 17472 ) on Sunday February 23, 2025 @01:58PM (#65189195)

    Been hearing very good things about Zig from people who are expert C coders

    • Re: (Score:2)

      by Entrope ( 68843 )

      Work like this, especially on open source projects, usually gets done by the people interested and motivated enough to do it. Is someone pushing for the same kind of kernel support and integration for Zig? (And does Zig provide as many safety guarantees as Rust?)

      • Zig has a different take on memory safety than Rust. Zig has many memory allocation strategies and it strictly enforces memory bounds. It has optionals and slices, and it's strict about not letting you shoot yourself in the foot. What puts Zig ahead is that its C FFI is a first-class concern, so no need for a Zig-specific ABI. It’s also significantly faster than Rust, and it has cross-compilation out of the box. If the move to Rust is for performance, then it's the wrong choice. Zig is 20-50% faster.

        • Re: (Score:2)

          by caseih ( 160668 )

          From what I've read rust is zero overhead and should produce the same fast machine code as c. I can believe zig is just as fast as rust and c but I have a hard time believing rust is 20-50% slower than c or zig. What is the basis for this claim?

          • Re: (Score:2)

            by _merlin ( 160982 )

            There are no zero-cost abstractions [youtube.com]. The video focuses on C++, but the same concepts apply to anything. I think 20-50% slower is almost definitely an abstraction, but various things in Rust do add overhead. One example is that it relies on reference-counted shared pointers a lot, and you need to use weak pointers to avoid leaks from reference loops as it isn't garbage-collected. Updating reference counts uses interlocked memory operations, which have significant overhead. You need to lock a weak point

            • There are no zero-cost abstractions.

              Mildly trollish talk titles are good for clicks, but... that's not what Stroustrup was talking about and it's not what most people mean when they reference him. He was talking about runtime costs, specifically. e.g. a std::vector should be (and is) no slower than mucking around with pointers by hand in C.

              I think 20-50% slower is almost definitely an abstraction, but various things in Rust do add overhead. One example is that it relies on reference-counted shared pointers

              • Re: (Score:2)

                by _merlin ( 160982 )

                Usually we use smart pointers or container types.

                Smart pointers and container types don't work using a genie in a bottle. Take the std::list for example. It's a double-linked list so each element has pointers to the next node and the previous node. The operations that modify these pointers are tightly encapsulated. The std::unique_ptr is a wrapper around a pointer that automatically deletes or assigns null under certain circumstances. Once again, it's a pointer with tightly encapsulated code for managi

            • Re: (Score:2)

              by caseih ( 160668 )

              Except that most of the protections Rust offers are in the compiler! So definitely zero run-time overhead there. Compiling is more expensive. From what I can tell Rust doesn't offer reference counting. Instead it enforces ownership so when something goes out of scope and it is owned by the scope, it's deallocated. Do I understand this wrong?

              I've seen zero evidence that Rust is 20-50% slower than C, and certainly not C++ with it's high overhead.

              • Re: (Score:2)

                by _merlin ( 160982 )

                Yes, Rust (like C++) has automatic unwind, but it still needs ways to manage heap-allocated objects. Rust does provide a reference-counted pointer [rust-lang.org] and a corresponding weak pointer [rust-lang.org]. I'm sure the 20-50% overhead figure is obtained by cherry-picking something that's difficult to do with Rust, much like the tests showing C++ has "high overhead" compared to C invariably end up being cherry-picked or intentionally implemented in a less efficient way.

  • Please (Score:4, Funny)

    by pele ( 151312 ) on Sunday February 23, 2025 @02:01PM (#65189215) Homepage

    Can we have some python too? It's magical.

  • Sometimes you just cannot escape someone else's mistakes. A case that I was called to deal with recently: GCC considers reading a pointer's value as `using' the pointer and starts yelling at the programmer as if the pointer is dereferenced. For instance, with that particular toolchain, invocation of free(3) followed by printing the address that was passed to free(3) triggered -Wuse-after-free.

    • Re: (Score:2)

      by Wyzard ( 110714 )

      A case that I was called to deal with recently: GCC considers reading a pointer's value as `using' the pointer and starts yelling at the programmer as if the pointer is dereferenced.

      GCC is right to give the warning: the C standard [open-std.org] says "the value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime." You might expect that free(p) doesn't modify p itself, and on your platform it might not, but the standard doesn't guarantee that.

      • Re: (Score:2)

        by _merlin ( 160982 )

        Actually, free(p) is guaranteed not to modify p because it's passed by value.

        • Re: (Score:2)

          by bsolar ( 1176767 )

          Actually, free(p) is guaranteed not to modify p because it's passed by value.

          It actually might in some C implementations. E.g. after free the pointer value might become a trap representation. This is because by definition after free the pointer value is indeterminate, so C implementations can do whatever they want with it.

          Since the value of the pointer after free is indeterminate, using it is undefined behaviour and C compilers might do different things depending on implementation. E.g. comparing the freed pointer to another pointer in an if statement might be optimized away as alwa

      • The sudden death of one John Q. Public does not change the fact that he resided recently on Main St. 17 where his body was moved from to be buried somewhere else.

        Please take care to find the definition of the value of a pointer in the document that you referred me to.

        Do not treat standards, esp. a committee draft as Revelation for those are written by humans.

        Errare humanum est, perseverare autem diabolicum.

        • Re: (Score:2)

          by Wyzard ( 110714 )

          Please take care to find the definition of the value of a pointer in the document that you referred me to.

          It doesn't have a definition of the specific phrase "value of a pointer", but 6.2.5 item 20 defines a pointer as "an object whose value provides a reference to an entity of the referenced type." This makes it clear that "value" means the pointer itself, not the thing that it points to.

          (Interestingly, searching for the phrase "value of a pointer" also reveals that the value of a FILE* is indeterminate

  • Language counts! (Score:4, Interesting)

    by david.emery ( 127135 ) on Sunday February 23, 2025 @02:37PM (#65189289)

    Programming languages that prevent these mistakes, detect them at compile-time, and/or generate well-defined runtime behavior (exceptions) have been around for a long time. (Ada 1983 is a good example, but by no means the only one. A lot of the Ada requirements and designs went into preventing or detecting these kinds of mistakes.) I've mentioned before the Bell Labs Technical Journal papers on 5ESS and the errors and mitigation strategies. These typical/chronic errors have been known for a long time: "An Empirical Study of Software Faults Preventable at a Personal Level in a Very Large Software Development Environment", Bell Labs Technical Journal Summer 1997 and " Software Fault Prevention Approach in Coding and Root Cause Analysis", Bell Labs Technical Journal April-June 1998. But they never considered -using a better programming language- (where "better" is by preventing problems through language design, or by detecting problems through compile-time or run-time checking.) Rust is yet another chance to break out from the tyranny of C/C++ and all the problems those languages facilitate. Sure, the expert programmer can produce fault-free C or C++. It takes a lot more than understanding just the language semantics; there's a lot of experience and "do it this way, don't do it that way" that programmers need to learn, usually the hard way.

    But as a profession, I don't think we learn from our mistakes, in large part because we often won't admit the mistakes in the first place.

  • Prove Rust is a problem-free process by forking Linux to a Rust-Only fork, convert it to Rust, and then A/B it.

    Rust was promoted as a C-like language, which it is not. See for your own eyes. It's interesting that the 1970s Basic statement "Let" makes a reappearance. https://en.wikipedia.org/wiki/... [wikipedia.org]

    • Prove Rust is a problem-free process by forking Linux to a Rust-Only fork, convert it to Rust, and then A/B it.

      Yep, nothing like A/B performance testing.
      My bet is: Rust Kernel will require ~4x memory space (assuming same features / modules). Result in more page swapping between memory and cache. And it will bog down far worse than C Kernel when active processes exceeds 3x processor nodes.

    • Prove Rust is a problem-free process by forking Linux to a Rust-Only fork, convert it to Rust, and then A/B it.

      No one has said ever said Rust would provide a "problem-free process". No one. The design of Rust appears to solve some problems that comes with C. Currently Linux is testing whether Rust provides any benefits by allowing drivers to be written in Rust.

      Rust was promoted as a C-like language, which it is not. See for your own eyes.

      From your own link: the only "C-like" reference is from this The Register article [theregister.com] by Liam Proven who is a journalist and not part of the Rust foundation. So who is "promoting" that again?

    • Re: (Score:1)

      by _merlin ( 160982 )

      Your arguments are getting more ridiculous each time. Last time you were trying to claim C was "made for Linux [slashdot.org]". This is even more stupid. BASIC is not the only language that uses a keyword to introduce variable declarations. For example Pascal uses the var keyword for this purpose. That aside, complaining about minor syntax differences sounds like you have no real arguments against Rust. Are you just trolling?

  • I agree with him in principle, but this is also a very odd approach to problem solving. He is ignoring other solutions to the identified problems. If the issues he is calling out could be caught by AI-driven lint use, is there really a problem to solve that justifies the additional problems of mixed language use?

    • "AI-driven lint..." Huh. Can you be specific about a product, its capabilities, and its limitations? Or is this just the projection of expectations to justify an existing decision?

      Me, I strongly favor solutions that PREVENT errors, rather than depending on outside tools or even testing to DETECT them. (And that started with using a debugger. For me, having to resort to a debugger was an admission that "I didn't know what the code was doing." But I guess that's just me.)

      Every significant system I worke

    • The thing that gets me with this discussion is that switching to Rust (or any other language) to address the problems that arise when using C fails to address the question of why those problems exist when using C.

      That is to say: the problem isn't in the language, because the language can be used properly - that is, the language doesn't "give rise" to the issues, it merely permits them to exist.

      So the question is - what insufficient mental models or processes exist that cause people to use C in a way that re

      • So the question is - what insufficient mental models or processes exist that cause people to use C in a way that results in hazards?

        See the first of the two BLTJ papers I referenced.

  • All of these problems already--just so that Rust people can claim it's good enough to write Linux.

    • This is Linux people claiming Rust is good enough to write Linux drivers in Rust. Which I happen to agree with, having some expertise in both.

      Unlike a dull thud such as yourself who apparently gets a boner from shooting off their mouth on a subject in which their competence rounds to zero.

  • https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/
    TLDR:
    C maintainers have no say in clients for their interfaces - if want to have a say in rust or any other client of their interface then be a part of that project too

  • Rust is in perpetual beta (Score:3)

    by Hentes ( 2461350 ) on Sunday February 23, 2025 @03:59PM (#65189551)

    I actually like the idea of Rust, I always thought that we really need a modern low level C replacement, something like what Ada tried to be just not shit and based on RAII principles, and Rust is pretty much that. But it has no place in the kernel. The problem is that even though Rust was made by Mozilla, it feels more like a Google product, it's a programming language that is in perpetual beta. I remember the outcry when Python 3 broke backwards compatibility, and how it took 15 years to get everybody to migrate, even though it was managed very well from Python's part. When Perl 6 broke compatibility, they had to admit defeat and fork a new language because people refused to migrate. Yet the same people who were constantly bitching about it are now embracing Rust, a language that breaks backwards compatibility every other year. I understand that sometimes you need change otherwise you will end up with the unholy mess that is C++, but there has to be middle ground. Rust shouldn't be let near the kernel until it becomes a stable language.

    • The problem is that even though Rust was made by Mozilla, it feels more like a Google product, it's a programming language that is in perpetual beta. I remember the outcry when Python 3 broke backwards compatibility, and how it took 15 years to get everybody to migrate, even though it was managed very well from Python's part.

      When was the last breaking change in Rust, and what was it?

      • Just wondering, where I could obtain a copy of the standard definition of the language How can I command the compiler to adhere to a particular revision of such a standard?

        • Just wondering, where I could obtain a copy of the standard definition of the language How can I command the compiler to adhere to a particular revision of such a standard?

          The Rust Reference Manual [rust-lang.org] provides the language definition.

          As for versioning, you can use rust-version in your cargo.toml file to specify the minimum version. This doesn't instruct the compiler to change behavior, but will cause the build to fail if the compiler doesn't meet the requirements.

          • Oh, that book has informally twice on the first page. Its writers, apparently, cannot tell a college textbook from a standard.

            Minimal version is not the same as strict standard compliance. Sorry, but industry does not like surprises.

  • NO (Score:1)

    by Anonymous Coward
    Just admit you're a shitty coder and shut the fuck up.

  • If arguably the best C programmers in the world, subjected to the most intense scrutiny by their peers still make errors like calling null pointers, double frees, buffer overflows etc. then what chance does anyone else have? The same goes for C++.

    So I'm not surprised if they see Rust as a way to mitigate for such errors by using a language that eliminates these issues by design and has a compiler which does things like borrow & lifetime checking.

Slashdot Top Deals

All power corrupts, but we need electricity.

Close