Richard Dale
recently pleasantly surprised me (and probably others) byannouncing that he has committed C bindings for the KDE3/Qt3 libraries toKDE's CVS.
Richard generated the C bindings automatically using a hackedkdoc, with relatively little
manual intervention. According to him, "The bindings wrap about
800 classes [and] 13,000 methods, with 200k [lines of code] of C/C++
generated." The same hacked kdoc can also
generate Objective C and Java bindings, and Richard hopes to be able to
consolidate generation of thesevarious
KDE bindings (Java/Objective C/C)
with this one tool. Currently the C bindings forKDE
3 andQt 3
are in KDE's CVS, with bindings for KDE 2.2.x/Qt 2.3.x
awaiting resolution of a dynamic linking/PIC problem which affects the
Objective C bindings (please contact Richard if you are knowledgeable in
this area).

Comments

It is assembler which produces far more efficient programs in all cases, but with C it is almost the same. In fact C++ is a C with some high-level additions. If you want to write a good app you have to write code fast when efficiency is not a matter ( 95% of typical GUI program ), and polish those small critical parts which need it - C++ shines here. Even in those low-level areas it is better than C - when the autor mastered templates and STL he needn't to reinvent sorting procedures, containers etc. If you want to do reasonable GUI development you have to build your own, nonstandard object layer on top of C, as gtk team did ( look how, for example, "inheritance" is implemented in gtk. Uff !!!!!! Only masochist can think that C is better for GUI apps ) I don't like also gtk "appealing" to other developers. Question: If you have ten libraries and want to use them from ten script languages how many bindings should you write ? The whole idea with language bindings is BROKEN. The main drawback of C++ is messy and complicated syntax and slow compilers.

i strongly doubt, that you can write far more efficient programs in assembler in all cases given the actual processor-design. sure, it is possible, but you will lose your mind in the process. only think of the difficulties you will have with keeping the command pipeline filled and thats not the only issue...

this is obvious for x86 platforms: the intel of course :) just read an article in the ix (german computer magazin) about the intel compiler for linux that said a simple recompile boosts perfomance up to 30% compared to gcc! with optimizations even up to 50%... i think that proves, that it is essential to know the internals of a cpu to write efficient assembler code and beat an optimized compiler might be very hard. (and there is more weird stuff in other cpus than x86...)

I thought we'd stopped having discussions about the relative merits of assembler vs. high level languages about the time punched cards went out of fashion.

Yes, of course C is completely unsuitable for writing GUI apps, but that isn't what these bindings are for. They are to allow people to implement bindings for languages which can't call C++ directly, like Objective-C.

"The main drawback of C++ is messy and complicated syntax and slow compilers."

Yes, C++ and/or STL doesn't shine, it stinks. Only a (genius level :) ) masochist would think that C++ is a great scripting or RAD language, and that we should give up all efforts to use more suitable languages such as Ruby or Objective-C via language bindings.

"Yes, C++ and/or STL doesn't shine, it stinks. Only a (genius level :) ) masochist would think that C++ is a great scripting or RAD language, and that we should give up all efforts to use more suitable languages such as Ruby or Objective-C via language bindings."

I meant that a good component model with IDL compiler for generating bindings would be better than maintaining and trying to keep up to date huge bindings. I could be even something like specialized IDL for binding C++ to C for Qt-based programs (without components). So, of course, language bindings are OK, but it should be done "by hand".

Yes - see kdebindings/kdejava/koala/kdoc for the tool used for the Java bindings generation. The C and Objective-C ones are very similar, but I just wanted to combine them all into one tool before checking it into the KDE cvs. I can send the source of the C and Objective-C source conversion tools to anyone interested as an email attachment.

Hee hee... Did you learn about DirectFB on Slashdot today? That was my article :-)

I'm excited about DirectFB. It seems like it could be a real X replacement for Linux desktop usage. If there was a QT port, it would be perfect. Perhaps DirectFB and QT/Embedded could get together? The nice thing is that no one has to give up network-transparent X apps to use DirectFB, since most programs nowadays are GTK or QT and can easily be compiled for X, and there is already an X server available for DirectFB. That way all those X diehards can continue running their apps remotely while the rest of us have fun with alpha-blended video players :-)

can DFB be run remotly like X can or do you have to use an Xserver on the remote system? also, can you write a program that localy takes advantage of DFB but remotly uses X? if the answer is yes to both I think it has a chance.

