you have to anticipate getting linked from major news sites.
Most major news sites will ask you before posting an article with a link to your site. I know this, because I've gotten asked by major news sites several times. (The exception to this rule was MSNBC, but go figure.)
Site owners budget their hardware and network capacity to handle the traffic they expect (or empirically determine). If they can afford to budget for a traffic spike of three orders of magnitude, they may do that. But the "little guys" obviously do not necessarily have the funds to do that.
With sufficient warning, the site owners might have been able to make arrangements in advance of the posting so their site could have survived.
A mirror sounds like a perfect idea, and wouldn't even suffer the artificial problems presented in the FAQ if you did it right. All you need is Apache configured to be a caching HTTP proxy and a regular web server at the same time. Using the ProxyPass and ProxyPassReverse directives, it would appear to users like any other mirror, except it'd be using HTTP caching rules to specify what can and cannot be mirrored/cached. So long as sites are using good cache-control policies, they'd never get Slashdotted...
What I really want to stress is a state may not take different values on the repetition of a single experiment.
Quantum::Entanglement takes this a step further and behaves more like you expect. The act of testing/observing the value of a variable permanently fixes its value (along with the other variables entangled with it).
It's meant to be more of a novelty than a practical example of quantum computing. There's also a Quantum::Entanglement module, allowing you to put variables in a superposition of states, do some calculations on them, and then "observe" the value of the result. The observation then causes the states of all of the other variables along the way to instantly resolve into states consistent with that observation.
See, I guess I don't consider it "buying". I would be upset if my congressman turned his back when a major employer in my area went under, causing a large number of my neighbors to lose their jobs.
Now, if my congressman were doing something intended to benefit a company at the expense of citizens he represented, I might cry "corruption," but when he's just trying to drum up business for his constituency, I don't view that as anything other than the job we elected him for.
Think about it this way: He has thousands of voters in the area he represents that work for this company. It would please those thousands if Qualcomm could secure a new source of revenue. They'd get raises and maybe some nice bonuses with which to buy a new car, do some remodeling, whatever. It has nothing to do with the company paying him off and everything to do with that senator trying to make his constituency happy.
It really saddens me when people like you have this view that every politician is by definition corrupt and working against the common citizen to only serve the interests of fat corporations. We see some evidence of crap like that today (DMCA), so I'm not saying it doesn't exist, but that doesn't mean it's fair to go off and assume that every act a congressman performs is done against the wishes of the common American.
This assertion is not based on reality. Their job is to represent their constituents, which includes people (which have a vested interest in their businesses) and businesses themselves. If businesses in their communities are doing well, the citizens there are doing well. If businesses do badly, people get laid off and the quality of life for them suffers. Try as you might, you will not be able to separate the two at this level.
Read a little history and watch a little CSPAN. A large amount of viewpoints represented in congress are put out there with the motives of the constituency behind them.
I do agree that this is a bad idea. I think it's stupid to try and force a US-specific wireless protocol on a region that clearly would be better off with a different one. But it does not surprise me in the least that a congressman is pushing for that.
His voting constituency would expect nothing less.
Is it easier to reverse-engineer an XML schema, or an unknown chunk of binary data?
It's not in Microsoft's best interests (though arguably) that they embrace the XML syntax while using a cryptic, obfuscated schema to mask the meaning of the information within the document.
What are you talking about? What do you think a senator's job IS, anyway? He's there to represent his constituents. This includes the voting citizens that make their living from companies like Qualcomm, who (not coincidentally) make a lot of CDMA-based products.
Those people would very much prefer to see their company's products used in more areas of the world. Their company makes money, and they reap the benefits as a result.
So yes, it's completely unsurprising that the senator representing these people would work to try and make that future happen.
Are you under some delusion that governments of other countries are not making political decisions designed to do what its citizens want?
XML and HTML are completely different beasts. If you're going to compare the two markup families, XML is more akin to SGML (the "parent" of HTML) than to HTML itself. To phrase another way, XML is to SGML as XHTML is to HTML.
Both XHTML and HTML are implementations atop a simplified lowest-common-denominator. XML itself is much simpler than HTML, precisely because it doesn't specify an implementation (monstrosity or otherwise).
XML can very easily allow interoperation with just about anything, provided you agree on a schema. If the schema itself is poorly designed, that's a problem with the schema, not the syntax!
I'm also not sure why you have an issue with validation. Nearly any parser has the ability to determine if the data it's parsing is valid or not. It's just that for legacy markup languages like HTML, the parsers usually are designed to work around bad markup and try to guess what the author intended. This is significantly more work than just throwing an error if the parser fails.
HTML also requires "formating". How is XML different in this regard? Are you talking about transforming XML into a more traditional markup language like HTML? If so, then yes, obviously if you're going to convert one markup language into another, you're going to need to transform it. Bear in mind, though, that CSS can be used to style XML just as easily as it styles HTML.
Proper SOAP toolsets abstract developers from XML
on
Why XML Doesn't Suck
·
· Score: 3, Insightful
If you're using the proper tools, and programming with the proper libraries, there's no reason you have to dig down into the XML in order to "write SOAP calls". I've used SOAP for a handful of tasks, and I can't tell you anything significant about how the requests are represented in XML. Developers don't necessarily need to know that. If things are breaking for you, and you're having to debug the actual XML data to figure out what's going wrong, then either your toolset is buggy or you're not using it correctly.
Is this a trick question? Maybe somebody went to a large number of companies and asked them how many intrusions they've had, and how many of those were reported to an authority or announced in a press release?
Sometimes certain vulnerabilities do not need the level of attention of prioritization that other vulnerabilities do.
Some vulnerabilities are discovered by black hats and are actively being exploited when the right people discover them. Those generally require a coding frenzy and an expensive emergency release to get a patch out that resolves the problem. Full and immediate disclosure is implied.
Other vulnerabilities are discovered by white hats that have a high probability of being discovered soon by someone else. These should require the same type of emergency patch/release and a public announcements needs to come out shortly afterward. Full disclosure is good and desirable, but perhaps it can wait a day or two, depending on the nature of the problem.
But more often than not, some vulnerabilities are discovered by white hats and do not have a significant probability of being independently discovered by black hats in the near future. If you're here to suggest that even these types of vulnerabilities need to be treated with the same level of urgency and associated cost, I'm not sure that's very realistic.
I personally think that *any* bug that has the potential to allow an intruder to break into a system or get access to information he shouldn't have is serious enough to warrant some amount of urgent work, and I agree with you that 3-4 months in these situations is hugely excessive, but not all bugs fall into this category.
Sometimes I feel like people are screaming for immediate full disclosure in situations where it really isn't all that necessary. It just adds significant additional costs on the part of the vendor (nobody's perfect) without a high likelyhood of actually preventing a malicious exploit.
I was simply trying to state that the phone company is out to make money. If a service (a directory) does not have the potential to make money, they're not generally interested in it.
Spare me the "you're obviously not from around here" crap. I know a little bit more about the phone company than you do.
And creating a usable directory means they maintain their ability to charge for its use, so it does all boil down to them wanting to keep making/make more money. If the directory becomes useless with everyone opting out, fewer people will use it and the telephone company uses a revenue stream (411 usage, telephone book advertising, etc.)
It's a balance of trying to create a usable directory (with a large percentage of subscribers being listed) and the privacy of the individual. If there were no cost to being unlisted, there would be a lot more people doing it, which reduces the value (and usefulness) of the directory. It's just a business thing.
There may be two problems here. The first is yours: your web server should not be closing the connection without delivering an HTTP response. You probably have a timeout setting somewhere that is disconnecting the HTTP client after 5 minutes. Correct this and you will probably correct your problem.
The dropped connection bit, and why this "silent rePOST" is expected and normal, is explained perfectly in Darin Fisher's last comment (5) in your bug. In the HTTP specification, a server is not required to honor a client's request for a keep-alive connection, and may close a keep-alive connection at any time after the first response is returned. Unfortunately, given the way that TCP/IP works (it's not a real-time protocol with real-time signaling), the browser cannot know if the server closed its connection in reply to its second request, or if the server closed the connection after sending its first reply and you just didn't notice until after you sent your second request.
So when the HTTP server does in fact close the connection without an HTTP response (even if this was only detected several seconds or several minutes later), the browser has to assume that the server simply doesn't want to honor HTTP keep-alives, so it retries the request on a new connection. Remember that the proper behavior here for an HTTP server is to send an HTTP response, not to simply close the connection.
The second issue might actually be a bug. If Mozilla is only trying to deal with this issue for *subsequent* requests on the same TCP connection (since those would be the only ones pre-empted by a closed connection), and the retry is occurring on a new TCP connection, that would be the first request on that connection, right? So if that failed, that should generate a real error, not a *second* retry, right?
Maybe that's why Darin asked for more information about what version of Mozilla you're using, and asked for some network trace information. They need more details like this so they can identify what exactly is going on. Please provide this to them if you can. This may be fixed in 1.3.
And IE doesn't handle this "fine" either as the earlier poster suggested. No browser does. They all invariably have a delay before the cached value is expired (5-15+ minutes or so), and this delay never seems to be based on DNS TTL values.:(
The best place I've found is probably Gateway Electronics on Page in University City. They tend to have a fairly interesting collection of hardware and HAM radio gear.
This is where companies could stand to separate roles better. For a given project, on the technical side, you need:
1. A manager (in the HR sense), who counts beans, budgets time, keeps morale up and possibly is your buffer from clients
2. A technical architect, who provides design guidance and who you go to when you have questions or concerns about integrating your project with others
3. The developers, who just need to crank out code (subject to the TA's design and the manager's prioritization).
The point is, the manager trusts his technical staff to make technical decisions. The TA trusts that his developers will do an efficient job of implementing his design, and the developers trust that the design is sound. Granted, questions should be asked so that knowledge is shared, but so long as the roles are clearly defined and honored, we shouldn't have annoying managers trying to make dumb technical decisions.
I love it when issues work out this way for me. Not all of the people I deal with are dumbasses, but one or two that frequently try to make use of this CC: trick are, and I have to take the rest of the day off when a really good issue gets resolved like this.
Unfortunately, it does tend to stop the CC: crap, even when it would continue to work in my advantage if it were continued. The only person seeing that they're a dumbass after that is me, and that's just no fun. I could CC:, but then I'm the ass that's CC:ing...
If anyone has a solution to this very interesting problem, I'd love to hear it.
The option of a "salary" versus "hourly" wage is something you negotiate with your employer. By saying, "I want an annual salary," you are saying, "I agree to do the job you hire me for in exchange for a fixed wage."
The job you're hired for is not required to have an 8-hour day and a 40-hour week just because you're salaried. It's whatever you've agreed with your employer that it should be. If your employer is abusing that agreement by changing the conditions of your job without renegotiating pay, that's an entirely different problem that you need to take up with your employer.
Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers.
Concede the likelyhood that this is due to one of two things:
1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code. 2. "other skilled Perl hackers" are not very good at reading Perl code.
Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.
In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.
Slashdot Mirror
you have to anticipate getting linked from major news sites.
Most major news sites will ask you before posting an article with a link to your site. I know this, because I've gotten asked by major news sites several times. (The exception to this rule was MSNBC, but go figure.)
Site owners budget their hardware and network capacity to handle the traffic they expect (or empirically determine). If they can afford to budget for a traffic spike of three orders of magnitude, they may do that. But the "little guys" obviously do not necessarily have the funds to do that.
With sufficient warning, the site owners might have been able to make arrangements in advance of the posting so their site could have survived.
A mirror sounds like a perfect idea, and wouldn't even suffer the artificial problems presented in the FAQ if you did it right. All you need is Apache configured to be a caching HTTP proxy and a regular web server at the same time. Using the ProxyPass and ProxyPassReverse directives, it would appear to users like any other mirror, except it'd be using HTTP caching rules to specify what can and cannot be mirrored/cached. So long as sites are using good cache-control policies, they'd never get Slashdotted...
Slashdot editors are just lazy.
What I really want to stress is a state may not take different values on the repetition of a single experiment.
Quantum::Entanglement takes this a step further and behaves more like you expect. The act of testing/observing the value of a variable permanently fixes its value (along with the other variables entangled with it).
It's meant to be more of a novelty than a practical example of quantum computing. There's also a Quantum::Entanglement module, allowing you to put variables in a superposition of states, do some calculations on them, and then "observe" the value of the result. The observation then causes the states of all of the other variables along the way to instantly resolve into states consistent with that observation.
See, I guess I don't consider it "buying". I would be upset if my congressman turned his back when a major employer in my area went under, causing a large number of my neighbors to lose their jobs.
Now, if my congressman were doing something intended to benefit a company at the expense of citizens he represented, I might cry "corruption," but when he's just trying to drum up business for his constituency, I don't view that as anything other than the job we elected him for.
Think about it this way: He has thousands of voters in the area he represents that work for this company. It would please those thousands if Qualcomm could secure a new source of revenue. They'd get raises and maybe some nice bonuses with which to buy a new car, do some remodeling, whatever. It has nothing to do with the company paying him off and everything to do with that senator trying to make his constituency happy.
It really saddens me when people like you have this view that every politician is by definition corrupt and working against the common citizen to only serve the interests of fat corporations. We see some evidence of crap like that today (DMCA), so I'm not saying it doesn't exist, but that doesn't mean it's fair to go off and assume that every act a congressman performs is done against the wishes of the common American.
Their job is government, not business growth.
This assertion is not based on reality. Their job is to represent their constituents, which includes people (which have a vested interest in their businesses) and businesses themselves. If businesses in their communities are doing well, the citizens there are doing well. If businesses do badly, people get laid off and the quality of life for them suffers. Try as you might, you will not be able to separate the two at this level.
Read a little history and watch a little CSPAN. A large amount of viewpoints represented in congress are put out there with the motives of the constituency behind them.
I do agree that this is a bad idea. I think it's stupid to try and force a US-specific wireless protocol on a region that clearly would be better off with a different one. But it does not surprise me in the least that a congressman is pushing for that.
His voting constituency would expect nothing less.
Ask yourself one question:
Is it easier to reverse-engineer an XML schema, or an unknown chunk of binary data?
It's not in Microsoft's best interests (though arguably) that they embrace the XML syntax while using a cryptic, obfuscated schema to mask the meaning of the information within the document.
Thanks for clarifying. I agree with your points completely.
What are you talking about? What do you think a senator's job IS, anyway? He's there to represent his constituents. This includes the voting citizens that make their living from companies like Qualcomm, who (not coincidentally) make a lot of CDMA-based products.
Those people would very much prefer to see their company's products used in more areas of the world. Their company makes money, and they reap the benefits as a result.
So yes, it's completely unsurprising that the senator representing these people would work to try and make that future happen.
Are you under some delusion that governments of other countries are not making political decisions designed to do what its citizens want?
XML and HTML are completely different beasts. If you're going to compare the two markup families, XML is more akin to SGML (the "parent" of HTML) than to HTML itself. To phrase another way, XML is to SGML as XHTML is to HTML.
Both XHTML and HTML are implementations atop a simplified lowest-common-denominator. XML itself is much simpler than HTML, precisely because it doesn't specify an implementation (monstrosity or otherwise).
XML can very easily allow interoperation with just about anything, provided you agree on a schema. If the schema itself is poorly designed, that's a problem with the schema, not the syntax!
I'm also not sure why you have an issue with validation. Nearly any parser has the ability to determine if the data it's parsing is valid or not. It's just that for legacy markup languages like HTML, the parsers usually are designed to work around bad markup and try to guess what the author intended. This is significantly more work than just throwing an error if the parser fails.
HTML also requires "formating". How is XML different in this regard? Are you talking about transforming XML into a more traditional markup language like HTML? If so, then yes, obviously if you're going to convert one markup language into another, you're going to need to transform it. Bear in mind, though, that CSS can be used to style XML just as easily as it styles HTML.
If you're using the proper tools, and programming with the proper libraries, there's no reason you have to dig down into the XML in order to "write SOAP calls". I've used SOAP for a handful of tasks, and I can't tell you anything significant about how the requests are represented in XML. Developers don't necessarily need to know that. If things are breaking for you, and you're having to debug the actual XML data to figure out what's going wrong, then either your toolset is buggy or you're not using it correctly.
It never ceases to amaze me how many people think XML is a language.
What do you think the L in XML stands for?
Is this a trick question? Maybe somebody went to a large number of companies and asked them how many intrusions they've had, and how many of those were reported to an authority or announced in a press release?
Anonymous polls like this aren't that uncommon.
Sometimes certain vulnerabilities do not need the level of attention of prioritization that other vulnerabilities do.
Some vulnerabilities are discovered by black hats and are actively being exploited when the right people discover them. Those generally require a coding frenzy and an expensive emergency release to get a patch out that resolves the problem. Full and immediate disclosure is implied.
Other vulnerabilities are discovered by white hats that have a high probability of being discovered soon by someone else. These should require the same type of emergency patch/release and a public announcements needs to come out shortly afterward. Full disclosure is good and desirable, but perhaps it can wait a day or two, depending on the nature of the problem.
But more often than not, some vulnerabilities are discovered by white hats and do not have a significant probability of being independently discovered by black hats in the near future. If you're here to suggest that even these types of vulnerabilities need to be treated with the same level of urgency and associated cost, I'm not sure that's very realistic.
I personally think that *any* bug that has the potential to allow an intruder to break into a system or get access to information he shouldn't have is serious enough to warrant some amount of urgent work, and I agree with you that 3-4 months in these situations is hugely excessive, but not all bugs fall into this category.
Sometimes I feel like people are screaming for immediate full disclosure in situations where it really isn't all that necessary. It just adds significant additional costs on the part of the vendor (nobody's perfect) without a high likelyhood of actually preventing a malicious exploit.
Uh, yah, whatever.
I was simply trying to state that the phone company is out to make money. If a service (a directory) does not have the potential to make money, they're not generally interested in it.
Spare me the "you're obviously not from around here" crap. I know a little bit more about the phone company than you do.
Welcome to the free market economy.
And creating a usable directory means they maintain their ability to charge for its use, so it does all boil down to them wanting to keep making/make more money. If the directory becomes useless with everyone opting out, fewer people will use it and the telephone company uses a revenue stream (411 usage, telephone book advertising, etc.)
It's a balance of trying to create a usable directory (with a large percentage of subscribers being listed) and the privacy of the individual. If there were no cost to being unlisted, there would be a lot more people doing it, which reduces the value (and usefulness) of the directory. It's just a business thing.
Dorm rooms can be tiny. It's not unreasonable at all to consider using your computer monitor as your television in this situation.
For kids too.
But no, now that I'm out of school, I much prefer them separate.
There may be two problems here. The first is yours: your web server should not be closing the connection without delivering an HTTP response. You probably have a timeout setting somewhere that is disconnecting the HTTP client after 5 minutes. Correct this and you will probably correct your problem.
The dropped connection bit, and why this "silent rePOST" is expected and normal, is explained perfectly in Darin Fisher's last comment (5) in your bug. In the HTTP specification, a server is not required to honor a client's request for a keep-alive connection, and may close a keep-alive connection at any time after the first response is returned. Unfortunately, given the way that TCP/IP works (it's not a real-time protocol with real-time signaling), the browser cannot know if the server closed its connection in reply to its second request, or if the server closed the connection after sending its first reply and you just didn't notice until after you sent your second request.
So when the HTTP server does in fact close the connection without an HTTP response (even if this was only detected several seconds or several minutes later), the browser has to assume that the server simply doesn't want to honor HTTP keep-alives, so it retries the request on a new connection. Remember that the proper behavior here for an HTTP server is to send an HTTP response, not to simply close the connection.
The second issue might actually be a bug. If Mozilla is only trying to deal with this issue for *subsequent* requests on the same TCP connection (since those would be the only ones pre-empted by a closed connection), and the retry is occurring on a new TCP connection, that would be the first request on that connection, right? So if that failed, that should generate a real error, not a *second* retry, right?
Maybe that's why Darin asked for more information about what version of Mozilla you're using, and asked for some network trace information. They need more details like this so they can identify what exactly is going on. Please provide this to them if you can. This may be fixed in 1.3.
Hey, that's my bug!
:(
And IE doesn't handle this "fine" either as the earlier poster suggested. No browser does. They all invariably have a delay before the cached value is expired (5-15+ minutes or so), and this delay never seems to be based on DNS TTL values.
So file this as a "bug" (enhancement)! Slashdot isn't Bugzilla, you know. :)
The best place I've found is probably Gateway Electronics on Page in University City. They tend to have a fairly interesting collection of hardware and HAM radio gear.
This is where companies could stand to separate roles better. For a given project, on the technical side, you need:
1. A manager (in the HR sense), who counts beans, budgets time, keeps morale up and possibly is your buffer from clients
2. A technical architect, who provides design guidance and who you go to when you have questions or concerns about integrating your project with others
3. The developers, who just need to crank out code (subject to the TA's design and the manager's prioritization).
The point is, the manager trusts his technical staff to make technical decisions. The TA trusts that his developers will do an efficient job of implementing his design, and the developers trust that the design is sound. Granted, questions should be asked so that knowledge is shared, but so long as the roles are clearly defined and honored, we shouldn't have annoying managers trying to make dumb technical decisions.
I love it when issues work out this way for me. Not all of the people I deal with are dumbasses, but one or two that frequently try to make use of this CC: trick are, and I have to take the rest of the day off when a really good issue gets resolved like this.
Unfortunately, it does tend to stop the CC: crap, even when it would continue to work in my advantage if it were continued. The only person seeing that they're a dumbass after that is me, and that's just no fun. I could CC:, but then I'm the ass that's CC:ing...
If anyone has a solution to this very interesting problem, I'd love to hear it.
What?
The option of a "salary" versus "hourly" wage is something you negotiate with your employer. By saying, "I want an annual salary," you are saying, "I agree to do the job you hire me for in exchange for a fixed wage."
The job you're hired for is not required to have an 8-hour day and a 40-hour week just because you're salaried. It's whatever you've agreed with your employer that it should be. If your employer is abusing that agreement by changing the conditions of your job without renegotiating pay, that's an entirely different problem that you need to take up with your employer.
Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers.
Concede the likelyhood that this is due to one of two things:
1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code.
2. "other skilled Perl hackers" are not very good at reading Perl code.
Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.
In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.