...you've just found more (still largely unarticulated) support for\r\nyour side.

The original discussion was [link|http://z.iwethey.org/forums/render/content/show?contentid=76952|here]\r\nBTW. I was somewhat disappointed that you didn't respond at the time.

While the XFree86 folks seem to think that network transparency is\r\nirrelevant to "the majority" of desktop GNU/Linux users (that would be\r\naccomplished by 50%+1 users), I'd say that this isn's something I'd toss\r\nlightly. Network transparency is very useful, and lends itself\r\nto numerous neat hacks.

Among them:

\r\n
• Dickless workstations. Suck your apps over a remote link, display\r\nlocally.
\r\n\r\n
• Local users sharing displays.
\r\n\r\n
• Multiple users sharing displays.
\r\n\r\n
• XNest. Running X-in-X sounds pointless...until you need to run at a\r\ndifferent color depth, want to try another WM, or otherwise need to put\r\na graphic environment in its own sandbox.
\r\n\r\n
• Display of remote apps on a local display.
\r\n\r\n
• Above. Tunneled through SSH.
\r\n\r\n
• Moving applications between displays (xmove).
\r\n\r\n

The main complaints I've seen articulated regarding X appear to\r\nbe:

\r\n
1. The development process has some lumps. This isn't an indictment of\r\nX, but of the XFree86 team. I won't say that this is fully independent\r\nof other aspects of development (e.g.: architecture, licensing, code\r\nquality), but it's a loose corrolary.
\r\n\r\n
2. New hardware is supported slowly. I don't know enough of what's\r\ngoing on here to comment meaningfully. The problem appears to be,\r\nhowever, a mix of vendor fuckwittedness, XF86's own internal methods and\r\nconflicts, and fnord knows what. When support does emerge, it generally\r\nappears to be pretty good -- high resolutions, many colors, good refresh\r\nrates. Not sure if there are driver goodies that GNU/Linux doesn't see,\r\nbut all I want is my 1200x1600 @32bpp, 85Hz.
\r\n\r\n
3. Performance bogs. I don't run high-end enough video to note this.\r\nPeter's the gamer, and doesn't complain about this (and Peter is of\r\ncourse loath to complain about anything that doesn't suit him\r\nperfectly...).
\r\n\r\n
4. Configuration. In particularly, on-the-fly reconfiguration of X\r\nresolution and refresh. Somewhat obviated by the ability to use XNest\r\nand multiple displays. I don't use the latest'n'greatest GNOME/KDE\r\nstuff, just Debian's dpkg-reconfigure xserver-xfree86, which\r\nwalks through some pretty clear menu-driven options. I'll grant though\r\nthat this remains a disadvantage, largely minimal though. Knoppix\r\naddresses this by managing everything automagically -- even lets you\r\nspecify your resolution and/or refresh at boot, and configures to spec.\r\nWell, sometimes. I've found resolution specs tend to be followed, but\r\nmy refresh preference (85Hz) usually isn't.
\r\n\r\n
5. Display postscript / AA fonts. Again, this appears to be something\r\nthat's being addressed, possibly in piecemeal fashion. But there are\r\nnow desktops with integrated DPS and AA font support.
\r\n\r\n
6. Programming interface. I hear a lot of grousing over this, but\r\nthere are tons and tons of apps written for X. I can't speak to this\r\nas I'm not a programmer, but the problem hardly seems insurmountable.
\r\n\r\n

Anything else I'm missing?

Any replacement for X would have to address several issues:

