it described how to find, exploit and avoid buffer overflows, how to store secrets reliably, how to determine good access controls to processes and objects,
See, my point exactly: you don't even see what's wrong with that.
Because that's how Microsoft actually implements security in their systems.
"Remember that security features != secure features."
Even if MS software and courses followed MS Press book, that isn't inconsistent with the belief that more (correctly implemented) security features result in more security.
I believe Microsoft security courses are based [...]
We both have to guess what the course contents will actually be (no matter what books they use), and it seems like a pretty good guess that Microsoft will teach security the way they practice it.
Out of this will come lots of students thinking about security the Microsoft way. They'll believe that more security features (ACLs, etc.) in a system make it more secure. They'll think that if they just throw more tools and wizards at software, they can handle anything. And, sadly, even if those programmers don't become Microsoft programmers, a lot of that bad thinking will spill over into Linux and other systems; too much of that is already happening, with people busily porting some of the worst misfeatures of Windows to Linux.
The limitations of current machines keep us from doing a lot of things that make sense:
interactive adjustments of full-resolution digital photographs
real-time high-quality video compression, indexing, and analysis
real-time camera-based user interfaces and interaction
better speech recognition
better indexing and analysis of text
We have barely scratched the surface of what is possible and useful.
Faster machines and bigger address spaces also enable a lot of other things and improve software quality. For example, on today's machines, we can write real-time video games in Perl and word processors in interpreted Scheme. Using higher level languages reduces programming effort, "time-to-market", and improves software quality. One of the biggest problems with current desktops (e.g., Windows, KDE, Gnome) is that they are mostly not written in high level languages, so adding features and debugging take forever.
Even for C/C++ programs, with fast machines, programmers need to waste much less time on assembly coding or tuning software. 64bit address spaces will greatly simplify dealing with video and databases, as programmers don't have to deal with as many hacks.
Altogether, faster machines and bigger address spaces mean cheaper software, higher quality software, and the creation of applications that we dreamed of decades ago but that are only now becoming possible.
Of course, if you run Windows, it's fine to be a couple of generations behind--Microsoft knows well that in order to maximize profit, they want those upgrade dollars from people still using older machines, so they hold back on features. Apple, on the other hand, profits from hardware upgrades, so they put compute-intensive features into their systems. And with Linux, it's your choice: you can run a desktop and applications that work just fine on a 75MHz Pentium, or you can run something that barely functions on an Athlon XP 3000+ with 2G of memory.
People have been working on speech coding since before computers were even around, and there was a lot of work in this area in the 1960's and 1970's. Patents only last around 20 years, so a lot of that stuff is in the public domain now.
If this isn't the perfect argument for modern nuclear energy, I don't know what is...
We still don't have any permanent place to put nuclear waste, and we have no idea how to secure a storage site for thousands of years.
A healthy energy policy is like healthy eating habits: you eat less and you eat more fruits and vegetables. In different words, we need to reduce per capita energy consumption, and we need to use renewable energy resources (plant-based fuels, solar-derived hydrogen).
It's beginning to look like their agenda all along was to slow economic activity,
Of course it is, at least as far as many current industries are concerned. This is not a deep dark secret, it's a simple fact.
Beyond that there are two camps. The first believe that green industries will more than make up for the reduction in economic activity in polluting industries. The second (much smaller) believes that reduced economic activity in general is desirable.
So don't feel bad about questioning the Green orthodoxy, because it's changed 180-degrees in the not too distant past,
Scientists don't know for certain whether CO2 emissions at current or future levels will cause global warming, global cooling, or not have any effect. There are plausible models predicting all three effects (although global warming is by far the most widely accepted model). And if climate change occurs on a massive change, plausible models say that it will be very damaging and costly.
The greens just take a conservative approach, which simply says: massive greenhouse gas emissions are a very recent phenomemon; since we have plausible models predicting grave consequences from this recent phenomenon, let's limit them to remain closer to historical levels until we know more.
It's ironic that the self-proclaimed "conservatives" are the ones most pushing for such a dangerous experiment on a global scale.
These days, most gamers are not interested in slapping down $49.95 for a traditional puzzle game when there are plenty of similar things available online for free
Well,that doesn't mean they are dying. There are probably more gamers today playing puzzle games than ever before: you get them free with your computer, you can play them on-line (games.yahoo.com), you can play them on handhelds, etc.
So why are graphic adventures now seemingly a dead genre?
They don't seem to be--games like Myst are basically a graphic adventure game only that the graphics are better. So, for that matter, are many games that at first glance look like FPSs or RPGs (Half Life, Splinter Cell, etc.).
Every time there's a/. article on "so and so released a beta of product X", someone comes along and makes this "Oh, they're just offloading testing" argument. The truth is, they have to have tested the thing in house beforehand, but users somehow manage to find bugs that your testers never do no matter how much testing is done.
The two statements aren't mutually exclusive. If they have the product tested by 1000 beta testers, of course, they are going to find more bugs than by the 10 in-house testers they have.
In any case, what's so silly about this is Apple getting miffed about the beta getting out and users behaving like it's a punishment not to get the beta. That amounts to saying: "We'll show them--we won't be doing any more beta testing and just release a really buggy browser!"
Companies that do betas with users are getting a free service, and they'll just have to deal with the reality that the users set the terms. An one is that betas usually end up being public, unless you have people sign NDAs.
We have already had pretty complete Windows clones (e.g., from IBM), but they never caught on. The reason is that what matters isn't the code itself, it's the fact that it's an official Microsoft release with the latest Microsoft hacks and changes. People want to know that they are getting the official release, not some third party distribution that is a few months or years behind.
So, if Microsoft merely were to distribute the source along with every release, nothing much would happen, because by the time other people would have managed to put a distribution together, Microsoft would already have moved on to something else in most cases.
What would make a difference is if Microsoft opened the development process itself, that is their "SourceSafe" repository, at least for read-only access, and nightly builds. That way, other people could keep up. But that goes far beyond opening the source to Windows.
So, just making source available, even under BSD or LGPL doesn't make much of a difference. Open source is an on-going process, not just occasional availability of source code to a released product.
The Titanium Powerbooks are very pretty (I have one), but they are not very rugged machines and their screen is not particularly good outdoors. And in terms of performance, the Toughbook is probably at least as good. The most rugged machine in the Apple line is the iBooks--kid tested--but not too fast.
Still, I understand the guy: I'd also much prefer a Ti Powerbook running OS X to a Toughbook running Windows. I think this was probably more a question of software.
Giving out software like that is a privage, not your God given right.
You make it sound as if Apple is doing people a favor by giving out unfinished software. What they are really doing is off-loading testing to unpaid outsiders.
Now its too late.
Good. So maybe they'll hire testers, pay them, and have them come in. No leaks.
Shouldn't the 5600 software just install on the 5500? I mean, the 5500 has more RAM, and it's trivial to put in lots of flash. Does that mean Sharp is not going to provide an upgrade?
Ah, sorry, I missed the entire intervening post; Slashdot had just moved it out of the way.
Further, I don't really think you need pixel-level control for most things. The only place I can think of is text, but that can be represented as unscaled bitmaps.
Actually, a lot of things need to align pixel-perfect in a GUI. It's not that OpenGL implementations don't do a reasonable job most of the time, it's that it isn't as well-defined what exactly they do. So, your GUI may look fine on one OpenGL implementation and may end up having little gaps on another.
Note that the situation is not analogous to DisplayPostscript or DisplayPDF. First of all, I believe DisplayPostscript was actually well-defined at the pixel level. Second, with DisplayPDF, there is only one implementation, and it's mostly software, so if it doesn't do what Apple wants it to, they just hack either their widgets or the DisplayPDF implementation. For OpenGL, however, the primary purpose of the implementations is great 3D graphics and there are many vendors, so there is no guarantee that you'll be able to write 2D widgets that render reliably and correctly across all implementations, and you have no chance to get the OpenGL implementations fixed..
Also, I think starting to rely on OpenGL is not necessarily a good idea. People do run very lightweight X servers, on handhelds, thin clients, schools, and other places. Why push things so hard just for buttons and widgets? Even using the "traditional" X11 2D APIs, you can still make things look pretty snazzy, in particular with transparency and shadows. And you can use OpenGL when the application really calls for it.
Strange, I don't see any of you nerds commenting on the various sendmail or Samba flaws that have come out recently?
Well, there are several reasons for that:
We didn't pay anything for Samba and Sendmail. But for products that may cost many thousands of dollars in licensing fees, we expect that the vendor does his own testing.
Software like Samba and Sendmail usually gets fixed and updated within a day or two.
Security holes in the free programs seem to cause serious problems much more rarely than security holes in Windows.
As the saying goes, "Linux is user friendly, it just picks its friends carefully."
Seriously, though, Windows documentation is copious, but it is very thin on actual information. I think most people just manage to run Windows because they have a nerd friend they can come to for help.
Definately, vector based graphics are the way to go.
Vector-based graphics, and retained server-side graphics are very useful. They make sense for many desktop applications. But for many other applications of X11, they don't make much sense. That's why it is good to provide them as extensions.
In my opinion (and this is a point of contention on the mailing lists) the best way to go would be to ditch the idea of an X-specific API,
X11 is a protocol, not an API. Lots of clients and lots of servers speak it. How can XFree86 produce an X server if it doesn't speak the X11 protocol? And what's the problem with the traditional X11 protocol? It does a lot of things much better than other window systems (window management, window properties, remote access, etc.). And a simple, true-color-only unaccelerated implementation of its graphics and 2D primitives really is pretty easy and perfectly sufficient for pretty much all traditional uses of X11 (c.f. Xvnc). "Ditching" it seems to have only disadvantages as far as I can tell.
and just make a library on top of OpenGL that provides a simple 2D subset.
OpenGL is not suitable for general purpose 2D raster graphics--it simply doesn't have enough well-defined bit-level semantics, and it simply cannot support a vast amount of existing X11 applications. Until we all get 300dpi screens, it really matters where each individual pixel falls, and X11 defines that.
However, as I was saying, it is perfectly fine to have a generic, unaccelerated, TrueColor implementation for X11's core 2D primitives; no hardware vendor or server developer ever needs to touch that, it just needs to be there.
For 2D graphics based on Keith's RENDER extension, an OpenGL-based implementation should be OK as far as I can tell. And over time, we will then see which graphics API becomes more popular for which market niches.
--- First, Quarts = Quartz.
X needs to be replaced by a direct-rendered model, on which a backwards-compatible X server can be reasonably trivially implemented."
But that statement doesn't even make any sense. X11 is a protocol: it's nothing more than a well-defined sequence of requests and responses between clients and servers. What does a "direct-rendered" implementation of that mean?
NT has pretty much the same architecture: the display server lives in the kernel and applications live in user space. Requests and responses go through queues between the two. The only difference is that the NT protocol isn't documented and that it is rather ad-hoc.
If you want to implement an X11 server, parts of which live in the same address space as the client, great, go right ahead. It's a SE nightmare and no other window system does that anymore, but, hey, maybe you can make it work. You don't need to change the protocol for that.
And I tend to agree with him. Check out directfb to see a good example of how multiple applications can have "direct" access to the video card (not really "direct frame buffer").
Well, gee, and that is just what XFree86 gives you. In fact, it is often handled completely transparently (read up on how OpenGL is implemented). But XFree86 also happens to give you the option of using non-local transport mechanisms, without imposing an additional cost for local communications.
I envision a lowlevel graphics project that is only interested in bringing high performant graphics to linux.
It's perfectly reasonable to divide an X11 implementation into a low-level graphics layer and a high-level windowing layer. It is also perfectly reasonable to give local applications controlled, direct access to the hardware. And it is perfectly reasonable to let applications communicate via shared memory. And, wouldn't you know it, that's just what XFree86 does. And even more nicely, it will transparently switch between local and remote implementations.
But it is not reasonable to expose the low-level graphics layer to applications through a separate API, because then you lose network transparency. Putting up multiple DirectFB windows on a screen and remoting some of them through the X11 protocol does not give you network transparent windowing. What makes X11 network transparent is that it can manage both local and remote windows transparently through a unified API. That costs you nothing in performance, and it gives you a lot in terms of functionality.
I have often thought that XFree86 project should be broken up into more reasonably sized pieces. I once tried to play around with the source, but it was just too dang large for me to get into on my spare time.
Sure, the XFree86 server code is big and complex. But, so what? It conforms to well-defined standards and APIs and it's very efficient. It won't be any more efficient or featureful if you re-implement it. The reason to re-implement it would be if maintenance of it becomes too much of a problem. That may or may not be the case, but it's something for the maintainers to worry about, and addressing that problem doesn't require changing the protocol.
AFAIK, it is either mass bitmap-copy, or use a "special" local native API that circumvents the network transparency (really, what are you going to do send opengl commands over the wire to the client [i.e., window server]??).
Well, what do you imagine would be the alternative to "sending commands over the wire"? X11 and NT do pretty much the same thing when you run them locally.
Under NT, the window system lives in the kernel, and graphics is usually drawn by a co-processor. If you call that "local native API" on Windows, be it for 2D graphics or 3D graphics, it enqueues your request in some buffer somewhere, eventually it switches to the graphics subsystem, the graphics subsystem enqueues the request with the graphics co-processor, and eventually, it gets executed and you probably get an acknowledgement.
Under X11, you call an Xlib function and it enqueues your request somewhere. Eventually, the system switches to the X11 server, which gets the request out of the queue, enqueues it with the graphics co-processor, and eventually it gets executed and you get back an acknowledgement. X11 servers on UNIX/Linux usually happen to use unix-domain sockets as the mechanism by which to get the enqueued requests from the clients to the display server (in addition to shared memory for bulk data transfers); that's because unix domain sockets are pretty much as efficient as you can get for this purpose. If NT had invented some mechanism that was faster (and I don't think it has), one could use that with X11; then, you might connect to maybe "super-duper-comm/:0" as your display, instead of ":0".
Note that if you use "localhost:0" instead of ":0", your X11 server will run much slower, because "localhost:0" really does have to go through parts of the TCP/IP stack. But ":0" really does use a very efficient IPC mechanism.
Now, both X11 and NT, and I mean both, give you some additional hooks (DRI, DirectX) that let user-mode programs ask nicely and get some "direct" access to the hardware. But that is obviously not a tradeoff many non-game programs make, and for good, practical reasons.
Note in particular that for 3D rendering, all of this has been worked out and happens transparently under X11 *:
OpenGL-based programs must link with the libGL library. libGL implements the GLX interface as well as the main OpenGL API entrypoints. When using indirect rendering, libGL creates GLX protocol messages and sends them to the X server via a socket. When using direct rendering, libGL loads the appropriate 3D DRI driver then dispatches OpenGL library calls directly to that driver.
Basically, X11's capabilities and performance are a superset of those of NT's graphics system: X11 handles the local case as efficiently as NT, using shared memory and "direct" hardware and memory access where possible, but falling back to other communications channels when needed.
Let me add to that Windows has had to add function calls that return "promises" in order to continue the illusion of being a frame buffer library when in reality, it's just a very messy and less functional implementation of an X11-like client-server architecture.
The notion that there is anything "direct" about Windows GUI rendering is silly. And for the Mac, it's even sillier, given that it uses a PDF-based system derived from DisplayPostscript. The world has moved to an X11 model, it's just that most application programmers haven't figured out yet that the world has shifted under their feet.
X11 needs major work, things like transparency, rendering, server-side vector graphics, etc.--and that is happening. But one thing it doesn't need is turn into a pretend-frame-buffer library. The other thing it doesn't need is to have a lot of junk and policy hard-coded into the server (widgets, window management, etc.), like some would-be competitors are trying to do.
The recent Slashdot story about kernel tweaking (kernel tweaking!) to make X more responsive underscores this perfectly. First you start tweaking the kernel... and then you realize that you have to move the graphics subsystem closer to ring 0 to make the thing work at sufficient speed. The very thing that Windows has been criticized for since NT 3.51 came out.
The reality of it is that NT's graphics system and X11 are not all that different. It's just that at a higher level, there is no support for remoting applications in NT.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
There are many possible reasons for that. Maybe you are running Gnome or KDE, for example. But X11 isn't at fault.
Get rid of X and you have a desktop OS that can actually compete. You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead.
The graphics is close to the metal in X11: you send the server a bunch of high-level operations you want it to execute and it does it for you, using hardware acceleration and highly optimized drawing routines. X11 is really like Apple's Quartz in that regard, only that X11 uses a more efficient binary protocol (server-retained vector graphics is an extension for X11).
By your argument, we should all be programming in framebuffer libraries running in user mode. We had that. It's slow, it's unsafe, and it's very inconvenient. Trust me, I have been there.
That's why DirectX is the darling of game developers.
And how many application developers do you know who program in DirectX? There is a reason why we have DirectX/DRI on the one hand and GDI+/X11 on the other.
Your jobs are secure for only a few more years, then millions more Chinese and Indians will learn C, C++, VB, etc etc and take your jobs.
Programming is no different there from most other jobs: people can do them overseas, and they will. And those same people will also become consumers and increase the demand for software and programming.
Software development is like the Mc Donalds job,
No, it isn't. McDonalds is a service industry job for which you have to be physically near the customer--that can't be outsourced to China or India. Barber, car mechanic, and lots of other other service and professional jobs fall into the same category. If you want a job that can't be moved out of the country, take one of those.
But some software development is indeed like McDonalds in that it is actually a service industry job and cannot be moved out of the country.
anyone can do it, theres no shortage of programmers,
Anyone can also perform surgery, and if we didn't license surgeons, there wouldn't be a shortage of people trying. And that just about sums up the software industry: a lot of bloated corpses left by people who don't know what they are doing. Frankly, I think it's quite healthy if the low-end stuff that "anybody can do" gets moved overseas. The Indians and Chinese can't do a worse job than the VB "programmers" with a couple of years of "experience" in the US.
Slashdot Mirror
See, my point exactly: you don't even see what's wrong with that.
Because that's how Microsoft actually implements security in their systems.
"Remember that security features != secure features."
Even if MS software and courses followed MS Press book, that isn't inconsistent with the belief that more (correctly implemented) security features result in more security.
We both have to guess what the course contents will actually be (no matter what books they use), and it seems like a pretty good guess that Microsoft will teach security the way they practice it.
Out of this will come lots of students thinking about security the Microsoft way. They'll believe that more security features (ACLs, etc.) in a system make it more secure. They'll think that if they just throw more tools and wizards at software, they can handle anything. And, sadly, even if those programmers don't become Microsoft programmers, a lot of that bad thinking will spill over into Linux and other systems; too much of that is already happening, with people busily porting some of the worst misfeatures of Windows to Linux.
- interactive adjustments of full-resolution digital photographs
- real-time high-quality video compression, indexing, and analysis
- real-time camera-based user interfaces and interaction
- better speech recognition
- better indexing and analysis of text
We have barely scratched the surface of what is possible and useful.Faster machines and bigger address spaces also enable a lot of other things and improve software quality. For example, on today's machines, we can write real-time video games in Perl and word processors in interpreted Scheme. Using higher level languages reduces programming effort, "time-to-market", and improves software quality. One of the biggest problems with current desktops (e.g., Windows, KDE, Gnome) is that they are mostly not written in high level languages, so adding features and debugging take forever.
Even for C/C++ programs, with fast machines, programmers need to waste much less time on assembly coding or tuning software. 64bit address spaces will greatly simplify dealing with video and databases, as programmers don't have to deal with as many hacks.
Altogether, faster machines and bigger address spaces mean cheaper software, higher quality software, and the creation of applications that we dreamed of decades ago but that are only now becoming possible.
Of course, if you run Windows, it's fine to be a couple of generations behind--Microsoft knows well that in order to maximize profit, they want those upgrade dollars from people still using older machines, so they hold back on features. Apple, on the other hand, profits from hardware upgrades, so they put compute-intensive features into their systems. And with Linux, it's your choice: you can run a desktop and applications that work just fine on a 75MHz Pentium, or you can run something that barely functions on an Athlon XP 3000+ with 2G of memory.
People have been working on speech coding since before computers were even around, and there was a lot of work in this area in the 1960's and 1970's. Patents only last around 20 years, so a lot of that stuff is in the public domain now.
We still don't have any permanent place to put nuclear waste, and we have no idea how to secure a storage site for thousands of years.
A healthy energy policy is like healthy eating habits: you eat less and you eat more fruits and vegetables. In different words, we need to reduce per capita energy consumption, and we need to use renewable energy resources (plant-based fuels, solar-derived hydrogen).
Of course it is, at least as far as many current industries are concerned. This is not a deep dark secret, it's a simple fact.
Beyond that there are two camps. The first believe that green industries will more than make up for the reduction in economic activity in polluting industries. The second (much smaller) believes that reduced economic activity in general is desirable.
So don't feel bad about questioning the Green orthodoxy, because it's changed 180-degrees in the not too distant past,
Scientists don't know for certain whether CO2 emissions at current or future levels will cause global warming, global cooling, or not have any effect. There are plausible models predicting all three effects (although global warming is by far the most widely accepted model). And if climate change occurs on a massive change, plausible models say that it will be very damaging and costly.
The greens just take a conservative approach, which simply says: massive greenhouse gas emissions are a very recent phenomemon; since we have plausible models predicting grave consequences from this recent phenomenon, let's limit them to remain closer to historical levels until we know more.
It's ironic that the self-proclaimed "conservatives" are the ones most pushing for such a dangerous experiment on a global scale.
I've been really happy with printroom.com. Their gallery seems fine and their prints were the best of a bunch of companies that I tried.
Well,that doesn't mean they are dying. There are probably more gamers today playing puzzle games than ever before: you get them free with your computer, you can play them on-line (games.yahoo.com), you can play them on handhelds, etc.
So why are graphic adventures now seemingly a dead genre?
They don't seem to be--games like Myst are basically a graphic adventure game only that the graphics are better. So, for that matter, are many games that at first glance look like FPSs or RPGs (Half Life, Splinter Cell, etc.).
The two statements aren't mutually exclusive. If they have the product tested by 1000 beta testers, of course, they are going to find more bugs than by the 10 in-house testers they have.
In any case, what's so silly about this is Apple getting miffed about the beta getting out and users behaving like it's a punishment not to get the beta. That amounts to saying: "We'll show them--we won't be doing any more beta testing and just release a really buggy browser!"
Companies that do betas with users are getting a free service, and they'll just have to deal with the reality that the users set the terms. An one is that betas usually end up being public, unless you have people sign NDAs.
Are these standard laptops with standard components? Is it reasonably easy to install Linux on them?
So, if Microsoft merely were to distribute the source along with every release, nothing much would happen, because by the time other people would have managed to put a distribution together, Microsoft would already have moved on to something else in most cases.
What would make a difference is if Microsoft opened the development process itself, that is their "SourceSafe" repository, at least for read-only access, and nightly builds. That way, other people could keep up. But that goes far beyond opening the source to Windows.
So, just making source available, even under BSD or LGPL doesn't make much of a difference. Open source is an on-going process, not just occasional availability of source code to a released product.
Still, I understand the guy: I'd also much prefer a Ti Powerbook running OS X to a Toughbook running Windows. I think this was probably more a question of software.
You make it sound as if Apple is doing people a favor by giving out unfinished software. What they are really doing is off-loading testing to unpaid outsiders.
Now its too late.
Good. So maybe they'll hire testers, pay them, and have them come in. No leaks.
Shouldn't the 5600 software just install on the 5500? I mean, the 5500 has more RAM, and it's trivial to put in lots of flash. Does that mean Sharp is not going to provide an upgrade?
Further, I don't really think you need pixel-level control for most things. The only place I can think of is text, but that can be represented as unscaled bitmaps.
Actually, a lot of things need to align pixel-perfect in a GUI. It's not that OpenGL implementations don't do a reasonable job most of the time, it's that it isn't as well-defined what exactly they do. So, your GUI may look fine on one OpenGL implementation and may end up having little gaps on another.
Note that the situation is not analogous to DisplayPostscript or DisplayPDF. First of all, I believe DisplayPostscript was actually well-defined at the pixel level. Second, with DisplayPDF, there is only one implementation, and it's mostly software, so if it doesn't do what Apple wants it to, they just hack either their widgets or the DisplayPDF implementation. For OpenGL, however, the primary purpose of the implementations is great 3D graphics and there are many vendors, so there is no guarantee that you'll be able to write 2D widgets that render reliably and correctly across all implementations, and you have no chance to get the OpenGL implementations fixed..
Also, I think starting to rely on OpenGL is not necessarily a good idea. People do run very lightweight X servers, on handhelds, thin clients, schools, and other places. Why push things so hard just for buttons and widgets? Even using the "traditional" X11 2D APIs, you can still make things look pretty snazzy, in particular with transparency and shadows. And you can use OpenGL when the application really calls for it.
Well, there are several reasons for that:
Seriously, though, Windows documentation is copious, but it is very thin on actual information. I think most people just manage to run Windows because they have a nerd friend they can come to for help.
Vector-based graphics, and retained server-side graphics are very useful. They make sense for many desktop applications. But for many other applications of X11, they don't make much sense. That's why it is good to provide them as extensions.
In my opinion (and this is a point of contention on the mailing lists) the best way to go would be to ditch the idea of an X-specific API,
X11 is a protocol, not an API. Lots of clients and lots of servers speak it. How can XFree86 produce an X server if it doesn't speak the X11 protocol? And what's the problem with the traditional X11 protocol? It does a lot of things much better than other window systems (window management, window properties, remote access, etc.). And a simple, true-color-only unaccelerated implementation of its graphics and 2D primitives really is pretty easy and perfectly sufficient for pretty much all traditional uses of X11 (c.f. Xvnc). "Ditching" it seems to have only disadvantages as far as I can tell.
and just make a library on top of OpenGL that provides a simple 2D subset.
OpenGL is not suitable for general purpose 2D raster graphics--it simply doesn't have enough well-defined bit-level semantics, and it simply cannot support a vast amount of existing X11 applications. Until we all get 300dpi screens, it really matters where each individual pixel falls, and X11 defines that.
However, as I was saying, it is perfectly fine to have a generic, unaccelerated, TrueColor implementation for X11's core 2D primitives; no hardware vendor or server developer ever needs to touch that, it just needs to be there.
For 2D graphics based on Keith's RENDER extension, an OpenGL-based implementation should be OK as far as I can tell. And over time, we will then see which graphics API becomes more popular for which market niches.
---
First, Quarts = Quartz.
That's actually spelled "typo".
But that statement doesn't even make any sense. X11 is a protocol: it's nothing more than a well-defined sequence of requests and responses between clients and servers. What does a "direct-rendered" implementation of that mean?
NT has pretty much the same architecture: the display server lives in the kernel and applications live in user space. Requests and responses go through queues between the two. The only difference is that the NT protocol isn't documented and that it is rather ad-hoc.
If you want to implement an X11 server, parts of which live in the same address space as the client, great, go right ahead. It's a SE nightmare and no other window system does that anymore, but, hey, maybe you can make it work. You don't need to change the protocol for that.
And I tend to agree with him. Check out directfb to see a good example of how multiple applications can have "direct" access to the video card (not really "direct frame buffer").
Well, gee, and that is just what XFree86 gives you. In fact, it is often handled completely transparently (read up on how OpenGL is implemented). But XFree86 also happens to give you the option of using non-local transport mechanisms, without imposing an additional cost for local communications.
I envision a lowlevel graphics project that is only interested in bringing high performant graphics to linux.
It's perfectly reasonable to divide an X11 implementation into a low-level graphics layer and a high-level windowing layer. It is also perfectly reasonable to give local applications controlled, direct access to the hardware. And it is perfectly reasonable to let applications communicate via shared memory. And, wouldn't you know it, that's just what XFree86 does. And even more nicely, it will transparently switch between local and remote implementations.
But it is not reasonable to expose the low-level graphics layer to applications through a separate API, because then you lose network transparency. Putting up multiple DirectFB windows on a screen and remoting some of them through the X11 protocol does not give you network transparent windowing. What makes X11 network transparent is that it can manage both local and remote windows transparently through a unified API. That costs you nothing in performance, and it gives you a lot in terms of functionality.
I have often thought that XFree86 project should be broken up into more reasonably sized pieces. I once tried to play around with the source, but it was just too dang large for me to get into on my spare time.
Sure, the XFree86 server code is big and complex. But, so what? It conforms to well-defined standards and APIs and it's very efficient. It won't be any more efficient or featureful if you re-implement it. The reason to re-implement it would be if maintenance of it becomes too much of a problem. That may or may not be the case, but it's something for the maintainers to worry about, and addressing that problem doesn't require changing the protocol.
Well, what do you imagine would be the alternative to "sending commands over the wire"? X11 and NT do pretty much the same thing when you run them locally.
Under NT, the window system lives in the kernel, and graphics is usually drawn by a co-processor. If you call that "local native API" on Windows, be it for 2D graphics or 3D graphics, it enqueues your request in some buffer somewhere, eventually it switches to the graphics subsystem, the graphics subsystem enqueues the request with the graphics co-processor, and eventually, it gets executed and you probably get an acknowledgement.
Under X11, you call an Xlib function and it enqueues your request somewhere. Eventually, the system switches to the X11 server, which gets the request out of the queue, enqueues it with the graphics co-processor, and eventually it gets executed and you get back an acknowledgement. X11 servers on UNIX/Linux usually happen to use unix-domain sockets as the mechanism by which to get the enqueued requests from the clients to the display server (in addition to shared memory for bulk data transfers); that's because unix domain sockets are pretty much as efficient as you can get for this purpose. If NT had invented some mechanism that was faster (and I don't think it has), one could use that with X11; then, you might connect to maybe "super-duper-comm/:0" as your display, instead of ":0".
Note that if you use "localhost:0" instead of ":0", your X11 server will run much slower, because "localhost:0" really does have to go through parts of the TCP/IP stack. But ":0" really does use a very efficient IPC mechanism.
Now, both X11 and NT, and I mean both, give you some additional hooks (DRI, DirectX) that let user-mode programs ask nicely and get some "direct" access to the hardware. But that is obviously not a tradeoff many non-game programs make, and for good, practical reasons.
Note in particular that for 3D rendering, all of this has been worked out and happens transparently under X11 *:
Basically, X11's capabilities and performance are a superset of those of NT's graphics system: X11 handles the local case as efficiently as NT, using shared memory and "direct" hardware and memory access where possible, but falling back to other communications channels when needed.The notion that there is anything "direct" about Windows GUI rendering is silly. And for the Mac, it's even sillier, given that it uses a PDF-based system derived from DisplayPostscript. The world has moved to an X11 model, it's just that most application programmers haven't figured out yet that the world has shifted under their feet.
X11 needs major work, things like transparency, rendering, server-side vector graphics, etc.--and that is happening. But one thing it doesn't need is turn into a pretend-frame-buffer library. The other thing it doesn't need is to have a lot of junk and policy hard-coded into the server (widgets, window management, etc.), like some would-be competitors are trying to do.
The reality of it is that NT's graphics system and X11 are not all that different. It's just that at a higher level, there is no support for remoting applications in NT.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
There are many possible reasons for that. Maybe you are running Gnome or KDE, for example. But X11 isn't at fault.
Get rid of X and you have a desktop OS that can actually compete. You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead.
The graphics is close to the metal in X11: you send the server a bunch of high-level operations you want it to execute and it does it for you, using hardware acceleration and highly optimized drawing routines. X11 is really like Apple's Quartz in that regard, only that X11 uses a more efficient binary protocol (server-retained vector graphics is an extension for X11).
By your argument, we should all be programming in framebuffer libraries running in user mode. We had that. It's slow, it's unsafe, and it's very inconvenient. Trust me, I have been there.
That's why DirectX is the darling of game developers.
And how many application developers do you know who program in DirectX? There is a reason why we have DirectX/DRI on the one hand and GDI+/X11 on the other.
Programming is no different there from most other jobs: people can do them overseas, and they will. And those same people will also become consumers and increase the demand for software and programming.
Software development is like the Mc Donalds job,
No, it isn't. McDonalds is a service industry job for which you have to be physically near the customer--that can't be outsourced to China or India. Barber, car mechanic, and lots of other other service and professional jobs fall into the same category. If you want a job that can't be moved out of the country, take one of those.
But some software development is indeed like McDonalds in that it is actually a service industry job and cannot be moved out of the country.
anyone can do it, theres no shortage of programmers,
Anyone can also perform surgery, and if we didn't license surgeons, there wouldn't be a shortage of people trying. And that just about sums up the software industry: a lot of bloated corpses left by people who don't know what they are doing. Frankly, I think it's quite healthy if the low-end stuff that "anybody can do" gets moved overseas. The Indians and Chinese can't do a worse job than the VB "programmers" with a couple of years of "experience" in the US.