[haiku] Re: AW: Re: another idea from me, sorry if it is foolish: aport of kodi would add netflix support

  • From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Tue, 18 Dec 2018 12:56:35 +0000

18 décembre 2018 13:40 "Liam Proven" <lproven@xxxxxxxxx> a écrit:


I think _some_ of the reasons that Linux has thrived are that it's
_both_ a server and a client OS. Sometimes things like codecs or GPU
support are useful for server stuff, but the side-effect is that they
bring benefits for desktop users, too.

Whether there are lessons in this for Haiku, I don't know.

Our view is that Linux tries to do a lot of things, and they have to make
compromises which don't always fit a desktop machine. For example, servers
don't need hibernation, and it is still a bit hit and miss on Linux these
days. The scheduler values performance over latency, so you can still get
the UI to freeze or lag behind despite throwing multi GHz CPU cores at the
task. And there are many other cases like this.

But what creates problems for Linux is the fragmentation. As I mentionned
in an earlier mail, quite often when writing an app for Haiku one ends up
working on patching the OS itself (at various levels). On Linux, this would
mean working with a dozen different development teams and coordinating
efforts. This also means a lot more interfaces to take care of and maintain,
for example the Linux kernel will never change the meaning of existing
syscalls, while we can replace and extend them as needed as long as we keep
our C library in sync.

Psion's EPOC32 project, it argues, was the last new computer.

By which he means it was the last time that a company did this:
conceived, built and sold, very successfully, as a complete whole, an
entire hardware/software/app platform.

Be already understood that they were to a point where hardware had become
irrelevant. There was a time where custom hardware would give you an edge
over the opponents, but not anymore. So you just get off the shelf hardware
and use that.


I have read learnèd discussion that says that some of the problems
with Symbian that stopped it being successfully modernised lay in the
use of C++ before it had been successfully standardised.

I am wondering if any of this also applied to BeOS, and thus by extension 
Haiku?

Because I am looking at more recent OS efforts, e.g.

* Redox OS: https://www.redox-os.org ;(in Rust)
* Google Fuschia: https://en.wikipedia.org/wiki/Google_Fuchsia ;(in Go)
* Google gVisor: https://github.com/google/gvisor ;(in Go)

Both Rust and Go are attempts to fix some of the issues with the
sprawling complexity of C++ alongside its relatively poor type safety,
little-improved over C.

Go is essentially "Python reworked for compiling" and has nothing to do
with fixing C++.

C++ is moving forward with C++14, C++17 and on. They are fixing their own
issues and I don't think neither Go nor Rust are going to replace it.

C++ is definitely not a failure, but I do think it's fair to say that
it failed to substantially improve on C, either in safety or in
simplicity. Both Go and Rust attempt to do just that.

It improves a lot, not only in safety and simplicity, but also on performance,
and code writing speed. There are still ways to bring it further, of course,
but it is miles ahead of C.


I am wondering if Haiku is as C++-centric as BeOS. I would assume so.
Can anyone tell me?

The API is C++ as it was for BeOS.

The kernel and most drivers are written in C++ too. This was NOT the case in 
BeOS.
So, Haiku is more C++-centric than BeOS.

I don't feel this gets in the way or is a problem, however. I use C++ a lot and 
I
find that it is quite well suited to the job, being both a low level language 
appropriate
for writing kernel or driver code, and a structured language allowing to reuse 
code,
design things cleanly, and write code more quickly than plain C.

Go is pretty similar I think, Rust is designed to be a bit more high level but 
allows
"unsafe" constructs to still bridge the gap. When you use these, however, it is 
not
anymore reliable than C++ in terms of security.

Anyway, Redox and Fuchsia are covering the needs for "operating system written 
in X" already.

-- 
Adrien.


Other related posts: