Slashdot Mirror

But now we see the strategy of Canonical and why the (at the time) weird decisions were being made

Um duh, it was made for Instant-On web devices, it just so happens that tablets fall into that category nicely.

But let's look at each point individually because not everything you stated relates to Canonical's desire to go to Tablet's, it's more along the lines of, "it just happens to also help them out towards tablets."

1) The nasty split, isn't any more nasty than other things in the Linux world. Canonical wants Canonical stuff in Canonical's distro. GNOME 3 is still used in Unity, but just differently. It's hard for me to explain because I suck at summing things up, but trust me, Unity is GNOME 3 at the core and Unity runs more with how people predicted GNOME3 to be used more as a platform and less like a standard desktop. The main facet is that it removes a lot of upstream push from the GNOME community. Canonical wants their desktop to look the way they want it to look, not what GNOME developers want it to look like. You'll see this type of mentality in a lot of Ubuntu. Also, let's face it GNOME developers are difficult to work with at best. It's very easy to paint the main developers as being the pearly towers (metaphor for someone who dictates how things should happen, but have little to zero real-world experience to back up exactly why that's right.)

2) The choice to use Wayland over X boils down to the same debate that was had on xgl versus aiglx. Mark thinks running direct to the video card is a better method than the way X provides. This has been a common thing that comes up ooo, I'd say every five to six years. Someone comes up with a better way to run direct to the card and someone jumps on the band wagon. Usually there is just too much inertia to make the jump from X to the something else happen and we all go back to using X happily. There's a lot of misconception that Xorg (specifically) and X11 (in general) are bloated, slow, won't run well on older machines. X11 is a pretty hefty "standard," but not everything in it is in every implementation. There are multiple of X11 implementations (I'm given too, Google can help you see more) that target embedded systems that run quite well. Xorg implements a lot of stuff to keep backwards compatibility with older machines. Wayland doesn't. However, don't confuse that because just because it is implemented does not mean that it gets loaded if it is not needed. You aren't going to be using XRender when your video card offers the ability to use OpenGL pixmap to texture. The biggest problem with X is drivers (and that shouldn't surprise anyone) and the low quality those drivers exist in. That problem will not go away with Wayland. The idea is, and to me it's a bad bet, if we make the model more simple (remember the X11 "spec" is a pretty big tome) then vendors will be more incline to write better drivers since the model for those drivers is more simplistic. However, as bets go, that's immaterial to why Canonical wants to go Wayland. It really boils down to the fact that they want to do Window Decorations the way they want to do Window Decora

Oh, really? No reason at all? About a year ago, I had to work on a project for Christie Digital through Alt Software. The project was about building software that controlled video input from multiple devices into the same computer (I tested with 70 simultaneous inputs, this was possible because the hardware used overhead busses from input cards to output cards,) and video output onto rear-projector TV Video Walls. The software had to be designed in a way that supported multiple different platforms (windows/linux/unix.) So the front end was written in Java - this piece handled the windows, channels and profiles, it handled all the user interface issues. In the middle there was cross-platform C++ for video thread handling and resource management, and the back-end was all platform specific C code (basically device drivers from different vendors.)

So I did prototypes with Swing and found that there were problems with JNI Canvas handling. It wouldn't work properly but it did work with AWT. The Canvas had to be drawn in a specific color (magenta,) so that when the window handle was passed through JNI to C++, that code could pass the window handle further to the C drivers, that would draw on top of the magenta color within the window (on the Canvas.)

We are looking for 10 solid C / C++ programmers. These positions are excellent opportunities to break into the Avionics and Aerospace industries. We'll teach you our DO178B development practices and you get to work on the next generation of aircraft systems, designing industry leading hardware and software solutions.

Who should apply? Looking at the HR job descriptions it appears that you should have some graphics experience; but I'll tell you straight away that this is not important to us. We can teach you OpenGL, just as we can teach you DO178B. What we can't teach is how to develop using C. We can't teach you that refactoring is a good way to solve many design problems. We can't teach you that effort spent on design saves time when you write the code or the test plan. We can't teach you pointer math, or methods for optimizing your code. These are things that you either understand or you don't.

If you can reverse a singly linked list in place, or have ever implemented "Scatter Gather" DMA transfers, or if you can describe the benefits and drawbacks of function pointers, then you are ready for the interview. And knowing why these things are discouraged in safety critical avionics applications will win you a job very quickly. (We'll teach you why these are bad ideas too, if you don't already know it.)

Send your resumes to: resumes@altsoftware.com

In your cover letter, mention that you are applying to ALT Software after reading Mike Agar's (Vice President of Software Engineering) Blog. It will get a closer look.

We are looking for 10 solid C / C++ programmers. These positions are excellent opportunities to break into the Avionics and Aerospace industries. We'll teach you our DO178B development practices and you get to work on the next generation of aircraft systems, designing industry leading hardware and software solutions.

Who should apply? Looking at the HR job descriptions it appears that you should have some graphics experience; but I'll tell you straight away that this is not important to us. We can teach you OpenGL, just as we can teach you DO178B. What we can't teach is how to develop using C. We can't teach you that refactoring is a good way to solve many design problems. We can't teach you that effort spent on design saves time when you write the code or the test plan. We can't teach you pointer math, or methods for optimizing your code. These are things that you either understand or you don't.

If you can reverse a singly linked list in place, or have ever implemented "Scatter Gather" DMA transfers, or if you can describe the benefits and drawbacks of function pointers, then you are ready for the interview. And knowing why these things are discouraged in safety critical avionics applications will win you a job very quickly. (We'll teach you why these are bad ideas too, if you don't already know it.)

Send your resumes to: resumes@altsoftware.com

In your cover letter, mention that you are applying to ALT Software after reading Mike Agar's (Vice President of Software Engineering) Blog. It will get a closer look.

We are looking for 10 solid C / C++ programmers. These positions are excellent opportunities to break into the Avionics and Aerospace industries. We'll teach you our DO178B development practices and you get to work on the next generation of aircraft systems, designing industry leading hardware and software solutions.

Who should apply? Looking at the HR job descriptions it appears that you should have some graphics experience; but I'll tell you straight away that this is not important to us. We can teach you OpenGL, just as we can teach you DO178B. What we can't teach is how to develop using C. We can't teach you that refactoring is a good way to solve many design problems. We can't teach you that effort spent on design saves time when you write the code or the test plan. We can't teach you pointer math, or methods for optimizing your code. These are things that you either understand or you don't.

If you can reverse a singly linked list in place, or have ever implemented "Scatter Gather" DMA transfers, or if you can describe the benefits and drawbacks of function pointers, then you are ready for the interview. And knowing why these things are discouraged in safety critical avionics applications will win you a job very quickly. (We'll teach you why these are bad ideas too, if you don't already know it.)

Send your resumes to: resumes@altsoftware.com

In your cover letter, mention that you are applying to ALT Software after reading Mike Agar's (Vice President of Software Engineering) Blog. It will get a closer look.

We (alt.software inc.) released an OpenGL-to-D3D wrapper based on Mesa code fairly recently (with source etc.). This should allow any card that supports hardware D3D acceleration to accelerate OpenGL applications. YMMV, but from what I've seen it works reasonably well.

You can find it at

http://www.altsoftware.com
(click on "OpenGL"), or read about it at
a href=
"http://www.opengl.org/News/Archives99/Feb99.htm l">
http://www.opengl.org/News/Archives99/Feb99.html
(look for 2/23/99 under the "Developer" section).