C# is designed the way it is for trivial NGWS development.
as far as VC++ becoming standard compliant... expect some more C++ changes as well with VS7...some of which should make developing non-system code in C++ much nicer. Some of the demos of VS7 done today at Forum 2k were very nice.
C and C++ are simply too difficult for reliable applications programming. Why does someone want to worry about byte ordering or memory management for a web-service ? They _dont_.
Don't take this as my personal comments on the difficulty of using C.. I love and use C and C++ where appropriate. The justification for VB, and Java, C#, and other languages is that they dont need to be so close to the metal to get the vast majority of programming tasks done.
C# is more flexible and less targeted than Visual Basic, but much easier than C or C++. More importantly though, C# was designed around a COMponentized object model. For developing COM+ objects, C# will probably be the language of choice, although _any_ of the MS language products can be used to do so.
C and C++ _can_ be used for the sorts of things MS is envisoning, but they're awfully big hammers.
If you were/are in attendence at Forum 2k today, you might have seen their pretty slick Web Services dev tools...
it all uses SOAP for object/server interoperability.. and that protocol basically just moves XML around.. the keynote specifically said you can code these services with any language and you can serve content and do ASP hosting on any platform.. they specifically mentioned UNIX...
In order to do what MS wants to do w.r.t. to NGWS they're making it possible for anything to play ball with their stuff... as usual, they plan on differentiating based on ease of use and developer support
Well, im glad to see you like IRIX. (I like, and Use IRIX daily as well).
As far as threading in irix, it didn't work with shit until 6.4. NFS on irix has been problematic at times, leading to pesky things like kernel panics, etc. The 32->64 bit migration on irix has been pretty amusing, unless you've actually had to use 3rd party tools or libs for anything, in which case, its been nightmarish. (n32 tools are better, vendiors love to ship o32... sound familiar ?)
IRIX has faults just like any other OS. I still like it. There is a pretty wide market niche for solaris to fill, one that IRIX wouldn't fill as well. Namely, Solaris has the right mix of "stable", "easy", and "thorough" to make it a very viable operating system. Outside of the world of slashdot, there are plenty of people that agree with me:)
IIRC, the largest IRIX installtion is ASCI-Blue mountain, at 6144 processsors. This is _not_ a single machine image. O2k machines have only been implemented upto 256 cpus with a single image, althoug the O2k architecture should support 4096 (see Lewis and Berg: Pthreads)
XFS _is_ a fast file-system. But if you were a hardcore irix user then you know its taken XFS a while to be what it is. Back in the day when we were running 5.3 + XFS, things were different. Back then there was no xfs_check. They just assumed it would alwasy work. This is in the XFS design papers, btw. Or like the time when XFS patches broke any possibility of conveniently booting a downed SGI machine (all the media was 6.2, effectivly patchlevel zero, but subsequent patches to the OS made the on-disk XFS file-system unreadable and thus unrepairable to the on-cd kernel and tools)
These sorts of things tend to not happen with solaris. It's not nearly as esoteric, so it doesn't have the bleeding edge performance of IRIX. On the other hand, it is very feature rich, and very stable as well.
Like i said, right mix of stabl, easy, and thorough. Might as well add "cheap".
... And yours seems to be filled with a bit of zealotry.
I've heard alot of nasty things about solaris, including slow and insecure. However, I've _not_ heard "obsolete" before. How do you figure solaris as being obsolete ? Is it that bit about working kernel level threads ? Or intelligent SMP support ? Maybe you were talking about the obselete man pages that fully document the thread safety of nearly any function call. Perhaps you meant the obsolete software/hardware integration w.r.t. fault tolerance features. Maybe you were upset about solaris's obsolete NFS performance, which by the way, destroys that of both linux _and_ OpenBSD.
I won't make a judgement about which OS "sucks less", both are critical in what I do every day. OpenBSD is not the end-all be-all operating system, you should of course be wise enough to know that no operating system is. Until *BSD and Linux can pick up some of the features I've mentioned above, there is plenty of future left for solaris, and some of the other top-tier Sys-V based unicies.
As an amusing postscript, Ironically enough, where is Linux getting major patches and work done on some of these "enterprise" and scalability issues ? From SGI of course.. makers of IRIX.. the most universally loathed UNIX amongst free unix/BSD zealots.
As Tom stated in the end of the review, it is somewhat disasppointing. I was hoping the new Athlon would completely trounce the intel chip. Instead, intel beats it by a fraction on a couple of benches, and Athlon comes out significantly ontop in just a few scenarios.
Amusingly enough, if AMD wins, it will be because of price and availability, not sheer performance. I imagine there are benchmarks out there that Tom didn't present that might cast the athlon in a more favorable light.. theres no doubt in my mind that it's simply a better designed processor.
You're probably wrong. Tom Clancy (who is a fiction author, yes, but likes to be reasonably accurate) refers to a missile designed to shoot down lower orbit satellites; it's launched from an F-15 at a very high altitute.
A geosynchronus sattellite is at a pretty high altitude though... so I donno if you could nail one of those.
Actually, since over half of my work experience has been as sysadmin as opposed to programmer, im speaking from both sides of the fence.
I don't really see the utility of labeling me as an asshole, or calling me high-minded. I'm simply expressing my perception of the situation. The majority of jobs out there require degrees. For those that dont, degrees help in other ways.
It's currently the case that anyone that puts "linux" on a resumé can get a job doing entry level sysadmin work. Problem is, to advance past that you need to have demonstrated amazing talent and assertiveness. Finally, regardless of how good you are, typically not having a degree will close doors for you near the top. That may not be relevant to everyone, but I think alot of people are selling themselves short without realizing it.
I see lots of friends my age bailing on school so they can get a double-minimum wage job doing T/S or entry level admin work, but then they don't really get promoted significantly from that. The company knows they dont have a degree and in reality can't necessarily do alot better. This is especially true in parts of the country without large established technology companies and the corresponding geniune lack of qualified labor.
I personally view programming and system admin as different flavors of the same problem: making computers solve problems. Any decent sysadmin should be a magnificent programmer, so as to better write system tools. Any decent programmer should be a brilliant sysadmin so as to better understand their programming environment, and the non-program related factors in program execution and health.
Do you think most programmers fit this description ? Certainly not. Do you think most sysadmins fit this description ? Certainly not. One issue though is that I'd say its slightly easier to go from programmer to administrator than it is from administrator to programmer. I'll leave it to you to argue the point, but essentially being a good sysadmin means doing alot of reading and spending alot of time with your nose to the wheel. You can become a good programmer doing the same things, but you miss something without the broad perspective you get with a computer science background. Also, on a more practical level, I think companies are alot more willing to hire sysadmins without degrees then they are programmers without degrees. If you're a programmer with a degree, sliding into adminstration isn't necessarily all that difficult. If you're an administrator with no degree, I'm not sure it's as easy.
At any rate, do you think most sysadmins that take jobs working 24/hour on-call shifts making 40k/year are going to be going anywhere anytime soon ? Especially if they've written off getting a formal background in the theory and practice of computer science ?
In conclusion, obviously not all sysadmins are babysitters, and not all of them need a college degree. I'd argue that many admins that go right into the tech sector and pass up on a university education are doing so because they think their hot shit based on their ability to use autoconf and gcc. Thats the way I felt when I was in highschool; luckily I went through a university program and had my eyes opened a bit.
I know alot of systems people and only a few of them make it big without degrees. Those are the sort of people that do well regardless of industry or environment. There aren't many of them.
I don't claim to predict the future. Unless you have some insight into the matter, I suggest you act similarly.
As far as which platform has a larger installed base, what are you basing your claim on ?
I've got 6 machines in this room, not one of them has Qt. Two have GTK installed, but then both also have Motif. There's an additional machine which _only_ have Motif installed. In my situation, there are more machines running Motif than GTK+Qt combined.
I'm just a home user. Granted, I buy much of my stuff to get a wide variety of environments at home so that I can hope to be familiar with anything I come in contact with. As it turns out, every job I've ever had, the machines that were the life support system of the company were running Commercial UNIXes with Motif-derived environments. People that convinced management to let them install linux on their PeeCees would run whatever GUI they wanted, but no one cared and no one paid attention.
People with workstations on their desk invariably used the environment shipped with that workstation. IMO no UNIX vendor ships an environment that is so horribly broken it impedes the progress of work. Why tear up Indigo Magic, which is beautiful and functional, on an IRIX machine just so you can tile all the freeware apps you use with pixmaps ?
If linux based PC's start replacing commercial UNIX machines in more roles, I'd see a posibility for GTK/Qt to displace motif. Right now, neither of them is the foundation for any well known commercial app (well known == I've heard of it / used it.) Sure, GTK is the foundation of GIMP, which is reasonably popular, and sure, Qt is the foundation of KDE, which is reasonably popular. You're not going to see something like P/Spice for solaris written in GTK though. I doubt you'll find that Oracle installer re-written with GTK any time soon.
Linux is a moving target. GTK is a moving target. Qt is a moving target. Motif is installed everyhwere _relevant_. Peices of software that have long development cycles tend to like use APIs that dont have major design changes over the course of a few months.
When Qt and GTK are mature toolkits that are reasonably fixed and stable, then they'll be in a position to put Motif to rest.
It's a horrible stroke of luck that Athena ever had anything at all written for it that didn't start with "test_". That's what athena was designed for - a proof of concept widget set based on Xt.
Motif is the bread and butter of commercial UNIX programming. For a while Openlook sort of mattered, but that was only on shops that were SunOS happy.
The role of Motif in real unix environments has only been strengthened with things like CDE.
Like it or hate it, the Xt/Motif combo run most of the real X software out there. There are good things about Xt/Motif that are missing from other solutions, namele, the resource system. While its awkward to use and sort of ugly, coding for it is easy and modifying the behavior of binaries that pay good attention to resources (and all Xt/Motif programs do so easily) is trivial. AFAIK GTK and/or Qt lack the post-compile customizability of Motif. Don't bother me with "themes" either.
I'm curious to hear your rationale for dropping mathematics from a computer science curriculum.
You have several massive gaps in your reasoning
1) Computer Science programs dont churn out programmers, they churn out computer scientists.
If you want to learn to program, buy a book, or go to DeVry. If you want to learn to analyze problems and model solutions to them using computers, then perhaps having a computer science degree and knowing how to use various programming tools available to you is the call.
2) Computer science was originally just "applied mathmatics", and for salary reasons im sure lots of math departments wish it were still that way. You simply cannot be a relevant computer scientist without a large understanding of various types of mid-level mathematics. I went through this same argument yesterday in a curiculum meeting. Some computer engineering senior was trying to suggest that discrete math isn't important to a computer engineers degree. Things like logic, set theory, graph theory, and proof methods are the foundation of _everything_ we do today. If you think the internet is broken and shitty _now_, let me tell you what it'd be like without basic graph theory. OSPF _is_ Dijkstra's algorithm. Ever hear of a chip with an "n" layer process ? Software doing that layout models the circuit as a graph, and then figures out the embedded planarity. You can mathematically prove a circuit can't be made with fewer layers.
I remember when I was a jackass highschool kid that figured "i'll just get my degree so people will beleive how smart I am". I'm glad I bothered to go to school. I was an idiot. People that dismiss getting a higher education because they know how to install linux, are also idiots. Idiots that I won't hire.
There are a class of programmers that dont need lots of mathematical understanding. VB programmers, or some random perl scripters. Application programmers, basically. If you want to write "pay me $15 for this shitty peice fo windows shareware I wrote in a weekend" sorts of software for the rest of your life, by all means, get "C++ / MFC For Dummies!" and go on your merry way.
If you want to take the "i'll just do networking and admin" route, you're going to find out one of two things.
1) Either you'll learn to program through lots of scripting tools, and eventually you'll realize you need to look up some theory on computational complexity, if nothing else.
2) You'll basically a machine babysitter that never gets promoted and never gets rid of that pager.
I have 6 computers in my bedroom and 5 Operating systems. _None_ of them are linux anymore. As it turns out, nearly every jackass writing GPL software is running x86 redhat. And thats nearly all they test it with.
For instance. GNU autoconf is either intrinsically broken, or people dont ever figure out how to make useful configure scripts. I'm going to guess its the latter. Autoconf is supposed to _fix_ portability issues. Yet it _causes_ them. "Oh boy, now i can manually edit 237 levels of recursive gMakefiles - joy!". Would it have been so difficult to just allow --with-nonstandard-shit-like-gtk-installed-in=/not /usr/bin as an option to./configure ?
Honestly. My main boxes are Solaris SPARC and Irix. Anything _not_ written by linux junkies tends to work great. It's ridiculous though. I've got a _real_ machine that does _real_ GL, and half the software out there these days wants all my libraries to be named "Mesa*". _Mesa_ isn't the standard. OpenGL is the standard. Mesa is a means to an end.
Source code does _not_ a portable product make. It certainly helps, but fucking it up with _no_ consideration (or more likely, no exposure) to other OSes, and shitty./configure scripts just ruins anyones day that would like to try and experiment with that software.
I'm not sure if I should be surprised though. When I started using linux, it was "the alternative", and everyone was happy just to get it working, or to get some new feature implemented. I remember when redhat formed and their business model was "we're going to sell Linux on a CD, for alot more than the cost of the CD, because somehow, we add value to software other people wrote". How alien that was to SLS, MCC, and Slack 1.x users, back in the day.
Things have gone down hill from there. Now linux seems to be the hot ticket for all the former "0-day-warez" folks to latch on to. Can there be any question about the state of linux users today when it seems everyone is using "Bitch-X" and making screen shots of their "Themable desktop" ?
I'm all for improving linux and making it easy to use, etc. I'm _not_ all for the attitude that people seem to have taken---namely "linux is better than everything else - linux will take over the world!". While linux may take over the world someday, that day is very far off as long as there are a few rational people running systems that count.
Linux is a great idea. The attitude of many linux users, and many people who's first development experience is with linux, is fucking _awful_.
I saw this amusing quip a while ago, maybe the moderators will enjoy it:
"People that think linux is free obviously don't value their time."
Re:Help make games go faster on SMP boards!
on
Quad G4 Boards
·
· Score: 1
Actually, Carmack did a hand coded assembler version of the Q1 or Q2 renderer for Dual pentium machines. IIRC the best he could get was between 3% and 10% improvement over 1 CPU. It was due to the braindead way the Pentium CPUs did cache invalidation or something.
The other comment about most rendering being done on the video card is well taken. It doesn't make much sense to start writing SMP software renderers on the dawn of every PC having a T&L card. Games _should_ be written with SMP in mind, but you'd effectively only want one CPU doing gfx. Even on massive SGI's you tend to only want one thread working with a given rendering context, for context switching reasons.
Additional CPUs should be used for better responsiveness. The Sega Saturn machine used dual primary CPUs; this was in addition to its graphics and audio processors (it had like 8 processors total). It was said that in some fighting games, you'd assign the AI of one character to one CPU, and the other cpu would do everything else.
I'm not sure what the best way to utilize SMP in a gaming environment would be, but I can think of some scenarios. A dual processor configuration could be used sort of like an application-specific read ahead cache. Let one CPU be running the game, and when it realizes that it needs to spool a new world tile off of disk soon, it sends a message to the other CPU telling it to do it and to get everything set up. If you had enough ram, and the game was written properly, it'd be like "double buffering" but with game levels. At the end of a level you'd just move the "current level" pointer:) It makes even more sense for something like Asheron's call or a game that has a contiguous world environment. Obviously the whole world can't fit into ram at once, but you could use a smart algorithm to decide when the the other CPU should page sections of world in and out of main memory, for seamless access by the other CPU.
Of course, most game developers are buying engines from other companies, and just cranking out different textures and FMV sequences. I wouldn't expect a whole lot of game innovation any time soon, save for from a couple of well known companies:)
I wouldn't worry too much. One reason china hasn't acted against Taiwan yet is because theres a pretty good chance China would _lose_. PRC is basically in such a sorry state of affairs financially and militarily that they have no hope of launching a successful amphibious assault against Taiwan, which is _made_ of money and can afford any military toys that it wants.
China doesn't like anything about motinos of Taiwanese independence, but all they can really do about it is give Taiwan a big bloody nose.
China doesn't even have the top of the line russian stuff. and we're talking _russian_ stuff here. MIG-17s ? are you kidding me ?
Even the Chinese nuclear program is basically a non issue. If China were to deicde to go nuclear on Taiwan, yeah, Taiwan would get hurt badly but think of the repercussions against China. They'd expel most of their aresenal (estimates put the size of the Chinese nuclear stockpile at less warheads and less tonnage than a single US Ohio-Class sub).
Basically, I wouldn't worry about Via getting bombed:)
Read up on the Windows CE architecture. It is _not_ like Windows. The kernel is threaded from the ground up. Win32 is a layer you can throw ontop of the kernel. You can make a WinCE device thats nearly nothing like a Wintel platform.
Also, the Pocket PC UI was redesigned because they figured out that no one wanted the clunky size of the windows UI on a palm sized device. So they changed it.
I have a palm III and love it, but I for one am extremely excited abotu the Pocket PC platform. Wait this summer a bit. Built in suport for wireless networking ? Active matrix color screen ? Built in support for IBM Microdrive ? In the size of a Palm III ? You can bet I'm excited. I like the idea of a Palm and a Rio in one box. Not to mention you can run a _real_ browser on one of these things. The only similar thing on Palm is the Sprint PCS PDQ. And it sucks. Alot.
We should all remember to thank carmack and id for a couple of reasons
The reason PeeCees have respectable mainstream gfx hardware is because gamers wanted it. Multi-thousand dollar gfx cards have always been available for PeeCees, but now you can get a $200 board that outclasses all but the biggest/newest SGI boxes in terms of low quality poly-pushing power. Gaming has created the demand for faster/better gfx hardware, better memory busses, faster CPUs, etc. Nothing stresses the capabilities of hardware (and software!) more than gaming.
A great deal of the clueful computer population got their start playing games... perhaps even id/apogee games. I remember the days when you could buy the Commander Keen source code for like $400 or so to see how to write your very own EGA/VGA side scoller with pc beeper sound. id, computing, and the state of game design has come along way since then
Finally, everyone and their mom is cranking out games these days, but the _fun_ of the games isn't getting all that better. If not with technology and visual dazzlement, the place where id consistantly helps the gaming industry push forward is with the sheer fun value of the products they develop. When it comes down to it, a game is worthless unless its been play tested for months and still shown to be worth playing. I'd say that all of id's releases are still fun games to play, regardless of how long ago they were originally written.
1. They are unsure of running the system at high RPM's(above7200)that cars usually go
Actually, it all depends on the market conditions. I'm something of a BMW fan, and at least on the other side of the pond, BMW AG has been making Diesel engines for ever. Really slick ones at that. For instance the 740d is a 4 liter v8 diesel, which has more torque than the new M5. It's acceleration numbers aren't up to the best of the gasoline super cars, but its still making well over 200 horsepower and given that you get quite alot better gas mileage, _and_ diesel fuel is considerably cheaper in europe, diesel engines in european cars is basically a no brainer.
Finally, the RPM limit you refer to frankly doesn't matter. BMW released the "eta" engines in the US during the early/mid 80s when we were feeling some oil crunch. You may have seen BMW 325e's or 528e's, the "e" here means its got an "eta" (or "economy") engine which has a redline of right around 4200 RPM. However, they have a monsterous amount of torque at the low end which makes them very zippy for driving around towns. They're just not very ideal track cars:)
BMW diesel engines in germany are already using electronic common rail direct injection today. It's a shame that the US market has responded so piss-poor to diesel engines; the BMW 524td was only sold in the states for about a year, however the few people that got their hands on that vehicle are still driving them (usually with over 200,000 miles on the original engine).
First things First. The nVidia cards are hands down the best performing and best looking Game-class video cards for x86. Multiple people _left_ SGI to work at nVidia. SGI _sold_ graphics chipsets to nVidia. nVidia boards are made to be high quality 3d accelerators; this should be evident from how they exhibit very little performance degredation as resolutions/color depths are cranked up to the cards limits. Unlike Voodoo Cars, which tend to run well at low resolutions, and with low colordepths, the nVidia cards have always been rock solid 2d cards, and stellar performing 3d cards, at any resolution and any color depth.
nVidia employees have admitted that the current linux drivers suck, and obviously there is a great deal of performance work that can be done. I don't know that i'd hold my breath for open source drivers, but drivers that simply work and work well for a reference x86 and XFree86 platform would suffice to fill the largest hole. I would speculate that part of nVidia's reluctance to release drivers is because theres's frankly too much they'd have to released to get a respectable solution delivered. The "way to do 3d on linux" is still developing, and there are multiple parties taking multiple approaches to the problem. Which does nVidia support ?
At any rate, the point is, the nVidia cards have amazing performance and do not sacrifice visual quality or standards compliance to acheive this. Furthermore, nVidia has the cream of the crop working for them. Mark Kilegard (sp?), author of GLUT and previous SGI legend even works for them now.
On to OpenGL vs. Direct-X. Frankly, it's a apples vs oranges sort of thing. OpenGL is basically a way to make a uniform API for putting lines and triangles into a rendering context. It is _very_ low level. To get more useful functionality, you're typically going to be using GLU routines, as well as something like GLUT, libaux, or Open Inventor. It's good that openGL is _there_ for people that need to get that low occasionally, but run of the mill apps usually target GLUT or Inventor, as opposed to GL directly.
Direct-X, on the other hand, is a general purpose set of libraries to make doing interesting things fast(er) and uniform. Direct-X is much more tied to windows, and Windows hardware than GL is. Direct-X is also much more all-encompassing. GL doesn't even interoperate iwth the X protocol; thats what GLX is for. There's no intrinsic way to make an app take over the full screen with GL; every Direct-X program does this, as well as changing the resolution on the fly. Direct-X provides a uniform way to talk to all the sorts of hardware you'd like to talk to. There isn't a uniform sound API in Linux, (case in point: competeing sound libraries), much less a cross platform UNIX sound API. There are _no_ good API's for input handling in Linux, much less a cross platform UNIX method. While UNIX of course has nice networking features, there's nothing provided at a higher level than connect()/bind(). while thats enough to establish a socket, thats _not_ enough to make a good LAN-game subsystem. Any UNIX games need to build from the ground up.
Finally, lets get to the real apples-apples comparison here. Direct-3D vs OpenGL. Basically, OpenGL wins hands down for quality, standards compliance, ease of programming, and _performance_. It was once said (and i forgot by who), that the D3D system was so poorly written that it couldn't push enough triangles at the video card to make a difference; D3D itself was the limiting factor.
One area where D3D might do better than as-accepted GL is making performance tradeoffs. GL is marvelously inflexible when it comes to using/not using hardware acceleration. The most wonderful example of this is the SGI Indy R5000, with XZ graphics. Basically, the Indy's main CPU can do a much better job doing geometry calcs than the older XZ video board can. However, the GL subsystem sees a Geometry accelerated card in the system and immediatly dumps all the work to the gfx board. Downgrading video cards in this situation _increases_ performance. A similar situation exists when you define more lights in a scene than the hardware can efficiently support; suddenly everything sucks and you are left wishing there were a way to say "just do 95% of the stuff in hardware, leave the lighting to me!". Allegedly, Direct-X has ways to specify what does what job. That'd be handy.
Performance feedback is _possible_ with GL, but its not standard. SGI has many SGI-specific X-server and GLX extensions to do this. For instnace, theres an SGI extension for guaranteed framerates. If it thinks it wont be able to draw the current frame fast enough, it scraps it, draws it at a much lower resolution, then pixel-multiplies the rendered frame to fill the view-window size. Thus you get a constant framerate, but variable image quality. This is a great feature (assuming it works right), but again, its not a GL thing, its an SGI thing. It's something that games could greatly benefit from, but theres no standard way of doing it.
In summary, GL is great at what it does. I don't think anyone can argue against that. Likewise, D3D is awful at what it does, but Direct-X is a much needed layer for developers, for which there is nothing _close_ to a counterpart in the Linux, or UNIX world.
SGI's new x86 boxes should come out this year.. as early as may (according to my memory of comp.sys.sgi.*).
They'll be using the nVidia NV10 chipset (i want to say thats the GeForce 256 / Quadro stuff)
These will run SGI's linux. I have no idea how different it will be from what other people are used to, but I welcome it. SGI knows a hell of alot more about making hi performance system architectures, and the software (though usually proprietary) to exploit it than about anyone.
Initial configurations will be using intel chips IIRC, which is too bad. There will be single and multi-CPU capable machines.
Allegedly, these will have a _real_ GL/GLX implementation. Not this nonsense the x86 currently has.
You are 100% wrong. Intel has NEVER had a respectable FPU. Ever. AMD's Athlon FPU destroys the intel chips. The only thing you might be thinking of is how the early quake games required a Pentium CPU because the id boys hand tuned for the pentium FPU.. 486-class amd/cyrix chips obviously ran horribly here...(and were legitimately outclassed by the pentium FPU at the time)
another thing.. what exactly is a "real time floating point operation" ? RT operation seems like it should have alot less to do with a CPU then it would a system, and more importantly, the software side of that system. RT computing has alot more to do with enforcable upper bounds on wall clock time for a given operation than it does with 'fast fpu'. How a CPU deals with interrupts and cache misses, and under what conditions, and how this interacts with FP ops _might_ make this "topic" relevant.. but i can't believe that some people are saying "AMD" and others are saying "intel" and not expanding any more..
Linux is the true industry leader in regards to scalability and security
Linux is neither. UNIX like systems are arguably a poor choice for a secure operating system since they are so damn intent on providing service and flexibility. However, even amongst UNIXes Linux is no where _close_ to being the security leader. Try OpenBSD. Any mention of "security" that doesn't also include "openBSD is pretty much the most secure UNIX flavor in wide use" is at best unenlightened.
as far as scalability, see my earlier post. Linux does _not_ lead in scalability because of its poor SMP supprt and the poor scalability of the SMP hardware it can run on.
Finally, IRIX machines can and do stay up for long periods of time, and there are frankly a hell of alot more mission-critical multi-CPU irix machines than there are _total_ multi-cpu linux boxes.
Stop trolling. Linux isn't touching solaris in the data center market. It doesn't touch it in the scalability department, and the x86 hardware to run it isn't there even if it could.
If Linux is just killing Sun then why can't they stop making money hand over fist ? The fact of the matter is that Linux scalability plain sucks, and the answer has been "we're working on that" for at least 2 years. It _is_ getting better, but it is simply not up to par with OSes designed explicitly to handle the massive multi-cpu systems made by their vendors.
Finally, "Beowulf != Scalable". Last time i looked into it, beowulf was originally very much like an MPP and had made some inroads to providing functionality of single-image computing. The applications of linux's "clustering" are still quite narrow, and chances are most people that say they want beowulf clusters don't have any clue what they'd do with them.
Scalability for most people is something different. "Hey, i've got this webserver and RDBMS that are both thread-aware and thus can benefit from SMP machines..I'll just add more CPUs and RAM to this giant box and they'll automagically get better". Linux is an extremely poor choice for that scenario. The kernel locking is still much too coarse, too many sections are still non-reentrant, and the SMP hardware linux supports isn't particuarly scalable anyhow. Linux is _so_ poor a choice for true SMP computing that that was the area that made those amusing Mindcraft comparisions between Linux and NT realistic (i.e. NOT falsified). If you bother to look, the comparisons were using Multiple CPU boxes with Multiple Network cards. It shouldn't surprise anyone that NT did much better here, as at that time (and perhaps even still today) the linux IP stack was not re-entrant. The test took advantage of the fact that NT handled multiple device instances and SMP extremely well and Linux handled it extremely poorly. NT was designed for SMP from the ground up, with linux its been a progressive hack.
People who disagree are more then welcome to come up with facts---NOT trolls, to support their arguments. Postings which make unsubstantiated claims and predictions are basically useless.
someone mentioned that "you'd need to have worked with this stuff to hack it"
time and time again this has been shown to be blatantly false. People that design systems are not clairvoyant. Interested parties can and do infiltrate and learn about systems that they've never seen before. Reading old phrack articles should leave you quite convinced of this.
Unmanned military vehicles are no longer an experiment. They are a reality. They were used successfully in the gulf war - in reconassiance roles. However, more traditional aircraft and military systems roles are also being moved to unmanned versions. It is my understanding that the JFX (or is it JSF or JSX ?) is the last planned manned fighter aircraft. Well, this summer they had mated the two halves fo the fuselage. In other words, don't expect too many more manned fighters. Fighter aircraft can already far outperform the limits of their frail human pilots.
The military is and will continue to use unmanned vehciles in an increasingly aggressive/active fashion. Many current generation missiles are "fire and forget" -- this is software driving the missle to the target once it is released. Commercial airliners already more or less fly themselves. Putting all these peices together is all thats left.
Someone else mentioned that taking a machine off a public network insured that it would not be hacked. I can't think of a more foolish statement. Systems were getting hacked -- and much more thoroughly than they are today -- long before everyone "had internet". The mentality which says "private network == unhackable" is the mentality that I don't want near _Any_ computer network with sensitive data. VPN's are just a matter of encryption. Isolated LANs invariably have some private dial-in #. Think of this problem in terms of telco stuff. What telco gear do you know of thats hooked up to the net ? Ask yourself how often that stuff gets completely compromised and understood by cajoling teens.
As far as buffer overruns in military systems, I wouldn't count on it. For instance, the majority of the F-15s software is written in Ada. C typically is _not_ used, and for good reasons.
The facts are clear. The future of the military is software automation. If people take the attitude that they are doing enough to safeguard their software and networks, then they probably really aren't. Paranoia is the only answer.
Slashdot Mirror
PCfileviewer for solaris has no problems reading .DOC, excel files, or whatever.
.DWG iirc.
It can also do
Reading these files is easy.. writing may be more complex.
C# does _not_ use the JVM.
C# is designed the way it is for trivial NGWS development.
as far as VC++ becoming standard compliant... expect some more C++ changes as well with VS7...some of which should make developing non-system code in C++ much nicer. Some of the demos of VS7 done today at Forum 2k were very nice.
C and C++ are simply too difficult for reliable applications programming. Why does someone want to worry about byte ordering or memory management for a web-service ? They _dont_.
Don't take this as my personal comments on the difficulty of using C.. I love and use C and C++ where appropriate. The justification for VB, and Java, C#, and other languages is that they dont need to be so close to the metal to get the vast majority of programming tasks done.
C# is more flexible and less targeted than Visual Basic, but much easier than C or C++. More importantly though, C# was designed around a COMponentized object model. For developing COM+ objects, C# will probably be the language of choice, although _any_ of the MS language products can be used to do so.
C and C++ _can_ be used for the sorts of things MS is envisoning, but they're awfully big hammers.
If you were/are in attendence at Forum 2k today, you might have seen their pretty slick Web Services dev tools...
it all uses SOAP for object/server interoperability.. and that protocol basically just moves XML around.. the keynote specifically said you can code these services with any language and you can serve content and do ASP hosting on any platform.. they specifically mentioned UNIX...
In order to do what MS wants to do w.r.t. to NGWS they're making it possible for anything to play ball with their stuff... as usual, they plan on differentiating based on ease of use and developer support
Well, im glad to see you like IRIX. (I like, and Use IRIX daily as well).
:)
As far as threading in irix, it didn't work with shit until 6.4. NFS on irix has been problematic at times, leading to pesky things like kernel panics, etc. The 32->64 bit migration on irix has been pretty amusing, unless you've actually had to use 3rd party tools or libs for anything, in which case, its been nightmarish. (n32 tools are better, vendiors love to ship o32... sound familiar ?)
IRIX has faults just like any other OS. I still like it. There is a pretty wide market niche for solaris to fill, one that IRIX wouldn't fill as well. Namely, Solaris has the right mix of "stable", "easy", and "thorough" to make it a very viable operating system. Outside of the world of slashdot, there are plenty of people that agree with me
IIRC, the largest IRIX installtion is ASCI-Blue mountain, at 6144 processsors. This is _not_ a single machine image. O2k machines have only been implemented upto 256 cpus with a single image, althoug the O2k architecture should support 4096 (see Lewis and Berg: Pthreads)
XFS _is_ a fast file-system. But if you were a hardcore irix user then you know its taken XFS a while to be what it is. Back in the day when we were running 5.3 + XFS, things were different. Back then there was no xfs_check. They just assumed it would alwasy work. This is in the XFS design papers, btw. Or like the time when XFS patches broke any possibility of conveniently booting a downed SGI machine (all the media was 6.2, effectivly patchlevel zero, but subsequent patches to the OS made the on-disk XFS file-system unreadable and thus unrepairable to the on-cd kernel and tools)
These sorts of things tend to not happen with solaris. It's not nearly as esoteric, so it doesn't have the bleeding edge performance of IRIX. On the other hand, it is very feature rich, and very stable as well.
Like i said, right mix of stabl, easy, and thorough. Might as well add "cheap".
http://research.microsoft.com
MS doesn't sleep on much anymore. IPv6 work is being done now.
Sun also has some IPv6 mumblings, and a few developers were doing ipv6 stuff with linux like 2-3 _years_ ago.
... And yours seems to be filled with a bit of zealotry.
I've heard alot of nasty things about solaris, including slow and insecure. However, I've _not_ heard "obsolete" before. How do you figure solaris as being obsolete ? Is it that bit about working kernel level threads ? Or intelligent SMP support ? Maybe you were talking about the obselete man pages that fully document the thread safety of nearly any function call. Perhaps you meant the obsolete software/hardware integration w.r.t. fault tolerance features. Maybe you were upset about solaris's obsolete NFS performance, which by the way, destroys that of both linux _and_ OpenBSD.
I won't make a judgement about which OS "sucks less", both are critical in what I do every day. OpenBSD is not the end-all be-all operating system, you should of course be wise enough to know that no operating system is. Until *BSD and Linux can pick up some of the features I've mentioned above, there is plenty of future left for solaris, and some of the other top-tier Sys-V based unicies.
As an amusing postscript, Ironically enough, where is Linux getting major patches and work done on some of these "enterprise" and scalability issues ? From SGI of course.. makers of IRIX.. the most universally loathed UNIX amongst free unix/BSD zealots.
As Tom stated in the end of the review, it is somewhat disasppointing. I was hoping the new Athlon would completely trounce the intel chip. Instead, intel beats it by a fraction on a couple of benches, and Athlon comes out significantly ontop in just a few scenarios.
Amusingly enough, if AMD wins, it will be because of price and availability, not sheer performance. I imagine there are benchmarks out there that Tom didn't present that might cast the athlon in a more favorable light.. theres no doubt in my mind that it's simply a better designed processor.
You're probably wrong. Tom Clancy (who is a fiction author, yes, but likes to be reasonably accurate) refers to a missile designed to shoot down lower orbit satellites; it's launched from an F-15 at a very high altitute.
A geosynchronus sattellite is at a pretty high altitude though... so I donno if you could nail one of those.
Actually, since over half of my work experience has been as sysadmin as opposed to programmer, im speaking from both sides of the fence.
I don't really see the utility of labeling me as an asshole, or calling me high-minded. I'm simply expressing my perception of the situation. The majority of jobs out there require degrees. For those that dont, degrees help in other ways.
It's currently the case that anyone that puts "linux" on a resumé can get a job doing entry level sysadmin work. Problem is, to advance past that you need to have demonstrated amazing talent and assertiveness. Finally, regardless of how good you are, typically not having a degree will close doors for you near the top. That may not be relevant to everyone, but I think alot of people are selling themselves short without realizing it.
I see lots of friends my age bailing on school so they can get a double-minimum wage job doing T/S or entry level admin work, but then they don't really get promoted significantly from that. The company knows they dont have a degree and in reality can't necessarily do alot better. This is especially true in parts of the country without large established technology companies and the corresponding geniune lack of qualified labor.
I personally view programming and system admin as different flavors of the same problem: making computers solve problems. Any decent sysadmin should be a magnificent programmer, so as to better write system tools. Any decent programmer should be a brilliant sysadmin so as to better understand their programming environment, and the non-program related factors in program execution and health.
Do you think most programmers fit this description ? Certainly not. Do you think most sysadmins fit this description ? Certainly not. One issue though is that I'd say its slightly easier to go from programmer to administrator than it is from administrator to programmer. I'll leave it to you to argue the point, but essentially being a good sysadmin means doing alot of reading and spending alot of time with your nose to the wheel. You can become a good programmer doing the same things, but you miss something without the broad perspective you get with a computer science background. Also, on a more practical level, I think companies are alot more willing to hire sysadmins without degrees then they are programmers without degrees. If you're a programmer with a degree, sliding into adminstration isn't necessarily all that difficult. If you're an administrator with no degree, I'm not sure it's as easy.
At any rate, do you think most sysadmins that take jobs working 24/hour on-call shifts making 40k/year are going to be going anywhere anytime soon ? Especially if they've written off getting a formal background in the theory and practice of computer science ?
In conclusion, obviously not all sysadmins are babysitters, and not all of them need a college degree. I'd argue that many admins that go right into the tech sector and pass up on a university education are doing so because they think their hot shit based on their ability to use autoconf and gcc. Thats the way I felt when I was in highschool; luckily I went through a university program and had my eyes opened a bit.
I know alot of systems people and only a few of them make it big without degrees. Those are the sort of people that do well regardless of industry or environment. There aren't many of them.
I don't claim to predict the future. Unless you have some insight into the matter, I suggest you act similarly.
As far as which platform has a larger installed base, what are you basing your claim on ?
I've got 6 machines in this room, not one of them has Qt. Two have GTK installed, but then both also have Motif. There's an additional machine which _only_ have Motif installed. In my situation, there are more machines running Motif than GTK+Qt combined.
I'm just a home user. Granted, I buy much of my stuff to get a wide variety of environments at home so that I can hope to be familiar with anything I come in contact with. As it turns out, every job I've ever had, the machines that were the life support system of the company were running Commercial UNIXes with Motif-derived environments. People that convinced management to let them install linux on their PeeCees would run whatever GUI they wanted, but no one cared and no one paid attention.
People with workstations on their desk invariably used the environment shipped with that workstation. IMO no UNIX vendor ships an environment that is so horribly broken it impedes the progress of work. Why tear up Indigo Magic, which is beautiful and functional, on an IRIX machine just so you can tile all the freeware apps you use with pixmaps ?
If linux based PC's start replacing commercial UNIX machines in more roles, I'd see a posibility for GTK/Qt to displace motif. Right now, neither of them is the foundation for any well known commercial app (well known == I've heard of it / used it.) Sure, GTK is the foundation of GIMP, which is reasonably popular, and sure, Qt is the foundation of KDE, which is reasonably popular. You're not going to see something like P/Spice for solaris written in GTK though. I doubt you'll find that Oracle installer re-written with GTK any time soon.
Linux is a moving target. GTK is a moving target. Qt is a moving target. Motif is installed everyhwere _relevant_. Peices of software that have long development cycles tend to like use APIs that dont have major design changes over the course of a few months.
When Qt and GTK are mature toolkits that are reasonably fixed and stable, then they'll be in a position to put Motif to rest.
It's a horrible stroke of luck that Athena ever had anything at all written for it that didn't start with "test_". That's what athena was designed for - a proof of concept widget set based on Xt.
Motif is the bread and butter of commercial UNIX programming. For a while Openlook sort of mattered, but that was only on shops that were SunOS happy.
The role of Motif in real unix environments has only been strengthened with things like CDE.
Like it or hate it, the Xt/Motif combo run most of the real X software out there. There are good things about Xt/Motif that are missing from other solutions, namele, the resource system. While its awkward to use and sort of ugly, coding for it is easy and modifying the behavior of binaries that pay good attention to resources (and all Xt/Motif programs do so easily) is trivial. AFAIK GTK and/or Qt lack the post-compile customizability of Motif. Don't bother me with "themes" either.
I'm curious to hear your rationale for dropping mathematics from a computer science curriculum.
You have several massive gaps in your reasoning
1) Computer Science programs dont churn out programmers, they churn out computer scientists.
If you want to learn to program, buy a book, or go to DeVry. If you want to learn to analyze problems and model solutions to them using computers, then perhaps having a computer science degree and knowing how to use various programming tools available to you is the call.
2) Computer science was originally just "applied mathmatics", and for salary reasons im sure lots of math departments wish it were still that way. You simply cannot be a relevant computer scientist without a large understanding of various types of mid-level mathematics. I went through this same argument yesterday in a curiculum meeting. Some computer engineering senior was trying to suggest that discrete math isn't important to a computer engineers degree. Things like logic, set theory, graph theory, and proof methods are the foundation of _everything_ we do today. If you think the internet is broken and shitty _now_, let me tell you what it'd be like without basic graph theory. OSPF _is_ Dijkstra's algorithm. Ever hear of a chip with an "n" layer process ? Software doing that layout models the circuit as a graph, and then figures out the embedded planarity. You can mathematically prove a circuit can't be made with fewer layers.
I remember when I was a jackass highschool kid that figured "i'll just get my degree so people will beleive how smart I am". I'm glad I bothered to go to school. I was an idiot. People that dismiss getting a higher education because they know how to install linux, are also idiots. Idiots that I won't hire.
There are a class of programmers that dont need lots of mathematical understanding. VB programmers, or some random perl scripters. Application programmers, basically. If you want to write "pay me $15 for this shitty peice fo windows shareware I wrote in a weekend" sorts of software for the rest of your life, by all means, get "C++ / MFC For Dummies!" and go on your merry way.
If you want to take the "i'll just do networking and admin" route, you're going to find out one of two things.
1) Either you'll learn to program through lots of scripting tools, and eventually you'll realize you need to look up some theory on computational complexity, if nothing else.
2) You'll basically a machine babysitter that never gets promoted and never gets rid of that pager.
... dont even belong in the same idea.
t /usr/bin as an option to ./configure ?
./configure scripts just ruins anyones day that would like to try and experiment with that software.
I have 6 computers in my bedroom and 5 Operating systems. _None_ of them are linux anymore. As it turns out, nearly every jackass writing GPL software is running x86 redhat. And thats nearly all they test it with.
For instance. GNU autoconf is either intrinsically broken, or people dont ever figure out how to make useful configure scripts. I'm going to guess its the latter. Autoconf is supposed to _fix_ portability issues. Yet it _causes_ them. "Oh boy, now i can manually edit 237 levels of recursive gMakefiles - joy!". Would it have been so difficult to just allow --with-nonstandard-shit-like-gtk-installed-in=/no
Honestly. My main boxes are Solaris SPARC and Irix. Anything _not_ written by linux junkies tends to work great. It's ridiculous though. I've got a _real_ machine that does _real_ GL, and half the software out there these days wants all my libraries to be named "Mesa*". _Mesa_ isn't the standard. OpenGL is the standard. Mesa is a means to an end.
Source code does _not_ a portable product make. It certainly helps, but fucking it up with _no_ consideration (or more likely, no exposure) to other OSes, and shitty
I'm not sure if I should be surprised though. When I started using linux, it was "the alternative", and everyone was happy just to get it working, or to get some new feature implemented. I remember when redhat formed and their business model was "we're going to sell Linux on a CD, for alot more than the cost of the CD, because somehow, we add value to software other people wrote". How alien that was to SLS, MCC, and Slack 1.x users, back in the day.
Things have gone down hill from there. Now linux seems to be the hot ticket for all the former "0-day-warez" folks to latch on to. Can there be any question about the state of linux users today when it seems everyone is using "Bitch-X" and making screen shots of their "Themable desktop" ?
I'm all for improving linux and making it easy to use, etc. I'm _not_ all for the attitude that people seem to have taken---namely "linux is better than everything else - linux will take over the world!". While linux may take over the world someday, that day is very far off as long as there are a few rational people running systems that count.
Linux is a great idea. The attitude of many linux users, and many people who's first development experience is with linux, is fucking _awful_.
I saw this amusing quip a while ago, maybe the moderators will enjoy it:
"People that think linux is free obviously don't value their time."
Actually, Carmack did a hand coded assembler version of the Q1 or Q2 renderer for Dual pentium machines. IIRC the best he could get was between 3% and 10% improvement over 1 CPU. It was due to the braindead way the Pentium CPUs did cache invalidation or something.
:) It makes even more sense for something like Asheron's call or a game that has a contiguous world environment. Obviously the whole world can't fit into ram at once, but you could use a smart algorithm to decide when the the other CPU should page sections of world in and out of main memory, for seamless access by the other CPU.
:)
The other comment about most rendering being done on the video card is well taken. It doesn't make much sense to start writing SMP software renderers on the dawn of every PC having a T&L card. Games _should_ be written with SMP in mind, but you'd effectively only want one CPU doing gfx. Even on massive SGI's you tend to only want one thread working with a given rendering context, for context switching reasons.
Additional CPUs should be used for better responsiveness. The Sega Saturn machine used dual primary CPUs; this was in addition to its graphics and audio processors (it had like 8 processors total). It was said that in some fighting games, you'd assign the AI of one character to one CPU, and the other cpu would do everything else.
I'm not sure what the best way to utilize SMP in a gaming environment would be, but I can think of some scenarios. A dual processor configuration could be used sort of like an application-specific read ahead cache. Let one CPU be running the game, and when it realizes that it needs to spool a new world tile off of disk soon, it sends a message to the other CPU telling it to do it and to get everything set up. If you had enough ram, and the game was written properly, it'd be like "double buffering" but with game levels. At the end of a level you'd just move the "current level" pointer
Of course, most game developers are buying engines from other companies, and just cranking out different textures and FMV sequences. I wouldn't expect a whole lot of game innovation any time soon, save for from a couple of well known companies
I wouldn't worry too much. One reason china hasn't acted against Taiwan yet is because theres a pretty good chance China would _lose_. PRC is basically in such a sorry state of affairs financially and militarily that they have no hope of launching a successful amphibious assault against Taiwan, which is _made_ of money and can afford any military toys that it wants.
:)
China doesn't like anything about motinos of Taiwanese independence, but all they can really do about it is give Taiwan a big bloody nose.
China doesn't even have the top of the line russian stuff. and we're talking _russian_ stuff here. MIG-17s ? are you kidding me ?
Even the Chinese nuclear program is basically a non issue. If China were to deicde to go nuclear on Taiwan, yeah, Taiwan would get hurt badly but think of the repercussions against China. They'd expel most of their aresenal (estimates put the size of the Chinese nuclear stockpile at less warheads and less tonnage than a single US Ohio-Class sub).
Basically, I wouldn't worry about Via getting bombed
Read up on the Windows CE architecture. It is _not_ like Windows. The kernel is threaded from the ground up. Win32 is a layer you can throw ontop of the kernel. You can make a WinCE device thats nearly nothing like a Wintel platform.
Also, the Pocket PC UI was redesigned because they figured out that no one wanted the clunky size of the windows UI on a palm sized device. So they changed it.
I have a palm III and love it, but I for one am extremely excited abotu the Pocket PC platform. Wait this summer a bit. Built in suport for wireless networking ? Active matrix color screen ? Built in support for IBM Microdrive ? In the size of a Palm III ? You can bet I'm excited. I like the idea of a Palm and a Rio in one box. Not to mention you can run a _real_ browser on one of these things. The only similar thing on Palm is the Sprint PCS PDQ. And it sucks. Alot.
We should all remember to thank carmack and id for a couple of reasons
Actually, it all depends on the market conditions. I'm something of a BMW fan, and at least on the other side of the pond, BMW AG has been making Diesel engines for ever. Really slick ones at that. For instance the 740d is a 4 liter v8 diesel, which has more torque than the new M5. It's acceleration numbers aren't up to the best of the gasoline super cars, but its still making well over 200 horsepower and given that you get quite alot better gas mileage, _and_ diesel fuel is considerably cheaper in europe, diesel engines in european cars is basically a no brainer.
Finally, the RPM limit you refer to frankly doesn't matter. BMW released the "eta" engines in the US during the early/mid 80s when we were feeling some oil crunch. You may have seen BMW 325e's or 528e's, the "e" here means its got an "eta" (or "economy") engine which has a redline of right around 4200 RPM. However, they have a monsterous amount of torque at the low end which makes them very zippy for driving around towns. They're just not very ideal track cars :)
BMW diesel engines in germany are already using electronic common rail direct injection today. It's a shame that the US market has responded so piss-poor to diesel engines; the BMW 524td was only sold in the states for about a year, however the few people that got their hands on that vehicle are still driving them (usually with over 200,000 miles on the original engine).
First things First. The nVidia cards are hands down the best performing and best looking Game-class video cards for x86. Multiple people _left_ SGI to work at nVidia. SGI _sold_ graphics chipsets to nVidia. nVidia boards are made to be high quality 3d accelerators; this should be evident from how they exhibit very little performance degredation as resolutions/color depths are cranked up to the cards limits. Unlike Voodoo Cars, which tend to run well at low resolutions, and with low colordepths, the nVidia cards have always been rock solid 2d cards, and stellar performing 3d cards, at any resolution and any color depth.
nVidia employees have admitted that the current linux drivers suck, and obviously there is a great deal of performance work that can be done. I don't know that i'd hold my breath for open source drivers, but drivers that simply work and work well for a reference x86 and XFree86 platform would suffice to fill the largest hole. I would speculate that part of nVidia's reluctance to release drivers is because theres's frankly too much they'd have to released to get a respectable solution delivered. The "way to do 3d on linux" is still developing, and there are multiple parties taking multiple approaches to the problem. Which does nVidia support ?
At any rate, the point is, the nVidia cards have amazing performance and do not sacrifice visual quality or standards compliance to acheive this. Furthermore, nVidia has the cream of the crop working for them. Mark Kilegard (sp?), author of GLUT and previous SGI legend even works for them now.
On to OpenGL vs. Direct-X. Frankly, it's a apples vs oranges sort of thing. OpenGL is basically a way to make a uniform API for putting lines and triangles into a rendering context. It is _very_ low level. To get more useful functionality, you're typically going to be using GLU routines, as well as something like GLUT, libaux, or Open Inventor. It's good that openGL is _there_ for people that need to get that low occasionally, but run of the mill apps usually target GLUT or Inventor, as opposed to GL directly.
Direct-X, on the other hand, is a general purpose set of libraries to make doing interesting things fast(er) and uniform. Direct-X is much more tied to windows, and Windows hardware than GL is. Direct-X is also much more all-encompassing. GL doesn't even interoperate iwth the X protocol; thats what GLX is for. There's no intrinsic way to make an app take over the full screen with GL; every Direct-X program does this, as well as changing the resolution on the fly. Direct-X provides a uniform way to talk to all the sorts of hardware you'd like to talk to. There isn't a uniform sound API in Linux, (case in point: competeing sound libraries), much less a cross platform UNIX sound API. There are _no_ good API's for input handling in Linux, much less a cross platform UNIX method. While UNIX of course has nice networking features, there's nothing provided at a higher level than connect()/bind(). while thats enough to establish a socket, thats _not_ enough to make a good LAN-game subsystem. Any UNIX games need to build from the ground up.
Finally, lets get to the real apples-apples comparison here. Direct-3D vs OpenGL. Basically, OpenGL wins hands down for quality, standards compliance, ease of programming, and _performance_. It was once said (and i forgot by who), that the D3D system was so poorly written that it couldn't push enough triangles at the video card to make a difference; D3D itself was the limiting factor.
One area where D3D might do better than as-accepted GL is making performance tradeoffs. GL is marvelously inflexible when it comes to using/not using hardware acceleration. The most wonderful example of this is the SGI Indy R5000, with XZ graphics. Basically, the Indy's main CPU can do a much better job doing geometry calcs than the older XZ video board can. However, the GL subsystem sees a Geometry accelerated card in the system and immediatly dumps all the work to the gfx board. Downgrading video cards in this situation _increases_ performance. A similar situation exists when you define more lights in a scene than the hardware can efficiently support; suddenly everything sucks and you are left wishing there were a way to say "just do 95% of the stuff in hardware, leave the lighting to me!". Allegedly, Direct-X has ways to specify what does what job. That'd be handy.
Performance feedback is _possible_ with GL, but its not standard. SGI has many SGI-specific X-server and GLX extensions to do this. For instnace, theres an SGI extension for guaranteed framerates. If it thinks it wont be able to draw the current frame fast enough, it scraps it, draws it at a much lower resolution, then pixel-multiplies the rendered frame to fill the view-window size. Thus you get a constant framerate, but variable image quality. This is a great feature (assuming it works right), but again, its not a GL thing, its an SGI thing. It's something that games could greatly benefit from, but theres no standard way of doing it.
In summary, GL is great at what it does. I don't think anyone can argue against that. Likewise, D3D is awful at what it does, but Direct-X is a much needed layer for developers, for which there is nothing _close_ to a counterpart in the Linux, or UNIX world.
SGI's new x86 boxes should come out this year.. as early as may (according to my memory of comp.sys.sgi.*).
They'll be using the nVidia NV10 chipset (i want to say thats the GeForce 256 / Quadro stuff)
These will run SGI's linux. I have no idea how different it will be from what other people are used to, but I welcome it. SGI knows a hell of alot more about making hi performance system architectures, and the software (though usually proprietary) to exploit it than about anyone.
Initial configurations will be using intel chips IIRC, which is too bad. There will be single and multi-CPU capable machines.
Allegedly, these will have a _real_ GL/GLX implementation. Not this nonsense the x86 currently has.
You are 100% wrong. Intel has NEVER had a respectable FPU. Ever. AMD's Athlon FPU destroys the intel chips. The only thing you might be thinking of is how the early quake games required a Pentium CPU because the id boys hand tuned for the pentium FPU.. 486-class amd/cyrix chips obviously ran horribly here...(and were legitimately outclassed by the pentium FPU at the time)
another thing.. what exactly is a "real time floating point operation" ? RT operation seems like it should have alot less to do with a CPU then it would a system, and more importantly, the software side of that system. RT computing has alot more to do with enforcable upper bounds on wall clock time for a given operation than it does with 'fast fpu'. How a CPU deals with interrupts and cache misses, and under what conditions, and how this interacts with FP ops _might_ make this "topic" relevant.. but i can't believe that some people are saying "AMD" and others are saying "intel" and not expanding any more..
Linux is the true industry leader in regards to scalability and security
Linux is neither. UNIX like systems are arguably a poor choice for a secure operating system since they are so damn intent on providing service and flexibility. However, even amongst UNIXes Linux is no where _close_ to being the security leader. Try OpenBSD. Any mention of "security" that doesn't also include "openBSD is pretty much the most secure UNIX flavor in wide use" is at best unenlightened.
as far as scalability, see my earlier post. Linux does _not_ lead in scalability because of its poor SMP supprt and the poor scalability of the SMP hardware it can run on.
Finally, IRIX machines can and do stay up for long periods of time, and there are frankly a hell of alot more mission-critical multi-CPU irix machines than there are _total_ multi-cpu linux boxes.
Stop trolling. Linux isn't touching solaris in the data center market. It doesn't touch it in the scalability department, and the x86 hardware to run it isn't there even if it could.
If Linux is just killing Sun then why can't they stop making money hand over fist ? The fact of the matter is that Linux scalability plain sucks, and the answer has been "we're working on that" for at least 2 years. It _is_ getting better, but it is simply not up to par with OSes designed explicitly to handle the massive multi-cpu systems made by their vendors.
Finally, "Beowulf != Scalable". Last time i looked into it, beowulf was originally very much like an MPP and had made some inroads to providing functionality of single-image computing. The applications of linux's "clustering" are still quite narrow, and chances are most people that say they want beowulf clusters don't have any clue what they'd do with them.
Scalability for most people is something different. "Hey, i've got this webserver and RDBMS that are both thread-aware and thus can benefit from SMP machines..I'll just add more CPUs and RAM to this giant box and they'll automagically get better". Linux is an extremely poor choice for that scenario. The kernel locking is still much too coarse, too many sections are still non-reentrant, and the SMP hardware linux supports isn't particuarly scalable anyhow. Linux is _so_ poor a choice for true SMP computing that that was the area that made those amusing Mindcraft comparisions between Linux and NT realistic (i.e. NOT falsified). If you bother to look, the comparisons were using Multiple CPU boxes with Multiple Network cards. It shouldn't surprise anyone that NT did much better here, as at that time (and perhaps even still today) the linux IP stack was not re-entrant. The test took advantage of the fact that NT handled multiple device instances and SMP extremely well and Linux handled it extremely poorly. NT was designed for SMP from the ground up, with linux its been a progressive hack.
People who disagree are more then welcome to come up with facts---NOT trolls, to support their arguments. Postings which make unsubstantiated claims and predictions are basically useless.
someone mentioned that "you'd need to have worked with this stuff to hack it"
time and time again this has been shown to be blatantly false. People that design systems are not clairvoyant. Interested parties can and do infiltrate and learn about systems that they've never seen before. Reading old phrack articles should leave you quite convinced of this.
Unmanned military vehicles are no longer an experiment. They are a reality. They were used successfully in the gulf war - in reconassiance roles. However, more traditional aircraft and military systems roles are also being moved to unmanned versions. It is my understanding that the JFX (or is it JSF or JSX ?) is the last planned manned fighter aircraft. Well, this summer they had mated the two halves fo the fuselage. In other words, don't expect too many more manned fighters. Fighter aircraft can already far outperform the limits of their frail human pilots.
The military is and will continue to use unmanned vehciles in an increasingly aggressive/active fashion. Many current generation missiles are "fire and forget" -- this is software driving the missle to the target once it is released. Commercial airliners already more or less fly themselves. Putting all these peices together is all thats left.
Someone else mentioned that taking a machine off a public network insured that it would not be hacked. I can't think of a more foolish statement. Systems were getting hacked -- and much more thoroughly than they are today -- long before everyone "had internet". The mentality which says "private network == unhackable" is the mentality that I don't want near _Any_ computer network with sensitive data. VPN's are just a matter of encryption. Isolated LANs invariably have some private dial-in #. Think of this problem in terms of telco stuff. What telco gear do you know of thats hooked up to the net ? Ask yourself how often that stuff gets completely compromised and understood by cajoling teens.
As far as buffer overruns in military systems, I wouldn't count on it. For instance, the majority of the F-15s software is written in Ada. C typically is _not_ used, and for good reasons.
The facts are clear. The future of the military is software automation. If people take the attitude that they are doing enough to safeguard their software and networks, then they probably really aren't. Paranoia is the only answer.