You're arguing too different issue. Maybe the providers ripped off the government, and maybe if they hadn't we'd have more bandwidth than we do. But we're never going to have infinite bandwidth, which is what the "all you can eat" model assumes.
So the "everybody go do something else" proposal you made was bullshit, since you yourself don't even use web streaming. It's just an excuse to justify your bandwidth hogging.
I guess what you really want is for everybody to switch to P2P access. Hot flash: most of us don't want. And why should we? Just to accommodate you? Pay your own way.
Having to wait 24 hours to watch a show is a bit of an imposition. I could live with the imposition if there were a good reason for it. But helping other people avoid paying extra for heavy bandwidth usage is not, for me, a "good reason".
You're basically arguing "As long as they're being dishonest, it doesn't matter whether they have a sustainable business model".
That's morally satisfying, but doesn't solve any problems. If a business can't sustain itself economically, it will die. The fact that the business was started with stolen money doesn't change anything.
If you think that TW should be made to pay the money back or spend it on infrastructure, go for it. But that's really a separate issue from pricing models. The whole all-you-can-eat pricing structure never made sense, and that's a fact we have to deal with, no matter how evil (and I agree that they're pretty damn evil) the big media companies are.
I've often wondered why we can't have packet meters. Too difficult to implement? Too intimidating to customers?
But tiered pricing isn't so bad if you do it right. I agree that the way cell phone providers do it sucks. But it's not the only way.
In Australia, when you hit your cap you start getting drastically throttled. That means you're pretty much limited to email and low-bandwidth web browsing. If that happens to you a lot (it wouldn't happen at all to most users) and if you care about it (I suspect most people would be content to wait until the next billing cycle before restarting their P2P software) then you call up the ISP and ask to change your plan.
Of course, overage charges are a big source of revenue to cell providers. American ISPs will certainly go the same route if we let them.
What's wrong with picking d? It just means that at peak times, when your ISP has to process more data than it has bandwidth for, everyone's transfer rate goes down. This happens until those watching streaming video get fed up with the "buffering..."
Excuse me, do you have a full-time job? I'm guessing not. Because people who do only use their home ISP connections during the peak times you mention. That's when we're home from work and want to recreate. What's a major recreational use of the Internet? Streaming media.
That's actually how I watch most broadcast TV these days. I live in an area with lousy reception, I refuse to get cable (not so much the cost as the distraction of 1000 channels of crap), and anyway watching online is much more convenient. If I can only do that at off-peak times, I can't do it at all, and my ISP service loses a lot of value to me. Why should I give that up just so a few heavy-bandwidth users can get a free ride?
I pretty much agree with you, except for the part where you blame the problem on the recent growth of streaming media. This problem has been around since commercial ISPs started appearing. Streaming media has just made the issue impossible to avoid.
Somehow geeks can't get it through their heads that providing bandwidth costs money. Back around 1992, I started to watch a talk on CSPAN about the potential of this new thing called the Internet. I tuned out when the geeks in the audience started flaming the speaker for suggesting that you should ever have to pay anything beyond a simple connection charge for unlimited bandwidth. About the same time, an online service I was subscribing to (Netcom) started morphing into an ISP — and promptly faced a rebellion from users who couldn't understand why Netcom wouldn't let them resell access.
How hard is this to understand? It's like going to an all-you-can-eat buffet and expecting to get a week's worth of food for $5. It's very funny that so many techies are devout "pure" Libertarians, yet seem unable to grasp the most basic concept of that philosophy, "There is no free lunch."
Re:Is this a responsible thing to do?
on
The Rootkit Arsenal
·
· Score: 2, Interesting
Besides, not publicizing this information amounts to security through obscurity. Nowadays, all security experts with any credibility consider obscurity to be the opposite of security, at least with respect to computer systems. If a vulnerability exists, some malware author will find it, no matter how many nooks and crannies need to be poked into. Even if there are million nooks and crannies, it's easy to automate the search!
I gotta wonder at the reliability of an author who insists on using his affiliation with a quasi-satirical religion as if it were a professional qualification!
I also find it very scary that I have to read 900 pages to become properly acquainted with just one particular kind of malware! Hmm, maybe you do need to be a Dobbshead to deal with that.
Please give all your "Informative" mod points back. I just looked at the Google App White List and Thread is most assuredly there. The irritating thing is that I started a really pointless flame war over whether Threads needed to go away without double checking your "facts".
I'm not going to repeat my arguments. Read them again. And if they're deficient, put out the deficiencies. Just saying "you're wrong" wastes both our time.
I've just realized that this whole argument is about a hypothetical. The Google white list does include Threads. Too bad.
So really, what we're arguing about is whether Google App should support every single class in the Java SE core class list. I don't even know what classes are missing from the White List. It looks pretty complete to me. To find the missing ones, I'd have to do a diff, and there doesn't seem to be a single files that lists all the official core classes. (There's a list of classes in the Javadoc, but not all of these are core.) It would be a lot of work to assemble a list from the core package list.
You do it, since you feel the Java Portability Apocalypse is at hand. Then do a diff and tell me why I should care about the missing classes. But I'm done with straw man hypotheticals like "what if they did away with System" or "what if they took up human sacrifice"?
Please. I'm expressing admiration, not nostalgia. Yeah, modern tech is cool. But let's not snicker at the accomplishments of past engineers. The fact that their creations were based on klunky old gearboxes only makes their achievements that much more impressive.
And since you mention military history: who's the most widely respected American? Probably George Washington. Why? He was the winning general in the Revolutionary War. How did he win that war? It wasn't leadership and charisma — the dude had wooden teeth. It wasn't brilliant strategy and tactics — no formal military training, and military historians agree he was mediocre at best.
Here's how he won: he worked himself brutally hard keeping an 18th century army together long enough to outlast the Brits. He kept them fed, clothed, and housed, despite lack of resources and basically no staff to help him. This with only half-assed support from one third of the country, the active hostility of another third, and total indifference from the rest.
Current U.S. generals bark an order at a subordinate, or click a few keys on a terminal, and all the things Washington worked so hard to accomplish happen as if by magic. Do you think these modern generals sneer at GW? Somehow I doubt it.
Not always, actually. The "write once, run anywhere" notion was invented after Java unsuccessful first career as a standalone embedded environment.
But yeah, portability is now a major feature of the Java platform. But portability has never been as absolute as that marketing slogan asserts. You can write a web browser that will run on any cell phone with the right kind of Java support. That same browser would be hard to run on a PC. But who wants to?
What, you say that Java ME, not regular Java? OK, try this one: a line of computer systems that I document comes with an embedded "lights-out manager" that you can use for (among other things) remote control of the system. If you're miles away (or just don't feel like going into the machine room) you can point a web browser at this thing and it will download a terminal program that allows you to access the console as if you were sitting in front of it. You can even mount your local devices (or ISO images) so they're accessible from the system. And yes, it's written in Java, so it simply doesn't matter what kind of system you have.
Now, would this terminal app run on Google App? Very much doubt it. And that has nothing to do with what classes are available. The GA cloud is just not the right place to run a graphics terminal.
The whole point of Java is that either it will work, or if it won't the compiler will at least tell you WHY it won't and WHERE you can get instructions on how to minimally refactor. Google's way the compiler just spews a bunch of "I've never heard of this class before: java.lang.System"
Please, don't overstate your case. I very much doubt that they've eliminated System. If you want to be credible, find some missing classes (haven't seen a list yet) and tell us what kind of applications won't run because of them. If these are applications that you should be able to run on Google App, then you have a good argument. But not otherwise. And if they're creaky old legacy classes that now have better alternatives, then Google has done the Java community a big favor by doing what Sun lacked the cojones to do.
Never said they were a panacea. Said they were more powerful and easier to use.
Every programming idiom has its pitfalls. It seems to me that the concurrency utilities do a lot to eliminate pitfalls based on hand-rolled thread management. Yes, there are still pitfalls that you can't get rid of without changing the way Java does threads, and there are others you can't get rid of at all. So what? It's still a significant improvement.
Hmm, I did forget about Thread objects being part of the language. But that doesn't mean they have to be part of the public API. You just fiddle with the package declarations so that programmers can't declare or instantiate Thread objects. The Thread objects still exist, but they're only accessible via the Concurrency classes.
Except this is all getting a little weird. I suspect that the real status of Thread (and the other classes missing from the "White List") is "deprecated" rather than "deleted". So you'd get a nasty warning, or maybe even a compiler error, if you tried to use them.
Most of what's wrong with FORTAN got designed in 50 years ago. Plus they're mostly part of the fundamentals of the language. Maintaining compilers that handle ancient FORTRAN design mistakes (FORTRAN was the very first high-level language, and taught all subsequent language designers a lot about how not to go about it) is one thing. Removing a class from Java is quite another. It's completely different from changing a language feature, which Sun is very very conservative about doing.
(Once had a coworker with a PhD in Physics. He was one of the few people in that field who hates FORTRAN. When I told him about the impending release of Fortran 2003, he turned green.)
And note that before you can remove an API, you have to deprecate it. That causes a warning message which tells the programmer that they need to retool. You give that a few years, then you pull the API.
Except now Sun rarely even deprecates an API. Too much blowback. And that is a formula for stagnation.
You're confusing threads (in the generic sense) with Threads (the Java data type). You can't have multithreading without threads (duh!) but you can easily dispense with Threads as part of the official API.
I'm no expert on this technology, but I do know a lot about the motivations behind the Concurrency classes. That's because I spent 2006 helping to update the Java Tutorial, and spent a lot of time getting indoctrinated by the key people involved in this stuff, including Doug Lea.
Slashdot Mirror
I really get tired of people who confuse contradiction with argument.
A packet is not the same thing as a byte. And although technically a transmitted byte should be called an octet, nobody does.
You're like the third person who has thrown this lame argument at me. Please read the other times I've responded to it.
You're arguing too different issue. Maybe the providers ripped off the government, and maybe if they hadn't we'd have more bandwidth than we do. But we're never going to have infinite bandwidth, which is what the "all you can eat" model assumes.
So the "everybody go do something else" proposal you made was bullshit, since you yourself don't even use web streaming. It's just an excuse to justify your bandwidth hogging.
I guess what you really want is for everybody to switch to P2P access. Hot flash: most of us don't want. And why should we? Just to accommodate you? Pay your own way.
Having to wait 24 hours to watch a show is a bit of an imposition. I could live with the imposition if there were a good reason for it. But helping other people avoid paying extra for heavy bandwidth usage is not, for me, a "good reason".
Didn't you just say that NBC allows P2P downloads of shows? If they don't use bittorrent (which runs on everything) what do they use?
You're basically arguing "As long as they're being dishonest, it doesn't matter whether they have a sustainable business model".
That's morally satisfying, but doesn't solve any problems. If a business can't sustain itself economically, it will die. The fact that the business was started with stolen money doesn't change anything.
If you think that TW should be made to pay the money back or spend it on infrastructure, go for it. But that's really a separate issue from pricing models. The whole all-you-can-eat pricing structure never made sense, and that's a fact we have to deal with, no matter how evil (and I agree that they're pretty damn evil) the big media companies are.
I've often wondered why we can't have packet meters. Too difficult to implement? Too intimidating to customers?
But tiered pricing isn't so bad if you do it right. I agree that the way cell phone providers do it sucks. But it's not the only way.
In Australia, when you hit your cap you start getting drastically throttled. That means you're pretty much limited to email and low-bandwidth web browsing. If that happens to you a lot (it wouldn't happen at all to most users) and if you care about it (I suspect most people would be content to wait until the next billing cycle before restarting their P2P software) then you call up the ISP and ask to change your plan.
Of course, overage charges are a big source of revenue to cell providers. American ISPs will certainly go the same route if we let them.
What's wrong with picking d? It just means that at peak times, when your ISP has to process more data than it has bandwidth for, everyone's transfer rate goes down. This happens until those watching streaming video get fed up with the "buffering..."
Excuse me, do you have a full-time job? I'm guessing not. Because people who do only use their home ISP connections during the peak times you mention. That's when we're home from work and want to recreate. What's a major recreational use of the Internet? Streaming media.
That's actually how I watch most broadcast TV these days. I live in an area with lousy reception, I refuse to get cable (not so much the cost as the distraction of 1000 channels of crap), and anyway watching online is much more convenient. If I can only do that at off-peak times, I can't do it at all, and my ISP service loses a lot of value to me. Why should I give that up just so a few heavy-bandwidth users can get a free ride?
I pretty much agree with you, except for the part where you blame the problem on the recent growth of streaming media. This problem has been around since commercial ISPs started appearing. Streaming media has just made the issue impossible to avoid.
Somehow geeks can't get it through their heads that providing bandwidth costs money. Back around 1992, I started to watch a talk on CSPAN about the potential of this new thing called the Internet. I tuned out when the geeks in the audience started flaming the speaker for suggesting that you should ever have to pay anything beyond a simple connection charge for unlimited bandwidth. About the same time, an online service I was subscribing to (Netcom) started morphing into an ISP — and promptly faced a rebellion from users who couldn't understand why Netcom wouldn't let them resell access.
How hard is this to understand? It's like going to an all-you-can-eat buffet and expecting to get a week's worth of food for $5. It's very funny that so many techies are devout "pure" Libertarians, yet seem unable to grasp the most basic concept of that philosophy, "There is no free lunch."
Besides, not publicizing this information amounts to security through obscurity. Nowadays, all security experts with any credibility consider obscurity to be the opposite of security, at least with respect to computer systems. If a vulnerability exists, some malware author will find it, no matter how many nooks and crannies need to be poked into. Even if there are million nooks and crannies, it's easy to automate the search!
I gotta wonder at the reliability of an author who insists on using his affiliation with a quasi-satirical religion as if it were a professional qualification!
I also find it very scary that I have to read 900 pages to become properly acquainted with just one particular kind of malware! Hmm, maybe you do need to be a Dobbshead to deal with that.
Please give all your "Informative" mod points back. I just looked at the Google App White List and Thread is most assuredly there. The irritating thing is that I started a really pointless flame war over whether Threads needed to go away without double checking your "facts".
I'm not going to repeat my arguments. Read them again. And if they're deficient, put out the deficiencies. Just saying "you're wrong" wastes both our time.
I've just realized that this whole argument is about a hypothetical. The Google white list does include Threads. Too bad.
So really, what we're arguing about is whether Google App should support every single class in the Java SE core class list. I don't even know what classes are missing from the White List. It looks pretty complete to me. To find the missing ones, I'd have to do a diff, and there doesn't seem to be a single files that lists all the official core classes. (There's a list of classes in the Javadoc, but not all of these are core.) It would be a lot of work to assemble a list from the core package list.
You do it, since you feel the Java Portability Apocalypse is at hand. Then do a diff and tell me why I should care about the missing classes. But I'm done with straw man hypotheticals like "what if they did away with System" or "what if they took up human sacrifice"?
I think we need a shorthand phrase to answer people who confuse contradiction with argument. I propose "Monty Python!"
Please. I'm expressing admiration, not nostalgia. Yeah, modern tech is cool. But let's not snicker at the accomplishments of past engineers. The fact that their creations were based on klunky old gearboxes only makes their achievements that much more impressive.
And since you mention military history: who's the most widely respected American? Probably George Washington. Why? He was the winning general in the Revolutionary War. How did he win that war? It wasn't leadership and charisma — the dude had wooden teeth. It wasn't brilliant strategy and tactics — no formal military training, and military historians agree he was mediocre at best.
Here's how he won: he worked himself brutally hard keeping an 18th century army together long enough to outlast the Brits. He kept them fed, clothed, and housed, despite lack of resources and basically no staff to help him. This with only half-assed support from one third of the country, the active hostility of another third, and total indifference from the rest.
Current U.S. generals bark an order at a subordinate, or click a few keys on a terminal, and all the things Washington worked so hard to accomplish happen as if by magic. Do you think these modern generals sneer at GW? Somehow I doubt it.
OK, those are good arguments for keeping a system around for 20 years. But "if it ain't broke" is not.
And if they sacrificed kittens in the basement to the Great God Baal, that would be even more uncool. But they haven't done either.
Java was always intened to be portable.
Not always, actually. The "write once, run anywhere" notion was invented after Java unsuccessful first career as a standalone embedded environment.
But yeah, portability is now a major feature of the Java platform. But portability has never been as absolute as that marketing slogan asserts. You can write a web browser that will run on any cell phone with the right kind of Java support. That same browser would be hard to run on a PC. But who wants to?
What, you say that Java ME, not regular Java? OK, try this one: a line of computer systems that I document comes with an embedded "lights-out manager" that you can use for (among other things) remote control of the system. If you're miles away (or just don't feel like going into the machine room) you can point a web browser at this thing and it will download a terminal program that allows you to access the console as if you were sitting in front of it. You can even mount your local devices (or ISO images) so they're accessible from the system. And yes, it's written in Java, so it simply doesn't matter what kind of system you have.
Now, would this terminal app run on Google App? Very much doubt it. And that has nothing to do with what classes are available. The GA cloud is just not the right place to run a graphics terminal.
The whole point of Java is that either it will work, or if it won't the compiler will at least tell you WHY it won't and WHERE you can get instructions on how to minimally refactor. Google's way the compiler just spews a bunch of "I've never heard of this class before: java.lang.System"
Please, don't overstate your case. I very much doubt that they've eliminated System. If you want to be credible, find some missing classes (haven't seen a list yet) and tell us what kind of applications won't run because of them. If these are applications that you should be able to run on Google App, then you have a good argument. But not otherwise. And if they're creaky old legacy classes that now have better alternatives, then Google has done the Java community a big favor by doing what Sun lacked the cojones to do.
Never said they were a panacea. Said they were more powerful and easier to use.
Every programming idiom has its pitfalls. It seems to me that the concurrency utilities do a lot to eliminate pitfalls based on hand-rolled thread management. Yes, there are still pitfalls that you can't get rid of without changing the way Java does threads, and there are others you can't get rid of at all. So what? It's still a significant improvement.
Hmm, I did forget about Thread objects being part of the language. But that doesn't mean they have to be part of the public API. You just fiddle with the package declarations so that programmers can't declare or instantiate Thread objects. The Thread objects still exist, but they're only accessible via the Concurrency classes.
Except this is all getting a little weird. I suspect that the real status of Thread (and the other classes missing from the "White List") is "deprecated" rather than "deleted". So you'd get a nasty warning, or maybe even a compiler error, if you tried to use them.
Most of what's wrong with FORTAN got designed in 50 years ago. Plus they're mostly part of the fundamentals of the language. Maintaining compilers that handle ancient FORTRAN design mistakes (FORTRAN was the very first high-level language, and taught all subsequent language designers a lot about how not to go about it) is one thing. Removing a class from Java is quite another. It's completely different from changing a language feature, which Sun is very very conservative about doing.
(Once had a coworker with a PhD in Physics. He was one of the few people in that field who hates FORTRAN. When I told him about the impending release of Fortran 2003, he turned green.)
And note that before you can remove an API, you have to deprecate it. That causes a warning message which tells the programmer that they need to retool. You give that a few years, then you pull the API.
Except now Sun rarely even deprecates an API. Too much blowback. And that is a formula for stagnation.
This was probably to give the Soviets parity, since they never developed a proper semiconductor industry.
Please. Not every shoot-from-the-lip blog entry is part of a FUD campaign.
You're confusing threads (in the generic sense) with Threads (the Java data type). You can't have multithreading without threads (duh!) but you can easily dispense with Threads as part of the official API.
I'm no expert on this technology, but I do know a lot about the motivations behind the Concurrency classes. That's because I spent 2006 helping to update the Java Tutorial, and spent a lot of time getting indoctrinated by the key people involved in this stuff, including Doug Lea.