Announcement

Collapse
No announcement yet.

Rust-Written Redox OS 0.8 Released With i686 Support, Audio & Multi-Display Working

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    Originally posted by cb88 View Post

    Obviously... but a side effect is that it forces slightly higher memory use because some "unsafe" methods cannot be used due to those checks. The fact remains that "purely compile time" isn't realistic... an DOES have affect how the runtime works ... after all that's the whole damn point anyway.
    That's not true at all. It doesn't affect the runtime behavior at all, and the compile-time checks actually encourages and makes it easier to develop algorithms that manage their memory efficiently.

    The only affect of the compile-time checks in Rust are the compile-time behavior, and therefore the way that you write software to adhere to the borrowing and ownership model. It either compiles or fails to compile, and that's the extent of the safety checks.

    Unsafe methods don't use less memory than safe ones. Unsafe operations are simply actions like making direct system calls, dereferencing a raw pointer, or accessing data from an array without validating that the data is in bounds.

    These aren't typically being used for the purpose of using less memory. It's to get access to special features like SIMD, low level file operations with the kernel such as io_uring, use of inline assembly, or the implementation of some novel technique in a research paper to create a safe interface for it. That last one is typically verified with Miri to ensure soundness.

    I think you're confusing the bad practice of beginner's cloning memory that doesn't need to be cloned with memory consumption. You don't need to reach for unsafe methods to manage memory efficiently. You just have to understand the aliasing XOR mutability model and design software with that in mind from the start.

    Comment


    • #82
      Originally posted by CochainComplex View Post
      Mh lack of USB mouse support is close to a PR disaster. A quite large group of potentially interested people will not pursue their initial curiosity to have a look at it.
      It's tested on laptops a lot, where the lack of USB mouse is a non-issue.

      Comment


      • #83
        Originally posted by xfcemint View Post

        Oh, the ignoramus of the thread has posted again. Why don't you hide yourself in some hole? Like, shut up, you are out of your league.

        The simple answer: Microkernels allow for a fully closed-source drivers; so manufacturers love to write drivers for microkernels.
        "I'm getting my ass whooped on the licensing point, so I'm just going to make some bullshit up about microkernels"

        Comment


        • #84
          Originally posted by xfcemint View Post

          Oh, the ignoramus of the thread has posted again. Why don't you hide yourself in some hole? Like, shut up, you are out of your league.

          The simple answer: Microkernels allow for a fully closed-source drivers; so manufacturers love to write drivers for microkernels.
          Why don't you come up with a good argument instead of turning this into an abusive insult session?

          ARM is designed primarily for Android, because ARM as a company, is built around an IP model. It's what they do. ARM is a holding company for patents.
          FYI: Android uses the Linux kernel, which is a monolithic kernel, but hardware manufacturers still create drivers and/or firmware for it, so your statement is total bunk. It just so happens that they're closed-source, which Google doesn't seem to mind. ARM on Linux is crap as a result. Even Torvalds doesn't care for it, namely because of there not being a standard firmware interface and the complete bootloader mess along with proprietary binary flashing tools. It's a niche, and hardware manufacturers of various ARM platforms, dev kits, and SBC's usually put out their own out-of-band kernel patches and drivers in a custom distro (just like with Android) because the chip maker won't put out first-party support to kernel.org. If this weren't a fact, you wouldn't need distros like Raspberry Pi OS, Armbian, or NVIDIA's custom Ubuntu image for Tegra. NVIDIA for years didn't want to make open source drivers because of IP. GPL says that IP is "nonsense", but hardware manufacturers don't like that opinion, so they don't build for it and often hardware support requires reverse engineering to get actual support.

          Comment


          • #85
            Originally posted by Anux View Post
            I didn't explain well enough what I meant:
            • If I have a function that adds values I could clone my variable, let 2 threads add values and add the returned values.
            • In C I would simply give the same pointer to both functions and wait till they are done.
            In Rust I had my value memory doubled. And for more complex scenarios I probably run into concurrency problems with my C approach.
            This sounds more like inexperience with Rust. The scenario you're describing could be resolved by using a thread scope to share an immutable reference to an atomic integer on the stack. Threads with a global static lifetime would require wrapping that integer into an Arc. Types larger than an atomic integer can use one of many varieties of thread-safe cell and lock types. From RwLock to QCell. There's a variety of crates out there offering varying ways of achieving interior mutability.

            Comment


            • #86
              Originally posted by xfcemint View Post

              I have given you the "good argument", but you are so ignorant that you failed to realize that licencing issues in a microkernel are different from those that you know of in a monolithic kernel.

              I'm not going to read the rest of your post because your ignorance makes you unable to understand what is relevant in this discussion, and what is not.
              No you haven't. You claimed that hardware manufacturers like to write for microkernels, but as I pointed out, that doesn't explain that hardware manufacturers like to support Android, but not desktop OS Linux-based distros, despite them using the same kernel, that being Linux.

              The difference is in the license, which is what I pointed out from the beginning, not that Android has a microkernel, which it doesn't.

              Comment


              • #87
                Originally posted by xfcemint View Post

                I don't know what has suddenly gotten into you, as you appeared to be quite a rational person a few posts earlier.

                In a microkernel, drivers are just normal applications. They don't need to be under the same licence as the kernel. So, a microkernel can be GPL, and drivers can be closed source. OK?
                The fact is that this has never, ever, been an issue with microkernels. It's entirely speculative.

                You might as well complain about fuse drivers, and yet every commonly used fuse driver is open source. People have a strong preference for open source drivers. They're the ones get picked up into mainline. They're the ones people distribute. They're also the ones that see community improvement.

                It's the real reason why time and time again open source software has won out over closed source software. It's almost NEVER been because companies were compelled to release their code by the GPL. Instead it's the open source software that received community attention and contribution that became superior.

                Even if a company were to try to push a closed source microkernel driver, the fact that it's resting on an open userspace with a defined interface means that every interaction it makes with the hardware can be traced. This makes reverse engineering vastly easier as you have direct introspection into everything the driver does.

                Edit: It's also not like the GPL does you any favors in preventing closed-source drivers. How many years did nvidia ship a closed source driver before begrudgingly opening up? And in the end the driving force was AMD and their open drivers providing a competitive alternative.
                Last edited by Developer12; 25 November 2022, 04:08 PM.

                Comment


                • #88
                  Originally posted by xfcemint View Post

                  So you, the ignoramus of the thread, claim that the only reason why manufacturers like to support Android is the difference in the license. And, we should take the words of ignoramus as granted.
                  Well you could continue to be an asshole.... Or you can come up with a viable reason as to the popularity of Android among ARM hardware OEM's, and answer why those same OEM's don't want to open their driver and firmware modules and submit them to the Linux kernel project to support desktop Linux distros. It has nothing to do with microkernels, despite your attempt at deflection.

                  Otherwise, I stand by my point.

                  Comment


                  • #89
                    Let me bring in a different argument, I can't really take a programming language serious as future technology that is not notated with the clearly superior s-expressions. Clojure was a reasonable attempt to bring forward the superior s-expressions and functional programming into the mainstream, sadly it more or less failed.

                    But it starts even below that, I might overlook somehow no native s-expression support and maybe at some point some s-expression libraries or wrappers like Hy-lang could heal the garbage fortran inspired languages, but not if they are that horrible.

                    Like just to attract dumb C programmers that need C syntax to accept a language they implemented the incorrect block levels of if blocks.

                    https://doc.rust-lang.org/rust-by-ex...l/if_else.html

                    That's as dump as having billions of computer users have to use a layout that was made as compromise for physical typewriters and just so that nobody has to relearn not only have we a stupid qwerty layout, no we also have lines shifted, because otherwise the sticks of the typewriter would have got blocked each other. For that reason only our letters are shiftet vertically per line, so such stupid reasons are used to have worse products.

                    In lisp you have clear that the else is the same block than the if so:
                    Code:
                    (if cond (true-statement) (false-statement))
                    In this case the else part is even implicit but it's part of the true block.

                    Now in fortran style languages that would have to look something like:
                    Code:
                    if{
                      condition cond {
                        true-statement();
                      }
                      else {
                        false-statement();
                      }
                    }
                    If is the parent block to the else block. But because somebody that had no ide but wrote in something like notepad and was to lazy to write the full statement out 60 years or so ago used some "syntax sugar" we all do it today. And since I know it's semantically wrong I can't see it without pulling out my hair. Often also the lambda support of many of this fortran languages is horrible probably the worst example would be python.
                    At least Rust seems to give back the value of the last statement in a block, that is something that allows code that is not with 1000 temporary variables.

                    And there are C-style languages that can do that, while in julia in the examples the if statement is not exactly like my example they have a "end" at the whole if block that surrounds from if -> end. You can have easy small ide tools that parse that while a C or Rust if/else is only parsable by a special case because nothing signals that the if blocks ends after the else block all syntax points to them being 2 separate blocks.

                    But that is just a small example of the problems. In python you are supposed to use some crazy dict lists hack to make up that it's normal control flow sucks so much. (no switch case statement) and if/else is a very code repetitive structure. (especially with multiple ifelse substatements)

                    But again it's not only the bad implementations of the fortran style structures it's the fortran style notation itself, Lisp is just better for functional programming and in most cases functional programming is superiour and you need less names of variables and get more optimised DRY code, and it pushes you to write better code.

                    The only reason to not use s-expression is either habit and what you get socialised in horrible schools / universities or if you use something like notepad to program.

                    Comment


                    • #90
                      Originally posted by xfcemint View Post

                      It appears to me that you don't even know how to read. In a microkernel, there is no need for drivers to be "modules", because drivers can simply run in userspace. That fact makes your sentences about as sensible as if a monkey was randomly typing them.

                      You are the asshole, because you are writing your claims as strong opinions, while at the same time it is obvious to everyone else that you don't have sufficient knowledge to support your strong opinions.
                      You still are trying to make an argument for microkernels. Android IS NOT a microkernel OS. It uses Linux.

                      Comment

                      Working...
                      X