Slashdot Mirror

I don't know how X.org is doing these days in terms of progress. The Fresco project appears to be dead.

Does anyone know anything about GGI? Do they have a handle on this concept?

http://www.ggi-project.org/

The KGI project still seems to have a website but mostly deals with FreeBSD.

There is also the GGI project which has been ported to both Vista, Linux, FreeBSD and Solaris.

But have these projects been overtaken by 3D desktop environments?

Let's assume this is a "because it's there" hack, because as others have pointed out, if all you want is a large video screen, you'd be better off spending the time doing a McJob and spending the proceeds on a projector.

So, you're doing it because it would be kinda cool. Have a play with GGI. It's a portable graphics layer with various targets implemented. e.g. there are kernel targets for various graphics cards, a Windows target, a VNC target, etc.

What'll interest you is the display-tile target, which is a proxy target that splits its input into tiles and forwards them to a set of other targets.

So:
  - find the most efficient way you can to display video on a GGI target. Mplayer can do it. here is a screenshot of mplayer tiled across a load of X windows via display-tile.
  - Set up each of your displays to be a GGI target that your central box can display to (be it VNC, X, or something more original)
  - configure display-tile to forward the right tiles to the right targets
  - point mplayer at display-tile
  - profit!

The tiles don't have to be a regular size. I'd quite like to see a video wall made up of various sized screens - a 32" TV here, a 17" monitor there, a PSP there, etc... maybe a vt100 in there displaying the aalib target...

Fun!

...not bound to any particular OS.

If that's what folks are looking for, another option is the tasks added to LibGG a while back. Tradeoffs either way -- LibGG's requires at least C signals (but will use pthreads or windows threads if detected during compile time), whereas this can be used in OS-less firmware. But on the positive side you can use switch() in LibGG tasks -- what
you can't use are a lot of non-MT-safe system calls. It's an OK abstraction but of course there are so very many ways to accidentally ruin portability that it is far from foolproof.

http://www.ggi-project.org/documentation/libgg/1.0 .x/ggAddTask.3.html

For anyone looking to do this with free software.. it has been around for YEARS. Infact, it was around before XFree86 supported Xinerama! Unfortunately, it does NOT do 3d acceleration; however, I'm providing this information for anyone else still interested.

Take a look at GGI + XGGI. Run an X11 server on each host and run XGGI, targeting each.

Take a look at the following screenshot:
http://www.ggi-project.org/resources/images/doom.j pg

Now, imagine that each of those tiles was displayed on a separate physical display, each running X11. You can do it.

If it's best to put the display code in the kernel, then this opens up that possibility, but does not require it. It opens up a wide variety of possibilities, where a protocol is limited to a client/server architecture. X's client/server architecture is the oddball in the world of display architectures, while a standard API is the norm.

I believe this is the way the GGI project is architected, so it's not a crazy idea at all.

This reminds me of the GGI Cube which did something similar. Sadly GGI is today rather irrelevant.

Tilt the canvas, twist the canvas, paint it around a cube and spin it...

If someone is looking for alternatives, look at XGGI, part of the the GGI project. Together with directfb or KGI(currently focussing at BSD, but the Linux core is there too) it's really powerfull.

This is what KGI, the kernel portion of the GGI project implemented (during the 2.3 series kernels), but the project exhausted its social captial in arguments with Linus and others and KGI never got merged.

Here is a link to Linus's thoughts on this:

http://www.ggi-project.org/mailinglist/may99/320.h tml

GGI Project, and 3dwm.

So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?

At what level? SDL? GGI? GTK? Qt? wxWindows? KPart? Six of one, half a dozen of the other, perhaps you're spoilt for choice?

Both KGI and GGI are alive and kicking at the moment. KGI, the Kernel Graphics Interface is almost rewritten from scratch, and GGI the user level library is developping very well.

Please click the links for more info.

How about A) A graphics layer worth shit?

