Slashdot Mirror

Well, this comment is kinda lateral (as in 'not related to opengl and games'), but I think you'd appreciate flipping through a few basic computer graphics books and related maths --- after all, opengl is just an implementation of the few of the most basic concepts and the red&blue books are mostly 'just' technical reference manuals. getting a handle of the basic concepts also probably clarifies what you actually want to do with the code.

Graphics:

watt&watt: Advanced Animation and Rendering Techniques - not a very recent book but the material is still relevant and the presentation of different concepts is relly good
Hearn & Baker: Computer graphics (c or opengl version depending on your preferences). Basic computer graphics. Pretty good. The opengl version eschews some of the more basic code samples from the c version, which is a bit shame really.
Moller & Haines: Real-Time Rendering - relevant for real time applications and contains great references to computer graphics resources in general

Geometry & linear algebra:
Philip Schneider & David Eberly: geometric tools for computer graphics (contains recipes for eg. checking collisions, raytracing, clipping...). Might be not best book of this type(?) but it's ok.

Freely available online material:
comp.graphics.algorithm faq:
http://www.faqs.org/faqs/graphics/algorithms-faq/

The physical modeling course of David Baraff available online is quite nice:
http://www.cs.cmu.edu/~baraff/sigcourse/index.html

Graphics gem's codes:

http://www.acm.org/pubs/tog/GraphicsGems/

The book's themselves are also excllent recipe repositories, but really useful only after you know the basic concepts from basic textbooks etc. ...and, if you have the access then the http://portal.acm.org/ stuff is really good. (search for 'siggraph "course notes" for starters') You can find details to most of the stuff Pixar, Alias etc. do from there...

If you have the time and resouces, then the Moller & Haines book is a decent roadmap to the field ("Oh, what's this...let's see the referred book/article has to say.. oh, that's interesting!") from the grass roots of z-buffers up to modern fps engine concepts.

Well, this comment is kinda lateral (as in 'not related to opengl and games'), but I think you'd appreciate flipping through a few basic computer graphics books and related maths --- after all, opengl is just an implementation of the few of the most basic concepts and the red&blue books are mostly 'just' technical reference manuals. getting a handle of the basic concepts also probably clarifies what you actually want to do with the code.

Graphics:

watt&watt: Advanced Animation and Rendering Techniques - not a very recent book but the material is still relevant and the presentation of different concepts is relly good
Hearn & Baker: Computer graphics (c or opengl version depending on your preferences). Basic computer graphics. Pretty good. The opengl version eschews some of the more basic code samples from the c version, which is a bit shame really.
Moller & Haines: Real-Time Rendering - relevant for real time applications and contains great references to computer graphics resources in general

Geometry & linear algebra:
Philip Schneider & David Eberly: geometric tools for computer graphics (contains recipes for eg. checking collisions, raytracing, clipping...). Might be not best book of this type(?) but it's ok.

Freely available online material:
comp.graphics.algorithm faq:
http://www.faqs.org/faqs/graphics/algorithms-faq/

The physical modeling course of David Baraff available online is quite nice:
http://www.cs.cmu.edu/~baraff/sigcourse/index.html

Graphics gem's codes:

http://www.acm.org/pubs/tog/GraphicsGems/

The book's themselves are also excllent recipe repositories, but really useful only after you know the basic concepts from basic textbooks etc. ...and, if you have the access then the http://portal.acm.org/ stuff is really good. (search for 'siggraph "course notes" for starters') You can find details to most of the stuff Pixar, Alias etc. do from there...

If you have the time and resouces, then the Moller & Haines book is a decent roadmap to the field ("Oh, what's this...let's see the referred book/article has to say.. oh, that's interesting!") from the grass roots of z-buffers up to modern fps engine concepts.

Indeed. The thechnology has been around since 2001.

McCullough and Wilson wrote a paper about Office back in 1997 which ripped Excel to shreds on its statistical accuracy and random number generation. They reissued the paper in 2002, and Excel still had the same problems in Office2000 and OfficeXP. Many of the worst problems were still there in Office2003. Have they actually fixed the horrible errors?

For your intro work - go ahead and use an IDE. Let the students get something up and running, with as little overhead as possible. It's a chance for them to see they can make something happen. What you achieve, hopefully, is to whet their appetite for more.

In the end however, they won't know what's going on. Not in any comprehensive sense of the word. Java or Python won't let them know what's going on either, so you've lost very little by using an IDE. Using command line tools will only change the focus of leaning from the code to the tools. Just make sure the program (the education program) gives them an oppertunity to get a real understanding through a language that makes what's actually happening visible.

I've watched with dismay the level of understanding drop year over year. I don't see anything checking the fall. The poor showing of US schools in the recent ACM programming contest is a reflection of this problem.

Watching my daughter learn programming leaves me with no question about this issue. When she went from Java to C her understanding of what was actually taking place went up dramatically. It reinforced my belief that learning a low level language - C or assembly - is necessary for real computer literacy. (Please, not C++, with C++ you end up with the worst possible combination: tremendous complexity and no support. And the addition Object Orientation doesn't really help.)

While there are few programs (at least by line count) that require C today, the deeper understanding of what's happening pays off. It pays off in being able to know what to expect. It pays off in better code in any language. Understanding the details allows you make informed choices. It seems the academic community has lost this perspective. There seems to be a belief that the "details" are beneath them. "You shouldn't have to think about memory management" is a popular comment to this effect. Unfortunate this is simply out of touch with reality - perhaps one too any levels of indirection.

Any computer education program should require a significant investment in low level coding. Demanding academic programs should require most of the work be done this way. The quality of the graduates would increase substantially. What we're getting instead, as Alan Kay put it in an recent interview, is "java certification" which is a much lower standard. And, as a standard, it's simply too low.

For your intro work - go ahead and use an IDE. Let the students get something up and running, with as little overhead as possible. It's a chance for them to see they can make something happen. What you achieve, hopefully, is to whet their appetite for more.

In the end however, they won't know what's going on. Not in any comprehensive sense of the word. Java or Python won't let them know what's going on either, so you've lost very little by using an IDE. Using command line tools will only change the focus of leaning from the code to the tools. Just make sure the program (the education program) gives them an oppertunity to get a real understanding through a language that makes what's actually happening visible.

I've watched with dismay the level of understanding drop year over year. I don't see anything checking the fall. The poor showing of US schools in the recent ACM programming contest is a reflection of this problem.

Watching my daughter learn programming leaves me with no question about this issue. When she went from Java to C her understanding of what was actually taking place went up dramatically. It reinforced my belief that learning a low level language - C or assembly - is necessary for real computer literacy. (Please, not C++, with C++ you end up with the worst possible combination: tremendous complexity and no support. And the addition Object Orientation doesn't really help.)

While there are few programs (at least by line count) that require C today, the deeper understanding of what's happening pays off. It pays off in being able to know what to expect. It pays off in better code in any language. Understanding the details allows you make informed choices. It seems the academic community has lost this perspective. There seems to be a belief that the "details" are beneath them. "You shouldn't have to think about memory management" is a popular comment to this effect. Unfortunate this is simply out of touch with reality - perhaps one too any levels of indirection.

Any computer education program should require a significant investment in low level coding. Demanding academic programs should require most of the work be done this way. The quality of the graduates would increase substantially. What we're getting instead, as Alan Kay put it in an recent interview, is "java certification" which is a much lower standard. And, as a standard, it's simply too low.

Most Windows users (especially those doing anything serious) on their machines know the security landscape and have taken steps to mitigate the problem with a defense in depth strategy (including, importantly, not running as admin). As for zero-day exploits, I'd love to know how anything is immune to specially crafted/0-day attacks.

Also, if someone demanding 'reliability' is going to view jpg and wmf files -- as a privileged user -- and listen to CDs with Autoplay=on (which was how the Sony rootkit spread), then he deserves whatever he's getting on his machine.

> the APIs just were not designed for that.

I disagree-- Windows is designed to be reliable enough for most enterprises to do their file/print, mail, database and app server. (Most IT folk running Windows are quite happy with the 2003 line of servers, for example). But the level of reliability is key here -- getting 5 or 6 9s reliability on Windows is devilishly hard if not impossible (it's much easier on Solaris, IMO).

But then, if you're comparing the reliability of a Windows workstation vs a Linux workstation used by an *average* user-- *shrug* that's a meaningless comparison because the average Linux user is far more sophisticated than the average Windows user.

> It even comes rooted, as the EULA explicitly states that MS can enter your computer in both the Windows and Windows Media Player EULAs.

I assume you're talking about this. Ignoring the tinfoil-hattish tone of that, it was amusing-- reminded me of "Reflections on trusting trust" for some reason. If you cannot trust your OS vendor (especially these days when internet-based binary patch distribution is common) then you're in trouble -- you'd better switch to ports or emerge (and audit every line of code, especially kernel code, before patching anything).

Anyway, the scope of that section in the EULA is to disable software that specifically subverts Windows Rights Management protections. But yeah, if you don't trust Microsoft to do the right thing, you ought to think twice before letting their code run in ring 0 of your CPU.

I don't think this sort of hype helps anyone. The Java code generation story is indeed solid (although the toy benchmarks you cite are meaningless). The real issue is garbage collection. It requires around 3 times more memory (or 7 times more) than explicit memory management to achieve equivalent performance -- less memory means more garbage collections. Unfortunately, more memory means longer pauses. Worse, if physical memory runs short, it's a paging disaster (although this can be fixed). Java - and garbage collection - are great technologies, but it's important to acknowledge their limitations (and try to address them).

I don't think this sort of hype helps anyone. The Java code generation story is indeed solid (although the toy benchmarks you cite are meaningless). The real issue is garbage collection. It requires around 3 times more memory (or 7 times more) than explicit memory management to achieve equivalent performance -- less memory means more garbage collections. Unfortunately, more memory means longer pauses. Worse, if physical memory runs short, it's a paging disaster (although this can be fixed). Java - and garbage collection - are great technologies, but it's important to acknowledge their limitations (and try to address them).

I don't think this sort of hype helps anyone. The Java code generation story is indeed solid (although the toy benchmarks you cite are meaningless). The real issue is garbage collection. It requires around 3 times more memory (or 7 times more) than explicit memory management to achieve equivalent performance -- less memory means more garbage collections. Unfortunately, more memory means longer pauses. Worse, if physical memory runs short, it's a paging disaster (although this can be fixed). Java - and garbage collection - are great technologies, but it's important to acknowledge their limitations (and try to address them).

Who installs software before knowing what it does?

  *You* do, if you have not gone through and analyzed every last line of code in every file in your kernel and userland source, and all your applications too.

Don't forget that there is more people than only me who actually take a look at the code. When they are properly signed the risk is minimized drastically.

Association for Computing Machinery

Yeah, but how do we know that these same folks didn't write the compiler, and have hidden code in the compiler to only be output when it receives this source code as input? Hmm?

In fact, computer use has been shown in studies not to be a major risk factor for carpal tunnel. Here's one article from a quick google search.

I can also personally confirm these claims. I worked in a bus factory for a couple summers and my hands would continually go to sleep at night after my 9 hours at the factory. Yet I have never had a problem from coding, even with weeks of 11-12 hour days.

Also, beyond all the other problems people have pointed out with using speech as input, it also interferes with the cognitive tasks needed for coding. Check out the article, for example.

It's an l dimensional space though. The PDF of the paper is http://portal.acm.org/ft_gateway.cfm?id=62050&type =pdf&coll=GUIDE&dl=GUIDE&CFID=70220506&CFTOKEN=528 80553, and is accessible to anyone who's had an undergraduate course in linear algebra. The crux of the argument is on page 4.

I'll also point out a relative of mine had this happen to her. She's a pretty, vivacious, young woman, married, was then working in a public relations firm. The IT fellow was always a little too attentive for her comfort, to the degree she actively avoided calling him for issues.

Eventually she needed her speakers for a project, but rather then call in creepy IT guy she asked office clever guy to take a look, it was probably just a loose wire or something. That was indeed the issue, however he also discovered an additional cable, running to a camera, mounted under her desk staring into her crotch, feeding into a nearby cabinet with a VCR.

Much hullaballoo ensued, everyone in the building heard of it within a few minutes, much to the ire of the police. There were fingerprints, and all of the fellas in the office but for creepy IT guy offered theirs for comparison. none of the supplied prints matched, IT guy quit, relative had her desk replaced with a table.

That's who you sound like when you post stuff like that.

The good news is Steve Jobs has been here before. I remember NeXT bringing around one of their boxes to demo at my local http://www.acm.org/">ACM chapter. It came with a nifty built-in microphone, to which someone immediately noted "great for spying!" The NeXT rep gave a smile and pointed to the red LED next to the microphone, hardwired to light up whenever the microphone was active.

This practice continues to this day at Apple, putting in hardwired signal LEDs to indicate when a camera is active. My expectation is that this will continue. Indeed I wouldn't be surprised if Apple were to even include a camera-active screen mode to brighten it for a better picture when the camera is active, possibly swapping in a white background.

IANAL, but my understanding is that if something's been published, it can't be patented. I read once (on /., so take it with a grain of salt) that sometimes a company will publish an invention when they don't want to go to the trouble and expense of patenting it, but don't want anybody else to patent it either.

I'm not sure what's considered "publishing" in this context. Maybe releasing an open-source program would be sufficient, or possibly you'd need to make a Usenet post, or send it to the JACM or something.

It often sounds (and experts say) that IT in North America is practicing something akin to slash-and-burn agriculture---get the fresh new CS grads, work them like dogs, and throw them away when they burn out 10 years later. (EA---the whole game industry, really---for example, is infamous for this.) Just like slash-and-burn agriculture, burn-and-churn IT is unsustainable, and an inefficient use of resources.

If employees don't want to work for your industry, maybe the problem isn't with the employees.

In a truely cashless society, there would be no way to have private transactions.

Except for digicash. (Sadly, the company folded.. No government or corporation really stands to benefit from secure anonymous electronic cash, just private citizens/consumers.

There used to not be a distinction.

The term "software" used to include both code and data, as both were simply forms of information which computer hardware used to perform some useful task. Even the ACM themselves used to only make the two distincions of hardware and software. The concept of three separate distinctions (hw,sw and data) is a fairly recent change (1990's) adopted by academia, and most states' taxing authorities are run by folks who got their college degrees back in the 1970's and 1980's when they learned the official definition of "software" included both code and data.

Mentifex was the original author of Mind.Forth, Mind.html and the AI4U ISBN 0595654371 textbook of artificial intelligence.

Mind.Forth was a primitive artificial mind written in Win32Forth for robots and based on a Theory of Cognitivity for artificial intelligence. AI functionality was developed by Mentifex first in Mind.Forth and ported subsequently into the Mind.html Seed AI for propagation throughout the installed user base.

Mind.html was an artificial intelligence coded by Mentifex initially in JavaScript for Web migration and in Forth for robots, evolving towards full civil rights on a par with human beings and towards superintelligence beyond any human IQ.

The AI4U textbook was reviewed falsely and viciously but found its way into libraries at such prestigious universities as the University of Hong Kong, North Carolina State University and Texas A&M University.

Technological Singularity was launched almost single-handedly by Mentifex against all odds and in the face of desperate opposition from the FAQ-writing AI Establishment and the Singularity wannabes whose revenue stream was threatened by the free Open-Source AI software released into the Web Wilds by Mentifex.

1. Clockless logic has been around for a long time, in fact Ivan Sutherland's Turing Award Lecture (I'm not sure this link points to the lecture, but the forum, topic and timeframe are right). was about this very topic.
2. With the very high clock rates currently in fashion, it is hard (perhaps impossible) to get the clock signal to propagate through the chip before too much of the cycle has elapsed.

You have a few good points. Just want to make a few things clear (my links may require subscription):
Many Linux advocates use security , internationalization and "free-ness" as a major selling point.
For security, many users in the US care about spyware and etc. sending off their private data. Meanwhile I didn't see as much concern for private data in India (I assume the whole identity theft factor will take a major role which is why I mentioned that). That killed off the security selling point. This is also why I also mentioned about Windows Updates since it can make a computer far more vulnerable to spyware and etc. However, US and India seem to share the lack of concern in performance factor.
For Internationalization, there has been a notion that Linux has great international support. However, when I had users try KDE's Gujarati, I didn't see any kind of quick adoption to the language. In general, users tend to need to see quick results before being convinced a product is worth adopting. So KDE's Gujarati could be "the best" out of every other interface out there, but it is not good enough to convince them that "Linux has great Gujarati support" (thus killing that selling point).
As for Linux being free, the Indian small businesses (the ones I interviewed with) had a pirated version of XP as opposed to US where many small businesses have a legal version that came with their computers. This can come in to play when these companies deals with larger companies (or governments) that may require their assets to all be legal (you can see an example of this in Thailand). The small businesses I talked to didn't seem to have a concern about it. Therefore, the "free" as in beer selling point was killed off.
So I tried those three major selling factors of linux on a few small businesses in India and they all didn't work out well at all. So yes, a lot of what I said is not India specific but those where the problems I saw upfront for businesses migrating to Linux.

You have a few good points. Just want to make a few things clear (my links may require subscription):
Many Linux advocates use security , internationalization and "free-ness" as a major selling point.
For security, many users in the US care about spyware and etc. sending off their private data. Meanwhile I didn't see as much concern for private data in India (I assume the whole identity theft factor will take a major role which is why I mentioned that). That killed off the security selling point. This is also why I also mentioned about Windows Updates since it can make a computer far more vulnerable to spyware and etc. However, US and India seem to share the lack of concern in performance factor.
For Internationalization, there has been a notion that Linux has great international support. However, when I had users try KDE's Gujarati, I didn't see any kind of quick adoption to the language. In general, users tend to need to see quick results before being convinced a product is worth adopting. So KDE's Gujarati could be "the best" out of every other interface out there, but it is not good enough to convince them that "Linux has great Gujarati support" (thus killing that selling point).
As for Linux being free, the Indian small businesses (the ones I interviewed with) had a pirated version of XP as opposed to US where many small businesses have a legal version that came with their computers. This can come in to play when these companies deals with larger companies (or governments) that may require their assets to all be legal (you can see an example of this in Thailand). The small businesses I talked to didn't seem to have a concern about it. Therefore, the "free" as in beer selling point was killed off.
So I tried those three major selling factors of linux on a few small businesses in India and they all didn't work out well at all. So yes, a lot of what I said is not India specific but those where the problems I saw upfront for businesses migrating to Linux.

You have a few good points. Just want to make a few things clear (my links may require subscription):
Many Linux advocates use security , internationalization and "free-ness" as a major selling point.
For security, many users in the US care about spyware and etc. sending off their private data. Meanwhile I didn't see as much concern for private data in India (I assume the whole identity theft factor will take a major role which is why I mentioned that). That killed off the security selling point. This is also why I also mentioned about Windows Updates since it can make a computer far more vulnerable to spyware and etc. However, US and India seem to share the lack of concern in performance factor.
For Internationalization, there has been a notion that Linux has great international support. However, when I had users try KDE's Gujarati, I didn't see any kind of quick adoption to the language. In general, users tend to need to see quick results before being convinced a product is worth adopting. So KDE's Gujarati could be "the best" out of every other interface out there, but it is not good enough to convince them that "Linux has great Gujarati support" (thus killing that selling point).
As for Linux being free, the Indian small businesses (the ones I interviewed with) had a pirated version of XP as opposed to US where many small businesses have a legal version that came with their computers. This can come in to play when these companies deals with larger companies (or governments) that may require their assets to all be legal (you can see an example of this in Thailand). The small businesses I talked to didn't seem to have a concern about it. Therefore, the "free" as in beer selling point was killed off.
So I tried those three major selling factors of linux on a few small businesses in India and they all didn't work out well at all. So yes, a lot of what I said is not India specific but those where the problems I saw upfront for businesses migrating to Linux.

Forgive the karma whoring: http://portal.acm.org/citation.cfm?id=63532

Any Tom, Dick or Harry can write subtly malicious steganographic code, or obfuscated ones. Real programmers leave no traces in their source codes: Bow to the leetest hack of them all.

Reflections on Trusting Trust. The first time I read this I was blown away.

More here. Legislation in this vein has been in the works for some time now, and this may be the best shot at getting anything passed this year. Still, that said, with the crypto exemption, I question the bill's true worth.

Also, if I remember correctly, they were some of the first to experiment with particle renders for CG (they used it in the Mask to create some of the storm/tornado transformations).

ILM introduced the concept of particle systems for film. It was first used for the Genesis Sequence in Star Trek 2. William Reeves then presented a paper at SIGGRAPH 83. He was also awarded an Academy SciTech award for it:

Particle Systems -- a Technique for Modeling a Class of Fuzzy Objects
Particle Systems
Particle Systems SciTech Award

Look at all they have done. While some of the stuff on there may have sucked... there is some really fucking good stuff on there.

I have a more complete list and that doesn't even include the hundreds of commercials they worked on:

ILM credits

Automated dump analysis is an old idea in the mainframe world, but almost unknown outside it. The microprocessor world grew up with interactive debuggers and an early user-as-programmer assumption. This hasn't translated well to the modern software world.

In the mainframe world, there have even been mainframes that recorded the last 64 or so branches using dedicated hardware, so that after a crash, the control path could be recovered.

What does the Mozilla project do with the data from their "quality feedback agent", anyway?

You're thinking of this kind of backdoor? You're right: in order to be able to really (i.e., to a level adequate for an organization like the US or UK military) "trust" any software, of course the org would have to bootstrap their entire computing platform, including writing their own compilers. [*1] It's not really that hard (again, for that sort of org). I'd be surprised and alarmed if I were to learn that they haven't been doing so as a matter of course.

As for the JSF software, if US refuses to turn over the code (sort of understandable why they'd want to), I suppose they could knock a bit off the price and sell the planes with blank computers, leaving UK to write their own software from scratch/specs.

--
[1] Yes, in assembly (or some intermediate language whose compiler they've written in assembly), with an assembler they've written in machine code, on hardware they've designed and built themselves (or audited the design and fabrication closely enough), etc., etc.

I hope for their sake that the Brits have their own compilers.

The compiler in question was not GCC, and the complete story can be seen in the paper reflections on trusting trust

I think you're thinking of Reflections on Trusting Trust by Ken Thompson.

(Mandatory reference) Reflections on trusting trust: http://www.acm.org/classics/sep95/

Spot on! Another question: How can you trust the net card (there was post not long ago about IPMI, and the potential for hiding complete remote control backdoors in network interfaces).

Then again, how can you trust humans to count perfectly?

What's wrong with paper
Nothing! Absolutely nothing. As much as my mom suggests I should write my masters or Ph.D thesis on "on-line voting", I relly think this is one of the areas where correctness is just too important to ever trust networked computers (which, afaict, is a strict requirement). Also, there's a lot of long-haired issues: how do we make sure each voter can vote at most once? How do we make selling votes difficult (My best guess: through social ways, i.e. education)? How do we make sure each vote is anonymous, yet at the same time make sure each voter can vote at most once? These are just hard problems in my mind.

In effect, since it's the foundation of democracy (for those nations that are still at least somewhat democratic, i.e. excluding the USA), we need to treat this as safety-critical systems. That includes the provability (and proof!) of correctness, one-time pads for encryption and all that rigamarole.

No. Please. That's the one area where a two-mile bike ride plus waiting in line to put a cross on a piece of paper really pays off well. Stick with the primitive technology here, due to the advantages of being primitive.

BNF originally stood for "Backus Normal Form", and the name Backus Naur Form was introduced by Donald Knuth:

@article{365140,
  author = {Donald E. Knuth},
  title = {Backus Normal Form vs. Backus Naur form},
  journal = {Commun. ACM},
  volume = {7},
  number = {12},
  year = {1964},
  issn = {0001-0782},
  pages = {735--736},
  doi = {http://doi.acm.org/10.1145/355588.365140},
  publisher = {ACM Press},
  address = {New York, NY, USA},
  }

Greatest ACM article: http://www.acm.org/cacm/AUG96/antimac.htm, demonstrating what I had thought from the beginning -- that the Mac is the opposite from how things should be done.

John Backus won the award in 1977 though, so it is quite legitimate to ask, as the original poster did, why they didn't recognize Naur sooner.

Aside from the obvious "what about buffer overruns?" questions, aimed at the usually poor competence Microsoft shows in writing code, there's also "what about cryptographic strength?" question -- maybe the NSA already has a simple and fast way to break whatever encryption BitLocker will end up using.

And, of course, there may well be several people working at Microsoft who actually work for the NSA or MI-6 or the FSB. (I'd be astonished if there weren't at least a few such people on the Microsoft payroll.) Those people may well do things as described in Reflections on Trusting Trust, without letting their superiors know.

they can insert in the middle of genes without causing harm because they can undergo chemical reactions by which they remove themselves from the RNA messages the genes make.

Am I too much of a geek, or did this remind anyone else of a rather similar situation with source code, Ken Thompson's fascinating 'Reflections on Trusting Trust'?

So, you say that you don't trust binaries from closed source companies?

Turns out you can't even believe in binaries you have built yourself.

Read this: http://www.acm.org/classics/sep95/

(Not for the paranoid!!!)

A very nice pdf article which shows why high precision is needed - for precision AND repeatability: Using accurate arithmetics to improve numerical reproducibility and stability in parallel applications.

RTFA you ignorant twit. There are more jobs, not less. There are more IT jobs now than during the dotcom era. Pay is going up, not down. Your little timeline is inane and ignorant. Stop acting like you have a clue, because you don't.

You may have RTFA, but you did not read the report from which the article cherry-picks its information. Although most categories of software jobs grew, two sub-specialties did not: database administrators and computer programmers (warning: PDF). From May 2003 to May 2004, the number of computer programming positions in the U.S. dropped by 4.5% and the number of DBA positions dropped by 3.9%. As for pay "going up, not down", the Federal Reserve does not agree with you.

"In other words, outsourcing has actually helped our economy and provided new employment opportunities for the displaced, just like almost every respectable economist has said it would, just like it has always done over the years. Yes, perhaps Paul Krugman disagrees, but I said "respectable" economist, which immediately disqualifies him. "

1st item... Statistics used by the report. Table 1-8. Lists a net tech job gain of 110,000...

What they don't mention is that between the two sample points May, 2003 to May 2004 is that the DOL changed the way they calculate employment statistics.

January 23, 2004, "Though U.S. jobs data have been ugly lately, some economists think the government's annual benchmark revisions, due in early February, will pretty the numbers up a bit. "

I for one wouldn't trust any number that the BLS publishes.

They also don't mention how many H-1B's ( 47% of FY2003 + 100% of FY2004 +no cap's) + all of L-1's(???) they let into the country during that period. My guess ~150,000... It doesn't look to good for US citizens..

2nd item.. Inflation verses Table 1-9.. Salary gains in the 2 to 4% range.

Just in case you have noticed. The biggest expense you'll ever incur in your lifetime is housing ~50% and climbing.
Guess what is not measured in the CPI?? You got it, housing.. (Oh the DOC screws around and tries to mask it by measuring the rent, but that doesn't reflect to true cost of living for a majority of Americans).

Guess what item has been inflating by leaps and bounds?. Housing, after that is medical expenses.

My bet.. The Real Inflation rate for 2003 to 2004 was in the 15 to 20% range.
That number kinda pooh-pooh's US tech workers meager, 2 to 4% salary increase, if it ever existed..

Summary.. US tech workers were and still are loosing ground, big time.

I am a bit skeptical of this report considering some of the members on the task force work for companies that outsource to these regions. There are also members for other nations that benefit from US outsourcing. I also wonder how much funding and donations the academic folks on the task force received for their institutions and pet projects.

Link to the actual report
http://www.acm.org/globalizationreport/

Task force members
http://www.acm.org/globalizationreport/biographies .htm

I am a bit skeptical of this report considering some of the members on the task force work for companies that outsource to these regions. There are also members for other nations that benefit from US outsourcing. I also wonder how much funding and donations the academic folks on the task force received for their institutions and pet projects.

Link to the actual report
http://www.acm.org/globalizationreport/

Task force members
http://www.acm.org/globalizationreport/biographies .htm

While the ACM or IEEE are theoretically advocates for US IT workers, they both receive a lot of money from the same companies advocating no cap on H1-B visas and so forth. Go to ACM's events and conferences web page and click on SIGCSE 2006. Who is sponsoring this in big letters on the bottom? IBM, Microsoft and Sun, the main drivers behind more H1-B visas.

There are other organizations which are not as in debt to these organizations. I did a web page of my own about this a year or two ago. Any organization like the ACM that takes massive money from these corporations which advocate no H1-B caps can not be trusted to advocate for IT workers. Only an organization that only depends on money from IT workers can be trusted. It's common sense. In fact, these corporate officers usually have more sense about these things, and who is on whose side, than many IT workers.

http://www.acm.org/globalizationreport/summary.htm