With XDirect, DirectFB essentially becomes an X server, capable of displaying X apps that are running remotely on another machine, or even locally on the same machine, just like XFree. You can continue to use your DirectFB native apps at the same time, but you can't display DirectFB apps remotely. That would defeat the whole purpose - DirectFB is meant to provide nearly direct access to the hardware for maximum speed. It might be possible to write a program that selects whether to use DirectFB or X at runtime, I'm not sure. What would be really cool is if you could dynamically link a KDE program to either QT/X or (hypothetically) QT/DirectFB depending on what you wanted, without a recompile, but I'm not sure if that's possible. The thing is, though, if you really need apps to run on both DirectFB and X, you can simply compile it for X and use DirectFB's X server.

does the X app benefit from running under XDirect as apposed to XF86? also, I would be cool if it Dynamicly linked the rendering engine at run time. I think it would be great for games and office programs and the base Desktop environment to use only DFB, and admin tools could use X....I think that programers just ned to consider what the app will be used for and program it for the correct rendering engine. programs that are in reality only good for local use such as games and office productivity and internet tools should use DFB, programs that can be realisticly used remotly or localy should use X. I say realisticly because what person in their right mind would play a game on a desktop from a remote machine? it whould be easier to just place the game on an NFS partition and place the link localy.

I think DFB deploied in this way on a linux machine would be very productive and give all the benefit for X apps and DFB apps. to apply each tool to the place it will do the most good.

>does the X app benefit from running under XDirect as apposed to XF86?

You can run it with DirectFB apps, which I suppose is a benefit, and you can set a global transparency for it, which is kind of pointless. The point isn't to run X apps better, though. The point is to be able to make efficient DirectFB native apps, while still keeping backwards compatibility.

>I think it would be great for games and office programs and the base Desktop environment to use only DFB, and admin tools could use X

I think that it would be better to decide what you want to use your system for when you set it up, and choose at that time whether to compile (or get RPMs of) all your apps for DirectFB or X. Dynamically changing the rendering system at runtime would be way cooler though :-)

Hi,
I am not exited about DirectFB at all.
XFree86 as a graphics subsystem is not only an implementation of the X windows system, it also has some features for direct accessing the graphics hardware: DRI for 3D and DGA for 2D for example. Also there is Shared Memory in its different variants (Shared Memory extension, I think XVideo is based on SHmem ...). When your video output is too slow it is almost always the way the app was programed.
Additionally, DirectFB runs in the kernel layer, so a bug in your video driver can bring down your whole system like in windows. There is a little performance loss if the Xserver is an additional layer, but a huge gain in stability!!!
The reason why we don´t have proper alpha blending etc. in XFree86 today is the missing rendering model for this type of graphics handling. The core rendering model is based on postscript, but stripped down. It can only do things like diplay recangles, draw lines fill etc. you can´t do alpha blending with this :(
The beauty of the X window system is that it has only the necessary things in its core the rest happens through extensions. You will always need to draw lines and rectangles etc. The core gives you the basics.
If you need feature xyz you write the xyz extension!!! The extension decides whether it is via direct access or networktransparent.
This also helps to get rid of "stupid ideas" easily. Some years ago there was PEX for 3D graphics. Today everyone uses GL so you can get rid of the PEX extension -> no bloat! The extension can make feature xyz either available for direct access only like DRI, or over the network like RENDER. If implemented correctly it is as fast as every DirectWhatEver!

Please understand that XFree86 is more than just an implementation of the X window system. There is absolutely no need to get rid of XFree86!

DFB runs at the kernel level? IIII......think I am going to stick with X :-) I don't like a lot of stuff running in my kernel that is dependant on a totaly seperate project.....besides, Linus would never allow that in since not all the drivers would not be under the Kernel hakers control.

>Additionally, DirectFB runs in the kernel layer, so a bug in your video driver can bring down your whole system like in windows. There is a little performance loss if the Xserver is an additional layer, but a huge gain in stability!!!

This is totally wrong. The framebuffer is in the kernel but it is only used for mode switching and a couple of other things, the entire DirectFB library is purely userspace and no more crash-prone than X, much less in fact since it is much smaller. Anyway, haven't you had your display locked up with X before so you couldn't use your computer? No one cares if the kernel is still running underneath, its the display that counts.

And don't go saying there's "little performance loss" either. You don't know that, and I don't know that, until something else is tried. I think DirectFB has the potential to be noticably faster, and I think we should try it and see.