\r\n
• Backward compatibility. X apps would have to be runable.\r\nPreferably transparently, not in a separate box ("unmanaged mode", in\r\nthe typical lingo of X server vendors). There's a huge library\r\nof existing X apps, and none for any of the potential replacement\r\nsystem.
\r\n\r\n
• Network transparency. The new system will have to be network\r\ntransparent. Otherwise, you're writing apps for either X\r\nor the new system. And network transparancy is sufficiently\r\nuseful (see above) that it's going to persist, or the replacement won't\r\nbe adopted. More significantly: network transparency is most valued by\r\nskilled, technical, and power users. These are the same folks who do\r\nthe bulk of development. This will impact uptake and architecture in no\r\nsmall way.
\r\n\r\n
• Seperation of mechanism and policy. X is a useful model for\r\ndeveloping displays for many types of platforms -- the GNU/Linux-based\r\nhandhelds, for example, run X. If GNOME is overkill for a 260x140mm\r\ndisplay, rather than rewriting all your apps, you just slap a different\r\nWM on top of it. And despite the prevalence of GNOME and KDE, there are\r\nmany people who prefer different window managers (I'm highly partial to\r\n[link|http://www.windowmaker.org/|WindowMaker], Tilly likes\r\nFVWM2, Peter was fond of XFCE, but he changes desktops faster than I\r\nswap grilfs). Of course, seperation of mechanism/policy is one of the\r\nfrequently iterated criticisms of X. Grossly misplaced. Uniformity\r\nbuys, well, uniformity. At a huge loss of flexibility. Approximately\r\n100%
\r\n\r\n
• It most be overwhelmingly superior. Free software\r\nvastly favors incremental enhancement,\r\nparticularly over core, and deeply-integrated components, over\r\nrevolutionary development. Even where options can be fairly\r\npainlessly swapped out, say filesystems, migration is slow. Look at the\r\nuptake of journaling filesystems. This changes virtually nothing in the\r\nday-to-day use of a GNU/Linux system, but I'd still warrant use of\r\next2fs is the majority. Switching to ext3fs is transparent (well, with\r\nkernel support). Reiserfs offers more benefits for a one-time\r\ncopy-off-and-restore penalty. My bet is this: $100 says X11 is still\r\nthe basis of the predominant GNU/Linux desktops in ten years. Too much\r\ninertia, too few benefits, too much uncertainty.
\r\n\r\n

And I really am interested in responses, commentary,\r\ncriticisms, or corrections. I keep seeing this matter raised. I see\r\nlittle clear articulation or benefit from alternatives though.

\r\n"Choice" is what open source is supposed to be about, and if a good measure of\r\ncompatibility can be maintained between two environments designed for users\r\nwith different needs, I think that would be excellent.\r\n

Absolutely. I don't think you're interpreting my comments as opposing\r\nchoice or dictating X. I'm not doing either. Rather, I'm indicating\r\nthat any alternative will be dead in the water until it addresses (or\r\novercomes by other means, e.g.: massive cash infusions from elsewhere)\r\nthese structural / systemic issues.

\r\n. . that Fresco thing is addressing all your requirements, except I don't know\r\nabout "vastly superior" - that kind of depends on how you want to look at it.\r\n

I've checked in on Berlin periodically over the years. It never\r\nseemed to be going much of anywhere. Likewise this is the first I've\r\nheard of Fresco. I'll scope it out...

\r\nIn any case, I see no reason why people who need the capabilities of X can't\r\ncontinue using X, but for "normal desktop users", much of the X stuff isn't\r\nuseful, but raw performance, smoothness and ease of programming are very\r\nuseful for a number of application types.\r\n

If apps need to be specifically targetted at one system or the other,\r\nand if Fresco doesn't provide network transparency in a model at least\r\nsuperficially similar to X (e.g.: client -display host:0),\r\nthis isn't sufficient, as there's now the very significant\r\nthreshold barrier of either writing network-transparent apps, or apps\r\nfor the system which aren't backwards-compatible to X. I see this as a\r\nkiller.

\r\nOnce again, I'm not the programmer here, I'm the marketing guy, and I see X\r\nshowing up in perhaps the majority of complaints and problems with Linux.\r\nProblems that affect marketability are good things to fix, and right now, with\r\nthe XFree86 group coming rather unhinged, might be a good time to look at the\r\nX situation.\r\n

I'd still prefer to see specificity greater than "I see X showing up\r\nin the majority of complaints". As a bug report, [link|http://www.catb.org/~esr/faqs/smart-questions.html|it fails minimum acceptance criteria].

I'll address the Fresco FAQ in another post.

I don't recall the name of the WM, but it's aimed at handhelds.\r\nDon't recall which...

Basically: you don't have windows. You have full-screen apps. You\r\ncan kill or cycle windows. That's pretty much it.

No window decorations (except IIRC a status bar/kill button at the\r\ntop, narrow -- 4-6 pixels?).

Cool stuff? You can run it in XNest on your desktop/laptop (or\r\nserver) system, to get an idea of what it's like. Featured on Slashdot\r\nsome time back.

Yes, the app still needs to be designed with the thought in mind that\r\nit might only have a minimal display area. But given that, taking way\r\nWM complexity is a huge win for real estate and usability.