Why is there no refrence to William Gibson's Neuromancer above +2? That book defined the ideas of cyberspace so well that it reads just as well after the computer revolution as before. In about '98 when I saw the first talking heads DHTML/SGML site, I had an erie feeling I'd been there before.
I have confidence it will be considered up there with Verne in terms of prophetic nature.
If NewLine, by winning the suit, can prevent Blizard from making their Diablo, I'm all for it. It can only prevent what would be the most hideous movie of all time.
I would optomize for the version of Intel chip that the AMD chip tries to emulate. Don't use any of the -march directives, since they create intel-only instructions. I would suggest -mpentium. Oh, and there's gotta be some AMD optomized compilers out there, but I don't know anything about them. As to gcc 3.0, it hasn't shippped yet(has it?) so YMMV big time.
Re:Optimizing the source build
on
KDE 2.1 Is Out
·
· Score: 2
I'm working from gcc 2.95.2, and it does give benifit from -march=pentiumpro. Most of the ppro core(aplicable to ppro,p2,p3) changes were merged from pgcc into normal gcc a while ago. I didn't reccomend using pgcc bacause a) most people don't have it, and b) because my version dies of an internal compiler error part way through kde2. If you're willing to use regular gcc to handle the few offending files, pgcc's a good choice. Oh, and I have no clue what mandrake ships with their distro.
Re:Optimizing the source build
on
KDE 2.1 Is Out
·
· Score: 2
The AC above is correct - I was using the cheap crack, and it should be -(Oh)3, not -(Zero)3
Optimizing the source build
on
KDE 2.1 Is Out
·
· Score: 5
For those who build KDE from source, and ESPECIALLY the pacakagers at big distros, consider strongly doing the folowing:
set the -no-g++-exceptions flag when building qt
and set the folowing options for all qt and kde:
-03
-mpentiumpro (or -march=pentiumpro for ppro only objs)
the exceptions optimization literally reduces the size of everyting related to qt by several megs a piece with no detriemntal effects. -03 is important because it turns on inlining, which is a big win for C++ code with lots of tiny functions. And optimizing for modern chips should be standard for anyone. These changes sped up my KDE load time by 50%, and made the whole thing feel much "snappier" and smoother. Don't let KDE2 get a rep for slowness just because you used lousy compiler options. (and yes, I posted something similar to the kde2.0 article, but I'm going to repeat it until the packagers get it right)
I live in boulder and have judged other elementary science fairs there. I saw the project before it was removed (although I wasn't a judge at mesa). This was hands down the best science fair project I've seen in a long time (at that level).
hypothesis was clear and testable
methodology was clear, simple, and tested the hypothesis
data was well tabulated and presented
conclusion was valid and didn't overreach
topic was relevant and current
It could have used a larger sample size, but it blew away all the chemical volcanoes
..but the reality is that he's selectivly enforcing his invalid trademark (check the trademark db if you don't believe me). And he's doing this enforcement against the product that's **gasp** putting him out of business. If he really wanted to protect the (tm), he would need to go after:
and, well, you get the point. He's just going after OpenSSH because they're beating him in the market. And not only does he have no legal leg to stand on, but he's being a real slime by only going after the successfull one. Theo would be right to tell hime where to stick his lawyers.
Yes, I have used OSX. You're missing the point. I can get gcc, etc. But it doesn't ship on the CD's. And downloading over a phone line isn't free in terms of time, and in many parts of the world in terms of money. Second, as to porting, no, software will not port well from OSX -> *BSD. The only shared APIs are for command line apps, and when was the last time you saw a graphics-free mac app? Well, I'm waiting... As to the X-windows issues, you again miss the point. There are X servers, but the ones that will run inside Aqua don't come with the libs to compile against - they assume you're running remotely. The java servers are the same way. So to get an X program working, you have to install XFree (which can't run because it can't get the display), compile against it, and then run the binaries against another XServer running inside Aqua. You've betrayed the spirit of the Mac if you think that's an acceptable solution.
I think counting every OSX install as a "BSD" is somewhat misleading. The Kernel's not BSD (it's Mach), there's just a bsd compatibility layer on top and a lot of bsd utils. I doubt the standard mac audience will use that much (they're into mac to avoid that kind of stuff). I also doubt that too many BSDers will adopt it because a) they mostly own i386,Alpha,and Sparc hardware, which OSX won't (yet) run on and b) becasuse it doesn't have a readily available compiler tool chain that you don't have to shell out the big bucks for. Somewhat worse, apps written for OSX won't port to other BSD's, and vice versa. The lack of X support in OSX(ironic?) and the lack of carbon/coco/whatever support in every other BSD will keep them appart.
It's a shame, because while a use FreeBSD exclusivly on my laptop (KDE2 made freebsd a servicable workstation without LINUX emulation, thanks to KOffice), I'm certainly not adverse to the idea of having a commercial BSD with real apps. It just doesn't appear that OSX really fills that niche.
The obligatory link to Jordan Hubbard's Salon article and review of OSX is
here. It's largly a rant about open source, but the second page covers the technical issues in a clear and unbiased way.
IBM's always been extreamly ignorant about BSD in general and FreeBSD in particular. I remember when the #1 comment at IBM's java site was a request to port their JDK to FreeBSD, and the only comment from IBM was a question asking what kind of Linux distro freebsd was.
There is a solution, though. I just put FreeBSD 4.2 on a new Dell Inspiron 5000e, and it went on nearly flawlessly. The only trouble was that X had to be compiled from CVS because the RAGE Mobility LF isn't really supported in XFree4.0.1. Of course that caveate applies to linux as well. Cardbus doesnt' work in 4.2, but does in -current. Standard PCMCIA is fine. Otherwise every single piece of hardware worked in all respects after a kernel recompile. This machine also has the famous 1600x1200 screen, and is several hundred $$$ cheaper than the equivelent IBM machine (which has a much crappier screen).
Moral of the story: If you have any desire to run FreeBSD or just want better hardware at a cheaper price, the Inspiron 5000 series is THE way to go.
This article gives good evidence that states implementing UCITA loose software sales from their vendors. Sad as it is, legislators in states considering UCITA will be far more swayed by
"UCITA will cost you tax $$$ and hurt your high-tech economy"
At my school, intro to programing is taught on windows in C++ withough objects (mostly just for cin/cout). This is so the general purpose labs can be used for the class. However, last semester, one section was taught on UNIX, and I was the TA for that section. In my expereience, the change to UNIX was a mixed blessing.
Gcc on UNIX kicked Borland's ass in the compiler department. I got about a tenth of the compiler problem reports that the other TA's did. It also had slightly more predictable descriptions of compile errors, although that's not saying much... We used Jed for our editor, and it got rave reviews from almost everyone. It did color syntax highlighting, emulated other editors people already knew, and could be used either via keyboard shortcuts or menues. The debugger was DDD over GDB, and that was ok. It really did shine in the pointers part of the course, because the way it shows variables allowed people to actually see their data structure. That was invaluable! So basically, the tools were very good.
Now for the down side: It took a lot of time to get people used to the enviroment. Since this is a class open to any student, a lot of people didn't know what a command line was. Directories (as opposed to folders) were lost on them, etc. Since I refuse to teach by pure rote, I had to explain quite a lot of UNIX lore in the first lab session to get them all up and running. Lastly, we needed a graphics tookit for the last project in the class. We chose gtk+, since it was procedural and I had used it before. I'm not sure why it didn't go over well, but it didn't. The students had far more trouble with it than they did with the borland toolkit used on the windows side.
At the end of the class, we had the students rate the tools they used on a 1-10 scale. Here are the averaged results from both classes:
Obviously, this isn't very scientific. I wan't involved with the windows classes, so I don't know what the issues with Borland were, but it's clear the students didn't much like it. I would be very interested in how KDevelop, CodeWarior, and MS-VC++ would fare.
During the class, 7 out of 30 people asked me to help them install LINUX (which was never mentioned during the class). I helped eveyone who had an Intel machine, and passed the rest off to a LinuxPPC expert. I don't think near as many people would have installled LINUX had I been activly evangelical.
I haven't been able to get JAVA working on anything since M18 on LINUX. It installs ok, but crashes when I hit a page with an applet. Any secret to this, or am I SOL?
If you think the're are iregularities now, imagine what a re-vote would be like:
The entire election-throwing machine of both parties would descend on a few more than a hundred thousand people. And the parties would KNOW that a fix here fixed the election. If there's a re-vote, I predict a huge turnout from dead people, pets, non-citizens, and inanimate objects. And I predict riots. Martial law is no way to hold an election.
I've been submitting bugs to the Moz project, because I want it to succeede in the worst sort of way, but I've concluded it never will. Here's why:
1. Unless you're someone@netscape.com, your patches never see the light of day. Umpteen bazillion code reviews later, it's still not in the build. Then Netscape marks your bug "RTM++", some Netscape engineer fixes it, and their all happy they fixed a bug that there was already a fix for.
2. Slow load time - IE under wine loads faster on my machine than a no-debug optomized to hell mozilla. That's not a good sign.
3. Contributions from the comunity never see the light of day either. Notice that only 3 of the platforms have a MathML enabled M18 build: the MathML people have to literally beg third party people to build their code, because Netscape refuses to wate their precious time on the project. If you're not netscape, you don't matter.
4. While you are an outside developer are living in code review hell, the senior developers are submitting code without even a basic regression test. That's why "regression" is about the most frequently seen word in mozilla status reports.
5. Netscape busts the builds - there a reason that NSPR-whatever is not only worse than the nightlies when it comes out, but the previous milestone as well. It's because all the crap netscape adds fucks up the build. Everyone knows this, but does netscape fix it? No....
Posted with Konqueror untill Mozilla gets it's shit working.
oops, I was a litttle whacked out there. It IS ok, and even apropriate to define -fno-exceptions. khtml correctly overrides this. It probably won't make a difference, but it made me feel better:)
Here's what I did to build a very speedy version of kde2. Package maintainers and tech heads take note!
first, I CVS co'd off the KDE_2_0_BRANCH. Check out qt-copy,kdesupport,kdelibs, and kdebase at a minimum. Do try out other packages, though...
In qt-copy, edit the/configs/your-architecture file to include the -fno-exceptions option in teh CXXFLAGS variable. Optionally, change the compiler to pg++/pgcc if you have them. If you're feeling lucky, kick the -O2 up to -O3 or even -O6. Then define -mpentiumpro (for portable objects) or -march=pentiumpro (for Pentiumpro+ only objects). Then configure and build the sucker.
if you have them. Do NOT define -fno-exceptions, as this may jack up khtml, and each module already correctly determines it's prefrence on this option. Then build as per normal instructions.
This gave me a %100 startup speed improvement (mostly due to turning of exceptions where not needed). It also gave me a noticable runtime speed boost and improved app 'feel'.
Major distro packagers, if you're out there, PLEASE DO THIS! It's unfair to give KDE a reputation for slowness just because you chose to use poor compiler options!
*for this post, success is defined as a project of reasonable length (say 3 months so far) ever reaching a stable release.
In the beginning, there were software projeccts, with a few people on them, written in C, and the success rate was good. Perhaps 70%
Then, the software engineers said: "You must have requirements, designs, and models!!!!" More people were added to the project to do these things. The projects switched to languages designed to support the added developers - C++ or Ada if DOD. Success rates dropped. Perhaps 50%
Then, the software engineers saw the droping success rates, and said: "You all clearly don't understand the customer! What you need are deeper requirements, multiple designs, and UML!" Hordes and "Tiger teams" of developers were added to fill these requirements. Languages were switched to support the hordes (oftern to JAVA). The success rate as measured now stands at 40% (even the industry aknowledges this).
The OSS came along, did no specs, of the top of the head designs, no models, and used a relativley small number of people, working mostly in C. And the success rate (as defined above for major projects) climbed to about 70%. Some would argue higher.
Now, when will we as a software developing comunity pitch out the "Software Engineers"? Their methods are strong negative predictors of success!
Someone above commented that not voting was an inefective form of protest, and that we need a none of the above protest vote. I agree, and here's how to get it.
PIck a person around you who's old enough to hold the office, and vote for them. If all the people who hated the current canidattes did this, there would be something like 20% of the votes for random people. That would get the basic message across - that an average joe is better equiped to run government than the lawyers we get now.
Then, be sure that if you're lucky enough to get exit polled that you give the pollster a mouthfull!
the above post was mine, and wasn't supposed to be AC - TACO, it's all your fault:) Someone mod it up at least one, though, I think it's really important.
There seems to be a lot of confusion about the nature of the Kursk, and whether is was a balistic missile sub, or an fast attack sub. Further confusion exists about wheter it normally carries nucular weapons. here's what I found from various sources:
The Kursk is an Oscar II class sub. It is not a balistic missile sub, nor is it a fast attack sub. Instad it carries cruise missiles used to attack surface ships, ports, and possible inland facilites. The cruise missiles can carry a nucular or conventional payload. A normal peacetime loadout would be entirely conventional weaponry. As best I can tell (someone who owns Janes Underwatter correct me:) it has vertical launch tubes designed to hold the cruise missiles, and then 4 torpedo tubes mostly for defense. The vertical launch tubes are similar to those found on a refitted Los Angeles class US sub, but can be reloaded at sea, while a LA has to reload in port.
This brings up some interesting questions:
1. Since the Kursk's primary mission is cruise-missile based, why was it testing a new torpedo? Wouldn't that be the job of an Alfa or some attack sub?
2. Why all the concern about nukes, when it's pretty clear that anyone familiar with the sub knew it wouldn't be carrying them?
I think the rumor of a mis-firing SSN-15 or 16 makes a lot more sense because it fits the Oscar II's mission profile a lot better. Incidently, those are fired out of the torpeedo tubes, not the special-purpose missile tubes, so it's reasonable that one could have caused the damage.
Why is there no refrence to William Gibson's Neuromancer above +2? That book defined the ideas of cyberspace so well that it reads just as well after the computer revolution as before. In about '98 when I saw the first talking heads DHTML/SGML site, I had an erie feeling I'd been there before.
I have confidence it will be considered up there with Verne in terms of prophetic nature.
If NewLine, by winning the suit, can prevent Blizard from making their Diablo, I'm all for it. It can only prevent what would be the most hideous movie of all time.
I would optomize for the version of Intel chip that the AMD chip tries to emulate. Don't use any of the -march directives, since they create intel-only instructions. I would suggest -mpentium. Oh, and there's gotta be some AMD optomized compilers out there, but I don't know anything about them. As to gcc 3.0, it hasn't shippped yet(has it?) so YMMV big time.
I'm working from gcc 2.95.2, and it does give benifit from -march=pentiumpro. Most of the ppro core(aplicable to ppro,p2,p3) changes were merged from pgcc into normal gcc a while ago. I didn't reccomend using pgcc bacause a) most people don't have it, and b) because my version dies of an internal compiler error part way through kde2. If you're willing to use regular gcc to handle the few offending files, pgcc's a good choice. Oh, and I have no clue what mandrake ships with their distro.
The AC above is correct - I was using the cheap crack, and it should be -(Oh)3, not -(Zero)3
For those who build KDE from source, and ESPECIALLY the pacakagers at big distros, consider strongly doing the folowing:
set the -no-g++-exceptions flag when building qt
and set the folowing options for all qt and kde:
-03
-mpentiumpro (or -march=pentiumpro for ppro only objs)
the exceptions optimization literally reduces the size of everyting related to qt by several megs a piece with no detriemntal effects. -03 is important because it turns on inlining, which is a big win for C++ code with lots of tiny functions. And optimizing for modern chips should be standard for anyone. These changes sped up my KDE load time by 50%, and made the whole thing feel much "snappier" and smoother. Don't let KDE2 get a rep for slowness just because you used lousy compiler options. (and yes, I posted something similar to the kde2.0 article, but I'm going to repeat it until the packagers get it right)
I live in boulder and have judged other elementary science fairs there. I saw the project before it was removed (although I wasn't a judge at mesa). This was hands down the best science fair project I've seen in a long time (at that level).
hypothesis was clear and testable
methodology was clear, simple, and tested the hypothesis
data was well tabulated and presented
conclusion was valid and didn't overreach
topic was relevant and current
It could have used a larger sample size, but it blew away all the chemical volcanoes
..but the reality is that he's selectivly enforcing his invalid trademark (check the trademark db if you don't believe me). And he's doing this enforcement against the product that's **gasp** putting him out of business. If he really wanted to protect the (tm), he would need to go after:
O SSH
TTSSH
NiftySSH
MacSSH
Java-SSH
TGssh
sshCE
An OpenVSM project called just SSH
SSH-OS2
...
and, well, you get the point. He's just going after OpenSSH because they're beating him in the market. And not only does he have no legal leg to stand on, but he's being a real slime by only going after the successfull one. Theo would be right to tell hime where to stick his lawyers.
Yes, I have used OSX. You're missing the point. I can get gcc, etc. But it doesn't ship on the CD's. And downloading over a phone line isn't free in terms of time, and in many parts of the world in terms of money. Second, as to porting, no, software will not port well from OSX -> *BSD. The only shared APIs are for command line apps, and when was the last time you saw a graphics-free mac app? Well, I'm waiting... As to the X-windows issues, you again miss the point. There are X servers, but the ones that will run inside Aqua don't come with the libs to compile against - they assume you're running remotely. The java servers are the same way. So to get an X program working, you have to install XFree (which can't run because it can't get the display), compile against it, and then run the binaries against another XServer running inside Aqua. You've betrayed the spirit of the Mac if you think that's an acceptable solution.
It's a shame, because while a use FreeBSD exclusivly on my laptop (KDE2 made freebsd a servicable workstation without LINUX emulation, thanks to KOffice), I'm certainly not adverse to the idea of having a commercial BSD with real apps. It just doesn't appear that OSX really fills that niche.
The obligatory link to Jordan Hubbard's Salon article and review of OSX is here. It's largly a rant about open source, but the second page covers the technical issues in a clear and unbiased way.
There is a solution, though. I just put FreeBSD 4.2 on a new Dell Inspiron 5000e, and it went on nearly flawlessly. The only trouble was that X had to be compiled from CVS because the RAGE Mobility LF isn't really supported in XFree4.0.1. Of course that caveate applies to linux as well. Cardbus doesnt' work in 4.2, but does in -current. Standard PCMCIA is fine. Otherwise every single piece of hardware worked in all respects after a kernel recompile. This machine also has the famous 1600x1200 screen, and is several hundred $$$ cheaper than the equivelent IBM machine (which has a much crappier screen).
Moral of the story: If you have any desire to run FreeBSD or just want better hardware at a cheaper price, the Inspiron 5000 series is THE way to go.
"UCITA will cost you tax $$$ and hurt your high-tech economy"
than they would be to
"UCITA is unfair and screws the consumer"
Gcc on UNIX kicked Borland's ass in the compiler department. I got about a tenth of the compiler problem reports that the other TA's did. It also had slightly more predictable descriptions of compile errors, although that's not saying much... We used Jed for our editor, and it got rave reviews from almost everyone. It did color syntax highlighting, emulated other editors people already knew, and could be used either via keyboard shortcuts or menues. The debugger was DDD over GDB, and that was ok. It really did shine in the pointers part of the course, because the way it shows variables allowed people to actually see their data structure. That was invaluable! So basically, the tools were very good.
Now for the down side: It took a lot of time to get people used to the enviroment. Since this is a class open to any student, a lot of people didn't know what a command line was. Directories (as opposed to folders) were lost on them, etc. Since I refuse to teach by pure rote, I had to explain quite a lot of UNIX lore in the first lab session to get them all up and running. Lastly, we needed a graphics tookit for the last project in the class. We chose gtk+, since it was procedural and I had used it before. I'm not sure why it didn't go over well, but it didn't. The students had far more trouble with it than they did with the borland toolkit used on the windows side.
At the end of the class, we had the students rate the tools they used on a 1-10 scale. Here are the averaged results from both classes:
Solaris: 5
gcc: 7
Jed: 9.5 - Wow!
ddd: 7
gtk+: 2 - Ouch!
Windows: 6
Borland C++ compiler: 3 - Ouch!
Borland Editor: 4
Borland Debugger: 3 - Double ouch!
Borland GUI Toolkit: 4
Obviously, this isn't very scientific. I wan't involved with the windows classes, so I don't know what the issues with Borland were, but it's clear the students didn't much like it. I would be very interested in how KDevelop, CodeWarior, and MS-VC++ would fare.
During the class, 7 out of 30 people asked me to help them install LINUX (which was never mentioned during the class). I helped eveyone who had an Intel machine, and passed the rest off to a LinuxPPC expert. I don't think near as many people would have installled LINUX had I been activly evangelical.
I haven't been able to get JAVA working on anything since M18 on LINUX. It installs ok, but crashes when I hit a page with an applet. Any secret to this, or am I SOL?
The entire election-throwing machine of both parties would descend on a few more than a hundred thousand people. And the parties would KNOW that a fix here fixed the election. If there's a re-vote, I predict a huge turnout from dead people, pets, non-citizens, and inanimate objects. And I predict riots. Martial law is no way to hold an election.
1. Unless you're someone@netscape.com, your patches never see the light of day. Umpteen bazillion code reviews later, it's still not in the build. Then Netscape marks your bug "RTM++", some Netscape engineer fixes it, and their all happy they fixed a bug that there was already a fix for.
2. Slow load time - IE under wine loads faster on my machine than a no-debug optomized to hell mozilla. That's not a good sign.
3. Contributions from the comunity never see the light of day either. Notice that only 3 of the platforms have a MathML enabled M18 build: the MathML people have to literally beg third party people to build their code, because Netscape refuses to wate their precious time on the project. If you're not netscape, you don't matter.
4. While you are an outside developer are living in code review hell, the senior developers are submitting code without even a basic regression test. That's why "regression" is about the most frequently seen word in mozilla status reports.
5. Netscape busts the builds - there a reason that NSPR-whatever is not only worse than the nightlies when it comes out, but the previous milestone as well. It's because all the crap netscape adds fucks up the build. Everyone knows this, but does netscape fix it? No....
Posted with Konqueror untill Mozilla gets it's shit working.
And they call it an institution of higher learning :)
handfull of busted 256m DIMMS: $10.71 with tax
6 reboots, a little math, and a partial kernel compile: 21min
The look on my roommate's face when I typed "top": priceless!
oops, I was a litttle whacked out there. It IS ok, and even apropriate to define -fno-exceptions. khtml correctly overrides this. It probably won't make a difference, but it made me feel better :)
first, I CVS co'd off the KDE_2_0_BRANCH. Check out qt-copy,kdesupport,kdelibs, and kdebase at a minimum. Do try out other packages, though...
In qt-copy, edit the /configs/your-architecture file to include the -fno-exceptions option in teh CXXFLAGS variable. Optionally, change the compiler to pg++/pgcc if you have them. If you're feeling lucky, kick the -O2 up to -O3 or even -O6. Then define -mpentiumpro (for portable objects) or -march=pentiumpro (for Pentiumpro+ only objects). Then configure and build the sucker.
Before building kde, define in the shell:
CXXFLAGS="-fno-exceptions [-O6][-march=pentiumpro | -mpentiumpro]"
and
CXX=pg++
CC=pgcc
if you have them. Do NOT define -fno-exceptions, as this may jack up khtml, and each module already correctly determines it's prefrence on this option. Then build as per normal instructions.
This gave me a %100 startup speed improvement (mostly due to turning of exceptions where not needed). It also gave me a noticable runtime speed boost and improved app 'feel'.
Major distro packagers, if you're out there, PLEASE DO THIS! It's unfair to give KDE a reputation for slowness just because you chose to use poor compiler options!
In the beginning, there were software projeccts, with a few people on them, written in C, and the success rate was good. Perhaps 70%
Then, the software engineers said: "You must have requirements, designs, and models!!!!" More people were added to the project to do these things. The projects switched to languages designed to support the added developers - C++ or Ada if DOD. Success rates dropped. Perhaps 50%
Then, the software engineers saw the droping success rates, and said: "You all clearly don't understand the customer! What you need are deeper requirements, multiple designs, and UML!" Hordes and "Tiger teams" of developers were added to fill these requirements. Languages were switched to support the hordes (oftern to JAVA). The success rate as measured now stands at 40% (even the industry aknowledges this).
The OSS came along, did no specs, of the top of the head designs, no models, and used a relativley small number of people, working mostly in C. And the success rate (as defined above for major projects) climbed to about 70%. Some would argue higher.
Now, when will we as a software developing comunity pitch out the "Software Engineers"? Their methods are strong negative predictors of success!
PIck a person around you who's old enough to hold the office, and vote for them. If all the people who hated the current canidattes did this, there would be something like 20% of the votes for random people. That would get the basic message across - that an average joe is better equiped to run government than the lawyers we get now.
Then, be sure that if you're lucky enough to get exit polled that you give the pollster a mouthfull!
the above post was mine, and wasn't supposed to be AC - TACO, it's all your fault :) Someone mod it up at least one, though, I think it's really important.
The Kursk is an Oscar II class sub. It is not a balistic missile sub, nor is it a fast attack sub. Instad it carries cruise missiles used to attack surface ships, ports, and possible inland facilites. The cruise missiles can carry a nucular or conventional payload. A normal peacetime loadout would be entirely conventional weaponry. As best I can tell (someone who owns Janes Underwatter correct me :) it has vertical launch tubes designed to hold the cruise missiles, and then 4 torpedo tubes mostly for defense. The vertical launch tubes are similar to those found on a refitted Los Angeles class US sub, but can be reloaded at sea, while a LA has to reload in port.
This brings up some interesting questions:
1. Since the Kursk's primary mission is cruise-missile based, why was it testing a new torpedo? Wouldn't that be the job of an Alfa or some attack sub?
2. Why all the concern about nukes, when it's pretty clear that anyone familiar with the sub knew it wouldn't be carrying them?
I think the rumor of a mis-firing SSN-15 or 16 makes a lot more sense because it fits the Oscar II's mission profile a lot better. Incidently, those are fired out of the torpeedo tubes, not the special-purpose missile tubes, so it's reasonable that one could have caused the damage.
Uh, KDE has nothing comparable to gnumeric? How bout kspread? Stop the FUD and check before you post.