Using Shared Memory or DGA the performance loss is minimal. Of course alpha blending and such will be slow if there is no appropriate rendering model in your driver and the app has to do the rendering and send the result to the Xserver.

If you go the networktransparent way (app sends request to Xserver, XServer writes to video memory) speed is reasonable as long as the rendering model supports it. And exactly this is the problem!!!

There was no development going on for over 10 years, because X was used by companies that produced servers, which mostly don´t even have graphic cards.
So we are missing the proper rendering models, not directness of the video driver. Again, now there is RENDER, DRI, Xvideo, DPS, DGS and many more...
Many excellent programmers are working on XFree86, a lot of innovation is coming from this project. The missing features will be integrated soon, a long time before DirectFB gets usable.

it sounds like XF86 is an exciting project to work on.....I think you need to get out and advertise more about what is going on at the project....I bet most people just think that you guys are sitting around looking for bugs and writing generic drivers which is where I bet most of this X is slow and bloated crap comes from, the people just don't know enough about the project. what is going on in the setup tools realm? are they working on a nice simple select and enter system where you don't need to know a ton about your hardware?
what about making the resolution settings more dynamic and less buggy when a change occurs? are you working on Direct3d libs? do you think your font server is getting much better?

it sounds like XF86 is an exciting project to work on.....I think you need to get out and advertise more about what is going on at the project....I bet most people just think that you guys are sitting around looking for bugs and writing generic drivers which is where I bet most of this X is slow and bloated crap comes from, the people just don't know enough about the project. what is going on in the setup tools realm? are they working on a nice simple select and enter system where you don't need to know a ton about your hardware?
what about making the resolution settings more dynamic and less buggy when a change occurs? are you working on Direct3d libs? do you think your font server is getting much better?

I see the main problem with X being slow is the acceleration architecture. For example (I read this in an interview with the Konqueror developers, so yell at them not me if it is wrong) X doesn't accelerate operations on pixmaps. Did you notice that most of the KDE themes are pixmap themes...I switched from using a pixmap theme to the builtin NeXT style, and the apps run a bit faster now. Also, there does seem to be a problem with context switching--you have the X server, windowmanager, applications, and other invisible apps. You have to do a lot of context switching between X, the app, and the windowmanger. Maybe if the WindowManger become part of the X server (i.e. it existed in a library that implemented a set interface so the X server could dlopen it, initialize it, and then run it in a thread). Maybe the pre-emptive patches to the Linux kernel would help, since they appear to reduce context switch time? DirectFB is not the solution! Write me a DirectFB app that will compile on GNU/Linux, all of the BSDs, SCO, Solaris, HP-PA UNIX, etc and I will use it. DirectFB is just like SVGALib, but with acceleration and such. I can see it being used for fast full screen games (I use the heroes of might and magic 3 dynamically linked binary and use the SVGALib display target of SDL because it plays _much_ faster that way). X is good. X is extendable. Most of X is a set of extensions (i.e. GLX, Shape, Render, etc). Is DirectFB able to be extended?...

The window-manager running as a seperate process doesn't make a whole lot of sense to me. It should be a binary module that can be dynamically loaded by the X server. Sure, in that case, a crash in the window manager could cause the Xserver to crash, but then, how often does kwin crash on you? I have a feeling that the overhead of an external window manager has something to do with X's perceived slowness in certain window-resize operations. If you look carefully, you'll see that Qt/X11 is very snappy to actually draw. Even under a complicated style (Liquid) redraw itself is very fast. Actual benchmarks of the X server bear out that it is faster than the GDI for most operations. What really seems to be the hangup is *intelligent* redraw.

So sure, you can write the Matrox drivers quite easily, and maybe few other cards - but you won't get any co-operation from nVidia, not ATI, nor S3, nor ST Micro (Kyro chip). You also won't have sufficient solution for 3D (DRI on DirectFB == slowness).

And if thats ain't enough - it's based on some kernel hooks, which means if this got bug - your machine goes down - Panic mode, and even if you make it stable, Linus (nor Alan Cox) will ever put it inside the main kernel version, so your users will have to patch and recompile the kernel to use this. Not a very good idea..

Its been said before and I say it again - yes, X is old but X is getting better all them. Take for example XFree 3D performance with NVidia drivers and compare it with Windows drivers - try a game on both of them and measure the FPS - you'll see that XFree FPS is maybe 2-4% slower then windows and consider that the entire X is loaded to memory while on Windows it's not.

