Maybe I don't follow this well enough to know, but I don't think Apple is doing an audit, much less line-by-line. Seems to me they just react after the fact. From what I understand they recently pulled some apps related to wifi for using undocumented APIs. If they pulled it after they fact they didn't audit the source in the first place, not even using some automated tool on the binary.
I don't have an iphone, just an ipod touch. But I don't get the impression they strictly control the app-store. They certainly impose their own restrictions, but I don't feel like it's for my benefit so I only get quality apps.
"a system used to help Google comply with search warrants" reads to me like it was something google used when notified the warrant was issued. That's not the same as law enforcement agencies/officers having access themselves which is how I read "designed to give law enforcement access to people's emails".
At least in this case, I wouldn't call it a "loophole" exploited by hackers. It's just a system they have to make it easier for them to provide information under warrant. If the information exists (and presumably it does, it sounds like they would have liked the contents of the emails), it's possible a hacker might get it, even if they don't have a "quicky warrant" front end but rely on a more manual process. Details are sketchy so who knows, but maybe this unintentionally turned out to be a form of honeypot where they got limited (subject lines, meta data, I guess whatever you must provide to LEO) information out of this system, whereas had it not been found they could have penetrated something else, perhaps better protected, but might have held even more information of value to the attackers.
That's a fair point, but I don't see mention of "use Wordpress" on Drupal's about page. Quite the opposite, they make it sound like the ordinary Joe could make whitehouse.gov. It's not a complete lie either, depending on the level of customization desired it's quite possible for someone without a lot of experience to use. But it's also quite possible you'll wind up needing a consultant. Drupal isn't immune to fanboism either. It's not so surprising that many people find it's not what they want and then tell others it wasn't what they wanted or thought they were getting.
That's an absurd thing to say and betrays your ignorance here. As far as not using the shell for day-to-day tasks, you can do that with Linux now.
Your second comment shows you clearly understood the point, so I think the first comment was... revealing.
If you want to make the argument that the CLI is never "needed" in linux, why not just go directly into that argument? Personally I was not the least bit persuaded by what you said in that regard. The assertion was that a CLI keeps home users away from linux, not that a CLI has no advantages.
Would you like to try again on refuting that? Your initial response seems to fall into the "delusional" category rather than just "fanboy".
You are confusing "censorship" and "first amendment violation". The first amendment only restricts government, not private parties, that's true. But it is still censorship when done by private parties.
I've seen (and been guilty of) implementing things for which there is already code for in core libraries. Or otherwise there is a readily available solution which is not used or used poorly. Each language out there has a large set of libraries available, either by default or a download away. This is the real difficulty in learning new languages. Mastering a language can take quite a while. It's true you can get code that "works" fairly quickly if you are familiar with another language in the same class (to use your term) as the syntax is easy.
I agree with the first part of your post. But I no longer agree on the part about picking up new (similar) languages. I used to think it was easy. I'm not sure if I've changed my mind more to my growth as a programmer or the expansiveness of modern core libraries. Maybe it's just old age:)
You generate XML for each piece of content. Multiple templates can then serve the dynamic content while the templates themselves are static. You only need to generate the content once, regardless of how many templates it appears in.
That said, I still think generating the entire pages is the way to go. Less requests should give better performance. Not to mention the other issues (search engine friendly (or other non-JS aware), proper back/foward support, less work for the browser means faster end-user experience especially for slower computers).
Although I see the point you are making, allow me to answer your questions.
1) How many went with the expensive software instead of open-source? All of them that picked Urchin obviously.
2) Wonder what exactly they're getting for thier money? I can't tell you specifically, but I don't think nothing is a good answer.
There are open source web log reporting solutions out there. The companies that went with Urchin did so for a reason. In some cases it may have been a bad reason, such as "someone to sue" or they weren't aware of the open source options. However I'm sure at least some companies went with Urchin because they felt it had useful features that weren't available in the open source alternatives.
Sure, they may be screwed now if there are bugs and they don't have the option of fixing them themselves. But there was no way of determining that was going to happen at the time. It's a risk. They might wind up in that situation, or they might wind up with web analytics that works better than the open source options.
I'm not arguing against open source, I'm just saying it's not always as black and white as you make it out to be.
I use this all the time. For example "flix clerks" will do a netflix query for me. I use this even with google and have the search engine box disabled in the UI. Because the cursor location defaults to the url area when opening a new tab/window, I find this easier (you don't get the history of search terms like with the search box though, I'm not sure that's always a bad thing).
I see a word I don't know? double-click word, copy, cntl-t, d space, paste, enter - bam, it's very quick and I only use the mouse to select the word.
premature optimisation being the root of all evil and all that
I have heard some people say that kind of thing before. I'm not sure where this comes from. Have you ever put in a lot of work to make your application 1% faster and then realized you ruined your portability? I haven't. Nor has anyone I know. Not what I would characterize as a major concern.
But most of the software industry is working at a level far higher than that, and if you are at that level and making your decisions based on what instructions the CPU is getting, then you're probably doing a worse job than somebody who is entirely ignorant of assembly.
This sounds familiar too. Knowing assembly doesn't mean you have to try to code based on the fastest possible CPU execution. Do you think people who are fluent in French are impaired in their ability to speak English on the assumption that they must somehow be thinking about French?
I can't say I think assembly knowledge is useful for the web programming I do. But I don't think it's hurting me either. It's not something I think about.
I will say that I have had problems because I didn't know enough about the details of things I was building on top of. And I've seen other people have the same kind of problems. I can't say I've ever seen a case where a programmer's ignorance of something, assembly or otherwise, was a strength allowing them better deal with higher levels of abstraction.
There is a big difference between Napster and YouTube regarding who hosts the files. Napster was unable to comply with takedown notices since they didn't host. YouTube can because they do. The ultimate outcome might be the same as with Napster anyway, but who hosts certainly has an impact on the arguments that will be made and I don't see it as being in Viacom's favor.
YouTube also has a lot of jackass-with-a-camcorder stuff on it. One of the things that hurt Napster was that almost all of the traffic was without the copyright holders permission. I'm not sure what the percentage is for YouTube, but I imagine they'll have an easier time demonstrating non infringing use.
I really don't know how to expect it to turn out, I could see either side "winning" (in court, who, if anyone, wins long term remains to be seen as well). The circumstances aren't quite the same as Napster though.
The hack extracts the title key by grabbing out of memory. It's in memory because the (software) player puts it there, at least temporarily.
If they revoke the key for that player on future discs then (that particular) software player won't be able to extract the title key, thus the hack can't access it.
In theory this should work, but not for any discs already created, only going forward. Of course all that really accomplishes is making someone have to compromise a different player, it's not exactly checkmate.
the hurdle of gaining root through user interaction limits the rate at which any exploits can spread
No, it doesn't. An exploit can spread even from a non-privileged user. It only affects spreading from one user on the machine to another user on the same machine, which is not the normal propagation mechanism.
Face it. unix's security model is different from, and superior to, that of Windows. That is what it boils down to. PCs give the bozo user rights to break the machine, Unix boxes do not.
I think that's oversimplified at best. It's true that OS X (and unix in general) provides a good mechanism to become a super user temporarily which doesn't tempt people to just do everthing as a super user. There are plenty of people who do login and do everything as root though (unix in general, not sure I know OS X users that do that). I agree those people are bozos, but they exist, and unix doesn't prevent them from being idiots.
To say that unix's security model is superior is a stretch. The unix security model is actually quite limited. Access is very coarse grained. Windows is actually superior in terms of granularity. You could even argue that part of the problem is that a non-privileged user is too restrictive in windows, thus the always login as an admin behavior. Really though windows just doesn't do enough to discourage it, it's not a fundamental flaw in capabilities as you suggest, it's just horrible attention to security at the UI layer.
Finally, "break[ing] the machine" was an important consideration in the 70s when the unix security model was developed. On a shared machine protecting the users from other users is important. On a desktop, typically with a single user, protecting the OS (which is easily reinstalled) is not as important as protecting the data of the user. OS X doesn't have a security model that prevents Joe User from hosing the important files, his own data. I'm not saying it should either, that's kind of the nature of the game.
This may have been modded down as a troll, but I think there is validity.
The parent poster says "Every reasonable person [...] already knows [...] that every OS has bugs". But being reasonable isn't sufficient, you need to both be reasonable and informed. And many people aren't informed enough to know this. Apple's marketing department isn't helping. They have a commercial, while only a metaphor, implies you don't need to worry about security if you have a mac. That kind of thing makes some people think that OS X/macs are immune to security problems.
"the security architecture of the OS, Mac OS X is a far more secure" is more of the same. It's anti-FUD or whatever you want to call it. I wish someone would explain this wonderful security architecture to me that makes OS X "far more secure". I think it's an overstatement.
I agree that Apple has a good track record both in default configuration as well as in getting bugs fixed. I think this "Month of Apple Bugs" is stupid. However this anti-FUD still pisses me off. The security practices (or lack thereof) of the USERS of machines has as much influence or more as the underlying OS. It's hard enough getting people to follow safe computing as it is, the anti-FUD is a step in the wrong direction.
Given the additional information, I have a little more to say. It reinforces my impression that you are basically on the right track, there are just no silver bullets. However I think unit testing is probably more significant for you than I assumed at first. I think jt2190 expressed the value of unit tests very well.
I also agree with jt2190 about the significance of requirement changes. This is absolutely the area where you stand to make the most gains. If your boss does not have professional software development experience him/herself than he/she almost certainly does not appreciate how severe the consequences of changes are. Even if you tell them, they won't fully get it.
The fact that your boss is the brain child is a double edged sword, but mostly positive I think. Try to push more of the testing burden on your boss. After all, it's your boss who best understands how they want it to work. Explain that he/she can't just test the part that changed, but must as least give a cursory test to everything to check for side effects. That will help reinforce the importance of avoiding changes. Assuming your boss is as busy as most bosses are, it will also increase your chances of getting a dedicated tester hired (most likely from zero to slightly non-zero if you are the only dedicated developer).
When you get a new requirement or a requirement change, question it. Make sure you understand the underlying concern that is supposed to be solved by that requirement. This is an art, I'm sure you're getting better at it already. More importantly make sure THEY understand both the concern as well as the solution they are proposing. Specifying good requirements, just like good testing, is very hard and a lot of it comes from misidentifying the problem itself. If you have a good way of producing a mockup that allows them to explore the solution hands-on without needing to invest a lot of time to create it, it will go a long way. That's tricky as there are two closely related traps: the quick-and-dirty mockup evolves to production code without adequate planning or the quick-and-dirty mockup gets thrown out entirely despite the fact that some of it was valuable.
One thing I noticed you didn't say is that you are under pressure from your boss to reduce bugs. That leads to me to believe you realize how time consuming bug fixes can be and are self-motivated to find a solution. If so, that's a good sign.
One last thing that I should have mentioned initially as it applies to almost all situations, clean up that old code. It's inevitable you'll find crufty code as you go back to things. Sometimes it started that way for whatever reason (most often time pressure), sometimes it evolved that way. Cleaning it up (also known as refactoring) pays off 95% of the time. Unit tests are perfect when you want to change the code but not the behavior.
Wow, hadn't heard of it but it definitely sounds very interesting. Will have to check it out. For anyone else who hadn't heard of it let me add two quick details: it's free (apache license according to FAQ) and it's available here.
Let me start by saying that there is no one size fits all solution. You described the nature of your projects to a degree, but not the nature of your employment.
Do you work for a company or are you a contractor? Is your responsiblity just for your code or the application as a whole (which is another way of asking how big the team is in most cases)? Are the users of the software someone close to you, you can ask them "does this do what you want" or is this going to go on the shelf in a store and you have no idea who might wind up using it?
I think these kinds of things factor into the equation. For example a number of people have suggested having dedicated testers. My guess is if you had them, you wouldn't be asking slashdot. And if you don't, it's probably not something you can make happen by yourself, though it might be a good point to bring up to your coworkers/boss.
I disagree with the Unit Testing advice that is being given out too. You should have unit tests, but it will only get you so far. Unit tests are effective at guarding against bugs being introduced when making changes, but far from sufficient to make sure there are no bugs in the entire system. In my experience the people who most heavily rely on unit tests are also the ones who produce the buggiest code. I think some of the comments make them out to be more of a panacea than they actually are, and worse yet can lead to a false sense of security.
Automation is extremely helpful. However if your issue is that " there is simply too much that could happen", it's hard to realistically automate all those paths. Presumably a problem with the things like CRUD operations are going to be tested in virtually any path through the application, which is why I don't think unit tests are necessarily what you are looking for. Still do automate everything you can, just be aware of the limitations.
My advice is as follows:
1) Keep doing what you're doing. You won't be able to catch
everything, but if you stop trying to do mimic what you think an
end user will do, you're going to miss a lot of things.
2) Write code that is likely to be bug free. Easier said than done,
but it's extremely important. Comment things, use descriptive
names, clear separation of concerns. You already know this, but
don't lose sight of it.
3) Use a logging framework. Have an error reporter for client side
apps. Write assertion checks into your code. If you try to insert a
row into the database, check the return value to see how many rows
were inserted. If you expected 1 and got something else, make sure
it's logged so you can find it later. Make sure you log as much
about the data/application state as reasonable so you can tell what
circumstances cause that problem. Make sure it's logged in such a
way that you can distinguish between serious errors like this and
as-you-go debugging output.
4) Do code reviews with other programmers. Develop best
practices. Re-evaluate them periodically to make sure they are
still "best".
5) Have a short write, compile, run cycle. Test that code as soon as
you can after writing it. If you find one of those "hmmm... I think
this should work", try to verify as soon as you can before you
forget. Don't wait until the end of the day and then conclude
"guess it worked". Test corner cases while the corner cases are
still apparent to you. If getting just created code to run is a big
pain in the ass (which could mean o
The problem with sudo (and other root/non-root separation schemes) is that they are too coarse grained to help much on the desktop. By running as a non-privledged user you can be sure that a trojan won't hose your OS. But the OS isn't the data you care about, it's easily reinstalled. All your personal data is what's really valuable and that's owned by you, thus entirely unprotected by sudo.
On a true multi-user system (by that I mean one which actually has multiple users using it regularly, not just supports multiple accounts) it provides protection from other users. However as computers have become cheaper and more ubiquitous the one user per machine scenario is more and more typical. I'm not saying sudo provides no benefit on a single user machine, I'm just saying it's a lot less important these days and some people put too much faith in it.
I'd rather see finer grained control. I'd like to have an option to restrict on a per program basis its access to various things. Access the lan only with my permission. Write to the hard drive only with my permission. "UnknownAppHaxor has requested to read from your hard drive. Yes? No? Only from the subdirectory it's installed in? Once? Always?"
I want that OPTION. But realistically, I'm just going to hit "yes to all" like everyone else unless I have a particular reason to be paranoid. Java's sandbox is pretty similar to that and applets that want to do something "special" are a big pain in the ass. There's a whole cascade of permissions they need and it's extremely tempting to just hit the "fuck it" option. Still useful sometimes at least to relatively sophisticated users or for specific circumstances. If I'm *reading* an email, that email should not trigger anything without my permission.
The firewall in SP2 is actually a step in the right direction. It's not just port based like many firewalls. The first time an application wants to connect to the internet you get prompted. It's all or nothing for the application, you can't say, for example, prompt me each unique IP it tries to connect to (worthles for a web browser, but my email client only needs to talk to the mail server). I believe ZoneAlarm allows more control.
Finer control would benefit me, but we still need a lot of user education for it to help the internet in general. That's easier said than done. An application/OS/whatever that requires that users "prove they have at least a minimal amount of clue" don't tend to very popular. In certain enviornments like a workplace you can force it on people, but there's still a lot of home machine out there that will be zombies.
When companies hold themselves out as "unbreakable" or make comments like:
For more than 27 years, Oracle has built a reputation for delivering many of the industry's most secure solutions (http://www.oracle.com/security/)
they make themselves a target.
I agree, software has bugs. But when a marketing department tries to imply company X is immune then if somebody going to get targeted, might as well be company X in my book.
That Apple ad where "PC" is sick and "Mac" is all touching PC's snotrag pissed me off. I realize Apple has a pretty good security record (way better than Oracle), but don't brag about it.
While I normally don't condone the existence of the DMCA, I'm glad it's there in cases like this, since it gives them some legal framework to exact justice.
I agree with you in part (don't like hacks, though I feel bnetd has legitimate uses), but not to this conclusion. A legal framework which can exact justice in some cases and pervert justice in others is a bad legal framework. It's ripe for abuse.
The United States of America is a country that I feel very positive about. I know there are a lot of countries where this isn't the case, but in my experience anyway with the USA in particular it's pretty simple...be square with them and they will be square with you. Nonetheless the idea that the president can waive the right to trial for anyone he, in his sole discretion, wants to is a horrible idea. If the system is setup in such a way that you just have to hope the people in power don't abuse it, it will be abused. The system must at least attempt to be fair and constrained, even if that means some shithead will sometimes get away with something.
Whether we're talking about the DMCA or the 6th amendment, the idea that laws should allow fucking everybody just to ensure you can fuck the fuckers is a bad theory. I personally don't see how the DMCA applies here, but if it does, I have a problem with that even if the outcome is one I'd like to see otherwise.
I don't see how there is any copyright or DMCA violation here. Their third claim "interfering with the contractual relationship with World of Warcraft's customers." sounds pretty weak too.
I don't think "control mouse/keyboard" is an adequate defense though. Those mouse/keyboard actions result in something happening and that isn't isolated just to the computer running wowglider. They affect what data gets sent to blizzard's servers and blizzard has a reasonable right to say effectively "you don't have a right to access our servers except under the conditions we allow".
The problem is that people CHOOSE to run this program. The software and/or company behind it doesn't interfere with the contractual relationship. The people who run wowglider intentionally violate that contract themselves.
Really though regardless of whether they might be able to stop this software from being openly sold, I don't think they will accomplish much in doing so. I definitely understand their reasons for wanting to prevent cheating, but the courtroom seems like an ineffective way of doing it.
The wowglider FAQ says that warden (their client side cheating-software detection tool) is "currently" unable to detect it. They are obviously aware of it and there is even a trial version available for free download. They can't just update warden? I realize it's a cat and mouse game, but they chose to pursue that route presumably on the belief that warden is a much more pragmatic approach to finding cheaters.
I think they would be better off spending more money on customer service reps to investigate complaints, as time consuming as that might be, rather than spending the money on lawyers. Personally I have never seen an avatar that appeared to be controlled by a bot. If I did and had a way to report them that would be followed up on, that seems like a much better approach. They need a way to stop the people using cheating programs, trying to stop people from making them via legal means seems pretty unwinnable to me.
* Easy to change the schema, don't have to convert old data.
This makes sense depending on what the alternative(s) were. How was data stored previously that didn't have an equivalent of change the schema?
* They didn't know exactly what XML was, so if I recommended it,... (a.k.a. "gee whiz" factor?)
I found this very odd. The fact that the bosses didn't know much about XML was a plus? It seems to me that's usually a minus.
* The other developers liked the idea
This itself is not a pro. The other developers must have had their reasons for liking it. What were they?
I'm not anti-XML or anything, just want more insight into how XML was helpful for you. I only understood 1/3 of the pros and even that wasn't entirely clear to me.
Slashdot Mirror
Maybe I don't follow this well enough to know, but I don't think Apple is doing an audit, much less line-by-line. Seems to me they just react after the fact. From what I understand they recently pulled some apps related to wifi for using undocumented APIs. If they pulled it after they fact they didn't audit the source in the first place, not even using some automated tool on the binary.
I don't have an iphone, just an ipod touch. But I don't get the impression they strictly control the app-store. They certainly impose their own restrictions, but I don't feel like it's for my benefit so I only get quality apps.
"a system used to help Google comply with search warrants" reads to me like it was something google used when notified the warrant was issued. That's not the same as law enforcement agencies/officers having access themselves which is how I read "designed to give law enforcement access to people's emails".
At least in this case, I wouldn't call it a "loophole" exploited by hackers. It's just a system they have to make it easier for them to provide information under warrant. If the information exists (and presumably it does, it sounds like they would have liked the contents of the emails), it's possible a hacker might get it, even if they don't have a "quicky warrant" front end but rely on a more manual process. Details are sketchy so who knows, but maybe this unintentionally turned out to be a form of honeypot where they got limited (subject lines, meta data, I guess whatever you must provide to LEO) information out of this system, whereas had it not been found they could have penetrated something else, perhaps better protected, but might have held even more information of value to the attackers.
That's a fair point, but I don't see mention of "use Wordpress" on Drupal's about page. Quite the opposite, they make it sound like the ordinary Joe could make whitehouse.gov. It's not a complete lie either, depending on the level of customization desired it's quite possible for someone without a lot of experience to use. But it's also quite possible you'll wind up needing a consultant. Drupal isn't immune to fanboism either. It's not so surprising that many people find it's not what they want and then tell others it wasn't what they wanted or thought they were getting.
That's an absurd thing to say and betrays your ignorance here. ... revealing.
As far as not using the shell for day-to-day tasks, you can do that with Linux now.
Your second comment shows you clearly understood the point, so I think the first comment was
If you want to make the argument that the CLI is never "needed" in linux, why not just go directly into that argument? Personally I was not the least bit persuaded by what you said in that regard. The assertion was that a CLI keeps home users away from linux, not that a CLI has no advantages.
Would you like to try again on refuting that? Your initial response seems to fall into the "delusional" category rather than just "fanboy".
You are confusing "censorship" and "first amendment violation". The first amendment only restricts government, not private parties, that's true. But it is still censorship when done by private parties.
I've seen (and been guilty of) implementing things for which there is already code for in core libraries. Or otherwise there is a readily available solution which is not used or used poorly. Each language out there has a large set of libraries available, either by default or a download away. This is the real difficulty in learning new languages. Mastering a language can take quite a while. It's true you can get code that "works" fairly quickly if you are familiar with another language in the same class (to use your term) as the syntax is easy.
:)
I agree with the first part of your post. But I no longer agree on the part about picking up new (similar) languages. I used to think it was easy. I'm not sure if I've changed my mind more to my growth as a programmer or the expansiveness of modern core libraries. Maybe it's just old age
Clearly it's there to keep FairPlay from being broken (too easily).
[...]
you can get around it by trapping the API call in gdb and disabling it.
If it's easy to work around (or disable) this, is it really accomplishing anything? Given its side effects it seems like a bad choice to me.
I think the answer is this:
You generate XML for each piece of content. Multiple templates can then serve the dynamic content while the templates themselves are static. You only need to generate the content once, regardless of how many templates it appears in.
That said, I still think generating the entire pages is the way to go. Less requests should give better performance. Not to mention the other issues (search engine friendly (or other non-JS aware), proper back/foward support, less work for the browser means faster end-user experience especially for slower computers).
Although I see the point you are making, allow me to answer your questions.
1) How many went with the expensive software instead of open-source? All of them that picked Urchin obviously.
2) Wonder what exactly they're getting for thier money? I can't tell you specifically, but I don't think nothing is a good answer.
There are open source web log reporting solutions out there. The companies that went with Urchin did so for a reason. In some cases it may have been a bad reason, such as "someone to sue" or they weren't aware of the open source options. However I'm sure at least some companies went with Urchin because they felt it had useful features that weren't available in the open source alternatives.
Sure, they may be screwed now if there are bugs and they don't have the option of fixing them themselves. But there was no way of determining that was going to happen at the time. It's a risk. They might wind up in that situation, or they might wind up with web analytics that works better than the open source options.
I'm not arguing against open source, I'm just saying it's not always as black and white as you make it out to be.
You can also use "%s" in conjunction with keywords which makes them even better.
bookmark keywords
I use this all the time. For example "flix clerks" will do a netflix query for me. I use this even with google and have the search engine box disabled in the UI. Because the cursor location defaults to the url area when opening a new tab/window, I find this easier (you don't get the history of search terms like with the search box though, I'm not sure that's always a bad thing).
I see a word I don't know? double-click word, copy, cntl-t, d space, paste, enter - bam, it's very quick and I only use the mouse to select the word.
Here's two links to amazon offering 6 foot HDMI cables in the $3 range from multiple vendors. Though I admit I paid about $20 for mine.
DVI gear
startech
premature optimisation being the root of all evil and all that
I have heard some people say that kind of thing before. I'm not sure where this comes from. Have you ever put in a lot of work to make your application 1% faster and then realized you ruined your portability? I haven't. Nor has anyone I know. Not what I would characterize as a major concern.
But most of the software industry is working at a level far higher than that, and if you are at that level and making your decisions based on what instructions the CPU is getting, then you're probably doing a worse job than somebody who is entirely ignorant of assembly.
This sounds familiar too. Knowing assembly doesn't mean you have to try to code based on the fastest possible CPU execution. Do you think people who are fluent in French are impaired in their ability to speak English on the assumption that they must somehow be thinking about French?
I can't say I think assembly knowledge is useful for the web programming I do. But I don't think it's hurting me either. It's not something I think about.
I will say that I have had problems because I didn't know enough about the details of things I was building on top of. And I've seen other people have the same kind of problems. I can't say I've ever seen a case where a programmer's ignorance of something, assembly or otherwise, was a strength allowing them better deal with higher levels of abstraction.
There is a big difference between Napster and YouTube regarding who hosts the files. Napster was unable to comply with takedown notices since they didn't host. YouTube can because they do. The ultimate outcome might be the same as with Napster anyway, but who hosts certainly has an impact on the arguments that will be made and I don't see it as being in Viacom's favor.
YouTube also has a lot of jackass-with-a-camcorder stuff on it. One of the things that hurt Napster was that almost all of the traffic was without the copyright holders permission. I'm not sure what the percentage is for YouTube, but I imagine they'll have an easier time demonstrating non infringing use.
I really don't know how to expect it to turn out, I could see either side "winning" (in court, who, if anyone, wins long term remains to be seen as well). The circumstances aren't quite the same as Napster though.
The hack extracts the title key by grabbing out of memory. It's in memory because the (software) player puts it there, at least temporarily.
If they revoke the key for that player on future discs then (that particular) software player won't be able to extract the title key, thus the hack can't access it.
In theory this should work, but not for any discs already created, only going forward. Of course all that really accomplishes is making someone have to compromise a different player, it's not exactly checkmate.
the hurdle of gaining root through user interaction limits the rate at which any exploits can spread
No, it doesn't. An exploit can spread even from a non-privileged user. It only affects spreading from one user on the machine to another user on the same machine, which is not the normal propagation mechanism.
Face it. unix's security model is different from, and superior to, that of Windows. That is what it boils down to. PCs give the bozo user rights to break the machine, Unix boxes do not.
I think that's oversimplified at best. It's true that OS X (and unix in general) provides a good mechanism to become a super user temporarily which doesn't tempt people to just do everthing as a super user. There are plenty of people who do login and do everything as root though (unix in general, not sure I know OS X users that do that). I agree those people are bozos, but they exist, and unix doesn't prevent them from being idiots.
To say that unix's security model is superior is a stretch. The unix security model is actually quite limited. Access is very coarse grained. Windows is actually superior in terms of granularity. You could even argue that part of the problem is that a non-privileged user is too restrictive in windows, thus the always login as an admin behavior. Really though windows just doesn't do enough to discourage it, it's not a fundamental flaw in capabilities as you suggest, it's just horrible attention to security at the UI layer.
Finally, "break[ing] the machine" was an important consideration in the 70s when the unix security model was developed. On a shared machine protecting the users from other users is important. On a desktop, typically with a single user, protecting the OS (which is easily reinstalled) is not as important as protecting the data of the user. OS X doesn't have a security model that prevents Joe User from hosing the important files, his own data. I'm not saying it should either, that's kind of the nature of the game.
This may have been modded down as a troll, but I think there is validity.
The parent poster says "Every reasonable person [...] already knows [...] that every OS has bugs". But being reasonable isn't sufficient, you need to both be reasonable and informed. And many people aren't informed enough to know this. Apple's marketing department isn't helping. They have a commercial, while only a metaphor, implies you don't need to worry about security if you have a mac. That kind of thing makes some people think that OS X/macs are immune to security problems.
"the security architecture of the OS, Mac OS X is a far more secure" is more of the same. It's anti-FUD or whatever you want to call it. I wish someone would explain this wonderful security architecture to me that makes OS X "far more secure". I think it's an overstatement.
I agree that Apple has a good track record both in default configuration as well as in getting bugs fixed. I think this "Month of Apple Bugs" is stupid. However this anti-FUD still pisses me off. The security practices (or lack thereof) of the USERS of machines has as much influence or more as the underlying OS. It's hard enough getting people to follow safe computing as it is, the anti-FUD is a step in the wrong direction.
Given the additional information, I have a little more to say. It reinforces my impression that you are basically on the right track, there are just no silver bullets. However I think unit testing is probably more significant for you than I assumed at first. I think jt2190 expressed the value of unit tests very well.
I also agree with jt2190 about the significance of requirement changes. This is absolutely the area where you stand to make the most gains. If your boss does not have professional software development experience him/herself than he/she almost certainly does not appreciate how severe the consequences of changes are. Even if you tell them, they won't fully get it.
The fact that your boss is the brain child is a double edged sword, but mostly positive I think. Try to push more of the testing burden on your boss. After all, it's your boss who best understands how they want it to work. Explain that he/she can't just test the part that changed, but must as least give a cursory test to everything to check for side effects. That will help reinforce the importance of avoiding changes. Assuming your boss is as busy as most bosses are, it will also increase your chances of getting a dedicated tester hired (most likely from zero to slightly non-zero if you are the only dedicated developer).
When you get a new requirement or a requirement change, question it. Make sure you understand the underlying concern that is supposed to be solved by that requirement. This is an art, I'm sure you're getting better at it already. More importantly make sure THEY understand both the concern as well as the solution they are proposing. Specifying good requirements, just like good testing, is very hard and a lot of it comes from misidentifying the problem itself. If you have a good way of producing a mockup that allows them to explore the solution hands-on without needing to invest a lot of time to create it, it will go a long way. That's tricky as there are two closely related traps: the quick-and-dirty mockup evolves to production code without adequate planning or the quick-and-dirty mockup gets thrown out entirely despite the fact that some of it was valuable.
One thing I noticed you didn't say is that you are under pressure from your boss to reduce bugs. That leads to me to believe you realize how time consuming bug fixes can be and are self-motivated to find a solution. If so, that's a good sign.
One last thing that I should have mentioned initially as it applies to almost all situations, clean up that old code. It's inevitable you'll find crufty code as you go back to things. Sometimes it started that way for whatever reason (most often time pressure), sometimes it evolved that way. Cleaning it up (also known as refactoring) pays off 95% of the time. Unit tests are perfect when you want to change the code but not the behavior.
Wow, hadn't heard of it but it definitely sounds very interesting. Will have to check it out. For anyone else who hadn't heard of it let me add two quick details: it's free (apache license according to FAQ) and it's available here.
Let me start by saying that there is no one size fits all
solution. You described the nature of your projects to a degree, but
not the nature of your employment.
Do you work for a company or are you a contractor? Is your
responsiblity just for your code or the application as a whole (which
is another way of asking how big the team is in most cases)? Are the
users of the software someone close to you, you can ask them "does this
do what you want" or is this going to go on the shelf in a store and
you have no idea who might wind up using it?
I think these kinds of things factor into the equation. For example a
number of people have suggested having dedicated testers. My guess is
if you had them, you wouldn't be asking slashdot. And if you don't,
it's probably not something you can make happen by yourself, though it
might be a good point to bring up to your coworkers/boss.
I disagree with the Unit Testing advice that is being given out
too. You should have unit tests, but it will only get you so far. Unit
tests are effective at guarding against bugs being introduced when
making changes, but far from sufficient to make sure there are no bugs
in the entire system. In my experience the people who most heavily
rely on unit tests are also the ones who produce the buggiest code. I
think some of the comments make them out to be more of a panacea than
they actually are, and worse yet can lead to a false sense of
security.
Automation is extremely helpful. However if your issue is that " there
is simply too much that could happen", it's hard to realistically
automate all those paths. Presumably a problem with the things like
CRUD operations are going to be tested in virtually any path through
the application, which is why I don't think unit tests are necessarily
what you are looking for. Still do automate everything you can, just
be aware of the limitations.
My advice is as follows:
1) Keep doing what you're doing. You won't be able to catch
everything, but if you stop trying to do mimic what you think an
end user will do, you're going to miss a lot of things.
2) Write code that is likely to be bug free. Easier said than done,
but it's extremely important. Comment things, use descriptive
names, clear separation of concerns. You already know this, but
don't lose sight of it.
3) Use a logging framework. Have an error reporter for client side
apps. Write assertion checks into your code. If you try to insert a
row into the database, check the return value to see how many rows
were inserted. If you expected 1 and got something else, make sure
it's logged so you can find it later. Make sure you log as much
about the data/application state as reasonable so you can tell what
circumstances cause that problem. Make sure it's logged in such a
way that you can distinguish between serious errors like this and
as-you-go debugging output.
4) Do code reviews with other programmers. Develop best
practices. Re-evaluate them periodically to make sure they are
still "best".
5) Have a short write, compile, run cycle. Test that code as soon as
you can after writing it. If you find one of those "hmmm... I think
this should work", try to verify as soon as you can before you
forget. Don't wait until the end of the day and then conclude
"guess it worked". Test corner cases while the corner cases are
still apparent to you. If getting just created code to run is a big
pain in the ass (which could mean o
The problem with sudo (and other root/non-root separation schemes) is that they are too coarse grained to help much on the desktop. By running as a non-privledged user you can be sure that a trojan won't hose your OS. But the OS isn't the data you care about, it's easily reinstalled. All your personal data is what's really valuable and that's owned by you, thus entirely unprotected by sudo.
On a true multi-user system (by that I mean one which actually has multiple users using it regularly, not just supports multiple accounts) it provides protection from other users. However as computers have become cheaper and more ubiquitous the one user per machine scenario is more and more typical. I'm not saying sudo provides no benefit on a single user machine, I'm just saying it's a lot less important these days and some people put too much faith in it.
I'd rather see finer grained control. I'd like to have an option to restrict on a per program basis its access to various things. Access the lan only with my permission. Write to the hard drive only with my permission. "UnknownAppHaxor has requested to read from your hard drive. Yes? No? Only from the subdirectory it's installed in? Once? Always?"
I want that OPTION. But realistically, I'm just going to hit "yes to all" like everyone else unless I have a particular reason to be paranoid. Java's sandbox is pretty similar to that and applets that want to do something "special" are a big pain in the ass. There's a whole cascade of permissions they need and it's extremely tempting to just hit the "fuck it" option. Still useful sometimes at least to relatively sophisticated users or for specific circumstances. If I'm *reading* an email, that email should not trigger anything without my permission.
The firewall in SP2 is actually a step in the right direction. It's not just port based like many firewalls. The first time an application wants to connect to the internet you get prompted. It's all or nothing for the application, you can't say, for example, prompt me each unique IP it tries to connect to (worthles for a web browser, but my email client only needs to talk to the mail server). I believe ZoneAlarm allows more control.
Finer control would benefit me, but we still need a lot of user education for it to help the internet in general. That's easier said than done. An application/OS/whatever that requires that users "prove they have at least a minimal amount of clue" don't tend to very popular. In certain enviornments like a workplace you can force it on people, but there's still a lot of home machine out there that will be zombies.
When companies hold themselves out as "unbreakable" or make comments like:
For more than 27 years, Oracle has built a reputation for delivering many of the industry's most secure solutions (http://www.oracle.com/security/)
they make themselves a target.
I agree, software has bugs. But when a marketing department tries to imply company X is immune then if somebody going to get targeted, might as well be company X in my book.
That Apple ad where "PC" is sick and "Mac" is all touching PC's snotrag pissed me off. I realize Apple has a pretty good security record (way better than Oracle), but don't brag about it.
While I normally don't condone the existence of the DMCA, I'm glad it's there in cases like this, since it gives them some legal framework to exact justice.
I agree with you in part (don't like hacks, though I feel bnetd has legitimate uses), but not to this conclusion. A legal framework which can exact justice in some cases and pervert justice in others is a bad legal framework. It's ripe for abuse.
The United States of America is a country that I feel very positive about. I know there are a lot of countries where this isn't the case, but in my experience anyway with the USA in particular it's pretty simple...be square with them and they will be square with you. Nonetheless the idea that the president can waive the right to trial for anyone he, in his sole discretion, wants to is a horrible idea. If the system is setup in such a way that you just have to hope the people in power don't abuse it, it will be abused. The system must at least attempt to be fair and constrained, even if that means some shithead will sometimes get away with something.
Whether we're talking about the DMCA or the 6th amendment, the idea that laws should allow fucking everybody just to ensure you can fuck the fuckers is a bad theory. I personally don't see how the DMCA applies here, but if it does, I have a problem with that even if the outcome is one I'd like to see otherwise.
I don't see how there is any copyright or DMCA violation here. Their third claim "interfering with the contractual relationship with World of Warcraft's customers." sounds pretty weak too.
I don't think "control mouse/keyboard" is an adequate defense though. Those mouse/keyboard actions result in something happening and that isn't isolated just to the computer running wowglider. They affect what data gets sent to blizzard's servers and blizzard has a reasonable right to say effectively "you don't have a right to access our servers except under the conditions we allow".
The problem is that people CHOOSE to run this program. The software and/or company behind it doesn't interfere with the contractual relationship. The people who run wowglider intentionally violate that contract themselves.
Really though regardless of whether they might be able to stop this software from being openly sold, I don't think they will accomplish much in doing so. I definitely understand their reasons for wanting to prevent cheating, but the courtroom seems like an ineffective way of doing it.
The wowglider FAQ says that warden (their client side cheating-software detection tool) is "currently" unable to detect it. They are obviously aware of it and there is even a trial version available for free download. They can't just update warden? I realize it's a cat and mouse game, but they chose to pursue that route presumably on the belief that warden is a much more pragmatic approach to finding cheaters.
I think they would be better off spending more money on customer service reps to investigate complaints, as time consuming as that might be, rather than spending the money on lawyers. Personally I have never seen an avatar that appeared to be controlled by a bot. If I did and had a way to report them that would be followed up on, that seems like a much better approach. They need a way to stop the people using cheating programs, trying to stop people from making them via legal means seems pretty unwinnable to me.
* Easy to change the schema, don't have to convert old data.
... (a.k.a. "gee whiz" factor?)
This makes sense depending on what the alternative(s) were. How was data stored previously that didn't have an equivalent of change the schema?
* They didn't know exactly what XML was, so if I recommended it,
I found this very odd. The fact that the bosses didn't know much about XML was a plus? It seems to me that's usually a minus.
* The other developers liked the idea
This itself is not a pro. The other developers must have had their reasons for liking it. What were they?
I'm not anti-XML or anything, just want more insight into how XML was helpful for you. I only understood 1/3 of the pros and even that wasn't entirely clear to me.