Slashdot Mirror
New X Proposal on Freedesktop.org
Bytal writes "Havoc Pennington (of Red Hat and GNOME fame) seems to have a very interesting entry in his blog on the development of a new extension to the venerable X server going on at freedesktop.org. More specifically it seems to provide for most things that people have clamoring for (alpha blending, flicker-free window compositing and switching, as well as even OpenGL integration) without altering the existing X protocol too much."
Crappie broken slashdot blah
its about time someone does some decent work on the actuyal framework of the xserver, because right now, most limitations are not due to the window manager, rather the server.
For a free exhibit hall pass use the promo code 'free'.
For 50% off a full access pass use the code 'sctek'
For your enjoyment in case this server is /.'ed:
2003-11-03: New X
The freedesktop.org X hacking is low-profile unstableware at the moment, but one particular proposal interests me the most. Here is how I understand it, I'll probably get it wrong:
The idea is to make the X server model-view. The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times. For each window, the default view copies the window's contents over the contents of the parent window. This results in the same user-visible display you have today - but you could implement alpha blended windows by alpha compositing rather than copying each window into its parent, since we now have the parent window's contents.
To this we add the ability for a "compositing manager" to replace the default view for a given window, using the aXe and XDamage extensions. The window manager might be the compositing manager for toplevel windows, for example.
If a window has a compositing manager, it will not be composited into its parent automatically; the window is invisible until the compositing manager does something. An external compositing manager could emulate the default built-in compositing manager by using XCopyArea() (or alpha-aware equivalent) to copy windows into their parents.
However, a more exciting compositing manager might apply embellishments/transformations to the window contents prior to drawing them, possibly drawing them using an API such as OpenGL. For example, you could add drop shadows. Or you could do effects similar to fast user switching or Expose. Or you could double-buffer the entire screen as a whole making workspace-switching, opaque resize, and other tasks flicker free. The compositing manager is rendering a scene in which the window contents are one element, so the possibilities are endless.
Note that the window contents stay entirely on the server side, the compositing manager uses regular X protocol requests to manipulate them.
Apps other than the single compositing manager can also use the damage extension; possible applications include VNC (desktop sharing), magnifiers, pagers with thumbnailing, and so forth. The compositing manager is a special kind of view in that it disables the default paint of the window to its parent, and is thus responsible for replacing that default paint. But there can be any number of extra views of a window.
There are a lot of little complexities and open questions here, but the idea is pretty interesting. I'm waiting for something I can try out to appear in jhbuild so I can make metacity super-leet.
Sig & Below
Yuck Fou
But did anyone notice that this sounds a lot like Avalon and DX10 in the M$ world?
I'm not flaming what Mr. Pennington is saying, but it does sound awfully similar. Although it will make the X experience a bit nicer, IMO.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
How much is "not too much"? Any modification may be enough to break an existing X application. So what will it break?
Thankfully most of my favourite X applications are open source and actively maintained, so if this takes off I suppose they will be fixed if necessary (or at least fixable). An exception to this would be the old Loki games, which are neither open source nor maintained. I suppose this demonstrates one reason why closed source is bad...
cool! decent opengl integration will make all those little flashy transitons and funny shaped windows that mac users have a snap to implement! x finally becomes less about boring rectangles, and becomes truly fun to hack ;)
Lets hope this gets support from enough different groups to make it a standard.
And then we can start hoping for something similar to the venerable pipe, but allowing easy use for graphical / media components! (ok i'll go back to dreaming)
Assuming xlib isn't statically linked, I don't think there'll be too much of a problem. I'd even venture a guess that simpler applications wouldn't be affected at all.
tasks(723) drafts(105) languages(484) examples(29106)
We returned a new 19" monitor the other day because it was native 1600x1200. The text was unreadable at that resolution and lower resolutions simply looked like crap. We replaced it with a 1280x1024 bit but that is still on the small side.
The last time that this was brought up on slashdot, most of the arrogant jerks tried to point out that you can "simply adjust the font size in the control panel". This doesn't work for anyone who has tried it.
Longhorn will take a big step forward in this area. They will be rendering the window system and applying it as a texture so that the DPI of the monitor is irrelevant. X will be light years behind if it doesn't do this first.
Life is the leading cause of death in America.
The main principle here seems simply to be for the X-server to store each window, wether it be visable or not. At the moment if you stack windows on top of each other the X-server forgets what is on the covered up bits, and when the window becomes visable again it is redrawn. This was a good idea back when memory was scarce, because storing X full screen applications could take X*screensize memory. However today with more memory, we can store all those windows without forcing a redraw.
This is long overdue in X, and also as stated makes things like alpha blending, and Mac OS-X style openGL window-dragging acceleration much more trivial, and also for those who like network transparency, won't require resending windows each time they become visable (although adds the new problem that unless you are careful you could end up spending lots of time sending updates to non-visable windows). It is of course nessasary to allow some chucking of hidden windows (because full screen 32-bit images still take up quite a lot of room), but overall its a good plan!
Combination - fun iPhone puzzling
Let's summarize the discussion that this is going to trigger:
Whine 1: X is slow and bloated we need a replacement.
Response 1: The XFree86 implementation may be slow and bloated and not the protocol.
Response 2: Come up with something better and we'll talk.
Whine 2: Who uses the remote display capability of X anyway?
Response 1: On local displays X uses shared memory and is fast enough.
Response 2: If 5% of the users need the feature it should be retained.
What a cool idea for topic image for X! It has that little x and everything!
This a text only webpage - I doubt it will go under.
Seriously perhaps it is time for X11R8. A revision that doesn't break compatability, i.e. not X12R1.
It's really important for me to be able to get to my PC from the lab (as I am doing now) and run all my apps (thank god for switched networks and gigabit ethernet - I'm using 1100k/sec at present, it used to only be possible to use 16 colour mode 800x600 VNC because of network congestion, now 24 bit desktops forwarded over SSH is fine). As such the biggest reason I wouldn't consider jumping to Apple is the fact that on Linux X 'just works' in a networked environment. I can browse local and remote filesystems with no pain at all, and it's very responsive.
If X is going to get the ability to do OS X's flash graphical tricks (the useful ones at least - functionality before form please) then this will make my desktop experience much more plesant, whilst still giving me a stable and predictable environment wherever I happen to be working. Even if the flash tricks are only available locally (at least until the college upgrades to terrabit ethernet...) it'll still be a pretty big bonus.
Beep beep.
"The server stores a tree of windows as it does now. However, unlike today, it keeps the full contents of each mapped window in memory at all times."
What are the memory implications of this ?
With many people using resolutions of 1280x1024 or 1600x1200 in 24-bit or 32-bit colour, dual-displays and multiple desktops becoming more common, this could chew up a lot of RAM.
A single, maximised window at 1600x1200/32-bit is going to use 7.5MB, even if it's just a terminal window. I can quite easily have 10 windows open at one time, especially when web browsing (OK, not all maximised, but not all small, either). There goes 75MB of RAM, just for the screen display (let alone the extra memory X uses for pixmaps, etc). If it's constantly being accessed in order to update the display, it won't be easily paged out to disk, either.
Things like tabbed browsers and terminal programs help quite a bit (assuming that the contents of each tab won't be stored in RAM - or will they ?). But not everyone likes using them.
Would someone with more knowledge about the current workings of X care to comment ?
Aqua is based on Display-PDF and is resolution independent. That was a really smart move by Apple because resolution is only going up. Even if there were small problems with resolution being to low on laptops (don't think so) this will go away in the future. All bitmap-oriented window systems will suffer from this design decision increasingly.
At the beginning was at.
....mention any other open source that can be used as an example of already existing functionality that is like this or can contribute to it, perhaps directly.
Not getting into the programming details but AROS is open source Amiga clone I believe having some of this...
Shrug
If you are going to break it a little, why not break it a lot. Broken is broken.
... someone proposes new X, I would be rich man.
This seems to be a band aid solution and complex as well. With OpenGL being so prevalent why not create an X replacement entirely upon it?
an ill wind that blows no good
Because it's harder to recover from a full break.
Fixed link to AROS
I also like what freedestop is doing with dbus, as it reminds me of the Amiga IPC usage that AREXX makes use of.
You don't understand the X protocol very well. It is actually quite likely that this change could be made without breaking any existing X application. The X protocol is very extensible and well designed in certain ways. This is one of them.
One of the first X protocol extensions was allowing you to have windows that were some shape other than square. It broke no existing X applications at all, and even if it had gone unimplemented until today, that would still be the case.
The X protocol has problems. It is badly designed for WAN links, especially with modern toolkits that draw complicated things for even 'simple' UI elements. Other WAN issues have to do with latency. X really needs a way for toolkits to export some of their drawing functions to the server so they can executed server side. This would fix many latency and protocol verbosity issues.
Need a Python, C++, Unix, Linux develop
Kill X and replace it with something simple, clean, extensible and lightweight. (All characteristics which X is not.) Then put a transparent X server on top of it for backwards compatibility. X is such a dinosaur, trying to extend it with all these modern features is like ricing up a Honda Civic.
...I suspect I will be completly grey by the time this gets to be remotely usable for the non-geek Linux crowd. I'll check back in a year to see how .69 beta is doing.
Design a decent file dialog and window manager for Gnome first. Gnome sucks because of them.
I seem to be seeing a new X logo as well from the slashdot page:
slashdot.jpg
It's so simple and plain. It just might work!
Fortunately the X protocol can be extended without being replaced. OpenGL (GLX actually), Xrender, XVideo and the XSHM (the shared memory extension) are all examples of extensions that have been added without breaking old apps. Parts of X may be crusty, but overall it is pretty well designed.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
You don't seem to understand the problem the way it was meant. I have a big monitor, I like to run at high resolution, but text is TINY, so I make the fonts bigger, but then everything is out-of-whack in terms of widget sizes and images.
What we're talking about is a VECTOR-based display, so 'increasing the size' won't make it any less readable. In a vector-based system EVERYTHING gets scaled up, you could run the big monitor at 1600x1200 or 512x384 and the elements on the screen would be the same actual size (meaured by a ruler) but the higher-res monitor would just look a hell of a lot better.
Now there ARE some issues that need to get worked out for this, a web browser, for example has to be prepared to have a bitmap GIF 'blown up', and it has to be done well enough to look decent but not take too much CPU power.
NEXT had this, Aqua has the underpinning of it, I think GNUStep is coming along with it, Longhorn is going to have it. I don't see the XFree86 folks picking this up, I think the toolkit folks and KDE/GNOME will have to implement it themselves because the XFree folks are really conservative.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I think it doesn't break anything, but instead adds new extension(s) for applications/toolkits to utilize. The X protocol is extremely extensible. It's almost as generic as TCP/IP.
What would be really nice is if we could have X11 with integrated audio. There are lots of ways of streaming audio, etc., but that is different.
What I want is that when I log into a remote X11 box using xdm the audio is sent to the local X11 server, just as the video now is. All the processing would be done remotely, and just the video/audio rendering for local hardware would be handled locally.
Best wishes,
Bob
...is all fine and good, but when do we get hot desktops, a la the SunRay environment?
I want to be able to move around my house and just login at any xdm screen without having to shut down the session where I just was, dammit!
Posted with Mozilla
My experience of running X on 1152x900 on a 17" monitor suggests that this is an appropriate resolution that doesn't cause too much issue; 1280x1024 should be more than fine.
I've driven 17" at 1280x1024, and depending on your applications everything works OK. X is a lot more customisable than MS Windows: you can actually change almost any screen font in use in most situations.
I run an IBM Thinkpad with a 15" screen at 1600x1200. In X Windows, I use the Xft2 font renderer, rather than the old core X font system, for almost every text string I see. Because I have also set the DPI for the screen to 133dpi, everything remains clear and readable and the fonts are all the correct size. So if the original parent poster was struggling with a 19" screen at this res, they should learn to configure their systems better.
The biggest problem I have with high DPI displays is viewing web sites, which will need browser technology to change in order to be useful.
Mozilla provides two useful functions at the moment, and there is another one almost there. Minimum text size is useful to stop the worst excesses of tiny fonts. Text zoom is an essential function on bad websites. Image zoom would be nice, especially if it simply runs in step with text zoom. Some tweaks would then be necessary to stop pages being limited to the 800 pixel width that some designers have decided is the perfect form factor.
SVG also offers improvements for high dpi screens. I look forward to the day that Moz/SVG takes over the web browsing domination and web designers really push vector graphics out there.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
How is this different from backing store?
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
...was to be able to cut and paste between applications. A unified API for a clipboard system that uses a unified set of keys to cut and paste.
Alpha blending should be miles and miles behind the development of a window system that actually works.
But, this looks to be more typical X development. No brake pedal, but you can shift gears via the steering wheel, the stereo, or a series of buttons on the sunroof; it has 539 airbags, each requiring a different pressure to go off, and there's a seatbelt interface for every previous seatbelt in existance. Plus it has the most efficient 46 horse power engine ever made, even though opening the glove compartment causes it to stall, or at least backfire.
~Wx
sig?
This proposal sounds very much like the render/tree-traversal stage of Y (page 25), except that in X your widgets still would be client-side, not server side.
It's 10 PM. Do you know if you're un-American?
Or maybe it's not a problem with closed source? Maybe this is why changing a defined protocol is bad?
I'm all for anything that makes X suck less! ;)
But, but...it doesn't give us flashy features like transparency, so we can brag at how cool our desktops are. Nevermind the fact that most can't seem to make a good desktop (from a HCI POV) with what one has presently. But I'm certain with those new, cool features, that will all change.
I've heard many adjectives used about X windows, but this is the first polite one!
need a free COBOL editor for Windows?
Tell that to Apple..
I have recently done some experiments with raytracing 2D scene graphs. It's very preliminary and would require a speedy processor compared to X, but it's supprisingly fast @700MHz. This approach eliminates the need to compute intersections, unions, etc.. of arbitrary areas on the screen - this is handled per ray during rendering. It also prevents any primitives having to know how to paint themselves. You only need to trace dirty pixels. Bitmaps only need to be stored for objects that contain bitmaps. You can also do anti-aliasing with a little more CPU and transparency should be simple. The code is NOT a GUI by a long shot, it only demonstrates that RT might be a practical approach to 2D scenes today. Oh, and it doesn't have font support :-(
I have a Samsung 19" CRT, and the text is perfectly readable to me at 1600 x 1200. Granted, I don't need vision correction, but if I did, that would hardly be the monitor's fault. Lower resolutions don't "look like crap" either.
If you're talking about an LCD rather than a CRT, I can see where lower resolutions might look worse, but I don't understand how that could be with a CRT. But if you're talking about an LCD that does 1600 x 1200 at 19", I'd sure like to hear about it, because I haven't been able to find any under 20".
That said, the upcoming Longhorn feature sounds nice, though I'm guessing the XFree86 folks might be able to come up with something comparable in the 2 years that they have. It will be good to stop having to explain to people why a higher resolution means that things get smaller; after all, printers don't work that way.
WMBC freeform/independent online radio.
I suppose this demonstrates one reason why closed source is bad...
Hmmm... closed source is bad because open source hasn't found a way to support it properly? That doesn't sound right. There will always be proprietary software, and OSS needs to get along with it. Breaking proprietary software all the time is not helping spread the adoption of Linux, because most people do need to rely on at least some proprietary software (even if that is just drivers).
Backing Store
Save Under
Will these finally be supported in XFree86?
well, it is either break the existing x apps or not have an OGL composited desktop like Quartz Extreme and Areo will be (areo will be DirectX) thus pushing Linux out of the Desktop market for a LOOOOOOOONG time.
I am the Alpha and the Omega-3
You can't argue down a person that is used to some other way of doing things.
In this case though, we can have our cake and eat it too, since we're in control of this software. Just give X11 a variety of selection and cutting and pasting options, including compatibility modes for those used to other systems, and everyone should be happy.
Why clear and paste into the URL bar.
Just paste the link into the browser window.
Works in galeon, probaly works in the others.
Just don't do this over an input box.
Really what else would you paste into a browser window.
Go ahead do it.
Many people are working on a few alternatives.
Some seem quite nice.
For me X is okay, it works with my apps, it looks nice.
I find it odd that X is so terrible and so unusable for many people, yet they haven't created a really usable alternative. I think mostly they are whiners who couldn't do any better.
(Obviously those who ARE working on making something better aren't included in that group)
Sure, fonts can be scaled just fine. But that's not the only user interface element that needs to be scaled.
....
Here at work, we have several of those IBM T22[01] displays. 24" diagonal with 3840x2400 resolution. I haven't done the math, but I think that's somewhere around 200 ppi. That's way too fine to do everyday work on.
So you scale up the font size. Great. What about images on web pages? What about the size of your scroll bars? What about toolbar buttons? What about
You see the dilemma.
Until there is a display technology like Quartz Extreme or what I hear rumor of in Longhorn (or a proposal like this, which could conceivably scale all X11 content), very high ppi displays are going to suffer serious usability problems.
I have looked into this and, yes, there are blatant inefficiencies in GTK. For instance: to draw the simple box with a mark in it for checkboxes, GTK 1.2 uses 6 PutImage operations. Does it cache the result at the server? No, it does it every time it needs to draw the box. It does not even compose the pixmap itself and then uses a single PutImage. The most efficient way of doing it is to compose the pixmap at the server, and the on each Expose event simply do a single CopyArea operation. (backing store would be even better). Looking into the GTK source code shows that this is not a simple thing to remedy. The drop-in shadows of the box is handled by one part of the code, the checkmark by another, and so on.
There are also examples of inefficient resource use. gcolorsel (v1.40) needs a pixmap for each color. 1165 pixmaps. This does not sound as a reasonable requirement to me.
A clean robust gui which off loads gui implemented and unimplemented gui tasks. Caching basic wigets menus and buttons so on in video ram for on speedy retrieval. Easy texture filtering (low quality textures made to look very good) duplication and manipulation which occurs on the fly with varied effects (or opportunity to provide seamless relevant information retrival such as graphing, mouse over, mipmapped zoom. etc... ). X desktops 'may' finally see a standardized wiget set for optimized performance and ease of development. Reverse compatibility with older apps my require a one time screen capture and then defaulted render and translation benign of user functions.
Stability is a concern, most cards prefer creating one draw buffer and doesn't release properly until a complete release of the of the api is called or forced. Even well made apps are much more likely to leak. Object orientation is subjective relying on more the just proper monitor drivers and screen resolution. User focus,
Desired, real 2d and 3d side by side occupying the space allocated to each "object" (in essence native 2d with the ability to speedily render possibly hundreds of individual gl windows within the display or allow transparency that allows user interaction through). Stacking (objects over top of each other) must default to a benign behaviour-but so as not to limit such useful intentional actions do by the user and allowed by the developer. Lighting or effects interaction between animated objects.
because most people do need to rely on at least some proprietary software
Part of open source is trying to change that. Also the connection between propietery and closed source is relatively new (last 25 years) based more on PCs not coming with system compilers when they came out (though funny enough better tools then they have today, like built in linkers).
Binary compatability is not a feature we should support. Let the closed source developers have to constantly keep up for a few years and we'll see how well their model works.
For an excellent example of how to do double-buffering in X, please read the source code (here) for the XSpectrum spectrum analyser (despite its age XSpectrum still runs faster than the newer gspectrum).
Scroogle
Well to be fair it didn't exactly work with window managers that didn't know anything about shaped windows. It didn't cause the WM to not work, but it pretty much caused the managed windows not to be shaped (except I think uwm which didn't reparent windows...). So it could be said to have broken a tiny handful of programs ("almost all X window managers").
It definitly broke as few things as such a change could have though. Just like future changes are unlikely to break anything that doesn't use them except in a lot of cases they will require help from window managers (lest you get partly transparent windows in a fully opaque window border for example)...and I expect there may be a few other places where the new and the old don't interact very well (for example if a second attempt is made at fixing cut and paste).
It is still hard to imagine a scheme where that sort of extention broke nothing though.
What you are referring to is a bug in Mozilla's Gecko Runtime Engine. It is not a feature! It is not documented behavior (other than in the bugzilla database) and it should be removed. You should not become accustomed to using it, because hopefully one day, it will be eliminated.
The preceding comments reflect the author's personal opinion and are public domain, unless explicitly stated otherwise.
XFree86 has done even better than not breaking the protocol. IIRC they have been *binary* compatible for Xlib for over 4 years.
That's easy to do when you don't release anything new in over 4 years too!
ba-da-bump!
Thank you ladies and gentlemen, I will be performing all day, every day at the slash-dot for the next week.
Sensible cut and paste is a bug, I want to view this URL, so I put the URL in the browser.
This make sense, I really hope that nobody starts removing features like this. I would appreciate a link indicating this desirable behaviour is a bug.
IE lets you drag and drop urls into the browser window.
I'm sick of add-ons and modifications to this ancient protocol. Can we please create a modern GUI protocol to allow us a modern desktop environment? Why are so many Linux users afraid of change?
XFree86 is HUGE and complicated. Too many libraries and conflicting interfaces and generally poor performance litter its userspace. When this is brought up, every X defender blames the windowing libraries and desktop environments. Look, it's 2003, can we please move beyond the 1998 era of Linux desktops and have something new and modern?
"Sufferin' succotash."
Why not give Y a shot?
http://www.doc.ic.ac.uk/~mbt99/Y/
"A significant percentage of the Linux community are not Unix technical types."(1)
They're former Windows users.
(1) Yeah! Yeah! Were do YOU think they come from?
What you are referring to is a bug in Mozilla's Gecko Runtime Engine
No, it's been in the Mozilla featureset since Netscape 4.x (probably earlier.)
You should not become accustomed to using it, because hopefully one day, it will be eliminated
It predates Gecko by several years, and is behaviour that was intentionally ported from the Unix version of Netscape into Gecko. It was ported specifically because people were accustomed to using it.
Everytime an X post comes up, it gets hard to tell where the technology fits in the X-window scheme. Is there a standard layer diagram like the OSI network one which could help place some of this tech?
Something needs to be done!
In other words, it misses the forest for the trees?
Have you looked at pnmtools?
They do what you want for certain limited image types: no alpha, rectangular images. (and some companion tools are able to extend things to add an alpha channel) The only problem is that last time I looked a few of them don't read/write to stdout.
Also, as the most common image processing I find I have to do is rotate pictures from my digital camera through 90 degrees, I find that the command line tools that come with libjpeg (often packaged as "jpegtools") are quite useful.
If Pennington wants to make extensions to X then let him go through the existing X community and standards process.
Why? Forks can be healthy.
Gnome and/or Linux are only a relatively small percentage of X users.
Where are most of the new features in X coming from? Who's driving the mass Unix desktop? I'd have to say that apart from OSX, it's XFree. Nothing wrong with meeting and exceeding what's available on other desktops.
Remember, Gtk was started by a guy who "wanted to learn how to write a GUI". Yes, that's right, and boy does it show.
Yay! Ad-Hominem attacks! What a persuasive, logical and coherent argument!
While I don't use the GNOME environment, I'm glad that folks are building the GLIB/GTK. Given that it's basically GTK and QT that are the relevant X toolkits today (Motif? BWAHAHAHA) and that vendor acceptance outside of OSS OSes (Solaris + gtk ring a bell?) the GTK guy's learning project has been pretty educational, no?
Kent
Oh, really? Well, what about that time I found you naked with that bowl of Jell-O?
has got to be the graphics and audio pipelines
/dev/dsp or esd?
they are so complex and overly complicated, not to meantion incompatible and slow in most cases,
which lib to compile against?
is it framebuffer or reg xlibs?
is it alsa ,
bah!
in windows, as a user i never have to worry about this crap, and i shouldnt have to under linux either
if windows can manage this linux should be able to!
its time to consolidate
especially if linux ever wants to get into the desktop market
back in the day we didnt have no old school
> Motif? BWAHAHAHA
A sure sign you a dealing with a Linux
fan-boy who has no clue how to use Motif
and doesn't understand the X way.
> and that vendor acceptance outside of OSS OSes
> (Solaris + gtk ring a bell?) the GTK guy's
> learning project has been pretty educational,
> no?
Umm, no is right. They are hedging their bets.
Their are lots of cases in the computing world
where crap has beat out a superior solution
and or product. Look at the phenomenon of Linux,
or GNOME, a clear case of style over substance.
Sun had to invest 1000s hour man-hours just to
make GNOME half-way useable.
> Oh, really? Well, what about that time I found
> you naked with that bowl of Jell-O.
Ummm, what about that time I found with that
penguin...
In Amiga every window had its own RastPort and its own underlying bitmap. Back in the day it was thought that graphics hardware would eventually be extended to do all the windows as sort of super sprites, but that never happened.
This is my sig.
You have to adjust the DPI setting.
I had no problems on my 15" 1600x1200 laptop, using windows in 120DPI mode. It looked GREAT, easy to read, etc.
The odd web page or crappy app would have some problems, due to improper use of widgets.. but for the vast majority of things, it worked just fine.
And am I the only one who remembers microsoft ALWAYS is going to solve everything in the next version?
I don't want to have to "learn to configure" a system to actually be readable. Heaven forbid I expect it to be well-designed and readable from the start.
Good thing that X can read the dimensions of a monitor and provide the needed system resolution then. That someone might wish to override the system setting because they might, say, have poor eyesight and wish everything to be bigger and higher contrast and finds that the two minutes reading the appropriate manual helps them not only set things up as they want it but also opens the door to other accessibility advantages.
Autoconfiguration is good. Manual overrides for autoconfiguration is better. Just like a good SLR camera. There will be times when you just want to press the shutter release and get a decent picture. There will be times when reading the manual and advancing your own skills so that you can take that soft focus, small depth-of-field portrait will be advantageous too.
Having many many options for configuration is a strength, not a weakness. Having good defaults is important.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
"The X old guard are seriously skirting making X completely irrelevant if they do not become more open and start adopting things that real users want."
....wait! You are not a real user. You do not drive corporate adoption. You do not manage 10,000 seat deployments. You do not fund the development of these projects, not even potentially.
Ah, real users like you, no doubt!
Ooooo, the "old guard". And you must be the "enlightened new wave"! Hail to you sir! Your are truly great! Spare us not the conviction of our great ignorance! Teach us oh enlightened one!
I suppose real users want l33t transparent windows!
I suppose real users want an additional 5fps in Quake2 and Halflife!
I suppose real users want their display optimized for viewing aNim3_d00d pornography and 3l33t XMMS skins!
Oh,
Some day you will no doubt grow up, have the ability to contribute meaningfully to these projects, have the ability to understand what they are about beyond your own immediate gratification, and like me, be telling people like you, just this.
Since when "Red Hat" is "fame"? Looks dumb to me.
The fact that Mr. Walther is a flaming idiot will severely hamper it.
Linux was started by a guy who "wanted to learn how to write a OS".
Now look where it is. It has beaten the *NIXes that the people who "really" know OSes made.
#include "sig.h"
All the Aqua widgets are bitmaps and they aren't scaled at all. Mac OS X has even poorer resolution independence than Windows and X11, because you can't even change the system font size (AFAIK).
Okay, if it bothers thens enough, they can.
1. Choose something else, be it console, MS Windows or GEOS.
2. Pay someone to fix it.
"Let the closed source developers have to constantly keep up for a few years and we'll see how well their model works."
I'd keep a close eye on how well _your_ model works as well under the same conditions.
Uhm. GNOME community is NOT GTK+/GIMP community. Not even close. And the person who started GTK+ didn't do it to "learn how to write a GUI." GTK+ was written mostly because there was nothing good AND free when Spencer Kimball and Peter Mattis wrote the first versions of GIMP. They became so fed up with Motif that they created what would later become known as GTK+.
Dijkstra Considered Dead
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. "Mechanism, not policy" was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend's Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend's Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend's X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week -- and that's before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer's point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.
-Don Hopkins
Take a look and feel free: http://www.PieMenu.com
-Don
From the X-Windows Disaster:
How to make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC
X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
-Don Hopkins
Take a look and feel free: http://www.PieMenu.com
Actually closed source is bad because once a closed-source company or developer disappears, there's NO WAY for the community at large to continue supporting that product. How do we continue to support it without the code? We're not even ALLOWED to hack it open to keep it alive, we were given no rights to do so.
The choice of the community is either to progress, sometimes breaking archaic stuff in favor of new and improved methods, or allow the project to be held captive to ancient software that nobody is using anyway. That leads to "kruft", one of Microsoft's great sins. If the games were open, interested volunteers could patch them and keep them alive forever complete with up-to-date performance advances in the OS, as long as there was sufficient interest.
On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.
The most that can be said about the lowest-common-denominator approach that X takes to graphics is that it levels the playing field, allowing incredibly stupid companies to jump on the bandwagon and sell obsolete junk that's just as unusable as high-end brand-name workstations.
-Don
Take a look and feel free: http://www.PieMenu.com
If you can do that, I'll give you a shiny medal.
Myth: X is Device Independent
X is extremely device dependent because all X graphics are specified in piel coordinates. graphics drawn on different resulution screens come out at different sizes, so you have to scale all the coordinates yourself if you want to draw at a certain size. Not all screens have square pixels: unless you don't mind rectangular squares and oval circles, you also have to adjust all coordinates according to the pixel aspect ratio.
A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra bonus pixels when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion). This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses enen though you scaled the rectangle corner coordinates to compensate for the aspect ratio.
The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python's Cheese Shop sketch, or a grail seeker in Monty Python and the Holy Grail. Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay(unix:0);
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1, BlackPixel(display, DefaultScreen(display)), WhitePixel(display, DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
WHAT IS YOUR DISPLAY? /* Black. */
/* Whoops! No, I mean: */
/* AAAYYYYEEEEE!! */
display = XOpenDisplay(unix:0);
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0;
favorite_color = BlackPixel(display, DefaultScreen(display));
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
/* Is that a SubStructureRedirectMask or a ResizeRedirectMask? */
display = XOpenDisplay(unix:0);
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display), 8, PseudoColor, &vinfo) != 0) visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
WHAT??! HOW AM I SUPPOSED TO KNOW THAT?
AAAAUUUGGGHHH!!!!
(server dumps core & falls into the chasm)
-Don Hopkins
Take a look and feel free: http://www.PieMenu.com
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They've become unwitting pawns in the hardware manufacturers' conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slies the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client an download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun's TNT Toolkit and Arthur van Hoff's HyperLook gui environment). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that
Take a look and feel free: http://www.PieMenu.com
Works fine. See about 2000 Unix projects for examples.
Hey didnt you now that wine can remote display diablo for you ?
=) And people say X sucs!
CIA Factbook 2002 (US):"Since 1975, practically all the gains in household income have gone to the top 20% of households
From: francis@ircam.fr (Joseph Francis)
I would like to propose that all GUI designers eschew anything actually resembling visible display of an interface, and simply ship a library, and a loose 'conceptual' discussion of what effects the display should provoke, according to a psychological or astrological model of the user's personality (Jungian, Freudian, or Dosteyevskian), their latitutude and longitude, and blood sugar levels. It should be completely up to the user to specify a display (I believe POSEUR is addressing the shipment of design-free GUI design for user-transparent configuration: open, scalable, and extensible, the problem is almost PN complete). Sample KIT (using a paradigm of an application which extracts semantic nets from French Literature in Translation):
1. Parameters: none /Utopia/, and a well-fingered /Neuromancer/
2. Two thick libraries, with enforced single-entry SlowRead(). and a single NoExit() for enforced modularity.
3. Copy of More's
4. One copy of Italian Vogue Summer collection '82
5. Default Interface Processor (DIP) to generate a user-configurable default interface upon which one can generate proposed target 'research' examples.
6. One copy of USA Today and Time (tm) magazine to be used for sample non-default graphical layout guidelines.
+ XYmorph (tm): a new easy-to-use open extensible and scalable system for randomly per/mutating user interfaces. A manifestation of the concept of both stimulated healling and scatter-brain i/o in order to most quickly reach suboptimal interface design with the least amount of effort on the part of the designer or the user.
+ Quagmire: a CD-rom collection of over 4 quadrillion possible interfaces generated for a Unix(tm) open, extensible, and scalable graphical C-shell-feel-good-alike system. Meets ANSI, K&R, A&P, S&H
+ and other stamped standards in continental US.
+ boraX: a user-configurable interface cleanser. Open, extensible, and scalable, it removes all traces of design constraint from simple structured systems and creates flat-design mazelike idio(syncratic/pathic/syncretic) systems of fresh and clean code.
Sample concept discussion:
The pointer (I hesitate to use such a loaded word: for users who object to object orientation and simplistic Western-philosophy views of dichotomatic (not diatomaceous or deciduous, though wooden feelings might be appropriate for Environmentally friendly X displays) subject/object distinctions might prefer to discuss 'object compliment', or even 'compliment' (as in Complimentary beverage or Complimentary sugar-coated dry-roasted 100% genuine Virgina grown goober peas just the way they grew them in olden times) in order to provoke an awareness and create a more extensible scalable and transparent user environment for those who aren't really worried about domain/range distinctions in disjunctive noun mappings) should respond to a click (which is to say a simple tap, of varying duration depending upon the physical capabilities and inclinations of those who might be inclined to acutally depress the open, extensible, and scalable button on a mouse (though those of us who object to laboratory research mechanomorphization of living entities prefer to call 'mice' 'clickers', thus preserving the dignity of what we all must recognize is part of a larger Gaiaen web of life (which is, I must remark, open, scalable, and extensible, life that is, not the mouse) and metonymically convolving form and function into the open, scalable and extensible nomenclature of X).
XBorges.
One longs for the day when the responsibility of programming computers falls squarely on the shoulders of the users, where it belongs; they are provided with a set of infinitely configurable instruction codes, on an open, extensible, and scalable n-bit bus, and their task before setting upo
Take a look and feel free: http://www.PieMenu.com
What I want to see is the disappearance of even the idea of distinct desktops on multiple machines. The very concept of a "desktop" as a point of control for a computer is dated. Time to move on to a new idea. Something like transparent aggregation. Think about having multiple machines interconnected in various ways that appears to the end user as one machine and the only differentiation is at the user account level.
Citrix is the closest thing I have seen so far (when used with nFuse).
Between OpenFiler, Compiere, the DSM for OpenMosix, all I need now is migratable sockets and you should be able to to something close to this.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
In fact, even more - the X protocol is compatible right back to the original X11 release, which is way back in the mists of time (1986, IIRC).
himi
My very own DeCSS mirror.
Don Hopkins is the Bob Metcalfe of the "X" world.
X applications which have been correctly programmed and which use the shared memory extension do run fast on local displays. The speed depends a lot on which X server software you use. If you use the free XFree86 implementation, just remember the graphics drivers for most chipsets are not optimised because they have been written by the XFree86 project without the benefit, in most cases, of having programming information for the graphics cards from the manufacturers.
Scroogle
Those other systems have a single "compositing engine". On OS/X this appears to be an OpenGL object that is texture-mapped and the results Z + alpha composited to get the screen display.
What he is proposing is to allow the compositing engine itself to be specified by different programs, in particular by the window manager. Now the primary reason I can see for this is that older X apps create literally hundreds of windows, and it is necessary to have a fast default, which is not going to be the desired engine for a Quartz-like window manager. Therefore there has to be at least two compositing engines, and once you have two you might as well allow an unlimited number of them.
Now obviously X has no compositing engine right now (or really one, but it destructively composites into the parent window's source), and the difference between 0 and 1 compositing engine is much more than the difference between 1 and many. However this is still a very clever idea and is NOT something that exists already!
X does have backing store. I have programed quite a bit in this.
Even the first X servers had Pixmap objects. You can draw into these and copy them to the screen. Because the reside on the server, a correct implementation can do it vastly faster than a local copy maintained by the program. In fact it is obvious that X pixmaps are vastly faster than Windows Bitmap objects, which I am forced to use on Windows to get backing-store on windows right now.
Even the first people to use X realized that Pixmaps could be used for backing store, and this led to the problem that programs immediatly allocated quite a few pixmaps for this and on early X servers exausted the memory. I think this caused a lot of people to say "don't do that!" and probably is why people now seem to think X does not have this. However on modern X servers I have seen no problem making every window in my program have a Pixmap backing store. The resulting pixmaps are equal to 10 to 20 screens in size.
There is also the Xdbe double-buffer extension. This works like OpenGL double-buffering. In this case there is only an offscreen pixel for each visible pixel on the screen, so the memory usage is fixed to the screen size, and also time is not wasted updating invisible windows (a possibly serious problem with the OS/X and Longhorn and these new X ideas that I don't think people are worried enough about!) On older hardware such double-buffering was the only way to get hardware acceleration. Xdbe does suffer from a typical horrid cryptic X API and seems to produce black blinking on my Nvidea driver when resizing windows. Double buffering also has the problem that the "compositing" now popular cannot be done, as only one window can contribute to each final pixel.
Backing store of various forms has been around for a LONG time, incidentally. However except for the "game sprites" popular on hardware on the 70's, the "composite on the fly" implementation that everybody is thinking about now did not exist. It is unfortunatle that everybody now seems to think the only purpose of backing store is to make transparent windows. Backing store has many other much more important purposes than that.
Can the clipboarding and pasting be reconfigured?
The one thing I can't stand about using Linux is how selecting something automatically copies it. I was expecting a windows-like behavior of select, copy, click, paste. Instead, I get select, click, paste, OH CRAP GOT THE WRONG THING.
(-1 Offtopic)
(-1 YOU MORON)
You can do that with VNC. I even saw a few lines to add to your kdm/gdm config so that when you log in you bring up a VNC window instead of a normal desktop. Might take a bit more to set up a whole "cluster" of these systems so you always get the same hot desktop, but it looks like it would be just a matter of hacking existing tools.
If you really want this functionality, do it! (then please make a deb package for it so those of us who are too lazy can get it too
You don't know enough about X to address any of the facts in my posting, so you attack my sources (which happens to be myself). Are you saying that it's "sad" for anyone to write about their own experiences on slashdot? Or that it's only fair to quote other people? Or are you saying I should't quote myself because I'm not qualified to hold an opinion about X-Windows?
Please justify your own opinion, Blackbolt: How much experience do you have developing software for X-Windows? Can you counter my points by sharing some of your own first-hand experiences, to hold up of your end of the argument instead of attacking my sources? Or would that be too "sad"?
I attended the first X Window System Users and Developers Conference in January of 1987, and hacked X10 window managers before that. I though X10 was cool, simple and elegant (though it had serious flaws), but it all went downhill with X11.
X-Windows simply sucks, and the fact that it hasn't stopped sucking after all these years does not bode well for its future. It's the monkey on the back of Linux, that prevents it from appealing to a wide market and succeeding on the desktop.
-Don
Take a look and feel free: http://www.PieMenu.com
Well to be fair it didn't exactly work with window managers that didn't know anything about shaped windows. It didn't cause the WM to not work, but it pretty much caused the managed windows not to be shaped
:).
Note that the wm would still work perfectly when not using the feature - so backward compatibility was provided.
Note also that you are talking about the specific *implementation* deficits in several window managers. Those may point to unclear protocol specifications or to bad code. Frankly, I suspect the latter. Code can be very broken if it makes assumptions about its input parameters without checking them first.
It is still hard to imagine a scheme where that sort of extention broke nothing though.
Agreed, but the worst outcome is that you can't use the new feature until your favourite applications work out-of-the-box with the feature enabled. The biggest problem will be finding the #define to (un)comment or set
This specific problem was that most window managers (all except UWM as far as I know) want to display decorations on the managed windows (resize, iconify, title bars, and so on). To do so they reparent the managed (application) windows so that they are contained inside windows the window manager owns (and therefore windows the WM can draw in without bothering the applications they manage).
When a window manager written prior to shaped window extentions (or that just doesn't care) reparents a shaped window you get a non-rectangular child window inside a rectangular window that the window manager owns. That rectangular window will pretty much make the child's shaped window look rectangular.
There isn't much you can do about that if you want to allow pre-extention applications (like window managers) to work with post-extention applications (the managed apps). There isn't any "checking of paramaters" the window managers could have done in 1990 that would prepair them for the 1991 addition of shaped windows. Nor is there much of anything that an X window manager can do in 2003 to make it work and play well with stuff using extentions that might be released in 2004 or 2037.
Well if you really like a window manager that is no longer being maintianed then there may never be a #define! Of corse historically the extentions don't not work, they are just visually a little iffy (windows that should be round aren't), and in the future that is likely to still be the case (transparent windows with very solid title bars).
OpenGL isn't a 2D rendering system. And, just to point it out, the compositing manager is completely free to use OpenGL to do said compositing.
You are confusing the high level management and protocol with the low-level rendering driver/architecture. Quartz Extreme may use OpenGL for rendering, but the apps don't use OpenGL calls to do it - they use Aqua/Quartz calls, which uses OpenGL in its lower layers for final rendering/composition.
Erm, except for the fact that Unics was written by Dennis who wanted to learn how to do some cool graphics routine for the PDP-7 340 vector display... And Ken wanted to make that little file system he'd been thinking about - - Unics was written for fun, failed when it was taken over by bizdroids and excelled when hackers once again took it on. Go Linus! (BTW - PDP-7 vector graphics are sexy. I have a PDP-7 I'm restoring so I should know)
toresbe