There's a huge gap somewhere in newspapers' thinking. (And actually, one in every content producers' thinking). People want free content.
There appears to be one in most content consumers' thinking, too. There is no such thing as free. Everything costs somebody, something.
TV is the perfect example of a very successful business model where the prime channels are free of charge to the end user. Advertisers pay millions to advertise on TV. There is, absolutely, categorically, beyond any shadow of a doubt, no technological impediment to why this can't happen for online news, TV, movies, music, or whatever else.
Other, you mean, than the ease of automatic filtering of online adverts? Online adverts cost a hell of lot less than TV adverts because they're too easy to avoid. This will only get worse. As technology advances and TV adverts become easier to filter out, TV advertisers will have options like increased product placement available to them (imagine little "buy now!" buttons hovering over laptops in CSI). These tricks will likely neither be possible nor desirable in text-based services like online news.
The reason it doesn't happen is narrow-minded executives who do not think creatively enough, or try hard enough. Adapt or die. End of story.
Indeed. I think the "adaption" that's been postulated elsewhere is quite possible: first, smaller news outfits die as advertising revenue on online services fails to replace lost revenue from newspapers; then, the few remaining big players get together and agree to simultaneously switch business models. Even if they don't do that, you're still left with a few large corporations controlling what news the public sees.
And while laws are not necessarily moral, the people who apply them are by definition.
Sorry, I don't see this one. You could argue that we are all moral by definition, but I don't see why those that apply the law are more likely to be so. In fact, the application of the law must be free of personal morals. Would you want a policeman who let his morals trump the dictates of the law? That only sounds good if he's applying his morals in your favour.
In any case, not to get distracted from the subject at hand, I refute that speeding, as defined by going faster than a posted limit, is needlessly endangering lives. Those limits are decided by engineers who have NOT decided on the best speed. They've applied some rules of thumb, some rules of law, and some rules of common sense to arrive at a nice round number that is more correct than not.
The engineers advise, they do not dictate. The decision on the speed limit is usually down to the local government. There are plenty of built-up, residential areas that could quite easily support speed limits 10, 20 or 30 kph faster from a pure engineering point of view. They don't because these are usually littered with parked cars and have small children playing in the street. Speeding on these streets needlessly endangers their lives.
(I don't mean to get all "think of the children" here, but road accidents are the leading cause of accidental death in young children)
Of course, it's all situational. It depends on the road, the car you're driving, the environment, the other cars on the road, whatever other hazards are around you and the weather conditions; this is why I would prefer that "reckless driving" or "not driving to the conditions" would be punished more harshly than "speeding". The problem is, that's too subjective for easy law enforcement.
However, with cameras you're no longer talking more or less. You're talking exactly, atomically, right or wrong.
You've fallen into a basic fallacy here. The speed limit is exactly that, a limit. It's not a target.
True. However, that situation should be very rare. I'm aware that in the USA some places have been tweaking the yellow-red transition time down, and that the skill and consideration of your fellow drivers is going to vary from place to place; bumper-to-bumper driving at 70+ kph is obviously going to lead to some sticky situations. But I do have to wonder sometimes what definition people are using for "stop safely".
From the extremely small sample of my own experience, I have never found myself in a situation where I was traveling so fast when a light turned yellow that I wouldn't have been able to stop safely or wouldn't have been across the intersection before the lights turned red.
I have found myself in the situation where I could have stopped safely, but I chose not to. That's a completely different thing, and if I got burned for it it would have been entirely my own fault.
...but you did a far better job of making him look foolish. Thank you:)
I wasn't going to bother replying to the above poster, but since you seem to think he validates your use of that statistic, I think I should reply to you.
You made two, separate claims in your post. One, that my use of the quoted statistic was invalid. Two, that the chance of introducing a bug in an isolated module of code (say, an About box) was vanishingly small. It was the second claim I was referring to. And I said it made you look foolish because you made that claim in a very aggressive manner. See the use of "moron".
Try not to take internet insults that seriously. I have no idea who the hell you are, and I wasn't actually trying to insult you personally. If I offended you, I apologize, but that was my way of saying you made a really stupid mistake in your use of those statistics
How about you try not to make Internet insults?. I wouldn't be the first person to observe that the impersonal nature of the Internet makes people very casual about throwing insults around.
...So 10-20 defects per 1000 lines of code is based on analyzing a lot of code, and you can expect it to be valid if you take a random sample of your program. However, you're likely to a much bigger number of defects per 1000 lines of complex code and a much smaller number of defects in simple code. That doesn't mean there will never be any bugs introduced in an About window, or a simple easter egg, in the same way that it doesn't mean that there are no democrats in South Carolina. I never tried to imply otherwise.
I accept my fault in including that statistic. I didn't mean very much by it, it was just to give people a sense of the density of defects in a typical program. Including that statistic has led people focus on that rather than the essence of what I was trying to communicate.
Just for fun I'm going to point out something else in his little example. It's only triggered if the user accesses the about box in the first place. That bug doesn't affect the program at all unless you go to the about box.
Um. Personally, I use About boxes a reasonable amount. For instance, the identify the precise version of the application that's installed.
The chances of a similar type of bug in an easter egg to affect an user is even smaller, because it would require the user to first find the Easter Egg. The chances of any other type of bug is also pretty small because, like the about window, the easter egg code doesn't typically really access or communicate with any operational part of your program.
No. I'm sorry, but you are just wrong here. If the easter egg doesn't communicate with any other operational part of the program then it wouldn't be possible to trigger it. If you can trigger it, then it must be hooked into one or another input into the program, and it can introduce a bug into that input algorithm, no matter how simple the code.
Um. I just re-read that. It makes it sound like I'd throw the devs to the lions if they disobeyed me:) Actually, I'd just tell them that they needed to fix it.
Well, I normally get pretty good feedback from devs who've worked for me;)
This is going to be hard to sum up succinctly, because it's not a hard-and-fast rule. You've got to look at it from the client's point of view. They're paying a professional software development organisation to craft (and that's the key word) an application for them. It's probably going to be a key part of their day-to-day processes, so they're taking it pretty seriously, and they want you to, too. It's not a question of a fragile relationship, it's about meeting the client's expectations.
Obviously not all clients are the same. Some are more laid-back, and they appreciate easter eggs for they what they are, a manifestation of the programmer's love for their job, of programming as an art. In fact, those kind of clients are happier when they see something like that. But that's them, and they're probably in the minority.
So, the first thing I'd say to a dev who wanted to put an easter egg into one of these applications is, you're being paid to be a professional software developer and to respect the desires of our clients. If you can't sublimate your art to your craft, and blow off steam in a different direction, then, yeah, maybe you shouldn't be working for this kind of organisation. It doesn't make you a bad developer, just badly suited to this kind of work.
The next thing I'd say is, consider the long-term implications of what you're doing. Like I said before, every piece of code you write risks introducing defects. I've seen quite a few people say here that they can guarantee that an easter egg can be isolated completely from the rest of the code, making it "impossible" for it to affect the main application. That's just hubris, and if you've been developing for more than a couple of years, you should know better than that.
Funny error messages, while less dangerous, don't help the long-term maintainability of the system. I'd rather have an error message that means something.
It's my responsibility to safeguard the quality of the finished product, and if there's anything wrong with it, the buck stops with me. The flip-side of that is that it's my privilege to define how we build it. I'll defend my developers if they're playing with Nerf guns when the client visits. I won't defend them if they do something I expressly asked them not to do.
The reason people post these statistics is they're true and they're useful. If we're starting a project, and I've got a rough idea how many lines of code or how many hours it'll take to implement, how do I work out how much time to allocate to defect fixing? If it's a new team, and a new technology, and I don't have any historical figures to go on, all I've got is industry average figures and some careful weighting. It's either that or gut feel, and most people's gut feel is terrible.
The links you posted refer to lines of code per unit of functionality, not defects per line of code. The defect rate of a language is not the inverse of its expressive power. That's because the majority of programmer-introduced defects are from one of three sources:
Programmers not understanding the requirements (usually not their fault, the requirements themselves are usually to blame).
Programmers not understanding the technology they're using.
Programmers not concentrating.
These are all independent of what language you're using, and they're all just functions of time (see below). That's why defects/KLOC or defects/hr are useful metrics.
Yes, of course the language you choose affects your productivity, and probably your defect rate too; consider that the move away from C++ to Java and C# probably eliminated 80% of the memory leak defects at a stroke. Of course, that still leaves the unchecked null reference defects...grrr.
I would, however sound a note of caution about that study. It's not at all clear that their productivity measure includes defect-fixing time. Remember, code's not done until it's done and working. Over the years, I've come to believe that in the hands of a talented programmer, dynamically typed, dynamically structured, interpreted languages can be orders of magnitude more productive. The only problem is, there aren't that many programmers of that caliber. Most programmers need all the help that the compiler can give them.
When I say they're all functions of time, consider:
If you don't understand the requirements, the more of them you implement, the more damage you'll do.
If you don't understand the technology, the more code you write with it, the more damage you'll do.
The longer you code, the lower your concentration drops. The longer you code with poor concentration, the more damage you'll do.
At my current place of employment, all the code we write belongs to the client (which is pretty much SOP in the field). Our clients sometimes do not share our sense of humour. As the technical lead, if I find it, you can be damn sure you're taking it out again. And I am looking:)
I'd discourage actual functionality easter eggs too, in most programs. The industry average is estimated to be 10-20 defects per 1000 lines of code. Every non-essential line of code you write risks introducing a bug.
Yes. Especially now that we are starting to move away from the traditional RDBMS.
Since when? I see this sentiment repeated a lot, but I don't see much evidence for it. The majority of applications are still written against an RDBMS.
Sure, Google and other high-profile Internet companies use some special-purpose databases, and their size and the frequency that they're talked about tends to distort people's perception to the point that they forget that they're talking about one company working in one specific field.
The reason that the RDBMS is still king is that the relational model is a general, mathematically founded abstract model of data that can represent any structure and which allows us to make deductions about the data based on predicate logic. Pretty much all of the pretenders to the crown (including object databases) sacrifice one or all of those elements for convenience.
According to multiple sources, the average life expectancy in the USA is 77 years (different sources differ by less than a year).
According to the National Center for Health Statistics's data from 2002, you have roughly a 75% chance of surviving to age 70, 65% chance of surviving to 75 and 52% chance of surviving to 80. In other words, between 75 and 80, your odds of surviving drop by between 2 and 3% per year. Not to be ignored. On the other hand, McCain would still have a slightly better than average chance of making it through his presidency, which could not be described as "vanishingly small". However, if you like McCain, but you don't like the idea of Palin being President, and you vote for McCain you are kind of, well, tossing a coin...
Of course, what stands in his favour is that he's a wealthy white man who, if he became Commander-in-Chief of the world's most powerful nation, would have a lot of people interested in keeping him healthy. What stands against him is he's had Stage II Malignant Melanoma. This doesn't doom him, by any measure, but he stands something like a 14% chance of recurrence, and a 9% chance of death, just going by the numbers.
Are you perhaps referring to this article from 2001 which suggests that cosmic rays (which are different from emissions from the Sun, btw) intensify the effect of CFCs?
I suggest that you first read through the resources on realclimate.org on solar forcing, where it has been extensively discussed, and if you wish to dispute their findings, then please attack the science, not the scientist.
First, they don't teach "slow traffic keep right" here. Or if they do, nobody follows it. Fair enough. In the UK, probably around 80-90% drivers follow the rule (it's actually part of the Highway Code, so a legal requirement).
Second, the video was filmed on I-285 around Atlanta, where the speed limit is 55mph. Under normal, uncongested, non-rush-hour traffic conditions, the flow of traffic is generally about 75mph. Anyone trying to do 55 on their own is putting themselves and those around them in serious danger. I kind of agree with you here. The legal limit on motorways in the UK is 70 MPH. The middle lane usually contains traffic doing 70-80 MPH, the outer lane seems to have no upper limit:) In other words, almost everyone breaks the law. I would have no problem with the legal limit being that high, because it is demonstrably acceptably safe.
(Incidentally, with that in mind, I would argue that a single car travelling at 55mph should not be putting anyone at serious danger if surrounded by semi-competent drivers. Consider that the maximum speed limit for a car with caravan on a UK motorway is 60mph, and many travel at 50-55. You will encounter them, and they're merely annoying, not life-threatening)
My problem is that they didn't prove that the limit was too low. If everyone obeyed the law, unjust or not, then traffic would flow perfectly well. In the strictest terms, if you're obeying the limit and that causes a speeding driver problems, well that's their problem, not yours.
All the film actually demonstrated was that driving four abreast at a slower speed than the prevailing flow blocks traffic. Congratulations Captain Obvious, have a badge.
The reason this sort of thing gets on my nerves is that when you are driving, you are surrounded by these idiots: people who think the law must be wrong because it's inconvenient for them. They are usually also appallingly unsafe drivers.
Let me just highlight three things here. I'll preface this by saying I've only ever driven in the UK and New Zealand, which have very similar road laws and approaches to teaching driving. If they teach driving differently in the US, then a couple of things I'm going to say here might not apply.
First, all of the drivers travelling at the speed limit with the correct stopping distance (IOW, the filmmakers) were making unimpeded progress and would have arrived at their destination at the fastest possible time (distance/speed).
Second, you are - or should be - taught that allowing yourself to be boxed in - like the filmmakers - on a motorway/freeway is a VERY BAD IDEA. A good driver makes space for themselves to allow them to react to trouble.
Third, excluding exit, entry and shoulder lanes, all lanes apart from the first are for PASSING. They are not for normal driving at the speed limit. If you are going as fast as the car in front of you, then you can damn well drive behind them in the same lane.
It wasn't the speed limit causing problems for other drivers, it was their poor driving.
I presume you mean "not using it by choice or out of aversion to Microsoft", as the Firefox Silverlight plugin works just fine for viewing the comic...
False comparison. An idea cannot be stolen because, when you have taken a copy of it, the creator still has the idea.
A domain is different. By definition, there is only one of each domain. Ergo, one person can posses it in its entirety, and deprive others of its possession. Hence it can be stolen.
Options are about choice. Choice is a luxury enabled by redundant resources. As the oil and coal run out, costs will rise. As costs rise, the average person will find their options being removed. In the end, they will have only two choices: conserve, or pay an ever-increasing amount for their energy. As the cost of their food will be going up at the same time, for the same reason, I'm betting they'll choose to conserve.
Other "choices" will be removed just as unceremoniously. Goods that require a lot of energy to produce will either find more efficient production methods or become uneconomic. Once they become uneconomic, they will disappear from the market. Maybe they'll be replaced with cheaper alternatives, maybe not. You will not be able to buy everything you buy today. And it just gets worse from there on.
Of course, it doesn't have to end like this, and the pressure to avoid this scenario is present and irresistible. We are pretending to talk about choosing what we should do to pull ourselves of this hole, but the truth is we have no choices; we will do what we can to maintain our lifestyles, and pretend we meant to do it all along.
Solar et al could save us. Sooner or later, we will turn to it. The problem is, it's probably "later".
So nuclear is the only way forwards. All the objections will fall away. The US will reconsider its opposition to fast breeder reactors, because it has no other choice. Political accommodations will be made, deals will be done. We'll do the best we can with the waste products, but in the end we'll decide to "cross that bridge when we come to it". Life will go on.
I still think we're in for some tough times. It takes ten years to commission a nuclear reactor, and I've heard some commentators say that it's actually taking more like twenty at the moment...
Um. This might sound radical, but why don't they just charge for the bandwidth we use? Not our potential usage (which is what you're talking about). I mean, I might watch a lot of video on the internet, but I'm pretty sure I don't watch 7TB a month.
You can create something undetectable for the moment in Windows. Diff between Windows and Linux is, its easier to find on Windows then it would be on Linux
Why?
Apparently you didn't look at the script... The heuristic used was based of time as a proof of concept. I could have used a random number and chosen a random file period.
I had another look. Perhaps I'm missing something. Even if you pick a totally random file on the filesystem, the backdoor has the same aim every time. Sooner or later, it must perform a certain action that is known to and expected by the attacker, otherwise it's of no use. This means it must execute equivalent code, or alter a particular file or resource. If it must always do this, then it must have a pattern. If it scrambles itself and rewrites the algorithm each time to avoid detection, the scrambling algorithm must still exist on the computer somewhere, and can only operate in a fixed number of ways. Hence, it will still leave a pattern.
Now, like I say, I wouldn't want to understate the difficulty of detecting a trojan like this in the first place, but if you can catch it in the act once, you can discover its pattern and devise a heuristic to detect its presence. You don't even need to constantly examine the filesystem, you can rely on the kernel-level filesystem modification notifications.
However, like I say, I don't specialise in this area...
Certain things will always need the root password, and the design of all operating systems is currently lacking in how they handle such things. Protecting users from themselves appears to be an unsolved problem. However, even without root access you should still be able to cause considerable havoc using this technique, given a set of known filenames. This is one of the inherent dangers of popularity.
Mind you, there is a bit of horse-poo in that article:
Author states you can't do this in Windows. Commenters point out that yes, yes you can. Author retorts that you can't do it as easily. Easily, shmeasily. You only have to work out how to do it once.
Author states his method can be configured to be undetectable. Highly doubtful; unless it uses a vastly different algorithm every time, I could probably develop a heuristic to detect it, and I don't even specialise in this kind of thing. Of course, I will acknowledge the difficulty in detecting it the first time:)
(Alternatively, "In Soviet Russia, Joost watches YOU")
The Joost EULA allows them carte blanche to install whatever they like on your machine, and makes it a contractual violation to interfere with it, its settings or its network traffic. That doesn't seem compatible with anti-virus or firewalls (which I imagine invalidates that aspect of the contract instantly, but IANAL and I digress). They swear that they anonymise all collected viewing habit information before passing it onto advertisers, but then again, they can change the EULA, TOS and PP at will. Again, probably invalid, but IANAL.
They state quite clearly that they will be using your bandwidth to communicate with other computers running their software. Obviously, because it's a P2P app. But this isn't Skype, with a relatively small amount of traffic. This is video, distributed P2P. That's going to eat my bandwidth, and probably be dog slow to boot.
This isn't what I want. I'm not sure this is what anyone wants, at least in their target early-adopter group. Who wants ad-supported content, for which I'm paying a variable, uncontrollable amount? Give me ad-free, DRM-free, fairly priced content that I can download direct, thanks. Too much bandwidth? Well, invest in a content distribution network, or keep poking ISPs in the side until they sort out multicast.
When they do vote it is often meaningless due to gerrymandered districts. If you're a Brit the analogy would be the 'rotten burroughs' of the 18th and 19th century in Britian.
The 20th century, too. The jury's out on the 21st;) Gerrymandering continues to be a popular government hobby in the UK, too. Consider the 2005 results.
You have to remember, a lot of uses of MSDE involve local applications keeping their local data in SQL Server, rather than flat files or some custom format. This is often data that currently doesn't make sense to keep centrally.
However, I understand what you're saying about local databases, but I am dubious that the changes to US law will have any major effect. It's because of something you said:
"As a developer, you know you need to be sensitive to the needs of your customers. Developers who do things that make their job easier and their customer's jobs harder or more costly are going to find less and less business."
While the management may be serious about legal compliance, persuading the rank-and-file to be as dedicated is largely going to be a lost cause. Unless, of course, being compliant is at least as easy as being non-compliant.
The reason Excel is so widely used is precisely because it satisfies a need. It fits a niche people didn't really know existed when spreadsheets were first conceived. If you want to wean people off storing their data locally, you (I guess I mean we) have to make storing information the right way at least as easy as doing it the wrong way. And it just isn't, yet.
Slashdot Mirror
But nobody does this which is why SAAS is a bad idea for anything other than 'nice to have' uses that you could live without.
Umm, I do? Because Gmail supports IMAP, it's easy to sync your mail to local disk.
There's a huge gap somewhere in newspapers' thinking. (And actually, one in every content producers' thinking). People want free content.
There appears to be one in most content consumers' thinking, too. There is no such thing as free. Everything costs somebody, something.
TV is the perfect example of a very successful business model where the prime channels are free of charge to the end user. Advertisers pay millions to advertise on TV. There is, absolutely, categorically, beyond any shadow of a doubt, no technological impediment to why this can't happen for online news, TV, movies, music, or whatever else.
Other, you mean, than the ease of automatic filtering of online adverts? Online adverts cost a hell of lot less than TV adverts because they're too easy to avoid. This will only get worse. As technology advances and TV adverts become easier to filter out, TV advertisers will have options like increased product placement available to them (imagine little "buy now!" buttons hovering over laptops in CSI). These tricks will likely neither be possible nor desirable in text-based services like online news.
The reason it doesn't happen is narrow-minded executives who do not think creatively enough, or try hard enough. Adapt or die. End of story.
Indeed. I think the "adaption" that's been postulated elsewhere is quite possible: first, smaller news outfits die as advertising revenue on online services fails to replace lost revenue from newspapers; then, the few remaining big players get together and agree to simultaneously switch business models. Even if they don't do that, you're still left with a few large corporations controlling what news the public sees.
And while laws are not necessarily moral, the people who apply them are by definition.
Sorry, I don't see this one. You could argue that we are all moral by definition, but I don't see why those that apply the law are more likely to be so. In fact, the application of the law must be free of personal morals. Would you want a policeman who let his morals trump the dictates of the law? That only sounds good if he's applying his morals in your favour.
In any case, not to get distracted from the subject at hand, I refute that speeding, as defined by going faster than a posted limit, is needlessly endangering lives. Those limits are decided by engineers who have NOT decided on the best speed. They've applied some rules of thumb, some rules of law, and some rules of common sense to arrive at a nice round number that is more correct than not.
The engineers advise, they do not dictate. The decision on the speed limit is usually down to the local government. There are plenty of built-up, residential areas that could quite easily support speed limits 10, 20 or 30 kph faster from a pure engineering point of view. They don't because these are usually littered with parked cars and have small children playing in the street. Speeding on these streets needlessly endangers their lives.
(I don't mean to get all "think of the children" here, but road accidents are the leading cause of accidental death in young children)
Of course, it's all situational. It depends on the road, the car you're driving, the environment, the other cars on the road, whatever other hazards are around you and the weather conditions; this is why I would prefer that "reckless driving" or "not driving to the conditions" would be punished more harshly than "speeding". The problem is, that's too subjective for easy law enforcement.
However, with cameras you're no longer talking more or less. You're talking exactly, atomically, right or wrong.
You've fallen into a basic fallacy here. The speed limit is exactly that, a limit. It's not a target.
True. However, that situation should be very rare. I'm aware that in the USA some places have been tweaking the yellow-red transition time down, and that the skill and consideration of your fellow drivers is going to vary from place to place; bumper-to-bumper driving at 70+ kph is obviously going to lead to some sticky situations. But I do have to wonder sometimes what definition people are using for "stop safely".
From the extremely small sample of my own experience, I have never found myself in a situation where I was traveling so fast when a light turned yellow that I wouldn't have been able to stop safely or wouldn't have been across the intersection before the lights turned red.
I have found myself in the situation where I could have stopped safely, but I chose not to. That's a completely different thing, and if I got burned for it it would have been entirely my own fault.
...but you did a far better job of making him look foolish. Thank you :)
I wasn't going to bother replying to the above poster, but since you seem to think he validates your use of that statistic, I think I should reply to you.
You made two, separate claims in your post. One, that my use of the quoted statistic was invalid. Two, that the chance of introducing a bug in an isolated module of code (say, an About box) was vanishingly small. It was the second claim I was referring to. And I said it made you look foolish because you made that claim in a very aggressive manner. See the use of "moron".
Try not to take internet insults that seriously. I have no idea who the hell you are, and I wasn't actually trying to insult you personally. If I offended you, I apologize, but that was my way of saying you made a really stupid mistake in your use of those statistics
How about you try not to make Internet insults?. I wouldn't be the first person to observe that the impersonal nature of the Internet makes people very casual about throwing insults around.
...So 10-20 defects per 1000 lines of code is based on analyzing a lot of code, and you can expect it to be valid if you take a random sample of your program. However, you're likely to a much bigger number of defects per 1000 lines of complex code and a much smaller number of defects in simple code. That doesn't mean there will never be any bugs introduced in an About window, or a simple easter egg, in the same way that it doesn't mean that there are no democrats in South Carolina. I never tried to imply otherwise.
I accept my fault in including that statistic. I didn't mean very much by it, it was just to give people a sense of the density of defects in a typical program. Including that statistic has led people focus on that rather than the essence of what I was trying to communicate.
Just for fun I'm going to point out something else in his little example. It's only triggered if the user accesses the about box in the first place. That bug doesn't affect the program at all unless you go to the about box.
Um. Personally, I use About boxes a reasonable amount. For instance, the identify the precise version of the application that's installed.
The chances of a similar type of bug in an easter egg to affect an user is even smaller, because it would require the user to first find the Easter Egg. The chances of any other type of bug is also pretty small because, like the about window, the easter egg code doesn't typically really access or communicate with any operational part of your program.
No. I'm sorry, but you are just wrong here. If the easter egg doesn't communicate with any other operational part of the program then it wouldn't be possible to trigger it. If you can trigger it, then it must be hooked into one or another input into the program, and it can introduce a bug into that input algorithm, no matter how simple the code.
Um. I just re-read that. It makes it sound like I'd throw the devs to the lions if they disobeyed me :) Actually, I'd just tell them that they needed to fix it.
I blame my hangover.
Well, I normally get pretty good feedback from devs who've worked for me ;)
This is going to be hard to sum up succinctly, because it's not a hard-and-fast rule. You've got to look at it from the client's point of view. They're paying a professional software development organisation to craft (and that's the key word) an application for them. It's probably going to be a key part of their day-to-day processes, so they're taking it pretty seriously, and they want you to, too. It's not a question of a fragile relationship, it's about meeting the client's expectations.
Obviously not all clients are the same. Some are more laid-back, and they appreciate easter eggs for they what they are, a manifestation of the programmer's love for their job, of programming as an art. In fact, those kind of clients are happier when they see something like that. But that's them, and they're probably in the minority.
So, the first thing I'd say to a dev who wanted to put an easter egg into one of these applications is, you're being paid to be a professional software developer and to respect the desires of our clients. If you can't sublimate your art to your craft, and blow off steam in a different direction, then, yeah, maybe you shouldn't be working for this kind of organisation. It doesn't make you a bad developer, just badly suited to this kind of work.
The next thing I'd say is, consider the long-term implications of what you're doing. Like I said before, every piece of code you write risks introducing defects. I've seen quite a few people say here that they can guarantee that an easter egg can be isolated completely from the rest of the code, making it "impossible" for it to affect the main application. That's just hubris, and if you've been developing for more than a couple of years, you should know better than that.
Funny error messages, while less dangerous, don't help the long-term maintainability of the system. I'd rather have an error message that means something.
It's my responsibility to safeguard the quality of the finished product, and if there's anything wrong with it, the buck stops with me. The flip-side of that is that it's my privilege to define how we build it. I'll defend my developers if they're playing with Nerf guns when the client visits. I won't defend them if they do something I expressly asked them not to do.
I was going to post a nasty reply to him for calling me a moron, but you did a far better job of making him look foolish. Thank you :)
The reason people post these statistics is they're true and they're useful. If we're starting a project, and I've got a rough idea how many lines of code or how many hours it'll take to implement, how do I work out how much time to allocate to defect fixing? If it's a new team, and a new technology, and I don't have any historical figures to go on, all I've got is industry average figures and some careful weighting. It's either that or gut feel, and most people's gut feel is terrible.
The links you posted refer to lines of code per unit of functionality, not defects per line of code. The defect rate of a language is not the inverse of its expressive power. That's because the majority of programmer-introduced defects are from one of three sources:
These are all independent of what language you're using, and they're all just functions of time (see below). That's why defects/KLOC or defects/hr are useful metrics.
Yes, of course the language you choose affects your productivity, and probably your defect rate too; consider that the move away from C++ to Java and C# probably eliminated 80% of the memory leak defects at a stroke. Of course, that still leaves the unchecked null reference defects...grrr.
I would, however sound a note of caution about that study. It's not at all clear that their productivity measure includes defect-fixing time. Remember, code's not done until it's done and working. Over the years, I've come to believe that in the hands of a talented programmer, dynamically typed, dynamically structured, interpreted languages can be orders of magnitude more productive. The only problem is, there aren't that many programmers of that caliber. Most programmers need all the help that the compiler can give them.
When I say they're all functions of time, consider:
At my current place of employment, all the code we write belongs to the client (which is pretty much SOP in the field). Our clients sometimes do not share our sense of humour. As the technical lead, if I find it, you can be damn sure you're taking it out again. And I am looking :)
I'd discourage actual functionality easter eggs too, in most programs. The industry average is estimated to be 10-20 defects per 1000 lines of code. Every non-essential line of code you write risks introducing a bug.
Yes. Especially now that we are starting to move away from the traditional RDBMS.
Since when? I see this sentiment repeated a lot, but I don't see much evidence for it. The majority of applications are still written against an RDBMS.
Sure, Google and other high-profile Internet companies use some special-purpose databases, and their size and the frequency that they're talked about tends to distort people's perception to the point that they forget that they're talking about one company working in one specific field.
The reason that the RDBMS is still king is that the relational model is a general, mathematically founded abstract model of data that can represent any structure and which allows us to make deductions about the data based on predicate logic. Pretty much all of the pretenders to the crown (including object databases) sacrifice one or all of those elements for convenience.
According to multiple sources, the average life expectancy in the USA is 77 years (different sources differ by less than a year).
According to the National Center for Health Statistics's data from 2002, you have roughly a 75% chance of surviving to age 70, 65% chance of surviving to 75 and 52% chance of surviving to 80. In other words, between 75 and 80, your odds of surviving drop by between 2 and 3% per year. Not to be ignored. On the other hand, McCain would still have a slightly better than average chance of making it through his presidency, which could not be described as "vanishingly small". However, if you like McCain, but you don't like the idea of Palin being President, and you vote for McCain you are kind of, well, tossing a coin...
Of course, what stands in his favour is that he's a wealthy white man who, if he became Commander-in-Chief of the world's most powerful nation, would have a lot of people interested in keeping him healthy. What stands against him is he's had Stage II Malignant Melanoma. This doesn't doom him, by any measure, but he stands something like a 14% chance of recurrence, and a 9% chance of death, just going by the numbers.
Are you perhaps referring to this article from 2001 which suggests that cosmic rays (which are different from emissions from the Sun, btw) intensify the effect of CFCs?
I suggest that you first read through the resources on realclimate.org on solar forcing, where it has been extensively discussed, and if you wish to dispute their findings, then please attack the science, not the scientist.
(Incidentally, with that in mind, I would argue that a single car travelling at 55mph should not be putting anyone at serious danger if surrounded by semi-competent drivers. Consider that the maximum speed limit for a car with caravan on a UK motorway is 60mph, and many travel at 50-55. You will encounter them, and they're merely annoying, not life-threatening)
My problem is that they didn't prove that the limit was too low. If everyone obeyed the law, unjust or not, then traffic would flow perfectly well. In the strictest terms, if you're obeying the limit and that causes a speeding driver problems, well that's their problem, not yours.
All the film actually demonstrated was that driving four abreast at a slower speed than the prevailing flow blocks traffic. Congratulations Captain Obvious, have a badge.
The reason this sort of thing gets on my nerves is that when you are driving, you are surrounded by these idiots: people who think the law must be wrong because it's inconvenient for them. They are usually also appallingly unsafe drivers.
Let me just highlight three things here. I'll preface this by saying I've only ever driven in the UK and New Zealand, which have very similar road laws and approaches to teaching driving. If they teach driving differently in the US, then a couple of things I'm going to say here might not apply.
First, all of the drivers travelling at the speed limit with the correct stopping distance (IOW, the filmmakers) were making unimpeded progress and would have arrived at their destination at the fastest possible time (distance/speed).
Second, you are - or should be - taught that allowing yourself to be boxed in - like the filmmakers - on a motorway/freeway is a VERY BAD IDEA. A good driver makes space for themselves to allow them to react to trouble.
Third, excluding exit, entry and shoulder lanes, all lanes apart from the first are for PASSING. They are not for normal driving at the speed limit. If you are going as fast as the car in front of you, then you can damn well drive behind them in the same lane.
It wasn't the speed limit causing problems for other drivers, it was their poor driving.
I presume you mean "not using it by choice or out of aversion to Microsoft", as the Firefox Silverlight plugin works just fine for viewing the comic...
False comparison. An idea cannot be stolen because, when you have taken a copy of it, the creator still has the idea.
A domain is different. By definition, there is only one of each domain. Ergo, one person can posses it in its entirety, and deprive others of its possession. Hence it can be stolen.
Options are about choice. Choice is a luxury enabled by redundant resources. As the oil and coal run out, costs will rise. As costs rise, the average person will find their options being removed. In the end, they will have only two choices: conserve, or pay an ever-increasing amount for their energy. As the cost of their food will be going up at the same time, for the same reason, I'm betting they'll choose to conserve.
Other "choices" will be removed just as unceremoniously. Goods that require a lot of energy to produce will either find more efficient production methods or become uneconomic. Once they become uneconomic, they will disappear from the market. Maybe they'll be replaced with cheaper alternatives, maybe not. You will not be able to buy everything you buy today. And it just gets worse from there on.
Of course, it doesn't have to end like this, and the pressure to avoid this scenario is present and irresistible. We are pretending to talk about choosing what we should do to pull ourselves of this hole, but the truth is we have no choices; we will do what we can to maintain our lifestyles, and pretend we meant to do it all along.
Solar et al could save us. Sooner or later, we will turn to it. The problem is, it's probably "later".
So nuclear is the only way forwards. All the objections will fall away. The US will reconsider its opposition to fast breeder reactors, because it has no other choice. Political accommodations will be made, deals will be done. We'll do the best we can with the waste products, but in the end we'll decide to "cross that bridge when we come to it". Life will go on.
I still think we're in for some tough times. It takes ten years to commission a nuclear reactor, and I've heard some commentators say that it's actually taking more like twenty at the moment...
I believe the term they're thinking of is working as designed.
Um. This might sound radical, but why don't they just charge for the bandwidth we use? Not our potential usage (which is what you're talking about). I mean, I might watch a lot of video on the internet, but I'm pretty sure I don't watch 7TB a month.
You can create something undetectable for the moment in Windows. Diff between Windows and Linux is, its easier to find on Windows then it would be on Linux
Why?
Apparently you didn't look at the script ... The heuristic used was based of time as a proof of concept. I could have used a random number and chosen a random file period.
I had another look. Perhaps I'm missing something. Even if you pick a totally random file on the filesystem, the backdoor has the same aim every time. Sooner or later, it must perform a certain action that is known to and expected by the attacker, otherwise it's of no use. This means it must execute equivalent code, or alter a particular file or resource. If it must always do this, then it must have a pattern. If it scrambles itself and rewrites the algorithm each time to avoid detection, the scrambling algorithm must still exist on the computer somewhere, and can only operate in a fixed number of ways. Hence, it will still leave a pattern.
Now, like I say, I wouldn't want to understate the difficulty of detecting a trojan like this in the first place, but if you can catch it in the act once, you can discover its pattern and devise a heuristic to detect its presence. You don't even need to constantly examine the filesystem, you can rely on the kernel-level filesystem modification notifications.
However, like I say, I don't specialise in this area...
Certain things will always need the root password, and the design of all operating systems is currently lacking in how they handle such things. Protecting users from themselves appears to be an unsolved problem. However, even without root access you should still be able to cause considerable havoc using this technique, given a set of known filenames. This is one of the inherent dangers of popularity.
Mind you, there is a bit of horse-poo in that article:
(Alternatively, "In Soviet Russia, Joost watches YOU")
The Joost EULA allows them carte blanche to install whatever they like on your machine, and makes it a contractual violation to interfere with it, its settings or its network traffic. That doesn't seem compatible with anti-virus or firewalls (which I imagine invalidates that aspect of the contract instantly, but IANAL and I digress). They swear that they anonymise all collected viewing habit information before passing it onto advertisers, but then again, they can change the EULA, TOS and PP at will. Again, probably invalid, but IANAL.
They state quite clearly that they will be using your bandwidth to communicate with other computers running their software. Obviously, because it's a P2P app. But this isn't Skype, with a relatively small amount of traffic. This is video, distributed P2P. That's going to eat my bandwidth, and probably be dog slow to boot.
This isn't what I want. I'm not sure this is what anyone wants, at least in their target early-adopter group. Who wants ad-supported content, for which I'm paying a variable, uncontrollable amount? Give me ad-free, DRM-free, fairly priced content that I can download direct, thanks. Too much bandwidth? Well, invest in a content distribution network, or keep poking ISPs in the side until they sort out multicast.
Meh.
When they do vote it is often meaningless due to gerrymandered districts. If you're a Brit the analogy would be the 'rotten burroughs' of the 18th and 19th century in Britian.
The 20th century, too. The jury's out on the 21st ;) Gerrymandering continues to be a popular government hobby in the UK, too. Consider the 2005 results.
You have to remember, a lot of uses of MSDE involve local applications keeping their local data in SQL Server, rather than flat files or some custom format. This is often data that currently doesn't make sense to keep centrally.
However, I understand what you're saying about local databases, but I am dubious that the changes to US law will have any major effect. It's because of something you said:
"As a developer, you know you need to be sensitive to the needs of your customers. Developers who do things that make their job easier and their customer's jobs harder or more costly are going to find less and less business."
While the management may be serious about legal compliance, persuading the rank-and-file to be as dedicated is largely going to be a lost cause. Unless, of course, being compliant is at least as easy as being non-compliant.
The reason Excel is so widely used is precisely because it satisfies a need. It fits a niche people didn't really know existed when spreadsheets were first conceived. If you want to wean people off storing their data locally, you (I guess I mean we) have to make storing information the right way at least as easy as doing it the wrong way. And it just isn't, yet.