Slashdot Mirror
X.org and XFree86 Reform
albepetr writes "NewsForge is reporting about a press conference held today at LinuxWorld 2004 in New York, where some members of the X Consortium, XFree86, and freedesktop.org announced that X.org and XFree86 have merged. They claim that the reformed group will be working together to bring "not just more eye candy but new functionality" to the X Window Manager for Linux and Unix." Newsforge and Slashdot are both part of OSDN. Update: 01/23 18:06 GMT by M : XFree86.org denies the story. I think a more accurate description of the event might be something like, "XFree86 core developers leave XFree86, join X.org, remaining people of XFree86 are peeved".
Will we see a unified Windows environment for Linux now?
give credit to -- individual contributors rather than continue to view X development primarily as a corporate activity.
I like this alot. Functionality to the desktop is something that Unix and Linux both need to see loads of improvement on to help spread it to a larger market. I also like to see the OpenSource community coming together and joining into larger projects that can do more, rather than see hundreds of smaller projects all going in the same direction seperately. Bringing lots of brain power together gets stuff done.
Hopefully, they will work out a SINGLE standard for getting copy/cut and paste working correctly.
I can't tell you how infuriating it is when you go to copy a page of text from, say, openoffice.org, and paste it into a webform in Mozilla - only to find that perhaps the first half a paragraph out of 6 made it over.
Ron Gage - Westland, MI
It's nice. Now we need the big desktop systems to agree on common ground, make a "base" system that they can develop each their own systems on ;)
Any technology distinguishable from magic, is insufficiently advanced.
Theres no sense in having talented people work on different projects trying to complete the same task. This is great news for the X interface.
What the fuck is the "X Window Manager"?
I'm seriously confused now.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I hope this means we're gotting one GOOD X server, instead of one that has the drivers but not the features, and one that has the features but not the drivers.
I still believe the Right Thing is to have an efficient system for local display, and a widget-based protocol (a la PicoGUI) for remote display, though.
Please correct me if I got my facts wrong.
It's called "X Window System" and not "X Window Manager".
It is so mostly because it is not a window manager.
Real life is overrated.
Ok, how many slashdot stories do we need where half the people support X and half the people want something new, or a re-write. This is what it comes down to. X has a lot of great features. X forwarding over ssh being the premier reason I use X. It's probably a feature I couldn't live without. But if linux wants to transition to being a desktop OS for everybody X wont cut it. It's just too big, slow, and full of features desktop users don't need. Directfb is more like what desktop users need, but not quite. That's all there is to it. Linux is about choice, and right now X is the only truly reliable choice for any sort of gui stuffs. We need a real alternative to X for those who don't need the features.
However, as a user of X, I think it's great these sites are joining forces. OSS is about collaboration, and the more they work together the better the end result will be. And if everyone works together they will follow the same standards like the ones from freedesktop.org programs will be much nicer. gaim easily going into the system tray which I put in my xfce4 taskbar is an example of freedesktop.org standards at work. If everyone followed them, imagine what we could do.
The GeekNights podcast is going strong. Listen!
From the article
"...the reformed group is working together to bring "not just more eye candy but new functionality" to the X Window Manager for Linux and Unix."
Umm, they mean X Server don't they, or is there suppossed to be some sort of official window manager now? That would be very bad news in my opinion - Linux benefits greatly from the diversity of GUIs that exist for it.
Please, let's get off this dead horse.
Cut'n'paste works on X's level.
The problem is (or probably: was) not with X, but with Gnome and/or KDE.
Real life is overrated.
A real welcome development.
But I'm curious where Keith Packard stands relative to all of this; he has talent to contribute substantially to an improved X and has had enough problems with the earlier XFree86 development that he thought a fork was justified.
"Provided by the management for your protection."
Don't be silly, what this does mean is that small development groups are merging. This will be good for Linux. A unified group, with real direction is essential for our world domination a good OS.
You forgot, some fraction of them don't know what X is at all, except for being the last letter of the 7-letter name of a proprietary multimedia i/o library released by Micro$oft, which they are going to use to break into the 37337 game scene.
HAHAHAHA!
Now would be the time to strike on a new name change for the system. Since we have two X groups joining and it a new X orginization. I suggest they rename it to "XXX Windows System". I would bet they would see there number of downloads skyrocket.
Papa Legba come and open the gate
Perhaps Xouvert will join yet.
Please correct me if I got my facts wrong.
One thing that always annoys me with programming for linux and unix is that include files are always in a different spot. I've spent days hunting for something(yes I know about whereis and assorted utils) only to find out it's name had an x infront of it, whereas on the other system it didn't or it was in another directory. Something stupid like /etc/bin/include/graphics/opengl.
Or one system uses opengl and the other mesa for example, and then your completely lost. The arguement that if you new the systems you were coding for better you would be fine, is ignorant as most people use standard libraries like opengl, sockets.h etc, because they aren't supposed to need to know much about the other os for it to work. Anyways, if the X guys standardize things like the directory structure, and procedure interfaces(although I think there are standards for these) it will make things much easier for us linux at home, unix at work guys.
...Year that Linux takes the Desktop...
wait wasn't that last year? the year before? hehe
But seriously though, I see this is a very good move on the part of both projects.
"why don't you just slip into something more comfortable...like a coma!"
...hands down.
The problem is (or probably: was) not with X, but with Gnome and/or KDE
Indeed.
X has the most elegant cut-and-paste scheme I've ever seen, certainly vastly superior to Mac OS X and Windows.
Select with the left button pressed, and click with the middle button in the target window to paste. No Apple-C or control-V crap, no need to press any key of any kind. Click-select, click, and you're done.
Once you get used to it, you won't be able to stand the way Mac OS X and Windows handle cut-and-paste.
Gnome and KDE made the extremely boneheaded decision to mimic Windows even when it really doesn't make sense; when the X way of doing things is vastly better. Click to focus as a default? Ugh! Windows-style cut-and-paste? An affront to humankind.
The Future of Human Evolution: Autonomy
Linux needs to fix cut and paste
Its been a while since xfree has done anything innovative at all, and with freedesktop making its rounds very quickly, this could lead to really great things for the linux desktop.
So, how do the new developments at freedesktop.org like XCB/XCL fit into this new picture? I'm hoping the exciting new code can be eventually rolled in more easily now?
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Thats the core problem with this unix emulator, its trying to be everything and its a unix server emulator trying to capture the desktop.
Then they wonder why they arnt succeeding.
how about PERFORMANCE?
needs to be more like a lean fast ferarri than a cadillac with a lot of superfluous whistles and bells.
X is the old standby but its SSLLLOOOOWWWW.
lets hop up the engine before we give it a paint job.makes sense,no?
*Repent!Quit Your Job!Slack Off!The World Ends Tomorrow and You May Die!
XFree86 should be for x86 versions of X, or X thats generally run on x86-based OSes shouldnt it? Ideally it should be named XFree which will mean a certain implementation of X, yet architecture-free. XFree86 is already used on almost as many architectures as NetBSD supports.
And if x.org is uniting with XFree86, maybe we can keep it simple and just call it X. I know there are other implementations of X, but since x.org owns the copyright, might as well keep the name simple.
At the least, I would lose the '86'.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Because lord knows XFree86 has one of the dookiest logos ever!
Yes, there are many more important reasons why the merge is a positive thing, but when I first started using Linux as a teenager in 1994, I loved the X11 logo, and it definitely contributed to my perception of Linux and UNIX. Let's face it: the X Consortium's logo feels clean and elegant, but it looks hard and deadly.
``It's just too big, slow''
I have heard people contradict that. X is certainly not that big; on my system it's mostly fonts that eat up space.
Speed is a more complicated issue. There are many people who say X can be fast if programmed right. I don't know how that would be done, though. Besides, I think there is no ``right'' way to display movies other than pushing pixels to the portion of the screen that is currently mapped on the screen, and still I often can't get more than 10 to 15 frames per second on X, where I am sure the same movie plays fine in other OSes.
Then there is the expose events. These are real performance killers under XFree86, but I am confident that freedesktop.org's server has solved the problem by keeping window contents at server side. I don't know if this is related, but moving and resizing windows has been a real pain for me.
Finally, there is driver issues. The only video card I have had that was properly supported is an ET4000. Then, if I really cared bout that I would just get a supported videocard; so to speak vote with my euros and reward a company that has managed to get their card supported.
Please correct me if I got my facts wrong.
...confuse X with Window Managers and who believe yo can have only KDE _or_ Gnome Apps installed?
I don't wan't to see those clueless questions anymore when there are manuals available everywhere.
I think copy-paste works fine on the X level. I think KDE and Gnome does something wrong. Especially when it comes to selecting regions of text using the mouse.
My biggest issue with using linux at the moment is when I try and select some text in a browser, x terminal, email client or whatever to copy it and paste it somewhere else, the selection just disappears while I drag or the starting position shifts to some random spot. This is very annoying, because I end up selecting the entire document, pasting it into a text editor and manually removing the bits I don't.
This is definitely not ideal. People shouldn't ever have to type things twice and I can't believe it hasn't annoyed anyone else enough to inspire them to do something about it.
Even windows had this sorted since forever. I don't know if the problem is application, Gnome/KDE or gtk/qt related.
But it is probably not a problem on the X level.
I just hope that with this new, more optimitic outlook, more developers will come on board and contribute new and refreshing ideas to the development of X.
The unfortunate thing with X is that it is so important to *NIX and yet it receives less attention than the kernel. Sure, X11 isn't sexy but it a very important component none the less.
What I hope by the end of this year is a strong cohesive X server development team/community with good links to IHVs and an active programme in place to encourage people with new and exciting ideas to come forward and discuss them.
What I would also like to see is a situation where the X specification becomes more than just what we see today. We need an encompassing standard which not only includes what we have today but flexible enough to adapt to new extensions as they arise.
Along with these extensions, the toolkit communities need to work closer together with X and each other and work towards an X11/Consortium backed HIG of which all toolkits conform to. What I am trying to get at is this, different tool kits are great, each community can concerntrate on developing the strengths of that particular toolkit, however, for this choice on one hand and the adoption of Linux on the other hand to continue, there needs to be a standard set down. Once that standard is set down and the the two, X + toolkits, work closer together and allow better interoperability, the net result should be applications which look consistant no matter what toolkit is used.
CNN has a story today in which various people purport that Linux isn't ready for desktop prime time but has a window (rimshot) of opportunity to establish itself therein before the release of Longhorn in 2006.
Might this be a step in the right direction? Your fabled bluehaired grandmother doesn't want to choose between different window managers, etc. Hell, she doesn't know what a window manager is and doesn't want to know. Try to explain various incarnations of X to her and watch granny sizzle.
It will mean nothing for them. All this is is a consolidation of duplicate functions in administration of the projects, and maybe not even that.
KDE and GNOME are totally insulated from the poitics and even a lot of tht technical issues surrounding XFree86. X11 and the projects that run under it are very different beasts.
Now if users migrated from X11 and started using display projects like Fresco, Y, or even FrameBuffer, the KDE and GNOME teams would have to write a air amount of new 'connector' code and rework some libraries.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
"If you want copy and paste, write a deamon to manage it"
...), preferably doing it the select and paste way as well as the keyboard way (which could add support for named buffers). U am not writing this, though, because it would merely add yet another standard, and besides, I don't care enough. It works for me as it is now.
I agree with that stance, though. The problem is not that there is no support, it's that there is too much support. KDE and GNOME do it differently. Some applications do it differently yet. If I select text in Mozilla and press Ctl+C, it goes to a different buffer than just selecting it. Etc...
My solution would be a module (lkm, library, daemon, I don't care) that handles it for all apps (be they console, GTK,
Please correct me if I got my facts wrong.
No one is forcing them to use those features either. Simply removing them because they won't use them is pointless, as they aren't required to be used to get this basic functionality you describe.
``One of the consequences is that if you select text and close that program then that data is gone!''
Sometimes I think the proponents of LISP-OS are right. Everything in one address space, no unnecessary copying of data or checking permissions.
If you select data, the clipboard obtains a reference to it. Close your app, the reference is still there and you can still paste the data. Replace the reference in the clipboard and your data gets garbage collected.
Please correct me if I got my facts wrong.
"If you want copy and paste, write a deamon to manage it"
I've been wondering for a long time why this hasn't happened already. How on earth can it be hard to come up with a daemon that can recieve, store and reguritate small blobs of text or binary data?!?
Best of all, it wouldn't depend on which gui you were using. It could work with all of them. It wouldn't depend on any gui being present all.
With a standard clipboard service/daemon, you could do stuff like cut in mozilla or a KDE app, and paste in commandline vi/emacs or reboot and paste into a gnome app.
My Karma: ran over your Dogma
StrawberryFrog
N/A
The best way to avoid all of this is to stay logged in. Read at -1 Nested. Always ensure that you keep "Post Anonymously" checked. That way you can avoid the idiotic moderation and read the lot, and it drives the Slashbots into a foaming frenzy when you get an AC post moded up to +5 Insightful.
Not only that but I can't stand the morons around here who have obnoxious sigs that state they'll ignore AC posts but think that posting under an account called "Fatboy747" means that they're not Anonymous. Idiots.
I am *so* tired of being say that X is slow. I use X everyday, at work and at home, and never, ever has it been slow. There are some *applications* that are slow, most notable among them OpenOffice running on a Pentium 400Mhz machine, but on my 1Ghz+ machines it's quite nice.
The X Server has never been slow for me, and I really wonder where the myth that running X is slow. I have plenty of apps that run rather speedily on my X boxes that take longer on faster Win32 based machines. (Firebird comes to mind.) And just for the fun of it, I use a PyQT text editor that I wrote to teach myself PyQT -- it's interpreted, gui-based text editor -- and it launches and displayed in under a second on this Pentium 400Mhz machine.
No, X is not slow. The apps are.
So PayPal has adoped Xfree86? Remarkable!
...oh, that's x.org, my bad.
myselfmusic
You know, back in The Days, I used to whinge that X was inefficient for a desktop PC where there is only ever going to be one user displaying on one monitor at one resolution, and hanker after a direct-rendered system that bypass most of the unnecessary features.
.....
Then I had a kind of revelation. It ought to be possible to compile a very stripped-down X server with all those assumptions hard-coded right into it. You might have to edit the makefile just to set it up for a different monitor; but for how often you're ever going to have to do that, it's no price really.
Then I looked at the X source tree, and decided that it's not so bad the way it is now
Je fume. Tu fumes. Nous fûmes!
"X merely marks the text as selected"
Down at the Xlib level it doesn't even do that. The client side code (usually in a widget library) has to check which text has been selected
where when the mouse was pressed and moving (or whatever the policy is) and keep it in a buffer. All the X server itself does is provide selection request and selection notify events
which do nothing more than allow clients to grab chunks of data from each other via the server. They could be used for anything really, not just cut-n-paste.
The real Gnome/KDE clipboard (controlled by ctrl+c/x/v), and the X11 text DnD buffer (controlled by select + middle clirk). While most things you ever do will be easy with the X11 DnD, replacing a specific selection, etc, is fewer steps with a clipboard ala Gnome/KDE. Unfortunately for Gnome, they will blindly copy text from the DnD buffer over the real clipboard contents most of the time.
Once you understand the difference between the clipboard and plain text DnD, you'll see why both are important. Especially since you just can't highlight a part of a picture and middle-click it into a new window in The Gimp.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
This troll isn't saying anything, just attaching the mispelling to the name. And gullible moderators are falling for it again and again!
People, try to read the contents of the post before you moderate. Just because you don't understand it, doesn't mean it's insightful -- it just means you don't understand it. Maybe because it's info, or maybe because it's random garbage like this parent post.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It is absolutely clear why the XFree86 team-members joined the X-Consortium:
They wanted this cool x.org mail-adress
Correct on both accounts. You haven't read the article and X is separate from the window manager. So what's the point of your comment?
Eric S. Rayrnond struck again :-)
"Honey, I feel a certain distance between us..." "Really? A 31ms ping ain't that bad..."
So does KDE 3.2
KControl -> Desktop -> Size & Orientation
For added convience check the box there that adds a system tray applet.
Dammit! Why can't the browser just be integrated into the OS?
*ducks*
My beliefs do not require that you agree with them.
WROGN!
That is not cut-paste scheme since you cannot cut and paste with it.
Really? I've been using X for over a decade and have never had any difficulty cutting and pasting with it. Perhaps you are dealing with user issues, and not design issues of the Window system or its applications.
I want to paste (and not cut)? Left-click/hold and select, point at the target and middle click.
I want to cut-and-paste? Left-click/hold and select, tap delete (or backspace), point at the target and middle click.
We need only one standard (by default, at least) and it seems that the market has chosen it
The 'market' hasn't chosen anything, any more than the market had chosen horse carriages over automobiles in 1920 simply because most people were still using the old technology.
Flames away, but I am still right.
Saying your right doesn't make it so, any more than Bush saying there are WMDs in Iraq make it so. Flames aren't required to rebut you: five seconds using X is sufficient.
The Future of Human Evolution: Autonomy
Has anyone recently written a cohesive description of the XFree86, X.org, FreeDesktop, Gnome and KDE projects, what thier states are, and when stuff is coming down the pipe? I understand the immense task this would represent, and that it would be several weeks out of date by the time it was readable, but I'd really appreciate a loose timeline for all of the fantastic projects I see outlined at freedesktop.
I've been looking at the screenshots up there and dreaming about translucency, D-BUD, unified spellchecking and display postscript for my desktop... Is this stuff two years out? Coming next month? Just vapor? Could I be running betas of them right now, if I chose to?
"the market has chosen it" is and always will be a bullshit statement.
X has both, and it has always had both. They're not "incompatible". Middle click inserts the primary selection, while application can access the clipboard buffer provided by X, for years and years long before KDE and GNOME with things like meny options or keyboard shortcuts. The GUIs use C-c, C-x and C-v just like Windows. (In which language does paste begin with v?)
That you can choose to use the clipboard buffer does not mean that we lazy geeks should be hindered from using the middle-click method. Neither is in the way of the other and they never were (except that for a while one of the DEs had a wrong implementation that used the primary selection buffer for C-c/C-x. This was dealt with accordingly - as a bug).
JWZ explains it nicely.
Not really.
I seriously doubt that X.org, the new face of the former X Consortium (members like HP, IBM, Sun, XFree86), has merged with XFree86. They have two totally different goals. The goal of X.org is to promote a single X (currently 11R6) standard between different vendors and implementors. XFree86 was and is a member of X Consortium/X.org, and is a specific (Open Source) implementation of the X standard.
The rest of it is too confused for me to make any real sense out of. I suspect that there is some good vibes between members of X.org, freedesktop.org, and hopefully XFree86 - which is a good thing. Key developers of XFree86 (e.g. David Dawes and Egbert Eich) and X.org (Alan Coopersmith) now seem eager to move forward and work together on making better software. Getting people all on the same page and working together is a lot of work, because of different interests and goals, but I think that XFree86 will see 2004 as a busy year with lots of improvements.
I really hope that freedesktop does not widely diverge from XFree86, let it be a test bed sure, but not a competing product.
Eric's a bit of an idiot. He describes development processes without knowing how to code himself (lifetime achievement was procmail, which would take me about a month to write, and I'm no longer a programmer myself -- he literally got laughed off of the Linux kernel mailing list when he tried to contribute). He's very eloquent, but very self-centered and very stupid. CatB is exceedingly well written, and just plain wrong (free software development doesn't work like that). He's willing to sell out to Microsoft, VA Software, and anyone else who is willing to throw a bone his way. His following consists mostly of non-technical people (sometimes very smart, but misled business people), slashdotters, and script kiddies. When someone posts trolling comments under the name Eric Raynond, do you think anyone will be able to tell the difference? Really....
Use emacs as your OS and set up your own damn bindings for cut, copy, and paste!
;)
yes, i said emacs is an OS.
When the XF86 Core Team decided to disband three weeks ago, weren't we told by Overly Critical Guy that this indicated that XF86 was falling apart rather than healing itself and that it was proof that the open source community can't produce sufficiently reliable software?
Where is that guy? I want his insights on how to understand these developments.
Now that X is opensource development, and the two major X groups have merged...
Perhaps it's time to build a new X, X12, and fix all the muddled patching X11 has gone through.
Reform CDE into something usable,
Create new widget libraries that don't have anything to do with GNOME or KDE, but can replace using Xt, Athena, Motif,...
Repeat: removing the networking code would not make X any faster.
So, given that including the gee-whiz features that a lot of us require in our daily usage has absolutely penalty for "average joe's grandma", why would you want to remove it? That's like saying that the average user won't use sed, so RedHat should remove it to make Linux faster.
[1] Webster: "uninstructed or uninformed". I don't know of a "nice" substitute, that is, one without the negative connotations. Don't infer malice. :-)
Dewey, what part of this looks like authorities should be involved?
This is good news, I hope things will change to better over time.
I hope this will also be the end of the "XFree86" name/brand. Let's face it, it's not really that great name - Not couting "GNU Anything", I've always disliked names that push the "free software" or "openness" aspect, so names with "Free" in them always sound silly. The ideology should be in the heart, not the name.
Also, the whole name is a joke on something that hasn't been around for a while. I hear it's supposed to be a pun on "x-three-eight-six" - X386, which was what the project was called until 1992. I'm sure whoever came up with "XFree86" name had a good laugh with fellow developers, but now, over a decade later, this obscure fact has been completely buried in sands of time. No new users find it funny because they have no idea where it comes from - it has turned from silly and odd-looking to just plain odd-looking. Kind of like "DivX ;-)". Yawn.
"X11 Public Implementation" sounds nice and technical, however =)
- Highlighting something copies it into the "primary selection" clipboard-type place.
- Highlighting something and hitting CTRL-C will put it in the "real" clipboard. It will stay there no matter what else you select, until you CTRL-C something else. You paste it with CTRL-V, of course.
Best of both worlds! I hate selecting something with the mouse and trying to paste it elsewhere with shift-insert only to have OpenOffice or whatever stupid program try and paste something from the CTRL-V clipboard instead.Middle-clicking the mouse button or shift-insert will paste the "primary selection" text.
Dlugar
Computer Go: Writing Software to Play the Ancient Game of Go
Now you'll be able to theme twm!
Making a note every now and then, depending on which editor is posting, just makes you looke (more) unprofessional.
If forking is one of the "bad things" that can happen to OSS, merging is one of the "good things." Multiple similar projects, each with their own advantages, merge together to make... damnit, what was that huge robot in the Power Rangers called...
Comment removed based on user account deletion
X (or really the desktop environments and applications) supports both
I challenge you to find a modern X program (ie a KDE or Gnome program) that does not support ctrl+x and ctrl+v for cut and paste. And don't you dare say "Emacs" or any other program that runs on Windows and does not support ctrl+x and ctrl+v there either. I can complaint that cut & paste don't work in Lotus 123 or in the DOS cmd.exe or hundreds of other Windows programs.
The middle mouse thing is really drag & drop, with the advantage that you can rearrange the windows and open/iconize them between when you "drag" and when you "drop", and also the advantage that it is trivial to "abort a drag". Unfortunatley the original X programs thought drag & drop was sufficient and did not do clipboard, which is the source of complaints. But you are basically saying the same as "Windows should get rid of drag & drop, it is confusing and everybody uses cut & paste".
I'd like to see X do something like this:
... but again, here a handy graphical app showing the stack could be handy for such ... expansive uses of the buffer).
1) Highlight new text with left button
2) Keep holding left button and press right button to cut to clipboard
3) Highlight text-to-be-replaced with left button
4) Keep holding left button and press middle button to copy from clipboard
What do you think? I find move-n-replace to be very handy for text editing.
That would be a handy enhancement.
I'd actually like to see something a little more general.
Cut-and-paste works as it is now, but make the buffer a stack (a little app could even display the buffer stack graphically)
Middle-click+number pulls that item from the stack.
Middle click pastes stack[0]
Your #4 (left and middle button) pastes stack[1] (your second cut has pushed it up and replaced stack[0]), as does middle-click+1.
middle-click+11 pastes stack[11],
middle-click+756 pastes stack[756] (if your stack is so large and you remember what you cut 756 steps ago
This returns keystrokes to more complex cut-and-paste operations, but 1) keeps basic cut-and-paste, copy-and-paste simple the way they are now, and allows for much more expandability in pasting older cuts and doing other complex c by only adding a couple of keystrokes.
The Future of Human Evolution: Autonomy
just look at the id number
Maybe, Maybe not... But it sure makes it easy for "average joe's" brother-in-law to get hands on with "grandma's" pc when there is something wrong, some procedure needs testing before teaching her how to do it, or such. All without going to going to grandma-in-law's house and dealing with her 15 cats and the special cookies she baked you that seem to taste like the ashes of the last three packs of cigarettes she smoked....
-Wade
[NT] I want mouse-only access to clipboard
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Is this going to get stuck in RC-limbo or are they going to finally release it?
Thanks,
F.O.Dobbs
Comment removed based on user account deletion
The Windows GDI seems to change whenever the wind blows.
Name the last time it changed. Oh, you can't. There are function calls in Windows going back to 1.0. You can still run MS-DOS Executive--the file manager from Windows 1.0--under XP if you try.
Pure FUD in Windows' direction.
Under X, you want to cut something and paste it to multiple applications, one after the other? In Windows, I cut once and can paste as many times as I want because it sits in a system-wide clipboard. In X, you have to do some of those steps manually.
If we were stuck with a widget-based implementation, I'd have to upgrade my X server every time Xlib, GTK+, WxWindows, QT, Motif, Lesstif, etc, changed. That's stupid.
What's not stupid is using the existing protocol, which is fast (it ran well on 10 mhz SPARC machines 15 years ago!), efficient, and easy to compress for slower links.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I have a feeling your post will be ignored, and the XFree86-heads will continue to call X's system of copy-paste "the most elegant they've ever seen," etc.
Yours is the most level-headed, rational criticism of X's copy-paste system I've ever seen, but as I've said before, X users have this bizarre fear of change and want things to stay the same for another 20 years.
(and that Windows' model is slowly transforming from the framebuffer to a more X-like approach)
How so? Explain. In fact the only real changing thing about the Windows model is that it will be using a 3D hardware-accelerated buffer to draw the screen with.
Why do you want to change the refresh rate anyway - because it was set wrong in the first place? Thats just a configuration issue. I can't seriously think of any reason why you'd actually want to switch back and forth between refresh rates in normal PC usage. That said it most likely can be done using the RnR extension, which allows you to change resolution on the fly (another pointless Windows concept).
Boneheaded questions like "why would you want to change the refresh rate anyway" are why X has taken about 20 years just to be able to change its own desktop resolution--and even that's still not fully implemented.
Guess what, people? Some people might want to change their resolution, refresh rate, or color depth without exiting the GUI. Horror of horrors! It's the principle of it, and that should be the end of the argument--it's something a supposedly modern GUI system should be able to do.
This is what I don't get. Linux people obsess over "choice," but then when someone dares suggest an alternative cut-paste system or an ability to change resolutions, people jump down their throats because they have a different method of using computers. "WHY WOULD YOU EVER CHANGE YOUR RESOLUTION? WHAT'S WRONG WITH YOUR REFRESH RATE?" Those kinds of questions come from ignorance over the fact that for you, everything is fine, but for some one else--god forbid--they want to change those values in the GUI.
If you need practical reasons (and I know you do because you're a raving XFree86-fanboy who wants things to never change), here they are:
- Connecting to another monitor, or a project, or any other display device in which the refresh rate, color depth, or resolution would suddenly be wrong.
- Maybe I want to switch down to a lower color depth to speed up some 3D operations going on.
- Maybe I want to change resolutions to see what resolutions is best for my eyes. I seriously have to exit and edit a text file to do this?
- Maybe I like the idea that a GUI would be smart enough to actually change its video mode.
- Tons of other reasons having to do with someone's personal preference for using their GUI in ways that--gasp--differ from yours. Choice and flexibility, right?
- Here's the part where the dunderheaded "Ctrl-Backspace-+" combination comes in, which doesn't change the desktop size or color depth and requires you to scroll the edge of your screen. It's completely different.
Why do newbies keep calling for a replacement for XFree86? Because these insanely basic features that every other visual interface has been expected to have since the early 90s still doesn't happen in XFree86. And the people who support X on Slashdot hoot and holler about how none of it is necessary. So, most people just assume it's not possible for X to do it and so clamor for a replacement. It's X's fault, and the fault of the fanboys who defend it constantly.
None as far as anyone knows. control-v was selected because it was very near control, on old [qwerty] keyboards. The interface designers realized that paste was a common enough operation that the hasstle to teach people what the short cut is, is more than out weighed by savings in time once they know it intuitivly.
Proper user interface design includes consideration of how to make the daily expert users fast, and control-v was an excellent decision from that standpoint, even though it means for the novice it is harder to use.
Seems someone is being ignorant. Slashdot even posted an article on it. It was a specification essay.
The Original Comment from Error27: http://slashdot.org/comments.pl?sid=91077&cid=7845 466
Repeat: removing the networking code would not make X any faster.
Then answer it once and for all--what is it that makes KDE/GNOME so slow? So we can put this issue to rest by fixing it.
Actually, I think it was just proof that you were trolled...
what about fdo's xserver?
keithp's server in other words.
it's small and fast as hell, and has eyecandy.. does this affect that?
Personally I moved to xfce and I've never looked back. It looks good and loads in seconds - even on my old p166 with 64 mb of ram.
you are barking up the wrong tree on the local / remote display issue.
The network stuff does not hurt X one bit with the display is local. Your particular X server / driver combination might be slow or not depending on your environment, but that does not mean X is slow.
Changing things now would break a lot of things that do not need to be broken. Everything written for many years now makes use of X. Do you really think we should start tearing into that? Sure, build a compatability layer right? Well, why not just make the changes to X that need to be made instead?
We need X to continue to be a feature of Linux. Not an addon, but a feature. X is what seperates UNIX machines from all the other machines out there. X preserves the multi-user attributes of UNIX at the GUI level.
Most people here bitchin' about X really have no idea what multi-user computing is about. I have written about this many times here before, but what the hell. As many times as it takes...
X allows you to distribute your computing as you see fit. It scales very nicely. It also needs more work to fit in to the single home user experience. This can be done without breaking it or mangling it into something less capable.
Besides, Microsoft would love to see X die. Then they would no longer be at a disadvantage in the display area. Just had another thought in this area. With a Microsoft (and others) system, you need to actually have a copy of a document in order to make use of it. Thus, they are putting in lots of ugly DRM stuff to limit what people can do.
With X, you can give the user the ability to work on a document, within limits you specify, yet not actually allow them any sort of real access to the document in question. How? Set up a machine with a limited set of tools specific to your document access needs. Then remote the display to the users computer. This is possible because of two UNIX multi-user features; namely, X and the ability for a program to SUID and run as its owner, not the user asking it to execute.
Want unified fonts for every machine in the building located in one place ready to use? Host a font server.
Tired of installing basic applications on every last machine? Host them on an application server for everyone to share. Make a change in one place and you are done. No pushing software through the network, no login scripts full of reg hacks and such.
Running a tweaked window manager for some reason? Host it as well.
Have a group of people who all need to use a powerful machine / application combination on occasion, but spend much of their time running normal applications? You could buy them all top of the line machines, or you could buy one really nice machine and let them *all* use it when they want to.
Of course you could just buy them all really nice machines and spend the time to load the application onto all of those machines. Most applications of this type require licensing as well. Getting that license to float across all of those machines takes time and effort as well, not to mention the dollars companies ask for that option.
Or, install it once and let X do your work for you.
All of these things might seem goofy to you if you are running a couple of machines at home, or have never really been exposed to a multi-user computing environment before. Don't feel stupid, check out this actual event that happened to me at SUN a while back.
I was there to install an application, but the admin was sick that day. Since I had flown in, things needed to happen that day. So, I installed the application in the user-space, then gave the others instructions on how to make use of it. (One user had a pretty nice machine.)
The guys were stunned! They said that was pretty cool. They did not know they could do that, somebody should market that stuff. Told them a three letter company was trying hard to do just that.
(Blank stare, then understanding... SUN!)
These guys w
Blogging because I can...
If we do this, new applications will be written for the framebuffer. When this happens we lose our multi-user computing ability and begin to have many of the same problems Microsoft currently enjoys having...
You want to trade our killer enterprise computing features for the short-term ability to make home and casual users happy.
This is crazy!
We need to continue to refine how X works, not get rid of it because it is hard somehow. These are simple presentation issues, not core problems.
X is better than everything else out there and has been from conception. We are fools to abandon that now.
Blogging because I can...
Ok, here's the thing: removing remote code would
not make X any faster - that's mostly true. However
if you reengineered X without network transparency
in mind it would get much faster for sure. One of
the things here is that you could then move X
entirely into kernel saving all the context switches.
In general, one thing people like about Windows is
that it puts an emphasis on treating the end user
right, and so bends over backwards to make GUI
responsive.
OTOH, I am myself evolving away from the idea that
X should be in the kernel. With ever more powerful
graphics cards, the day is coming when we will be
able to move all of X into a separate RTOS running
strictly off of graphics card resources. My
personal conclusion is that X is too big to rewrite
so its performance needs to be hardware brute forced.
None of this stuff requires getting rid of X. It does require some coordinated effort to solve them however. Which this project appears to be.
All display systems have to specify these things. The simple truth about X is that nobody has focused on these things yet. (Looks like it is about to start.)
Blogging because I can...
Tried XFCE4 yet?
CDE users will feel comfortable, and it has the benefit of NOT being CDE.
X is not slow by design. Look at SGI machines, they all run X. Even the really old 30Mhz ones will provide a nice snappy GUI experience and they were made in 91! The linux implementation needs further refinement which is some of what this project looks to provide (finally).
As far as the eye-candy goes, you are right for many casual/home users. With regard to enterprise computing you are dead wrong. People are supposed to be working with their machines. The less that gets in the way of that, the better.
Do we need the work? For sure. Is any of this stuff work replacing X. Not a bloody chance. X plays hard in the enterprise computing space, saving money & time through central administration and effective use of avaliable computing resources. Buffers simply cannot compare.
Network transparancy was wonderful and innovative 20 years ago. Just think, networks were young then and they still bothered to build it. Today, we have networks everywhere, and people call for the removal of the network display feature? WTF! Now is the time to be pushing it because the networks/ OS / hardware are all dirt cheap!
The only reason people say this sort of thing is because of the PC mindset.
X is great today, and it is going to continue to get better. Most of the old slashdot responses are dead on in that regard. Will we get the eye-candy nirvana you claim other systems have?
Given the excellent response qualities of my SGI, running X, I would say it is only a matter of time for Linux...
Blogging because I can...
XFree86 has not Merged with X.Org
[23 January 2004]
There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge.
X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors; XFree86 is an independent volunteer organisation, with a focus on the individual. Therein lies the rub.
Just in case no one has posted on this issue.
Here is a link to XFee86.org refuting this news.
To quote:
XFree86 has not Merged with X.Org [23 January 2004] There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge. XFree86 is an independent volunteer organisation, with a focus on the individual. X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors.
XFree86 News
23 January 2004
from xfree86.org
XFree86 has not Merged with X.Org
[23 January 2004]
There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge.
X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors; XFree86 is an independent volunteer organisation, with a focus on the individual. Therein lies the rub.
From xfree86.org:
XFree86 has not Merged with X.Org
[23 January 2004]
There are several news items claiming that X.Org and The XFree86 Project have merged. This is a blatant lie. The XFree86 Project remains an independent organisation, and will continue as operate as an independent organisation according to its mission statement. There has been no discussion with X.Org about any such merge, let alone any agreement to a merge.
X.Org is a vendor-sponsored organisation, formed by vendors to best suit the interests of those vendors; XFree86 is an independent volunteer organisation, with a focus on the individual. Therein lies the rub.
Except that you're wrong. As an experiment, a group re-wrote X without using sockets. The end result was that there was little measurable advantage to stripping out the networking layer. The main reason is that, for local connections, X uses Unix domain sockets, which are highly optimized with lots of zero-copy communication. There's really no penalty at all for using them as a communication method.
Sure, it seems logical that removing networking would make X faster, but people who know what they're doing have tried it and it didn't make any difference.
Dewey, what part of this looks like authorities should be involved?
Buy a multi-button mouse
Where can I buy a multi-button trackpad to replace the two-button trackpad built into my Acer TravelMate 721TX laptop? (I couldn't find anything relevant with Google.) And who is hiring programmers in the Fort Wayne, Indiana, area so that I may earn the money to buy anything? (I couldn't find anything relevant with CareerBuilder.)
Maybe this project will see faster development in this area.
Thinking of old school widgets, which we could get the SGI viewkit. Old school maybe, but pretty useful and good looking today...
Blogging because I can...
XFree86 is an independent volunteer organisation, with a focus on the individual.
I don't know, but that sounds to me like a "Blatant Lie". Focus on the individual? How can they claim this when they have already agreed that they've dropped the ball. Isn't that why they disbanded in the first place?
Sounds like a bunch of bullshit to me.
Luyseyal touched on an issue that is very dear to my heart. He described my idyllic cut-and-replace:
If you do this in X... Oops! By selecting the text that you want to replace, you've just copied it into the buffer again, overwriting what was there.
Bonus points if you already closed the first application, and the important copied text is gone forever.
Like Luyseyal, I find the current workaround (comprised of extra 'delete' steps) to be much slower, and kludgy besides.
But unlike Luyseyal, I would prefer the X developers to just implement the Windows method, instead of requiring users who migrate to learn a new method.
KDE has been my desktop for over a year, and I use the "kludgy method" to cut-and-replace day in and day out, hating every minute of it.
In a related vein, does anyone know how to disable the regular CTRL-C in a KDE terminal window, perhaps by making it into a menu item instead? Then I could finally use CTRL-C in the terminal.
Daniel
Why do that when you have a multitasking OS and a window manager?
I cannot usefully open every application installed on my system because I don't have enough RAM, and I don't have enough RAM because I don't have enough money, and I don't have enough money because I can't find a suitable job, and I can't find a suitable job even with my B.S. in computer science because I am unwilling to relocate, and I am unwilling to relocate because no employers known to me have posted jobs available in towns where I have relatives.
I was able to repeat your experiment with xterms.
Then I tried opening two gnome-terminals and repeating the experiment. It failed.
Copying text from an xterm, closing it, then pasting into a gnome-terminal doesn't work. Opening a new xterm and then pasting (from the old, closed xterm) still works.
So the facility obviously exists, making it the application's fault for not using it.
The enemies of Democracy are
[NT]my ideal is a mouse-only and a keyboard method
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Try searching for X on Google. It would be much easier if everyone agreed on a name
X11. X Window System. Was that so hard?
Highlighting text intuitively implies making a copy of it? Absolutely no way.
How do you expect to make a copy of something if you don't point out what it is you want to make a copy of? It is intuitive. It's so natural, this is the first time I've ever thought about it.
If anything, it's X.org looking like morons claiming they got live breathed into them by XFree.
Which is the shit and which is obsolete? I think the former holds both titles.
And the other repliers wonder why you got downmodded. Also, never quote penny arcade again. It's really fagtastic.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Start with the source application (whether a terminal or open office or whatever). Select what you want to copy, then use the Copy command from the Edit menu. This _should_ put the selected text in the CLIPBOARD. i.e. it moves the PRIMARY text to the CLIPBOARD.
No matter what you select afterwards, the CLIPBOARD is never erased until you use Edit... Cut/Copy again. The PRIMARY may be erased, but not the CLIPBOARD.
Switch to the other app., select what you want to replace, and choosed Edit... Paste.
Voila!
Now if the apps don't make use of PRIMARY/CLIPBOARD correctly, well there's nothing X can do about that. X even allows content negotiation, but that's something I haven't seen done hardly at all.
You have to stop thinking about using middle click to paste. Only do that if you're editing something in place. Otherwise use the Edit... menu in your app. It's there for a reason.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The original comment from Error27 can be found here
Mod him back down please.
but no one has sat down and figured out how that's going to work.
You'd need a "media" registry like the CLSID section in Windows to get this to work properly... to answer questions like "How do I uniquely identify a data format" and "What application/KPart/ORB do I need to display it", or "Can I assert a different format that can be downconverted into something I can handle using ImageMagick"
Something like mime_magic from Apache but system-wide. And you'd have to get all the app suites to adhere to it so they can negotiate. It might have transformation rules and default openers/editors, etc.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
If you middle click into the browser window (not on a link), it goes to the URL you "paste". It's quite handy. For example, someone types a link in a post but doesn't make it clickable. Just select, and middle click. Wham! This even works in Windows, believe it or not.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Check the spelling of this guys name out (Eric S RayRNond). It's not ESR. Also note the number of replies that point this out that have been modded down.
It's not an original post either - the text is straight from a post by Error27 which you can find it here
I want mouse-only access to clipboard
As I said, a small application that shows a graphical view of the buffer stack would allow that. Scroll to the desired entry, click on the item with the left mouse button (copying it into buffer[0], pushing buffer[0] to buffer[1]), and middle-click to paste. Left+Middle to paste buffer[1].
I'm sure someone could get creative with the scroll wheel to make navigating the buffer stack even easier, sans keyboard.
The Future of Human Evolution: Autonomy
XFree86 and X.org are completely separate groups and have little to do with each other. The XFree86 core haven't left to go join X.org. The XFree86 core disbanded because most of the members were essentially retired and didn't do anything anymore. The core team disbanding was an acknowledgement that the core team didn't lead development anymore. The assertions made in this slashdot news article are a complete fabrication.
Didn't you see that Usenix paper by Gettys and Packard? They studied the X traffic produced by various toolkits, and they all make far too many roundtrips to the X server. Fix the toolkits, and X programs will run a lot faster.
BTW, X runs nicely on my 32Mbyte 200Mhz PDA. But the X server was written by Keith Packard, so you would expect that.
-russ
Don't piss off The Angry Economist
Also, XFree96 needed to be a corporation because only corporations could join the X [industry] Consortium (x.org).
-russ
Don't piss off The Angry Economist
Well no, you don't get it. If X is not networked,
then it doesn't need ANY security, then you can
easily stuff it into kernel space and save on
context switches.
See? You are already calling it two names.
But notice that the same top results pop up for both queries. Still, if you insist, x11 OR "x window system" happy?
Other people say Xfree86, or just Xfree.
I see four times as many Google hits for XFree86 than for XFree. It seems that most users have settled on "XFree86" as the name of the popular implementation.
Some say X.
"X" and "XFree86" are two different things. "X", "X11", "X Window System" refer to a protocol specification and the framework of an implementation; "XFree86" refers to one popular distribution of a full implementation. "Exceed" is another, and "WeirdX" is yet another. If you want to search for X meaning X11 in any of several idiomatic phrases, you still can: "X server".
Some say X Windows.
I see "works on X Windows and Mac" and mentally insert commas, as if it referred to three platforms: POSIXish systems running an X server, Microsoft Windows systems, and Macintosh computers.
The whole point of control characters was to do things with the terminal that didn't have anything to do with printing glyphs on the screen, like moving the cursor around, clearing lines, or on some terminals, entering escape sequeneces that ultimately allowed for cut and paste.
When GUIs came into vouge, and people weren't worried about users not having a "typical" VT100 key->action mapping, they could repurpose the Control key to do other common things in the gui. It's still serving the same function (doing non-data-entry actions inline), albeit not with terminals in mind.
In this sense, for hybrid environments like Linux, I think the idea of using the windows keys for a MacOS-like command key is a grand idea.
The only trouble is with smaller laptop keyboards. Perhaps FN can fulfill the same role.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
That's the problem I always had with X.
We are Turing O-Machines. The Oracle is out there.
http://www.xfree86.org/current/xclipboard.1.html
But there's always the xclipboard option. Basically, if you want to put your primary in the clipboard, just middle click into the running xclipboard. Then you can "paste" from Mozilla, or Gnome, or whoever.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I won't get into the question of whether X does remoting right for the most common modern cases of remote access (i.e. not dumb terminals, plenty of CPU resources all over, except in niche cases like wireless handheld devices)...
The whole concept of remoting is not about horsepower; it's about administration. It's much easier for me to install and upgrade an application in one location (a server) than multiple locations (individual servers).
I triple-your-money-back guarantee it is easier to administer a well-designed X-based system of desktops than it is to administer the same number of MS-Windows based desktops.
The added benefit of modular horsepower is, of course, very important, as well; the average lifespan of a desktop PC running MS-Windows is about 3 years. If those were instead the same PCs running an X-based desktop, the lifespan would be much, much greater. We have NCD X terminals that are 8 years old still in service, providing very useful work.
But that gets back to the "lots of desktop horsepower" discussion, which I said isn't important to establish the value of application remoting. (As opposed that stupid desktop remoting so prevalent in the MS-Windows world.)
Microsoft is to software what Budweiser is to beer.
I believe this idea has been tried before... if my memory serves me right, the proper technical name for it is: "BSOD".
Not to mention the fact that context switches would be required to access all the APIs of said application....
Hey everyone. I have no idea how X works, nor have I ever seen the code and I don't care to at the moment. But there are two things that would seem to make sense to me regarding what X does.
Give it a fonts folder, and when you copy (or click and drag) fonts into the folder, every application would be able to use that font immediately. A font daemon or something could do this, automagically or you could update it manually at your will to save from having to run one extra process (that will most likely be unneccicary to the powerusers).
It is a network protocol. I like that. But is there a way to turn off the part where you can access it over the net by default, therefor leaving it secured. All in a conf file for "enable X over networks". I know it uses unix sockets but .. ah i don't really know what I'm saying.
Is there a way to make it smaller? I've seen the X source code coming from a few different ftp servers, all in chunks of 3 tarballs totalling about 30-50 megs. I'm not one to complain, but if there were a smaller GUI server available for download (generic linux binary, or code with available addons) wouldn't this be a simpler solution?
anyways, that's my 0.02 bits.
feedback is welcome, I've also posted this in my journal Journal
Actually it would. Just not significantly. The XFree86 guys have experimented with different transports including a SHM transport (btw: that's not the same thing as MIT-SHM). They could achieve 5% speed improvements with SHM transports for some (limited) operations. The performance improvement wasn't considered worth the effort and the loss of networking functionality.
It's more correct to say that the socket transport in XFree86 doesn't significantly impact the performance. And the benefits greatly outweigh the costs; my home setup involves three computers running GNOME applications displaying on my laptop. I was most impressed to find that GNOME handles widget-theme changes across all computers automagically. Cut and paste works, etc. The only annoying thing is when I save a file to /tmp then try to load it in another app. I need to remember that it's $HOME/tmp if I want it shared between my apps.
sweet. Slashdot reporting on XFree86. Slashdot can continue their tradition of not knowing _shit_ yet posting innuendo.
Nice work, douches.
Just because office programs use ctrl-c to copy doesn't mean every other program should.
None of this has a thing to do with X - it comes down to the applications you use , the window manager, and a belief that everything should be the same as another OS. That other OS is improving dramaticly, and has a place for those that are trained to use it and do not wish to learn how to use another system. Computers are hard things to use, so it makes sense for people to use what they are trained to use - but expecting all systems to behave the same way is an unrealistic assumption.If you paste something that isn't text both applications have to know what to do with it - even ms windows and third party don't have that completely solved yet, you can only cut and paste between applications that can work together.
David Wexelblat coined 'XFree86' as a weak pun on 'X386', which turned commercial. It is named for the processor, not the year.
Everyone I know is going to want to turn that Longhorn shit back to the "Windows Standard" of Server 2003, et al.
I'll take a decently configured WindowMaker desktop over that any day. It may not have antialiased, transparent icons in the dock, BUT WHO THE FUCK CARES ABOUT THAT?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Like I said, back in the day when MS put GUI in the
kernel it was the right thing to do for a desktop
OS. Nowadays I believe an even better approach is to
recode X to be hard real time and run it in an RTOS
running wholly inside the graphics card.
As a side note, the attitude in your response indicates
that you are not willing to compromise every aspect
of computer operation for ease of use and responsiveness.
I therefore hope that you do not get involved in
developing desktop anything. Stick to servers,
please.
Xnest :1 -geometry 1024x768 -query localhost
Presuming that Xnest is included in your X installation and you are running a display manager (kdm, gdm or xdm for example), this will open a 1024x768 window and display a login prompt within it. You can then log in (either as the same user or as a completely different user) and use a web browser on a 1024x768 screen even though your screen is 2560x2048.
My sister-in-law uses this to see what the pages in her forthcoming web site would look like to someone browsing at that res. Her comment on 640x480 was "What is this? A thumbnail?" (-:
In short, why bother being merely as good as MS-Windows? As well as doing everything that it does, we should take note of useful things which are easy for us and impossible for the convicted monopolist.
With Xnest, as well as opening a session at a different resolution, you can also open one at a different depth. If the hardware supports it, it will be done directly otherwise it will be emulated. You can see how horrid you app looks in 16 colours, greyscale or black-and-white. If the Xnest session is larger than your physical screen, you can scroll around and see it all in chunks as big as your hardware allows.
If you want to put an MS-Windows session on your screen rdesktop 1.3 or later does full RDPv5 protocol, all depths and resolutions (plus sound, if you don't mind kissing your bandwidth farewell). If you want a copy of someone else's screen, use x2x. If you want to display stuff at a resolution or depth which you don't have, or in batch without toucing your video hardware, use Xv - take 4096x4096 screenshots on your S3-Virge-equipped machine, knock yourself out. Or use Xvnc and display to a VNC client only. And so on. I'm waiting for Xrdp to appear. (-:
Got time? Spend some of it coding or testing
Your choice, I guess. A damn silly one, but you get that.
Try searching for "Windows". Low signal to noise? Not half!
Got time? Spend some of it coding or testing
Telling it to listen only on the lo/127.0.0.1 interface seems to do that quite nicely. The "-nolisten tcp" option to X shuts down TCP listening completely (your apps then connect to X through a Unix socket), if you prefer that.
Got time? Spend some of it coding or testing
And when that 'aspect' is stability, as in 'no BSOD's then he's completely correct.
Having windows dragging a few percent faster is not an improvement if it means that you're going to lose even an hours work once. Then all that 'saved' time is more than used up, and then some.
On the contrary, we need more people like him developing for the desktop. People who for example understand that developing a GUI application in 'C' just so that it can crash from a random null pointer reference as soon as the user turns his back, on the theory that 'code that draws must be fast' is not the way to do it.
Repeat after me; an application (or whole computer if you're under windows) that crashes is supremely unusable. Always was, always will be. First the functional requirements must be met, and then the non-functional. If you can only have one, then go for the functional. Fast and wrong is never right.
Stefan Axelsson
Fast and wrong is never right.
It is even worse than that, having X in the kernel would be wrong and would likely gain no speed and might even lose some. Simply because he forgets that applications are conducting very intensive conversations via graphical APIs with the X server, so moving it to the kernel would simply move context switches from the calls X makes the kernel onto the calls applications make to X. I have not conducted much investigation here but a cursory glance would indicate that the kernel calls made by X are restricted to some bulk AGP/PCI data transfers whereby one context switch occurs per large block of data and on the other hand the APIs exposed to the applications deal with much smaller and frequently used objects like window elements and widgets. So it would probably be a net loss of performance.
Like the IO optimisations that take place in a (decent) C library, by blocking transfers. Of course, never thought about that but it makes sense. If you have the time to investigate further I think many people would be interested in the results.
As an aside, it's all this talk about NT being a 'microkernel' that irks me. With the graphics subsystem in the kernel proper it's even less of a 'microkernel' than a traditional UNIX monolith. After all many critical system functions do take place in user land daemons in a traditional UNIX kernel. I can't really see a difference there. Especially if one compares with a proper microkernel, like QNX, VSTA, L3 or the like.
Stefan Axelsson
The context switches occur when entering or leaving kernel space. If one were to remove the network layer completely then what I said earlier applies (I assume thats what the poster was implying). If you were to retain the network layer and move the X starting at the initial socket interface into the kernel you would save on 2 context switches per call (assuming best case scenario). The penalty however would be extreme in the sense that X would become essentially as difficult to maintain and debug as kernel-space device drivers. Much worse actually since the X server is much more complex then any driver and lack of any memory separation would make X extremely dangerous to the rest of the kernel and introduce whole new class of security issues.
This whole discussion is almost pointless anyhow since the context switches in X even with the network layer constitute minimal overhead. Contrary to the popular belief, context switches, unless used in insane ways, do not introduce significant performance problems. Just about any application makes hundreds of them per second since any disk or network or terminal I/O for example requires them.
What most opponents of X take issue against is the network layer. And it is precisely the network layer that makes X a killer enterprise system. Also on a local socket the overhead is truly minimal since the kernel does "copy-in-place" transfers. As many other people here point out the preceived performance "problem" with X is in fact a result of sub-par performance of complex GUI toolkits found in behemoth environments like KDE or GNOME with feature-sets so complex that they come with their own distributed common object architectures like DCOM. X gets blamed for their poor performance, and no amount of pointing out that much cleaner X applications run with lightning speeds on the same very computers and even over the wire using X networking layer seems to convince the opponents. So we end up with positively looney ideas like moving X to the kernel or to video card hardware etc, while all along KDE and GNOME get bigger and more convoluted and consume more and more system resources performing vast amounts of redudnant and inefficient X operations (mostly repetetive bitmap transfers).
X has its own problems, mostly related to legacy architectural decisions and font handling but these are being solved in their own ways and in the long run the X system will deliver all the fancy aye candy at a very good performance while retaining its great advantage of built-in networking layer.
Well, X with twm is still a slow beast. Blaming KDE
or Gnome is convinient but misleading. All I want is
for X to be real time, i.e. a guarantee that when
I drag a window there is no lag. Yes it would be
nice also to have GUI toolkits to be real time as in
when I click a button visual feedback happens as I
click. Right now this is more or less the case but
latency is not guaranteed and sometimes you notice.
I don't care what's the GUI layer(s), I merely care
that they are either fast enough or have high
enough priority to guarantee impereptible latency
on most complex operations. And no, low latency
patches are no substitute for hard real time.
My experience (and it would seem many others here on slashdot feel the same) does not confirm what you are describing. I use WindowsMaker and experience no lag of any sort on any of my systems. Window dragging/resizing even with the contents being redrawn is snappy and I have absolutely no complaints about that part. Some applications (like Mozilla) are slower to start then others but thats due to their massive use of shared libraries which are being loaded at that time. So I am not sure what are you talking about, perheaps there is something wrong with your X configuration or the hardware you are using is not fully supported. In the latter case X falls back on non-accelerated blitting mode which would significantly reduce speed of drawing of any sort of items on the screen. This would be equivalent of using, say, Windows XP with "Generic VGA" compatibility device drivers instead of the proper drivers for the hardware and which would make XP draw windows really slowly just like a non-accellerated X server would.
I dunno. Often, when I have a computation running
and taking near 100% CPU or when a few processes
have entered an infinit loop, then I start seeing
X slowing down. Is it too much to ask that my GUI
be either slim enough to run comfortably on 1% of
CPU at complex tasks or be entirely off my main CPU?
That has nothing to do with X but everything to do with the 2.4 and earlier kernels task scheduler. A major effort went into the 2.6 task scheduler to lessen this problem significantly. Basically the task scheduler is unable to manage the interactivity levels that are expected by the users of GUI interfaces like X. This problem would have occured should you run on a text-only terminal although would be less visible since terminal screen updates are much lesser then those that X has to perform in graphical mode. So as I suspected we are talking about two different things and as usual X gets the blame for a problem with some completely unrelated sub-system. Further on this note, Windows ilk of OS' has a special hack in the task scheduler which is intended to make the top level windows appear much more interactive by artificially increasing their associated tasks' scheduling priority which creates an appearance of greater interactivity under heavy CPU or I/O loads.