X had lots of ugly and old code in it - but they're killing old stuff and putting new features and extensions all the time (hence the new Xv extensions with texture support, RandR extension to switch to any resolution/color-depth on the fly, XRenderer support, HP port [coming soon] of true 3D on dual heads [SHS], Mesa improvments for OpenGL 1.3 and 2.0, etc...) - when do u think this DirectFB will have it? in 3 years? who's going to fund such a development?

And I'm not mentioning applications of course - if you want it to be used, it got to run old applications (remember Motif? Athena widgets? TCL/TK?) which even if it will support - I can hardly imagine any serious ISV will support it..

To summorise my respond - X is pretty good solution for graphics, and it keeps being improved. DirectFB roads looks to me more and more like Berlin and GGI tried before (and you know whats with them today). I wish all of them good luck, but I can hardly belive they worth the effort.

They seem to be doing quite well so far on getting drivers. It is true that XFree supports more right now, but the developers of DirectFB seem to be quite dedicated.

About your kernel panic comment: This is NOT TRUE! Why do so many people think DirectFB is a kernel module or something? DirectFB is a normal user space library and all the work of hardware acceleration is done in user space. All it does is call the normal kernel framebuffer which is already in the kernel (yes, approved by Linus and Alan Cox) to set the video mode and do a few other things. It will NOT bring down your kernel!

Besides, what good does it do you when X crashes and locks your display that the kernel is still running underneath? You can't recover your work. The only thing you can do is telnet in and kill X, which kills all your applications. It might save you a reboot and fsck, but with ext3 in the kernel now, there's no excuse to still be fscking.

About old applications: DirectFB has an X server, so you can still run Motif, Athena, etc. No problem at all with support for old applications.

Look! there it is! OpenGL support on one of the drivers for DirectFB! The Matrox series. Guess that were not just 3 years that passed by since I read this article....were it? And about Nvidia support.... I personally got information and very usefull headerfiles from guy that makes Linux overclocking utils at Nvidia. How's that? Another argument put to the ground. And documentation is still coming.
DirectFB might be based on the kernel and might crash when the kernel has flaws, but look at the Nvidia drivers! They also have kernel stuff with them that requires to be loaded.

FrameBuffer support is under developement and in 2.6 is it not experimental (as it was in <=2.4)

Btw, did you even read the website? It was meant for embedded stuff. I wouldn't want to see X run on an embedded system. And believe me, I ran it on a 486. For 2 days, after wich I ditched it.

Ow, here are a few things against X:
- Why is it network-based if graphics-intense stuff performs like shit?
- Why is the client-server model flipped on it's back? The client dies when the display-server crashes (wich still is likely to happen)
- Why do Nvidia drivers often lack SMP support and make people with 4 CPU's run Linux over 1?
- Why does stuff like MPlayer perform _way_ better on directfb when compared to X?
- Why is the X-windows protocol known to be more overhead than actual data?
- Why does linux (read: X) still lack a general look?

I'm not a particular fan of DirectFB. It's a step backward. The directfb X server misses the point - you lose all the benefits of network transparency for _new_ applications. This sort of thing will be increasingly, not decreasingly, important - think of wandering into a room with your bluetooth-enabled PDA and having the GUI for equipment in it appear automagically.

The X Window System is burdened with some legacy crap - but it is being phased out. The whole font subsystem, for example, has just been reworked. The XRENDER and forthcoming RandR extensions, in particular, give X whizz-bang eye-candy features like alpha blending etc, and will do it in a hardware accelerated manner on cards that support it (i.e. all modern big-name 3D cards). And the DRI/GLX subsystem is nice, although AFAIK it's not to the point where across-the-network GL commands are also HW accelerated properly. The modular redesign that happened in XFree 4 also means that it's easier for 3rd parties to write accelerated display drivers - for example, the NVidia and Matrox modules.

Personally, I think Display Postscript / PDF (MacOS X quartz) is a nicer way to do it all (since it uses natural units (inches or mm), rather than pixels, so will look good even on 600 DPI Monitor of the Future) - but, guess what? Display Ghostscript for X is coming along nicely too!

Also, X isn't really slow. It was a tad slow when it came out. Back then you were lucky to have 8 MByte on your $20000 computer. These days, it's not slow, unless you're on a card that isn't accelerated, or have it misconfigured.

