Redox OS and GhostBSD - fork

[arcmatrixnt]

Hello, I have seen an interesting new kernel of the RedoxOS project. Because of its characteristics, it would not be interesting to merge the projects in substitution of what you have in the FreeBSD Kernel to take advantage of the new features of the Kernel Redox but without stopping using the advantages in the modules present in FreeBSD, what do you think?

Of course, this would only be interesting if you were friendly to work with that idea, that is, do not bring an unnecessary burden of difficulty and be largely advantageous. That is, assuming the initial problems of FreeBSD could be mitigated and it was still possible to bring new drivers as well as "dock" what already exists. Exemplifying, as long as it is easier to bring the latest Gnome Shell 3.x or KDE Plasma also upgraded and fully functional without having devastating performance gambiarras and bug breeding.

The fight for the best way to have a protection without being a patent, because of the costs of its maintenance. They created the GPL. But it is bad for the industry that can only survive when it "hides" the source code because it came from a job where several dollars were spent with a development team.

I have an idea of ​​becoming more profitable Operating System, hence the difficulty of wondering if an idea would be enough for it to be taken into account or rewarded. Well, this is difficult and goes against whether the license is MIT, BSD, GPL or EULA. Anyone has the right to ignore the author of the idea. But I know that to grow, a new Operating System needs to be: user friendly to any application, robust without abrupt drops and allow good hours of fun (games, games and games). Thanks for listening.

[Hecktor]

That is a fairly aggressive request. Requesting a whole new operating system be built from scratch as a feature request.

If RedoxOS is being built from scratch, what use would trying to force FreeBSD into the mix be? Wouldn't you just incorporate the features you want as you are building RedoxOS from scratch? And if you are introducing only the RedoxOS kernel into FreeBSD, it would break almost everything and take huge effort to get it to have less functionality than FreeBSD. Look at Debian with a FreeBSD kernel, basically a dead project.

[arcmatrixnt]

Yes, I fully agree. I thought about these efforts exactly when they mix a kernel with another project. The difference is usually that, they say, FreeBSD is modular and this RedoxOS tries to do everything, but it would not be interesting to use their desktop shell.
And the question is: is this advantageous? So, to the point where one can take advantage of the features of RedoxOS (just the Kernel and maybe the File System), maybe it is. I'm not scrounging FreeBSD, just trying to understand if the kind of BSD kernel development might be harming other improvements and better use on desktop machines and servers. This is because I see a lot of people complaining about the way FreeBSD takes to load on less robust machines, not that this is a problem (nor would it be, since it is a way to have a more secure loading). Good, but I'm not imposing an idea, just talking. Thank you!

[Hecktor]

Well the reason why Redox OS is fast is because it does nothing.

It has no card specific video drivers. It doesn't support USB.

When it becomes more functional it would probably be slower than FreeBSD as it has more to do based on the type of kernel. There is a reason every OS that is used is basically monolithic.

All drivers for video, network, and the file system need to be recreated from scratch. Who knows when if ever the file system for Redox OS would ever become stable, especially considering the low amount of testing it would receive.

Basically it boots fast because it would load 3 things as compared to FreeBSD's 100 things. Those aren't exact numbers obviously.

I'm not sure why you would want ZFS(which is the envy of all operating systems) to be replaced with something that isn't really functional yet and might never be.

The reason FreeBSD isn't a desktop operating system is because there isn't a demand for it. Firefox on FreeBSD lacks a lot of the functionality of Firefox on Linux or Windows. That is because FreeBSD is missing those parts that would give that functionality. Netflix doesn't require that desktop functionality in order to stream its videos to its customers. Mac OS uses chunks of FreeBSD and have had to create the missing desktop functionality. For Mac there was a payoff of doing that. For FreeBSD, it can be done as well. But there would be no real payoff and it would take a lot of resources to do that, so it isn't going to be done.

I think you probably misunderstand what Redox OS is by saying FreeBSD is modular and Redox OS tries to do everything. FreeBSD is an OS. Linux is only a kernel. Redox OS kernel is a kernel that does almost nothing. There is very little required to get a microkernel working. All the difficulties would be in making an OS work with that microkernel. So there is no advantage to using the Redox OS kernel anywhere else.

Rust is nice. It will be interesting to see where Redox OS goes. But probably it will die the way of menuetOS. Drivers are the huge part of something like this and there is basically no incentive for anybody to sink the huge resources required to get yet another OS with functional drivers.

[arcmatrixnt]

I fully agree, and put points that make it difficult to expand FreeBSD. But on ZFS I do not think I should go out, on the contrary. Yes, Redox has nothing even what can be good and bad, but anyway, I think their project looks for something smaller than serving the desktop systems. It is well known that they always mention that a microkernel is slower than the monolithic kernel. It reminded me a lot of Firefox that my test ended up having problems when running in VM.
Tell me, will Ghostbsd try to use KDE Plasma?

[Hecktor]

In case Eric doesn't clarify this is my understanding.

TrueOS is basing stuff on current and going with QT apps for the desktop with their new Lumina desktop.

Eric works for the company that is using/developing TrueOS. So he is going to take advantage of their work but use GTK stuff and use the Mate and XFCE desktop.

So neither is going to go for KDE. By KDE Plasma I assume you mean Plasma 5. When I tried it, it worked pretty well on FreeBSD 11, but 12 definitely had a lot of work to do. This was about a month ago or so. Since TrueOS is based on 12 with a lot of changes and GhostBSD is going to use TrueOS' stuff, it is unlikely that it will be very easy to get KDE Plasma 5 working on either very well.

[Hecktor]

I just checked out an interview with the maker of Redox OS.

Redox OS doesn't look very promising. It has gotten to the stage that tons of other hobby OS have gotten too. He gives a convincing sell to those that haven't programmed an OS before. His reasoning is extremely flawed and erroneous. There isn't any real hope for that OS. For example he seems to imply that there are dead projects that are unmaintained because they were written in C rather than Rust. It had nothing to do with the programming language. It is because somebody felt like programming something at the time, and then they moved onto something else in life.

The only reason linux progressed as it did is because there was nothing like it before. So an absolutely humungous amount of people contributed their programming resources into it. But now that it exists, there is very little reason for people to put their resources into something like Redox OS.

[ericbsd]

Hi, arcmatrixnt,

I think Hecktor did sum up everything, and to be clear there is no one on this project that has the knowledge do that, I am basically a FreeBSD freak and work for the company that makes FreeNAS, TrueNAS, and TrueOS and my manager is now involved in GhostBSD. So yeah I am not really interested in Redox OS.

I am more interested in making GTK graphical user interface for FreeBSD/TrueOS Core.

[arcmatrixnt]

Hello guys! I fully agree! I have seen there that there is no project really focused on the users, although they are creating something apparent. And the issue of KDE Plasma is that it is much more interesting than the previous versions to the point of being able to change the layout to any way you want, it is even possible to imitate Gnome 3 or even Unity.

And I went over the tip about creating mini windows for advertisements that may even be integrated with the Operating System and using 3gp to rotate images. So, because of KDE's plasticity, I believed that it would be easier to integrate into it than it is in Gnome, and that's an interesting thing to do, within a Qt code or some other language that fits better.

And sorry, I had not seen the whole message before. Too bad the Plasma can not be used.