At $1B per year, a $19B acquisition will pay for itself never (future money being worth less than present money). Of course, since a chunk of that price was FB stock, it's a reasonable deal at the cash price I think.
I see this sort of argument a lot. "In an ideal world with well-written regulation, our lives would be better by regulating X, therefore in this world let's regulate X.", usually by people who are complaining about corruption and corporations writing regulations in their previous post.
Is it mathematically possible to write such regs? Maybe. Is it possible for the actual FCC we have to write such regs? No. It's not simple to regulate, so they'll get it wrong, just like they so recently did.
Sure, but that system was built out with national monopoly pricing (and even then, a guaranteed circuit - a "dedicated line" wasn't cheap). All I'm saying is that it gets quite expensive when you start getting the chance of congestion close to 0, and saying "customers who don't care about occasional congestion should pay a lot more for a basic utility just so we can avoid solving hard regulatory problems" seems misguided.
Cheap oversubscribed networks with occasional congestion and proper throttling are a good product. I can see the argument that "but they aren't cheap because of ISP monopolies, so force the ISPs to deliver a more costly product", but my whole point is: the FCC will never achieve that.
I am arguing against net neutrality in the way that the FCC is going about it. I'm not sure what the better answer is. Regulatory capture is IMO the biggest problem to solve for advancement in the first world.
BTW, as was pointed out, TCP simply doesn't work for voice, because the re-transmit delay is, in practice, unworkable. We're really quite sensitive to latency in voice, and substituting static for a lost packet is less noticeable and disruptive.
And it doesn't help the picture that people have been gaming the favoring of voice traffic for years, building protocols on UDP that any sane person would build on TCP simply because some ISPs blindly favor UDP traffic rather than voice specifically (or used to, when deep packet inspection was hard).
We simply don't have the right sort of networking protocols to make this work. Netflix for example really does use all available bandwidth up to it's maximum quality feed - it's optimizing for the quality of Netflix, not the quality of your network. The Right Thing, IMO, is to let each endpoint designate the priority of it's traffic (relative only to the rest of its traffic), which for TCP could be managed entirely by the home router, with nice defaults provided (and there are "gaming routers" that do an OK job of it). Letting the end user control the throttling (with any ISP participation needed) seems the best bet, but then we'd be debating the defaults on the router your ISP installs.
It not that they're the same, it's that one sort of requires the other. You really want voice traffic to "win" during peak demand, because the total bandwidth is small and the perceived effect of dropped packets is large. So now you're throttling based on rules - showing preference to one kind of traffic, and in fact showing preference to the kind the ISP sells over the kind that competes against what they sell.
With me so far? Having everything equally affected is not a good answer: you will get better service thanks to selectively throttling specific traffic. We want that. We don't want Comcast to throttle Netflix as an extortion racket.
People seem to imagine there's some simple set of rules that would achieve that goal, but so far the evidence suggests otherwise.
OK, so how precisely do you write the rules such that the ISP can't game them with "fake throttling". Again, in the recent case where Comcast was throttling Netflix they weren't breaking the rules as written. This isn't a simple engineering problem where you just have to find something that makes sense, this is like security hardening where you have to continuously correct problems as your attackers point them out. Do you believe a simple set of rules could work?
That's an orthogonal concern though. The product ISPs sell for home use isn't a guaranteed bandwidth product (those exist for business), it's an oversubscribed product. It's really much cheaper to provide an oversubscribed product, chances are you'd pay 10x for the guarantee of bandwidth.
In any case, for the world we live in, what do we do about throttling? Do we let the packets fall where they may? That would certainly be fair, but your telephone would become unusable under high congestion. I treasure my analog phone line, but since those are going away I'd sure like to hear clear voice traffic at the expense of torrents.
And what do you do about services like Netflix that (on pitiful DSL lines like mine) use all available bandwidth by design? It's the right design, I think, because it shouldn't be Netflix's job to ensure my voice call is clear. But with Netflix cramming as many packets down the pipe as possible, unaware of my voice call, someone has to do QoS throttling somewhere, and I sure as heck don't want to replace my router with Linux box just so I can learn to do that myself!
Oversubscribed always means "congested sometimes". If the ISP is doing it's job (pause for laughter) then it's not congested most of the time.
If an ISP sells a 10mb connection, they should not be the bottle neck. I repeat, the ISP should not have congestion on their networks.
If you want guaranteed bandwidth price a T3 line sometime. Guarantees are very expensive. A service that's congested 5% of the time likely costs 1/10th as much as a service that guarantees no congestion. Chances are you want the oversubscribed product, not the guaranteed bandwidth for home use.
If this is so great, explain "total prohibition of throttling". Most networks are oversubscribed, and that's OK since most users use a small portion of their allowed bandwidth. One way or another, there will be throttling. What about QoS-based throttling? Voice traffic is harmed much more by dropped packets than torrents. The ISPs sell voice service, and they sell products that compete with torrents. Doing the right thing for QoS directly serves the financial interests of the ISPs. Should we cut off our nose to spiderface? Never spiderface.
So are we going to have clear rules about what you can and can't throttle? Simple rules won't work. ISPs will be better at gaming those rules than the FCC will be at writing them. As SuperKendall posted about 4000 times the last time this came up (and still most people didn't get it): the way Comcast was throttling Netflix was perfectly OK under the last set of rules. Do you think more rules will help? There are always corner cases to exploit, because each new rule just creates new corners.
Anyhow, we know where any complex set of rules ends: the big players end up writing the rules. I'm sure the cable companies would happily give up throttling Netflix if they get in exchange the ability to bar any new players from entering the ISP business. After all, they don't have local monopolies everywhere yet, but with a high enough regulatory barrier to entry they could get there.
So, you're saying that the rules of production are axioms too. Still doesn't change what I said.
Not that it changes your conclusion, but it's an important difference in kind. Axioms are just the assumptions of the model, and you can reject certain axioms without being a hardcore skeptic who doubts logic. The latter assumption - that deduction works - is an assumption often made by solipsists who won't grant the assumption that sense data is accurate, but never think to question their other assumptions. It's great fun to poke at the solipsist position that way!
It's also a non-trivial realization: that it goes far beyond solipsism and that you can't have rationality without simply stipulating some stuff. As a philosophy prof once pointed out to me: if rationality isn't required, I'm free to make any assumptions I like, and so I'll make the assumptions required for rationality.
The problem with this is that "axiomatic system" is an inadequate caveat. You also have to blindly assume that some specific system of deduction works. In practice, specific axioms are usually chosen based on the assumption that induction works, the basic unprovable assumption underlying all of science. But it's worse than that: you can't even prove that deduction works! (It's obvious in hindsight, really.)
Any logical system simply asserts rules of deduction. Why use some particular rules of deduction over another? Worse: humanity only realized recently that no such system can be both consistent and complete. What else are we missing?
So the best you can say is that a proof is or is not correct given arbitrary axioms and rules of deduction and we can't know in the general case whether a given proof is correct! Not much of a claim, really.
I think there's great value in being able to pick out a "column" by name instead if text parsing tricks. Say I want to grab the sizes from 'ls' - better to just be able to say.size than to try to find the right offset into a string, or worse: doing everything with XML (shudder).
Well, obviously that's a mistake, and one the early noises from MS suggest they understand is a mistake. If I can write one program, and have it compile to both Metro and classic UIs, then I win. Sure, for a complex application, the usability won't be great on one of those platforms, since I will have tuned it for the other, but for simple interfaces it should Just Work.
Well, sort of the point of this style is to embrace triggers as a powerful and underused tool. I'm a big fan of powerful and underused tools, but generally there's a reason they're underused.
Pick the right tool for the job. Reactive programming seems like it makes life wonderfully easier for this very narrow set of problems. That's neat. But both trying to us it for everything and insisting that it's useless because it doesn't work for everything are mistakes. Like a power screwdriver with a U-joint attachment, some tools go from pointlessly awkward to awesomely helpful when faced with a particularly-shaped niche.
Proof is absolute, within the confines of the accepted axioms.
No, not really. Or perhaps I should say: one can never be absolutely certain that a proof is correct. Practically the flaws in the model (when the model is just math) are so small compared to likely flaws in the modeling that it's best to ignore them, but even in the abstract there is no "absolute proof".
There's not really any such thing as "provably correct logic" to begin with. A some point you just have to decide that the chance of errors across the process is low enough to go on with. I think of this as the "certainty noise floor": it's not important whether the chance of error is 0, but that the chance is really quite small, because that's the best we ever get.
There's no reason not to have 2 disjoint desktops - one cutesy and one "srs bsns". Have them both available everywhere, but make the default appropriate for the platform. If I really want Metro on a server or workstation, I can enable that feature (but for goodness sake make it go away by default). If I want a real UI on a tablet, say I've attached a keyboard, mouse, and monitor, I should be able to make that switch, but I'd want to go back to Metro for mobile use.
Oh, the concept is great, it's the implementation that's awful. Powershell pointlessly carries the legacy baggage of BAT file command syntax. Had the same concept been realized with Bash syntax, it would have been made of win and awesome.
I've had more entertainment with some MMOs writing bots than playing the actual game. I wrote a bot for Everquest 2 crafting that was great fun to write and tune (there was actually some game strategy to that goofy crafting system, so there was a neat optimization puzzle there). But you should anticipate the ban hammer when you do stuff like this - don't have any linkage between the meta-game and any game account you actually care about.
I somehow misread the headline, confusing it with the headline below it on the/. front page: "Windows 8 Metro Could Face Prosecution For 'Crimes Against Humanity'". Sadly, I was mistaken.
I have far more important things to worry about in life than some games. If Valve craters, there will be a new outlet for games (maybe we'll get lucky and there's be a move to GoG). As long as the risk-adjusted price I pay is fine, I don't see the problem.
As with everything in life, you pays your money and you takes your chances. The chances that Valve will vanish in the next few months, while I'm still heavily playing whatever game I just bought, are quite small.
Slashdot Mirror
At $1B per year, a $19B acquisition will pay for itself never (future money being worth less than present money). Of course, since a chunk of that price was FB stock, it's a reasonable deal at the cash price I think.
I see this sort of argument a lot. "In an ideal world with well-written regulation, our lives would be better by regulating X, therefore in this world let's regulate X.", usually by people who are complaining about corruption and corporations writing regulations in their previous post.
Is it mathematically possible to write such regs? Maybe. Is it possible for the actual FCC we have to write such regs? No. It's not simple to regulate, so they'll get it wrong, just like they so recently did.
Sure, but that system was built out with national monopoly pricing (and even then, a guaranteed circuit - a "dedicated line" wasn't cheap). All I'm saying is that it gets quite expensive when you start getting the chance of congestion close to 0, and saying "customers who don't care about occasional congestion should pay a lot more for a basic utility just so we can avoid solving hard regulatory problems" seems misguided.
Cheap oversubscribed networks with occasional congestion and proper throttling are a good product. I can see the argument that "but they aren't cheap because of ISP monopolies, so force the ISPs to deliver a more costly product", but my whole point is: the FCC will never achieve that.
I am arguing against net neutrality in the way that the FCC is going about it. I'm not sure what the better answer is. Regulatory capture is IMO the biggest problem to solve for advancement in the first world.
BTW, as was pointed out, TCP simply doesn't work for voice, because the re-transmit delay is, in practice, unworkable. We're really quite sensitive to latency in voice, and substituting static for a lost packet is less noticeable and disruptive.
And it doesn't help the picture that people have been gaming the favoring of voice traffic for years, building protocols on UDP that any sane person would build on TCP simply because some ISPs blindly favor UDP traffic rather than voice specifically (or used to, when deep packet inspection was hard).
We simply don't have the right sort of networking protocols to make this work. Netflix for example really does use all available bandwidth up to it's maximum quality feed - it's optimizing for the quality of Netflix, not the quality of your network. The Right Thing, IMO, is to let each endpoint designate the priority of it's traffic (relative only to the rest of its traffic), which for TCP could be managed entirely by the home router, with nice defaults provided (and there are "gaming routers" that do an OK job of it). Letting the end user control the throttling (with any ISP participation needed) seems the best bet, but then we'd be debating the defaults on the router your ISP installs.
It not that they're the same, it's that one sort of requires the other. You really want voice traffic to "win" during peak demand, because the total bandwidth is small and the perceived effect of dropped packets is large. So now you're throttling based on rules - showing preference to one kind of traffic, and in fact showing preference to the kind the ISP sells over the kind that competes against what they sell.
With me so far? Having everything equally affected is not a good answer: you will get better service thanks to selectively throttling specific traffic. We want that. We don't want Comcast to throttle Netflix as an extortion racket.
People seem to imagine there's some simple set of rules that would achieve that goal, but so far the evidence suggests otherwise.
OK, so how precisely do you write the rules such that the ISP can't game them with "fake throttling". Again, in the recent case where Comcast was throttling Netflix they weren't breaking the rules as written. This isn't a simple engineering problem where you just have to find something that makes sense, this is like security hardening where you have to continuously correct problems as your attackers point them out. Do you believe a simple set of rules could work?
That's an orthogonal concern though. The product ISPs sell for home use isn't a guaranteed bandwidth product (those exist for business), it's an oversubscribed product. It's really much cheaper to provide an oversubscribed product, chances are you'd pay 10x for the guarantee of bandwidth.
In any case, for the world we live in, what do we do about throttling? Do we let the packets fall where they may? That would certainly be fair, but your telephone would become unusable under high congestion. I treasure my analog phone line, but since those are going away I'd sure like to hear clear voice traffic at the expense of torrents.
And what do you do about services like Netflix that (on pitiful DSL lines like mine) use all available bandwidth by design? It's the right design, I think, because it shouldn't be Netflix's job to ensure my voice call is clear. But with Netflix cramming as many packets down the pipe as possible, unaware of my voice call, someone has to do QoS throttling somewhere, and I sure as heck don't want to replace my router with Linux box just so I can learn to do that myself!
"Oversubscribed" does not mean "congested".
Oversubscribed always means "congested sometimes". If the ISP is doing it's job (pause for laughter) then it's not congested most of the time.
If an ISP sells a 10mb connection, they should not be the bottle neck. I repeat, the ISP should not have congestion on their networks.
If you want guaranteed bandwidth price a T3 line sometime. Guarantees are very expensive. A service that's congested 5% of the time likely costs 1/10th as much as a service that guarantees no congestion. Chances are you want the oversubscribed product, not the guaranteed bandwidth for home use.
If this is so great, explain "total prohibition of throttling". Most networks are oversubscribed, and that's OK since most users use a small portion of their allowed bandwidth. One way or another, there will be throttling. What about QoS-based throttling? Voice traffic is harmed much more by dropped packets than torrents. The ISPs sell voice service, and they sell products that compete with torrents. Doing the right thing for QoS directly serves the financial interests of the ISPs. Should we cut off our nose to spiderface? Never spiderface.
So are we going to have clear rules about what you can and can't throttle? Simple rules won't work. ISPs will be better at gaming those rules than the FCC will be at writing them. As SuperKendall posted about 4000 times the last time this came up (and still most people didn't get it): the way Comcast was throttling Netflix was perfectly OK under the last set of rules. Do you think more rules will help? There are always corner cases to exploit, because each new rule just creates new corners.
Anyhow, we know where any complex set of rules ends: the big players end up writing the rules. I'm sure the cable companies would happily give up throttling Netflix if they get in exchange the ability to bar any new players from entering the ISP business. After all, they don't have local monopolies everywhere yet, but with a high enough regulatory barrier to entry they could get there.
So, you're saying that the rules of production are axioms too. Still doesn't change what I said.
Not that it changes your conclusion, but it's an important difference in kind. Axioms are just the assumptions of the model, and you can reject certain axioms without being a hardcore skeptic who doubts logic. The latter assumption - that deduction works - is an assumption often made by solipsists who won't grant the assumption that sense data is accurate, but never think to question their other assumptions. It's great fun to poke at the solipsist position that way!
It's also a non-trivial realization: that it goes far beyond solipsism and that you can't have rationality without simply stipulating some stuff. As a philosophy prof once pointed out to me: if rationality isn't required, I'm free to make any assumptions I like, and so I'll make the assumptions required for rationality.
The problem with this is that "axiomatic system" is an inadequate caveat. You also have to blindly assume that some specific system of deduction works. In practice, specific axioms are usually chosen based on the assumption that induction works, the basic unprovable assumption underlying all of science. But it's worse than that: you can't even prove that deduction works! (It's obvious in hindsight, really.)
Any logical system simply asserts rules of deduction. Why use some particular rules of deduction over another? Worse: humanity only realized recently that no such system can be both consistent and complete. What else are we missing?
So the best you can say is that a proof is or is not correct given arbitrary axioms and rules of deduction and we can't know in the general case whether a given proof is correct! Not much of a claim, really.
I think there's great value in being able to pick out a "column" by name instead if text parsing tricks. Say I want to grab the sizes from 'ls' - better to just be able to say .size than to try to find the right offset into a string, or worse: doing everything with XML (shudder).
I did as well. Now I always check GoG first, because Steam just gets more annoying every year, but still better that than physical media!
Well, obviously that's a mistake, and one the early noises from MS suggest they understand is a mistake. If I can write one program, and have it compile to both Metro and classic UIs, then I win. Sure, for a complex application, the usability won't be great on one of those platforms, since I will have tuned it for the other, but for simple interfaces it should Just Work.
- Triggers are kind of an anti-pattern.
Well, sort of the point of this style is to embrace triggers as a powerful and underused tool. I'm a big fan of powerful and underused tools, but generally there's a reason they're underused.
Pick the right tool for the job. Reactive programming seems like it makes life wonderfully easier for this very narrow set of problems. That's neat. But both trying to us it for everything and insisting that it's useless because it doesn't work for everything are mistakes. Like a power screwdriver with a U-joint attachment, some tools go from pointlessly awkward to awesomely helpful when faced with a particularly-shaped niche.
Proof is absolute, within the confines of the accepted axioms.
No, not really. Or perhaps I should say: one can never be absolutely certain that a proof is correct. Practically the flaws in the model (when the model is just math) are so small compared to likely flaws in the modeling that it's best to ignore them, but even in the abstract there is no "absolute proof".
There's not really any such thing as "provably correct logic" to begin with. A some point you just have to decide that the chance of errors across the process is low enough to go on with. I think of this as the "certainty noise floor": it's not important whether the chance of error is 0, but that the chance is really quite small, because that's the best we ever get.
"whallah"? Really?
There's no reason not to have 2 disjoint desktops - one cutesy and one "srs bsns". Have them both available everywhere, but make the default appropriate for the platform. If I really want Metro on a server or workstation, I can enable that feature (but for goodness sake make it go away by default). If I want a real UI on a tablet, say I've attached a keyboard, mouse, and monitor, I should be able to make that switch, but I'd want to go back to Metro for mobile use.
Oh, the concept is great, it's the implementation that's awful. Powershell pointlessly carries the legacy baggage of BAT file command syntax. Had the same concept been realized with Bash syntax, it would have been made of win and awesome.
I've had more entertainment with some MMOs writing bots than playing the actual game. I wrote a bot for Everquest 2 crafting that was great fun to write and tune (there was actually some game strategy to that goofy crafting system, so there was a neat optimization puzzle there). But you should anticipate the ban hammer when you do stuff like this - don't have any linkage between the meta-game and any game account you actually care about.
I somehow misread the headline, confusing it with the headline below it on the /. front page: "Windows 8 Metro Could Face Prosecution For 'Crimes Against Humanity'". Sadly, I was mistaken.
Ah, the "my mind's made up, don't confuse me with the facts" argument. Always nice when people are that open about it.
Do you have a right to an attorney in a constitution-free zone? Do you have any rights at all?
BUT WHAT IF THEY SHUT DOWN?*
I have far more important things to worry about in life than some games. If Valve craters, there will be a new outlet for games (maybe we'll get lucky and there's be a move to GoG). As long as the risk-adjusted price I pay is fine, I don't see the problem.
As with everything in life, you pays your money and you takes your chances. The chances that Valve will vanish in the next few months, while I'm still heavily playing whatever game I just bought, are quite small.