More Work On Red Hat's Wayland Project

[Vighy]

I'm not going to quote all the post, since it was long and it would make the page longer

What you said (made exception for now of when you say that I think bad C++ programmers would be good C programmers... since I think the opposite ), is absolutely right, and I think the same, but I just try to realize that we are living in a real world and we have to face real compilers that have real bugs or regressions.
We need to make in account that even if theoretically speaking most of the features, and I mean features, of C++ would give the same result of C work-by-yourself-reinventing-the-wheel, in a real compiler most of the times produce bloated code.
That's not a C++'s fault... but you need to deal with it.

Now, about programmers, ok, bad C++ programmers would be even worse C programmers, but on the other hand when you are a good programmer in both the examples, it's a bit more difficult to optimize C++ than C.
Inheritance is a wonderful tool and I do use it, but it's easy with it to generate bloat. You need to be veeeery careful to not loose performance.

Finally, I hope we can quickly reach a point since we are out of topic

[Vighy]

to return a bit in topic, wayland works only on intel platforms because relies on features that are just provided by that driver (like kms)

I opened a thread into which I ask if it's possible to develop kms for the VirtualBox video driver, since it seems to be smaller and less complex, and it would allow everyone to work on projects like wayland even if their HW wouldn't let them directly.

http://www.phoronix.com/forums/showthread.php?t=15106

tell me what do you think, or what kind of help you could provide.

[Ze..]

And performance will suck
source: [url]http://www.kernel.org/pub/linux/docs/lkml/#s15-3[/url

That page basically distils down to "it's too much work". Honestly when it comes to Linux I agree with them but that doesn't mean that one couldn't write a new kernel, and initially make use of linux drivers with a compatibility layer.

And remember that even today C++:
a) produces more bloated code. (with every compiler, otherwise you are simply coding in C)

That's simply bullshit. That happened in the past with poor compilers but it's not a limitation of the language.

b) has issues (remember when in RadeonHD they needed to convert back inline functions to macros since the compiler was not doing the right job?)

Wait you mean even precious c compilers have issues? btw not inlining can be a performance win if it's a rarely used function and it reduces cache thrash.

c) leads developers to bad attitudes, seducing them with wonderful tools and then giving them worse performance (read what Keith Whitwell says: http://sourceforge.net/mailarchive/f...ame=mesa3d-dev )

Wait you mean developers that don't actually understand whats going on write bad code? shit that's a brilliant piece of insight

The simple fact is bad developers write bad code in whatever language they use whether it be c , c++ , java , O'Caml, python , perl , haskell , erlang , scheme , etc.

And what about microkernels? that's a design pattern with intrinsic performance issues, and that's not going to change in the future, since it's a design pattern and not an implementation.

The kernel is a critical piece of software. it's not admitted performance loss there.

Microkernels don't have to be slow , you only need to look at the L4 series of kernels and it's descendants. The lesson there is you need to be careful with how you design your scheduler and IPC mechanisms.

BTW monolithic kernels have their own problems you only need to look at the current work in asynchronous function calls in linux and the difficulty of implementing them.

Then we've got the fact that linux is tending more and more to getting some microkernel like features in it. We only need to look at FUSE,CUSE,Video4Linux and GEM/TTM/KMS to see this trend.

Micro-kernels allow us to do separation of concerns , so we can catch errors instead of silently corrupting data , this is a good thing and furthermore they limit the damage that any one modules/server/driver/interface can do. They aren't a magic bullet though and like any other kernel code they don't allow you to simply ignore the performance consequences of what you are doing.

If you want a microkernel written in C++, write it, and you will find that performance sucks

One of these days I'll have the time and I'll work on it for interest , at the moment though I don't have time since I'm in the middle of a big project with a lot of people depending upon it.

[Vighy]

@Ze for the half of your post, it looks clear you didn't read my last post about C & C++

But this is not the place to go on further speaking about coding languages or programmers.

To remain in topic I asked if it was possible to develop kms for the guest additions of VirtualBox.

If in the future you want to develop a kernel... why not starting developing such a patch for a device driver?? It could help you!

[zAo_]

Any updates on Wayland? The Google groups are silent

I'm really excided about the new Window server.

[Vighy]

Any updates on Wayland? The Google groups are silent

I'm really excided about the new Window server.

You'd really better reading the changelog of git commits, than relying on "textual" updates... since coders tend to code more than speaking

http://cgit.freedesktop.org/~krh/wayland

[89c51]

i have a question regarding eagle (if anyone knows)

from what i can understand by reading stuff around the net eagle is an egl implementation for mesa


will gallium (when OpenGL ES is implemented as stated here) make it obsolete??? (or i understood the whole thing wrong?)

sorry but i think it got lost in the posts about c vs c++

anyone knows?