Sorry. I was just pointing out that there are, in fact, entities that wish to compete with telcos, contrary to (some) econ theory's predictions, which is why telcos spend a ton of money on regulatory capture to fight them.
My main point being, of course, that economic theory describes tendencies, and imperfectly at that, so treating them as if they were on par with thermodynamics leads to false conclusions.
But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is
You're still abusing a page cache as a record cache. I'm quite aware of the advantages (and disadvantages) of RESTful models. There are reasons why DBMSes do things they way they do, and browser caches do the things that they do, and why wire protocols for web browsing and databses interactions are different. As I said, I don't care how you wish to use or misuse the facilities; have fun!
I never claimed that was doable.
Oh, but it is! Just use your lovely record cache, and store your offline changes in cookies. Then when the client goes back online, your trusty Javascripty goodness merely has to check in with the server and reconcile your cookie-recorded changes. Simple, and clearly how those specs were meant to be used, just like a hash table document store (your browser cache) is a local DBMS.
Which, AFAICT, is the one and only problem solved by local storage for web apps
You seem to be having a different conversation than the one I was. Don't let me stop you, though. But if you want to continue to pick nits, have fun with that, but I'm done playing along, thanks.
First off, that's not true: HTTP/1.1 supports both partial GET requests (using the Range header) and caching partial GET requests, so it does have semantics for things not of "document" granularity, including caching them.
Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.
HTTP provides exactly record level caching, if your record is accessible by a GET request to a specific URL, or as a specified byte range of a specific URL.
Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?. In the mean time, I think most sane folks are looking forward to using client side storage.
The point being, of course, that yes, you could do that, much like you could also cook your dinner on a car engine. That doesn't mean that your car has "stove semantics".
Doesn't HTTP define a whole slew of metadata headers and specified caching behavior to specifically address this kind of thing? Why build "rich" web apps that don't leverage HTTP features that specifically address the need you are dealing with?
HTTP page caching doesn't have semantics for things not of 'document' granularity. Think database records. People want to use these things as front ends to corporate directories and whatnot, be able to futz around with them on a plane, and have them sync when they're back in touch with the mothership. HTTP doesn't try to provide anything at all close to record level caching.
Congrats on your credential. I hope it does you some good.
Apparently, it doesn't help you not make weird assumptive leaps; I have no idea why you seem to believe what you do about my knowledge of math. And not only does that have nothing to do with what I was saying, but also that you pick it up as an example to ignore what I'm saying is a complete non sequitur. One can only hope that your next degree will be in rhetoric.
Wait, are you seriously arguing that your misunderstanding of a literary/sociological critique is a valid way to misunderstand the scientific method in order to support the notion that religion should be taught in schools?
I hope you're being funny, but suspect you're not. I think your thinking is just incredibly muddled by culture war bullshit to the point that you're incapable of understanding science, postmodernism, or, really, anything in sufficient depth to make a coherent argument.
No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world.
I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?
No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world.
I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?
I know people will use PHP. I use PHP. Your inability to pay attention does not, however, say anything about how PHP is perceived. And it is true that listening to non-hacks, like people who tend to congregate here, has an influence. So go figure.If you want to play about how how dumb code-monkeys misuse a PHP feature, that's entirely your business. I'm simply pointing out that there are better ways to go about things, and that while it may make sense to still use a legacy platform, things have actually moved on. I'm not begrudging whatever business you have - have fun!
Um, no. The page also illustrates an example of short-circuit evaluation, and it might be looked at as a serving suggestion to go along with '@', but the use of '@' syntax is to suppress error notification.
No, I think I'll stick with attacking it for being a truly crappy language. I don't care that it is slow or wastes memory. If you're paying$20/month for your dance-school-business-calendar installed and customized by a local teenager, the idea of writing a web app in C is silly for efficiency is silly. Likewise, whatever the intent of @ is for, I most certainly expect people have and will abuse it in exactly the way described to "fix" problems. People endlessly bash, for instance, Perl as being write only, and there's truth to that. But there is truth to that because the language tends to encourage hard to read code. You can say that's not the intent, and you'd be right, but that doesn't matter. (Though I do still love Perl.)
I do agree that PHP is fine for toy web sites, and that people get themselves in trouble using the executable web page model because the don't know what they're doing. These things are true for the same reason: PHP is full of poorly thought out magic that allows people to get in over their head, and doesn't provide the tools to easily dig back out. I'm all for making programming more accessible, but encouraging people to foot-bullet themselves in predictable ways doesn't strike me as a good approach.
I dislike it for other reasons, but for instance Ruby on Rails is a much more solid approach, in my opinion - the path of least resistance is generally the right thing to do, once a newbie internalizes the MVC idea and a couple conceptual points the learning curve is pretty gentle, and Ruby is a pretty well constructed language that lets people grow into using more conceptually useful techniques over time without the up-front demands of learning, say, Lisp.
(While I'm chasing people off my lawn, the whole RoR mindset seems to lead people down a rabbit hole of writing dumb little DSLs -- who on earth thinks a toy language for generating CSS is a good idea? You just push yourself one more indirection layer away from what's going on and end up dinking around with yet another silly new syntax for your effort. Muppet coding at its worst.)
Oh, good lord. I didn't know about that one. Every time I think I know just how awful PHP is, I learn something like that.
I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.
I think it is a bit like penis envy. Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.
If they took the time to actually understand what makes Perl, Python or Ruby so superior, well, it is unlikely that they'd still be happy with PHP.
It can't be dumping, which is selling comparable commodities below cost. (These measurements don't make a lot of sense when we're talking software -- what is the per-unit "cost" of making an instance of software that runs on a phone? All the physical items for GPS navigation are already there, and break-even cost of development depends on how many instances of the software are produced, so per-unit costs go down when you give it away.)
And Nokia may be huge, but with strong competitors in Apple and Google, I don't think anyone (at least under US law) would call them a monopoly.
This isn't even anyone targeting Garmin and friends - this is Nokia, Google and Apple gearing up for a pretty furious brawl. I think it just qualifies as a casualty of competition. Although I'm willing to bet you that Apple is talking to at least one of the dedicated GPS players about M&A.
FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the can't quite make sense of, that looks scary, that is not on the critical path between getting files from point A to point B. So, they do what all humans do, which is go back to the lowest common denominator that is not directly related to their chosen career.
Email? Encryption? Are you fucking kidding me? I knew that was a failure when X509 was pushed. People do now want is-a-person identity verification for themselves, just for everyone else. And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security. The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is, yes, basically free and self-signed certs work just as well as that one from Verisign. But, still, this is transport, not storage, so (in the U.S., at least) the legal system intersects, and transport encryption is necessary, but not sufficient, for personal control over one's email. And this is putting aside that a rather large part of the population has migrated to web mail, where they don't even control the storage in the first place, and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.
I don't think I've seen an ecommerce shop running on port 80 in 5 or 6 years, but I'm sure there are some out there still. But this ignores that we're really not that worried about people compromising routers and whatnot (I'm not saying it hasn't happened, but that is by no stretch the most common security breach mode for Joe User). Transport encryption doesn't help you when the Chinese government targets you with a zeroday, or even when you're not paying attention on a more generic phishing attack.
I was on the Cypherpunks list back in the early 90s, and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia (dystopia?). And that reason is that a lack of crypto is not the weak link, and, as always, the problem exists between chair and keyboard, if you're prone to considering that the problem.
My view is that people want to get things done, not worry about getting things done securely. And so any time "securely" means even slightly more work, fuck it, it won't happen. And that means even really minor points of friction, because people don't even understand why they're doing these things in the first place. ("Why did my login have to time out? I still want to put things there.")
Ultimately, the right posture for someone who wishes to promote security is to make it transparent. That's not possible, of course. But we, as a culture, are used to accounting safeguards, CPAs imposing annoying multiparty checks and balances and whatnot, so it isn't impossible that this sort of thing could be pushed to consumers. I'm personally skeptical, because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that.
Thank you! See, I've been using the 1040 for my users' search needs, and boy, for the life of me, I've just never understood why they've been so pissed about it.
It doesn't matter the country - so much of "security" is simply following obeying form. A great deal of it is cargo-cult behavior. In more respectable circles, this is called "auditing", but the result is the usually (not always) same. To a great extent, the practice of security is a particularly weird form of consensus risk-spreading. A manager authorizes paying a consultancy to pay a box checker to create forms for a company to fill out, you do so. When your security fails, people review the paperwork, and if it was done well, no heads roll, insurance pays, and "lessons are learned".
The only difference in this case was that there was real accountability, but that probably only proves that Russia's capitalism is still immature.
Call it PR, or negotiation, or leverage. Fundamentally, it is the same thing at the scale Google is talking about.
Google wants something, and thinks that now is the time to discuss it. I would guess there is more going on than just this hackery. It may well be that what they want is to close down, but I can't imagine, even if they do, that that's the whole of it - they don't seem the sort of company to simply give up on such a huge market in their core markets simply because Baidu out-"competed" them (for values of competition that do include government-level lobbying).
Er... I know this is/. and all, but you should read the article before being so sure. Kerr, something of an expert on the 4th amendment, is exploring whether or not, legally speaking, a warrant is required.
Due to the way the SCOTUS wrote the governing decision, it is not at all clear.
Slashdot Mirror
Sorry. I was just pointing out that there are, in fact, entities that wish to compete with telcos, contrary to (some) econ theory's predictions, which is why telcos spend a ton of money on regulatory capture to fight them.
My main point being, of course, that economic theory describes tendencies, and imperfectly at that, so treating them as if they were on par with thermodynamics leads to false conclusions.
Which is why existing telcos spend large amounts of money trying to stop others from entering the market.
Confusing economic theory with reality causes a lot of problems. Remember the old joke:
An econ professor and a student are walking across campus. The student says, "Look! a $20 on the ground."
The professor replies, "Nonsense. If there were, someone would have picked it up!"
I suppose it is flamebait. Fair enough. Can you state that I didn't describe facts?
Is this also why China runs over unarmed people with tanks?
Of course not. But the U.S. outsources that behavior to Israel, and prefers bulldozers.
Look up the word "sarcasm" - it might come in handy some day. You can find it in the dictionary, between "muppet" and "twit".
But, since (as I stated in the next paragraph), HTTP doesn't impose any limit on what a resource is
You're still abusing a page cache as a record cache. I'm quite aware of the advantages (and disadvantages) of RESTful models. There are reasons why DBMSes do things they way they do, and browser caches do the things that they do, and why wire protocols for web browsing and databses interactions are different. As I said, I don't care how you wish to use or misuse the facilities; have fun!
I never claimed that was doable.
Oh, but it is! Just use your lovely record cache, and store your offline changes in cookies. Then when the client goes back online, your trusty Javascripty goodness merely has to check in with the server and reconcile your cookie-recorded changes. Simple, and clearly how those specs were meant to be used, just like a hash table document store (your browser cache) is a local DBMS.
Which, AFAICT, is the one and only problem solved by local storage for web apps
You seem to be having a different conversation than the one I was. Don't let me stop you, though. But if you want to continue to pick nits, have fun with that, but I'm done playing along, thanks.
First off, that's not true: HTTP/1.1 supports both partial GET requests (using the Range header) and caching partial GET requests, so it does have semantics for things not of "document" granularity, including caching them.
Well, yes, and if you want to do byte-range seeking over structured data in Javascript, be my guest. Some of us use DBMSes for a reason.
HTTP provides exactly record level caching, if your record is accessible by a GET request to a specific URL, or as a specified byte range of a specific URL.
Sigh. Let me know when you have that on/offline groupware system built on top of your browser cache done, 'kay?. In the mean time, I think most sane folks are looking forward to using client side storage.
The point being, of course, that yes, you could do that, much like you could also cook your dinner on a car engine. That doesn't mean that your car has "stove semantics".
Doesn't HTTP define a whole slew of metadata headers and specified caching behavior to specifically address this kind of thing? Why build "rich" web apps that don't leverage HTTP features that specifically address the need you are dealing with?
HTTP page caching doesn't have semantics for things not of 'document' granularity. Think database records. People want to use these things as front ends to corporate directories and whatnot, be able to futz around with them on a plane, and have them sync when they're back in touch with the mothership. HTTP doesn't try to provide anything at all close to record level caching.
Congrats on your credential. I hope it does you some good.
Apparently, it doesn't help you not make weird assumptive leaps; I have no idea why you seem to believe what you do about my knowledge of math. And not only does that have nothing to do with what I was saying, but also that you pick it up as an example to ignore what I'm saying is a complete non sequitur. One can only hope that your next degree will be in rhetoric.
Wait, are you seriously arguing that your misunderstanding of a literary/sociological critique is a valid way to misunderstand the scientific method in order to support the notion that religion should be taught in schools?
I hope you're being funny, but suspect you're not. I think your thinking is just incredibly muddled by culture war bullshit to the point that you're incapable of understanding science, postmodernism, or, really, anything in sufficient depth to make a coherent argument.
No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world. I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?
No, it is rather telling that you're attacking ruby after spending a lot of time promoting Microsoft. I don't actually care. I want more, and faster, web apps. That is not only good for me, but I think it is good for the world.
I think you are, bluntly, wrong. I can tell you how I traced a function though the generally accepted method of inserting a link to the navigation bar for a client. It involved modifying code. Now, you can tell me that I'm wrong about how it happened. But people keep telling me I'm silly for being concerned with actual outcomes. Tell me: which is it? I'm a software guy. You folks, fight it out. Not my business. But how do I not notice that certain companies seem to pay more attention to particular outcomes than others?
I know people will use PHP. I use PHP. Your inability to pay attention does not, however, say anything about how PHP is perceived. And it is true that listening to non-hacks, like people who tend to congregate here, has an influence. So go figure.If you want to play about how how dumb code-monkeys misuse a PHP feature, that's entirely your business. I'm simply pointing out that there are better ways to go about things, and that while it may make sense to still use a legacy platform, things have actually moved on. I'm not begrudging whatever business you have - have fun!
Ladies and gentleman,
A Way To Miss The Point, illustrated.
Next up, LingNoi will point out that they included no pictures in their brilliant takedown, so it wasn't illustrated.
Um, no. The page also illustrates an example of short-circuit evaluation, and it might be looked at as a serving suggestion to go along with '@', but the use of '@' syntax is to suppress error notification.
No, I think I'll stick with attacking it for being a truly crappy language. I don't care that it is slow or wastes memory. If you're paying$20/month for your dance-school-business-calendar installed and customized by a local teenager, the idea of writing a web app in C is silly for efficiency is silly. Likewise, whatever the intent of @ is for, I most certainly expect people have and will abuse it in exactly the way described to "fix" problems. People endlessly bash, for instance, Perl as being write only, and there's truth to that. But there is truth to that because the language tends to encourage hard to read code. You can say that's not the intent, and you'd be right, but that doesn't matter. (Though I do still love Perl.)
I do agree that PHP is fine for toy web sites, and that people get themselves in trouble using the executable web page model because the don't know what they're doing. These things are true for the same reason: PHP is full of poorly thought out magic that allows people to get in over their head, and doesn't provide the tools to easily dig back out. I'm all for making programming more accessible, but encouraging people to foot-bullet themselves in predictable ways doesn't strike me as a good approach.
I dislike it for other reasons, but for instance Ruby on Rails is a much more solid approach, in my opinion - the path of least resistance is generally the right thing to do, once a newbie internalizes the MVC idea and a couple conceptual points the learning curve is pretty gentle, and Ruby is a pretty well constructed language that lets people grow into using more conceptually useful techniques over time without the up-front demands of learning, say, Lisp.
(While I'm chasing people off my lawn, the whole RoR mindset seems to lead people down a rabbit hole of writing dumb little DSLs -- who on earth thinks a toy language for generating CSS is a good idea? You just push yourself one more indirection layer away from what's going on and end up dinking around with yet another silly new syntax for your effort. Muppet coding at its worst.)
Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!
Oh, good lord. I didn't know about that one. Every time I think I know just how awful PHP is, I learn something like that.
I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.
I think it is a bit like penis envy. Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.
If they took the time to actually understand what makes Perl, Python or Ruby so superior, well, it is unlikely that they'd still be happy with PHP.
Oops, you're right about the denominator; I'm an idiot. Dunno why I was thinking 23.
As for the numerator, I believe Belgium + Norway + Netherlands + Denmark, when counting in nation states, == 4.
Yes, but 4/23 =17.3% of the EU, from a nation-state perspective. Interoperability between governments' IT infrastructure matters.
It can't be dumping, which is selling comparable commodities below cost. (These measurements don't make a lot of sense when we're talking software -- what is the per-unit "cost" of making an instance of software that runs on a phone? All the physical items for GPS navigation are already there, and break-even cost of development depends on how many instances of the software are produced, so per-unit costs go down when you give it away.)
And Nokia may be huge, but with strong competitors in Apple and Google, I don't think anyone (at least under US law) would call them a monopoly.
This isn't even anyone targeting Garmin and friends - this is Nokia, Google and Apple gearing up for a pretty furious brawl. I think it just qualifies as a casualty of competition. Although I'm willing to bet you that Apple is talking to at least one of the dedicated GPS players about M&A.
It is orthogonal.
FTP is unencrypted because what people want to do is get files from point A to point B. Something as simple as scp causes them to see a warning message that the can't quite make sense of, that looks scary, that is not on the critical path between getting files from point A to point B. So, they do what all humans do, which is go back to the lowest common denominator that is not directly related to their chosen career.
Email? Encryption? Are you fucking kidding me? I knew that was a failure when X509 was pushed. People do now want is-a-person identity verification for themselves, just for everyone else. And it turns out that PGP web of trust sort of key management only works for geeks that like concerning themselves with security. The single best thing that happened to email over the last 12 or so years is admins accepting that opportunistic transport encryption is, yes, basically free and self-signed certs work just as well as that one from Verisign. But, still, this is transport, not storage, so (in the U.S., at least) the legal system intersects, and transport encryption is necessary, but not sufficient, for personal control over one's email. And this is putting aside that a rather large part of the population has migrated to web mail, where they don't even control the storage in the first place, and the service providers have obligations to state actors that are substantially less robust than storing your own damn email on your own damn disk.
I don't think I've seen an ecommerce shop running on port 80 in 5 or 6 years, but I'm sure there are some out there still. But this ignores that we're really not that worried about people compromising routers and whatnot (I'm not saying it hasn't happened, but that is by no stretch the most common security breach mode for Joe User). Transport encryption doesn't help you when the Chinese government targets you with a zeroday, or even when you're not paying attention on a more generic phishing attack.
I was on the Cypherpunks list back in the early 90s, and there is a reason why most of the predictions of the use of crypto did not pan out to create a cyber-anarcho-capitalist-utpoia (dystopia?). And that reason is that a lack of crypto is not the weak link, and, as always, the problem exists between chair and keyboard, if you're prone to considering that the problem.
My view is that people want to get things done, not worry about getting things done securely. And so any time "securely" means even slightly more work, fuck it, it won't happen. And that means even really minor points of friction, because people don't even understand why they're doing these things in the first place. ("Why did my login have to time out? I still want to put things there.")
Ultimately, the right posture for someone who wishes to promote security is to make it transparent. That's not possible, of course. But we, as a culture, are used to accounting safeguards, CPAs imposing annoying multiparty checks and balances and whatnot, so it isn't impossible that this sort of thing could be pushed to consumers. I'm personally skeptical, because the non-geek consumer has an interest in not caring and the people selling stuff have an interest in catering to that.
Thank you! See, I've been using the 1040 for my users' search needs, and boy, for the life of me, I've just never understood why they've been so pissed about it.
It doesn't matter the country - so much of "security" is simply following obeying form. A great deal of it is cargo-cult behavior. In more respectable circles, this is called "auditing", but the result is the usually (not always) same. To a great extent, the practice of security is a particularly weird form of consensus risk-spreading. A manager authorizes paying a consultancy to pay a box checker to create forms for a company to fill out, you do so. When your security fails, people review the paperwork, and if it was done well, no heads roll, insurance pays, and "lessons are learned".
The only difference in this case was that there was real accountability, but that probably only proves that Russia's capitalism is still immature.
Call it PR, or negotiation, or leverage. Fundamentally, it is the same thing at the scale Google is talking about.
Google wants something, and thinks that now is the time to discuss it. I would guess there is more going on than just this hackery. It may well be that what they want is to close down, but I can't imagine, even if they do, that that's the whole of it - they don't seem the sort of company to simply give up on such a huge market in their core markets simply because Baidu out-"competed" them (for values of competition that do include government-level lobbying).
Er... I know this is /. and all, but you should read the article before being so sure. Kerr, something of an expert on the 4th amendment, is exploring whether or not, legally speaking, a warrant is required.
Due to the way the SCOTUS wrote the governing decision, it is not at all clear.