Slashdot Mirror

Hello! I december 2013[1] Herb Sutter has written about adding a graphics library to C++. As far as I know Cairo is a well written und usable library and in fact my complete desktop is using it (GNOME/GTK+ on GNU/Linux). But I shy away from the idea to see a graphics library within the standard, because drawing graphics is not part of the base requirements like Input/Output, String-Handling or Containers. What do you think about that? Is Cairo, as an low-level graphics library, also agnostic enough for the long-term future of C++? In my eyes Java only suffered from the integration of AWT/Swing as toolkit into the JRE. But AWT/Swing is a high-level toolkit and merely based on the paradigma of "runs anywhere". Thank you [1] http://lists.cairographics.org...

The cairo-ickle blog has maintained very interesting benchmarks of the different cairo rendering backends. The short story is that every hardware accelered backend except for sandybridge SNA has performed worse than the software implementation. And in some cases the hardware acceleration is significantly less stable. I'm curious to see if this finally pushes Glamor over the hump and makes it faster than the software path.

You mean high level things like file I/O? There is no good reason why 2d graphics should not be standard across platforms. Now many OS already have a Cairo library already available? http://cairographics.org/backends/ Looks like more than a few. I would even like to see a GUI library become a standard part of the language but that might be asking for too much.

Heh, that's correct.

Here's the proper link to Herb's post. http://lists.cairographics.org/archives/cairo/2013-December/024858.html

(You have to flip to 2014 archives to see the full thread.)

The second link goes to the wrong article.
Here is the correct link

Perhaps but there's always Cairo which runs on many platforms and seems to do a good job. There's a succinct description on Wikipedia. Some of the popular projects using it are GTK+ (GNOME), Firefox and WebKit.

Unix pipe and filters can't be used to build a complex workflow. They are unidirectional streams of bytes. They are useful tools, but when was the last time you wrote a shell script that used only pipes?

The original article, laments about the way we program today, by assembling components. I'm only saying it's a good thing that we are finally there. And no, we weren't there in the 1970's as far as I remember, nor in the 1990's for that matter.

You are right that designing an API is hard. But I would add that it's not just a matter of API design, it's also a matter of use cases. That's why I still see value in someone writing the code she needs, and sharing it with me as open source. Because if the way she did it doesn't suit me, I can fix it. As a matter of fact, I did exactly that just last week with Cairo.

SVG is good for (mostly-)static vector graphics. While it was designed with a DOM and proper handlers in place to facilitate animation, in practice it's A) not fast enough and B) a very, *very* large standard.

If you want to see Canvas used for animation, check out the Chrome Experiments page. Most of the animation there is done using Canvas. It's a smaller standard, and it's very close to already-implemented 2D-model engines, like cairo.

How would you say AGG compares to Cairo?

You might want to look at Cairo. It has a Win32 backend as well as many other platforms. It is written in C and has bindings for C++ and lots of other languages as well. http://cairographics.org/

There's already something very close to Processing using Python, BSD licensed, even though it's OSX only: Nodebox (http://www.nodebox.net/).

On the other hand, there's a GPL fork/port of this project that works on GNU/Linux and Windows -- Shoebot (http://www.tinkerhouse.net/shoebot) (Disclosure: i'm one of the authors)

