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

[Waethorn]

I think you should do to some kind of medical check-up. Your gears are malfunctioning.



Nope, the original point of contention is in an earlier post.

Your gears are malfunctioning. Please do a checkup.

Despite your abusive insults, you have nothing to back up your claim that "manufacturers love to write drivers for microkernels". There is no statistic that you can point to that backs this up whatsoever.

[Waethorn]

Let's get back to the original point of contention:

manufacturers love to write drivers for microkernels.

Where's your proof of this?

[Waethorn]

The first problem is that you can't use Android vs main-tree Linux as an example because Redox OS (a microkernel) can alow drivers to stay under closed-source licenses, unlike the main-tree Linux kernel, where manufacturers are forced to open-source their drivers.

That statement EXACTLY backs up my point. Android has a different license than desktop Linux, which is what makes it popular among hardware manufacturers, which I will more-specifically name as the ARM SoC makers. Those same manufacturers, I might add, that have drivers for their chips for Android, but refuse to open source them for desktop Linux because they don't want to disclose their IP. GPL is not attractive to them because of that fact. Android, Windows, MacOS, iOS, all with permissive driver code licenses, are all more popular with hardware manufacturers. Your original statement to say that hardware manufacturers prefer open source licenses has been sufficiently debunked.

Android is ALSO, NOT a microkernel OS. You bringing up the point that Redox is, contains nothing to support your counter-claim to my statement.

The second problem is that you claim that Android is popular only because of licensing terms, but you are disregaring all the other possible factors.

You are writing complete nonsense.

And yet you provide no "other possible factors". Who's writing nonsense now?

[Waethorn]

We are talking here about the Redox OS (it's in the title). Redox OS uses a microkernel. You keep mentioning Android for some reason that makes absolutely no sense or relevance. What's wrong with your head, I can't figure out.

EDIT: I just can't believe what an idiot this Waethorn is. He just made me check the title of the thread, because I was thinking that I might have been posting in the wrong thread.

I stated that hardware vendors like to write drivers for closed source operating systems using Android as an example. I could've used Windows as an example too, but I had mentioned ARM because that's the biggest "Linux"-supported hardware base right now (I was mentioning hardware vendor support for GPL vs BSD license permissability), just like how Mac is the biggest Unix hardware base right now, which is a bigger desktop *nix user base than desktop Linux. MacOS is the most successful commercial Unix product ever, and XNU is NOT a microkernel either, nor is it GPL. Your little statement about microkernels is a deflection, and means nothing. I could literally make a chart and show you your arguments versus mine with checkmarks to who proved their point, and you wouldn't have any.

[Waethorn]

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.

[blackiwid]

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:

(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:

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.

[Waethorn]

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.

[Developer12]

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.

[Waethorn]

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.

[mmstick]

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.