I think you need to reread what I said. I wasn't suggesting that ships plug into the grid, I was stating that land installations simply plug into the grid, but that ships have to generate their own power.
More than likely they'll tow her out to location, anchor her 500 different ways, and use generators combined with solar or some other energy source to keep her systems going.
Is there an echo in here?
I wouldn't be surprised if the engines get stripped out of the ship altogether. Ships that don't go anywhere get emasculated on a regular basis - witness the USS Intrepid, which is literally bolted to the harbor bottom.
The Intrepid is a Museum ship that will be forever docked. I seriously doubt they'd remove the engines on a ship anchored several miles offshore. Any time the ship needed to change its position (which it would need to do for the occasional dockyard maintenece), they'd need to call a tug out to pull her in. Not to mention braving bad weather in a boat with nothing but an anchor holding it in place...
Umm... no. The ship, being of US registry, can be confiscated and searched by US authorities. Not to mention that the US *has* enforced its borders beyond its 3 mile claim in the past.
Actually, each country is different. The US claims 3 miles, some nations claim up to 12. 7s and google told me that.
Tell that to the US Third Fleet as a full carrier group pulls along side and warns you to prepare to be boarded. With about 200 planes, 180+ missiles, and 5" deck guns pointed your way, you're lible to listen.
Of course, that's only if we want to make them shit their pants. Otherwise the First Fleet (i.e. The Coast Guard) has more than enough power to raid and shutdown this operation. If I were them, I would hedge my political connections *very* carefully.
BTW, this is not in windows. This is on X11/linux, and X11 allows popping windows over the top fullscreen window.
Ah, ok. In Windows that's a bug. In X11, well, technically it isn't designed for playing games in the first place.:-) However, I thought that games were supposed to set the "Always on top" flag. Granted, the window manager could ignore it, but the feature does exist and is supposed to be honored.
That was my thought as well, but then I realized that they're going to need a LOT of diesel just to keep the lights on. On land, you'd sinply run off the grid. But on a boat, their entire power capacity is going to be supplied by the ships engines or generators. Those aren't quite as power hungry as when the ship is under power, but with the number of electronic toys they're going to need, it's not going to be cheap either.
This is probably the oppurtunity of a life time for a lot of people to get out of their home country for a while and see the U.S. a little bit.
And what VISA are they going to use to gain enterance to the US? The article contradicts itself on this point:
"...and run a 24-hour-a-day programming shop, thereby avoiding H-1B visa hassles while still exploiting offshore labor cost..."
-verus-
"Staff can make the three-mile voyage into town in their off hours by calling a water taxi."
I smell something rotten here. Specifically the usage of the word "staff". As in "American Employees can go ashore when they need a break." Gee, thanks.
Ok, technically it's not supposed to do that. The game should have complete control over the screen and the GDI should be detached. Sounds like you're exploiting a bug.:-)
(And yes, it is a bug. Specifically an undesirable side effect of sharing the same screen space between the GDI and DirectX subsystems. Microsoft's literature tends to caution against accidental GDI calls when in DirectX modes.)
Dumbest idea EVER. I do not understand this infatuation with outsourcing professional workers. You can't tell me it's anywhere near as cost effective as they're making it out to be. (My own experience says otherwise.) I smell another crash of DotCom proportions...
But if they're going to do this thing, they should at least do it in style. By utilizing an inexpensive aircraft carrier they could at least send these people home for occasional weekends and vacations. Under the proposed plan, they're basically prisoners on the ship unless they can manage to get a Visa to enter the country. Which, of course, negates the entire point of not messing with H1-Bs. And how do they think the government is going to react to having these people parked right off our shore? (Hmm... maybe they could refit the guns on the old carrier to keep the coast guard off their backs.)
Well yes, that should interrupt a game, but I'm afraid that it won't under pretty much any system. You have to listen for the IM sound to get played through the mixer, then pause and minimize your game. Nothing different from what I'm proposing.
Just to stuff in one last comment, the whole graphical tty business is cool, but I still think that a single manager is preferable due to the critical notification.
I'm still not clear on what sort of critical notification should interrupt a game. Unless the system is about to blow up (the infamous "the processor is on fire" interrupt;-)), there's really nothing that won't wait for you to exit your game (or hit the key combo to switch the screen back to check). The only thing that *might* be important enough (and I stress *might*) would be an OS/X11 level event. In that case you don't need to check, just tell the OS "I want to be in charge." A bit like setting the active window in Windows.
This is the reason why I am watching kdrive very closely, as it has the potential to become the properly architectured X11.
People were argueing with you about X11's display hotplugging. I thought everyone knew it sucked.
Oh, they know it sucks. I was getting *blamed* for it because of a comment I made about X's improved ability to handle pluggable hardware. Yeash, people can be testy about this stuff.
However the bigger problems are that the driver support still sucks.
But... it's something that could more easily be focused on if the driver was separated from X.
It is an application that goes over X to switch a mode in a video card, without X realizing the problem. Unfortunately X sometimes reacts poorly to the change.
Well, there's a few points on this front:
1. A lower level driver would have to define event for when screen mode and geometry changes happen. Any X server built on top should listen for those changes and pass the information down to the root window to do something about. (Presumably, the root window is the Window Manager, which would then take care of moving any windows that need to be moved.)
2. Applications shouldn't be changing the screen mode of X. Remember my point about changing virtual terminals? Any program that wants to have exclusive access to the screen should be in a separate TTY. That way the screen mode issues don't matter, because the mode will be restored when the X server is active. This gets into your next point of:
My point: the ability to switch displays should only be allowed by the driver which currently owns the terminal. That means if X is running, X is the only thing that is allowed to make the call.
Which is fine. X should control its tty with an iron fist. But Quake III should also be able to control its TTY with an iron fist. Since both can't occupy the screen at the same time (which is what actually happens today), there is no issue.
Think the current terminal nightmare: application crashes leaving terminal in raw mode, application now in control of the terminal does not see the problem causing the terminal to become useless.
That was one of Packard's points in his article. If the OS controlled the graphics hardware, then it would be able to detect this situation. Once it detects that the program has crashed, it closes the TTY and pops the next one off the stack. Life continues on.
PS> Agree with you? I did not know we were arguing?
Sorry, just me being flippant again. I thought the whole big head comment would tip you off.:-)
Nice link. Packard basically blames all of X's woes on the architectural problems I was describing, and then backs up his statement with common examples such as display hotplugging. (A salient point that I was taking undeserved flak for from another poster in this topic.)
So, does everyone agree with me now?;-) (Me? Big head? Never.)
Ok. So what you are basically looking for is an api for X to stop sending stuff to the video processing code, and let the programs do it directly. Hmm..there is some point to that statement, but then these video processing drivers will need to have a way to translate things like xvideo->video card specific calls. In other words, all the drivers will need to present the same interface.
This is mostly true. The exception is that extensions like XVideo would be potentially working with both the X-Windows APIs (I'm about to use this area of the screen here) and separate video decompression drivers (ok graphics card, X11 says I can stick the video here). If support is missing in some area, then you simply couldn't install the extension.
To some extent this is already done in X. The only thing that X offers on top of that are windowing primitives, and a level of indirection for the desktop (great for xinerama, virtual desktop, etc).
Well, that's the problem. X combines the two concepts into one. Look at how Windows handles it:
Video Drivers -> HAL -> GDI -> Win32 -> MFC
The clear layers of separation help keep everything in line and ensure that a given area doesn't overstep its bounds. In the X world, everything from part of Win32 on down is mixed up in one big glob.
The only thing that separating the hardware specific parts from X will get you is an ibility to use those drivers outside of X. I do not see how that would suddenly help the situation.
It would help from a focus perspective. If the drivers were moved to the OS level, then the focus would be on defining *good* interfaces for things like changing the screen mode and giving device caps. Right now, no one can fix those issues because they're all tied up in other areas of the server. Once you move hardware out of the domain of the X server, the code suddenly becomes leaner, and FAR more portable.
The thing is, X is not mucking around that level. The driver part of X is mucking around the hardware level. The rest of X is completely hardware independent.
Which is again my point. Why is X managing hardware? That's the job of the OS.
So basically what you are suggesting is to move the X video drivers out of X, and make them separate.so with a more or less standardized interface based on X extensions. In other words if your video card supports video capabilities, then the driver will provide XVIDEO. If it has GL support, then it will provide GLX, etc. All of these interfaces should follow some spec.
Bingo.:-)
Do note however, that this will probably not be kernel code. A lot of capabilities will probably require some emulation, as no card will support everything in GPU. And having that much code in the kernel is scary.
Of course not. NVidia's drivers aren't part of the kernel on Windows or Linux. They're kernel mode drivers. The higher level APIs would of course run in usermode, but the option could be later added for kernel mode for the performance junkies. (e.g. Solaris provides this option for high performance workstations.)
There are a few tricky things. First, there is a similar issue as that encountered by the terminal: who owns the screen.
That's easy. Who owns the screen now? Whoever last requested it, or whoever the user has forced. If I run X, does X not grab the screen? But what happens if I hit CTRL+F1? Now who owns the screen? This is the same thing, with the exception that more than one graphical TTY can exist.
However, the realist in me suggests that 99% of the time you want a manager anyway.
Even if it were 100% of the time, I think it still makes sense to split these two components. The graphics driver and the windowing system are two separate layers that shouldn't be forced together. All one has to do to convince themselves is run an X server such as WeirdX *inside* an X server such as X.org.
I despise the icon zooming feature not because it's flashy or eats CPU/GPU, but becaue it's awful from a usability standpoint.
I'll never understand why people don't like the dock. I think the feature is excellent as it allows an otherwise cluttered area to become useful. Just think of Windows. How many times do you have no idea where the heck your program is because all of the taskbar buttons look like "[tiny icon]..."? And I use a double-tall taskbar!
In any case, you can turn the effect off. Just adjust the dock zoom setting to zero. You can also set the initial size of the dock itself.
This could be achieved using other methods. Programs have been popping up windows to allow you to edit preferences and other data for quite some time now. There's no reason that a sheet couldn't drop down from the window title bar or pop up from pressing a button.
I was wondering if someone was going to mention that. Thinking like a Mac user, eh?:-)
The reason why the notes on the back of the window make more sense, is that it is a far more natural position for them to be. e.g. When you look at a movie or game in the store, what the first thing you do after you pick it up? That's right, look on the back!
The alternative methphor would be akin to having a special pocket on every product that people are somehow trained to check. Not very natural as things stand today.
And while we're on the subject of hardware that no-one has yet, why don't we just use a neuro-interface to transmit the computer's interface directly into the users brain using our 50Ghz 20 CPU superduperwoopercomputer.:D
Ok, this is why we're on the subject of UI Research. The tabletop interface may not be commercially available yet (otherwise it wouldn't be research), but it is something that exists today and can be viewed in the video.
Do you mean separate the device drivers from the X11 libraries? Separate it from the window/keyboard events?
No, not quite. Yes, the driver needs to be in ther kernel. But the API layer above that should provide exclusive access to the video card services. The X11 system can then build on top of that, but something else (e.g. a video game) can request that X11 temporarily relinquish control.
I am confused by what you are trying to say. The graphical system is a shared resource. X11 becomes the manager of that resource, and naturally does not want any other people trying to simultaneously manage it (SuperVGA).
You've just stated the problem. X11 is controlling the graphics system. That's a problem, because there's no way to do anything graphical *without* X11. This particularly sucks as X11 support for things as simple as changing the screen mode or reporting hardware capabilities, well, sucks.
The same on linux, it simply switches the vt, hence the updates to framebuffer from a different vt are ignored.
I'm going to ignore the lameness of this statement.
The correct way of doing this is closer to what the DRI and nvidia people are doing. Stuff the hardware specific things into the kernel driver, and pass a more machine independent calls via a device file into the user mode. Then in the user mode, more advanced processing can be done (driver specific gl implementation, driver specific video implemenation, etc).
Now you've got it! The trick is that we don't need X mucking things up at this level. X should be one step above. If X is directly managing hardware, then it's doing something wrong.
Also, there seems to be some awfully weird licensing kind of stuff going on there lately... The developers have been claiming that someone "stole" the source code to Y, and warning people against "pirated" versions... That sent all kinds of red flags up in my head. And here is the archive of the discussion of the "stolen" source code (see Y-windows update)
Because you called output device hotplugging in X useless.
Ah. I was trying to be funny. As in "what is all this useless crap hooked up to my computer!" I didn't intend for my comment to be taken so seriously.:-)
The hardware stuff (the video drivers) are already partially in the kernel
Ehh... sort of. A "standard" X11 driver sits outside the kernel, but controls the device. The trick that NVidia has been pulling (which I think is true of ATI as well) is that they've been taking their Windows Driver code, compiling it to a Linux Driver, then writing a glue driver for X11 to load.
In short, all the groundwork has been laid, but the XFree86/X.org servers continue to think they should be controlling the hardware.
Another intersting point is that FreeBSD controls most of its input hardware (e.g. the mouse), and X11 merely talks to the BSD drivers. That's the way it *should* work, but that hasn't quite percolated through to the Linux guys yet.
Completely splitting X into a hardware support/renderer infrastructure part and a windowing system part sounds like a great idea to me, too. And then, making the renderer accept vector data and use the GPU to process it would be awesome. OS X awesome.
actually X is treated as the video driver for the most part.
Which is a problem. Video Card support is a completely different thing from Window Management. They are related, but only in that the latter builds upon the former.
Me, I like having the most problematic and changing driver put one layer above the kernal. That way, a crash in it doesn't barf everything else.
What do you *mean* by this? Barfing in the hardware can crash a system just as surly as a kernel mode exception.
If you mean that the Windowing System should be in the user-mode area above the driver layer, then I agree with you.
Screw you. Lack of proper X support for switching between my laptop's LCD and external DVI output is my biggest problem with Linux right now.
Oooookkkaaayyy... And you are swearing at me for this because... ??? It's not like I wrote X-Windows. I just commented that it's gotten a lot better than it used to be. Hotplugging video monitors IS a big deal, but otherwise X tends to do reasonably well at cold-plugging devices.
Of course, the *correct* solution would be to move all the hardware stuff to the kernel and allow the X-Server to just do the Windowing System. This is the way that commercial Unixes are implemented, and it works quite well. Unfortunately, as you said, the Linux kernel hotplug support is dicey as well. Works quite well on FreeBSD, though.:-D
What exactly has sun done with window shading that's so evolutionary even? I've had that for years.
Not the Looking Glass style, you haven't. Instead of folding the window up into the title bar, the desktop allows you to shift it ro the side as if it were a book on a shelf. You can see the title on the spine, as well as a slight amount of the window's front. And since the window is on the side, it's completely out of the primary work area!:-)
Mod parent up. After reading the paper I was left to scratch my head at the conclusion that "marking software is largely ineffective", yet we should "mark software to bring it more in line with physical invention patents".
The author does an excellent job shedding light on the difficulty of "process" and software patents, but his solution leaves much to be desired.
You forgot the Dock effect, which DOES actually improve usability. There's also a neat dropshadow trick that improves the user's ability to visually figure out what window is active. There's also the Expose effect which helps you dig out the window you want from everything that's open.
In other words, OS X leverages its OpenGL abilities in a rather sneaky fashion. By doing this, it improves the overall experience without screaming the features in your face.
Did I say I was dissatisified with X? No? So you ASSUMED I was dissatisfied with X. Hint: Assume makes an ASS out of U and ME.
The only point I'm being critical of is the amount of fooling around that has gone into adding OpenGL features to XFree86/X.org. The XGL extensions have been in the works for years and (as far as I can tell) they should have just been polished off and plugged into X years ago. It doesn't matter that nothing immediately uses the features. Get the features there, and allow the KDE, GNOME, XCFE, and other projects work out what they want to do with the features.
Then there's Enlightenment. *sigh* For a *decade* now it's been able to do better eye candy than everyone else. But instead of leveraging that in some useful way, they keep messing with it. Every time Enlightenment gets somewhere, they notice the "next cool idea" in UI eye candy and run off to redesign the system around it. Meanwhile, the rest of the world never manages to obtain a release.
Slashdot Mirror
I think you need to reread what I said. I wasn't suggesting that ships plug into the grid, I was stating that land installations simply plug into the grid, but that ships have to generate their own power.
More than likely they'll tow her out to location, anchor her 500 different ways, and use generators combined with solar or some other energy source to keep her systems going.
Is there an echo in here?
I wouldn't be surprised if the engines get stripped out of the ship altogether. Ships that don't go anywhere get emasculated on a regular basis - witness the USS Intrepid, which is literally bolted to the harbor bottom.
The Intrepid is a Museum ship that will be forever docked. I seriously doubt they'd remove the engines on a ship anchored several miles offshore. Any time the ship needed to change its position (which it would need to do for the occasional dockyard maintenece), they'd need to call a tug out to pull her in. Not to mention braving bad weather in a boat with nothing but an anchor holding it in place...
Umm... no. The ship, being of US registry, can be confiscated and searched by US authorities. Not to mention that the US *has* enforced its borders beyond its 3 mile claim in the past.
Actually, each country is different. The US claims 3 miles, some nations claim up to 12. 7s and google told me that.
Tell that to the US Third Fleet as a full carrier group pulls along side and warns you to prepare to be boarded. With about 200 planes, 180+ missiles, and 5" deck guns pointed your way, you're lible to listen.
Of course, that's only if we want to make them shit their pants. Otherwise the First Fleet (i.e. The Coast Guard) has more than enough power to raid and shutdown this operation. If I were them, I would hedge my political connections *very* carefully.
BTW, this is not in windows. This is on X11/linux, and X11 allows popping windows over the top fullscreen window.
:-) However, I thought that games were supposed to set the "Always on top" flag. Granted, the window manager could ignore it, but the feature does exist and is supposed to be honored.
Ah, ok. In Windows that's a bug. In X11, well, technically it isn't designed for playing games in the first place.
That was my thought as well, but then I realized that they're going to need a LOT of diesel just to keep the lights on. On land, you'd sinply run off the grid. But on a boat, their entire power capacity is going to be supplied by the ships engines or generators. Those aren't quite as power hungry as when the ship is under power, but with the number of electronic toys they're going to need, it's not going to be cheap either.
This is probably the oppurtunity of a life time for a lot of people to get out of their home country for a while and see the U.S. a little bit.
And what VISA are they going to use to gain enterance to the US? The article contradicts itself on this point:
"...and run a 24-hour-a-day programming shop, thereby avoiding H-1B visa hassles while still exploiting offshore labor cost..."
-verus-
"Staff can make the three-mile voyage into town in their off hours by calling a water taxi."
I smell something rotten here. Specifically the usage of the word "staff". As in "American Employees can go ashore when they need a break." Gee, thanks.
Ok, technically it's not supposed to do that. The game should have complete control over the screen and the GDI should be detached. Sounds like you're exploiting a bug. :-)
(And yes, it is a bug. Specifically an undesirable side effect of sharing the same screen space between the GDI and DirectX subsystems. Microsoft's literature tends to caution against accidental GDI calls when in DirectX modes.)
Dumbest idea EVER. I do not understand this infatuation with outsourcing professional workers. You can't tell me it's anywhere near as cost effective as they're making it out to be. (My own experience says otherwise.) I smell another crash of DotCom proportions...
But if they're going to do this thing, they should at least do it in style. By utilizing an inexpensive aircraft carrier they could at least send these people home for occasional weekends and vacations. Under the proposed plan, they're basically prisoners on the ship unless they can manage to get a Visa to enter the country. Which, of course, negates the entire point of not messing with H1-Bs. And how do they think the government is going to react to having these people parked right off our shore? (Hmm... maybe they could refit the guns on the old carrier to keep the coast guard off their backs.)
Did I mention that this is a dumb idea?
An IM from a girl I asked out. ;-)
:-D
LOL!
Well yes, that should interrupt a game, but I'm afraid that it won't under pretty much any system. You have to listen for the IM sound to get played through the mixer, then pause and minimize your game. Nothing different from what I'm proposing.
Just to stuff in one last comment, the whole graphical tty business is cool, but I still think that a single manager is preferable due to the critical notification.
;-)), there's really nothing that won't wait for you to exit your game (or hit the key combo to switch the screen back to check). The only thing that *might* be important enough (and I stress *might*) would be an OS/X11 level event. In that case you don't need to check, just tell the OS "I want to be in charge." A bit like setting the active window in Windows.
:-)
I'm still not clear on what sort of critical notification should interrupt a game. Unless the system is about to blow up (the infamous "the processor is on fire" interrupt
This is the reason why I am watching kdrive very closely, as it has the potential to become the properly architectured X11.
True 'dat.
People were argueing with you about X11's display hotplugging. I thought everyone knew it sucked.
:-)
Oh, they know it sucks. I was getting *blamed* for it because of a comment I made about X's improved ability to handle pluggable hardware. Yeash, people can be testy about this stuff.
However the bigger problems are that the driver support still sucks.
But... it's something that could more easily be focused on if the driver was separated from X.
It is an application that goes over X to switch a mode in a video card, without X realizing the problem. Unfortunately X sometimes reacts poorly to the change.
Well, there's a few points on this front:
1. A lower level driver would have to define event for when screen mode and geometry changes happen. Any X server built on top should listen for those changes and pass the information down to the root window to do something about. (Presumably, the root window is the Window Manager, which would then take care of moving any windows that need to be moved.)
2. Applications shouldn't be changing the screen mode of X. Remember my point about changing virtual terminals? Any program that wants to have exclusive access to the screen should be in a separate TTY. That way the screen mode issues don't matter, because the mode will be restored when the X server is active. This gets into your next point of:
My point: the ability to switch displays should only be allowed by the driver which currently owns the terminal. That means if X is running, X is the only thing that is allowed to make the call.
Which is fine. X should control its tty with an iron fist. But Quake III should also be able to control its TTY with an iron fist. Since both can't occupy the screen at the same time (which is what actually happens today), there is no issue.
Think the current terminal nightmare: application crashes leaving terminal in raw mode, application now in control of the terminal does not see the problem causing the terminal to become useless.
That was one of Packard's points in his article. If the OS controlled the graphics hardware, then it would be able to detect this situation. Once it detects that the program has crashed, it closes the TTY and pops the next one off the stack. Life continues on.
PS> Agree with you? I did not know we were arguing?
Sorry, just me being flippant again. I thought the whole big head comment would tip you off.
Nice link. Packard basically blames all of X's woes on the architectural problems I was describing, and then backs up his statement with common examples such as display hotplugging. (A salient point that I was taking undeserved flak for from another poster in this topic.)
;-) (Me? Big head? Never.)
So, does everyone agree with me now?
Ok. So what you are basically looking for is an api for X to stop sending stuff to the video processing code, and let the programs do it directly. Hmm..there is some point to that statement, but then these video processing drivers will need to have a way to translate things like xvideo->video card specific calls. In other words, all the drivers will need to present the same interface.
.so with a more or less standardized interface based on X extensions. In other words if your video card supports video capabilities, then the driver will provide XVIDEO. If it has GL support, then it will provide GLX, etc. All of these interfaces should follow some spec.
:-)
This is mostly true. The exception is that extensions like XVideo would be potentially working with both the X-Windows APIs (I'm about to use this area of the screen here) and separate video decompression drivers (ok graphics card, X11 says I can stick the video here). If support is missing in some area, then you simply couldn't install the extension.
To some extent this is already done in X. The only thing that X offers on top of that are windowing primitives, and a level of indirection for the desktop (great for xinerama, virtual desktop, etc).
Well, that's the problem. X combines the two concepts into one. Look at how Windows handles it:
Video Drivers -> HAL -> GDI -> Win32 -> MFC
The clear layers of separation help keep everything in line and ensure that a given area doesn't overstep its bounds. In the X world, everything from part of Win32 on down is mixed up in one big glob.
The only thing that separating the hardware specific parts from X will get you is an ibility to use those drivers outside of X. I do not see how that would suddenly help the situation.
It would help from a focus perspective. If the drivers were moved to the OS level, then the focus would be on defining *good* interfaces for things like changing the screen mode and giving device caps. Right now, no one can fix those issues because they're all tied up in other areas of the server. Once you move hardware out of the domain of the X server, the code suddenly becomes leaner, and FAR more portable.
The thing is, X is not mucking around that level. The driver part of X is mucking around the hardware level. The rest of X is completely hardware independent.
Which is again my point. Why is X managing hardware? That's the job of the OS.
So basically what you are suggesting is to move the X video drivers out of X, and make them separate
Bingo.
Do note however, that this will probably not be kernel code. A lot of capabilities will probably require some emulation, as no card will support everything in GPU. And having that much code in the kernel is scary.
Of course not. NVidia's drivers aren't part of the kernel on Windows or Linux. They're kernel mode drivers. The higher level APIs would of course run in usermode, but the option could be later added for kernel mode for the performance junkies. (e.g. Solaris provides this option for high performance workstations.)
There are a few tricky things. First, there is a similar issue as that encountered by the terminal: who owns the screen.
That's easy. Who owns the screen now? Whoever last requested it, or whoever the user has forced. If I run X, does X not grab the screen? But what happens if I hit CTRL+F1? Now who owns the screen? This is the same thing, with the exception that more than one graphical TTY can exist.
However, the realist in me suggests that 99% of the time you want a manager anyway.
Even if it were 100% of the time, I think it still makes sense to split these two components. The graphics driver and the windowing system are two separate layers that shouldn't be forced together. All one has to do to convince themselves is run an X server such as WeirdX *inside* an X server such as X.org.
I despise the icon zooming feature not because it's flashy or eats CPU/GPU, but becaue it's awful from a usability standpoint.
:-)
:D
I'll never understand why people don't like the dock. I think the feature is excellent as it allows an otherwise cluttered area to become useful. Just think of Windows. How many times do you have no idea where the heck your program is because all of the taskbar buttons look like "[tiny icon]..."? And I use a double-tall taskbar!
In any case, you can turn the effect off. Just adjust the dock zoom setting to zero. You can also set the initial size of the dock itself.
This could be achieved using other methods. Programs have been popping up windows to allow you to edit preferences and other data for quite some time now. There's no reason that a sheet couldn't drop down from the window title bar or pop up from pressing a button.
I was wondering if someone was going to mention that. Thinking like a Mac user, eh?
The reason why the notes on the back of the window make more sense, is that it is a far more natural position for them to be. e.g. When you look at a movie or game in the store, what the first thing you do after you pick it up? That's right, look on the back!
The alternative methphor would be akin to having a special pocket on every product that people are somehow trained to check. Not very natural as things stand today.
And while we're on the subject of hardware that no-one has yet, why don't we just use a neuro-interface to transmit the computer's interface directly into the users brain using our 50Ghz 20 CPU superduperwoopercomputer.
Ok, this is why we're on the subject of UI Research. The tabletop interface may not be commercially available yet (otherwise it wouldn't be research), but it is something that exists today and can be viewed in the video.
Do you mean separate the device drivers from the X11 libraries? Separate it from the window/keyboard events?
No, not quite. Yes, the driver needs to be in ther kernel. But the API layer above that should provide exclusive access to the video card services. The X11 system can then build on top of that, but something else (e.g. a video game) can request that X11 temporarily relinquish control.
I am confused by what you are trying to say. The graphical system is a shared resource. X11 becomes the manager of that resource, and naturally does not want any other people trying to simultaneously manage it (SuperVGA).
You've just stated the problem. X11 is controlling the graphics system. That's a problem, because there's no way to do anything graphical *without* X11. This particularly sucks as X11 support for things as simple as changing the screen mode or reporting hardware capabilities, well, sucks.
The same on linux, it simply switches the vt, hence the updates to framebuffer from a different vt are ignored.
I'm going to ignore the lameness of this statement.
The correct way of doing this is closer to what the DRI and nvidia people are doing. Stuff the hardware specific things into the kernel driver, and pass a more machine independent calls via a device file into the user mode. Then in the user mode, more advanced processing can be done (driver specific gl implementation, driver specific video implemenation, etc).
Now you've got it! The trick is that we don't need X mucking things up at this level. X should be one step above. If X is directly managing hardware, then it's doing something wrong.
Also, there seems to be some awfully weird licensing kind of stuff going on there lately... The developers have been claiming that someone "stole" the source code to Y, and warning people against "pirated" versions... That sent all kinds of red flags up in my head. And here is the archive of the discussion of the "stolen" source code (see Y-windows update)
Dude, check the date.
Because you called output device hotplugging in X useless.
:-)
:-)
Ah. I was trying to be funny. As in "what is all this useless crap hooked up to my computer!" I didn't intend for my comment to be taken so seriously.
The hardware stuff (the video drivers) are already partially in the kernel
Ehh... sort of. A "standard" X11 driver sits outside the kernel, but controls the device. The trick that NVidia has been pulling (which I think is true of ATI as well) is that they've been taking their Windows Driver code, compiling it to a Linux Driver, then writing a glue driver for X11 to load.
In short, all the groundwork has been laid, but the XFree86/X.org servers continue to think they should be controlling the hardware.
Another intersting point is that FreeBSD controls most of its input hardware (e.g. the mouse), and X11 merely talks to the BSD drivers. That's the way it *should* work, but that hasn't quite percolated through to the Linux guys yet.
Completely splitting X into a hardware support/renderer infrastructure part and a windowing system part sounds like a great idea to me, too. And then, making the renderer accept vector data and use the GPU to process it would be awesome. OS X awesome.
Glad you agree.
actually X is treated as the video driver for the most part.
Which is a problem. Video Card support is a completely different thing from Window Management. They are related, but only in that the latter builds upon the former.
Me, I like having the most problematic and changing driver put one layer above the kernal. That way, a crash in it doesn't barf everything else.
What do you *mean* by this? Barfing in the hardware can crash a system just as surly as a kernel mode exception.
If you mean that the Windowing System should be in the user-mode area above the driver layer, then I agree with you.
Screw you. Lack of proper X support for switching between my laptop's LCD and external DVI output is my biggest problem with Linux right now.
:-D
Oooookkkaaayyy... And you are swearing at me for this because... ??? It's not like I wrote X-Windows. I just commented that it's gotten a lot better than it used to be. Hotplugging video monitors IS a big deal, but otherwise X tends to do reasonably well at cold-plugging devices.
Of course, the *correct* solution would be to move all the hardware stuff to the kernel and allow the X-Server to just do the Windowing System. This is the way that commercial Unixes are implemented, and it works quite well. Unfortunately, as you said, the Linux kernel hotplug support is dicey as well. Works quite well on FreeBSD, though.
Is there a benefit to a vertical strip rather than a horizontal strip?
I would think that the benefits would be obvious:
1. Moves the shaded window out of the primary work area automatically.
2. Allows you to partially see any activity that may be going on in the shaded window.
What exactly has sun done with window shading that's so evolutionary even? I've had that for years.
:-)
Not the Looking Glass style, you haven't. Instead of folding the window up into the title bar, the desktop allows you to shift it ro the side as if it were a book on a shelf. You can see the title on the spine, as well as a slight amount of the window's front. And since the window is on the side, it's completely out of the primary work area!
Mod parent up. After reading the paper I was left to scratch my head at the conclusion that "marking software is largely ineffective", yet we should "mark software to bring it more in line with physical invention patents".
The author does an excellent job shedding light on the difficulty of "process" and software patents, but his solution leaves much to be desired.
You forgot the Dock effect, which DOES actually improve usability. There's also a neat dropshadow trick that improves the user's ability to visually figure out what window is active. There's also the Expose effect which helps you dig out the window you want from everything that's open.
In other words, OS X leverages its OpenGL abilities in a rather sneaky fashion. By doing this, it improves the overall experience without screaming the features in your face.
Did I say I was dissatisified with X? No? So you ASSUMED I was dissatisfied with X. Hint: Assume makes an ASS out of U and ME.
The only point I'm being critical of is the amount of fooling around that has gone into adding OpenGL features to XFree86/X.org. The XGL extensions have been in the works for years and (as far as I can tell) they should have just been polished off and plugged into X years ago. It doesn't matter that nothing immediately uses the features. Get the features there, and allow the KDE, GNOME, XCFE, and other projects work out what they want to do with the features.
Then there's Enlightenment. *sigh* For a *decade* now it's been able to do better eye candy than everyone else. But instead of leveraging that in some useful way, they keep messing with it. Every time Enlightenment gets somewhere, they notice the "next cool idea" in UI eye candy and run off to redesign the system around it. Meanwhile, the rest of the world never manages to obtain a release.