Wasn't this modern technological society supposed to make life easier? Wasn't automation supposed to mean that we would have more time to play instead of work? Yet people today are working as hard (or harder, depending on what you read) than people did in pre-industrial times. Yeah, we live a little longer (arguably -- opinions differ) and we have better teeth (no question), but the ``Protestant Work Ethic'' still has us working like slaves instead of doing what we really want to do. It's gotten so bad that a lot of people think that what they want to do is fnord ``be a productive member of society!''
Still, there's a lot of cool stuff you can buy, isn't there?
Reading the X debate, on OSO and elsewhere, I've read the same two opposing opinions again and again:
1. X is an extremely capable protocol that does all the things you could want it to do, so why change?
2. X is an inelegant, slow behemoth. The first argument seems to come from experienced X developers who are used to the way it works; the second from people who've written a few small applications and found it amazingly ugly.
That hasn't been my experience at all. I've seen three basic sets of opinions:
People who don't know the difference between X and FVWM, and note that Linux has a crummy and inconsistent end-user GUI experience;
People who have done little or no X programming and think that being able to run an xterm on the machine down the hallway is really neat;
People who have done an extensive amount of X programming, know a lot about X, and hate it because it is completely unsuitable for any kind of performance-critical tasks, including (for example) anything that uses graphics.
I'm in camp #3, obviously.
This thread is going to re-hash everything that was discussed here last week and the week before then, is it? I guess that's appropriate, since the article that started these comments also seemed to disregard it.
SRL is cool (I've seen them many times) but the thing they are sorely lacking is a sense of pacing. They build these really cool machines, but watching their shows, the experience one mostly has is monotony. It's not unusual to spend half an hour in the middle of the show wondering whether the show is over now, before some machine starts tearing some new machine apart.
Sadly, the SFPD seem to be on SRL's mailing lists these days, so they don't get away with much any more. For the last few years, the Fire Marshall has tended to show up before the show has even gotten underway.
Did Linus get anything? I'm sure he got the letter...
Just a guess, but I'll bet at some point during their existence, Red Hat offered Linus a job. If he had taken it, he'd be worth many millions today. That's a much better deal than being handed a paltry 400 IPO shares. (But he's given his reasons for not wanting to be beholden to one particular Linux-oriented company. So his entry in the startup lottery is with a non-Linux company instead.)
Like everyone else (it seems) I saw the notices this morning, first telling me that I needed to reconfirm the market order (what do they think "market order" means exactly?) and then the notice telling me that I had gotten no shares.
I never got any email from E*Trade -- I still haven't.
Well, I was in the middle of posting to slashdot about this when I got a phone call from someone at E*Trade asking me if I still wanted to buy shares at the offering price. I said that I had just checked my account, and the notices seemed to be telling me that it was too late, and that I had gotten no shares.
He sounded uncomfortable and said, ``um, well, it seems that some people got those notices by accident.'' So, I re-confirmed my order, and am still waiting to hear how many shares I got, if any.
I asked him if there was any chance that I would be allocated more than 100 shares, given how many people were participating. He said that it was likely that I would get more than 100, but he didn't want to guess how many.
One of my friends talked to them later in the day, and the rep couldn't tell him whether his confirmation had gone though, because E*Trade's internal system wasn't responding.
They sure have their act together. And they've got a hell of an infrastructure too! I'm so impressed!
It's just amazing to me that a full day of trading has gone by, and E*Trade hasn't yet told me how many of the shares I asked to buy I was actually allowed to purchase.
Once this is all over, I am certainly going to try (again!) to close my E*Trade account. If you don't plan to use E*Trade again, then you should do the same -- if you don't, they'll just continue bragging about their artificially inflated customer count.
(And having open but unused accounts at financial insitutions is generally a bad idea: if they make some stupid mistake, like draining your account with service charges, they can screw up your credit rating for you in ways that are difficult or impossible to repair. I know many people this has happened to.)
Ack! Even worse, this notation *has* to be used in X resource files and other preferences.
"-*-courier-bold-o-*-*-*-120-*-*-*-*-iso8859-1" is actually what you should be using, if you want your resources to have a better chance of being portable from one machine to another. That X's font names are verbose doesn't mean you need to specify all those fields.
But what they want is to be able to say "Switch from the Adobe font folder to Bitstream and redisplay", not the anal level of detail that X requires.
X doesn't require that level of detail. However, neither does it make the operation you described easy. This is largely because there aren't a set of library routines for doing things like asking for a similarly-sized font in a different face, or the next-larger font size that is displayable and/or looks good.
I'm sure lots of people have rolled their own solutions to this over the years. I did it once in emacs-lisp, and did it again twice for Netscape (which is on its third or fourth version of the font-selection code now, so if you still hate it, it's not my fault any more...)
X's font management is lousy in many ways, but I don't think that its long font names are a problem.
I agree with the person who said SGI should extend into the consumer graphics hardware business. I can only imagine how fast Diamond Mm et al. would fall to the might of SGI hardware.
In my opinion, that would be suicide. SGI are not cut out to be 'graphics board' manufacturers. They build complete systems.
I think SGI's best hope for survival would have been for them to have expanded into the PC graphics board business in 1993 or 1994. They should have been 3DFx -- instead, 3DFx was founded by SGIers who jumped ship. It's far too late for that now.
I remember being stunned at the marketing campaign for the Indy -- they had an ad where someone was saying, ``finally, SGI is making a computer that's just like everyone else's!'' Yeah, except that it cost 3x as much! They got the idea that they should be building these low-end general-purpose Unix workstations, and were actually downplaying the fact that these machines all came with kick-ass graphics as a standard feature.
It's hard to tell what business SGI is actually in these days, after all of these reorgs. They seem to have sold off the part of the company that does graphics hardware. What's left? Has SGI turned into a VA Research clone?
This is all very sad, because SGI has done some amazing things.
And you know, Sun can't build graphics hardware or software to save their life. Never have. It's sad to see that some people think that Sun is actually competition to SGI. Well, they are competition, but they're just not in the same league, dammit.
This means I'm never going to be able to get spare parts or bug fixes for my O2, doesn't it? Sigh.
Re:You've missed the point of X
on
Is X The Future?
·
· Score: 2
You're absolutely correct that graphics can be accelerated tremendously by dumping the functions that get in the way of performance and running on the bare metal the way Windows does.
I am most certainly not talking about ``dumping the functions that get in the way'' or ``running on the bare metal.'' There's a world of difference between having every application have hardware-specific knowlege; and having every application use proper high-level abstractions, but having the implementation of those abstractions not involve handshaking between multiple processes!
It's a fundamental architectural decision: do you build a graphics system on top of an operating system or an operating system on top of a graphics system?
What's this supposed to mean, besides being a dig against the fact that Windows doesn't have memory protection? I think you're confusing memory protection and the client-server model. Neither implies the other.
The latter approach has screaming performance as long as the various clients play by the rules and respect each others' memory, screen, etc. space. By interposing networking and security functions between the layers, OTOH, the client-server approach buys stability, security, and portability at the expense of performance
Maybe you don't realize this, but any X program can scribble on the windows of any other X program. Or even free resources allocated by other programs, causing them to get X errors and (usually) crash. It's not particularly easy to do this by accident, but X does nothing to prevent it (in fact, it's explicitly allowed.) Once you have a connection to the display, you have free reign.
The client-server approach buys you nothing in terms of stability, security, or portability. Those are all orthogonal issues. All the client-server approach buys you is network-transparent graphics.
Likewise, having an implementation that gives you in-process access to the frame buffer (and the ability to do graphics fast) does not imply lack of memory protection. Remember that these clients are still going to be doing their drawing through high-level APIs, and the implementation of those APIs can do whatever bounds checking is appropriate. The X server does such checks internally anyway -- in addition to all the IPC overhead.
there's just no reason to use a non 32-bit color depth. There's that one xscreensaver hack that uses palette shifting on 8-bit displays and is slow on other color depths... but that's the only advantage to 8bit color left, and there is no advantage to 16 bit color.
Actually, quite a few of the xscreensaver hacks behave very differently on PseudoColor versus TrueColor: the difference will be that, when a colormap is available, the whole screen will be alive with motion, and when there is no colormap, the screen will be pretty much a static image. There are some things you just can't do fast without colormaps.
Another reason for using 8-bit depth is speed: that's 1/4 as many bits that the server has to move around. You might expect that this wouldn't be a big deal, but it turns out that it is. The difference really is perceptible: there are a few hacks in xscreensaver (``compass'' comes to mind) that very obviously run 4x faster in 8-bit mode than in 24-bit mode. Sad but true.
SGI got this right, of course, by having an X server that allows 8-bit-deep colormapped windows and 24-bit-deep non-colormapped windows to exist side by side on the same display. That way, each application can pick the color depth that is most appropriate to its task.
Re:You've missed the point of X
on
Is X The Future?
·
· Score: 2
I guess my point is that for many apps real life performance is not as markedly affected as you'd guess based on the internal workings of the X protocol. In my pedestrian view that means X is mostly good enough to get work done.
Well sure -- if what you're doing doesn't require high performance graphics, then the fact that X can't deliver high performance graphics doesn't much matter, right?
It's certainly true that most applications don't require high performance graphics. But when you need it, you need it. And X can't deliver.
Re:in answer to the original questions...
on
Is X The Future?
·
· Score: 2
This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; [...] What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is.
I hope you're right; that would be a very good outcome.
It does give me some hope that MacOS X is looking so Unixy, because people who have experience writing Macintosh applications just will not tolerate the kind of UI free-for-all that X brings to the party, so maybe they will actually do something about it.
My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.
I don't know about that; I don't think that rescuing all of those NeXTstep applications will really make that big an impact, given how marginal NeXT has always been in the market. It's a nice looking system, no doubt about that, but that doesn't mean it's ever going to catch on.
I'm also somewhat dubious of Display PostScript. I've done a lot of PostScript hacking, and it's frankly a lousy language to program in. (It's a great page-description language, but these days I really believe it's more suited to use as an output format than to use as a language you would actually write code in, and debug.) Of course, I haven't actually hacked on a Display PostScript system, so maybe the DPS APIs are different enough to make it bearable. I don't know. Would someone who has hacked DPS care to comment? Do you end up actually writing PostScript code, or is that hidden behind the scenes somehow?
Re:You've missed the point of X
on
Is X The Future?
·
· Score: 2
As much as I respect Jamie, I beg to differ. The 'dubious feature' to remotely display lets me get my work done very effectively.
As a sysadmin / app supporter my screen is littered with windows displayed from all manner of Unix hosts, and not all of them are xterms. It saves me countless hours of walking across the hall or campus.
(I'm curious, what are those non-xterm tools?)
The ability to admin machines remotely is obviously a great feature. But X decided that it was such an important feature that it had to be built into the window system at such a low level that local access pays the price: that is, that it was more important to be able to use the machine down the hall than to be able to use the machine on your desk!
X could have been designed to be efficient locally, with remote access being possible but slow. It wasn't. It was designed in such a way that local and remote access are about equally slow (if you have a fast local network, which was another fundamental assumption of X.)
In my view the remote display capability is one of the best assets that X has. Granted, it makes X a dog compared to other windowing systems
Wouldn't it be better if remote access was a dog and local access was fast, instead of both being a dog? That's how other window systems do it.
The idea that the way to do network transparency is to have the remote machine be the one tracking the mouse is just crazy. It would be far better for all GUIs to live locally, and for the on-the-wire activity to happen with some more domain-specific RPC, or other services.
(Like, for example, through a web server. CGI is a great example of how to do remote operations while keeping UIs local, and doing it portably as well.)
but that's why my desktop is an SGI. Their X server is as great as it gets.
SGI has a great X server, and it's a credit to them that they made it go as fast as they did (I've never seen a better X server than SGI's.) But it's still ridiculously slow, given what their hardware is capable of! You only have to compare X performance to GL performance to see this.
in answer to the original questions...
on
Is X The Future?
·
· Score: 3
With this question, I don't want to start a discussion if X should be replaced or not, but I only want to find out what's bad about it and where other solutions are better.
There has been a lot of discussion here already about what X's failings are. Quite a lot of it has been wrong (X has many problems, but it's not that ``tvtwm sucks.'' That has nothing to do with X.)
The X chapter of the Unix Haters' Handbook really does do a great job of covering the major points. Yes, this was written several years ago, and not all of it is relevant any more (for example, most Linux users don't use Motif, so all the abuse piled on the Motif implementation probably isn't relevant to most of you; and GTK doesn't even use the X resource manager, so most of you probably don't use your.Xdefaults file any more.) But where he talks about the X protocol, the low-level X API, and the horrors that X's fundamental design decisions have inflicted on us (``run xterm well'' with window management added as an afterthought) it's spot-on. The ``Myth: X Demonstrates the Power of Client/Server Computing'' and ``Myth: X is Device Independent'' section are especially key.
But none of that matters. Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.
Another point I feel the need to make is that most of the people who have been posting to this thread don't understand what X actually is. Some people are talking about X, and some people are talking about ``the sum total of the graphical Unix experience'', of which X is only a small part. In particular, if you're flaming the way your window manager works, you're not talking about X, you're talking about some random crummy application. There are a ton of window managers (there are possibly even more WMs than there are IRC clients, and that's pretty impressive.)
The source of this confusion is that most other window systems come with policy: the look of the window management controls are built in to the window system itself, as are all kinds of other things like cut-and-paste and drag-and-drop: in the interest of ``flexibility,'' X left all of these things undefined, meaning there is no consistency at all.
X itself is very low-level, handling graphics operations and little else. Though small, it imposes serious performance restrictions by the nature of its design.
Because X itself does close to nothing, on top of it, many organizations have built the so-called ``toolkits'' that let you actually build user interfaces. These toolkits impose policy, and implement all the things that one would expect from a window system if one's first experience with a window system was something other than X.
These toolkits inherit all the limitations of X, and then add more of their own: Athena is ugly as sin, and does very little (it doesn't even have real menubars.) Motif was insanely buggy for years, and is still incredibly inefficient. GTK is slow, and isn't really finished yet. KDE requires C++. And so on. And of course all of them are incompatible with each other to various degrees.
If you're bitching about things not being ``object oriented'' enough, then you're bitching about a toolkit, not about X. X itself is so low level that there's just no need for OO hair: those abstractions come at a higher level.
Some people think it's a great thing that X doesn't come with policy. I say nonsense: rampant customizability is almost always an excuse for not having taken the time to get it right in the first place. I just want an appliance that works, I don't want to have to spend days tweaking it before I can turn it on.
Here's what X's lauded ``flexibility'' has given me: right now I'm looking at a screen that has applications on it written using five different toolkits. They all work basically the same (which is to say, they all work basically like a Xerox Alto), but each one renders menus differently, and half of them do cut-and-paste in incompatible ways. Thanks to the flexibility of X, there is no consistency. I really don't care what menus look like, or how cut-and-paste works; I just wish it was possible to pick one and stick with it.
The other efforts to provide consistency across the desktop (Gnome, KDE, whatever) all start off with the requirement of rewriting every single application to do so! What a colossal waste of time! But there is simply no other way, thanks to the legacy of X: thanks to X's refusal to dictate policy, there is no one policy to replace, there are dozens.
For that matter, where did *you* get *this* idea? Have you benchmarked?
Further, exactly what do you mean? I agree that communication speed may decrease by quite a bit, but that's not directly correlated to *display* speed.
I get that idea from having spent ten years trying to squeeze every drop of performance out of X programs as I can. The inefficiencies that the design of the X protocol forces on clients are just staggering! All the handshaking back and forth between the client and server (and associated context switches) adds up really quickly. I see it every day -- I see operations that are fast in every window system that preceeded X slowing X programs to a crawl, and because I know X inside and out, I understand why. It's no mystery to me, it's because of the fundamental design decisions that went into the X protocol on day 1.
I have not done bechmarking, because I have had no reason to. I know X is slow, but I also know I'm stuck with it. However, if you want to try it out for yourself, try and do some simple 2D graphics that do double-buffering using Xlib. Now rewrite that same program using OpenGL (note that we're talking about 2D here, not 3D, no textures. Just line drawings.) Code both programs such that it replaces the image as quickly as it can, yet results in no perceptible flicker. Tell me which one runs faster. Here's a hint: it's the one that can touch the frame buffer in-process, rather than having to suck bits through a straw. (Use the joke of the X Double-Buffer extension if you like, and the XSHM extension. It won't help.)
Individual pixel operations are slow, Quake shouldn't use the X pipe. That's obvious.
Obvious, is it? So what you're saying is, ``Quake shouldn't use X.'' Which is to say, ``X is unsuitable for anything graphics-intensive.'' Which is my point.
Sockets are slightly slower than direct memory copy, but unless the video card is *really* fast I suspect the time spent servicing a request far exceeds the time spent in the request.
You're missing the point again. It's not just the fact that there's a pipe involved, it's the fact that there is synchronization between multiple processes: one writes, and flushes, and then some time later the other becomes runnable, and eventually gets around to reading from the pipe, then talking to the hardware, then writing a response, then flushing it, and eventually the first process becomes runnable again and...
When window operations are involved, you often have to block waiting for answers from the window manager, resulting in a three-way cluster-fuck between the client, the server, and the WM. Oh, but isn't it great that they could be running on three different machines? Whatever.
Do you have a constructive suggestion for improvement or are you just getting a kick out of making snide remarks?
Ah, we've reached that point already I see. We always get here whenever the failings of X, Unix, or anything else Linux weenies hold dear are discussed: the fallacy that, before one has the right to point out a problem, one must have already handed the world the solution on a silver platter. Well guess what, the fact that we're stuck with X forever (because it is completely entrenched) does not mean that X has no problems, or that those problems are not severe. There appear to be some people, like you, who don't understand the extent of those problems, so don't bitch at me for pointing them out, ok?
Having a well-known email address doesn't mean you can simply make insinuating remarks with no explanation to back them up.
Another note: if X is so dated and clunky, what about SGI? I thought that IRIX uses X. I can't envision a much better media OS! Maybe they know something I don't. Hopefully they will share:-)
SGI uses X, and they have an X server that is insanely optimized for their hardware. On top of that, for anything that actually needs to go fast, they use GL instead of X. Basically, they use X to allocate a rectangle, and then X stays out of the way. The GL library then talks to the hardware directly, without a zillion context-switches in the way.
It wastes some. It goes as much as 5 to 10% slower because of it. That is about it.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
However, the benefits are well worth it. Imagine all the recompile cycles needed if all the programs were dynamically linked to the server (like Windows does). Ouch...
WTF? Do you recompile libc every time you compile your program? Are you aware of how libraries work?
One of these days he will come into the present. And maybe just maybe we'll get some constructive critisizem out of him.
Nice words, coming from someone who's too chicken-shit to attach their name to them. Don's one of the smartest people I know. Who are you and what have you done?
2) Client Server Architecture. This means that we can have any number of Window Managers and switch among them at will. This is great becasue different people work differetly. What is efficient to you is ineficient to me, etc.
The fact that the window manager is not built into the server really doesn't have much to do with the client/server model. In a Windows-like library world, the window manager could as easily be a pluggable DLL with the same effect, but without taking the X hit of all the context switches and network traffic.
A Direct Rendering Interface is required, and with X 4.0 should be introduced, and should solve the speed problems without restricting the remote operation enjoyed by legacy X programs. The inclusion of the DRI should help solve a majority of the complaints heard about X's speed.
This, of course, is The Way of X. Got a problem that people have been suffering from for ten years? Fix it by adding yet another new and optional API! So now all the applications writers get to code their graphics routines twice, with lots of runtime feature-checking. Have you ever written X code that made use of XSHM, the shared-memory extension? Did you do it in such a way that your program actually worked when the extension didn't exist? Are you sure? Did it still work when the extension existed on the server, but the server was on a different machine? Are you sure? (In my experience, 99% of the programs that try get it wrong.)
This is no way to fix a bug. X's refusal to add required features to the protocol (SHAPE is still optional, for pete's sake!) makes life hell for application writers until the end of time. Or leaves users with applications that mostly work most of the time.
Guess what, Netscape doesn't (and can't) use XCopyArea for scrolling. Because that just moves bits, not subwindows (think form elements.) Netscape plays crazy tricks with window gravity to move all the windows at once, since the alternative (moving each subwindow by hand) is insanely slow.
But probably the reason you see flicker isn't really X's fault, but is because the table redisplay code isn't great.
Re:You've missed the point of X
on
Is X The Future?
·
· Score: 3
The argument that "X is slow because of its network capability" doesn't hold any water and is really used only by people who don't understand X. X is slow (in some ways, it is) for other reasons... ones that, generally, can be solved.
In a word, wrong.
X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.
Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations.
For the dubious feature of sometimes being able to have clients and servers on different machines, you pay the price of never being able to have decent performance in the common one-machine case.
1) Our frustration will be compounded as Red Hat's stock soars and we realize that we rightfully deserved to be making some earnings off of all of this.
This sense of entitlement is appalling. If you didn't want it to be possible for someone else to take your work and make money off of it, then you should not have given them explicit permission to do so by using an open source license on your contribution! How hard is that to grasp? Red Hat owes you nothing, because they are only doing exactly what you expressly told them they were allowed to do.
It's a very nice gesture for them to have extended this offer, and it's too bad that some people aren't allowed to participate because of factors outside of Red Hat's control. But the way so many of you are acting like something you deserve has been taken from you is just sickening. Grow up.
I would think that hackers would have a better understanding of how this stuff works: if you want to play a game, first you need to understand the rules.
E*Trade has rules, and the SEC has rules, and apparently most of you weren't even aware that they existed. That should be a pretty strong indication that you don't know enough about this game to play. Whine all you like about how this should be your decision, not E*Trade's and not the SEC's, and that you should be allowed to do any stupid thing you want, but the bottom line is, it's not your decision, and there's nothing you can do about it this week. (If you like, campaign to get the SEC's rules changed. Good luck.) You're shouting at the wind, here, people. These rules have existed for a long, long time, and they're not Red Hat's fault.
Perhaps if you do some research, and actually understand the rules of this game, you'll still be able to get in on the deal. Perhaps you'll even be able to do so without breaking any laws. You certainly won't be able to do so without risk -- nobody can. But no, whining on Slashdot like spoiled children because someone didn't make it even easier for you is less hassle.
Red Hat tried to do something nice (out of generosity, not debt), and you're beating them up for it. When someone gives you a gift that, for whatever reason, you can't use, you're supposed to thank them anyway, not start screaming.
I would say that Neuromancer is a much more mature read than Snow Crash..
Uh, maybe that's because Snow Crash was comedy and Neuromancer was noir? I'm always amazed at how many people totally miss the joke, and don't realize that Snow Crash is at least half parody of the very genre it is putatively a member of.
I loved Snow Crash, but comparing it to Neuromancer is like comparing ``Dr. Strangelove'' and ``Fail-Safe.''
Slashdot Mirror
Productivity? Who cares about that?
Wasn't this modern technological society supposed to make life easier? Wasn't automation supposed to mean that we would have more time to play instead of work? Yet people today are working as hard (or harder, depending on what you read) than people did in pre-industrial times. Yeah, we live a little longer (arguably -- opinions differ) and we have better teeth (no question), but the ``Protestant Work Ethic'' still has us working like slaves instead of doing what we really want to do. It's gotten so bad that a lot of people think that what they want to do is fnord ``be a productive member of society!''
Still, there's a lot of cool stuff you can buy, isn't there?
That hasn't been my experience at all. I've seen three basic sets of opinions:
I'm in camp #3, obviously.
This thread is going to re-hash everything that was discussed here last week and the week before then, is it? I guess that's appropriate, since the article that started these comments also seemed to disregard it.
Sadly, the SFPD seem to be on SRL's mailing lists these days, so they don't get away with much any more. For the last few years, the Fire Marshall has tended to show up before the show has even gotten underway.
If you like SRL, you might also like Seemen: here's an announcement for one of their recent shows: news:344de302.1085384@news.concentric.net.
Some like-minded links are over at Laughing Squid.
Just a guess, but I'll bet at some point during their existence, Red Hat offered Linus a job. If he had taken it, he'd be worth many millions today. That's a much better deal than being handed a paltry 400 IPO shares. (But he's given his reasons for not wanting to be beholden to one particular Linux-oriented company. So his entry in the startup lottery is with a non-Linux company instead.)
I never got any email from E*Trade -- I still haven't.
Well, I was in the middle of posting to slashdot about this when I got a phone call from someone at E*Trade asking me if I still wanted to buy shares at the offering price. I said that I had just checked my account, and the notices seemed to be telling me that it was too late, and that I had gotten no shares.
He sounded uncomfortable and said, ``um, well, it seems that some people got those notices by accident.'' So, I re-confirmed my order, and am still waiting to hear how many shares I got, if any.
I asked him if there was any chance that I would be allocated more than 100 shares, given how many people were participating. He said that it was likely that I would get more than 100, but he didn't want to guess how many.
One of my friends talked to them later in the day, and the rep couldn't tell him whether his confirmation had gone though, because E*Trade's internal system wasn't responding.
They sure have their act together. And they've got a hell of an infrastructure too! I'm so impressed!
It's just amazing to me that a full day of trading has gone by, and E*Trade hasn't yet told me how many of the shares I asked to buy I was actually allowed to purchase.
Once this is all over, I am certainly going to try (again!) to close my E*Trade account. If you don't plan to use E*Trade again, then you should do the same -- if you don't, they'll just continue bragging about their artificially inflated customer count.
(And having open but unused accounts at financial insitutions is generally a bad idea: if they make some stupid mistake, like draining your account with service charges, they can screw up your credit rating for you in ways that are difficult or impossible to repair. I know many people this has happened to.)
When I saw the subject ``Quote from Hackers'' I thought it was going to be ``I hope you don't screw like you type.''
I agree, but...
"-*-courier-bold-o-*-*-*-120-*-*-*-*-iso8859-1"is actually what you should be using, if you want your resources to have a better chance of being portable from one machine to another. That X's font names are verbose doesn't mean you need to specify all those fields.
X doesn't require that level of detail. However, neither does it make the operation you described easy. This is largely because there aren't a set of library routines for doing things like asking for a similarly-sized font in a different face, or the next-larger font size that is displayable and/or looks good.
I'm sure lots of people have rolled their own solutions to this over the years. I did it once in emacs-lisp, and did it again twice for Netscape (which is on its third or fourth version of the font-selection code now, so if you still hate it, it's not my fault any more...)
X's font management is lousy in many ways, but I don't think that its long font names are a problem.
I think SGI's best hope for survival would have been for them to have expanded into the PC graphics board business in 1993 or 1994. They should have been 3DFx -- instead, 3DFx was founded by SGIers who jumped ship. It's far too late for that now.
I remember being stunned at the marketing campaign for the Indy -- they had an ad where someone was saying, ``finally, SGI is making a computer that's just like everyone else's!'' Yeah, except that it cost 3x as much! They got the idea that they should be building these low-end general-purpose Unix workstations, and were actually downplaying the fact that these machines all came with kick-ass graphics as a standard feature.
It's hard to tell what business SGI is actually in these days, after all of these reorgs. They seem to have sold off the part of the company that does graphics hardware. What's left? Has SGI turned into a VA Research clone?
This is all very sad, because SGI has done some amazing things.
And you know, Sun can't build graphics hardware or software to save their life. Never have. It's sad to see that some people think that Sun is actually competition to SGI. Well, they are competition, but they're just not in the same league, dammit.
This means I'm never going to be able to get spare parts or bug fixes for my O2, doesn't it? Sigh.
I am most certainly not talking about ``dumping the functions that get in the way'' or ``running on the bare metal.'' There's a world of difference between having every application have hardware-specific knowlege; and having every application use proper high-level abstractions, but having the implementation of those abstractions not involve handshaking between multiple processes!
What's this supposed to mean, besides being a dig against the fact that Windows doesn't have memory protection? I think you're confusing memory protection and the client-server model. Neither implies the other.
Maybe you don't realize this, but any X program can scribble on the windows of any other X program. Or even free resources allocated by other programs, causing them to get X errors and (usually) crash. It's not particularly easy to do this by accident, but X does nothing to prevent it (in fact, it's explicitly allowed.) Once you have a connection to the display, you have free reign.
The client-server approach buys you nothing in terms of stability, security, or portability. Those are all orthogonal issues. All the client-server approach buys you is network-transparent graphics.
Likewise, having an implementation that gives you in-process access to the frame buffer (and the ability to do graphics fast) does not imply lack of memory protection. Remember that these clients are still going to be doing their drawing through high-level APIs, and the implementation of those APIs can do whatever bounds checking is appropriate. The X server does such checks internally anyway -- in addition to all the IPC overhead.
Actually, quite a few of the xscreensaver hacks behave very differently on PseudoColor versus TrueColor: the difference will be that, when a colormap is available, the whole screen will be alive with motion, and when there is no colormap, the screen will be pretty much a static image. There are some things you just can't do fast without colormaps.
Another reason for using 8-bit depth is speed: that's 1/4 as many bits that the server has to move around. You might expect that this wouldn't be a big deal, but it turns out that it is. The difference really is perceptible: there are a few hacks in xscreensaver (``compass'' comes to mind) that very obviously run 4x faster in 8-bit mode than in 24-bit mode. Sad but true.
SGI got this right, of course, by having an X server that allows 8-bit-deep colormapped windows and 24-bit-deep non-colormapped windows to exist side by side on the same display. That way, each application can pick the color depth that is most appropriate to its task.
Well sure -- if what you're doing doesn't require high performance graphics, then the fact that X can't deliver high performance graphics doesn't much matter, right?
It's certainly true that most applications don't require high performance graphics. But when you need it, you need it. And X can't deliver.
I hope you're right; that would be a very good outcome.
It does give me some hope that MacOS X is looking so Unixy, because people who have experience writing Macintosh applications just will not tolerate the kind of UI free-for-all that X brings to the party, so maybe they will actually do something about it.
I don't know about that; I don't think that rescuing all of those NeXTstep applications will really make that big an impact, given how marginal NeXT has always been in the market. It's a nice looking system, no doubt about that, but that doesn't mean it's ever going to catch on.
I'm also somewhat dubious of Display PostScript. I've done a lot of PostScript hacking, and it's frankly a lousy language to program in. (It's a great page-description language, but these days I really believe it's more suited to use as an output format than to use as a language you would actually write code in, and debug.) Of course, I haven't actually hacked on a Display PostScript system, so maybe the DPS APIs are different enough to make it bearable. I don't know. Would someone who has hacked DPS care to comment? Do you end up actually writing PostScript code, or is that hidden behind the scenes somehow?
(I'm curious, what are those non-xterm tools?)
The ability to admin machines remotely is obviously a great feature. But X decided that it was such an important feature that it had to be built into the window system at such a low level that local access pays the price: that is, that it was more important to be able to use the machine down the hall than to be able to use the machine on your desk!
X could have been designed to be efficient locally, with remote access being possible but slow. It wasn't. It was designed in such a way that local and remote access are about equally slow (if you have a fast local network, which was another fundamental assumption of X.)
Wouldn't it be better if remote access was a dog and local access was fast, instead of both being a dog? That's how other window systems do it.
The idea that the way to do network transparency is to have the remote machine be the one tracking the mouse is just crazy. It would be far better for all GUIs to live locally, and for the on-the-wire activity to happen with some more domain-specific RPC, or other services.
(Like, for example, through a web server. CGI is a great example of how to do remote operations while keeping UIs local, and doing it portably as well.)
SGI has a great X server, and it's a credit to them that they made it go as fast as they did (I've never seen a better X server than SGI's.) But it's still ridiculously slow, given what their hardware is capable of! You only have to compare X performance to GL performance to see this.
There has been a lot of discussion here already about what X's failings are. Quite a lot of it has been wrong (X has many problems, but it's not that ``tvtwm sucks.'' That has nothing to do with X.)
The X chapter of the Unix Haters' Handbook really does do a great job of covering the major points. Yes, this was written several years ago, and not all of it is relevant any more (for example, most Linux users don't use Motif, so all the abuse piled on the Motif implementation probably isn't relevant to most of you; and GTK doesn't even use the X resource manager, so most of you probably don't use your .Xdefaults file any more.) But where he talks about the X protocol, the low-level X API, and the horrors that X's fundamental design decisions have inflicted on us (``run xterm well'' with window management added as an afterthought) it's spot-on. The ``Myth: X Demonstrates the Power of Client/Server Computing'' and ``Myth: X is Device Independent'' section are especially key.
But none of that matters . Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.
Worse is Better.
Another point I feel the need to make is that most of the people who have been posting to this thread don't understand what X actually is. Some people are talking about X, and some people are talking about ``the sum total of the graphical Unix experience'', of which X is only a small part. In particular, if you're flaming the way your window manager works, you're not talking about X, you're talking about some random crummy application. There are a ton of window managers (there are possibly even more WMs than there are IRC clients, and that's pretty impressive.)
The source of this confusion is that most other window systems come with policy: the look of the window management controls are built in to the window system itself, as are all kinds of other things like cut-and-paste and drag-and-drop: in the interest of ``flexibility,'' X left all of these things undefined, meaning there is no consistency at all.
X itself is very low-level, handling graphics operations and little else. Though small, it imposes serious performance restrictions by the nature of its design.
Because X itself does close to nothing, on top of it, many organizations have built the so-called ``toolkits'' that let you actually build user interfaces. These toolkits impose policy, and implement all the things that one would expect from a window system if one's first experience with a window system was something other than X.
These toolkits inherit all the limitations of X, and then add more of their own: Athena is ugly as sin, and does very little (it doesn't even have real menubars.) Motif was insanely buggy for years, and is still incredibly inefficient. GTK is slow, and isn't really finished yet. KDE requires C++. And so on. And of course all of them are incompatible with each other to various degrees.
If you're bitching about things not being ``object oriented'' enough, then you're bitching about a toolkit, not about X. X itself is so low level that there's just no need for OO hair: those abstractions come at a higher level.
Some people think it's a great thing that X doesn't come with policy. I say nonsense: rampant customizability is almost always an excuse for not having taken the time to get it right in the first place. I just want an appliance that works, I don't want to have to spend days tweaking it before I can turn it on.
Here's what X's lauded ``flexibility'' has given me: right now I'm looking at a screen that has applications on it written using five different toolkits. They all work basically the same (which is to say, they all work basically like a Xerox Alto), but each one renders menus differently, and half of them do cut-and-paste in incompatible ways. Thanks to the flexibility of X, there is no consistency. I really don't care what menus look like, or how cut-and-paste works; I just wish it was possible to pick one and stick with it.
The other efforts to provide consistency across the desktop (Gnome, KDE, whatever) all start off with the requirement of rewriting every single application to do so! What a colossal waste of time! But there is simply no other way, thanks to the legacy of X: thanks to X's refusal to dictate policy, there is no one policy to replace, there are dozens.
I get that idea from having spent ten years trying to squeeze every drop of performance out of X programs as I can. The inefficiencies that the design of the X protocol forces on clients are just staggering! All the handshaking back and forth between the client and server (and associated context switches) adds up really quickly. I see it every day -- I see operations that are fast in every window system that preceeded X slowing X programs to a crawl, and because I know X inside and out, I understand why. It's no mystery to me, it's because of the fundamental design decisions that went into the X protocol on day 1.
I have not done bechmarking, because I have had no reason to. I know X is slow, but I also know I'm stuck with it. However, if you want to try it out for yourself, try and do some simple 2D graphics that do double-buffering using Xlib. Now rewrite that same program using OpenGL (note that we're talking about 2D here, not 3D, no textures. Just line drawings.) Code both programs such that it replaces the image as quickly as it can, yet results in no perceptible flicker. Tell me which one runs faster. Here's a hint: it's the one that can touch the frame buffer in-process, rather than having to suck bits through a straw. (Use the joke of the X Double-Buffer extension if you like, and the XSHM extension. It won't help.)
Obvious, is it? So what you're saying is, ``Quake shouldn't use X.'' Which is to say, ``X is unsuitable for anything graphics-intensive.'' Which is my point.
You're missing the point again. It's not just the fact that there's a pipe involved, it's the fact that there is synchronization between multiple processes: one writes, and flushes, and then some time later the other becomes runnable, and eventually gets around to reading from the pipe, then talking to the hardware, then writing a response, then flushing it, and eventually the first process becomes runnable again and...
When window operations are involved, you often have to block waiting for answers from the window manager, resulting in a three-way cluster-fuck between the client, the server, and the WM. Oh, but isn't it great that they could be running on three different machines? Whatever.
Ah, we've reached that point already I see. We always get here whenever the failings of X, Unix, or anything else Linux weenies hold dear are discussed: the fallacy that, before one has the right to point out a problem, one must have already handed the world the solution on a silver platter. Well guess what, the fact that we're stuck with X forever (because it is completely entrenched) does not mean that X has no problems, or that those problems are not severe. There appear to be some people, like you, who don't understand the extent of those problems, so don't bitch at me for pointing them out, ok?
Bite me, fanboy.
SGI uses X, and they have an X server that is insanely optimized for their hardware. On top of that, for anything that actually needs to go fast, they use GL instead of X. Basically, they use X to allocate a rectangle, and then X stays out of the way. The GL library then talks to the hardware directly, without a zillion context-switches in the way.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
WTF? Do you recompile libc every time you compile your program? Are you aware of how libraries work?
Nice words, coming from someone who's too chicken-shit to attach their name to them. Don's one of the smartest people I know. Who are you and what have you done?
The fact that the window manager is not built into the server really doesn't have much to do with the client/server model. In a Windows-like library world, the window manager could as easily be a pluggable DLL with the same effect, but without taking the X hit of all the context switches and network traffic.
This, of course, is The Way of X. Got a problem that people have been suffering from for ten years? Fix it by adding yet another new and optional API! So now all the applications writers get to code their graphics routines twice, with lots of runtime feature-checking. Have you ever written X code that made use of XSHM, the shared-memory extension? Did you do it in such a way that your program actually worked when the extension didn't exist? Are you sure? Did it still work when the extension existed on the server, but the server was on a different machine? Are you sure? (In my experience, 99% of the programs that try get it wrong.)
This is no way to fix a bug. X's refusal to add required features to the protocol (SHAPE is still optional, for pete's sake!) makes life hell for application writers until the end of time. Or leaves users with applications that mostly work most of the time.
Guess what, Netscape doesn't (and can't) use XCopyArea for scrolling. Because that just moves bits, not subwindows (think form elements.) Netscape plays crazy tricks with window gravity to move all the windows at once, since the alternative (moving each subwindow by hand) is insanely slow.
But probably the reason you see flicker isn't really X's fault, but is because the table redisplay code isn't great.
In a word, wrong.
X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.
Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations.
For the dubious feature of sometimes being able to have clients and servers on different machines, you pay the price of never being able to have decent performance in the common one-machine case.
This sense of entitlement is appalling. If you didn't want it to be possible for someone else to take your work and make money off of it, then you should not have given them explicit permission to do so by using an open source license on your contribution! How hard is that to grasp? Red Hat owes you nothing, because they are only doing exactly what you expressly told them they were allowed to do.
It's a very nice gesture for them to have extended this offer, and it's too bad that some people aren't allowed to participate because of factors outside of Red Hat's control. But the way so many of you are acting like something you deserve has been taken from you is just sickening. Grow up.
I would think that hackers would have a better understanding of how this stuff works: if you want to play a game, first you need to understand the rules.
E*Trade has rules, and the SEC has rules, and apparently most of you weren't even aware that they existed. That should be a pretty strong indication that you don't know enough about this game to play. Whine all you like about how this should be your decision, not E*Trade's and not the SEC's, and that you should be allowed to do any stupid thing you want, but the bottom line is, it's not your decision, and there's nothing you can do about it this week. (If you like, campaign to get the SEC's rules changed. Good luck.) You're shouting at the wind, here, people. These rules have existed for a long, long time, and they're not Red Hat's fault.
Perhaps if you do some research, and actually understand the rules of this game, you'll still be able to get in on the deal. Perhaps you'll even be able to do so without breaking any laws. You certainly won't be able to do so without risk -- nobody can. But no, whining on Slashdot like spoiled children because someone didn't make it even easier for you is less hassle.
Red Hat tried to do something nice (out of generosity, not debt), and you're beating them up for it. When someone gives you a gift that, for whatever reason, you can't use, you're supposed to thank them anyway, not start screaming.
I never said that.
Uh, maybe that's because Snow Crash was comedy and Neuromancer was noir? I'm always amazed at how many people totally miss the joke, and don't realize that Snow Crash is at least half parody of the very genre it is putatively a member of.
I loved Snow Crash, but comparing it to Neuromancer is like comparing ``Dr. Strangelove'' and ``Fail-Safe.''