Slashdot Mirror
Debian Sid Moves to X.Org
debiansid writes "Yes, Debian sid finally has X.Org. The Changelogs suggest that some work has been taken from the Ubuntu packages of X.Org. Here is an
article that gives details on how to migrate to X.Org on sid. This article, by the way, has been posted from an X.Org based X-Window System, and it really IS much faster than XFree86."
It would be really nice if Debian started another release process right after the transition to X.org and the C++ ABI are finished.
I really like Debian, and I'd prefer not to wait a couple years for the next release. :-)
I did the upgrade last week, and it's been no problem at all. I've had to hold back xbase-clients and xutils because they want to pull in libgluc2 (with the new C++ ABI), and I have software that uses the old stuff, but the vast majority of it is running X.org.
Runs real sweet, too.
No problems on a laptop or 4 desktops. Just use aptitude and hold back anything that causes conflicts.
Oh, and I didn't make any safety backups at all. Crazy me.
The glibc transition wasnt exactly a walk in the park either.
You asked about the difference as a desktop user between XFree86 and X.Org, and you got modded flamebait by some clueless moderator. How ironic that your sig says "#define CLUE 0".
This reminds me of the pain we went through with the libc5 => libc6 migration, except now we have the gcc4 ABI change and X.org breaking everything that uses a colored pixel.
Wow, I wonder why they call it unstable (rolls eyes).
If you think that was annoying, I don't know what you'll do when serious issues surface after upgrading.
"Why, o why do they always make changing the C++ ABI such an effort? It takes some credibility out of C++ as a stable lower-level programming target if such a relatively frequently occuring change in the core obsoletes so much essential packages."
The GCC people are the ones changing the ABI, and they're the ones losing credibility.
I rarely criticize things I don't care about.
The new hand-written recursive descent parser added in 3.4 improved performance a fair bit (making 3.4 the fastest g++ version ever as of the release they claim). The performance for compiling without optimization was improved even more in 4.0. For Gentoo users and other OCD-level recompilers it might not matter, but it does help developers everywhere. This is what I would personally call the place where it matters, end users that obsess over recompiling stuff themselves for no reason can wait.
It is overall a general consensus among gcc developers that performance should be improved. Don't expect C-level compilation speeds from C++ though, it is a heavy language to compile by nature. This keeps getting worse with the increasing prevalence of extreme template metaprogramming libraries like Boost, to a great part in meaningless areas in a quest for performance that will never matter or materialize (I don't claim that Boost or template metaprogramming is a bad thing, just that people obsessivly use it in places where normal coding practices would do just as well except for imagined performance/purity issues).
If you want stability, then don't run debian unstable. You'll probably be far better off on ubuntu, which essentially is debian unstable, stable.
This is your sig. There are thousands more, but this one is yours.
The GCC people are changing the API as the enormously complex C++ standard changes beneath them. It's C++ that's losing credibility (frankly anyone who can get a reasonably compilant C++ compiler out the door deservces praise)