It all completely depends on your level of skill. I work for a company that is growing very fast, and my group within the company is growing even faster. We're looking as hard as we can for good qualified programmers/engineers, and we have a very difficult time finding good people. For every 40 or so people we interview, we hire one. The issue is that a lot of undergrads are under-prepared, and we we require people who are top-notch at problem solving, top-notch at engineering, good at C/C++, good at system level concepts, very good w/ graphics HW, and good w/ graphics algorithms. It's very hard to find the skillset we need, and so we pay top dollar for it when we find it. If you have the skills to work at a company like mine, you'll do very, very well. You also have to be willing to work very hard (at least at times). If however you only know how to code HTML and perl (and aren't willing to learn anything else), or if you think that programming knowledge stops w/ what languages you know, or if you don't develop deep expertise in at least one area of computer science (like graphics, databases, language theory/compilers, security, networking, etc.), if you aren't willing to constantly keep learning the latest and greatest new technologies/tools/techniques, then yeah.... you might be in for a rough ride.
My company will hire good programmers wherever they are. At least in my group, we'd prefer to hire US programmers. It's easier if everyone works within a few timezones of each other. It's easier if everyone speaks the same language well. It's easier for engineers to meet w/ customers. There's just less friction overall. However, if we can't find the right people in the US, we will hire from Europe, from India, from China, from wherever. For our team, it has nothing to do with cost, and everything to do with finding the right people.
It's like any industry, if you work hard and make yourself valuable, you will always be employable (and will be able to make VERY good money), but it's just not like it was the late 90s: you actually need to have some skill (and motivation) to survive these days. I have no worry about losing my job to someone from another country, because I am very good at what I do, and it would be very hard to find someone who is willing to work as hard as I am, and who has the level of skill that I do.
I'm a PhD student working in computer graphics, and I have to say... where's my pork? NSF funding has almost completely dried up, military and homeland security spending has all gone to corporate pockets (or savy small business pockets), and corporate funding is very, very scarce. I've been lucky enough (and had enough hustle) to just barely bring in my own funding for the last year and a half or so, but everyone I know is pretty well starving for any sort of research funding. Highly successfull professors and researchers from all over are not getting the funding they need for some very good tech research proposals.
I don't know who's supposedly getting all this tech pork, but I can pretty well assure you that it isn't universities.
It really, really depends. A good employer will try to people with a strong capacity to learn, and good problem solving skills. Once hired the employees generally just pick things up as they go. It's kind of expected at top tech companies that you'll stay on top of your field, and learn everything you can. IF however your job requirements change drastically, a good employer usually sees it as in their best interest you train you (or give you the time to train yourself).
What you have is really a company with bad management. First of all, giving a rats ass about any sort of certificate (i.e. MCSE, or whatever else) is usually a bad sign (means they are more concerned with beaurocracy than with reality). Then the fact that they trained the wrong person is a bad sign. The fact that their communications with you is so terrible is a really, really bad sign. Many other companies would handle this far better than yours has.
That being said, it looks like it is indeed your own problem to train yourself. My best advice would be to train yourself as well as you can (forgoing personal life for a while), and then jump ship for a company with better management. Look for a company where management cares more about how well people can problem solve than what certificates they have (sometimes hard interview questions and logic puzzles are a good guage of how seriously they take problem solving). If they place a strong emphasis on teamwork, and trying to retain good people, that's another good sign.
I've worked in several different environments (and companies) over the years, and I've worked with a lot of programmers. I've known college dropouts who were stellar programmers and could really deliver solid products on time. I've also known PhDs who couldn't be trusted to write (let alone maintain) good code at all. The one constant I've seen in good management is that they can recognise those programmers (and IT) people who are good, and those who are not. They try hard to support (and retain) those who are good, and nurture those who are not (and cut them loose if they refuse to be helped). Look for a manager like that if you can.
I'm currently a PhD student in a top college in the US. I can attest that the article is basically correct regardling underdgraduate eduation.
Most top colleges are research schools. Research schools (as the name would imply) have one primary motivation: research. The professors they hire tend to reflect this. Most of these professors are very, very good at research and are often not so good at teaching. But this doesn't really matter. In the day to day business of these schools, teaching undergrads is a burden, not a serious responsibility. Many of them do what they can to try to get rid of non-optimal undergrads. Not because the undergrads show no promise, but because it simply takes too much time and effort to help them. To be fair, there are a good number of a very dedicated teaching professors and lecturers, but these people are not well supported by the administration (and are in the minority).
There is a LOT more that could be done to further teaching of engineering in the US. Sadly, if you want an engineering degree, the best places to get them are often the second tier universities. Live in California? Want an engineering degree? Many people think the best place in CA to get a degree is the UC system (and this IS true of grad school), but the truth is, the CSU system (Cal State University) is often a better place for undergraduate learning than the UC system. Placing undergraduates above research would be a HUGE step up for much of the US college system, but undergraduates have not (until recently) paid as well as research. In the CSU system, you are often more likely to find professors who are dedicated to teaching, rather than research. In the UC system, research is the #1 goal, and anything else (including teaching undergrads often) is a bit of a distraction.
To blame TAs completely would be unfair, and to blame professors completely would be unfair. In my experience, most of the blame lies squarely with the top administration, and their funding priorities. They tend to want to hire professors who ONLY want to do research, and view teaching as an ugly chore. Many of my undergrad classes had 200+ students (some as many as 800+). Physics was all about weeding out the weak (first semester core physics contained 350+ people, 5th semester contained 25 people). The whole atmostphere was one of destroying all but the ubermensch. Those unprepared (or not perfectly motivated) were left to fail.
Luckily for me I do well in such circumstances, but if the US wants to do well over the long haul, it would be best not to get rid of everyone who isn't just like me. Most of my colleagues in grad school are either Chinese, Indian or German. I wish all of them the very best (they are all incredibly bright and motivated), but I wish that more of my own countrymen were here as well. I know that many of them are quite smart, but I also know that many of them are defeated by poor professors, and poor support. Not to mention (of course) very good pay outside of the engineering/science world.
Actually, I know a lot of graduate students who will be really happy about this. It turns out that for a lot of research uses, 512 MB of ram would be really useful. Examples include 3D volume data-set visualization and general purpose GPU computations (GPGPU).
I don't know where ATI expects to make the money on this (certainly not that much $$$ in the research market), but I'm personally glad that they released this card.
The big question in my mind now is how good the cache performance is on this new card.
VR is coming, just slowly. I am working on my PhD, and I'm specializing in VR technology. I can tell you that the basic problems are twofold:
VR is expensive
Most people don't currently NEED VR, so compelling applications (outside of a few small domains) are somewhat rare. This will change over time.
There's of course a lot more to it than just that, but that is the basic problem. I've seen all sorts of programs that people would find interesting to run at home, but not vital to run at home. It currently isn't worth the cost for most people (anywhere from $5k for bargain basement stereo vision with poor tracking, to $1 million+ for a cave + haptic/robotic interfaces). People won't use VR until it is (a) unobtrusive, (b) cheap, and (c) intuitive.
On the 3D display end, VR needs to move from large space filling displays like caves to small setups like a small pair of glasses (current top end devices from manufacturers such as MicroOptical and Microvision give a glimpse at possible avenues forward). Ideally, these glasses should still let you see the real world (referred to as augmented reality, rather than virtual reality). This is far less disorienting for many people. There are also technical problems with HMDs (head mounted displays) aside from size and weight. The best HMD resolutions today are generally about 1280x1024, and the field of view often isn't stellar. For many people, these displays can cause headaches. The closer a display is to the eyes, the higher res it needs to be in order to avoid ill physiological effects. Then, the VR applications themselves need to run fast enough to have very little lag (ideally less than 12 ms between a user's action, and the application visually responding). If the lag gets too large, many people begin to get motion sickness (this is potentially a huge barrier for many people w/ VR). One alternative to VR glasses is projected displays, but without some additional engineering & mass production, these displays are not likely to be very cheap in the near future (and these displays still require some type of glasses, either shuttered glasses, or polarized glasses). The final visual alternative (ignoring fancy and expensive volumetric displays) are auto-stereoscopic displays, which work w/o special glasses. These displays have the downside though of requiring the user to sit/stand in a precise location in order to get the 3D effect.
Motion tracking also needs to get significantly better. Current motion tracking techniques (for gesture recognition, head tracking, etc.) are generally quite bulky and expensive. Some image processing techniques using video cameras show promise for cheap compact systems. Large scale motion tracking and registration (i.e. matching your position and orientation precisely with a map and models) is a much bigger problem for outdoor situations. GPS is one of the better ways right now, and that is abysmal (GPS gives positional accuracy to within a few meters, and no clues about orientation. VR apps require position to within a few centimeters usually, and orientation to within a degree or two). There is a fair amount of research into improving this, but it will likely be several years before any non-miliary applications emerge.
Finally, once VR is cheap enough (less than $2K USD for 3D vision and tracking), and small enough (i.e. a small/light pair of glasses, and at most a few stationary webcam sized cameras, or a single 3D projector), then average people can start to think about using VR. Even then, people won't use it until there are compelling applications. The first big applications will of course be games, but outside of 3D modeling, medical data, scientific data, psychology and geology there have been few compelling uses shown. Clearly there are a lot of compelling applications just waiting to be developed, but until VR becomes cheaper, smaller and more intuitive, these will most likely not be developed.
Don't take a major just because it'll make more money. Choose the one you'll enjoy more. Nothing leads to burnout faster than a job you don't like.
From my observations of people I know, as long as you are competent at what you do (and you would be surprised how many CS people aren't) you will not have trouble finding a job with either a hardware or a software based CS degree.
This solution is exactly the opposite of what I want. I don't really want to lug a computer around with me. I really want to take my data with me, and just use whatever computer is handy nearby. I use a laptop because that is the smallest computer that fits my needs that I'm willing to carry everywhere. However, I would happily have a system where I could use the data on my laptop on any other machine I use as well, just by connecting my laptop (or my laptop's drive) (something more elegant than making my powerbook a dumb firewire drive at least).
However always having the same RAM/CPU/GPU in every machine I use, and just changing the shell? Why? What's the point? Where is the advantage? The whole point of a desktop is the embarrassingly large number crunching power. If I never needed to run big FEM simulations or large VR environments, I would never even bother with a desktop.
I'm not sure which distro makes the most sense (although, for a school setting, I'm fond of Fedora Core 3), but I definitely think that they should look into a system to manage a large group of machines from a central point.
I've been using stateless linux from RH on our local cluster, but for a more polished solution, I would recommend onesis (what Sandia National Lab uses for their cluster management) http://onesis.org/index.php
A solution like this can make upgrades/changes to the computers in the network much less painful than what a lot of sysadmins use.
More often then not when I need a piece of software that has an evaluation version, that software is for a fairly small price (<$1000), and for a fairly urgent need (i.e. debugging some piece of code, defragmenting a hard drive). Sometimes it is for a less pressing need (a new source code control system), but always, when I download an eval version, it is because I am in the process of research.
Now, often times I'll come across something that seems ideal, only to find later that I've found an even better tool. In your company's case, I think it entirely possible that somebody has signed up for the eval to see if it might fit their needs, but while they are waiting for the username/password to arrive, they find something that fits their needs even better. Or perhaps a few hours is too long for them to wait?
Anyway, I rather suspect that between the time they order the eval, and the time they get the username/password, they've found some other solution to their problem.
Yeah. That's a good sentiment if you have a compiler with some decent diagnostics (i.e. "'}' expected on line 554" or something like that), but most of these errors are very tough to catch in a non-compiled language (or rather an interpreted one) where some random user agent (read: browser) can handle bad code in any number of unexpected ways.
If HTML was compiled and then released, I would agree, but the reality is that it's not. Any tool that helps allow for this and still comply with the intent of the author is a helpful tool.
Don't get all snobbish just because you can program and others can't.
Let me start by saying that I've implemented S/MIME for several different products on windows platforms, and have a reasonable amount of experience with what I am talking about (at least where it relates to the windows world).
Why don't people develop an email client that supports S/MIME or PGP/MIME for Linux? The crypto toolkits. It's that simple. The tools are really complex, involve math that most people aren't familiar with, and invlove security, so if you don't do it just right, it might be insecure.
Don't even think about using a third party toolkit for a linux app (unless you want to make the app non-open source). You would go bankrupt 100x over if you tried that. They are absurdly expensive for the most part (both the PGP kits from Network Associates, and the RSA kits and so on). I'm not over familiar with what might be available already open source, but I would be extremely surprised to find an open source toolkit that handled all of the neccessary algorithms and encodings.
Not long ago, you couldn't use the RSA alg without paying royalties to RSA (of course you can now). That severely limited what you could do with open source RSA based algs. You also had the problem of export controls and ITAR etc. Just ask Phil Z. why this is a pain in the ass. So until just recently it would have been almost absurd to support S/MIME on open source. (Being as you would have had to pay RSA royalties on each copy of your free toolkit, and then get commerce department approval to export your toolkit (i.e. put it on the internet for general consumption) if you are in the US).
Even today, if you want to develop an S/MIME client for linux, you will still need to write a good toolkit that handles all of the cryptography algorithms as well as the encoding/decoding of ASN.1 data (and other data formats if you are using PGP/MIME). Your toolkit must be open source (well at least it seems like it SHOULD be anyway), it must be secure (i.e. good PRN generators, zero out used memory, take advantage of cryptographic hardware if it is there, etc.), and it is going to take a heck of a long time to write.
Now, when you are all done with the toolkit, then you can integrate it into an email client, with all of the UI that that may or may not require. All for a feature that almost nobody will use, and for functionality that you could have gotten (for the most part) using PGP and a little extra work.
I think security is "a good thing", but today very, very few people use it, and most people simply don't care about security. Partially becuase it is so complex to do and to use properly, partially because most people just don't see the need for it in their day to day lives. Even in the simplest implementations, security makes exchanging email more complex because both parties must first create keypairs (and certs if using many protocols), and then somehow exchange them.
Don't get me wrong, I think that email clients with built in security (such as S/MIME or PGP/MIME) can be a very nice thing, but I'd say that at this point they probably aren't worth the effort on Linux.
NOTE: Why was it (relatively) easy in windows? The cryptography API that is part of windows. It has (more than) its share of flaws, but you can work around all of them that get in the way, it's free, and it's guaranteed to be on every windows box out there (excepting Win 3.x). Say what you want about M$ (I am not a big fan), but the gazillion APIs in the OS do make it easy for developers to add new features to existing apps in a relatively small amount of time (assuming that the API works and/or is documented). (I know, I know. The same can be said of open source, assuming that what you want is out there already). If my work had been targeting UNIX platforms instead, we would have had to have licensed a toolkit from RSA probably, and that would have cost us at least a quarter million, whereas the M$ stuff was free.
What is really interesting is that at VP at Sony has essentially just pledged that the company will be seeking vigilante justice. He didn't mention anything about waiting for the court's decision, he simply states that they are going to take matters into their own hands, and bring the 'rogue' company to justice as Sony sees it.
Vigilante justace was both illegal and looked down upon in the old west. The same is true today. If Sony really does take to this course of action, it will most likely come back to haunt them, either legally, or through public relations.
Most people on this thread are talking about this being an issue of corporate vs. individual rights. While this may be true on a broad sense, I think that the most important point is that Sony has decided that the law doesn't work for it, and that in order to best protect themselves they need to work outside (or at least on the boundary) or the law. I'm sure that Sony won't explicitly violate any laws in getting their firewalls up. I'm pretty sure that it will be through strongarm tactics against large providers like AOL, @home, SBC, Verizon and others. Perhaps they will also call in some political favors, and get some laws passed to allow them to do what they want. The end result though is that Sony has decided that living in a democratic society does not suit it, and so it will attempt to force society to it's will.
Only time will tell what this will do to society, but I believe that if Sony does attempt this, this is going to be one of those little tests that our country has from time to time to see how much it really wants to maintain a democratic society. If we rise to the occasion and show Sony that it must play nicely and by our rule system, then I believe that it will be a big step for America. If we allow them to trample about, then we have taken one more step towards relinquishing the rights of a democratic society.
And thus we also need more anonymous remailer type proxies. You could encrypt your information, and then encrypt it again, this time including final destination info and intended for the re-router, and then send it to an anonymous re-router. The re-router would decrypt the stuff you encrypted for it, and then use the destination info to send along your encrypted data to wherever it was destined.
This way IP analyses becomes much more difficult. This is especially true if the re-router has a lot of traffic, and intoduces random delays before sending packets back out into the world.
It seems to me that the vendors who decided to continue with plans to make their equipment tapable are voluntarily taking part in a very strange experiment.
The way I see it, since there will very clearly be other vendors who do not insert taping abilities into their equipment, the ones that do are going to find out just how important an issue this is to the people who buy their equipment.
Most IT people I know have a thing about civil liberties, and I suspect that those companies that put backdoors into their products are going to get hurt in the marketplace because of their decisions (as long are there are alternatives to their products). It will be very interesting to see if the people who buy the network equipment will be willing to put up with a back door, or if they will simply find ways around it (the most obvious of which is to simply not buy the goods with the back doors built in).
Let the experiment begin...
Re:ISO 9000 (offtopic) Was Re:...a bunch of garbag
on
One for the Kids
·
· Score: 1
I agree in principle. It's just that in practice most organizations (at least from what I have seen or experienced) that implement ISO 9000 do so in such a way as to quite cumbersomely regiment everything that must be done, and completely stifle all creativity and/or productivity.
Most companies that value ISO 9000 tend to have a similar mindset (or so it would appear), and so rather than hire people (or train people) who know how to build good software, they rely on standards and procedures to turn out good software. Even the very best standards and procedures will fail to turn out good software if good people aren't coding and testing, but this is often overlooked. I would far rather have better people with fewer S&P than a mountain of S&P in order to insure good code (when often the mountain of S&P is counter-productive to the code-building process).
Don't look to documents to build good code. Look to good people to build good code.
There is one thing you've overlooked though. Almost all software today is a LOT more complex than just about anything else I can think of. Software is far easier to work with than physical objects, and far easier to reuse. This leads to our ability to create (relatively fast) very complex very usefull programs. Think about it, even the space shuttle is less complicated (mechanically and electrically anyway) a piece of work than the software contained on just about any fully loaded personal computer in use today, and the space shuttle is generally considered to be one of the most complex engineering undertakings of the century.
If auto makers were making things as complex as software, it would probably take them several decades to move from design to fabrication, and then each vehicle would cost something like the budget of NASA for a year (something like $11B). If we were to hold software companies to the same standards for initially shipped software as auto companies, then each major software product would take a decade or more, and would cost far more than any consumer would ever be able to pay (just to recoup the developers costs).
If instead we are willing to settle for software that works 99%+ of the time when it first ships, and then have the company fix all bugs that are found promptly and release free updates (containing bug fixes), then we are willing to settle for something that can actually happen.
Most software can be tested more than it is before it is shipped, and it isn't unreasonable to expect a product to be 99% bug free, so long as any bugs that are found will be fixed and released for free. To expect the software industry to function just as the auto industry does though (i.e. 99.9999999% bug free on the first run) is unreasonable, and would mean the virtual dismantling of the software industry (not just negligent companies like M$, but even responsible ones that just can't meet the standards of the auto or nuclear industries).
I agree with everything you said with just one caveat: what constitutes a "reasonable effort"?
I've been involved with a lot of software, and I know that the amount of QA that software goes through can vary greatly, but there are certain kinds of bugs that only the most maniacal QA will find, and these bugs would slip through anything that I could possibly consider a "reasonable effort".
I personally think that "reasonable effort" would consist of a group of QA people working on a product from the time the first architecture is drawn up until the product is retired. This team should be 0.5 to 1.0 times the size of the development team, and put in the same hours as the dev team. Any bugs they find should be fixed ASAP and included in the next update of the software (if the bug is found after the software has shipped), and bug based updates should be free.
Now, that is what I think is reasonable, but I know (and have met some of them) people are out there who think that reasonable effort consists of full ISO 9000-9001 compliance and full adherence to every hare-brained software engineering scheme known to man. Some of the software engineering approaches that I have read call for 60+ pages of documentation for every 1000 lines of code. This is okay for a company like IBM (who, at least in the past) have done that much documentation per code, but a lot of small (i.e. startup) companies couldn't even dream of this kind of load. On top of that, from my experience, a lot of the software engineering approaches that I have seen (and some that I have used) add no overall value, but rather cost a lot of time and effort, and result in poorer overall code.
Legally forcing developers to use a lot of the software engineering practices out there is the wrong answer (it would be highly counter productive), yet I fear that a legally codified "reasonable effort" clause would do just that. I think having a good (intelligent/knowledgeable) team of coders and QA people who know what they are doing will always turn out a better product than a team of mediocre coders weighed down with 10 hours of engineering practices to follow for every hour of actual coding.
If I felt assured that a reasonable effort clause wouldn't force people into using some of the horrific software engineering practices out there, then I would completely agree, but until reasonable effort is precisely spelled out I will remain highly skeptical.
You forget trafic analysis. There is an awful lot of information that can be gained by analyzing trafic that passes around between computers.
Things like: who sent it where is it going when was it sent when was it received how fast was the response delivered what patterns arise over the long term (i.e. how often is data exhanged, is it periodic...) how do the involved parties act before and after these exchanges etc. etc. etc.
There is also a lot that is not encrypted, such as email headers and so forth that could be read and analyzed for any possibly useful info.
You are also asuming that techniques such as quantum computing which could be used to crack conventional codes are indefinately far away in the future. However if you combine something like IPv6 (with the built in MAC codes) and the (likely) eventuality of quantum computing then you have neither encryption nor anonymity.
Quantum crypto is often held up as the answer to quantum comptuers, however the way in which quantum crypto works pretty much rules out the internet (unless all you want to do is real time communications over satelites only (assuming that free-air quantum crypto becomes a reality and is available to anyone), and that isn't really an internet situation). That means that there will be no such thing as effective crypto for things such as email and so forth. (NOTE: Before I get flamed to death, I should note that there are systems that you could create that would leverage quantum crypto together with the internet, but they would require a seperate, non internet connection between parties (in most cases) to establish secure transfer of OTPs and so forth).
You should plan for the maximum possible privacy and try for both unbreakable encryption and anonymity. Better yet, communicate without making it obvious that you are doing so. Use a combination of encrypted data and proprietary steganography. It is hard to eavesdrop if you don't know that people are having a coversation.
One of the things about the open exchange of ideas (be they source code or less structured dialog such as conversation) is that it is free to all.
I think it is best that everyone have access to these ideas, rather than a select few, or even just those who will use it for good ends. It seems that the widest possible spread of ideas is the best policy. There are bad side effects of such policies (i.e. those who use these ideas to oppress others), but I think the good effects (i.e. everyone who is interested knowing as much as possible) far outweigh the bad.
Suggesting that they should be kept in the dark also suggests that if they aren't told, they won't figure it out. I imagine that if they (I'm talking about the sort of people who have the resources to actually suppress people AND use computers as a part of that) are really interested in knowing these things, they probably already know it (how did you learn these things. Now ask yourself if you really believe that the aforementioned (really determined) people would be unable to learn (or have people learn for them) in the same ways that you did).
One parting thought: Regardless of how much information about computer security third world dictators (or anyone for that matter) possess, there will always be ways to hack into their systems. There may come a time when social engineering is easier (or when significantly different hacks become easier), but there will ALWAYS be a way around any barrier that is put up. I very much doubt that there really is such a thing as an impervious computer system (just ones that are hellishly tough to crack).
True, but the card is out there for some privileged few to develop with (so far as I have heard anyway) (and it is definately out in limited release to some advance companies now), and presumably Nvidia has done some work along these lines. (I've heard bits and pieces about a Linux openGL driver). If the card does indeed ship by the end of Sept as buzz would have it, it would be great to be able to play w/ and code w/ it's keen new features from within Linux (rather than just Win9x/NT).
I've been working with signatures and PKI at my company for more than two years now, and I've seen a lot of the things that kill it. There are three main reasons that the average joe doesn't want to have anything to do with it:
(1) The average user doesn't know what signatures or certificates are, or what they do (i.e. they're too obscure), so why do they care?
(2) Too complex and too much of a hassle (why pay Verisign or someone else for something that you'll probably never be able to use anyway). Most security UIs are overly complex, and no average user will want to deal with it. It is also difficult to manage certs. What if Alice wants to send an encrypted email to Bob, but she doesn't have Bob's cert? Without a lot of common LDAP servers and other such things getting people's certs will be a hassle, and so nobody but us geeks will bother.
(3) For those people who care enough to figure out the complexity, and deal with the hassles, there is still an issue of trust. How do I know that IE5's implementation of S/MIME is secure? They could be storing things on my system insecurely, or perhaps Netscape (even though it is open source, the security areas of the code are not) has a bad security implementation. Granted that I trust that once things hit the network, that they are secure because I trust the S/MIME and the involved algorithms, but on my own system I'm not so sure. If I was to be really paranoid about security, I would still use PGP (or my own custon S/MIME implementation) so that I knew that what was going on was secure. For the average user who can't (or won't) use PGP or their own software, trust is a major issue, and perhaps a roadblock.
So all of that being said, what can be done to fix it? There are three things (again, three, hmmmm...) that I think could move things a very long way.
(1) This is the biggest. Since good certificate systems usually tie a certificate to an email address, and you get your email address from your ISP, I think that if when you got your ISP account a certificate/keypair were created automatically (without much in the way of user interference), then things would be much easier. Like with all certificate authorities today, the keypair and cert request would be generated on your machine, and then sent to your ISP. They in turn would create your certificate, and send it back. Just as secure as todays systems, but the advantage is that it would happen automatically when you first set up the ISP connection (maybe custom software from the ISP?). Imagine if ISPs acted as certificate authorities (or proxies for CAs) (listen up AOL). If that happened, most people with home internet accounts would have certificates. This is the most crucial thing: making sure that everybody has a certificate/keypair, and that there is no hassle for the user in getting this. If this service were part of the cost of the ISP connection, it would be no big deal. (Verisign charges something like $10 for their basic level 1 cert, and that works out to less then a dollar/month, so it wouldn't be too expensive for ISPs I wouldn't think, especially if they only acted as secondary CAs and didn't have to handle the physical security of a root cert)
(2)Biometric security devices standard as part of new computers. This isn't totally necessary, but it has the potential to make things a lot more secure in general. If I remember right, Compaq started shipping a thumbprint scanner with one of their lines sometime last year. If this became common (or if smartcards to store keypairs became common), security would mean a lot more.
(3) If a big name like the USPS, or Verisign got involved with being a central repository of certificates (using LDAP or whatever) and application developers made lookups to this database invisible to the user, it wouldn't matter if you already had a cert or not. Your application could simply fetch it from the repository if you didn't already have it. On a similar note, if a body was formed to certify products as secure, that would also help. If I knew that some trusted thrid party had verified the security of Netscape's, or Microsoft's, mail programs, I would feel a lot better about using them. I suspect other users would feel the same.
In the end, the answer is: security will be used when all the average John (or Jane) Doe has to do is click the Signing or Encryption button on their outgoing mail, and the rest is taken care of for them. If security is supremely easy to use, then everybody will use it (there will be no reason not to).
Slashdot Mirror
It all completely depends on your level of skill. I work for a company that is growing very fast, and my group within the company is growing even faster. We're looking as hard as we can for good qualified programmers/engineers, and we have a very difficult time finding good people. For every 40 or so people we interview, we hire one. The issue is that a lot of undergrads are under-prepared, and we we require people who are top-notch at problem solving, top-notch at engineering, good at C/C++, good at system level concepts, very good w/ graphics HW, and good w/ graphics algorithms. It's very hard to find the skillset we need, and so we pay top dollar for it when we find it. If you have the skills to work at a company like mine, you'll do very, very well. You also have to be willing to work very hard (at least at times). If however you only know how to code HTML and perl (and aren't willing to learn anything else), or if you think that programming knowledge stops w/ what languages you know, or if you don't develop deep expertise in at least one area of computer science (like graphics, databases, language theory/compilers, security, networking, etc.), if you aren't willing to constantly keep learning the latest and greatest new technologies/tools/techniques, then yeah.... you might be in for a rough ride.
My company will hire good programmers wherever they are. At least in my group, we'd prefer to hire US programmers. It's easier if everyone works within a few timezones of each other. It's easier if everyone speaks the same language well. It's easier for engineers to meet w/ customers. There's just less friction overall. However, if we can't find the right people in the US, we will hire from Europe, from India, from China, from wherever. For our team, it has nothing to do with cost, and everything to do with finding the right people.
It's like any industry, if you work hard and make yourself valuable, you will always be employable (and will be able to make VERY good money), but it's just not like it was the late 90s: you actually need to have some skill (and motivation) to survive these days. I have no worry about losing my job to someone from another country, because I am very good at what I do, and it would be very hard to find someone who is willing to work as hard as I am, and who has the level of skill that I do.
I'm a PhD student working in computer graphics, and I have to say... where's my pork? NSF funding has almost completely dried up, military and homeland security spending has all gone to corporate pockets (or savy small business pockets), and corporate funding is very, very scarce. I've been lucky enough (and had enough hustle) to just barely bring in my own funding for the last year and a half or so, but everyone I know is pretty well starving for any sort of research funding. Highly successfull professors and researchers from all over are not getting the funding they need for some very good tech research proposals.
I don't know who's supposedly getting all this tech pork, but I can pretty well assure you that it isn't universities.
It really, really depends. A good employer will try to people with a strong capacity to learn, and good problem solving skills. Once hired the employees generally just pick things up as they go. It's kind of expected at top tech companies that you'll stay on top of your field, and learn everything you can. IF however your job requirements change drastically, a good employer usually sees it as in their best interest you train you (or give you the time to train yourself).
What you have is really a company with bad management. First of all, giving a rats ass about any sort of certificate (i.e. MCSE, or whatever else) is usually a bad sign (means they are more concerned with beaurocracy than with reality). Then the fact that they trained the wrong person is a bad sign. The fact that their communications with you is so terrible is a really, really bad sign. Many other companies would handle this far better than yours has.
That being said, it looks like it is indeed your own problem to train yourself. My best advice would be to train yourself as well as you can (forgoing personal life for a while), and then jump ship for a company with better management. Look for a company where management cares more about how well people can problem solve than what certificates they have (sometimes hard interview questions and logic puzzles are a good guage of how seriously they take problem solving). If they place a strong emphasis on teamwork, and trying to retain good people, that's another good sign.
I've worked in several different environments (and companies) over the years, and I've worked with a lot of programmers. I've known college dropouts who were stellar programmers and could really deliver solid products on time. I've also known PhDs who couldn't be trusted to write (let alone maintain) good code at all. The one constant I've seen in good management is that they can recognise those programmers (and IT) people who are good, and those who are not. They try hard to support (and retain) those who are good, and nurture those who are not (and cut them loose if they refuse to be helped). Look for a manager like that if you can.
I'm currently a PhD student in a top college in the US. I can attest that the article is basically correct regardling underdgraduate eduation.
Most top colleges are research schools. Research schools (as the name would imply) have one primary motivation: research. The professors they hire tend to reflect this. Most of these professors are very, very good at research and are often not so good at teaching. But this doesn't really matter. In the day to day business of these schools, teaching undergrads is a burden, not a serious responsibility. Many of them do what they can to try to get rid of non-optimal undergrads. Not because the undergrads show no promise, but because it simply takes too much time and effort to help them. To be fair, there are a good number of a very dedicated teaching professors and lecturers, but these people are not well supported by the administration (and are in the minority).
There is a LOT more that could be done to further teaching of engineering in the US. Sadly, if you want an engineering degree, the best places to get them are often the second tier universities. Live in California? Want an engineering degree? Many people think the best place in CA to get a degree is the UC system (and this IS true of grad school), but the truth is, the CSU system (Cal State University) is often a better place for undergraduate learning than the UC system. Placing undergraduates above research would be a HUGE step up for much of the US college system, but undergraduates have not (until recently) paid as well as research. In the CSU system, you are often more likely to find professors who are dedicated to teaching, rather than research. In the UC system, research is the #1 goal, and anything else (including teaching undergrads often) is a bit of a distraction.
To blame TAs completely would be unfair, and to blame professors completely would be unfair. In my experience, most of the blame lies squarely with the top administration, and their funding priorities. They tend to want to hire professors who ONLY want to do research, and view teaching as an ugly chore. Many of my undergrad classes had 200+ students (some as many as 800+). Physics was all about weeding out the weak (first semester core physics contained 350+ people, 5th semester contained 25 people). The whole atmostphere was one of destroying all but the ubermensch. Those unprepared (or not perfectly motivated) were left to fail.
Luckily for me I do well in such circumstances, but if the US wants to do well over the long haul, it would be best not to get rid of everyone who isn't just like me. Most of my colleagues in grad school are either Chinese, Indian or German. I wish all of them the very best (they are all incredibly bright and motivated), but I wish that more of my own countrymen were here as well. I know that many of them are quite smart, but I also know that many of them are defeated by poor professors, and poor support. Not to mention (of course) very good pay outside of the engineering/science world.
Actually, I know a lot of graduate students who will be really happy about this. It turns out that for a lot of research uses, 512 MB of ram would be really useful. Examples include 3D volume data-set visualization and general purpose GPU computations (GPGPU).
I don't know where ATI expects to make the money on this (certainly not that much $$$ in the research market), but I'm personally glad that they released this card.
The big question in my mind now is how good the cache performance is on this new card.
There's of course a lot more to it than just that, but that is the basic problem. I've seen all sorts of programs that people would find interesting to run at home, but not vital to run at home. It currently isn't worth the cost for most people (anywhere from $5k for bargain basement stereo vision with poor tracking, to $1 million+ for a cave + haptic/robotic interfaces). People won't use VR until it is (a) unobtrusive, (b) cheap, and (c) intuitive.
On the 3D display end, VR needs to move from large space filling displays like caves to small setups like a small pair of glasses (current top end devices from manufacturers such as MicroOptical and Microvision give a glimpse at possible avenues forward). Ideally, these glasses should still let you see the real world (referred to as augmented reality, rather than virtual reality). This is far less disorienting for many people. There are also technical problems with HMDs (head mounted displays) aside from size and weight. The best HMD resolutions today are generally about 1280x1024, and the field of view often isn't stellar. For many people, these displays can cause headaches. The closer a display is to the eyes, the higher res it needs to be in order to avoid ill physiological effects. Then, the VR applications themselves need to run fast enough to have very little lag (ideally less than 12 ms between a user's action, and the application visually responding). If the lag gets too large, many people begin to get motion sickness (this is potentially a huge barrier for many people w/ VR). One alternative to VR glasses is projected displays, but without some additional engineering & mass production, these displays are not likely to be very cheap in the near future (and these displays still require some type of glasses, either shuttered glasses, or polarized glasses). The final visual alternative (ignoring fancy and expensive volumetric displays) are auto-stereoscopic displays, which work w/o special glasses. These displays have the downside though of requiring the user to sit/stand in a precise location in order to get the 3D effect.
Motion tracking also needs to get significantly better. Current motion tracking techniques (for gesture recognition, head tracking, etc.) are generally quite bulky and expensive. Some image processing techniques using video cameras show promise for cheap compact systems. Large scale motion tracking and registration (i.e. matching your position and orientation precisely with a map and models) is a much bigger problem for outdoor situations. GPS is one of the better ways right now, and that is abysmal (GPS gives positional accuracy to within a few meters, and no clues about orientation. VR apps require position to within a few centimeters usually, and orientation to within a degree or two). There is a fair amount of research into improving this, but it will likely be several years before any non-miliary applications emerge.
Finally, once VR is cheap enough (less than $2K USD for 3D vision and tracking), and small enough (i.e. a small/light pair of glasses, and at most a few stationary webcam sized cameras, or a single 3D projector), then average people can start to think about using VR. Even then, people won't use it until there are compelling applications. The first big applications will of course be games, but outside of 3D modeling, medical data, scientific data, psychology and geology there have been few compelling uses shown. Clearly there are a lot of compelling applications just waiting to be developed, but until VR becomes cheaper, smaller and more intuitive, these will most likely not be developed.
Don't take a major just because it'll make more money. Choose the one you'll enjoy more. Nothing leads to burnout faster than a job you don't like.
From my observations of people I know, as long as you are competent at what you do (and you would be surprised how many CS people aren't) you will not have trouble finding a job with either a hardware or a software based CS degree.
This solution is exactly the opposite of what I want. I don't really want to lug a computer around with me. I really want to take my data with me, and just use whatever computer is handy nearby. I use a laptop because that is the smallest computer that fits my needs that I'm willing to carry everywhere. However, I would happily have a system where I could use the data on my laptop on any other machine I use as well, just by connecting my laptop (or my laptop's drive) (something more elegant than making my powerbook a dumb firewire drive at least).
However always having the same RAM/CPU/GPU in every machine I use, and just changing the shell? Why? What's the point? Where is the advantage? The whole point of a desktop is the embarrassingly large number crunching power. If I never needed to run big FEM simulations or large VR environments, I would never even bother with a desktop.
I'm not sure which distro makes the most sense (although, for a school setting, I'm fond of Fedora Core 3), but I definitely think that they should look into a system to manage a large group of machines from a central point.
I've been using stateless linux from RH on our local cluster, but for a more polished solution, I would recommend onesis (what Sandia National Lab uses for their cluster management) http://onesis.org/index.php
A solution like this can make upgrades/changes to the computers in the network much less painful than what a lot of sysadmins use.
More often then not when I need a piece of software that has an evaluation version, that software is for a fairly small price (<$1000), and for a fairly urgent need (i.e. debugging some piece of code, defragmenting a hard drive). Sometimes it is for a less pressing need (a new source code control system), but always, when I download an eval version, it is because I am in the process of research.
Now, often times I'll come across something that seems ideal, only to find later that I've found an even better tool. In your company's case, I think it entirely possible that somebody has signed up for the eval to see if it might fit their needs, but while they are waiting for the username/password to arrive, they find something that fits their needs even better. Or perhaps a few hours is too long for them to wait?
Anyway, I rather suspect that between the time they order the eval, and the time they get the username/password, they've found some other solution to their problem.
Yeah. That's a good sentiment if you have a compiler with some decent diagnostics (i.e. "'}' expected on line 554" or something like that), but most of these errors are very tough to catch in a non-compiled language (or rather an interpreted one) where some random user agent (read: browser) can handle bad code in any number of unexpected ways.
If HTML was compiled and then released, I would agree, but the reality is that it's not. Any tool that helps allow for this and still comply with the intent of the author is a helpful tool.
Don't get all snobbish just because you can program and others can't.
Let me start by saying that I've implemented S/MIME for several different products on windows platforms, and have a reasonable amount of experience with what I am talking about (at least where it relates to the windows world).
Why don't people develop an email client that supports S/MIME or PGP/MIME for Linux? The crypto toolkits. It's that simple. The tools are really complex, involve math that most people aren't familiar with, and invlove security, so if you don't do it just right, it might be insecure.
Don't even think about using a third party toolkit for a linux app (unless you want to make the app non-open source). You would go bankrupt 100x over if you tried that. They are absurdly expensive for the most part (both the PGP kits from Network Associates, and the RSA kits and so on). I'm not over familiar with what might be available already open source, but I would be extremely surprised to find an open source toolkit that handled all of the neccessary algorithms and encodings.
Not long ago, you couldn't use the RSA alg without paying royalties to RSA (of course you can now). That severely limited what you could do with open source RSA based algs. You also had the problem of export controls and ITAR etc. Just ask Phil Z. why this is a pain in the ass. So until just recently it would have been almost absurd to support S/MIME on open source. (Being as you would have had to pay RSA royalties on each copy of your free toolkit, and then get commerce department approval to export your toolkit (i.e. put it on the internet for general consumption) if you are in the US).
Even today, if you want to develop an S/MIME client for linux, you will still need to write a good toolkit that handles all of the cryptography algorithms as well as the encoding/decoding of ASN.1 data (and other data formats if you are using PGP/MIME). Your toolkit must be open source (well at least it seems like it SHOULD be anyway), it must be secure (i.e. good PRN generators, zero out used memory, take advantage of cryptographic hardware if it is there, etc.), and it is going to take a heck of a long time to write.
Now, when you are all done with the toolkit, then you can integrate it into an email client, with all of the UI that that may or may not require. All for a feature that almost nobody will use, and for functionality that you could have gotten (for the most part) using PGP and a little extra work.
I think security is "a good thing", but today very, very few people use it, and most people simply don't care about security. Partially becuase it is so complex to do and to use properly, partially because most people just don't see the need for it in their day to day lives. Even in the simplest implementations, security makes exchanging email more complex because both parties must first create keypairs (and certs if using many protocols), and then somehow exchange them.
Don't get me wrong, I think that email clients with built in security (such as S/MIME or PGP/MIME) can be a very nice thing, but I'd say that at this point they probably aren't worth the effort on Linux.
NOTE: Why was it (relatively) easy in windows? The cryptography API that is part of windows. It has (more than) its share of flaws, but you can work around all of them that get in the way, it's free, and it's guaranteed to be on every windows box out there (excepting Win 3.x). Say what you want about M$ (I am not a big fan), but the gazillion APIs in the OS do make it easy for developers to add new features to existing apps in a relatively small amount of time (assuming that the API works and/or is documented). (I know, I know. The same can be said of open source, assuming that what you want is out there already). If my work had been targeting UNIX platforms instead, we would have had to have licensed a toolkit from RSA probably, and that would have cost us at least a quarter million, whereas the M$ stuff was free.
Eric Klein
What is really interesting is that at VP at Sony has essentially just pledged that the company will be seeking vigilante justice. He didn't mention anything about waiting for the court's decision, he simply states that they are going to take matters into their own hands, and bring the 'rogue' company to justice as Sony sees it.
Vigilante justace was both illegal and looked down upon in the old west. The same is true today. If Sony really does take to this course of action, it will most likely come back to haunt them, either legally, or through public relations.
Most people on this thread are talking about this being an issue of corporate vs. individual rights. While this may be true on a broad sense, I think that the most important point is that Sony has decided that the law doesn't work for it, and that in order to best protect themselves they need to work outside (or at least on the boundary) or the law. I'm sure that Sony won't explicitly violate any laws in getting their firewalls up. I'm pretty sure that it will be through strongarm tactics against large providers like AOL, @home, SBC, Verizon and others. Perhaps they will also call in some political favors, and get some laws passed to allow them to do what they want. The end result though is that Sony has decided that living in a democratic society does not suit it, and so it will attempt to force society to it's will.
Only time will tell what this will do to society, but I believe that if Sony does attempt this, this is going to be one of those little tests that our country has from time to time to see how much it really wants to maintain a democratic society. If we rise to the occasion and show Sony that it must play nicely and by our rule system, then I believe that it will be a big step for America. If we allow them to trample about, then we have taken one more step towards relinquishing the rights of a democratic society.
I suspect that we will see a lot more of the Wankel engine in the future...
And thus we also need more anonymous remailer type proxies. You could encrypt your information, and then encrypt it again, this time including final destination info and intended for the re-router, and then send it to an anonymous re-router. The re-router would decrypt the stuff you encrypted for it, and then use the destination info to send along your encrypted data to wherever it was destined.
This way IP analyses becomes much more difficult. This is especially true if the re-router has a lot of traffic, and intoduces random delays before sending packets back out into the world.
It seems to me that the vendors who decided to continue with plans to make their equipment tapable are voluntarily taking part in a very strange experiment.
The way I see it, since there will very clearly be other vendors who do not insert taping abilities into their equipment, the ones that do are going to find out just how important an issue this is to the people who buy their equipment.
Most IT people I know have a thing about civil liberties, and I suspect that those companies that put backdoors into their products are going to get hurt in the marketplace because of their decisions (as long are there are alternatives to their products). It will be very interesting to see if the people who buy the network equipment will be willing to put up with a back door, or if they will simply find ways around it (the most obvious of which is to simply not buy the goods with the back doors built in).
Let the experiment begin...
I agree in principle. It's just that in practice most organizations (at least from what I have seen or experienced) that implement ISO 9000 do so in such a way as to quite cumbersomely regiment everything that must be done, and completely stifle all creativity and/or productivity.
Most companies that value ISO 9000 tend to have a similar mindset (or so it would appear), and so rather than hire people (or train people) who know how to build good software, they rely on standards and procedures to turn out good software. Even the very best standards and procedures will fail to turn out good software if good people aren't coding and testing, but this is often overlooked. I would far rather have better people with fewer S&P than a mountain of S&P in order to insure good code (when often the mountain of S&P is counter-productive to the code-building process).
Don't look to documents to build good code. Look to good people to build good code.
I wonder if XiG is worried that XFree 4.0 will come out and give them a real run for their money, for no money.
:)
Of course they are, if you were XiG wouldn't you be?
On that note, I can't wait for XFree 4.0 (not that XFree is bad now, just the new features in 4.0 will be welcome enhancements)
There is one thing you've overlooked though. Almost all software today is a LOT more complex than just about anything else I can think of. Software is far easier to work with than physical objects, and far easier to reuse. This leads to our ability to create (relatively fast) very complex very usefull programs. Think about it, even the space shuttle is less complicated (mechanically and electrically anyway) a piece of work than the software contained on just about any fully loaded personal computer in use today, and the space shuttle is generally considered to be one of the most complex engineering undertakings of the century.
If auto makers were making things as complex as software, it would probably take them several decades to move from design to fabrication, and then each vehicle would cost something like the budget of NASA for a year (something like $11B). If we were to hold software companies to the same standards for initially shipped software as auto companies, then each major software product would take a decade or more, and would cost far more than any consumer would ever be able to pay (just to recoup the developers costs).
If instead we are willing to settle for software that works 99%+ of the time when it first ships, and then have the company fix all bugs that are found promptly and release free updates (containing bug fixes), then we are willing to settle for something that can actually happen.
Most software can be tested more than it is before it is shipped, and it isn't unreasonable to expect a product to be 99% bug free, so long as any bugs that are found will be fixed and released for free. To expect the software industry to function just as the auto industry does though (i.e. 99.9999999% bug free on the first run) is unreasonable, and would mean the virtual dismantling of the software industry (not just negligent companies like M$, but even responsible ones that just can't meet the standards of the auto or nuclear industries).
I agree with everything you said with just one caveat: what constitutes a "reasonable effort"?
I've been involved with a lot of software, and I know that the amount of QA that software goes through can vary greatly, but there are certain kinds of bugs that only the most maniacal QA will find, and these bugs would slip through anything that I could possibly consider a "reasonable effort".
I personally think that "reasonable effort" would consist of a group of QA people working on a product from the time the first architecture is drawn up until the product is retired. This team should be 0.5 to 1.0 times the size of the development team, and put in the same hours as the dev team. Any bugs they find should be fixed ASAP and included in the next update of the software (if the bug is found after the software has shipped), and bug based updates should be free.
Now, that is what I think is reasonable, but I know (and have met some of them) people are out there who think that reasonable effort consists of full ISO 9000-9001 compliance and full adherence to every hare-brained software engineering scheme known to man. Some of the software engineering approaches that I have read call for 60+ pages of documentation for every 1000 lines of code. This is okay for a company like IBM (who, at least in the past) have done that much documentation per code, but a lot of small (i.e. startup) companies couldn't even dream of this kind of load. On top of that, from my experience, a lot of the software engineering approaches that I have seen (and some that I have used) add no overall value, but rather cost a lot of time and effort, and result in poorer overall code.
Legally forcing developers to use a lot of the software engineering practices out there is the wrong answer (it would be highly counter productive), yet I fear that a legally codified "reasonable effort" clause would do just that. I think having a good (intelligent/knowledgeable) team of coders and QA people who know what they are doing will always turn out a better product than a team of mediocre coders weighed down with 10 hours of engineering practices to follow for every hour of actual coding.
If I felt assured that a reasonable effort clause wouldn't force people into using some of the horrific software engineering practices out there, then I would completely agree, but until reasonable effort is precisely spelled out I will remain highly skeptical.
You forget trafic analysis. There is an awful lot of information that can be gained by analyzing trafic that passes around between computers.
Things like:
who sent it
where is it going
when was it sent
when was it received
how fast was the response delivered
what patterns arise over the long term (i.e. how often is data exhanged, is it periodic...)
how do the involved parties act before and after these exchanges
etc. etc. etc.
There is also a lot that is not encrypted, such as email headers and so forth that could be read and analyzed for any possibly useful info.
You are also asuming that techniques such as quantum computing which could be used to crack conventional codes are indefinately far away in the future. However if you combine something like IPv6 (with the built in MAC codes) and the (likely) eventuality of quantum computing then you have neither encryption nor anonymity.
Quantum crypto is often held up as the answer to quantum comptuers, however the way in which quantum crypto works pretty much rules out the internet (unless all you want to do is real time communications over satelites only (assuming that free-air quantum crypto becomes a reality and is available to anyone), and that isn't really an internet situation). That means that there will be no such thing as effective crypto for things such as email and so forth. (NOTE: Before I get flamed to death, I should note that there are systems that you could create that would leverage quantum crypto together with the internet, but they would require a seperate, non internet connection between parties (in most cases) to establish secure transfer of OTPs and so forth).
You should plan for the maximum possible privacy and try for both unbreakable encryption and anonymity. Better yet, communicate without making it obvious that you are doing so. Use a combination of encrypted data and proprietary steganography. It is hard to eavesdrop if you don't know that people are having a coversation.
One of the things about the open exchange of ideas (be they source code or less structured dialog such as conversation) is that it is free to all.
I think it is best that everyone have access to these ideas, rather than a select few, or even just those who will use it for good ends. It seems that the widest possible spread of ideas is the best policy. There are bad side effects of such policies (i.e. those who use these ideas to oppress others), but I think the good effects (i.e. everyone who is interested knowing as much as possible) far outweigh the bad.
Suggesting that they should be kept in the dark also suggests that if they aren't told, they won't figure it out. I imagine that if they (I'm talking about the sort of people who have the resources to actually suppress people AND use computers as a part of that) are really interested in knowing these things, they probably already know it (how did you learn these things. Now ask yourself if you really believe that the aforementioned (really determined) people would be unable to learn (or have people learn for them) in the same ways that you did).
One parting thought: Regardless of how much information about computer security third world dictators (or anyone for that matter) possess, there will always be ways to hack into their systems. There may come a time when social engineering is easier (or when significantly different hacks become easier), but there will ALWAYS be a way around any barrier that is put up. I very much doubt that there really is such a thing as an impervious computer system (just ones that are hellishly tough to crack).
True, but the card is out there for some privileged few to develop with (so far as I have heard anyway) (and it is definately out in limited release to some advance companies now), and presumably Nvidia has done some work along these lines. (I've heard bits and pieces about a Linux openGL driver). If the card does indeed ship by the end of Sept as buzz would have it, it would be great to be able to play w/ and code w/ it's keen new features from within Linux (rather than just Win9x/NT).
What are the prospects for NV10 drivers? Anybody hear buzz on that? (For 4.0 that is)
I've been working with signatures and PKI at my company for more than two years now, and I've seen a lot of the things that kill it. There are three main reasons that the average joe doesn't want to have anything to do with it:
(1) The average user doesn't know what signatures or certificates are, or what they do (i.e. they're too obscure), so why do they care?
(2) Too complex and too much of a hassle (why pay Verisign or someone else for something that you'll probably never be able to use anyway). Most security UIs are overly complex, and no average user will want to deal with it. It is also difficult to manage certs. What if Alice wants to send an encrypted email to Bob, but she doesn't have Bob's cert? Without a lot of common LDAP servers and other such things getting people's certs will be a hassle, and so nobody but us geeks will bother.
(3) For those people who care enough to figure out the complexity, and deal with the hassles, there is still an issue of trust. How do I know that IE5's implementation of S/MIME is secure? They could be storing things on my system insecurely, or perhaps Netscape (even though it is open source, the security areas of the code are not) has a bad security implementation. Granted that I trust that once things hit the network, that they are secure because I trust the S/MIME and the involved algorithms, but on my own system I'm not so sure. If I was to be really paranoid about security, I would still use PGP (or my own custon S/MIME implementation) so that I knew that what was going on was secure. For the average user who can't (or won't) use PGP or their own software, trust is a major issue, and perhaps a roadblock.
So all of that being said, what can be done to fix it? There are three things (again, three, hmmmm...) that I think could move things a very long way.
(1) This is the biggest. Since good certificate systems usually tie a certificate to an email address, and you get your email address from your ISP, I think that if when you got your ISP account a certificate/keypair were created automatically (without much in the way of user interference), then things would be much easier. Like with all certificate authorities today, the keypair and cert request would be generated on your machine, and then sent to your ISP. They in turn would create your certificate, and send it back. Just as secure as todays systems, but the advantage is that it would happen automatically when you first set up the ISP connection (maybe custom software from the ISP?). Imagine if ISPs acted as certificate authorities (or proxies for CAs) (listen up AOL). If that happened, most people with home internet accounts would have certificates. This is the most crucial thing: making sure that everybody has a certificate/keypair, and that there is no hassle for the user in getting this. If this service were part of the cost of the ISP connection, it would be no big deal. (Verisign charges something like $10 for their basic level 1 cert, and that works out to less then a dollar/month, so it wouldn't be too expensive for ISPs I wouldn't think, especially if they only acted as secondary CAs and didn't have to handle the physical security of a root cert)
(2)Biometric security devices standard as part of new computers. This isn't totally necessary, but it has the potential to make things a lot more secure in general. If I remember right, Compaq started shipping a thumbprint scanner with one of their lines sometime last year. If this became common (or if smartcards to store keypairs became common), security would mean a lot more.
(3) If a big name like the USPS, or Verisign got involved with being a central repository of certificates (using LDAP or whatever) and application developers made lookups to this database invisible to the user, it wouldn't matter if you already had a cert or not. Your application could simply fetch it from the repository if you didn't already have it. On a similar note, if a body was formed to certify products as secure, that would also help. If I knew that some trusted thrid party had verified the security of Netscape's, or Microsoft's, mail programs, I would feel a lot better about using them. I suspect other users would feel the same.
In the end, the answer is: security will be used when all the average John (or Jane) Doe has to do is click the Signing or Encryption button on their outgoing mail, and the rest is taken care of for them. If security is supremely easy to use, then everybody will use it (there will be no reason not to).