Lucas isn't really losing anything to pirates. He's not earning it, which is different.
Let's suppose Lucas was in the business of selling DVDs. A disk costs say, $10 to produce and sells for $20 (not real numbers, but will work for the sake of example). If $20M was needed to produce the movie, then 2M disks need to be sold to pay for the production costs. Say he sells 3M disks, so now he's $10 M richer than when he began.
Now, the difference:
If people stole 2M disks, then Lucas would face a $20M loss due to the money spent to produce disks that didn't result in any benefit. Now overall he's $10M poorer, and would now be in serious trouble.
However, if 1M people copied the DVD from their friends, watched it at a friends' house, or downloaded it, Lucas would still have his $10M. Hence he wouldn't have lost anything.
Yeah, you can make a nice interface that will make things easier for everyone. But there's also such a thing as an interface for experts.
Interfaces for normal people can be easily found pretty much everywhere. Say, in Windows. MS Paint, Nero, Windows Explorer.
Interfaces for experts: Blender, which looks horrible to a Windows user. Povray, which is even scarier. Command line interfaces. Programs such as mplayer and cdrecord that let you do absolutely everything and have a man page that if printed would be the size of a little book. Specialized management applications that allow a seller to sell really fast because it contains lots of shortcuts and can be all used with the keyboard.
Yes, sometimes you can improve things for everyone. But what you have to understand here is that there IS value in making tools for experts. Povray can't be made into anything that a normal user would call "user friendly" except by making a GUI that will generate the source, but that doesn't mean it's not useful. And sometimes, reaching the largest market is NOT the point.
Freenet has websites, and a message board with Frost. While everything is anonymous it doesn't mean you can't see what's available.
Of course nobody actually knows who downloads what and how much, but there are big lists of websites and such. Although you can hardly call them accurate, since nobody forces anybody to submit their site to the existent indexes.
It's been ages since I last tried Freenet though. The Java server is incredibly annoying, eats tons of RAM and uses a lot of CPU time, and the rest is still very unimpressive. There was Entropy which seemed noticeably smoother, but it had plenty problems of its own, such as a complete lack of security (from what I could see)
A sane OS should do that through a package manager. You can do that easily on any Linux distro without needing any specific support in the application.
I suppose there must be something like that for Windows.
There are no substantiated reports of tarantula bites proving fatal to a human. However, the effects of a tarantula bite are not well known. While the bites of many species are reported to be no worse than a wasp sting, other accounts say these bites are some of the most painful. Because other proteins may get included when a toxin is injected, some individuals may suffer severe symptoms due to allergy rather than poison.
Try running your own mail server some time. You'll notice that all the ones that are currently in use pretty much include their own little programming language. Besides simply reading the mail spool, or sniffing the wire, the server itself could be set up to report anything that looks like a card number.
So, you haven't had any problems yet. That can mean several things. Perhaps nobody is sniffing your current link, or they missed your data, or they got it but didn't use it, or they made a small charge you missed.
However, one thing it doesn't mean is that you're safe. Such a thing can eventually bite you in the ass one day. Of course you could be lucky. But maybe you're not.
Well, it's just the way you write for multiple platforms in pretty much every language. For example, when writing C code you have to have in mind where it's going to run. If you call mmap you have to know that it doesn't exist on Windows, for instance.
A tool that would allow me to specify a list of systems I want to be compatible with and then warns about things that wouldn't work on some of them would actually be very handy.
Having characters that could actually exist in reality is a good thing, IMHO. Some I've seen are so ridiculous that they'd probably have needed magic just to avoid falling from all the weight. I think the current record is held by anime, though. Divergence Eve took it to a really ridiculous level, so that it made it hard watching just because of that. Not that the plot was much better though.
Of course there are also male characters that make Schwarzenegger look like a wimp, but I'd say that's a somewhat different thing since an unrealistic amount of muscle is at least good for something, especially when using a sword is an everyday activity.
It would be kind of obvious to me that if you're going to play with a headset that completely obscures your vision you should do that in some place where there's no danger.
Although I suppose that there's the inconvenience of that not everybody can clear enough space to use a thing like that, unless it can be used sitting on a chair or lying on a bed.
On the contrary. The problem is that the general population had been fed a pipe dream to them, and now are finding it wasn't true. You are right now describing this dream.
I don't need IT people myself. Computers are easy to fix and service. IMHO, the largest problem ironically is with all the usability improvements that have been made.
Try with a comparison: Not so long ago, at a company that sells stuff the computers would run DOS. The disk would be nearly blank, the only thing running on it constantly would be the selling terminal application. It would be efficiently handled with only the keyboard.
Then there would be a big server somewhere handled by a few people without much trouble.
These days, the same computer runs Windows. It faces viruses and worms due to stupidities committed in the name of ease of use. The same application is now a GUI, which makes it really pretty, but adds extra workload in the terms of interface programming, which increases the possible failure mode, and makes automated testing harder.
The whole system is managed by an army of often poorly educated people, who run around the company removing viruses, reinstalling systems, and bitterly complaining that people can't just get into their head that life would be much easier without Outlook.
Not saying that the UI hasn't improved, but I'm pretty sure that for commercial purposes the DOS version of all this stuff was working better.
I think I can see the logic of this - most cops probably don't give a damn about who's selling DVDs, especially since the people who do it (at least here) are usually immigrants (sometimes illegal) who have a very poor knowledge of the language and can't get a job.
Doesn't seem to be much point to me in arresting some guy who managed to get some income that way, when there are much more harmful people out there. I think most cops would be pretty happy with that at least they're not selling drugs or mugging people.
PostgreSQL gotchas are a lot less severe. Most of them result in errors. Some result in bad performance. Only two (date parsing and integer overflow) produce unexpected behavior. Both were fixed.
MySQL gotchas mostly deal with things the database flatly ignores when they don't fit, resulting sometimes in completely wrong information inserted into the database. I don't know about you, but if I say the column is NOT NULL, I definitely expect the attempts to insert a NULL there to fail.
Yeah, things seem to be a lot better in mySQL 5. But it's not stable yet, so these gotchas remain in full effect.
Well, it might just be me, but I definitely don't look forward to hex editing databases when the thing goes down and the whole company grinds to a halt.
Now, I will readily say that mySQL has its uses. If you're simply aiming to logging data it works well. IIRC, that's what it was designed for in the beginning.
But it's still quite far from being a good database. Doing crap like silently ignoring things it doesn't like is one of the things that makes sure I'll never use it for anything important.
That's not a database problem, but an application problem.
In the Windows world you can do this with ADO, for instance. Simply make EVERYTHING go through a stored procedure, then call it always creating a Command object. For example, in VB:
Dim cmd As New ADODB.Command With cmd
Set.ActiveConnection = ServerConnection.CommandText = "do_stuff"
With.Parameters.Append cmd.CreateParameter("foo", adVarChar, adParamInput, 100, Foo).Append cmd.CreateParameter("bar", adVarChar, adParamInput, 100, Bar)
End With.Execute End With
Writing from memory here, so something might be wrong. Anyway, ADO will make sure that everything is properly quoted and it's guaranteed that SQL injection won't work.
Libraries, even big ones like glibc are trivial to test. Games and GUI programs are hard to test, although the components can be if they're well designed. Now, kernels...
The problem with the kernel is that it usually doesn't fail in a predictable way. Most of the problems are not because a syscall does the wrong thing when the parameters are strange, but something like this:
Under a high load, on a SMP system, with heavy filesystem activity there exists a chance of disk corruption/oops if one program does foo on CPU 1 and another does bar on CPU 2. And this happens due to an unlikely to happen issue, so it may take an hour for it to happen.
And this is exactly the kind of issue I had. Everything works fine for a month, then the kernel oopses somewhere after spending 4 hours compiling OpenOffice. Unfortunately, kernels are complicated things, and they tend to fail in more interesting ways than say, compilers.
Uh... and why would you want something as messy as that?
I'll say it again - Unix sockets are one of the basic and most used IPC methods in Unix systems. They do NOT have any noticeable performance impact!
Doing some strange crap with memory wouldn't give you any better performance. Besides it sounds more complicated and a lot less secure.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 2, Informative
Aha, I think I'm starting to understand the way you think at last. But I still don't see the point.
So fine, GGI has the API concept you like so much, and provides an uniform interface to anything. It's modular, cool and shiny. Now, how do you suggest to make a GUI environment following the same system?
The thing you seem to be missing is that X, or its replacement can't be done this way. So okay, we'll try to do it the Windows way. We'll come up with a nice API so that we call CreateWindow, and a window is made. Now, how does that actually happen?
Well, something needs to make that window. It can't be the application. In the case of GGI/SDL it's simply a problem of translating that high level command into pixels on the screen. But that won't work, you need to be able to run several applications on the same desktop. Just letting several processes call functions and draw stuff where they please is only going to create a huge mess or something useful.
So, how do we solve this? We need an arbitrator, which will assign and manage resources. It will ensure whatever is drawn is drawn in the right order. It will keep track of who owns what, and what is where. It will send messages when something of interested happens, like a paint event.
How, this can't go inside this magical library. How would you decide who is in control? That won't work. The arbitrator must be its own entity and dictate the rules to all who use the services it provides. One example of a system like this is the kernel. A program can't just take a 64K chunk of memory starting at 0x80abcdef, hell, no. The program instead calls the kernel and asks: "I want 64K of memory", and the kernel makes sure there's enough of it, that there's some location big enough, and that the program is allowed to have that much. Then, it adds it at the end of the current process, marks it as used, etc.
Same here. Now, who would arbitrate this stuff? Well, one possibility is the kernel. However, as I mentioned already, this won't happen. The kernel developers don't want it and with good reason. They say that if it can go in user space then it will have to go in user space. And since you can perfectly do all this stuff in user space that's where it will be.
Now that we decided it will be in user space, we know it will run as a process. This process manages resources used by other programs, which also are processes. All of this means both the manager and the users need to talk. And how do we do that?
Well, we can pick: Network sockets, unix sockets, shared memory, pipes, queues. I'll leave out queues because I'm not that familiar with them. Pipes are unidirectional. You can get the same effect, just better with unix sockets. Shared memory is great for sharing data but not for implementing protocols. In a complex event based system you need to be able to poke things and to be poked, and networking does this a lot better.
So, we arrive at using networking yet again! Amazing, isn't it?
Whoops. Ignore AC post. But what you're talking about has nothing to do with X.
If there's no X process, then what handles windows? GGI, at least from what I can see on its website is simply an API that provides access to low level functions, pretty much like SDL.
However, I don't see anything in GGI that indicates it has any ability to draw windows, widgets or anything remotely GUI like. If you want a thin layer that lets you draw stuff on the screen you can have it already: The framebuffer.
Enable support, boot with a VESA framebuffer console. Knoppix and many other distributions boot with a VESA console if you don't want to mess with the kernel config. Now write junk to/dev/fb0 to test it. It's currently there and it's usable. But it has nothing to do with windowing systems.
And again, network transparency can't be implemented on top of it because networking is the best IPC mechanism Unix has. It's that simple. If you want to avoid networking the only two options are: X in the kernel, which won't happen. Or application as a module in X, which won't happen either.
Something has to do the GUI stuff. You know, manage the different applications that have access to the same display. Send messages to other applications when appropiate. All of that requires communication. If all this stuff doesn't happen inside one unique process, then that means IPC. And good IPC means networking.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 2, Informative
There is a standard API, the X library. It's not like its interface changes every week or something. I don't know of any applications that talk the X network protocol directly.
So, we have that already. You can change the network protocol, and it IS being changed and extended (Xrandr, Render, Shape, etc). But still, you won't get rid of it.
Please take an Unix book and open it. The classic Unix server either forks or multiplexes to handle multiple clients. If it forks, how does the parent server talk to the children? Usually using shared memory, unix sockets, or pipes. How do the children talk to the clients? Shared memory, network sockets, unix sockets, or pipes.
How does the X server talk to clients? Network sockets, unix sockets or shared memory. There you have it. It works *exactly* the same way virtually every other Unix server works. Nothing at all oddball about it.
And that's what you people don't get - it's not unrelated!
Networking is simply the best way to communicate client and server. You can choose from: Network sockets, unix sockects, pipes, queues and shared memory.
TCP/IP sockets and unix sockets are functionally equivalent (except that the later are only local and have less overhead). Pipes are unidirectional. Queues aren't used much by anything AFAIK, and shared memory is an inconvenient mechanism for exchanging messages.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 3, Informative
Um, and how exactly would you communicate? So, you remove the protocol. And then?
An API is an interface that can be provided by instance for a library. Or it can be provided by an application and used by a library (plugins). But your application isn't *linked* to the X server, so it can't just call functions in it!
The only way to make what you say possible would require each application to be in the same address space as the X server, or for the X server to be in the kernel. Both approaches are quite horrible, IMO.
If the application is a module in the X server then a failure in the application can bring the whole server down. And there's no possible to have applications running with different permissions. Just wonderful, we can go back to MS-DOS levels of security and stability!
X in the kernel is a more viable approach, but forget about it. The kernel developers don't want it there for a good reason, and this isn't exactly removing the network protocol anyway - it's an entirely different system that wouldn't even look remotely like X.
I get the idea that you don't know much about software design. I'll say it again: You can't get rid of network transparency that easily! It has to be there because there has to be some way to talk to the server. I'll try to explain this way. Here are the most common forms of Unix IPC:
Guess what? Except shared memory all of those are pretty much the same as network sockets. RPC (remote procedure call), which is probably what you mean by "API" works through network sockets. And shared memory is inconvenient to use for some things.
So, again: Unless the X server moves into the kernel, or the application moves into the X server there's simply nothing better than networking to make the application and server talk.
I'm absolutely not an expert in the area, but I find the idea of a microkernel pretty cool. But I'm not a fanatic of any of those designs, and will use whatever works for me - currently that's Linux with its monolithic design.
In my rather uninformed opinion, microkernels sound quite complex. Now, I'm not a kernel programmer so I think I'd better leave the actual kernel programmers to debate the pros and cons of the approach.
There's also that drawing a window is a pretty complex thing. I'd say that the overhead needed to send the command is probably pretty much insignificant compared to the time needed to calculate what to draw where, and execute the actual operation.
Slashdot Mirror
Lucas isn't really losing anything to pirates. He's not earning it, which is different.
Let's suppose Lucas was in the business of selling DVDs. A disk costs say, $10 to produce and sells for $20 (not real numbers, but will work for the sake of example). If $20M was needed to produce the movie, then 2M disks need to be sold to pay for the production costs. Say he sells 3M disks, so now he's $10 M richer than when he began.
Now, the difference:
If people stole 2M disks, then Lucas would face a $20M loss due to the money spent to produce disks that didn't result in any benefit. Now overall he's $10M poorer, and would now be in serious trouble.
However, if 1M people copied the DVD from their friends, watched it at a friends' house, or downloaded it, Lucas would still have his $10M. Hence he wouldn't have lost anything.
You're in part correct here.
Yeah, you can make a nice interface that will make things easier for everyone. But there's also such a thing as an interface for experts.
Interfaces for normal people can be easily found pretty much everywhere. Say, in Windows. MS Paint, Nero, Windows Explorer.
Interfaces for experts: Blender, which looks horrible to a Windows user. Povray, which is even scarier. Command line interfaces. Programs such as mplayer and cdrecord that let you do absolutely everything and have a man page that if printed would be the size of a little book. Specialized management applications that allow a seller to sell really fast because it contains lots of shortcuts and can be all used with the keyboard.
Yes, sometimes you can improve things for everyone. But what you have to understand here is that there IS value in making tools for experts. Povray can't be made into anything that a normal user would call "user friendly" except by making a GUI that will generate the source, but that doesn't mean it's not useful. And sometimes, reaching the largest market is NOT the point.
Freenet has websites, and a message board with Frost. While everything is anonymous it doesn't mean you can't see what's available.
Of course nobody actually knows who downloads what and how much, but there are big lists of websites and such. Although you can hardly call them accurate, since nobody forces anybody to submit their site to the existent indexes.
It's been ages since I last tried Freenet though. The Java server is incredibly annoying, eats tons of RAM and uses a lot of CPU time, and the rest is still very unimpressive. There was Entropy which seemed noticeably smoother, but it had plenty problems of its own, such as a complete lack of security (from what I could see)
Why should there be any?
A sane OS should do that through a package manager. You can do that easily on any Linux distro without needing any specific support in the application.
I suppose there must be something like that for Windows.
Bad idea.
Try running your own mail server some time. You'll notice that all the ones that are currently in use pretty much include their own little programming language. Besides simply reading the mail spool, or sniffing the wire, the server itself could be set up to report anything that looks like a card number.
So, you haven't had any problems yet. That can mean several things. Perhaps nobody is sniffing your current link, or they missed your data, or they got it but didn't use it, or they made a small charge you missed.
However, one thing it doesn't mean is that you're safe. Such a thing can eventually bite you in the ass one day. Of course you could be lucky. But maybe you're not.
Well, it's just the way you write for multiple platforms in pretty much every language. For example, when writing C code you have to have in mind where it's going to run. If you call mmap you have to know that it doesn't exist on Windows, for instance.
A tool that would allow me to specify a list of systems I want to be compatible with and then warns about things that wouldn't work on some of them would actually be very handy.
Indeed, looks pretty normal now.
Having characters that could actually exist in reality is a good thing, IMHO. Some I've seen are so ridiculous that they'd probably have needed magic just to avoid falling from all the weight. I think the current record is held by anime, though. Divergence Eve took it to a really ridiculous level, so that it made it hard watching just because of that. Not that the plot was much better though.
Of course there are also male characters that make Schwarzenegger look like a wimp, but I'd say that's a somewhat different thing since an unrealistic amount of muscle is at least good for something, especially when using a sword is an everyday activity.
Sheesh, that's stupid.
It would be kind of obvious to me that if you're going to play with a headset that completely obscures your vision you should do that in some place where there's no danger.
Although I suppose that there's the inconvenience of that not everybody can clear enough space to use a thing like that, unless it can be used sitting on a chair or lying on a bed.
On the contrary. The problem is that the general population had been fed a pipe dream to them, and now are finding it wasn't true. You are right now describing this dream.
I don't need IT people myself. Computers are easy to fix and service. IMHO, the largest problem ironically is with all the usability improvements that have been made.
Try with a comparison:
Not so long ago, at a company that sells stuff the computers would run DOS. The disk would be nearly blank, the only thing running on it constantly would be the selling terminal application. It would be efficiently handled with only the keyboard.
Then there would be a big server somewhere handled by a few people without much trouble.
These days, the same computer runs Windows. It faces viruses and worms due to stupidities committed in the name of ease of use. The same application is now a GUI, which makes it really pretty, but adds extra workload in the terms of interface programming, which increases the possible failure mode, and makes automated testing harder.
The whole system is managed by an army of often poorly educated people, who run around the company removing viruses, reinstalling systems, and bitterly complaining that people can't just get into their head that life would be much easier without Outlook.
Not saying that the UI hasn't improved, but I'm pretty sure that for commercial purposes the DOS version of all this stuff was working better.
Yup, exactly. We all know that on average, operating systems are equivalent in their quality and usefulness.
Anybody that tells you that Solaris is better than MS-DOS, or MS-DOS is better than Solaris is, at best, simply wrong.
Or at least according to this article. My Lian Li case happens to have two intake fans blowing on the same place where the hard disks are mounted.
Of course that's only if you don't count the more than $100 the case cost. Can't say I regret it though.
Not every crime is equally important.
I think I can see the logic of this - most cops probably don't give a damn about who's selling DVDs, especially since the people who do it (at least here) are usually immigrants (sometimes illegal) who have a very poor knowledge of the language and can't get a job.
Doesn't seem to be much point to me in arresting some guy who managed to get some income that way, when there are much more harmful people out there. I think most cops would be pretty happy with that at least they're not selling drugs or mugging people.
This is what I love about the Internet
You can find about anything online, included experts in popcorn. I'm bookmarking this under my "Interesting esoteric knowledge" folder.
Um, look well at both pages.
PostgreSQL gotchas are a lot less severe. Most of them result in errors. Some result in bad performance. Only two (date parsing and integer overflow) produce unexpected behavior. Both were fixed.
MySQL gotchas mostly deal with things the database flatly ignores when they don't fit, resulting sometimes in completely wrong information inserted into the database. I don't know about you, but if I say the column is NOT NULL, I definitely expect the attempts to insert a NULL there to fail.
Yeah, things seem to be a lot better in mySQL 5. But it's not stable yet, so these gotchas remain in full effect.
Well, it might just be me, but I definitely don't look forward to hex editing databases when the thing goes down and the whole company grinds to a halt.
Now, I will readily say that mySQL has its uses. If you're simply aiming to logging data it works well. IIRC, that's what it was designed for in the beginning.
But it's still quite far from being a good database. Doing crap like silently ignoring things it doesn't like is one of the things that makes sure I'll never use it for anything important.
That's not a database problem, but an application problem.
.ActiveConnection = ServerConnection .CommandText = "do_stuff" .Parameters .Append cmd.CreateParameter("foo", adVarChar, adParamInput, 100, Foo) .Append cmd.CreateParameter("bar", adVarChar, adParamInput, 100, Bar) .Execute
In the Windows world you can do this with ADO, for instance. Simply make EVERYTHING go through a stored procedure, then call it always creating a Command object. For example, in VB:
Dim cmd As New ADODB.Command
With cmd
Set
With
End With
End With
Writing from memory here, so something might be wrong. Anyway, ADO will make sure that everything is properly quoted and it's guaranteed that SQL injection won't work.
The problem is that some things are hard to test.
Libraries, even big ones like glibc are trivial to test. Games and GUI programs are hard to test, although the components can be if they're well designed. Now, kernels...
The problem with the kernel is that it usually doesn't fail in a predictable way. Most of the problems are not because a syscall does the wrong thing when the parameters are strange, but something like this:
Under a high load, on a SMP system, with heavy filesystem activity there exists a chance of disk corruption/oops if one program does foo on CPU 1 and another does bar on CPU 2. And this happens due to an unlikely to happen issue, so it may take an hour for it to happen.
And this is exactly the kind of issue I had. Everything works fine for a month, then the kernel oopses somewhere after spending 4 hours compiling OpenOffice. Unfortunately, kernels are complicated things, and they tend to fail in more interesting ways than say, compilers.
Uh... and why would you want something as messy as that?
I'll say it again - Unix sockets are one of the basic and most used IPC methods in Unix systems. They do NOT have any noticeable performance impact!
Doing some strange crap with memory wouldn't give you any better performance. Besides it sounds more complicated and a lot less secure.
Aha, I think I'm starting to understand the way you think at last. But I still don't see the point.
So fine, GGI has the API concept you like so much, and provides an uniform interface to anything. It's modular, cool and shiny. Now, how do you suggest to make a GUI environment following the same system?
The thing you seem to be missing is that X, or its replacement can't be done this way. So okay, we'll try to do it the Windows way. We'll come up with a nice API so that we call CreateWindow, and a window is made. Now, how does that actually happen?
Well, something needs to make that window. It can't be the application. In the case of GGI/SDL it's simply a problem of translating that high level command into pixels on the screen. But that won't work, you need to be able to run several applications on the same desktop. Just letting several processes call functions and draw stuff where they please is only going to create a huge mess or something useful.
So, how do we solve this? We need an arbitrator, which will assign and manage resources. It will ensure whatever is drawn is drawn in the right order. It will keep track of who owns what, and what is where. It will send messages when something of interested happens, like a paint event.
How, this can't go inside this magical library. How would you decide who is in control? That won't work. The arbitrator must be its own entity and dictate the rules to all who use the services it provides. One example of a system like this is the kernel. A program can't just take a 64K chunk of memory starting at 0x80abcdef, hell, no. The program instead calls the kernel and asks: "I want 64K of memory", and the kernel makes sure there's enough of it, that there's some location big enough, and that the program is allowed to have that much. Then, it adds it at the end of the current process, marks it as used, etc.
Same here. Now, who would arbitrate this stuff? Well, one possibility is the kernel. However, as I mentioned already, this won't happen. The kernel developers don't want it and with good reason. They say that if it can go in user space then it will have to go in user space. And since you can perfectly do all this stuff in user space that's where it will be.
Now that we decided it will be in user space, we know it will run as a process. This process manages resources used by other programs, which also are processes. All of this means both the manager and the users need to talk. And how do we do that?
Well, we can pick: Network sockets, unix sockets, shared memory, pipes, queues. I'll leave out queues because I'm not that familiar with them. Pipes are unidirectional. You can get the same effect, just better with unix sockets. Shared memory is great for sharing data but not for implementing protocols. In a complex event based system you need to be able to poke things and to be poked, and networking does this a lot better.
So, we arrive at using networking yet again! Amazing, isn't it?
Whoops. Ignore AC post.
/dev/fb0 to test it. It's currently there and it's usable. But it has nothing to do with windowing systems.
But what you're talking about has nothing to do with X.
If there's no X process, then what handles windows? GGI, at least from what I can see on its website is simply an API that provides access to low level functions, pretty much like SDL.
However, I don't see anything in GGI that indicates it has any ability to draw windows, widgets or anything remotely GUI like. If you want a thin layer that lets you draw stuff on the screen you can have it already: The framebuffer.
Enable support, boot with a VESA framebuffer console. Knoppix and many other distributions boot with a VESA console if you don't want to mess with the kernel config. Now write junk to
And again, network transparency can't be implemented on top of it because networking is the best IPC mechanism Unix has. It's that simple. If you want to avoid networking the only two options are: X in the kernel, which won't happen. Or application as a module in X, which won't happen either.
Something has to do the GUI stuff. You know, manage the different applications that have access to the same display. Send messages to other applications when appropiate. All of that requires communication. If all this stuff doesn't happen inside one unique process, then that means IPC. And good IPC means networking.
There is a standard API, the X library. It's not like its interface changes every week or something. I don't know of any applications that talk the X network protocol directly.
So, we have that already. You can change the network protocol, and it IS being changed and extended (Xrandr, Render, Shape, etc). But still, you won't get rid of it.
Please take an Unix book and open it. The classic Unix server either forks or multiplexes to handle multiple clients. If it forks, how does the parent server talk to the children? Usually using shared memory, unix sockets, or pipes. How do the children talk to the clients? Shared memory, network sockets, unix sockets, or pipes.
How does the X server talk to clients? Network sockets, unix sockets or shared memory. There you have it. It works *exactly* the same way virtually every other Unix server works. Nothing at all oddball about it.
And that's what you people don't get - it's not unrelated!
Networking is simply the best way to communicate client and server. You can choose from: Network sockets, unix sockects, pipes, queues and shared memory.
TCP/IP sockets and unix sockets are functionally equivalent (except that the later are only local and have less overhead). Pipes are unidirectional. Queues aren't used much by anything AFAIK, and shared memory is an inconvenient mechanism for exchanging messages.
Um, and how exactly would you communicate? So, you remove the protocol. And then?
An API is an interface that can be provided by instance for a library. Or it can be provided by an application and used by a library (plugins). But your application isn't *linked* to the X server, so it can't just call functions in it!
The only way to make what you say possible would require each application to be in the same address space as the X server, or for the X server to be in the kernel. Both approaches are quite horrible, IMO.
If the application is a module in the X server then a failure in the application can bring the whole server down. And there's no possible to have applications running with different permissions. Just wonderful, we can go back to MS-DOS levels of security and stability!
X in the kernel is a more viable approach, but forget about it. The kernel developers don't want it there for a good reason, and this isn't exactly removing the network protocol anyway - it's an entirely different system that wouldn't even look remotely like X.
I get the idea that you don't know much about software design. I'll say it again: You can't get rid of network transparency that easily! It has to be there because there has to be some way to talk to the server. I'll try to explain this way. Here are the most common forms of Unix IPC:
Network sockets
Unix sockets
Pipes
Shared memory
Message queues
Guess what? Except shared memory all of those are pretty much the same as network sockets. RPC (remote procedure call), which is probably what you mean by "API" works through network sockets. And shared memory is inconvenient to use for some things.
So, again: Unless the X server moves into the kernel, or the application moves into the X server there's simply nothing better than networking to make the application and server talk.
I did not say anything about kernels.
I'm absolutely not an expert in the area, but I find the idea of a microkernel pretty cool. But I'm not a fanatic of any of those designs, and will use whatever works for me - currently that's Linux with its monolithic design.
In my rather uninformed opinion, microkernels sound quite complex. Now, I'm not a kernel programmer so I think I'd better leave the actual kernel programmers to debate the pros and cons of the approach.
There's also that drawing a window is a pretty complex thing. I'd say that the overhead needed to send the command is probably pretty much insignificant compared to the time needed to calculate what to draw where, and execute the actual operation.