I'd heard briefly about the Mozilla bug, and I understand why it's X's fault, but I'm curious... how is it that X is able to crash the system this hard? Because it's got direct access to hardware?

There's an interesting historical footnote that underscores how developer egos and stubborness (on both sides of the argument) can lead to disagreements and very sub-optinmal solutions. The folks working on the GGI project tried to fix this back in the 2.0 kernel days (and possibly earlier) and were poo-pooed by Linus Torvalds. Their argument was that the kernel's job is to abstract the hardware layer from userspace software, so that applications like X don't have to talk to the graphics card directly, they simply make functions calls to the kernel code, which are handled by the appropriate device drivers. Similiar to the way just about every other piece of hardware on your GNU/Linux system works.

This was an argument that, at the time, I felt Linus was completely wrong on, and the GGI folks were completely right on. But of course, as a mere user and developer on GNU/Linux, and not a kernel developer, my opinion counts for little (even less since I chose not to get involved in that particular argument at the time).

Ironically, the kernel developers backpedaled a little on this with 2.2, and moreso with 2.4, in which they implimented the rudiments of a framebuffer system that does precisely what GGI advocated, though not nearly as well, and not for as much diverse hardware.

The GGI project is still very much alive, and doing very intersting work, for any who are interested. I haven't had time to play with it for a while, but it is on my list to get back to at some point. Imagine how much cleaner graphics usage would be under GNU/Linux (and perhaps other *nixes) if, instead of having to tack on hardware specific tasks onto X, it were being done in hardware device drivers instead. They argued, quite compellingly IMHO, that X crashes should never be able to take down the operating system, regardless, and that with proper hardware abstraction done via kernel device drivers, as is done with every other piece of hardware in the system, it would be impossible for X to do so (barring, of course, bugs in the kernel code itself).