One thing to note is that on Windoze and MacOS, the GUI has its priority bumped so that it pre-empts background tasks. Try negative renicing the X server for a similar effect on linux, giving a jump in responsiveness. It even suggests this in the X documentation - most distros don't do it, because they're mainly still destined for servers. The kernel pre-emption patch at http://www.tech9.net/rml/linux/ will also make your interactive sessions with your computer more pleasant.

Oh, and, it's always worth pointing out that the memory usage reported for X in top includes the entire adress space of your graphics card - so if you have a 32Mbyte card the reported size will be at least 32 Mbytes larger than your main system memory usage (possibly even more, since not all cards have a linear address space)

>The directfb X server misses the point - you lose all the benefits of network transparency for _new_ applications.

No you don't: You write your apps to QT or GTK and use either X or DirectFB depending on what you want. Notice that practically nobody writes pure X apps anymore, and I don't expect anyone to start writing lots of DirectFB native apps. DirectFB is just a faster way to display QT or GTK apps, an option for people who want speed and efficiency and don't need network transparency (i.e. the majority of KDE users). Maybe high-performance games would be written directly to DirectFB but they aren't network transparent anyway so there's no point in writing them for X.

(a) I'm not so sure that DirectFB _is_ *significantly* faster than a properly configured X setup, even in the local case. X has a massive head start in accelerated driver support, and the continuing modularisation of the X server is making it easier and easier to write new drivers. X has a lot of good design features, as well as some bad ones. The bad ones are being phased out, and new ones are taking their place. 3/4 of the complaints I hear about X have little basis in fact, and many seem to come from people who have never even RTFM of X. Qt and Gtk are not actually good examples of toolkits which take advantage of X's strengths - they both go in for a fair bit of wheel-reinvention, since Qt (and newer versions of Gtk) are not targetted solely at X.

(b) Re: Games. One of the major points of GLX is to allow high performance 3D to be network transparent! The current DRI and GLX implementation in XFree86 fails at this goal - but it's in the roadmap and the framework is there. In thoery, one should be able to run an application on one box, and have its display hardware-accelerated 3D using the hardware of a completely different box running an X Server with the GLX extension. No you can't do that yet on linux, but it's a matter of time/developer effort - the standards for it are already written, and certain commercial unix systems have being doing this for years.

(fc) People who do not understand unix^H^H^H^HX are doomed to reinvent it. Poorly.

> One thing to note is that on Windoze and MacOS, the GUI has its priority bumped > so that it pre-empts background tasks. Try negative renicing the X server for a > similar effect on linux, giving a jump in responsiveness. It even suggests this > in the X documentation - most distros don't do it, because they're mainly still > destined for servers.

Where does it suggest this? I remember thinking of this on my own but not noticing a real difference (this years ago)

Well, I use renice -10. The difference can indeed be very slight, particularly if you're already using a modern computer with lots of mega-hurts :-) and a card that's decently supported under X. Since the linux scheduler dynamically fiddles with priorities fairly enthusiastically anyway, the difference also isn't as huge as on older UNIX. However, there is a perceptible difference in many cases.

One other thing to note is that if you're using xfs for no good reason (as many distros, irritatingly, do), then stop (there's very little need for xfs[ft|tt] these days, now that TrueType support is integrated into the v4 XFree). If you renice X itself, then it can end up starving the xfs process a bit, which means you could actually end up making things a little slower.

If you are currently still using xfs on a local machine in order to use outline fonts (rather than the legitimate use of it for serving fonts to multiple thin client X servers)

