So, you saved $80K and wasted a million. Way to go !
Yes, way to go!
You forget, that in corporate America, NOBODY polices the organization as a whole. If your department manages to save $80,000 by creating a liability for the [future | some other department | the public at large], management is pleased. That half-million dollar power usage problem is owned by the building management, not the IT department. So, kudos to the IT department for saving eighty grand!
Well, perhaps the article glossed over a few things.
Galileo was called to Rome because he attempted to interpret the Bible. Which is kind of odd for a scientist, isn't it? Or perhaps Galileo, like a large portion of the world, saw no fundamental conflict between theology and science. After all, both seek the truth, but I'm digressing here...
Anyway, in Galileo's time, someone else attempted to interpret the Bible, and it eventually led to a new religion. You might be familiar with the name Martin Luther. It doesn't surprise me the least that Galileo got called to Rome, because he did have political enemies. And this was just what they were looking for - something that could be misrepresented as threatening the authority of the Vatican. In that time, claiming to have some special knowledge of God was not merely a religious statement; it was political as well.
And what does the Vatican do? They aren't quite sure if he's a problem or not, but to avoid the possibility him emulating Luther, they confine him to house arrest - which would be a serious obstacle to a political revolutionary, but not impose much on a scientist.
the amount of damage (direct and indirect) that has been perpetrated on humanity in the name of vague ethereal omnipotent beings is so stunning that very few people even realize it
Link, please.
This particular myth gets bandied about quite a bit by those who would rather bash religion than actually analyze history. I know it's so godwin, but it is relevant:
Nazi Germany: secular nation; killed 6 million Jews, and 6 million others - poles (Catholic, mostly), homosexuals, political dissidents (Niemoller comes to mind, a Christian).
Stalin's Russia: killed about 50 million in the Gulag.
Pol Pot: 1.6 million.
Time and again we hear this old myth about religion causing people to kill each other, but the most violent regimes in history were always anti-God.
As far as mobile phones go, you're out of luck unless you happen to have a development environment for said phone, and and upload applications to it.
As for the internet cafe, you burn the application and keys to a CD. Then you run the app from the CD. Still, using an internet cafe is not really that smart, because it could be trojaned or keylogged, and read your cleartext. But it is possible for those willing to take the risk.
Rather than build an email client plugin, many of which already exist, I took a different approach. It's a standalone application where the input text is in one pane, and the output text is in another. There are two buttons: encrypt, and decrypt. The user justs copies and pastes text from the browser into the input pane, and decrypts. For encryption, you write your message in the input pane, hit encrypt, enter your passphrase, and copy the output (base64 encoded) into your mail client, webmail, whatever.
So the users can carry the keys and application with them on a USB stick or CDROM. The latter is a little safer, as it would prevent a malicious host from overwriting your keyfile. But there's still the possibility that if you are using it on a compromised machine, the message will be compromised.
The reason why this works so well is that it doesn't require a user to change the way they work with email. It's client agnostic. And, it's simple - there are only two buttons on the application; the key is automatically selected by the application; the user enters their own passphrase. Everyone can copy and paste. Not everyone wants to change their email client or learn a large set of cryptic commands (no pun intended).
So, if the user loses their usb stick or CD, their messages are still secured. If someone learns their passphrase, they still have to acquire the key file to decrypt messages. And, recovery from such situations is as automatic as possible - create a new keyfile, burn a new CD, and distribute copies to your cohorts. Or, just change the passphrase and inform the others.
Public key crypto does have the nice advantage of automating key exchange. However, it is susceptible to a MITM attack; safeguarding against this still requires an uncompromised channel (while eavesdropping alone would not compromise the communication, the ability to impersonate the other party would.) While PK crypto is technically a little better in regard to key exchange, both public and private key crypto requires the exchange of some secret over a secured channel. From the perspective of the end user, there's little difference in the inconvenience level. However, public key cryptography can get complex - imagine explaining the concept of "web of trust" to the average soccer mom; in general, GPG does not shield the user from this complexity, and can still be used in a very insecure way by uneducated or lazy users. People can more easily understand the need to keep a secret secret; burning a CD for them and their 10 friends is a lot easier for them to grasp than calling up their ten friends and repeating a 64 digit base-64 encoded key. And the possibility for error is far greater in the latter scenario than the former.
Well I've gone on too long about this. Hopefully, source code will be posted soon; though I'm so busy I can't say just when.
When GM introduced the 350 ci V8 in the 70's, it was based on the 305 ci V8. Because of the gas shortage at the time, GM advertised the larger engine as, "Having more metal removed from the cylinders to reduce weight..." Technically, it was true - a 350 was just a bored-out 305. Supposedly, lightening the car in this manner would improve fuel efficiency, though I doubt the reduced weight was enough to compensate for the increased displacement.
You know, I thought about those very possibilities when I designed this thing:
Number one doesn't do any good because you need both the key and the passphrase to cipher data. The key isn't on the computer. Nor is the passphrase, though it is entered through the keyboard at cipher time. Yes, it is possible that a trojaned system could compromise the passphrase, but why would you bother logging the passphrase when one could just log the cleartext as it is typed? If you don't have a secure computer, encryption isn't going to buy you anything. However, we're talking about cases where the government is interested in spying en masse, and planting keyloggers on everyone's machine isn't really a viable option. Encryption keeps your email from being compromised by someone who doesn't have physical access to your computer.
Given a choice between rendition and handing over my key, I'm going to choose the latter. My email encryption might be bulletproof, but I'm not. Anyone, for that matter, could become a victim of such an attack; even the "gun-stockpiling" guys in Waco couldn't fend off the Feds. Encryption doesn't solve the problem of government corruption, but it can prevent the activists from becoming known before the revolution happens.
Even if turned over to the FISA court, you're still burning government resources. The idea behind everyone encrypting everything is that it forces the government to go after people who are very likely to be criminals, instead of eavesdropping en masse, hoping to find dirt on a relatively innocent person. The idea is that we want actual crimes prosecuted, not the imaginary fantasies of an over-zealous prosecutor. If email scanning is not available, they'll have to revert to the time-honored tactic of using traditional police methods for investigation, instead of invading the privacy of the entire nation.
The real crux of the problem is that it seems like a lot of people are getting mad about the erosion of liberties, but nobody is actually doing anything. Don't just complain about your lost liberties! Do something!
Or you might soon find that you can no longer do anything, except reminisce about the times when America was still free.
Seriously. There are already libraries such as FLTK and QT for the graphic front end. For the back end, you could use XySSL, OpenSSL, or even GNU GPG.
I'm about 20 hours into an encryption client, and I've already got people using it. I initially wanted to use GPG, but realized that most technophobes won't go for a command line application. So I pulled out FLUID (the FLTK design utility) and had a prototype working within hours.
Today, there's no excuse for not encrypting your email. I realize that you may think you have Constitutional rights in this regard, but GW & Co. have the guns, the taxpayer financing, and even the (unsolicited!) cooperation of the major network carriers. It doesn't matter what you think the Constitution says if you can't even get a trial. You're on your own from here on out.
So why encrypt, even if you've nothing to hide? Well, simple, really. Why let the government violate the 4th ammendment with impunity? If you encrypt your email, the government can't perform secret, mass surveillance. Sure, they can pound on your door, and even demand the key. You might even have to give it to them. But in them doing so, you've achieved three key goals:
In order to get the key from you, they'll have to contact you. So they can't secretly eavesdrop on your communications.
Should you refuse the key, they will have to convince a judge to order you to divulge it - thus, your 4th ammendment rights are preserved - the judge will require probable cause before issuing the order.
In demanding the key, the issue will move from the administrative branch to the judicial branch. You want to force the government into the courtroom so that your other rights are not trampled as well.
Encryption is highly Constitutional (TM) software. It keeps terrorists from eavesdropping on our conversations, knowing our whereabouts, and stealing our valuable intellectual property. If the government can't read my email, neither can the terrorists.
Be patriotic. Support the Constitution. Encrypt everything.
I think the bigger issue is that I can't talk about the relative costs and benefits of any technology if my employer is known. Even if said technology is completely unrelated to my actual professional work, I can imagine the criticisms now:
"Engineer X, who works at [big name company] says technology Y is garbage. Obviously, [big name company] won't be interested in partnering with [company pushing technology Y]", or
"Engineer X, who works for [big name company] says technology Y is fantastic. [Company pushing Y] quotes engineer X in marketing materials, and now Engineer X is called on the carpet because his employer is pushing technology Z and wants to know why one of their engineers isn't playing ball.
If I divulge my employer, I can't contribute to the discussion without also risking the liability that my statements will be misattributed to my employer, or reflect badly on the company as a whole. If I don't divulge my employer, I can speak my opinion honestly. I can have an honest discussion about the merits of a particular technology.
And really, it shouldn't matter for whom I work. If I happen to know technology Z is better than technology Y, and explain so with valid data, the points I make are true regardless of whether technology Z is my employer's product.
As an example: Statement completion is a valuable feature in IDEs. Would this statement be any less true if I worked for Intellisense (or whoever makes that VS widget)? We could have an editor flame-war regardless of my employer; knowing for whom I work wouldn't add anything to the discussion.
In the case at hand, we have an Intel employee dressing down OLPC. Perhaps his criticisms were valid; perhaps not. However, his arguments stand or fall on their merits, regardless of where he works. The fact that he works for Intel doesn't mean that his reasons are any less valid.
Sadly, people will use a conflict of interest as a means to dismiss someone else's opinions without even evaluating them on their merits. Truth is true regardless of the messenger; if a solar cell maker said the sky was clear, it would not cease to be so merely because the company has a vested interest in the sky being cloudless. What we have now are people who refuse even to look up to the sky to check, instead insisting that the messenger's conflict of interest must necessarily mean their statements are false or tainted.
Problem is, until someone actually downloads the files, no infringement occurs. This is the problem: while he may have intended to share the files, and might even have intended to break the law (that is, he knew copyright infringement was illegl), damages have only occurred when someone actually copied the files. It's akin to unlocking your neighbor's door - it's not being an accessory to theft until someone actually walks in and robs the place.
This is important, because without actual copying, the plaintiff suffers no damages. There's not even the possibility of lost revenue if no one actually downloads the song.
Because copyright infringement carries statutory damages, the RIAA doesn't have to prove actual damages; the value of the work is assumed by the law. Thus, it is even more important to ensure that actual copying took place, because without it, the RIAA could collect from a defendant damages that it never actually suffered. This is why it is important for the plaintiff to show that copying actually occurred.
It has gone from protecting the rights of the artists to an attempt to bilk anyone remotely connected to the music. If the RIAA is allowed to stretch this definition of copyright law through precedent, how much further will they take it? If copying need not occur for copyright infringement, then couldn't they likewise claim that merely hearing an unlicensed copy also constitutes infringement?
I work for a major engineering company. My views do not necessarily represent the views of my employer, and I wish it to remain this way.
So, if I personally felt that my employer's project was superior to a competitor's, should I be forced to disclose my employer? What if I felt my employer was following the wrong marketing strategy? Should I disclose then?
The problem, as I see it, is if I disclose my employer, people will associate my opinions with my employer. Or worse, if I am critical of some new technology, will assume that my employer is also critical of said technology. Either situation can damage the reputation and possibly the business prospects of my employer. In light of such, if people knew who employed me, I would be less likely to state my opinion, for fear of the negative repercussions.
Unfortunately, all too many people are willing to discredit others based on their affiliations and associations rather than the strength or weaknesses of their arguments. The problem, as I see it, is that everyone seems to want an unbiased source, rather than dealing with the fact that this is almost impossible in the real world, and rather than evaluating the bias of the debater, we should be debating the merit of his arguments. Sadly, because so many are concerned with the authority and credentials of the presenter, those of us who actually have authority on technical issues are loathe to discuss them in public. I would rather have my arguments evaluated in light of their strengths and weaknesses than whom has chosen to employ me.
And for this reason, I chose not to divulge my employer. I want my arguments evaluated on their merits, without respect for my authority in the field. Too many people have adopted the practice of taking a position in a debate based not upon the merits of the arguments, but rather, the authority of the presenter. I expect people to think; I'm not here to make up your mind for you.
Why not just force them to install solar cells to supplement the building/home's electricity during peak hours?
The peak hours are caused by periods of increased radiant energy by the sun. IOW, during peak solar efficiency.
I suspect, however, that PG & E doesn't want such a solution because it would dilute their monopoly on power. So rather than give the customers what they want and need (by building generation capacity), or allowing them an innovative solution to the problem (solar supplementation), or control demand through increased pricing during peak hours - somewhat unethical because the power company determines "peak hours"), they would rather opt for a solution which makes their customers suffer, while providing no actual benefit to the power company.
Why not just say to the waitress, "If I can't buy alcohol without you scanning my license, I'll drink water instead..."
Don't walk out. Don't bother faking a license. Just shorten the bill. They'll figure it out soon enough.
Most restaurants make a substantial portion of their revenue on the sale of alcohol. If consumers fight this by refusing to purchase, the business side is going to figure out how to make it go away.
Yes, but balance that against the lower health insurance premiums you'll pay because moderate drinkers are 60% less likely to suffer a heart attack than teetotalers.
Maybe they didn't switch all of their computers, maybe they switched back, or maybe they just figured it would be easier to pay off the BSA than go to court.
Which is why no one should use Windows. But everyone does, and just hopes that they're not the one who's box gets owned and does something which raises the ire of law enforcement.
You might not have been able to avoid the visit no matter what you did. Maybe you were just unlucky.
You could have been any idiot running Windows, who got their box owned, and subsequently visited by the FBI. It doesn't require an insecure WiFi setup - all it requires is an insecure system.
Not to nitpick, but I get the same zero-initialized array even when declared inside the body of a function. The problem I see with this is that someone who learns C through trial and error will expect every compiler to zero pad an array.
These kinds of details are important, because I was taught that the compiler always zero terminates a string. So it apparently works out something like this:
char foo[5] = {0}; produces a 5 byte string of all 0's. (Yes, there was a time when this was true; it was valid C). I don't think this will compile on most modern compilers.
char foo[5] = { 'a', 's', 'd', 'f' }; produces a 5 byte string, where the last byte is not necessarily 0 (but happens to be when gcc is used).
Apparently, if you have a string on the rhs of an expression, the compiler creates an ANSI-C, null terminated string literal. If you declare an array and initialize it element-by-element, the compiler is free to leave the remaining bytes unitialized; that is, it doesn't implicitly null terminate an array initialized element-by-element. To the compiler, the first is treated as a null terminated string; the second is merely a sequence of bytes.
You know, this violates the principle of least surprise. If the ANSI standard declares a string to be null terminated, then one expects a literal string to be null terminated, regardless of whether the object to which it is assigned is a "char *" or a "char []", or "char [size]". Semantically, they are identical; the difference is that when the size is specified, the compiler doesn't go through the additional step of determing the allocation size.
When I first learned C, I was taught that the only time the compiler initialized the entire array was when the syntax of [3] was used. And the compiler didn't zero-initialize an array unless it was explicitly specified as such. Apparently, both of these have changed. The first is no longer valid syntax, and the compiler is now apparently free to zero-initialize an array, (or not). What disturbs me is that in an attempt to outsmart the "dumb" programmer, we've now created a situation which allows subtle bugs to hide in code. I think the GP example, and the discussion that followed, is a prime example of how violating the principle of least surprise can produce subtle and difficult to find bugs in code. Even though I code in C on a daily basis, it wasn't immediately apparent that the GP code was flawed; in fact, it compiles and runs correctly on an x86 system. So to most C programmers, the argument of whether or not it is ANSI compliant seems pedantic. (Even though it isn't).
You see, 480 Mbs is the electrical interface speed. As in, 480 Million bits go across the wire every second. Not all of those bits are used for traffic.
However, some of those bits are used by the overhead of the transfer protocol. You've got USB packets in the stream which do nothing but reserve space for some psuedo-realtime device which might be connected to the bus at any second. Whether or not the OS/USB Controller allocates these blank packets even in cases where they aren't needed is a matter of programming.
As an aside, I've noticed that on the same computer, with the same flash drive, Linux does a much faster job with file transfers than Windows. I suspect Windows is just under-utilizing the bus, to make it easier for their engineers. But I could be wrong, as I haven't looked into it in detail.
This is good advice for your personal and professional development as a programmer. But one thing you should keep in mind is that in practice you use the language your employer mandates you use. You don't often get to choose, and the language used is often times less than optimal for the problem you are solving. Learning how to creatively work around the limits of a language without creating an unmaintainable mess of code is the mark of a professional. It will get you much farther than complaining about how language X isn't suited for the job.
Though, you also need to be realistic. If the language is so outdated that it can't do the job, you might be better off moving to a different company before the project fails and you get the blame.
The interesting thing about this code is that it will work correctly until someone tries to port to a system with a different/older compiler which doesn't implicitly zeroize data sections.
The problem with installing Windows on the OLPC is that it destroys the original purpose of the device: to educate children about how computers work. With Windows:
They won't be able to see the source code, to figure out how it works.
Or, if they are allowed to see the source code, they will be never be able to work in the OS/Office Suite/whatever market.
They won't learn computer science, or even proper programming practices. They'll come to believe that writing bug-free code is impossible, and that every computer crashes from time to time. They'll learn that viruses are a normal part of owning a computer.
If Windows goes on the OLPC, the project has failed. It's that simple.
Because as we all know, manual memory allocation is hard to understand. Programmers shouldn't have to know basic math, right?
Why don't we just make a language that does it automatically, and then we won't have any problems like this? Right?!
Those of us who cut their teeth on assembly and C look at this and just wonder in wide amazement. A part of us wonders how anyone could be so negligent - but the other part knows how things work in proprietary software shops. (A hint - the management doesn't consider it a bug unless the customer notices it.) Yes, we've all done this before, but the solution isn't to create a language which dumbs down the programmer (Dude - you're writing directly to memory!!! You must be some kind of uber-hacker!!). Rather, there are steps you can take to virtually eliminate this kind of problem:
A different language isn't the solution (cue the Java trolls). The problem is that the programmer did not know how to correctly allocate the buffer, didn't bother to calculate the size needed, or was just plain sloppy. A sloppy C programmer makes an even sloppier Java programmer; if one can't be bothered to understand the details, they won't be saved by switching to another language.
People do make mistakes, and the field of software engineering knows this. Thats why we advocate things like Formal Technical Reviews - where other engineers review the code you've written. Even if the author of this abomination was fresh out of college and didn't know any better, a thorough review would have caught the mistake.
A good system test plan would have a.) known that such vulnerabilities are common, and b.) stress tested the code for this very situation. One thing I like to do in testing is to put values into fields that are one larger than what the program expects. Does it overflow? Does it crash? Does it correctly detect and properly handle the incorrect input? A good test program would have caught this bug even if the review had missed it.
There are automated tools which can find buffer overflows, uninitialized variables, and the like. Why weren't they used? Or, perhaps they were...
The most likely cause of this bug was not a sloppy programmer, or a bad choice of language (in fact, at this level, Java and C++ are pretty much out because of the performance issues.), but rather, a company that chose to forego the requisite design, review, and testing needed to produce a high quality product. Microsoft's customers have become so accustomed to buggy software that releasing a bug like this - and patching it later - is par for the course. From a business perspective, a buffer overflow is probably considered nothing more than a contingency that has to be dealt with eventually, that need not stop a product from shipping.
You know, there was a time when formal methods were taught, when programmers were expected to know how to properly allocate and release memory. When things like calculating the size of the buffer, applying basic math(!) and testing your own code were considered just a part of the programmer's job. Now we're hearing people blame languages for the faults of the programmer.
If I keep going, I suppose I'll start to sound like Bill Cosby. But consider this: the most reliable operating systems to date were built on C (UNIX) and assembly (MVS). If a bunch of old farts (well, perhaps they were young then...) can crank out correct, reliable, fast code without an IDE and a bunch of GUI tools, clearly the language is not to blame.
The old adage still applies: a poor workman blames his tools. Software engineering works, regardless of the implementation language. This isn't a failure of the language or the environment, but rather, failure to do software engineering right:
The programmer made the initial mistake, and
Then no review of the code was performed, or all of the reviewers missed it, and
They chose to use the term unlimited usage, and if they don't want to offer unlimited access, they should change their TOS.
There's nothing criminal or unethical about expecting a company to provide what it has promised. Some of us would be quite willing to pay, say, only $10 per month for a 1.3 Mbs connection, even if it came with a 5 GB/month transfer cap. But the cable companies won't do that. Instead, you have to buy their unlimited plan, and pay for bandwidth that you don't even use.
And the cable company will happily resell your unused bandwidth to others. It's called capacity planning, and they use statistical analysis to figure out the bandwidth that most people will actually use. Problem is, they have a financial interest in fully utilizing their equipment, i.e., buying only as much as needed. Which, when their estimates are wrong, results in lousy service for customers. Your problem is not that you are paying for someone else's bandwidth, but rather, that the cable company is making you pay for bandwidth they don't expect you to use.
Your torrent-hosting neighbor is simply using all of the bandwidth for which he paid. He's not using yours. (That is, unless he's owned your box, but that's a different thread entirely...)
Granted, it would work were there sufficient stopping distance between the vehicles. But today people don't leave enough room to stop, much less react, between their vehicles, and the engineer implies that the computer will reduce even this distance between them.
But more to the point, most accidents (of this sort) are not the result of faulty reaction time, but of simply not having enough distance to stop. Regardless of how quickly the computer reacts, even a subcompact takes about 200 feet to stop from 60 miles per hour. That's a full 2 seconds of travel at that speed - reducing the reaction time from 250 milliseconds to zero will only result in about a 25 foot shorter stopping distance, or about a 12% reduction in stopping distance.
Furthermore, avoidance won't be an option, because the very reason why they're traveling so closely is that the freeway itself is packed. Thus, they take a bad situation, and make it worse.
Now, perhaps there's more variance with human drivers - I've had people tailgate me at 120 mph before - but there's also a lot more caution. A human being who doesn't know the exact limits of adhesion (or rather, doesn't know well enough to bet their life) is going to be more cautious than a computer which believes it does. And problems will invariably creep up with this approach - either the computer will underestimate traction in most circumstances, leading to frustrated, slow travel; or it will overestimate it, resulting in even greater danger to *all* drivers on the road. As it is, a person driving today can pretty much choose their risk level, but if the computer is driving, the risk level is prescribed by GM. Compounding the problem even more is that while a human being can see adverse traction conditions ahead and slow down accordingly, the computer can only *react* to the conditions it currently detects. Thus, by the time the computer figures out you've hit an ice patch, it's already too late for it to slow down safely, no matter how precisely it can control the steering and the brakes.
Slashdot Mirror
So, you saved $80K and wasted a million. Way to go !
Yes, way to go!
You forget, that in corporate America, NOBODY polices the organization as a whole. If your department manages to save $80,000 by creating a liability for the [future | some other department | the public at large], management is pleased. That half-million dollar power usage problem is owned by the building management, not the IT department. So, kudos to the IT department for saving eighty grand!
Well, perhaps the article glossed over a few things.
Galileo was called to Rome because he attempted to interpret the Bible. Which is kind of odd for a scientist, isn't it? Or perhaps Galileo, like a large portion of the world, saw no fundamental conflict between theology and science. After all, both seek the truth, but I'm digressing here...
Anyway, in Galileo's time, someone else attempted to interpret the Bible, and it eventually led to a new religion. You might be familiar with the name Martin Luther. It doesn't surprise me the least that Galileo got called to Rome, because he did have political enemies. And this was just what they were looking for - something that could be misrepresented as threatening the authority of the Vatican. In that time, claiming to have some special knowledge of God was not merely a religious statement; it was political as well.
And what does the Vatican do? They aren't quite sure if he's a problem or not, but to avoid the possibility him emulating Luther, they confine him to house arrest - which would be a serious obstacle to a political revolutionary, but not impose much on a scientist.
the amount of damage (direct and indirect) that has been perpetrated on humanity in the name of vague ethereal omnipotent beings is so stunning that very few people even realize it
Link, please.
This particular myth gets bandied about quite a bit by those who would rather bash religion than actually analyze history. I know it's so godwin, but it is relevant:
Time and again we hear this old myth about religion causing people to kill each other, but the most violent regimes in history were always anti-God.
So the users can carry the keys and application with them on a USB stick or CDROM. The latter is a little safer, as it would prevent a malicious host from overwriting your keyfile. But there's still the possibility that if you are using it on a compromised machine, the message will be compromised.
The reason why this works so well is that it doesn't require a user to change the way they work with email. It's client agnostic. And, it's simple - there are only two buttons on the application; the key is automatically selected by the application; the user enters their own passphrase. Everyone can copy and paste. Not everyone wants to change their email client or learn a large set of cryptic commands (no pun intended).
So, if the user loses their usb stick or CD, their messages are still secured. If someone learns their passphrase, they still have to acquire the key file to decrypt messages. And, recovery from such situations is as automatic as possible - create a new keyfile, burn a new CD, and distribute copies to your cohorts. Or, just change the passphrase and inform the others.
Public key crypto does have the nice advantage of automating key exchange. However, it is susceptible to a MITM attack; safeguarding against this still requires an uncompromised channel (while eavesdropping alone would not compromise the communication, the ability to impersonate the other party would.) While PK crypto is technically a little better in regard to key exchange, both public and private key crypto requires the exchange of some secret over a secured channel. From the perspective of the end user, there's little difference in the inconvenience level. However, public key cryptography can get complex - imagine explaining the concept of "web of trust" to the average soccer mom; in general, GPG does not shield the user from this complexity, and can still be used in a very insecure way by uneducated or lazy users. People can more easily understand the need to keep a secret secret; burning a CD for them and their 10 friends is a lot easier for them to grasp than calling up their ten friends and repeating a 64 digit base-64 encoded key. And the possibility for error is far greater in the latter scenario than the former.
Well I've gone on too long about this. Hopefully, source code will be posted soon; though I'm so busy I can't say just when.
When GM introduced the 350 ci V8 in the 70's, it was based on the 305 ci V8. Because of the gas shortage at the time, GM advertised the larger engine as, "Having more metal removed from the cylinders to reduce weight..." Technically, it was true - a 350 was just a bored-out 305. Supposedly, lightening the car in this manner would improve fuel efficiency, though I doubt the reduced weight was enough to compensate for the increased displacement.
You know, I thought about those very possibilities when I designed this thing:
The real crux of the problem is that it seems like a lot of people are getting mad about the erosion of liberties, but nobody is actually doing anything. Don't just complain about your lost liberties! Do something!
Or you might soon find that you can no longer do anything, except reminisce about the times when America was still free.
Seriously. There are already libraries such as FLTK and QT for the graphic front end. For the back end, you could use XySSL, OpenSSL, or even GNU GPG.
I'm about 20 hours into an encryption client, and I've already got people using it. I initially wanted to use GPG, but realized that most technophobes won't go for a command line application. So I pulled out FLUID (the FLTK design utility) and had a prototype working within hours.
Today, there's no excuse for not encrypting your email. I realize that you may think you have Constitutional rights in this regard, but GW & Co. have the guns, the taxpayer financing, and even the (unsolicited!) cooperation of the major network carriers. It doesn't matter what you think the Constitution says if you can't even get a trial. You're on your own from here on out.
So why encrypt, even if you've nothing to hide? Well, simple, really. Why let the government violate the 4th ammendment with impunity? If you encrypt your email, the government can't perform secret, mass surveillance. Sure, they can pound on your door, and even demand the key. You might even have to give it to them. But in them doing so, you've achieved three key goals:
Encryption is highly Constitutional (TM) software. It keeps terrorists from eavesdropping on our conversations, knowing our whereabouts, and stealing our valuable intellectual property. If the government can't read my email, neither can the terrorists.
Be patriotic. Support the Constitution. Encrypt everything.
I think the bigger issue is that I can't talk about the relative costs and benefits of any technology if my employer is known. Even if said technology is completely unrelated to my actual professional work, I can imagine the criticisms now:
If I divulge my employer, I can't contribute to the discussion without also risking the liability that my statements will be misattributed to my employer, or reflect badly on the company as a whole. If I don't divulge my employer, I can speak my opinion honestly. I can have an honest discussion about the merits of a particular technology.
And really, it shouldn't matter for whom I work. If I happen to know technology Z is better than technology Y, and explain so with valid data, the points I make are true regardless of whether technology Z is my employer's product.
As an example: Statement completion is a valuable feature in IDEs. Would this statement be any less true if I worked for Intellisense (or whoever makes that VS widget)? We could have an editor flame-war regardless of my employer; knowing for whom I work wouldn't add anything to the discussion.
In the case at hand, we have an Intel employee dressing down OLPC. Perhaps his criticisms were valid; perhaps not. However, his arguments stand or fall on their merits, regardless of where he works. The fact that he works for Intel doesn't mean that his reasons are any less valid.
Sadly, people will use a conflict of interest as a means to dismiss someone else's opinions without even evaluating them on their merits. Truth is true regardless of the messenger; if a solar cell maker said the sky was clear, it would not cease to be so merely because the company has a vested interest in the sky being cloudless. What we have now are people who refuse even to look up to the sky to check, instead insisting that the messenger's conflict of interest must necessarily mean their statements are false or tainted.
Sure, the guy was trying to give them away.
Problem is, until someone actually downloads the files, no infringement occurs. This is the problem: while he may have intended to share the files, and might even have intended to break the law (that is, he knew copyright infringement was illegl), damages have only occurred when someone actually copied the files. It's akin to unlocking your neighbor's door - it's not being an accessory to theft until someone actually walks in and robs the place.
This is important, because without actual copying, the plaintiff suffers no damages. There's not even the possibility of lost revenue if no one actually downloads the song.
Because copyright infringement carries statutory damages, the RIAA doesn't have to prove actual damages; the value of the work is assumed by the law. Thus, it is even more important to ensure that actual copying took place, because without it, the RIAA could collect from a defendant damages that it never actually suffered. This is why it is important for the plaintiff to show that copying actually occurred.
It has gone from protecting the rights of the artists to an attempt to bilk anyone remotely connected to the music. If the RIAA is allowed to stretch this definition of copyright law through precedent, how much further will they take it? If copying need not occur for copyright infringement, then couldn't they likewise claim that merely hearing an unlicensed copy also constitutes infringement?
I work for a major engineering company. My views do not necessarily represent the views of my employer, and I wish it to remain this way.
So, if I personally felt that my employer's project was superior to a competitor's, should I be forced to disclose my employer? What if I felt my employer was following the wrong marketing strategy? Should I disclose then?
The problem, as I see it, is if I disclose my employer, people will associate my opinions with my employer. Or worse, if I am critical of some new technology, will assume that my employer is also critical of said technology. Either situation can damage the reputation and possibly the business prospects of my employer. In light of such, if people knew who employed me, I would be less likely to state my opinion, for fear of the negative repercussions.
Unfortunately, all too many people are willing to discredit others based on their affiliations and associations rather than the strength or weaknesses of their arguments. The problem, as I see it, is that everyone seems to want an unbiased source, rather than dealing with the fact that this is almost impossible in the real world, and rather than evaluating the bias of the debater, we should be debating the merit of his arguments. Sadly, because so many are concerned with the authority and credentials of the presenter, those of us who actually have authority on technical issues are loathe to discuss them in public. I would rather have my arguments evaluated in light of their strengths and weaknesses than whom has chosen to employ me.
And for this reason, I chose not to divulge my employer. I want my arguments evaluated on their merits, without respect for my authority in the field. Too many people have adopted the practice of taking a position in a debate based not upon the merits of the arguments, but rather, the authority of the presenter. I expect people to think; I'm not here to make up your mind for you.
Why not just force them to install solar cells to supplement the building/home's electricity during peak hours?
The peak hours are caused by periods of increased radiant energy by the sun. IOW, during peak solar efficiency.
I suspect, however, that PG & E doesn't want such a solution because it would dilute their monopoly on power. So rather than give the customers what they want and need (by building generation capacity), or allowing them an innovative solution to the problem (solar supplementation), or control demand through increased pricing during peak hours - somewhat unethical because the power company determines "peak hours"), they would rather opt for a solution which makes their customers suffer, while providing no actual benefit to the power company.
This "solution" is the worst of both worlds.
The holy men knew what they were doing: moderate drinking helps you live longer.
Why not just say to the waitress, "If I can't buy alcohol without you scanning my license, I'll drink water instead..."
Don't walk out. Don't bother faking a license. Just shorten the bill. They'll figure it out soon enough.
Most restaurants make a substantial portion of their revenue on the sale of alcohol. If consumers fight this by refusing to purchase, the business side is going to figure out how to make it go away.
Yes, but balance that against the lower health insurance premiums you'll pay because moderate drinkers are 60% less likely to suffer a heart attack than teetotalers.
Didn't they switch to Linux a few years ago?
Maybe they didn't switch all of their computers, maybe they switched back, or maybe they just figured it would be easier to pay off the BSA than go to court.
Which is why no one should use Windows. But everyone does, and just hopes that they're not the one who's box gets owned and does something which raises the ire of law enforcement.
You might not have been able to avoid the visit no matter what you did. Maybe you were just unlucky.
You could have been any idiot running Windows, who got their box owned, and subsequently visited by the FBI. It doesn't require an insecure WiFi setup - all it requires is an insecure system.
Not to nitpick, but I get the same zero-initialized array even when declared inside the body of a function. The problem I see with this is that someone who learns C through trial and error will expect every compiler to zero pad an array.
These kinds of details are important, because I was taught that the compiler always zero terminates a string. So it apparently works out something like this:
Apparently, if you have a string on the rhs of an expression, the compiler creates an ANSI-C, null terminated string literal. If you declare an array and initialize it element-by-element, the compiler is free to leave the remaining bytes unitialized; that is, it doesn't implicitly null terminate an array initialized element-by-element. To the compiler, the first is treated as a null terminated string; the second is merely a sequence of bytes.
You know, this violates the principle of least surprise. If the ANSI standard declares a string to be null terminated, then one expects a literal string to be null terminated, regardless of whether the object to which it is assigned is a "char *" or a "char []", or "char [size]". Semantically, they are identical; the difference is that when the size is specified, the compiler doesn't go through the additional step of determing the allocation size.
When I first learned C, I was taught that the only time the compiler initialized the entire array was when the syntax of [3] was used. And the compiler didn't zero-initialize an array unless it was explicitly specified as such. Apparently, both of these have changed. The first is no longer valid syntax, and the compiler is now apparently free to zero-initialize an array, (or not). What disturbs me is that in an attempt to outsmart the "dumb" programmer, we've now created a situation which allows subtle bugs to hide in code. I think the GP example, and the discussion that followed, is a prime example of how violating the principle of least surprise can produce subtle and difficult to find bugs in code. Even though I code in C on a daily basis, it wasn't immediately apparent that the GP code was flawed; in fact, it compiles and runs correctly on an x86 system. So to most C programmers, the argument of whether or not it is ANSI compliant seems pedantic. (Even though it isn't).
Yes, and no.
You see, 480 Mbs is the electrical interface speed. As in, 480 Million bits go across the wire every second. Not all of those bits are used for traffic.
However, some of those bits are used by the overhead of the transfer protocol. You've got USB packets in the stream which do nothing but reserve space for some psuedo-realtime device which might be connected to the bus at any second. Whether or not the OS/USB Controller allocates these blank packets even in cases where they aren't needed is a matter of programming.
As an aside, I've noticed that on the same computer, with the same flash drive, Linux does a much faster job with file transfers than Windows. I suspect Windows is just under-utilizing the bus, to make it easier for their engineers. But I could be wrong, as I haven't looked into it in detail.
This is good advice for your personal and professional development as a programmer. But one thing you should keep in mind is that in practice you use the language your employer mandates you use. You don't often get to choose, and the language used is often times less than optimal for the problem you are solving. Learning how to creatively work around the limits of a language without creating an unmaintainable mess of code is the mark of a professional. It will get you much farther than complaining about how language X isn't suited for the job.
Though, you also need to be realistic. If the language is so outdated that it can't do the job, you might be better off moving to a different company before the project fails and you get the blame.
While technically you may be correct about the C standard, gcc does indeed provide zero padded arrays:
A dump of the file produces this:
The interesting thing about this code is that it will work correctly until someone tries to port to a system with a different/older compiler which doesn't implicitly zeroize data sections.
The problem with installing Windows on the OLPC is that it destroys the original purpose of the device: to educate children about how computers work. With Windows:
If Windows goes on the OLPC, the project has failed. It's that simple.
Because as we all know, manual memory allocation is hard to understand. Programmers shouldn't have to know basic math, right?
Why don't we just make a language that does it automatically, and then we won't have any problems like this? Right?!
Those of us who cut their teeth on assembly and C look at this and just wonder in wide amazement. A part of us wonders how anyone could be so negligent - but the other part knows how things work in proprietary software shops. (A hint - the management doesn't consider it a bug unless the customer notices it.) Yes, we've all done this before, but the solution isn't to create a language which dumbs down the programmer (Dude - you're writing directly to memory!!! You must be some kind of uber-hacker!!). Rather, there are steps you can take to virtually eliminate this kind of problem:
You know, there was a time when formal methods were taught, when programmers were expected to know how to properly allocate and release memory. When things like calculating the size of the buffer, applying basic math(!) and testing your own code were considered just a part of the programmer's job. Now we're hearing people blame languages for the faults of the programmer.
If I keep going, I suppose I'll start to sound like Bill Cosby. But consider this: the most reliable operating systems to date were built on C (UNIX) and assembly (MVS). If a bunch of old farts (well, perhaps they were young then...) can crank out correct, reliable, fast code without an IDE and a bunch of GUI tools, clearly the language is not to blame.
The old adage still applies: a poor workman blames his tools . Software engineering works, regardless of the implementation language. This isn't a failure of the language or the environment, but rather, failure to do software engineering right:
But the cable companies market it as if it were.
They chose to use the term unlimited usage, and if they don't want to offer unlimited access, they should change their TOS.
There's nothing criminal or unethical about expecting a company to provide what it has promised. Some of us would be quite willing to pay, say, only $10 per month for a 1.3 Mbs connection, even if it came with a 5 GB/month transfer cap. But the cable companies won't do that. Instead, you have to buy their unlimited plan, and pay for bandwidth that you don't even use.
And the cable company will happily resell your unused bandwidth to others. It's called capacity planning, and they use statistical analysis to figure out the bandwidth that most people will actually use. Problem is, they have a financial interest in fully utilizing their equipment, i.e., buying only as much as needed. Which, when their estimates are wrong, results in lousy service for customers. Your problem is not that you are paying for someone else's bandwidth, but rather, that the cable company is making you pay for bandwidth they don't expect you to use.
Your torrent-hosting neighbor is simply using all of the bandwidth for which he paid. He's not using yours. (That is, unless he's owned your box, but that's a different thread entirely...)
Granted, it would work were there sufficient stopping distance between the vehicles. But today people don't leave enough room to stop, much less react, between their vehicles, and the engineer implies that the computer will reduce even this distance between them.
But more to the point, most accidents (of this sort) are not the result of faulty reaction time, but of simply not having enough distance to stop. Regardless of how quickly the computer reacts, even a subcompact takes about 200 feet to stop from 60 miles per hour. That's a full 2 seconds of travel at that speed - reducing the reaction time from 250 milliseconds to zero will only result in about a 25 foot shorter stopping distance, or about a 12% reduction in stopping distance.
Furthermore, avoidance won't be an option, because the very reason why they're traveling so closely is that the freeway itself is packed. Thus, they take a bad situation, and make it worse.
Now, perhaps there's more variance with human drivers - I've had people tailgate me at 120 mph before - but there's also a lot more caution. A human being who doesn't know the exact limits of adhesion (or rather, doesn't know well enough to bet their life) is going to be more cautious than a computer which believes it does. And problems will invariably creep up with this approach - either the computer will underestimate traction in most circumstances, leading to frustrated, slow travel; or it will overestimate it, resulting in even greater danger to *all* drivers on the road. As it is, a person driving today can pretty much choose their risk level, but if the computer is driving, the risk level is prescribed by GM. Compounding the problem even more is that while a human being can see adverse traction conditions ahead and slow down accordingly, the computer can only *react* to the conditions it currently detects. Thus, by the time the computer figures out you've hit an ice patch, it's already too late for it to slow down safely, no matter how precisely it can control the steering and the brakes.