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

  • From: Liam Proven <lproven@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Tue, 18 Dec 2018 18:39:21 +0100

On Tue, 18 Dec 2018 at 13:58, Adrien Destugues <pulkomandy@xxxxxxxxxxxxx> wrote:

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.

Fair points!

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.

Definitely, I can see that.

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.

Well, it did by the end. But remember that orignally BeOS only ran on
the BeBox -- and the BeBox originally hat AT&T Hobbit CPUs. Then
PowerPC CPUs.

Then it ported the OS to Power Mac -- not a new CPU but a new
motherboard etc. -- but Apple opposed this and refused to document its
systems. So Be ported the OS _again_ to x86 PC-compatibles.

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

I'd say that was a bit too sweeping! Go is seeing significant amounts
of use in low-level stuff like kernels -- I mean, I listed 2.

It's picking up some smart admirers.

ESR may be a difficult person, but he's definitely a smart chap and a
skilled programmer.

http://esr.ibiblio.org/?p=7711

http://esr.ibiblio.org/?p=7724

Go is very definitely not just a compiled Python. It's a real, valid,
safe low-level language. It has a superb pedigree. Rob Pike more or
less invented the idea of the graphical multitasking Unix terminal
(the BLIT project), and Plan 9 i.e. Unix v2 -- everything really *is*
a file this time, and it's network-wide -- and then the
CPU-independent successor to Plan 9, Inferno. Go brings lessons
learned from Inferno's Dis language and Limbo VM.

As for Rust, well, it may not have the big names behind it, but it's
certainly gaining support and credibility.

So I'd argue that _both_ are valid successors to C, yes, and therefore
arguably inherit some of C++'s mantle too.

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.

Hmmm. I don't know much about them. I will take your word for it.

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.

Hmmmm. This does go against much of my recent research, I have to admit...

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.

Thanks for the info!

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.

Well, yes, but then you _would_ say that, wouldn't you? :-)

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.

True.

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

Also true.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lproven@xxxxxxxxx - Google Mail/Hangouts/Plus: lproven@xxxxxxxxx
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Other related posts: