Slashdot Mirror

Perhaps.

I'll ignore threads - it's hard enough to prove a simple deterministic program is correct so I'll assume that this is running without an OS.

As for bit flips due to cosmic radiation, there are plenty of algorithms that ensure a bit hasn't been flipped in a transmission and I would suspect they could be applied to a situation like this. Google pops up helpful hints too, e.g. http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2002/01/r1toc.xml&DOI=10.1109/2.976922

Second, ISPs are not regarded as common carriers whereas local telephone companies are. The rational is that telcos operate as government granted monopolies and must therefore be subject to special regulation. Back in the day when we all connected to our ISP using a telephone line and modem, the ISP space was competitive and common carrier status did not apply. These days, in most regions there are only one or a small number of broad band ISPs and in many cases these are near monopolies because they are using infrastructure built under telco and cable TV monopoly franchises.

The whole net neutrality debate has further muddied the waters on whether ISPs are common carriers. The law governing privacy of electronic communications is anything but clear.

There is also a history of case law holding that email is not private and that employers are free to monitor email.

It sounds exactly like Amazon's patented recommendation algorithm that computes the cosine between binary vectors.

http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/ic/&toc=comp/mags/ic/2003/01/w1toc.xml&DOI=10.1109/MIC.2003.1167344

According to this article you can sort in constant time, although current systems allow you to sort in O(log (n)) time. However this only works if you have n^2 processors. Which was kind of my original point. Parallelization can offer significant increases in the speed of an algorithm, but only if you have an inordinately large number of processors.

computer science is the study of the theory. It has almost nothing to do with programming as you know it. CS is closer to math than engineering.

http://en.wikipedia.org/wiki/Computer_science

The truth is we DO have a language to tell the difference - people just use the nomenclature incorrectly.

CS = Theory and algorithm development

Software Engineering = System design and development

You know what a person that writes code is called? A Developer. Good luck getting the accreditation boards to ever accept that however. If the college you went to referred to the CS majors as people who programmed and learned web development, your college is wrong and likely unaccredited.

Regards,

Haha, yes, but it's not a very good model at all, really. I was actually referring to tuplespaces or an Erlang-like thing. There's a reason why Erlang doesn't use threads, and yet is also the most stable language environment there is.

I refer you to this IEEE article: http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover.xml&xsl=article.xsl&;jsessionid=HTWQvFsBn0gtqDQ3qVPNjzgwTkN18fKLvrhlJk02snyhs53jvx2C!935834109

Read the references section, start at about the 1950's and repost

This IEEE article sums it up nicely: http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover.xml&xsl=article.xsl

Also look up Erlang and tuple spaces. The latter are implemented in various ways: LinuxSpaces, JavaSpaces, etc.

Erlang's huge uptime and reliability is notable. It is of course the one language designed specifically for running parallel applications.

I look at the threading issue kind of like how we used to look at memory management: it's unnecessary bookkeeping for most apps and subtracts time spent on the actual problem domain. Ten years ago, we worried about memory management, but then garbage collection came along and for most purposes, memory management wasn't a huge issue any more (I'm not talking about the areas where C/C++ are crucial, obviously). In the same sense, programmers currently spent an inordinate amount of time debugging threaded apps when they should be focused on other things, like solving the business problem they've been presented with.

Clearly there's room for improvement, and I wonder if tuple spaces will do for parallel programming what garbage collection did for memory management.

Heres a good article from the IEEE Computer Society entitled "Setting Boundaries at Borders: Reconciling Laptop Searches and Privacy." The article discusses United States v. Arnold Federal and other precedent. Arnold, a federal district court opinion on a motion to suppress evidence, appears to have come out the right way. To add my own 2 cents, why would the fear of contraband be more intense at the border when the speed of information transfer on the internet has made such concerns all but irrelevant?

Intelligent Agents were a big deal at the beginnings of the dotcom bubble era. There are plenty ofBooks and Articles about them. A good part of Java's sandbox security model evolved from the anticipation that we would be allowing agents to come visit our computers to do their intelligent activities. In the real world other technologies did a better job at whatever agents were designed to do. As the article points out, Google and other well constructed search engines are much better at finding online information than a series of wide-flung bits of software. Well designed APIs filled much of the gap for more specific applications. Intelligent Agents did find one toehold in the marketplace though, spyware and botnets show just how useful it can be to have your software running on someone else's machine. Of course they're completely outside of any security 'sandbox' and get to do what they please. It sounds as if someone is making an attempt to capitalize on some IP before it expires.

Yeah, right.

Bluebag Project can crack any bluetooth device in some 6 hours. The current form of it has a potential to increase the speed 8 times (currently it uses 8 dongles to scan possible 64 channels in paralell. If you use 64 bluetooth dongles to scan one channel each, you gain a lot of speed).

When I read stuff like this it always amazes me that people actually think such things can be predicted for any degree of usefulness.

I doubt that those who fund actually believe that, but are in need for a proper envelope to direct the money to worthy and willing puppet researchers usable for other projects as well (I have the suspicion that there are a lot of those at the 'University of Arizona', all keen to use AI for repression, among them a Fei-Yue Wang (Chinese Academy of Sciences), especially interested in using robots in riot control — go figure).

CC.

Here are a couple more prior art candidates references:

http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/mags/co/&toc=comp/mags/co/1990/11/r ytoc.xml&DOI=10.1109/2.60879
http://books.google.com/books?id=obxCY0wcaTgC&dq=& pg=PP1&ots=xNhr72NKWt&sig=n8bM_SOzg7Trzj04Y1Xgx2tb dng&prev=http://www.google.com/search%3Fq%3Dreacti ve%2Bkeyboard%26ie%3Dutf-8%26oe%3Dutf-8%26rls%3Dor g.mozilla:en-US:official%26client%3Dfirefox-a&sa=X &oi=print&ct=title#PPP1,M1

Well I've done security audits for these systems and well lets see here: >>> The long story short is that most of these installations are physically protected from intrusion. Dude; I've done security audits on pipe-lines and electric power grids. Just because a substation in the middle of time-buck-two has a lock on the door doesn't mean the lock actually gets used. >>> First rate firewalling, ... A huge percentage of firewalls deployed even by pros have at least 1 large error in them. ( http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/mags/co/&toc=comp/mags/co/2004/06/r 6toc.xml&DOI=10.1109/MC.2004.2 ) And you obviously haven't developed SCADA software long-enough to realize that on the average Plant-floor, the knowledge required to properly construct and deploy a firewall just isn't there. The rift between the "Scada Engineering" crowd and the "IT" crowd is larger than you think. >>> and in most cases, complete seperation of internet and operations systems are in place. Oh wow ... not directly connected to the Internet. Hmmm, that's a tough one, Not! On average, I've found in security audits on site, 50% more network access/entry points than what the companies security officer knew about. And separation between Control and Enterprise network, you're blessed if you have a Cisco Firewall as protection. (Until the 3am Engineer puts in the remote dial-in modem completely screwing over your cooperate security ) >>> Physical alarms and access controls, id badges, Amazing how you can audit the physical access controls, simply with kind-words and a smile. (Thank you Mr Mitnick) >>> and real security guards do the rest. Yeah, 15 to 20 security guards, one some facilities covering 10 square miles. >>> I am not naive enough to suggest that any such situation is 100% perfect, Good, shows you may have learned something while "Developing Scada Software" >>> but at the very least, we are not talking about script kiddies. The problem that I've found, is that we're not even putting in enough to stop the script-kiddies. When a simple port-scan of a Scada device may "brick it" (Brick It: send it back to manufacture to get replaced) think what even script-kiddies can do. >>>If someone has a real reason or agenda to break into these systems, and enough money and skillful crackers, they will get in. You don't need money, nor skillful crackers. In the last stages of the "World Wide War-drive" effort of a year or two back, they started to get Wireless Scada networks being reported. :-) >>> For example, WiFi ethernet networks are almost never used in these types of systems Dude, they don't have to be used directly on the Control-Network. With the number and types of connections between Control Network and enterprise growing, the hacker just needs to find 1. I've see and heard first hand accounts of Security professionals doing security audits on the Enterpise network and finding themselves with access to control network gear. One particular chap, did an audit of a Cookie factory's Office network, and his scanner tool found a hole in the Control network firewall that resulted in 1million in wasted cookie dough. Now wireless use on these systems; have you had your head in the sand for the last year or 2 ? Get real! It's the typical flood of technology again, easy of use before any thought of the security implications. >>> -- that doesn't have the engineering necessary for this kind of data. Instead, proprietary solutions with microwave dishes, and other forms of FCC/CRTC licensed data radios are used. >>> While proprietary != secure, it does mean that a wardriver looking for an open access point isn't equ

I agree with you as does the publisher of IEEE Intelligent Systems in a recent editorial of his.

Not only is the combinatorics in Go greater than that of Chess but also the pattern recognition requirements in Go are much greater than that of Chess. With Chess, you have things like passed pawns, zugzwang, sister squares, and open files to recognize. In Go, you have things like life and death, thickness, shape, and the direction of play that you must be able to recognize. IMHO, the Go patterns are much more abstract than the Chess patterns.

However, let me take this moment to plug a great OSS Go program, GNU Go, which is the AI player part, and Panda-glGo, which simulates a Go board and can integrate with GNU Go. This is a great way for beginners to drill and improve their Go playing skills.

I suppose you're now going to try and say that the programs aren't underpopulated but that the US still can't produce enough graduates.

You didn't read it carefully enough. "The US" hasn't been able to produce enough CS graduates, which is why it has been bringing in foreigners to fill its CS programs. So, CS programs are full, but only because 50% of its graduates are foreigners, foreigners that need H1B visas in order to work in the US computer industry when they graduate.

Note that even with foreign students, the number of CS graduates in the US is ridiculously small; the total number of grad students in CS is similar to each the total number in psychology or political science, fields which don't exactly have thriving commercial industries.

So, for the third time, according to whom?

Since you seem to be incapable of doing a Google search, here are the NSF numbers:

http://www.nsf.gov/statistics/infbrief/nsf06321/

In 2004, total new CS grad students are made up of 3651 US residents and 4243 foreigners. CS enrollment declined 6.3% that year alone, a trend that's been going on for several years, and I suspect the figures for 2005, 2006, and 2007 are worse.

Here's a nice graph:

http://www.nafsa.org/_/Image/_/presidents_graph.gi f

Here's a comparison with other nations:

http://mwhodges.home.att.net/science_undergrad_int l.gif

Here is undergraduate CS majors over time:

http://www.computer.org/portal/cms_docs_computer/c omputer/homepage/0306/r3dive01.jpg

There is no shortage of qualified native born American scientists and technology workers--no matter how much you might wish it to be so.

Well, that's an unsupported assertion by you that flies in the fact of facts.

But even if you were right, so what? What economic, social, or moral imperative do these companies have to hire you instead of someone in India or China?

First off, it's a Roland the Plogger story, so you know it's clueless. Roland the Plogger is just regurgitating a press release.

Here's an actual paper about the thing. Even that's kind of vague. The general idea, though, seems to be to insert a layer of code-patching middleware between the application and the hardware. The middleware has access to CPU instrumentation info about cache misses, power management activity, and CPU temperature. When it detects that the program is doing things that are causing problems at the CPU level, it tries to tweak the code to make it not do so much bad stuff. See Power Virus in Wikipedia for an explaination of "bad stuff". The paper reports results on a simulated CPU with a simulated test program, not real programs on real hardware.

Some CPUs now power down sections of the CPU, like the floating point unit, when they haven't been used for a while. A program which uses the FPU periodically, but with intervals longer than the power-off timer, is apparently troublesome, because the thing keeps cycling on and off, causing voltage regulation problems. This technique patches the code to make that stop happening. That's what they've actually done so far.

Intel's interest seems to be because this was a problem with some Centrino parts. So this is something of a specialized fix. It's a software workaround for some problems with power management.

It's probably too much software machinery for that problem. On-the-fly patching of code is an iffy proposition. Some code doesn't work well when patched - game code being checked for cheats, DRM code, code being used by multiple CPUs, code being debugged, and Microsoft Vista with its "tilt bits". Making everything compatible with an on the fly patcher would take some work. A profiling tool to detect program sections that have this problem might be more useful.

It's a reasonable piece of work on an annoying problem in chip design. The real technical paper is titled "Eliminating voltage emergencies via microarchitectural voltage control feedback and dynamic optimization." (International Symposium on Low-Power Electronics and Design, August 2004). If you're really into this, see this paper on detecting the problem during chip design, from the India Institute of Technology in Madras. Intel also funded that work.

On the thermal front, back in 2000, at the Intel Developer Forum the keynote speaker after Intel's CEO spoke, discussing whether CPUs should be designed for the thermal worst case or for something between the worst case and the average case: "Now, when you design a system, what you typically want to do is make sure the thermal of the system are okay, so even at the most power-hungry application, you will contain -- so the heat of the system will be okay. So this is called thermal design power, the maximum, which is all the way to your right. A lot of people, most people design to that because something like a power virus will cause the system to operate at very, very maximum power. It doesn't do any work, but that's -- you know, occasionally, you could run into that. The other one is, probably a little more reasonable, is you don't have the power virus, but what the most -- the most power consuming application would run, and that's what you put the TDP typical."

From that talk, you can kind of see how Intel got into this hole. They knew it was a problem, though, so they put in temperature detection to slow down the CPU when it gets too hot. This prevents damage,

The resolution capability of the human eye provides the ultimate limiting factor in displays. Unfortunately, in the past estimates of this value varied considerably because we lacked a good model of the human eye. In 1998, however, Michael Deering proposed that the resolution of each eye topped out at 16 million pixels.

Compare this value to what we see in a movie theater. Studios now regularly scan movies from film to digital intermediate formats for editing. The current state of the practice is 4K a resolution of 4,096 × 2,160, or about 9 million pixels.

Robert Clark, a researcher for the US Geological Survey, points out that to reach a human's maximum visual acuity requires 530 pixels per inch for a 20 × 13.3-inch display viewed at 20 inchesa total of 74 million pixels. Clark also estimates that devices will need roughly 576 million pixels to display a 120-degree field of view at the limits of human vision.

Already done, thirty-five years ago.

This brochure from the ACM, IEEE Computer Society, and the Association for Information Systems claims, "Estimates for job growth in the United States range from 38% to 56% across the computing spectrum. With more choices and more opportunities, it's a better time than ever to begin a career in computing. In fact, according to CNN/Money Magazine in 2006, software engineering is the number one best job for salary and opportunities!" The document is targeted at high school students. In my opinion all the parents have been taken in by the FUD. I have worked in Software Engineering since 11/95 and have seen the market keep growing. More and more people are relying on technology and software everyday. Applications are never "done". There are new features to add, new hardware to support, and new technologies to take advantage of.
As for outsourcing, I was involved in an attempt to outsource some software development. They wanted to find a company in India who could do Windows device drivers. Again and again, we could talk to the PhD highups but when we pushed to talk to the actual folks that would work on the project we found they had little experience in driver development and almost no experience in development on multiprocessor severs. This happened with several different companies. Also, folks are finding that outsourcing to far away countries is a massive management headache. It takes all the problems of local contractors and makes them worse.

Outsourcing is like anything in life...in the end you get what you pay for!

It's impossible NOT to oversubscribe.

For example, let's assume that backbone network is 10 GBit (actually, it's usually much less). So just 2000 subscribers at 5MBit will saturate the backbone. And 2000 subscribers is NOTHING. The current backbone network infrastructure just can not scale much.

And there's another problem: routers. Central router speeds must scale as O(N^2) with the number of nodes. This can be alleviated by using clever network topologies, but only to a certain degree.

There's a good article about these problems:
"The Next-Generation Internet: Unsafe at Any Speed?" ( http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/mags/co/&toc=comp/mags/co/2000/08/r 8toc.xml&DOI=10.1109/2.863968 ). It was written back in 2000 but it's still accurate today.

This versatile model could one day be used for automobile driver's assistance, visual search engines, biomedical imaging analysis, or robots with realistic vision

• There already exist working automated driving software. The december 2006 issue of IEEE Computers magazing was on them last month. Read about the car that drove a thousand miles on Italy's road thanks to Linux, no less.
• Visual search engine exist, at the research level. The whole field is called "Content Based Retrieval", and the main issue is not so much to search, but to formulate the question.
• Biomedical image analysis has been going strong for decades and is used every day in your local hospital. Ask your doctor !
• Robotic vision is pretty much as old as computers themselves. There are even fun robot competitions like robocup.

Oops, my bad. That site has abstract circuits and doesn't show the actual transistors. This paper shows some circuits.

Strange then that artificial intelligence research is almost as old as computing itself.

Strange then that artificial intelligence research is almost as old as computing itself.

• 2006 -- Large Display Research Overview
• 2005 -- Large display user experience
• 2004 -- Display space usage and window management operation comparisons between single monitor and multiple monitor users
• 2003 -- Towards characterizing the productivity benefits of very large displays
• 2003 -- Effects of Visual Separation and Physical Discontinuities when Distributing Information across Multiple Monitors

• 2004 -- A Diary of Task Switching and Interruptions

I am a student in Software engineering at an engineering school that gives and discriminates very well between:
software engineering
IT engineering
electrical engineering
mechanical engineering
etc (they dont have CS, only engineering. . . )
lots of our teachers in soft eng. work on the IEEE comitees.
To make the most out of the lot of overlapping curriculum, refer to this:
http://www.computer.org/
(big pdf file)

The problem with threads:

http://www.computer.org/portal/site/computer/menui tem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pN ame=computer_level1_article&TheCat=1005&path=compu ter/homepage/0506&file=cover.xml&xsl=article.xsl

Basically, even the simplest tasks require significant armor plating to run correctly.

OTOH: Multi-PROCESS programming is far simpler than multi-THREADED programming.

"- how can a driver have the same bug on windows and macos x?"

Quite simply; the Intel card is, in both cases, doing things like UDP and TCP offload from the main system. This means the card and driver together have an internal state in software to manage it, and (due to the asynchronus nature of networking) you can get the hardware and driver software's core into a situation where they don't agree on the state.

The small glue layer that deals with the OS hooks is a static translation layer that wouldn't be involved. The SB Live! and Audigy drivers in Linux are the same driver as the Windows Creative driver (well, they were about 6 years ago when they contributed the code). nVidia uses the same driver code on all platforms as well. For anyone who's written a driver, this is easy to understand.

"- why use this stupid external card? what are the chances it did have the same chipset as the internal one?"

He uses it because it's a timing race, and because it's easier to demonstrate with 2 cards in the system. With a 4000 microsecond delay, this means it's likely taking a bit longer for the OS to service the interrupts between the two cards; enough that the driver bug can show itself. There are likely other ways to tickle this bug that don't require multiple cards, but then you'd have to have something running on the OS. Still, If you setup a machine to throw packets around, you could make an intermittent crash bug appear on an OS -- that's not cool.

"- and odds are the bug is a buffer overrun... does it take a SO LONG for apple to fix a stupid memory overrun?"

A stupid memory overrun? Man, you haven't programmed ever, have you? A timing related bug in device driver code is probably the second hardest bug you'll ever encounter to debug (the first would be the core of the OS itself). Concurrent programming is difficult.

It's responses like these that show why this person had been light on detail. Most people lack the technical background in OS design to understand this issue.

Actually, it all depends on the workload. Some would say that Processes are a Unix hack, because they didn't think about threads.

Actually, not so much. Saying you "didn't think about threads" is like arguing that you went with protected multi-tasking OS and "didn't think about DOS". Adding memory protection and compartmentalisation is the only difference between a thread and a "process". In most cases, you just don't care anyway ... all you want is to not block, and threads are the worst fix for that problem.

Any advice, Slashdot?

This is the point I think people are missing. It's not just the technical details that are killing CORBA, its the fundamental assumption that transparent distributed objects are a good idea. I wrote an academic paper on this.. the conclusions will be no surprise to experts... but I'm trying to explain and quantify the issues: Web Services versus Distributed Objects: A Case Study of Performance and Interface Design William R. Cook, Janel Barfield To appear, Proc. of the IEEE International Conference on Web Services ( ICWS) 2006. September 18-22, Chicago, USA

Maybe they need these error-checking techniques for spreadsheets (see also here)?

For members of IEEE with a subscription to IEEE Computer Society's Transactions on Software Engineering, the last issue (April) has a very interesting article related to this stuff titled: Interactive Fault Localization Techniques in a Spreadsheet Environment. Basically, the article explains how they have worked to develop and test techniques that allow "end-user programmers" (people who create formulas in spreadsheets and such) to use automated fault localization testing tools to help debug their "applications" (spreadsheets) at runtime. Pretty interesting stuff that they found in their analysis. (It's easier for you to just go read it than for me to attempt to summarize it at the end of my work week. ;)

This post was up earlier: http://www.computer.org/portal/site/computer/menui tem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pN ame=computer_level1_article&TheCat=1005&path=compu ter/homepage/0506&file=cover1.xml&xsl=article.xsl&

and what struck me is how many of these problems go away if the hardware context is encoded in the PTP/PTE for a page of memory. SPARC does this. Contexts could be created for drivers and the driver could address only that set of pages of memory, and not the whole kernel.

Here is some good readign amterial, maybe people should read and _understand_ it before posting on the subject..

This does not mean you have to agree with the guy.

http://www.computer.org/portal/site/computer/menui tem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pN ame=computer_level1_article&TheCat=1005&path=compu ter/homepage/0506&file=cover1.xml&xsl=article.xsl&

http://vig.prenhall.com/catalog/academic/product/0 ,1144,0131429388,00.html

Any kernel with upwards of 2.5 million lines of code is going to be incredibly buggy, perhaps it's time to rethink and go back to the microkernel

Read about Minix 3 two-thirds into the article.
They claim it to be less than 10% slower compared to a monolithic kernel. You can check for yourself -- Minix 3 is freely downloadable now (minix3.org), they even provide a live cd.

That's not a bad idea, except that computer vision like that is hard. It could be done, though -- you'd just have to combine the hand-recognition from this with the gesture-recognition from this. (The former knows how to differentiate skin from the rest of the environment (and thus find the hand), but doesn't know many gestures. The latter can recognize more gestures, but relies on a silhouette to find the hand.)

Some may be interested in the IEEE design competition: http://www.computer.org/csidc, which typically involves designing a hardware/software system constrained within a pre-determined theme. Judging entries includes considering the creativity in addressing the theme, how well the design/development process was planned and executed, does the system work correctly, etc. Submissions are initially judged as paper designs. Those submissions that make the cut have working models judged.

I believe both contests have their merits.

This seems to be a good overview of clockless chips. I can't vouch for its accuracy (not my area), but the source - IEEE Computer Magazine - should be good. The article was published March 2005.

(warning: PDF)
http://csdl2.computer.org/comp/mags/co/2005/03/r30 18.pdf

Hey I got a link Newer by two days than the article posted. Anyway, at least someone isn't repeating a post. There were Amulet cores which were essentially ARM32 clockless cores much before ARM did make a public announcement. I wouldn't be surprised if the 996HS is a rebranded and reworked Amulet. Amulet was quite well known in Academic circles for at least 3 years. That's my $0.02.

I disagree with that assertion. But it may depend heavily on what our respective definitions of "computer scientist" and "software engineer" are.

How do you figure? As a developer of commercial embedded software, that hasn't been my experience. Teams usually consist of both...

Which is unusual. Software in many other application domains is developed almost exclusively by CS grads. Hence "embedded software [...] the software most likely to be written by people trained as engineers".

...but code written by Electrical Engineers, well, let's just say it's notorious.

Obviously, I can't speak to your personal experiences. I've seen some absolutely gawd-awful code written by graduates of "good" CS programmes and "good" engineering programmes.

Above all else, please save your judgement for the quality of particular education programs instead of blanketing an entire field with your views.

Fair enough. Perhaps I did generalize little much. In my defense, allow me to point out that these are not my views alone. See, for example, this article by Steve McConnell, or this article by David Parnas (I apologize for being unable to find a version available to non-IEEE members). Both of them make the same points about the differences between CS training and SE training that I have been attempting to make. It's not a question of whether or not CS grads can learn to do software engineering (they undoubtedly can, just as physicists can learn to be electrical engineers). It's a question of what the appropriate focus of the undergraduate programme is, and of whether we should assume that a CS programme is the correct preparation for industrial software developers.

It's quite a bit cheaper if you're a member, but I love IEEE Software magazine.

Milalwi

IEEE Software is my favorite software development magazine. It tends to straddle the academic and professional worlds in a way that most other publications don't. To give you a sense of how good it is, it was once edited by the author of Code Complete, and it features a column by the guys who wrote "The Pragmatic Programmer".

I like Dr. Dobbs Journal, C/C++ Users Journal, Communications of the ACM and IEEE CGA.

If you haven't heard of DDJ or CUJ before, give them both a try. DDJ covers all sorts of stuff and (as an example) the October '05 CUJ had the best accidental intro to template metaprogramming I've ever seen.

One of CACM's selling points is that the articles are regularly featured on slashdot. :p

IMO, IEEE CGA is much more useful to me than any of ACM's SIGGRAPH stuff. This is only relevant if you're into computer graphics at all.

I'm thinking of joining the Association of C/C++ Users for it's C-Vu journal, I dunno.

I read 2600 for the hell of it.

Your mileage will vary.

Here's another link, a paper about clock-powered CMOS. Most of the university research I've seen on this kind of stuff is this sort of clock-powered CMOS.

Here you can find out how many experts think a undergraduate program in computer science should look like. http://www.computer.org/portal/cms_docs_ieeecs/iee ecs/education/cc2001/cc2001.pdf

You are correct that Compaq killed the alpha after Intel "showed them the Itaniun roadmaps",
but now that Intel owns the alpha rights and employs a lot of the engineers that developed it,
they may have a different view from HP.
I wonder how many of the people that put out this paper now work for Intel?
http://csdl2.computer.org/persagen/DLAbsToc.jsp?re sourcePath=/dl/proceedings/&toc=comp/proceedings/i sca/2002/1605/00/1605toc.xml&DOI=10.1109/ISCA.2002 .1003586