This will add TT fonts to the old X font mechanism (there's a new, better, non-backward compatible mechanism based on the XRENDER extension for antialiased fonts - setting up that system is a different kettle of fish - but only applications rewritten to use the new extension can take advantage of it - fortunately, that includes KDE :-) )

Now, if you put directories containing truetype fonts
in the
FontPath lines of
Section "Files",
they'll just work (provided you've run ttmkfdir in directories in the normal fashion.

RH and Mandrake keep the xfs configuration in /etc/X11/fs/config -
if you copy the contents of "catalogue" section of that file into XF86Config
as your FontPath, you won't lose anything. - there's also no point keeping
the line Fontpath "unix:/-1" in your XF86Config, as it tells the X Server to talk to xfs.

> One thing to note is that on Windoze and MacOS, the GUI has its priority bumped > so that it pre-empts background tasks. Try negative renicing the X server for a > similar effect on linux, giving a jump in responsiveness. It even suggests this > in the X documentation - most distros don't do it, because they're mainly still > destined for servers.

Where does it suggest this? I remember thinking of this on my own but not noticing a real difference (this years ago). What would a suitable value be?

I think that is time for X to go. Cause it's old and slow, dont give me this crap about apps being slow.

Netowrk trans... who cares, tell me, what app are you using over the net. A real
X (XP) terminal cost's the same as a new machine (AMD, duron). And you get much better performance, you have sound and you don't wait as long. Why slow the net even more down???

1. X is not slow. It was not slow 14 years ago when it was created, and
with increasing bandwidth, it has only become faster. In fact, I think
it was Jim Gettys who once said that an XPutImage over a network today
is as fast as a local XCopyArea in 1987.

2. I care, and I care very much. I use Emacs, matlab, xdvi, gv and
other programs over the network all the time. What this has to do
with the hardware used is beyond me. Running X doesn't imply using an
X terminal. In fact, most X servers today certainly run on ordinary
PCs.

I run my entire X session over the network, all day every day. I very much care for the network transparency. I get sound over the network too thanks to the EsounD project. And I get the very best in performance, as instead of buying 3 top-of-the-line machines to dot around my house I bought 1 even better server and 3 cheap (no hard disk, weak CPU, low RAM, but very decent gfx card, all standard x86 hardware) terminals. This saved me a packet and got me performance I could not otherwise afford.

At work we did the same, because the company wasn't going to shell out for £8000's of sun server for each developer, and they would have looked ridiculous underneath our desks. Instead the company bought one such server, and an X terminal for each of us - a custom job of x86 hardware + linux + XFree86 that cost £250 a piece. A saving of £60,000

Just because YOU don't use the network transparency of X please don't assume no-one does. X network transparency is what makes X stand out above the crowd, and in the right set up, it can save one hell of a lot of money, administration and noise pollution.

As for DirectFB, I have little use for it right now because I never run any local apps, but its there and its small and it looks so very very good, so job well done and keep up the good work.

If I ever get a PDA, I want to see it running DirectFB ;-)

P.S. If X is so slow, why do I get better fps running Counter Strike under linux + wine + X than I do under windows?

FACT: Encoding/Decoding of any protocol (GLX/X) is an CPU/Bandwidth overhead.
FACT: For the fastest possable graphics software you need direct access to the underlying graphics hardware.
FACT: For the fastest possable graphics software you WILL lose network transparency.
FACT: DRI is NOT network transparent.
FACT: DRI was created BECAUSE the x server protocol IS to SLOW.
FACT: Remote GUI Access does not mean you MUST use X protocol.
Stupendus Examples of such are:
Remote Desktop Protocol (RDP)
Virtual Network Computing (VNC)
FACT: RDP/VNC Does NOT require you to develop your applications with a specific toolkit to get the network transparency functionality. ( X does )

BOTTOM LINE: Higher performance comes from direct access to the graphics hardware the X protocol cannot give you this, it will ALWAYS BE SLOWER! Network transparent GUI has a place, However it is not between a local user and his local graphics hardware.

>> P.S. If X is so slow, why do I get better fps running Counter Strike under linux + wine + X than I do under windows?

Because it's using DRI, which is NOT network tranparent and gives your application direct access to the graphics hardware by bypassing the OLD and SLOW X protocol.

That's not true. There are X11 Programs that run OK even on 486 computers, xfig for example. Why is kontour that much slower than xfig? They both run in X.

Yes, X11 adds some overhead, but thats not what makes Gnome and KDE so slow. KDE and Gnome are so slow because the huge number of libraries linked to them. They take some time to resolve symbols at start time and make cache less effective, just because they don't fit in it.

Slashdot has been such insanity for years... how could one actually read slashdot (the comments) and glean anything out of it these days? Do people even bother making informed posts over there anymore?? (no offense to anyone who still does, if anyone does).

hey, I am a metamoderator over there.........all I have to say about /. is oye......the last 2 weeks the news has sucked, the editors are dumb and the post moderators are a bunch of 1d107 highschool weenies......I got modded down as over rated.......Im sorry, but why is that even a moderation? I earned my posting score or 2 damn it........

less content crappy moderators....I only wish I had thier names when I moderated the moderators.