[the counter argument was that 3d acceleration and other graphics primitives were too bloated to go into the kernel. The GGI folks didn't design their stuff this way ... the hardware access routines go into the device driver, the rest of the logic resides in user-space libraries. You get the complete hardware abstraction via the kernel features, including accelerated 3d support, without the kernel bloat Linus and others so feared. It is really quite elegant, and might have spared us the whole GLX/DRM/DRI mess anyone wanting to do 3d acceleration under X has to suffer through these days, had anyone listened at the time].

So instead, today, we have X talking directly to the video hardware with little or no kernel involvement (unless you're using framebuffer support and the fb-dev X driver), and when X goes south, there's a good chance your entire hardware and operating system are heading south along with it. It is the only situation in which GNU/Linux performance approaches that of Microsoft Windows, and it is due to a design flaw in how grafics cards are accessed from within GNU/Linux -- directly from the userspace program instead of via a standard, hardware device driver like everything else.

That's where you can use something like GGI as an abstract library over either backend. Other infrastructure, like GTK or QT, could also be ported to both backends.

It seems similar -- GGI uses KGI, where I suppose DirectFB uses the framebuffer. The advantage being, I suppose, that the framebuffer is included in the main kernel where KGI has always been a patch.

But the problem with the framebuffer is that it is so darn slow. Perhaps reasonable in hardware that doesn't have any graphics acceleration (like on a handheld), but not useful on normal computers. I don't know if there is any real effort to ever make the framebuffer any faster -- the very name seems to imply non-accelerated simplicity.

I think the path away from X involves factoring the pieces better -- maybe that can even save X, as Xlib isn't really the problem, it's all the other half-assed crap that goes with X.

I'm glad you're annoyed. Without such simplistic 2D primitives inelegant hacks are all that's left to do. Hack after hack after hack. For those that find that this scratch needs itching there's goatse... or GGI, DirectFB, (Linux Only Framebuffer), or EVAS.

That's not that bad, but it's no better than Windows 2000. Seriously, the Linux kernel development has not focused on real stability issues, and seems to have little intention to do so. One area that has caused me considerable problems, but will no doubt be fixed, is VM issues. If some rogue program takes up all my virtual memory my computer becomes unusable. I can't even telnet it and kill the offending program most of the time, the system is so sluggish.

The other real problem is one that Linus has decided to, basically, never fix: X. X is really part of the operating system. It does an operating system job -- provides the "safe" interface between software and hardware. Of course, it's not safe. X can bring down your system. Or, even more easily, the X-based interfaces can become unavailable (keyboard lock, some weird focus issue, etc), and there's no way to kill the offending program (unless you have close access to a computer to telnet in).

Linus has decided that graphics are Too Hard, and he's not willing to deal with it. Which is, if you ask me, totally lame. It's like saying virtual memory is Too Hard, and people should just make sure they have enough RAM. Linux is DOS-level when it comes to graphics.

And, yeah, X is complicated. Because it does a lot of non-OS stuff too. But that's what caused programmers of yore to create concepts like abstraction and interfaces -- concepts which seemed to have escaped X designers.

The annoying part is that people really wanted to fix this situation: GGI/KGI (KGI being the kernel level stuff). But, at least from what I understand, they've been put off by Linus and can't get into the kernel. As a result the development has been extremely slow, because the motivation has been understandably low. Looking at the website, though, there's been some activity in the last few months, which is good.

X isn't a powerful architecture. It's excellent and impressive how far it has gone, but it can be done better.

Berlin is resolution independent, uses CORBA, blah blah blah. All the good stuff.

The main issues now are getting hardware acceleration for Berlin. It can run in an X window, or on SVGAlib - which isn't fun for anyone.

Qt Embedded is, as the name suggests, mainly for embedded environments (meaning it's small).

The features are nice but it wouldn't be able to support the most simple hardware acceleration features (like blitting) and such because it only interfaces to a dumb block of memory, the framebuffer. This is evident when actually running QtE...

Flicker time!

Even in just 640x480 the tearing and flicker stick out like a sore thumb. . . and that's with the matrox optimizations compiled in.

A project that seems to be promising is the GGI KGI combo. GGI for the graphics library and KGI for the hardware acceleration/abstraction. If the Qt library was ported to GGI then there would be a real posibility of having an X'less, accelerated desktop for linux.

It's probably a little more correct to say that, although Berlin can do 3D, it's resolution independant and it's GUI is vector based. Unlike pixel based GUIs everything doesn't crunch down into the top left corner of the screen - consider it more like Quake in that a higher resolution adds more detail to the same physical. Current GUIs encourage using a low resolution to clearly see lettering - they don't fully exploit the maximum from your hardware. If anyone remembers that slashdot story a year ago about a 15" flatscreen monitor doing 3000x3000 (or something) and running MSWindows.. the widgets were so incredibly small it was unusable. It's like something you'd hear on the news - but pixel based GUIs are the y2k bug of interfaces.

The GUI is very NeXTish from the resizing widgets. And, as Apple kil^^bought NeXT it's very similar to MacOSX in it's graphical style. Berlin is more advanced than MacOSX though.

The main problem facing Berlin however, IMO, is hardware acceleration. There is no hardware acceleration for transparent GUIs (as proven in ArsTechnica's review of MacOSX's GUI and how Apple are talking to hardware manufacturers for a solution). This would involve a layered approach to 2D rendering. Anyway, drivers for Linux are only written for X (with few exceptions) - Berlin will have a difficult time unless they figure this out. Currently it's not hardware accelerated and is as slow as any SVGALib software, ugh. Berlin needs hardware acceration to the level of X at least. It would be nice to bypass X server entirely though (while providing a compatibility layer).

I would love for BeOS to have a vector based interface. Their GUI although very functional isn't nearly as advanced as the rest of their OS. They can't have a GUI object that isn't in a rectangular window for example and increasing font-sizes breaks their own bundled applications.

Berlin kicks arse though. It's a really exciting GUI project and I highly recommend developers joining in.

Why not just port GTK to GGI*. Sure, they haven't updated in a while--but with a big name project like GTK relying on them, maybe they'd get a move on.

(Note to latecomers: GGI is a display-device agnostic graphics API--it can use svgalib, framebuffers, X windows, X root window, even paper!)

*I just tried to follow my own link and found the I couldn't resolve the name. Google's most recent cached pages have dates from December. Is GGI dead?
--

Silly girl, there's a reason why Berlin will never succeed.

It's the same reason why other Open Source projects like the HURD, GGI, and Freedows are going nowhere fast: Too much design, not enough code.

Too often, non-programmers (or worse random C newbies) will propose some absurdly difficult endevour ("Just imagine: an Open Source version of Microsoft Office 2000! On my PalmPilot!"). Usually, this will be followed by the registration of a .org domain name, a SourceForge page, and a "0.01" announcement on Freshmeat. Occasionally, one of these ideas will be taken too seriously. Web pages will be written and re-written. Mailing lists will be created. White papers will be written. Developer hierarchies will emerge. Often, one sub-groups ego will be bruised, and they will splinter off to form some equally vaporous project.

But what never happens is code being written. APIs might be formalized, but that is worthless without working code. The most succesful projects (such as GNU, the Linux kernel, the BSDs, KDE, and GNOME) were founded on the "shut up and code" model. The authors spent time hacking rather than writing press releases or yet another web site revision, or the checking the latest PDF copy of the Offical Project X Standard for Widget Frobbing into a CVS mirror. And who gives us results?

Berlin is a pipe dream. A nice dream, perhaps, but so are many others.

But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway.

While 3D drivers would have to be in the kernel, I don't think that's so bad. That doesn't mean OpenGL has to be in the kernel, just the necessary interface to the hardware. Interfacing hardware is exactly what the kernel is supposed to do. Linus just wimped out because graphic hardware is more volatile than most other hardware, and there was a crappy (X) solution already.

But the reality is that X doesn't have the quality and security that the kernel has. Linux is not stable for me, because it's not uncommon that X blows up for some reason, leaving the kernel happily chugging along while the monitor and keyboard are completely frozen. If you don't run X -- like on a server -- it's easy to have great uptimes. Otherwise...

Proper abstraction is what is necessary. All of X doesn't need to be in the kernel. Only the part that interfaces the hardware. The rest can be done (safely!) in userspace, as opposed to doing everything (very unsafely!) in userspace as X does.

The framebuffer doesn't seem to be a good solution. I really think that KGI and GGI provide a solid technical solution. But Linus has been very negative about those projects, unfortunately, and they seem to be moving slowly :-(

GGI - the general graphics interface is a graphics API that supports multiple targets, including X, the framebuffer, ascii art rendering, and recently, an experimental MS windows DirectX target. Using a wrapper library would seem like a better idea because of the portability. There is an old GGI demo disk lying around somewhere showing that you can fit Linux+GGI in 1.4 megs).

SDL is a compatibility layer, and for 3D, it uses OpenGL. This person's looking for something that would replace OpenGL, too.

I recommend checking out the GGI project. It's essentially what you're looking for, short of the audio stuff. They've got input support through libGII, graphics through libGGI with specialized functions for advanced 2D in libGGI2D and 3D stuff in libGGI3D.

There's even a port of X to it, so you can run your X server "boxed off" so that X crashes don't take down the system. (Assuming you have a card that it supports; it really only supports about a half dozen chipsets--the ones the developers own.)

The GGI people had kernel-level drivers in KGI a year before the X people even started taking DRI seriously, and their monitor drivers auto-detect the hardware attached, no modelines or nothin'.

It's a shame, imo, that they never were more popular, but they were shunned at every turn. GGI never seems to make it into any of the commercial distros, and Linus apparently flipped over the idea of putting graphics logic in the kernel. (How quickly times change..)

In any event, the project link is http://www.ggi-project.org. Good luck..

(there might be the odd snap crack pop in XLib but most demo programmers I know have goals of tiny executables and SVGA.. not dozens of libraries and XLib. My associate is doing something ontop of GGI which i'm told is a lot better. An Amiga 500 could do something equally impressive, though).

-matthew

GGI-Project - Because lets face it, X sucks.

(my words, not theirs.)

I think.

Unfortunately neither X nor BeOS is good for 160x160 graphics. Very few windowing environments look good like that because it's hard to window at 160x160! Maybe what they need to do is port GGI and create a basic set of apps for that framebuffer system. Remember, you heard it here first...

If you really want to see a replacement for X, you can rally behind Berlin! They definitely need the help. They are at version 0.2 right now, and have been mentioned on Slashdot from time to time.

The above post should be read to the tune of Baz Lehrman's "Everybody's Free to Wear Sunscreen" speech.

Insightful, yes, funny, but when you're 11, you shouldn't be reading on /. all day. Go out and program! Write your own version of Pac-Man, complete with homing missiles, explosions, and profuse gore.

(Rant: )

Once you start on Slashdot, there's no going back. You start getting Karma, then you start craving more. First you post stuff that's insightful, maybe informative... after a while it trickles down to a few points of "interesting" here and there. "5"'s become rarer and rarer, then you do the unthinkable.

You resort to humor. All out "hope they don't think this is a troll", karma-whoring humor, the kind that only flies on Slashdot.

And before you know it, Slashdot is your browser's home page, and it starts taking up all of your free time. All of a sudden, there's precious little time to program, and you can forget about keeping your pretty GPA above C-level :-).

I broke 90 today. Karma that is. Weeks ago I've stopped reading /. all the time, but the Karma keeps pouring in. I feel dirty. I'm a karma whore. I've only been on this frickin' forum since November, and I'm at 90+ karma. I could troll all day and all night for a week and still post at (Score: 2) by default.

I've moderated 6 times, mostly on weeks when I was too busy to post.

People think I'm funny, insightful, interesting (and overrated, but those moderators suck! ;).

These are presumably rational adults, and I'm not even 18!

It's with this in mind, that I've decided to take a vacation from Slashdot. That means checking /. no more than three times a day. Three shall be the number of the checkings, and the number of the checkings shall be three. Check thou not 4, neither check thou two, excepting that thou then proceed to three. Five is right out!

Okay... sorry, just letting off steam.

And that also counts checking my "User Info" to see how much Karma I've gotten. Honestly, the stuff's pretty much useless once you reach 25, and can post at Score: 2. Of course, it's always nice to have some padding in case the moderators get bitchy.

And no more than 1 post a day from me, either. Maybe two if I'm on a roll. But that's it, except on days ending in "y". Then three's the limit.

I'm gonna sit down and program, play video games, go with friends to see movies, maybe get a <gasp> j-o-b, and maybe find a like-minded member of the female species to play videogames with, or whatever it is you're supposed to do with the opposite sex.

I'm going to code a decent game or two this summer. Maybe just one if I actually succeed at finding that elusive MOS. (You can bet your ass they don't hang out in chat rooms!)

I'll update my personal web page. Read more books. (An even 50/50 between reference manuals and sci-fi/fantasy novels).

Just as long as I can refrain from posting to Slashdot. Hey, maybe this means that I can finally disable cookies on my browser. (Mozilla's still crashy, even M16, so I can't use it for day to day stuff. M13 was good, though, and I did use that as my main browser for a time.)

Maybe I'll even update my Sourceforge project.

Whatever I do, I've just got to stay clear of this forum... it's addictive. As one reader's sig says, "I miss my free time, Rob". I agree so wholeheartedly it's not even +1, funny anymore.

I do have a suggestion, though. Weight the karma based on the posts you're trying to achieve.

If you think too many people are clowning around, make a "funny" post worth .5 karma and an "informative" post worth 1.5. If you think it's getting to dry, post a silly story and reverse the above. Change it around, but keep posters aware of the current settings.

And get rid of that damned "overrated" markdown. Moderators should be given better tools than "overrated" to articulate exactly what is wrong with that post.

Finally, kudos to the best change I've seen in /., that is the change of the default threshold from 0 to 1. ACs (and, yes I'm being hypocritical right now, but bear with me) keep getting lamer all the time.

