My interpretation of Daneel's development of the Zeroth Law was that he had finally become human.
The entire series of Daneel detective books (Caves of Steel, etc) dealt with Daneel's evolving human characteristics: friendship, loyalty and honour. I saw the Zeroth Law as his final understanding that advancing humanity was the greatest accomplishment any human could make. The human's time for living is short (unlike the almost immortal Daneel) so it is only through great accomplishments that humans can live forever. When Daneel recognised this, he was able to postulate the Zeroth Law, and also was able to believe in it strongly enough to break the other laws without burning out his circuitry.
Xerox didn't invent the desktop metaphor. PARC took a lot of neat ideas from lots of places, added some neat hacks of their own, and put it all together in one place.
Engelbart had a desktop metaphor of sorts literally decades before PARC.
In fact, Engelbart must hold a record for being the sole contributor of so many incredible hacks.
I see you've never done professional CAD work before. For the most part you only ever do 2d work. Schematics are handed to the machinist, and machinists do not want 3d drawings.
Apart from that the upgrade went flawlessly. Didn't lose any data. Didn't lose any apps. The only thing I care about that stopped working was Frotz.
Oh, and the new version of Hardball is now way too fast to play and causes a crash when it exits. This was the 3.3 version included in the upgrade.
Also this might be my imagination, but it seems as if my Palm III is faster now. I could be dreaming, but it seems as if the ToDoList app is faster when bringing up ToDos. Similarly, the Applications app seems to be faster when switching between groups.
Has anyone else noticed a speedup? Is this perhaps just due to the defragment my Palm got when it did the upgrade (full reset and resync)? Maybe I'm just delusional?
I'm happy with the upgrade. I've lost a few apps, but the 2x speedup on HotSync more than compensates for that. And the IR HotSync looks like fun.
I don't want to say anything about "Why Women Aren't Geeks". It seems everyone here has their own opinion (social, political, brain 'wiring', upbringing) and honestly all they are is factless opinions. The truth of the matter is that there simply are fewer Women Geeks.
Now I see this everywhere. The jobs I've worked, the computing clubs I frequent, even the close circle of friends I have. There are a few female geeks, and some of them are computer literate to a high level, but they are always outnumbered by the male geeks by a factor of 10.
And I don't think this has anything to do with the actual people I know. When there's an all night party, or a drinkup at the pub, or a campout, or a trip down the beach, or a video night, there is always a fair 50% representation of both genders. But when you have a LAN party you can count the number of females on one hand.
Now I think this is changing. I'm seeing more female geeks now than I used to. More girls are finding the games fun and joining in the LAN parties, or having "their turn" on the consoles when you're lounging on the couch. I reckon that the proportion of male/female geeks is starting to naturally balance out. So what worries me is that the next generation is going to churn out a higher proportion of female geeks, and that Carnegie Mellon is going to incorrectly think that they had anything to do with the increased numbers. This is bad science for a start (no control group), and it's going to lead to bad conclusions (race/gender inequality can be solved by throwing money at it).
The other thing that concerns me is the statement in the article that you don't see many multimillionaires who are female geeks. Well to be completely honest you don't see all that many multimillionaire geeks of either gender. Computing isn't the land of milk and honey. Most of the truly great computing minds are not rich. Most of the time it's the venture capitalists (Cisco) or the salesguy (Gates, Jobs) who gets rich while the true computing geek gets a lesser amount (Allen, Wozniak). And the real geeks, the ones that should be admired for their pure geek value, seem to get nothing at all (Engelbart, Ritchie, Knuth). If you want to get rich off computing, become a venture capitalist and study economics at university, do not become a geek!
It's really strange. If someone said "is Linux ext2 the way of the future?" then nobody would pipe up. People would realise that they don't understand the issues well enough to comment. But ask "is X the way of the future?" and suddenly everyone has an opinion, whether they've ever written X code in their lives be damned. Writing a DOS starfield demo in assembly does NOT make you the leading expert on platform independent windowing systems.
But look at the "reasons" given by the X haters and the revolution wanters!
X is hard to setup: here's a clue, this has nothing to do with X, it has something to do with PC hardware, changing windowing system isn't going to solve this.
Xlib is hard to write: it's hard to write anything if you use the lowest layer possible. Try using the appropriate API layer for the task, not the absolute lowest layer possible.
X doesn't support (alpha blending, multiple keyboards, 3d window managers, virtual 3d glasses, my thrustmaster joystick, insert crackpot feature here): guess what, X version 1 didn't support colour! Things evolve. Linux 0.4 didn't have a TCP/IP stack and Linux 1.0 had flaky support for pretty much any hardware you had available, would you have been crying "Linux is not the future!" back then?
X is slow because of (crackpot self-formed opinion that has never been verified by tests, and never will be because crackpot suggesting person has no idea what they're talking about): here's what illuminary Keith Packard has said about the matter.
This implies that the entire X window system, including TCP/IP, is faster than the lowest level of a typical NT graphics driver. Even when the target is an ancient NCD X terminal (nearly nine year old technology).
Now Keith doesn't stop there. He points out that half the problem with X isn't X itself, but the very stupid widget sets (Xt, Motif, even GTK) that waste too much time in expose events.
If people who whined about X performance ever had some figures to backup their claims (and not just lines/second under WinNT and lines/second under a XFree86 driver, I'm talking definitive proof that X is the fundamental slowdown, not a badly written driver, or a badly implemented X server) then they might have an opinion worth listening to, but the "X is slow" crowd seem to have nothing to offer but hot air and loud mouths and NO HELPFUL IDEAS OR PATCHES.
Here are some real clues. XFree86 4.0 has support for TrueType. It has support for multimon (multiple desktops over multiple monitors). It has support for Xinerama (single desktop over multiple monitors). It has Xinput (joysticks, tablets, mice and whatever). It has DGA 2 (resolution AND depth switching on the fly, direct framebuffer access as fast as SVGALIB). It has DRI (bypass X pipe to avoid layers of inefficiency when doing hardware accelerated graphics). It has Xv (X knows about hardware which blits over your framebuffer, like TV capture cards). It has modularised drivers (so you can easily add support for your video card, and the documentation on how to do so is easy to follow). It has one of the most efficient ways possible of communicating in an ORDERED fashion between many clients and a single framebuffer (local sockets). It has some of the smartest brains in graphics history working on it, and these people know what they're talking about, unlike half the rabble who have replied to this slashdot topic with their own uninformed opinions.
Afterall, Linux has it's flaws as well (and I'm not talking INSTALLATION or PENGUIN GRAPHICS WHEN IT BOOTS, I'm talking about the SCSI MIDLAYER and the ISDN LINKLAYER) but would the proper fix be to throw Linux away and write a brand new kernel? Of course not, yet a windowing system is 100s of times more complicated than the Linux kernel and it seems that people think throwing code away is appropriate here. All that implies to me is that the X haters have no idea what they're suggesting.
I advise people shutup about things they don't understand. If there is a problem in X, try fixing it, rather than complaining about it, or suggesting that the proper fix is to reimplement the 100s of 1000s of man hours of design, testing, coding and fixing that has gone into X.
There are a number of design flaws with X, though I think the commonly claimed ones are pure madeup nonsense. Here are some of the real ones.
--
1) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
More modern windowing systems (such as Display PostScript) let you store procedures/methods on the server. You can create a method DrawRoundBox which performs the 8 operations. Then you send only 1 command to draw rounded boxes.
Server stored methods don't seem to be popular though. Probably because the server is far more complicated, needs far more ram, and in practice the overhead of the device independent language outweighs the benefits of reduced pipe traffic.
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
If you think about it, all systems need some way of synchronizing multiple client requests to the display, and a pipe does so neatly. No serious windowing system uses clientspace functions which directly modify the framebuffer!
So the actual problem is how to keep the pipe but decrease the time spent copying pixmaps over this pipe. And remember, this is only for the benefit of programs which heavily blit the display (quake or xanim are perfect examples).
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer. No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
Take note that MacOS/Win32 (the components which can be compared to X11) work exactly like X, with queued messages to communicate between clients + display and a direct graphics access mode for any apps that need high speed unencumbered blits.
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Font and cursors were also implemented as bitmaps instead of pixmaps. This means you get black/white fonts with no anti-aliasing against the background colour. It also means that cursors look ugly and have limited capabilities.
The only solution here is to extend the protocol (ie start coding X12).
4) X has tonnes of legacy baggage. This can't be argued against either. XResources? Great idea, but don't seem to be used very much. XIntrinsics? Not a bad idea, no widget set seems to use them. XPrt? Exactly the same as GDI or QuickDraw printing, but nobody in the X world wants to use it. Support for DECNET? Throw away that baggage!
--
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
The question is not whether Linux or WinXXXX wins; the question is, what will replace both of them?
What will replace Linux? Why, Linux, of course.
People don't seem to realise, or intentionally try and ignore, the fact that UNIX has changed significantly in the past ~30 years. Early UNIX didn't have sockets or streams, didn't have mmap or virtual memory, no support for asynchronous IO or select or poll, and certainly nothing fancy like VFS or network support. Even the sticky bit on directories is a relatively recent invention!
UNIX evolves, just like Linux evolves, when a user gets an itch and needs it scratched. We use a UNIX today that bears only a token resemblance to the UNIX that Thompson wrote. And even then, that token resemblance is often only in the abstract concepts of how UNIX should create processes and communicate between them. These things don't need to change, because they are fundamental concepts which are used by UNIX and competitors alike.
So I don't know what the future will hold, or what exactly will replace the Linux we use today, but I'm 100% certain it will be "UNIX", and I'm almost equally certain that the variant of UNIX we'll be using will be Linux.
It's not a simple matter of comparing high load Ethernet versus high load Token Ring and concluding that Token Ring is the superior technology. Both solutions have their pros and cons. Token Ring for example has multiple points of failure - each link in the ring must be up for the entire network to work - something which isn't true for switched Ethernet.
Ethernet is a suitable solution for low to medium bandwidth networks. Token Ring is better for slightly higher bandwidth networks. For extremely low bandwidth and extremely high bandwidth networks you look towards completely different solutions. Ethernet is by no means a "cheap and nasty" solution to the problem. In fact it's a fairly clever design, with the occasional warts that all technology has, based on well known and analysed theoretical networking principles.
He didn't call people who use M$ geeks. He called them warez puppies.
Keep reading past that point. He is replying to someone who has used an M$ variant, and then goes on to say...
It's one thing when we see the term once, but you look like a god damned warez puppy when you use them over and over. Not an ounce of logical thought shows through... and isn't that what geeks prize? Aren't geeks always bashing people who don't use their brains?
This reads quite clearly that a geek should know better, a geek shouldn't exhibit "not an ounce of logical thought", and geeks should "use their brains", and from the grammar you can see that the geek in this case is in the first person, ie the person he's talking to. It's obvious that he's telling the previous person that if they want to be a geek they should stop using terms like M$, because it is very ungeeklike to attack in non-technical or non-logical ways.
You're misunderstanding the term geek. It has a positive connotation in these circles.
And you're misunderstanding me: I'm well aware that geek is a positive term.
And being 30+ or having families has nothing to do with anything.
Well, as I said, it is my belief that being 30+ does have something to do with it. That was my assertion, the point of my post, the thrust of my argument. The greatest contributors to Linux are for the most part older, wiser, and often have a family to look after. My belief is that proper geekdom goes hand in hand with age, because with age often goes increased responsibility not only for yourself but also for others. It is by having this responsibility that you act in proper geeky ways: being rational, calm, collected, arguing in logical and technical ways rather than flaming or insulting.
I don't know how you go from drawing conclusions about the vast majority of/.ers based on emails to mindcraft sent by some morons.
I didn't base my assertion on this, and I don't see where you got the impression that I did. In fact I made no conclusions, only an assertion.
I don't see any logic in any of your assertions.:)
I only made one assertion, and it's pretty clear that you didn't understand it. Also you didn't argue against my assertion, instead you just presented your own differing assertion. I presented a reason for my assertion, whereas you just made some incorrect claims about what I think and therefore concluded that I was wrong.
I'm sorry, I think you're one of the geek wannabes I was talking about.
I don't know where you got the impression that AGP textures sit in system memory. Even in the very latest 3D boards they use onboard texture ram. You may get system memory textures with SGI hardware, but I for one can't afford SGI hardware.
Also, the problem I was referring to was a problem with X, not with hardware. X can clip and draw 2d rectanglar windows, nothing more. It can't work on windows with perspective. You could possibly do some very very nasty hacks with XShape, but there would be horrendous performance.
Remember X uses the principle of windows within windows, each window a 2d shape with a clipping area. You simply can't force a 3d interface into this model. You'd need a completely redesigned system that knew about depth, had 3 coords for a point, etc. This is because the root window and the window manager both use X as well: they aren't special cases which get exempted from the rules.
In other words, your idea is fine, but it doesn't mesh with the reality of the situation.
What makes you think the people who use terms like 'Micro$haft' are geeks? They're clearly not geeks because they're spending far too much time acting immaturely and writing foul mouthed email and not nearly enough time writing good quality code.
Linux attracts a broad spectrum of users, but I strongly suspect that the geek population of Linux is a lot lower than many people think. Forums like Slashdot which try and promote Linux as a "geek" culture don't help matters one whit. It's a case of geek implies Linux, not Linux implies geek.
In fact, I'd also be willing to bet that the vast majority of true contributors to Linux are of a reasonble age (30+) and have responsibilities of a family or job. These people often have the skills and acquired wisdom necessary to write truly great code, something that younger coders often don't have (even if they think they do). I would expect a few rare exceptions, but there always are.
Which means that the vast majority of Linux users are non-contributors. They are either teenagers or in their early 20s. They don't have any real kinds of responsibility. They may have reasonable skills but lack the wisdom and experience to apply it.
Is it any wonder that given these people as the majority of "advocates" then all Linux users come across in general as childish immature imbecilic dolts? That is the current opinion regarding Linux users amongst computer professionals I know, and opinions like this are not formed lightly.
I would like to see 3d accel for full screen / non X targets. Being forced to run X to access 3d acceleration seems like a waste of resources when all you want to do is play kickass fullscreen video games.
Have you ever actually measured the overhead of X11? I don't mean have you watched your disk swap while starting up Enlightenment and GNOME and fifty xterms and a 2Mb JPEG background and backing store because it's "kewl" and ten thousand fonts (because you obviously need ALL the Type1 and Speedo and TrueType fonts), crying while 128Mb of ram suddenly becomes "not enough".
I mean have you turned off all the superfluous fonts, started up an X11 server, not loaded silly background images, started a single non-bloated client (which neatly rules out xterm), and then used a decent memory analysing tool which shows actual usage just by that application (remember a lot of tools show you a total which includes the shared glibc libraries, which is RAM you wouldn't get back by killing the X server).
It's about 1500kb on my machine. Not a great deal of overhead really. Especially seeing as that for this 1500kb you get scaled fonts, hundreds of drawing primitives, proper clipped windows, XInput handling, authenticated access, and remote network access.
Now if you want to argue that existing X11 is slow because you're drawing down a pipe, I don't disagree. Fortunately, that's what this Direct Rendering Interface thing is all about! It avoids the overhead caused by the X11 pipe by not using it. In other words, there's nothing wrong with using X11 for a game, not with DRI and DGA. There simply isn't as much overhead as the (uneducated) would like to believe, and X11 isn't that much of a resource hog (not compared to similar solutions).
Remember there's more to a game than just fast graphics. You also need good input device. The GII project is trying to address this, but XInput is here now, and it isn't all that bad, and it's very well integrated into X11.
Does this mean I'll finally get to use a version of enlightenment that lets me push and pull windows further and closer to me?
Possibly, but it'll have nothing to do with the direct rendering code. A window in X11 will still be 2D. The direct rendering code simply means that GL code can render directly into a 2d window, so you bypass lots of copies and buffers that normally get in the way and slow you down.
A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.
What direct rendering does mean is that there is no point in having SVGALIB applications or GGI3D games. The X11 solution will be within 5% of the same speed but will work with less effort, will be tightly integrated with XInput, will support a much richer drawing API, and will be network transparent with no effort (GLX to remote terminals really is impressive; imagine playing GLQuake on a server which is sitting in the next room).
For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc).
I'm almost ashamed to say it, but I have to agree with you. I enjoyed Linux more back when it came on 5.25" floppies (3 of them) and the installation instructions said "use fdisk and mke2fs to format your hard disk, then cp this floppy onto it".
Sure, it wasn't easy to use. Sure, it wasn't even that impressive: it was slow, buggy, didn't have half the features my copy of Interactive had, and even my SCO box made Linux look like a cheap and nasty toy.
But I enjoyed Linux because it was FREE. Proper free. Free speech. It was liberating. I didn't care that Linux was crap. I was happy to see the rekindled interest in free software, proof that software didn't have to hide behind locked doors.
Now Linux has become just a face among many. So many people don't realise that Linux would be the better OS even if it isn't as fast. Even if more users choose MacOS or BeOS or Windows. Even if it was harder to use, or slower, or crashed more.
RMS recently gave a speech at the ANU where he expressed the same concerns. People using Linux should be exalted by the realisation that they have experienced something that was well on it's way to becoming extinct. Instead too many users think only of destroying Microsoft, of having an impressive number of users, or having elite new features and all the latest buzzwords. Don't get so impressed by the glitz that you lose sight of the goal.
While I can sympathize that you lacked resources to get certification in the traditional sense, I don't think this excuses the fact that the vast majority of Information Technology workers I have to deal with are simply INCAPABLE of doing their jobs due either to inexperience, incompetence, or downright stupidity.
Regulation of the industry is necessary. There are (I believe) more shysters in IT than any other field of "intelligent" work. I've dealt with IT companies that have overquoted on projects by 50 times or more, have sent out network experts who didn't understand basic concepts of TCP/IP routing or subnetting, and damn rotten corporations (most of them have as names 3 letter acronyms) who will take college graduates and palm them off to the client at 11 times the salary the graduate will see, often claiming these graduates have skills that our either exaggerated or downright false (like the firewall expert who didn't actually know what a firewall was, or the C++ programmer who had 2 weeks book experience and had yet to use a C++ compiler).
I can understand your position, that regulation would have had an adverse affect on your chances, but the alternative is that the customer continues to be ripped off by greedy companies and clueless workers. Perhaps instead of being against the concept of regulation you should be looking for (and even promoting) methods of regulation that are based on real world achievements rather than upfront payments. In this way you would not have been affected, nor would other people in a similar situation to yourself.
I'm not an expert on The X Window System, so I really don't know what a viable solution would entail. I'm just throwing this out: What if we were to make an extension to Xlib that would ask the X Server if it would allow the Xclient to mmap part of the framebuffer (it's client area) or just mmap the entire thing? All subsequent Xlib calls would write to the framebuffer.
You're too late, it's already been done. It's called DGA (Direct Graphics Access) and has been part of modern X servers for a while now. With a DGA application you get *equal* performance when compared to FB or SVGALIB.
The obvious examples of well written DGA apps include XMAME and SNES9X.
DGA even works exactly like you suggested. It lets you mmap the framebuffer.
The MITSHM solution others have pointed to is simply not good enough. You still get bogged down in the X socket, so there are a couple of wasted copies involved, and performance degrades fairly noticeably. DGA is the better solution.
UNIX (LOCAL) sockets speed this up by about 100% (or more or less, depending on the implementation), but it's still fundamentally flawed.
Please be careful to know that though sockets are "fundamentally flawed" (in that sockets are always going to reduce performance), the concept of X isn't fundamentally flawed. SGI uses mmap'd ring buffers for local clients, avoiding all the issues with system call overhead. SGI manages to retain the benefits of the X abstraction without sacrificing performance. They just used cleverer X-server code.
Remember that all good systems will sacrifice some speed for a good abstraction. Even Linux is guilty of sacrificing that extra 10% performance to keep the nice UNIX abstraction. X is a really nice abstraction, so don't blame it for losing a few percentile points of performance.
Also, the XFree86 team could really do with a lot more coders. X is easily as complicated as a UNIX kernel, if not more so, but they have a lot fewer people working on XFree86 than work on the Linux kernel! There are a lot of very cool ideas that X can do - stuff invented by SGI - that the XFree86 group would like to do, but without good coders these ideas will never be implemented. If you want a real project to get your teeth into then XFree86 is challenging: drivers aren't the only things XFree86 members work on! And, if you really like 3D stuff and OpenGL, then now is the right time to help work on XFree86!
Slashdot Mirror
You better make gibs, you better get frags
You better shoot grunts, zombies and scrags
Santa Carmack G-P... L'd Quake
He's written some code, debugged it all twice
Then made it all free, isn't that nice
Santa Carmack G-P... L'd Quake
He knows when you've been fragging
He knows when you've got quad
He knows when you've just rocket jumped
'Cause Carmack is Quake God
So don't you be lame, don't you not play
Join a net game, I'll frag you today
Santa Carmack G-P... L'd Quake
My interpretation of Daneel's development of the Zeroth Law was that he had finally become human.
The entire series of Daneel detective books (Caves of Steel, etc) dealt with Daneel's evolving human characteristics: friendship, loyalty and honour. I saw the Zeroth Law as his final understanding that advancing humanity was the greatest accomplishment any human could make. The human's time for living is short (unlike the almost immortal Daneel) so it is only through great accomplishments that humans can live forever. When Daneel recognised this, he was able to postulate the Zeroth Law, and also was able to believe in it strongly enough to break the other laws without burning out his circuitry.
Xerox didn't invent the desktop metaphor. PARC took a lot of neat ideas from lots of places, added some neat hacks of their own, and put it all together in one place.
Engelbart had a desktop metaphor of sorts literally decades before PARC.
In fact, Engelbart must hold a record for being the sole contributor of so many incredible hacks.
This is pure and utter tripe. The correct statement is that entropy increases in any CLOSED system over time.
Your RedHat box is not a closed system. Your administrative input decreases the entropy.
It's not hard to keep a UNIX box neat. It just requires patience and some small effort.
My real peeve here is the thermodynamics bollocks: I guess I've been reading talk.origins too much lately...
I see you've never done professional CAD work before. For the most part you only ever do 2d work. Schematics are handed to the machinist, and machinists do not want 3d drawings.
Frotz just resets. No more Zork! Sob.
Also Patience has stopped working completely.
Apart from that the upgrade went flawlessly. Didn't lose any data. Didn't lose any apps. The only thing I care about that stopped working was Frotz.
Oh, and the new version of Hardball is now way too fast to play and causes a crash when it exits. This was the 3.3 version included in the upgrade.
Also this might be my imagination, but it seems as if my Palm III is faster now. I could be dreaming, but it seems as if the ToDoList app is faster when bringing up ToDos. Similarly, the Applications app seems to be faster when switching between groups.
Has anyone else noticed a speedup? Is this perhaps just due to the defragment my Palm got when it did the upgrade (full reset and resync)? Maybe I'm just delusional?
I'm happy with the upgrade. I've lost a few apps, but the 2x speedup on HotSync more than compensates for that. And the IR HotSync looks like fun.
Welcome to High School, please leave your dignity and freedom with the policeman operating the metal detector.
I don't want to say anything about "Why Women Aren't Geeks". It seems everyone here has their own opinion (social, political, brain 'wiring', upbringing) and honestly all they are is factless opinions. The truth of the matter is that there simply are fewer Women Geeks.
Now I see this everywhere. The jobs I've worked, the computing clubs I frequent, even the close circle of friends I have. There are a few female geeks, and some of them are computer literate to a high level, but they are always outnumbered by the male geeks by a factor of 10.
And I don't think this has anything to do with the actual people I know. When there's an all night party, or a drinkup at the pub, or a campout, or a trip down the beach, or a video night, there is always a fair 50% representation of both genders. But when you have a LAN party you can count the number of females on one hand.
Now I think this is changing. I'm seeing more female geeks now than I used to. More girls are finding the games fun and joining in the LAN parties, or having "their turn" on the consoles when you're lounging on the couch. I reckon that the proportion of male/female geeks is starting to naturally balance out. So what worries me is that the next generation is going to churn out a higher proportion of female geeks, and that Carnegie Mellon is going to incorrectly think that they had anything to do with the increased numbers. This is bad science for a start (no control group), and it's going to lead to bad conclusions (race/gender inequality can be solved by throwing money at it).
The other thing that concerns me is the statement in the article that you don't see many multimillionaires who are female geeks. Well to be completely honest you don't see all that many multimillionaire geeks of either gender. Computing isn't the land of milk and honey. Most of the truly great computing minds are not rich. Most of the time it's the venture capitalists (Cisco) or the salesguy (Gates, Jobs) who gets rich while the true computing geek gets a lesser amount (Allen, Wozniak). And the real geeks, the ones that should be admired for their pure geek value, seem to get nothing at all (Engelbart, Ritchie, Knuth). If you want to get rich off computing, become a venture capitalist and study economics at university, do not become a geek!
It's really strange. If someone said "is Linux ext2 the way of the future?" then nobody would pipe up. People would realise that they don't understand the issues well enough to comment. But ask "is X the way of the future?" and suddenly everyone has an opinion, whether they've ever written X code in their lives be damned. Writing a DOS starfield demo in assembly does NOT make you the leading expert on platform independent windowing systems.
But look at the "reasons" given by the X haters and the revolution wanters!
X is hard to setup: here's a clue, this has nothing to do with X, it has something to do with PC hardware, changing windowing system isn't going to solve this.
Xlib is hard to write: it's hard to write anything if you use the lowest layer possible. Try using the appropriate API layer for the task, not the absolute lowest layer possible.
X doesn't support (alpha blending, multiple keyboards, 3d window managers, virtual 3d glasses, my thrustmaster joystick, insert crackpot feature here): guess what, X version 1 didn't support colour! Things evolve. Linux 0.4 didn't have a TCP/IP stack and Linux 1.0 had flaky support for pretty much any hardware you had available, would you have been crying "Linux is not the future!" back then?
X is slow because of (crackpot self-formed opinion that has never been verified by tests, and never will be because crackpot suggesting person has no idea what they're talking about): here's what illuminary Keith Packard has said about the matter.
Now Keith doesn't stop there. He points out that half the problem with X isn't X itself, but the very stupid widget sets (Xt, Motif, even GTK) that waste too much time in expose events.
If people who whined about X performance ever had some figures to backup their claims (and not just lines/second under WinNT and lines/second under a XFree86 driver, I'm talking definitive proof that X is the fundamental slowdown, not a badly written driver, or a badly implemented X server) then they might have an opinion worth listening to, but the "X is slow" crowd seem to have nothing to offer but hot air and loud mouths and NO HELPFUL IDEAS OR PATCHES.
Here are some real clues. XFree86 4.0 has support for TrueType. It has support for multimon (multiple desktops over multiple monitors). It has support for Xinerama (single desktop over multiple monitors). It has Xinput (joysticks, tablets, mice and whatever). It has DGA 2 (resolution AND depth switching on the fly, direct framebuffer access as fast as SVGALIB). It has DRI (bypass X pipe to avoid layers of inefficiency when doing hardware accelerated graphics). It has Xv (X knows about hardware which blits over your framebuffer, like TV capture cards). It has modularised drivers (so you can easily add support for your video card, and the documentation on how to do so is easy to follow). It has one of the most efficient ways possible of communicating in an ORDERED fashion between many clients and a single framebuffer (local sockets). It has some of the smartest brains in graphics history working on it, and these people know what they're talking about, unlike half the rabble who have replied to this slashdot topic with their own uninformed opinions.
Afterall, Linux has it's flaws as well (and I'm not talking INSTALLATION or PENGUIN GRAPHICS WHEN IT BOOTS, I'm talking about the SCSI MIDLAYER and the ISDN LINKLAYER) but would the proper fix be to throw Linux away and write a brand new kernel? Of course not, yet a windowing system is 100s of times more complicated than the Linux kernel and it seems that people think throwing code away is appropriate here. All that implies to me is that the X haters have no idea what they're suggesting.
I advise people shutup about things they don't understand. If there is a problem in X, try fixing it, rather than complaining about it, or suggesting that the proper fix is to reimplement the 100s of 1000s of man hours of design, testing, coding and fixing that has gone into X.
There are a number of design flaws with X, though I think the commonly claimed ones are pure madeup nonsense. Here are some of the real ones.
--
1) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
More modern windowing systems (such as Display PostScript) let you store procedures/methods on the server. You can create a method DrawRoundBox which performs the 8 operations. Then you send only 1 command to draw rounded boxes.
Server stored methods don't seem to be popular though. Probably because the server is far more complicated, needs far more ram, and in practice the overhead of the device independent language outweighs the benefits of reduced pipe traffic.
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
If you think about it, all systems need some way of synchronizing multiple client requests to the display, and a pipe does so neatly. No serious windowing system uses clientspace functions which directly modify the framebuffer!
So the actual problem is how to keep the pipe but decrease the time spent copying pixmaps over this pipe. And remember, this is only for the benefit of programs which heavily blit the display (quake or xanim are perfect examples).
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer. No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
Take note that MacOS/Win32 (the components which can be compared to X11) work exactly like X, with queued messages to communicate between clients + display and a direct graphics access mode for any apps that need high speed unencumbered blits.
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Font and cursors were also implemented as bitmaps instead of pixmaps. This means you get black/white fonts with no anti-aliasing against the background colour. It also means that cursors look ugly and have limited capabilities.
The only solution here is to extend the protocol (ie start coding X12).
4) X has tonnes of legacy baggage. This can't be argued against either. XResources? Great idea, but don't seem to be used very much. XIntrinsics? Not a bad idea, no widget set seems to use them. XPrt? Exactly the same as GDI or QuickDraw printing, but nobody in the X world wants to use it. Support for DECNET? Throw away that baggage!
--
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
What will replace Linux? Why, Linux, of course.
People don't seem to realise, or intentionally try and ignore, the fact that UNIX has changed significantly in the past ~30 years. Early UNIX didn't have sockets or streams, didn't have mmap or virtual memory, no support for asynchronous IO or select or poll, and certainly nothing fancy like VFS or network support. Even the sticky bit on directories is a relatively recent invention!
UNIX evolves, just like Linux evolves, when a user gets an itch and needs it scratched. We use a UNIX today that bears only a token resemblance to the UNIX that Thompson wrote. And even then, that token resemblance is often only in the abstract concepts of how UNIX should create processes and communicate between them. These things don't need to change, because they are fundamental concepts which are used by UNIX and competitors alike.
So I don't know what the future will hold, or what exactly will replace the Linux we use today, but I'm 100% certain it will be "UNIX", and I'm almost equally certain that the variant of UNIX we'll be using will be Linux.
It's not a simple matter of comparing high load Ethernet versus high load Token Ring and concluding that Token Ring is the superior technology. Both solutions have their pros and cons. Token Ring for example has multiple points of failure - each link in the ring must be up for the entire network to work - something which isn't true for switched Ethernet.
Ethernet is a suitable solution for low to medium bandwidth networks. Token Ring is better for slightly higher bandwidth networks. For extremely low bandwidth and extremely high bandwidth networks you look towards completely different solutions. Ethernet is by no means a "cheap and nasty" solution to the problem. In fact it's a fairly clever design, with the occasional warts that all technology has, based on well known and analysed theoretical networking principles.
Keep reading past that point. He is replying to someone who has used an M$ variant, and then goes on to say...
This reads quite clearly that a geek should know better, a geek shouldn't exhibit "not an ounce of logical thought", and geeks should "use their brains", and from the grammar you can see that the geek in this case is in the first person, ie the person he's talking to. It's obvious that he's telling the previous person that if they want to be a geek they should stop using terms like M$, because it is very ungeeklike to attack in non-technical or non-logical ways.
And you're misunderstanding me: I'm well aware that geek is a positive term.
Well, as I said, it is my belief that being 30+ does have something to do with it. That was my assertion, the point of my post, the thrust of my argument. The greatest contributors to Linux are for the most part older, wiser, and often have a family to look after. My belief is that proper geekdom goes hand in hand with age, because with age often goes increased responsibility not only for yourself but also for others. It is by having this responsibility that you act in proper geeky ways: being rational, calm, collected, arguing in logical and technical ways rather than flaming or insulting.
I didn't base my assertion on this, and I don't see where you got the impression that I did. In fact I made no conclusions, only an assertion.
I only made one assertion, and it's pretty clear that you didn't understand it. Also you didn't argue against my assertion, instead you just presented your own differing assertion. I presented a reason for my assertion, whereas you just made some incorrect claims about what I think and therefore concluded that I was wrong.
I'm sorry, I think you're one of the geek wannabes I was talking about.
I don't know where you got the impression that AGP textures sit in system memory. Even in the very latest 3D boards they use onboard texture ram. You may get system memory textures with SGI hardware, but I for one can't afford SGI hardware.
Also, the problem I was referring to was a problem with X, not with hardware. X can clip and draw 2d rectanglar windows, nothing more. It can't work on windows with perspective. You could possibly do some very very nasty hacks with XShape, but there would be horrendous performance.
Remember X uses the principle of windows within windows, each window a 2d shape with a clipping area. You simply can't force a 3d interface into this model. You'd need a completely redesigned system that knew about depth, had 3 coords for a point, etc. This is because the root window and the window manager both use X as well: they aren't special cases which get exempted from the rules.
In other words, your idea is fine, but it doesn't mesh with the reality of the situation.
What makes you think the people who use terms like 'Micro$haft' are geeks? They're clearly not geeks because they're spending far too much time acting immaturely and writing foul mouthed email and not nearly enough time writing good quality code.
Linux attracts a broad spectrum of users, but I strongly suspect that the geek population of Linux is a lot lower than many people think. Forums like Slashdot which try and promote Linux as a "geek" culture don't help matters one whit. It's a case of geek implies Linux, not Linux implies geek.
In fact, I'd also be willing to bet that the vast majority of true contributors to Linux are of a reasonble age (30+) and have responsibilities of a family or job. These people often have the skills and acquired wisdom necessary to write truly great code, something that younger coders often don't have (even if they think they do). I would expect a few rare exceptions, but there always are.
Which means that the vast majority of Linux users are non-contributors. They are either teenagers or in their early 20s. They don't have any real kinds of responsibility. They may have reasonable skills but lack the wisdom and experience to apply it.
Is it any wonder that given these people as the majority of "advocates" then all Linux users come across in general as childish immature imbecilic dolts? That is the current opinion regarding Linux users amongst computer professionals I know, and opinions like this are not formed lightly.
Have you ever actually measured the overhead of X11? I don't mean have you watched your disk swap while starting up Enlightenment and GNOME and fifty xterms and a 2Mb JPEG background and backing store because it's "kewl" and ten thousand fonts (because you obviously need ALL the Type1 and Speedo and TrueType fonts), crying while 128Mb of ram suddenly becomes "not enough".
I mean have you turned off all the superfluous fonts, started up an X11 server, not loaded silly background images, started a single non-bloated client (which neatly rules out xterm), and then used a decent memory analysing tool which shows actual usage just by that application (remember a lot of tools show you a total which includes the shared glibc libraries, which is RAM you wouldn't get back by killing the X server).
It's about 1500kb on my machine. Not a great deal of overhead really. Especially seeing as that for this 1500kb you get scaled fonts, hundreds of drawing primitives, proper clipped windows, XInput handling, authenticated access, and remote network access.
Now if you want to argue that existing X11 is slow because you're drawing down a pipe, I don't disagree. Fortunately, that's what this Direct Rendering Interface thing is all about! It avoids the overhead caused by the X11 pipe by not using it. In other words, there's nothing wrong with using X11 for a game, not with DRI and DGA. There simply isn't as much overhead as the (uneducated) would like to believe, and X11 isn't that much of a resource hog (not compared to similar solutions).
Remember there's more to a game than just fast graphics. You also need good input device. The GII project is trying to address this, but XInput is here now, and it isn't all that bad, and it's very well integrated into X11.
Possibly, but it'll have nothing to do with the direct rendering code. A window in X11 will still be 2D. The direct rendering code simply means that GL code can render directly into a 2d window, so you bypass lots of copies and buffers that normally get in the way and slow you down.
A windowmanager could potentially use direct rendering to blit into the root window, but X11 applications will still need 2d windows within the root window. So spinning windows or windows with perspective could at best be visual hacks in the root window, not real windows you can work with.
What direct rendering does mean is that there is no point in having SVGALIB applications or GGI3D games. The X11 solution will be within 5% of the same speed but will work with less effort, will be tightly integrated with XInput, will support a much richer drawing API, and will be network transparent with no effort (GLX to remote terminals really is impressive; imagine playing GLQuake on a server which is sitting in the next room).
For people who need that last 5% of performance and can't bear the thought of X11 using it, don't forget to turn off Linux when you start your games either, because it's chewing about 5% in lots of places too (disk, scheduler, buffer copies for the audio, etc).
I'm almost ashamed to say it, but I have to agree with you. I enjoyed Linux more back when it came on 5.25" floppies (3 of them) and the installation instructions said "use fdisk and mke2fs to format your hard disk, then cp this floppy onto it".
Sure, it wasn't easy to use. Sure, it wasn't even that impressive: it was slow, buggy, didn't have half the features my copy of Interactive had, and even my SCO box made Linux look like a cheap and nasty toy.
But I enjoyed Linux because it was FREE. Proper free. Free speech. It was liberating. I didn't care that Linux was crap. I was happy to see the rekindled interest in free software, proof that software didn't have to hide behind locked doors.
Now Linux has become just a face among many. So many people don't realise that Linux would be the better OS even if it isn't as fast. Even if more users choose MacOS or BeOS or Windows. Even if it was harder to use, or slower, or crashed more.
RMS recently gave a speech at the ANU where he expressed the same concerns. People using Linux should be exalted by the realisation that they have experienced something that was well on it's way to becoming extinct. Instead too many users think only of destroying Microsoft, of having an impressive number of users, or having elite new features and all the latest buzzwords. Don't get so impressed by the glitz that you lose sight of the goal.
While I can sympathize that you lacked resources to get certification in the traditional sense, I don't think this excuses the fact that the vast majority of Information Technology workers I have to deal with are simply INCAPABLE of doing their jobs due either to inexperience, incompetence, or downright stupidity.
Regulation of the industry is necessary. There are (I believe) more shysters in IT than any other field of "intelligent" work. I've dealt with IT companies that have overquoted on projects by 50 times or more, have sent out network experts who didn't understand basic concepts of TCP/IP routing or subnetting, and damn rotten corporations (most of them have as names 3 letter acronyms) who will take college graduates and palm them off to the client at 11 times the salary the graduate will see, often claiming these graduates have skills that our either exaggerated or downright false (like the firewall expert who didn't actually know what a firewall was, or the C++ programmer who had 2 weeks book experience and had yet to use a C++ compiler).
I can understand your position, that regulation would have had an adverse affect on your chances, but the alternative is that the customer continues to be ripped off by greedy companies and clueless workers. Perhaps instead of being against the concept of regulation you should be looking for (and even promoting) methods of regulation that are based on real world achievements rather than upfront payments. In this way you would not have been affected, nor would other people in a similar situation to yourself.
You're too late, it's already been done. It's called DGA (Direct Graphics Access) and has been part of modern X servers for a while now. With a DGA application you get *equal* performance when compared to FB or SVGALIB.
The obvious examples of well written DGA apps include XMAME and SNES9X.
DGA even works exactly like you suggested. It lets you mmap the framebuffer.
The MITSHM solution others have pointed to is simply not good enough. You still get bogged down in the X socket, so there are a couple of wasted copies involved, and performance degrades fairly noticeably. DGA is the better solution.
Please be careful to know that though sockets are "fundamentally flawed" (in that sockets are always going to reduce performance), the concept of X isn't fundamentally flawed. SGI uses mmap'd ring buffers for local clients, avoiding all the issues with system call overhead. SGI manages to retain the benefits of the X abstraction without sacrificing performance. They just used cleverer X-server code.
Remember that all good systems will sacrifice some speed for a good abstraction. Even Linux is guilty of sacrificing that extra 10% performance to keep the nice UNIX abstraction. X is a really nice abstraction, so don't blame it for losing a few percentile points of performance.
Also, the XFree86 team could really do with a lot more coders. X is easily as complicated as a UNIX kernel, if not more so, but they have a lot fewer people working on XFree86 than work on the Linux kernel! There are a lot of very cool ideas that X can do - stuff invented by SGI - that the XFree86 group would like to do, but without good coders these ideas will never be implemented. If you want a real project to get your teeth into then XFree86 is challenging: drivers aren't the only things XFree86 members work on! And, if you really like 3D stuff and OpenGL, then now is the right time to help work on XFree86!