Without wanting to spark a debate on piracy, I don't get this response (and there's other companies that have done it too). "We're going to react the people who're downloading our movie for free by withdrawing it from the market and making it unavailable via legitimate channels, thus ensuring that any copy is pirated and the people most likely to buy it become upset and aggravated with us, incenting them to pirate it."
It's the distribution license for the MSVC7 runtimes. Some time will Google will show some of the discussion (it's been a concern in Python, too, Python 2.4 is built with MSVC7). I'm not convinced that it's a real problem, but absent a formal statement from MS and/or the approval of a qualifed copyright lawyer, I can see the desire to be conservative.
I'm afraid I don't get this kind of reasoning. Fewer vulnerabilities is more secure, right? Yes.
Further, if patches for vulnerabilites aren't released, they what good is Windows Update? (Note that you can't update *anything* except MS products via Windows Update. You think this is a coincidence?). Do you explain to your boss that yes, you aren't as secure, but if you had a patch to fix things you could deploy it quickly? If Microsoft is controlling what patches you get, when they're applied, and what the priority for fixes is, then exactly how much control over your security do you actually have? Wouldn't it be more cost effective for your boss to just fire you and outsource to Microsoft?
It's not just overconfidence, it's basic information theory. All the components for cracking the XBox are present in the XBox itself.
CSS was broken very quickly by extracting a valid key from a player. Note that this is not a "cheat" - this is a fundamental hole in this sort of DRM. The key is and must be present to play the DVD, and with the key present it can be extracted.
However, DeCSS does not rely on extracting a key - it's an algorithmic attack on CSS itself.
Note that SHOULD and SHOULD NOT are not binding behaviors in RFCs. MUST and MUST NOT are. SHOULD and SHOULD NOT are reccommended, not mandatory.
Regardless, the difference is that standard suggests one concept for back buttons/history lists, and (some) browsers choose to implement a difference concept. In many ways, the one that IE and Firefox use makes more sense. In others, the standards recommendation makes more sense. Take the recent surge in web applications for example - the need to keep state in sync between the browser and the server makes the usage of the history list more problematic.
Yes, it is. If you already have all the code to make a new request, then it's easier to reuse that than to figure out what to do in the myriad situations that a real history list can produce.
This would be true if the browser unconditionally issues a new request, which is not what it does. The logic both ways is equally complicated.
Please try and be more clear: do you know this, or are you just speculating?
I have implemented caching and history lists myself and I know for a fact that it's just as easy to implement it either way. It's not laziness.
The short answer here is that you're wrong. Theres a longer answer with more discussion, but honestly looking at this crap you spew instead of language is making me a little sick.
That is not the first specification - look at the date on the RFC. HTTP was in common use for several years before then and browsers already had common behavior.
Technically, "no-cache" doesn't mean "don't cache". That's what "no-store" is for. RFC 2616 says that clients must revalidate (not refetch) no-cached documents before using them for subsequent requests:
I should have been more clear, I believe that Opera does not revalidate no-cache documents when you hit "back". I know for a fact that some older versions didn't (or at least not always), I don't use Opera on a daily basis anymore though.
What's your basis for claiming that? I believe users who hit the back button want to see what they previously saw, and only a small minority (i.e. web developers) understand how things work well enough to expect anything different.
I regularly see users who hit the back button and expect to see a report or view refresh. The need to manually refresh these is addressed through training, of course, but the first reponse is to assume that the data is fresh.
I wouldn't consider hitting the back button to be a subsequent request, since the specification is quite clear that hitting the back button is going back in history, not showing the current state.
Well, sort of. You can quite reasonably make a claim that the back/forward buttons are not neccesarily the history lists addressed by the standard. Many people expect the back button to be a shortcut for "reload my previous page", rather than navigation in an offline history, in which case it is a new request and you'd interpert the no-cache and no-store parameters differently. It's an issue of user expectations and preferences.
Do you have any evidence of this? I'm more inclined to believe they implemented what was easier.
It's not any more difficult to implement one way than the other. It's a design decision, not laziness.
If you've had 3 hours of downtime in less than 2 years, thats not even 99.9% reliability. 3 9s is about 52 minutes of downtime per year. Of course, since you have no plans or redundencies in place for failures, your current uptime is basically luck rather than the result of expertise and planning. Note that if you'd had even 1 other machine clustered in, you could have made 99.9%, because you wouldn't have lost service while you rebuilt the mail store.
Are you talking (and I use the word loosely here) about the extension updater? This has to stay, because otherwise every single extension has to be packaged for every disto and OS's native update facility. Firefox has never auto-updated itself on Linux systems.
I am almost certain from your comments that you don't actually have much experience with measureing and detecting memory leaks. The first rule: what Windows is telling you is not true. You cannot get an accurate measure of an applications memory use using the standard Windows tools.
Firefox makes a number of design decisions to trade memory usage for performance.
The flexibility of the Firefox platform comes with a price in memory and CPU overhead. Thats another design decision which is inherent in the platform. If you want something smaller, you'll want to use a different browser.
GC won't reduce Firefoxes memory footprint. In fact, efficent GC requires signifigant memory overhead, so memory usage would actually *increase*.
All this is not to say that there's room for improvement or optimization - there always is. But you don't know what you're talking about.
The Mozilla codebase already has a reference counting mechanism that handles GC as well as any C++ GC can. What you're suggest is a) not better than nothing and b) wouldn't help.
The current standard says that "back" should always load from cache, but for a long time it didn't directly address it and a lot of browsers did various thing. IE and Netscape both send a HEAD request for to check for a new version. Opera will unconditionally load from cache. I believe that Opera will load from cache even with a page that has no-cache set, which is wrong.
Firefox, by the way, will fall back on the cache if it's unable to get the HEAD request. I'm not sure if it will correctly fall back if the HEAD succeeds but the actual request does not. IE will crap out, though.
Precisely what the "correct" behavior is, by which I mean "what the user expects" will vary from case to case, so it's hard to have a case that everyone agrees with. Netscape and IE both implemented what they thought was right, and have retained that behavior for consistencies sake even though some of the purists in the standards bodies have changed it.
No. If we consistently fired people for that hardly anyone in the world would work again. Inappropriate, unadult, immature, unprofessional behavior *that ends up being noticed and making waves* is what gets people fire.
Note that, in the US, everyone from 13-16 can watch the same stuff, but that we have a special distinction for the 1 year gap between 17 and 18. Retarded.
This is incorrect, because the things you need to implement complex JavaScript validation are actually some of the few areas where there is a well implemented standard. Unless you decide, intentionally, to make your validation only work on IE because you want to use XML data islands or modal dialogs or any of the other slews of crap. But as long as you don't do that, and there's no good reason to, all you need to implement JavaScript validation is a W3C DOM implementation. And *maybe*, if it's very complicated, which this form is not, some AJAX techniques.
It's using some retarded fucking captcha implementation using IE XML data islands instead of using one of the 40 million scripts that don't require brower support. Fuckers.
I hate this stupid shit. And I know it's not even malicious, because I've seen it happen before at government agencies. It's out and out incompetence. Although it seems that given all the other crap FEMA has fucked up lately, this won't even register to most people.
The "OMG you made us look bad" is the reason she was fired. If the exact same thing had happened but it was a shouting match in the hall or the parking lot or even the lobby, they would not have been fired.
The plethora of examples of countries with high gun ownership rates and low[er] gun crime rates
I'm curious which countries there are. Surely you aren't claiming that Afghanistan, Iraq, and Palestine have lower rates of gun-related crime than Australia?
Gecko, at least in my build of firefox, renders -moz-border-radius with an ugly unaliased curve. In the small border that matches the IE one, its nasty and jagged. By the way, you forgot to change the border-style to line - it's rendered as groove (or ridge? I forget) by default
And yeah, scrollable table bodies in IE is a mess. It's pretty easy if you can set explicit column widths, but if you want to keep the self-sizing columns then it's a ton of nasty, nasty, DHTML work. In mozilla it's trivial. I cried like a baby when I saw how easy it was, after spending several days implemented an imperfect solution for IE.
Perhaps you're only seeing what you want to see then. Porn companies were some of the first companies to release DVDs, they pushed the format over tapes before any of the traditional companies did. You could buy porn on DVD before you could get anything from Disney or New Line.
The formula traditionally goes something like this: some guy invents a new media technology. Traditional companies, being conservative, are interested but won't buy in until there's more awareness and other people buying in. Porn companies are more liberal, less worried about reputation, smaller overhead, jump right in and refine and popularize the format. The traditional media companies, seeing the viability, then buy in and push it themselves.
It's happened with photography, color photography, movies, home movies, DVD, VHS, and the Internet. Porn companies pretty much created e-commerce - they were the first ones online and they needed to take credit cards.
You can question whether or not porn was outright *responsible* for the rise of the market. But porn absolutely led the way and was there first.
I've never seen any studies about whether pornography is mainly watched by the lower economic classes, but I suspect it's bullshit and you pulled it out of your ass. For one thing, porn is *expensive*. Also, sexual interest and perversion knows no special economic barriers, and wealthy people are far more likely to indulge a whim or vice with money. There is a *vast* amount of piracy in the porn market (much more than in traditional movies or music, and yet they still manage to make billions...), and I suspect a lot of this has to do with the fact that a major consumer (not purchaser) of porn are kids in thier late and early teens. Colleges drove the initial (Internet) piracy in pretty much everything so it's unsuprising they drove porn piracy there too.
And yet, Microsofts testing procedures still suck. I know this because Windows still ships with bugs that would have been caught by basic static analysis programs, of the kind that I know for a fact Microsoft has and uses. Granted that Windows is massive, but really, they've had what, 3 years now since they announced their new dedication to security? They could have done a total code audit of the Windows source in that time, including ensuring that it passed static analysis tools. This is totally aside from classic test suites - something that I am not convinced Microsoft uses, at least not in the Windows kernel and Win32 API.
This is not entirely true. Many, many, many Windows security holes (especially the ones a few years old - low hanging fruit) are/were the kind that are especially easy to to find via automated testing. Running lint against the Windows source code would have found a signifigant number of them.
Slashdot Mirror
It's not *lots*, but there is some cool stuff involved. http://code.google.com/
Without wanting to spark a debate on piracy, I don't get this response (and there's other companies that have done it too). "We're going to react the people who're downloading our movie for free by withdrawing it from the market and making it unavailable via legitimate channels, thus ensuring that any copy is pirated and the people most likely to buy it become upset and aggravated with us, incenting them to pirate it."
*NOT* free for commercial use. This is important.
It's the distribution license for the MSVC7 runtimes. Some time will Google will show some of the discussion (it's been a concern in Python, too, Python 2.4 is built with MSVC7). I'm not convinced that it's a real problem, but absent a formal statement from MS and/or the approval of a qualifed copyright lawyer, I can see the desire to be conservative.
Further, if patches for vulnerabilites aren't released, they what good is Windows Update? (Note that you can't update *anything* except MS products via Windows Update. You think this is a coincidence?). Do you explain to your boss that yes, you aren't as secure, but if you had a patch to fix things you could deploy it quickly? If Microsoft is controlling what patches you get, when they're applied, and what the priority for fixes is, then exactly how much control over your security do you actually have? Wouldn't it be more cost effective for your boss to just fire you and outsource to Microsoft?
CSS was broken very quickly by extracting a valid key from a player. Note that this is not a "cheat" - this is a fundamental hole in this sort of DRM. The key is and must be present to play the DVD, and with the key present it can be extracted.
However, DeCSS does not rely on extracting a key - it's an algorithmic attack on CSS itself.
Regardless, the difference is that standard suggests one concept for back buttons/history lists, and (some) browsers choose to implement a difference concept. In many ways, the one that IE and Firefox use makes more sense. In others, the standards recommendation makes more sense. Take the recent surge in web applications for example - the need to keep state in sync between the browser and the server makes the usage of the history list more problematic.
Yes, it is. If you already have all the code to make a new request, then it's easier to reuse that than to figure out what to do in the myriad situations that a real history list can produce.
This would be true if the browser unconditionally issues a new request, which is not what it does. The logic both ways is equally complicated.
Please try and be more clear: do you know this, or are you just speculating?
I have implemented caching and history lists myself and I know for a fact that it's just as easy to implement it either way. It's not laziness.
The short answer here is that you're wrong. Theres a longer answer with more discussion, but honestly looking at this crap you spew instead of language is making me a little sick.
Technically, "no-cache" doesn't mean "don't cache". That's what "no-store" is for. RFC 2616 says that clients must revalidate (not refetch) no-cached documents before using them for subsequent requests:
I should have been more clear, I believe that Opera does not revalidate no-cache documents when you hit "back". I know for a fact that some older versions didn't (or at least not always), I don't use Opera on a daily basis anymore though.
What's your basis for claiming that? I believe users who hit the back button want to see what they previously saw, and only a small minority (i.e. web developers) understand how things work well enough to expect anything different.
I regularly see users who hit the back button and expect to see a report or view refresh. The need to manually refresh these is addressed through training, of course, but the first reponse is to assume that the data is fresh.
I wouldn't consider hitting the back button to be a subsequent request, since the specification is quite clear that hitting the back button is going back in history, not showing the current state.
Well, sort of. You can quite reasonably make a claim that the back/forward buttons are not neccesarily the history lists addressed by the standard. Many people expect the back button to be a shortcut for "reload my previous page", rather than navigation in an offline history, in which case it is a new request and you'd interpert the no-cache and no-store parameters differently. It's an issue of user expectations and preferences. Do you have any evidence of this? I'm more inclined to believe they implemented what was easier.
It's not any more difficult to implement one way than the other. It's a design decision, not laziness.
If you've had 3 hours of downtime in less than 2 years, thats not even 99.9% reliability. 3 9s is about 52 minutes of downtime per year. Of course, since you have no plans or redundencies in place for failures, your current uptime is basically luck rather than the result of expertise and planning. Note that if you'd had even 1 other machine clustered in, you could have made 99.9%, because you wouldn't have lost service while you rebuilt the mail store.
Are you talking (and I use the word loosely here) about the extension updater? This has to stay, because otherwise every single extension has to be packaged for every disto and OS's native update facility. Firefox has never auto-updated itself on Linux systems.
- I am almost certain from your comments that you don't actually have much experience with measureing and detecting memory leaks. The first rule: what Windows is telling you is not true. You cannot get an accurate measure of an applications memory use using the standard Windows tools.
- Firefox makes a number of design decisions to trade memory usage for performance.
- The flexibility of the Firefox platform comes with a price in memory and CPU overhead. Thats another design decision which is inherent in the platform. If you want something smaller, you'll want to use a different browser.
- GC won't reduce Firefoxes memory footprint. In fact, efficent GC requires signifigant memory overhead, so memory usage would actually *increase*.
All this is not to say that there's room for improvement or optimization - there always is. But you don't know what you're talking about.The Mozilla codebase already has a reference counting mechanism that handles GC as well as any C++ GC can. What you're suggest is a) not better than nothing and b) wouldn't help.
Firefox, by the way, will fall back on the cache if it's unable to get the HEAD request. I'm not sure if it will correctly fall back if the HEAD succeeds but the actual request does not. IE will crap out, though.
Precisely what the "correct" behavior is, by which I mean "what the user expects" will vary from case to case, so it's hard to have a case that everyone agrees with. Netscape and IE both implemented what they thought was right, and have retained that behavior for consistencies sake even though some of the purists in the standards bodies have changed it.
No. If we consistently fired people for that hardly anyone in the world would work again. Inappropriate, unadult, immature, unprofessional behavior *that ends up being noticed and making waves* is what gets people fire.
Note that, in the US, everyone from 13-16 can watch the same stuff, but that we have a special distinction for the 1 year gap between 17 and 18. Retarded.
This is incorrect, because the things you need to implement complex JavaScript validation are actually some of the few areas where there is a well implemented standard. Unless you decide, intentionally, to make your validation only work on IE because you want to use XML data islands or modal dialogs or any of the other slews of crap. But as long as you don't do that, and there's no good reason to, all you need to implement JavaScript validation is a W3C DOM implementation. And *maybe*, if it's very complicated, which this form is not, some AJAX techniques.
I hate this stupid shit. And I know it's not even malicious, because I've seen it happen before at government agencies. It's out and out incompetence. Although it seems that given all the other crap FEMA has fucked up lately, this won't even register to most people.
The "OMG you made us look bad" is the reason she was fired. If the exact same thing had happened but it was a shouting match in the hall or the parking lot or even the lobby, they would not have been fired.
I'm curious which countries there are. Surely you aren't claiming that Afghanistan, Iraq, and Palestine have lower rates of gun-related crime than Australia?
And yeah, scrollable table bodies in IE is a mess. It's pretty easy if you can set explicit column widths, but if you want to keep the self-sizing columns then it's a ton of nasty, nasty, DHTML work. In mozilla it's trivial. I cried like a baby when I saw how easy it was, after spending several days implemented an imperfect solution for IE.
The formula traditionally goes something like this: some guy invents a new media technology. Traditional companies, being conservative, are interested but won't buy in until there's more awareness and other people buying in. Porn companies are more liberal, less worried about reputation, smaller overhead, jump right in and refine and popularize the format. The traditional media companies, seeing the viability, then buy in and push it themselves.
It's happened with photography, color photography, movies, home movies, DVD, VHS, and the Internet. Porn companies pretty much created e-commerce - they were the first ones online and they needed to take credit cards.
You can question whether or not porn was outright *responsible* for the rise of the market. But porn absolutely led the way and was there first.
I've never seen any studies about whether pornography is mainly watched by the lower economic classes, but I suspect it's bullshit and you pulled it out of your ass. For one thing, porn is *expensive*. Also, sexual interest and perversion knows no special economic barriers, and wealthy people are far more likely to indulge a whim or vice with money. There is a *vast* amount of piracy in the porn market (much more than in traditional movies or music, and yet they still manage to make billions...), and I suspect a lot of this has to do with the fact that a major consumer (not purchaser) of porn are kids in thier late and early teens. Colleges drove the initial (Internet) piracy in pretty much everything so it's unsuprising they drove porn piracy there too.
And yet, Microsofts testing procedures still suck. I know this because Windows still ships with bugs that would have been caught by basic static analysis programs, of the kind that I know for a fact Microsoft has and uses. Granted that Windows is massive, but really, they've had what, 3 years now since they announced their new dedication to security? They could have done a total code audit of the Windows source in that time, including ensuring that it passed static analysis tools. This is totally aside from classic test suites - something that I am not convinced Microsoft uses, at least not in the Windows kernel and Win32 API.
This is not entirely true. Many, many, many Windows security holes (especially the ones a few years old - low hanging fruit) are/were the kind that are especially easy to to find via automated testing. Running lint against the Windows source code would have found a signifigant number of them.
Windows does not support 1TB of RAM, but *will* support a 2TB disk partition.