So, I'm out of here for a while... tomorrow I'm going with a group of close friends (some of whom are actually, Females, to see Titan A.E., regardless of what Jon Katz may think of it [IMO, Katz himself is proof that just because someone bashes something/someone, it doesn't mean that they deserve that criticism.] Jon, kudos for Hellmouth and Geeks, both of which I strongly identified with. Keep cranking out stuff like that, and leave movie reviews to videogame-playing, anime junkie coder types like CmdrTaco :-).

And a big kudos to the Geeks In Space. Love the show (and no, I'm not taking a vacation from listening to GiS! Crank out that episode 31!)

Ahh... in the morning I get to decide whether to use SDL, Clanlib, or GGI for my game. So many choices, so little time. And, of course, it'll be GPL'ed so all y'all can enjoy it :-).

Good night, Slashdot. See you less often, for the time being.

But please don't take it personally. (It's not you, it's just me... I think I need more space... it's too much of a commitment... can't we just be friends? ;-)

Feel free to moderate me into oblivion, or to leave it at the default AC score of 0. It really makes little difference to me, and honestly the impact you'd be making either way is negligible. Nobody reads at zero anyway, unless they want to see posts like this one.

Perhaps we need to get rid of "topics" as they're known, and have a giant message board for all stories. That could get interesting.

Your poster geek-in-training, the kind who's going to keep free software alive as the old demigods fall off the 'Net... signing off.

Berlin's contribution to the user interface world is that it offers several enhancements to the user interface that makes your UI look cool and spiffy. Accompanied by 3DWM, you're on your way to creating a very good starting environment for developing visually stunning as well as utilitarian user interface. As most people seem to be screaming for performance, we'll have to wait and see how well theGGI team does for making use of advances in hardware and software.

Just like most technologies, you probably will have to wait a while to see the emergence of new applications that take advantage of 3D visualization. Think back to all the fantastic images of user interfaces in movies: The Lawnmower Man (1992), Disclosure (1994), and Wierd Science (1985)... (There are probably alot of better examples here, but what can I say... it's daylight out.)

Most likely we'll have our usual pioneers into the immersive environment, 3d games, pr0n and chat rooms. It will be interesting to find the other applications that will be introduced once this becomes more standardized and refined: statistical analysis, RDBMS/OODBMS visualization, network administration, etc. Truly intersting.

-Caracal

What you've listed are the vices of XFree86, not X11 per se. In other words, you could find an X server implementation and/or X library implementation that would solve those problems you listed.

Also, hardware support is at way too high a level. Something like GGI/KGI is a much better system. With that sort of seperation, one set of people could debug the hardware support, while another set of people could debug the graphics server (X) support.

X11R6 has been X11R6 for a long time. So why can't they do it right? Why can't XFree simply figure it out, get to a completely solid foundation, and then start adding more features? I think it's because of the hardware -- it muddies the waters. It also hurts anyone who wants to make an alternative to X, or (imagine) write a completely new version of X.
--

I'm wondering how this would compare to the Berlin windowing system or GGI? With the goal of running embedded, I'd guess QT's new system is simpler, and less cross-platform. Basically a way to get QT apps ported to handhelds really quickly, rather than a general replacement for X. I'll freely admit, though, that I don't know much about GUI framework design. Anyone out there in the know and willing to comment?

I have to wonder, though, how many X apps will really work well on a handheld? It's a different environment, after all, with somewhat different inputs and uses. Just dumping X apps to a PDA would be like the approach MS used for WinCE, and it didn't really work.

Jon

Most of us are looking forward to antialiasing for fonts, somehow. Unfortunately, the server returns fonts as a 2-dimensional binary array (if I'm understanding things correctly). That's means pixels are either "on" or "off" (no greys).. So, it would seem that antialiasing would not be possible without a major rewrite of the API or something.

That's my question, though. Is a rewrite of the API likely? Or, do you think that a competing display technology to XFree taking hold would be more probable?

Alex Bischoff
---

If you follow his link the the earlier post about 'odd day' back on November 11 1999, sengan, the author of the post says "The next even day will be 2-2-2000 - the first one since 28-8-888."

This comment is completely true -- 28-8-888 is a true 'even day'. However, the last even day according to schmoko is 12-28-888, which is not actually an even day, since it contains a '1' as one of its digits.

I imagine this should clear up most the controversy caused by this big mistake by schmofo...

Well, how does TurboLinux differ from the situation above? Well...

• TurboLinux figured out from the *beginning* that it was to their advantage to release their module under GPL. Caldera's distribution went through several revisions before they decided to make the source code available.
• The size modification to the kernel is smaller! NKFS was 2940 lines of code, IP_CS is 2781 lines of code
• IP_CS is better broken up into approx 60 functions whereas NKFS is only broken into approx 50 functions.
• The header files for NKFS has only two lines of comment explaining the purpose of the data structures. The IP_CS header file has comments next to every variable and function defined.
• The NDS browser uses RSA code which is under patent and US export control which means that Caldera probably will never release the entire source code (if any) of the program which uses the NKFS module. TurboLinux has indicated that as newer versions of the cluster server daemon comes out that they will release the source code to the older versions.
• NKFS has never been a part of the offical kernel source distribution and Caldera has never indicated that they will try to submit it for being included. IP_CS is also presently not part of the offical kernel source distribution but TurboLinux appears to be interested in submitting it for being included in future major versions of the kernel.
• The November 1999 Linux Journal lists Caldera's website as having had approx 10,000 visits whereas TurboLinux was listed as having less than 2,000. It seems clear that Caldera has five times the influce in pushing a prioritary fork.

So why are we getting so upset over the fact that George Weiss of Gartner Group Inc. has "fork fears"?! Isn't this the same G. Weiss that in January had fears about the "chaotic nature of the [Linux] market." He goes on to state "... best practices would entail putting in place practices to discourage, if not ban, code hacking when using Linux." Does this guy really understand Linux? The fact is that being able to code hack linux is one of it's biggest advantages. Another advantage is the growing number of non-standard modules. For example: you get better performce with INN v2 if you have rawfs, your not going to get far on the network with a Madge token ring card unless you have loaded the non-standard Madge kernel module driver and if you want to really fork from standard kernel method just put a distribution together based around the results of the GGI Project or RTLinux. Non-standard kernel patches and modules have been around for a long time and IP_CS is no different. History has shown that the main Linux kernel can survive this "problem." So, hand a spoon to Mr Weiss' "fork fears" and enjoy what TurboLinux is providing under GPL.

There seems to be agreement in the fact that the bandwidth and connectivity is increasing and soon may be as ubiquitous as the dialtone. That's a good thing.

A great deal of work is being done on web browsers to support more and more functionality. JavaScript, for examples, is an attempt to get programming in the browsers. Servlets are fine, but still constrained by the HTML widget set. Applets are problematic as Java support in browsers is problematic. And plugins are just plain problems.

Some folks have mentioned VNC as an alternative approach. Others mentioned X. How about a slightly different view.

Java seems to perform very well (at least where I work) on server side applications. So long as there is no GUI, the systems run great. This makes sense, as Java gives the developers a consistent processor/OS to code to. For non GUI apps, this is possible because most all OS have the same basic functionality (i.e. memory management, file system access, networking, process control, etc). The real differentiator is the user interfaces. All work differently (except Telnet ;-) ).

So, why not create a viewer that is consistent and applications are written to it? I know X is sorta there, but there are some problems with client side requirements and no session saving.

What about building a browser that is nothing more than a canvas for paint commands and an event gatherer. Then, build graphics libraries for your favorite development tools (AWT.so, libx.so, Win32.DLL, etc) that use this viewer as the graphics context. Now we could run the applications anywhere.

How does this affect browsers? Well, instead of adding more and more functionality and rendering capability into the browser (XML+XSL, JavaScript, VBScript, etc), the web servers become the rendering engines. Put all the rendering at the server and just send the paint commands to the viewer.

This way users don't need to wait Until the browsers support what I need, or make different versions for different browsers. If new functionality is added to the server, then all users now see it.

I'm thinking something like the GGI project along with VNC (which there is a mapping to by the way), might get this type of project started.

I note that ATT labs which owns VNC is using it in conjunction with CORBA. They don't want to release that as they don't want to support it. But imagine the possibilities.

Sorry for the length of this post. Just thinking out loud.

... is a verifier for the interpreter to the compiler of the vm translator that emits code to the vectorising assembler optimised for the hardware scheduler :-).

If you look at any high level abstract language (say Python) it goes through a number of stages, each of them designed to feed into the lower layers. The debates about the various schools can be viewed as an on-going bun-fight between the various groups as to who gets the largest slice of the $$ pie and simplified workload. In some ways, the hardware guys have a conceptually easier task, they get to include more of the surrounding chipset. The software language or API developers are forced to explore unknown territory. Witness the fumbled gropings to move beyond OpenGL to higher level 3D scene representation.

The rather interesting factor is that the OpenSource scene allows flexibility for the software and hardware to be realigned periodically. The example I'm thinking about is the GGI project and the move towards the Graphics Processing Unit as a self-contained CPU instead of an add-on video board. The next step might even be dedicated I/O/media processors combining FibreChannel, TCP/IP, SCSI, XML/Perl/Java engines, codecs, etc ... As Linus pointed out, controlling the complexity of the kernel requires understanding very clearly the minimal protocol that is needed to communicate between the different functions.

The biggest problem nowadays is not actually technical (tough but doable) but legal. Witness the jockeying around System on a Chip where you have to combine multiple IPs along with the core. Hardware vendors have cross-licensing portfolios and reverse-engineer their competitors to copy the ideas anyway. Linux avoids the problem by making everything GNU and thus designers/engineers can concentrate on the job without fighting with the lawyers, as well as defining prior art (cf with universities rushing to publish the human genome before the commerical mobs fence it off). Given the fast pace of the industry, the market is a stronger judge than any legal protection (why bother protecting something trivial that will be obsolete in a few years?). Perhaps in a few decades, people might look back and consider the millstone the patent system has become.

The biggest open question IMHO now is how to get multiple internet sites to interoperate. For example, some people might wish to combine customised /. filtering with references to Encyclopeida Britanica or archived news sites. Much as EBay might squeal about sites "stealing" their auction databases (what they want to do in practice), it is a way of creating large aggregated information complexes.

CPU tricks and speed races will always make headlines but despite the appeal of multi-gigahertz chips, the information backlane will remain a mess until the telcos/cable/sat get their act together.

LL

Cheers,
Joshua.

It exits already, umm.. 3dwm was one thing I heard of, don't know its status. Another was Objective Reality, a commercial 3D UI for linnux. And ggi has some nifty stuff of things like putting different X sessions on sides of a cube. Really cool stuff. You can try these out if you wish.. Xfree support will be cool tho...

We've hosted several open source projects ( Linux, Linux Documentation Project, GGI and more -- even WAIS and Mosaic in ancient days).
We're open to supporting more projects. So if you have some that need www, ftp, mailing lists etc, drop us a note at webmaster@MetaLab.unc.edu

http://www.ggi-project.org/screenshots. html :)

I hear about Glide being ported to Linux/PPC -- this may need 'architecture hack' work I'd reckon.
I also hear about FreeBSD/i386 Glide binaries but nothing seem to come of either.....

Dear ID developers,

what about using mesa+GGI in a future game? This may be more portable than glide in the long run.. check out

http://www.ggi-project.org

and there is libgii for keyboard/mouse input........ http://www.pl.ggi-project.org/

take a look at the screenshot, different no? example screenshots