Nodebox uses Cocoa as its graphics back-end, while Shoebot uses Cairo (http://www.cairographics.org/); our plans for it are to implement other graphics back-ends including OpenGL (via Pyglet or Pygame), so seeing the parent open-source their Python/OpenGL project would be a godsend to us. Hey, there's common goals and all, so no reason to keep it closed, right? ;-)

(do pardon me if the links come out wrong, it's my first post over here -- bonjour to all)

The XScale range has always been based on ARM5 with the FPU removed. It seems this is still the case.

One of the strengths of Firefox for some time has been that right out of the box, the binary just ran on lots of Linux versions. With FF3 (starting with betas) they broke this.

Good. Firefox has a large enough memory footprint without statically compiling all the libraries into it just because someone might want to run it on an outdated distro.

FF3 requires a pretty new library (libpangocairo 1.0). I spent an hour trying to come up with it this afternoon for my 100+ users. No luck so far.

Cairo is available from http://www.cairographics.org/. Pango is available from http://www.pango.org/. What, exactly speaking, is the problem ?

The firefox team really let us down big time. We've been anxiously awaiting this release because it's supposed to solve the memory bloat problems (several of us here have to restart the browser several times a week because it's consumed insane amounts of RAM).

Using the same shared libraries as everything else will reduce memory usage, because that way there will only be a single copy of the code in memory. Statically compiling libraries into programs for distribution was always a stupid, stupid, stupid hack.

Now, maybe the Firefox team should also provide a self-contained Firefox version for people who insist on using it on outdated distros - it's not much work, just a single linker flag if I remember correctly - but that certainly shouldn't be the default.

Check out Roadster:
http://cairographics.org/roadster/

Here's a screenshot:
http://www.mp3car.com/vbulletin/attachments/linux/34562d1157775234-linux-gps-roadster-roadster-0.2.4-1.png

It has data available for the united states, download, compile, and give it a shot.

I second your opinion, but I also want to point out the hard work done by Linux Audio Developers.

For one, they pushed the development of preemptible and low-latency Linux kernel to make it possible to do low-latency stuff, even on relatively aged hardware. Mac OS X's micro-kernel architecture is potentially superior in this regard because you can easily go hard real-time with micro-kernels (Linux is a monolithic kernel), but Linux kernel is more suitable than Windows XP for running audio applications because of these improvements.

They also obsoleted OSS (open sound system) and came up with ALSA, which makes it easier to support new sound devices from the developer's point of view. ALSA supports a range of consumer to professional sound cards, just like CoreAudio. It just works.

Another notable framework, JACK, goes beyond CoreAudio by providing audio routing between applications, like ReWire. JACK is also available on Mac OS X, except it is less robust than on Linux. Thrashing can cause audio drop-out because Mac OS X kernel can't lock pages in real memory.

Finally, if you ever considered audio production work on Linux, you definitely know about Ardour at some point. It's the hard work of Paul Davis, working on it unemployeed and full-time for many years. Ardour also runs on Mac OS X, by the way, because of the generous nature of Linux developers for offering you a choice.

If you do mostly recording, then you can get by on Linux quite sufficiently. If you do a lot of synthesized stuff like Reason or NI, then you'll be disappointed. There is simply no comparable app on Linux.

------

On the other hand, Linux has a lot of architecture catch-up on the graphics stack. Cairo recently has some talk about supporting more color spaces than RGB. However, the lack of end-to-end color management is a serious issue. Colors you see on the screen simply will look different when printed out. The colors are also not even consistent from monitor to monitor.

One thing I'm really impressed with Mac OS X is its monitor calibration. It lets you fine tune gamma by inspecting the monitor response in highlight, mid-tone and shadow for red, green and blue. I can easily color-match two monitors by different manufacturers.

Mac OS X also has superior built-in typesetting support, completely unparalleled by any operating system, and this is available in any application even TextEdit. In TextEdit, you can already turn on common ligatures like "fi" and "fl" as you type. In comparison, you must insert ligature glyphs manually when using Microsoft Word. Mac OS X supports more typesetting feature than that. For example, the Hoefler font has an archaic font variant with a "long s" (so congress looks more like congrefs where the f has shorter middle bar---the s at the end of the word remains the usual form because the long s is a contextual ligature that happens only in the middle of a word) and the "st ligature" (there is a small hook that goes from the top end of s to the top stem of t). Needless to say, contextual ligature is a crucial feature to support scripts like Arabic.

Mac OS X definitely has received a lot of attention in the aesthetics that goes way beyond eye candy.

Umm, Firefox 3 will be using Cairo, but I have no idea where the "fully based on Vectors" comes from. (Also, Firefox 1.5.x is Gecko 1.8.0; Firefox 2.x is Gecko 1.8.1)

If there's native support for OpenID, I haven't seen it yet :)

And in the improving-the-web direction, you basically want to look at WHATWG anyway - at least Mozilla, Opera, and Apple are behind it, so even if IE isn't there the other major desktop players are. And the new-ish HTML WG at W3C...

The technical reasons are largely due to adopting the Cairo graphics library, which is primarily developed for Linux but also supports Windows and OS X (plus other backends for outputting PDF for printing, OpenGL for better performance on reasonably modern computers, etc). Cairo's Windows implementation makes use of features only provided from Windows 2000 – especially for text rendering, and especially because they care about international support with Unicode and complex scripts that just weren't handled well back in Windows 98. In FF 1.5/2.0, the SVG renderer already suffers on Win98 because the OS doesn't provide the necessary support for proper text, and nobody has offered to invest the effort to patch the problems.

Cairo has a separate backend implementation for X, which probably works better than the Windows one because it's had more development effort, and that uses totally different technologies (building on the standard components that modern Linux distributions provide) for things like text rendering, so it's not affected by the same issues &ndash - Mozilla's move is not weakening their Linux support in any way.

It doesn't support older Windows because it uses Cairo for faster rendering, which I've read doesn't support older Windows versions. I'm not sure if it's the same reason older versions of OS X are not supported.

I worry about the future of Firefox... because they are, apparently, going ahead with dropping all rendering backends except for "Cairo". It's become increasingly apparent that Cairo is a performance nightmare by design.

This become obvious when the first major project moved over to it -- GTK. GTK is already suffers from shoddy performance due to maintainer incompetence, but when it dropped all rendering backends and moved to Cairo alone... it went from bad to worse. The later versions of GTK that use Cairo exclusively are, to put it mildly, fucking shit. Nokia even went so far as to point out that Cairo's performance was "catastrophic" on their Maemo system... though, in their case it was made even worse by being run on a system without an FPU (and Cairo hammers the floating point system).

Essentially, Cairo has been a performance disaster for GTK. I seriously hope Firefox ignores their roadmap and forgets abotu Cairo.

As long as you stick with Gecko 1.8.x or older. Gecko 1.9 (to be in Firefox 3 / Seamonkey 1.5 / whatever) will be Cairo-based, which is part of where the no-Win9x thing comes from.

There sort of is - Microsoft Layer for Unicode. It doesn't target the graphics API though, just some boring strings stuff.

I think there's also some sort of licensing problem with using MSLU in Mozilla though. There was a bug about that, and some sort of open source alternative that... didn't really go anywhere. That, and the main problem with Mozilla was needing a Cairo backend that runs on Win9x. Last I checked, they just didn't have the manpower for it, and was open to help.

un sued Microsoft for their Java support in Windows/IE. Microsoft removed (again) the support and we know where Java is today in terms of client-side browser applets. At the same time Microsoft has managed to spread wide their version of Java: .NET.

How much of a liability will PDF writing support be in the next generation of the Cairo graphics library?

Cairo with the PDF writing backend was set to ship with the next crop of distributions as the bugs have been pretty comprehensively fixed over the last few months.

It would be a shame if PDF writing support ends up tainting Linux distributions and slowing their adoption in large organisations. It seems that making at least a branch of Cairo without the PDF writing backend would be a good move for now.

The risk of having free distribution FTP sites, the free Ubuntu ShipIt service etc. threatened and forced to charge for the software they distribute because of PDF writing capabilities just seems too great.

This has been done for a few years now. Take a look at Cairo. It's (approximately) the PDF imaging model, like Quartz. It has a variety of backends, including win32 (with GDI+), vanilla X11, XRender, Quartz and hardware-acccelerated OpenGL (via GLitz).

GTK stable has been using Cairo for drawing for almost a year now. The Xlib API (wrapped up as gdk_*) is deprecated. I imagine KDE will have a cairo backend at some point too.

Actually, Firefox 3.0 could take advantage of your spiffy GPU because Gecko 1.9 will be drawing on Cairo or WP Cairo which will be accelerated by Glitz

exists already for linux.

http://cairographics.org/

Did you miss the Gnome 2.14 announcement?

Cairo integration?

Cairo Snippets

Go down on this page to the section labelled "Sharp Dressed Man".

Cairo Introduction

It's good stuff, and exactly what you are asking for, I think.

Did you miss the Gnome 2.14 announcement?

Cairo integration?

Cairo Snippets

Go down on this page to the section labelled "Sharp Dressed Man".

Cairo Introduction

It's good stuff, and exactly what you are asking for, I think.

The new GNOME looks great, but it certainly doesn't match the effects of Vista. Check it out: 3d window stacking, hardware alpha blending with blurring, etc. It'll be a long time before the freedesktop guys get Cairo and XGL working to the compatibility, quality and speed of DirectX. Xorg composite still crashes for me frequently.

I haven't read the article, since GTK+ is already my preferred GUI toolkit. And this in spite of the fact that I run KDE as my primary desktop! I run both Gnome and KDE, and my choice of KDE over Gnome is based more on organization and flexibility than it is on the underlying GUI toolkit.

As background: My wrote my first GUI programs back in the days of Window 3.1, and while most of my work is on data-crunching engines, I do write quite a few GUI applications. I need to rapidly generate an interface, back it with code, and have it presentable on Windows and Linux.

As a programmer, I don't like QT. It feels klunky, bloated; nor do I find QT Designer all that friendly. Beyond matters of taste and comfort, TrollTech requires a commercial license for certain tools (e.g., a MathML widget) that I can obtain under GPL for GTK+.

I'm rather fond of Glade. Most of my GTK+ GUI programs are in C, some in C++; I define an interface in Glade, fill in the appropriate functions, and I'm ready to rock and roll.

GTK+ 2.8 brought with it Cairo, a very nice drawing toolkit. I just put together a little interactive graphics application, just to better familiarize myself with Cairo, and the result is quite nice.

In the near future, I'll be writing some very extensive OpenGL applications, and I'll likely wrap these in a GTK+ GUI. If something better comes along, I'll try it -- but for now, GTK+ provides what I need. Your mileage may vary.

Er, we've already got a great (at least in the sense of "large") Web infrastructure with market buyin and lots of developers, which is totally cross-platform. Distributed X apps have none of that. If you haven't seen any good AJAX drawing programs yet, that means you should encourage people to develop one, not discourage it. Especially since encouraging X development for the same benefit is obviously a doomed adventure.

I was using X more as an example of a dumb, supposedly obsolete system for network-transparency which can still do things which are impossible with AJAX. Like, erm, drawing circles quickly, setting pixels to particular colours without creating a miniature new document section and so on.

As traditional graphical user interface APIs go, AJAX is basically shit, as it's a simple document markup system with scripting grafted on. Its main, colossal advantage is that everyone's got the client software already - there's no X server, Java virtual machine or VNC client to download. But for someone designing this hypothetical drawing program, they'd be writing it without the aid of any modern graphics APIs. I'd be utterly amazed if someone produced a fast, usable and cross-platform equivalent of (say) Inkscape using AJAX.

Improving existing web applications? Brilliant! Making possible interesting new ways of submitting textual data or retrieving graphical data? Definitely. Recoding existing, offline desktop applications in a way that isn't a gigantic hack? Not really...

afaik, the X Windows System is not frozen in time as you seem to think. Far from it, cool and exciting modular technologies either building up on it or adding value are coming. Check it out:

http://www.freedesktop.org/
http://xorg.freedesktop.org/wiki/
http://www.freedesktop.org/wiki/Software_2fXserver
http://cairographics.org/introduction

Cairo, a 2D vector-based GUI backend. GTK2.8 is already built on cairo. BTW, GTK ( along with Mozilla's XUL ) also pionneered the on-the-fly translation of an xml-based document describing a GUI into a running GUI, via libglade.

I don't think the next generation of either KDE or GNOME will be taking a beating from either M$ or Apple.

As for graphics acceleration, that's outside the reach of most open-source projects, since the main hardware manufacturers do not undisclose the specifications and only provide proprietary closed-source drivers... the usual solution is to use OpenGL.

yet another "replacement" for X11. Cairo does sound like a better replacement than previous attempts. But my money is on it falling flat on it's face like all the others.

Luckily the application base for X11 is relatively small and mostly open source. So replacing X11 won't be that painful. Also things like Cairo do provide some compatibility between different systems.

LGPL is kind of a weird license though, I'm not confident it's appropriate for Cairo. but I suppose if Cairo really does turn out to be good alternate systems written to it's specification can be implemented.

Guess you've never heard of Cairo (as another reply pointed out), or maybe Xgl /Xegl?

Or even seen the videos of what luminocity can do? It can do that NOW. How about Project Looking Glass?

Just becuase you don't know about them yet doesn't mean they don't exist.

1. Last time I checked, Avalon was being killed, erm, "removed from the default distro".
2. http://cairographics.org/

Do you mean this Cairo? It seems farther along than anything Microsoft is working on right now...

The Inkscape people are not ignoring this. They just need someone to do the work. Any volunteers?

When will we get a vector-based Linux desktop?

They have icon themes, there's talk of Cairo, and all that Luminocity good stuff, but when, oh when, will we actually have a fully scalable desktop?

Hell, I'd be happy if I could just have a file manager, console, and calculator that were resolution-independent. How far off is that? There seems to be no central clearinghouse for this sort of information.

--grendel drago

For me, it's Longhorn's vector-based approach to the UI. While everybody's busy giggling and snorting at the 'eye-candy' at Longhorn, the reality is you'll be able to use it on monitors with > 3,000 pixels in width without having to use a microscope to read the text. You'll be able to resize windows etc to suit your needs. I also really enjoy the idea of using the system's GPU to offload the graphical stuff.... ...Certainly Linux is going to have its own implementation of this feature set.

Vector based graphics, offloading work to the GPU? Linux has its own implementation of this featureset now. It is called Cairo, and it works right now. GTK+ is going to be using it very soon, and SWT already makes use of it for their "advanced graphics" system. If you want Cairo rendering of GTK+ right now, use the cairo-gtk theme engine and associated themes.

Is Cairo fully integrated in yet? No, development is still in the works to port things over to Cairo (but work on both Mozilla and OpenOffice is already underway as well). In a sense then while the backend has been hammered out (Cairo) the full end to end functionality is till in the works. Then again Longhorn is still a ways from release as well.

This does mark an interesting point though: Linux is not playing catchup with Windows on this one, they are running pretty much in parallel. Similarly Beagle is in parallel or ahead of WinFS. I know all the Mac people will complain that their both playing catchup with OS X, but let's take this one hurdle at a time. In terms of new features Linux is playing head to head with Windows these days, and considering how far behind they were when they started (or how far behind they were even a year or two ago) I would take that to mean that Linux will be running ahead of Windows and only a little behind OS X in another few years.

Jedidiah.

I think what deserves more attention is the badass development of cairo into Mozilla.

Check out the blog of the main developer thats doing this development. Hes got some excellent demo screenshots.
http://weblogs.mozillazine.org/roc/

Have you looked at the Cairo-graphics project? (cairographics.org) Everyone is porting their apps and DEs to it. It will give Quartz a run for its money (probably not core image for a while, but it will happen if core image turns out to be actually useful).

Gtk+ already runs on cairo, btw. I believe that gnome 2.12 or whatever is planned to run on cairo.

It does happen, it's just that sometimes it takes an external example to motivate free software people to do it (such as MacOSX and Avalon). This isn't necessarily a bad thing.

Oh brother.

There is a language being developed codenamed cairo..

No. Cairo is a 2D vector graphics library, not a language. ...to be used in Linux...

or Windows. or Mac. It is a cross platform library.

its a GTK fork...

No. It is not. The CVS head version of GTK uses cairo for drawing. ...and its special feature is ability to use opengl rendered screens in place of bitmaps for window drawing...

Among its features are multiple drawing back-ends. One is OpenGL, another is Render. Because it is a vector library, it may or may not render to bitmaps - depending on the backend.

A product is already being developed using this called luminocity.

Luminocity is a fork of the metacity window manager that has a built in composite manager that renders to OpenGL.

Now that that's been cleared up...

Please don't post here such nonsense! Read at least the first sentence on http://cairographics.org/introduction: Cairo is a vector graphics library designed to provide high-quality display and print output.

That's what it is. A 2D vector graphic library with multiple backends, which means you can draw something and choose if you use as drawing backend X11, a PNG file, a PDF file, glitz (OpenGL) or something else.

Gtk3(?) will _use_ Cairo and it's X11 or glitz backend to draw it's widgets!

... because we make the "copy" better, more secure and add more features all while adhereing to open, published standards.

Take http://www.spreadfirefox.com/, which is the Firefox webbrowser, for example. This piece of software is hardly new in the sense of being first of its kind, and yes it "copies" the same basic functionality that IE does (and IE copies from Mosaic - check out help->About Internet Explorer, it says clearly "Based on NCSA Mosaic."), but just because someone else invented the wheel doesn't mean we can't use it or make our own, or a better one.

And don't get me started on innovation. As a matter of fact FOSS has already beaten the mighty M$ to a better desktop search (Beagel http://www.gnome.org/projects/beagle/ vs. WinFS - though I will admit I can't quite predict what WinFS will be like IF it ever gets released or if the 2 are even comparable).

Oh, and we are creating new virtual machine architectures[VMA] (XEN http://www.xensource.com/ for example? Again, not sure if that is what you meant with VMA) and new visual interfaces (check out http://cairographics.org/introduction/ for Cairo, which may beat M$ again to the finish-line).

And while M$ buys 90% of the time the technology or licenses it, FOSS actually does develop their stuf from scratch.

Rehashing what's been done before and then claim we do not have freedom to do what we want to do. Interesting. I am not quite sure where these 2 opinions intersect to make sense. Please explain yourself further ...

All in all I think you are way of mark, Microsoft-Fanboy!

http://www.cairographics.org/ is what I meant of course. Don't be me, use Preview!

I'd argue that they are indeed investing credible resources (if not "pumping money") into important parts of desktop infrastructure.

Robert Love working on HAL.
Robert O'Callahan working on Mozilla.
David Reveman working on Glitz/Cairo
Etc, etc.

Actually, I typed up my mini-summary without reading your last, particularly informative post - it seems I was on the right track! While I do use an Apple iBook for loads of (non-graphical) programming stuff, I hadn't really understood why Quartz was so different, and your previous posts really informed me.

So, thanks to you! :-)

Interestingly, and more on-topic, I note that the new X rendering system, Cairo, "provides a stateful user-level API with capabilities similar to the PDF 1.4 imaging model". I've no idea how similar it is to Quartz, but it still sounds vastly superior to the existing X way of doing things. Even my old Atari ST's VDI is better than that...

Indeed the Gnome Devs already have realized that Longhorn should be next targetted. In fact, they've almost rendered your second complaint null and void. Could anyone miss this story from three days ago? As noted: the Gnome devs have the underpinnings of Gnome successfully implemented over a generalized vector rendering library, which will have as a backend a hardware accelerated composition library. This integration is the second step in the FOSS answer to your second warning. The first was SVG icons, which have been fully functional since Gnome 2.4. I can't speak for KDE, but I imagine they're reacting similarly.

Apple got to the advanced desktop first. FOSS will be second. I'll be surprised if Microsoft doesn't come in a slow third. Heck, Reiser 4 will be ready with metadata delivery long before WinFS is.

Cheerleading session over.

1. The entire OS will be accessible through a set of managed APIs. This makes coding 10 times easier and faster, and raises productivity to unprecedented levels. This also makes buffer overflows and some other security issues a thing of the past.

"Managed APIs". I can see where this is going already.

2. New, resolution independent, vector based, GPU-enabled UI engine. Two years from Longhorn release people will be buying 200+ DPI displays because things look a lot better on them. What's KDE/Gnome users gonna do? That's right, try to discern tiny non-scalable icons on these displays.

Gnome/KDE already support SVG. So gnome/kde have scalable fonts/icons.. right now, today. Not only that but work is already being done in this respect http://cairographics.org/introduction.

3. Completely new UI, including some significant paradigm changes.

PARA DIG EM! Yeah.. when I wanna be wowed by UI i'll use Enlightenement or OSX. Suprisingly nothing from Microsoft has ever impressed me in that department. I mean, the screenshots I've seen of gnome/kde/enlightenment/osx/xfce. Microsoft needs to hire new UI designers.. I mean, seriously.

4. Seamless integration of client and server side (that's what XAML is all about, IMHO). Your webapps will actually run sandboxed .NET code on your machine. Kind of like applets, but the entire webapp will be built out of them. Just think about the possibilities there.

Mozilla and XML. Thats what Mozilla is all about. Your webapps will actually run regular ole XML on your machine. Kind of like google mail, but the entire webapp will be built out of them. I'm living in the present by the way.. Just incase you were wondering.

5. Reliable Web Services - Indigo, web services that don't suck. More importantly, web service protocol that's supported by the majority of computers in the world (when most people upgrade). And you can bet your ass they will upgrade, just like a couple of years after W95 was released almost everyone ran W95.

Reliable Web Services? Web service protocol? So whats that called? HTMP? is that going to be ontop of HTTP? Making it more reliable and supported worldwide (after everyone switches from HTTP). Bet my ass i'll upgrade for a protocol, just like when I upgraded for ftp!

It's time to stop copying Windows XP, folks. It's time to start copying Longhorn. Gnome devs have already realised that.

What you say?! Stop copying XP and start copying Longhorn?! Why my lad, you can't copy what doesn't exist.

Seriously though, I hate Microsoft and if they had anything genuinely original coming out in Longhorn i'd probably be interested. Especially if it's good technology. To date, i'm hearing about stuff people have either already implemented or wrote about. Things that have been discussed by numerous people over the years. The innovation isn't happening at Microsoft, it's happening elsewhere. It's not even an attractive company to work for nowadays and i'd be hard pressed to say they've ever invented anything original.

I mean, if I wanted to do original shit i'd have to go to work for anyone other than Microsoft.

xxx_self_intersect

That sounds sort of, you know, obscene.