My answer was meant to be flip. No upper case is just one of many issues (long convoluted sentences, weird logic...) that make me disinclined to have a conversation with you. If you want folks to listen to your opinions, you need to show a little more care and patience in expressing them.
Yeah, I'm sure Google developers have too much self respect not to let bugs go unfixed, or at least not the really glaring ones. But I've seen programmers skimp on their bug fixing because they had a kewl new feature they wanted to work on. And this with a deadline bearing down on them! Though in fact, to these guys, meeting deadlines wasn't a big priority.
At Google, do they even have deadlines? Not from what I can see.
By "acceptably mature" I suppose you mean "usable, and with no nasty glitches". Maybe you, as a technogeek can live with that. But if Google actually cares about not losing mindshare to Yahoo, "acceptably mature" is not enough.
I've said it many times before, but maybe this time people will stop and think before dismissing me as a troll.
Google does not know how to produce mature applications. They only hire brilliant people (or people who are good at passing themselves as brilliant; and yes I do have specific individuals in mind) and they let people work pretty much without supervision. Plus, they have a rule that all developers must spend a fixed percentage of time on unassigned projects!
So basically, their developers never have to do anything they don't really want to do. I've worked in organizations that fostered this kind of working environment (though usually not intentionally) and here's what happens: developers spend all their time finding intellectually challenging work to do, and just ignore all the boring stuff. So you get lots of kewl new features, but nobody's squashing bugs or polishing the GUI, or doing any of the other boring chores you need to polish the rough edges off a product.
You mention Yahoo maps versus Google maps. For a long time, the technology behind Google maps was way superior to Yahoo's. In some ways, it still is. (Yahoo doesn't let you change your route with a simple drag.) But Yahoo has always been ahead of Google in the boring-but-necessary stuff, like providing simple drop-down lists of your memorized locations. Google didn't even have memorized locations for a long time, and when they finally implemented it, they used a weird keyword system that's a pain to use.
Google really needs to hire some relatively stupid plodders to go in and clean up stuff. Hey, I'm available!
Well, that's nice to know, but the fact is that I'm probably older than you. How old? Without being to specific, I'll just say that I once met Harpo Marx.
Turbo Pascal (version 1 of which I used) post-dates the original Adventure by some 5 years or more, I'm not sure how much RAM he would have had to work with, but 64kB isn't out of the question.
It was probably a lot less than 64K. And yes, Turbo Pascal came out later. I only mentioned it to demonstrate that you don't need a lot of memory to compile a block-structured language. Indeed, it's probably easier to write a low-footprint Pascal compiler than it is to write a low-footprint FORTRAN compiler — Pascal's formal syntax is much simpler.
FORTRAN's failings have to do with it being the first high-level language, and thus the one on which language designers made all their worst mistakes. They have nothing to do with the limitations of old hardware.
Yeah, Perl has gotos (computed and otherwise) but it also has block structure. Which is why few Perl programmers ever have occasion to write a goto. (I don't think I ever have.) Perl's readability problems are exactly the opposite of FORTRAN's. Where FORTRAN's designers knew too little about artificial language theory, Perl's designers know way too much! Indeed, Larry Wall started out as a linguist, and can't seem to stop dreaming up clever language constructs. The result is a language that has a nasty tendency to bring out the poet in the programmer. Why is that a bad thing? Because, as any English 101 student will tell you, reading poetry is hard work.
Memory is not the issue here. Turbo Pascal was designed to run in a single 64K 8086 segment, and Pascal is the quintessential block-structured language. The real problem is that the designers of FORTRAN were totally ignorant of the principles of language design. They could hardly be otherwise: FORTRAN was the very first high-level language.
But here's a sobering thought: Dijkstra launched his attack on the goto statement in 1968. Every programmer who's grown up with block structured languages would take it as a given that Dijkstra was right. But at the time, the concept was extremely controversial, and there was a lot of resistance — as evidenced by the fact that Crowther and Wood were still using computed gotos in 1976!
It may be obvious to you that SCO is history, but it's not obvious to everybody. Maybe they think the decision will be overturned on appeal. Maybe they think UnixWare is still worth something. Maybe they know something you don't — or think they know something.
Maybe they're just stupid. One of the cliches of investment is that you can only get rich by buying when "there's blood in the streets". In other words, you buy when everybody sells. People often lose a bundle by applying that strategy indiscriminately. It's the same kind of half-assed logic that makes people think they can get rich playing roulette.
...while some may argue the merits of tebi versus tera...
It's a simple choice. If you say "tebi", all your geek friends will make fun of you. If you say "tera", people will not be sure whether you mean 1024 * 1024 * 1024 or 1000 * 1000 * 1000 or 1000 * 1000 * 1024.... (Finish iterating yourself — I've seen then all.) This confusion might get you sued. So, do you want to be cool, or do you want to stay out of courtrooms?
But instead of refunds, Google should have allowed users to download the videos and perhaps, if required by content owners, put some "traditional" DRM on them, eg. Playsforsure or whatnot.
I doubt they had that option. Content providers don't just say "present our content from being pirated, we don't care how." Their agreements with Google must specify that content can only be provided as streams.
Well, the analogy with Germany/Flawed is pretty flawed. (It doesn't get that cold in Armonk.) And I do wish that people wouldn't use flamebait as a synonym for "dumb".
Nor did I say you did. But you used the word, and that's just as rude. Good manners is not something you can claim on a technicality.
If you have digital cable, you may be using Java to look at the program listings. Oh and people play Java games on their cell phones... (*cough* embedded).
Yeah, yeah, I know all about embedded Java. I used to work for the Java part of Sun. (I even have some Java software on my cell, though I haven't bothered with any of it since shortly after I got the phone.) But you're talking a special embedded version of Java. Which Sun supports because they get big license fees for doing it.
Go to the Java download page. Pick a Java SE or EE bundle and click its "download" link. Look at all the different platforms supported. Where's the ARM package? The Freescale package? There isn't one. So how did Sony Ericsson get a Java runtime onto my cell phone?
What they did was go to Sun and ask to license one of their embeddable versions of the Java runtime. These runtimes, unlike the regular runtimes, aren't freely available. (They also use older versions of the JVM, so you can't use all the language features of Java 6.) You have to jump through a few hoops just to get an evaluation copy.
There is, I just discovered, an embeddable Java (from Sun) for the PPC. So why does Sun support Java for embeddable PPC but not Linux/PPC? Because there's no money in it. Like I said before, the embeddable world and the desktop world are completely different marketplaces.
Java6 isn't really an issue (maybe IBM is waiting to see what happens with OpenJava) since Java6 apps aren't widely used yet. As for being able to run Java on PPC here is a link http://www.yellowdog-board.com/viewtopic.php?t=158 1&sid=4c349bb1bc422cb54a968bb97535feeb of a volunteer helping someone else with Java.
None of which is responsive to my main point, that IBM only supports Java for POWER not PPC. And the instructions on the page you link don't actually work. But never mind. Let's just stipulate that I was wrong about IBM supporting Java on PPC. (I've found some references to them doing so, but nothing recent.) But if your aim is to understand my arguments (as opposed to jumping on every real or imaginary mistake I make) then you will recall that I my original "vile" post was in response to a guy who complained that PPC/Linux wasn't supported. His assertion may have been wrong, but I stand by the argument I made in response: no software vendor can afford to support every platform.
You just gave an example of that yourself. Somewhere, somebody wants to run a Java 6 app on his zSeries mainframe and complaining to his IBM rep that they don't support Java 6. His rep is telling him that there isn't enough demand for Java 6 yet to justify porting it to all of IBM's hardware. Which is the same argument I'm making
I'd be hard press to name a software vendor that is not paying attention to Linux... Even Microsoft is paying attention.
"Paying attention to Linux" is not the same thing as "creating and supporting all your applications on Linux". And it's even further from "creating and supporting all your applications on Linux/PPC." There might somebody be a x86/Linux version of Microsoft Office (MS's reasons for not doing it in the past seem to be political.) But I'll bet my bottom dollar that there will never be a PPC/Linux version
Hey, here's another example. Sun is more than "interested in" Linux: they sell a lot of x86-based systems to folks that plan to run Red Hat or SUSE on them. And they will provide support for such a configuration. They also sell SPARC-based systems. (Indeed, there are still folks at Sun who'd be happier if they only sold SPARC-based systems.) But do they support Linux/SPARC? They do not. The market isn't big enough.
"Loading the runtime" basically amounts to transferring the libraries from disk to RAM. So startup time has nothing to do with the supposed efficiency gain for native code compared to byte codes. (Which is mostly not true anyway, but that's another issue.) What it does have to do with is the size of the files being loaded. Translating the libraries to native code wouldn't necessarily make them smaller. Indeed, it would probably make them bigger.
I'll buy "abrasive". That's a pretty good description of my personality. But my personality traits have nothing to do with the validity of my arguments. Nor do they justify your using the word "idiot".
As long as we're discussion personalities, go look up the word "patronizing".
Anyway, now that we've thoroughly abused each other, let's look at your arguments:
1. While PPC may be in your opinion obsolete on the desktop, it is still one of the platforms of choice for embedded applications.
Fine, I should have qualified my statement: "obsolete on desktop systems". Though that's just a little pedantic.
When I started using microcomputers in the late 70s, the leading desktop CPU was the Zilog Z80. That processor is still widely used in embedded applications (many of the credit card swipers use it) but nobody wants a desktop system with an 8-bit processor any more. Also "obsolete", at least for our purposes. We're talking about personal computers (in the broad sense); what's going on in the embedded world is a whole different thing. People don't play Java games on their TiVo.
We don't have to hold our breath, just download the JVM from IBM.
The IBM JVM supports POWER. Which of course IBM has to support, since they sell a lot of POWER-based systems. But POWER and POWER-PC are different chips, even though one is derived from the other. I'm guessing that it's wouldn't be terribly hard to make POWER software run on the POWER PC. But the fact is, nobody's taken the time to do it. Which was exactly my point: there isn't a lot of incentive to support PPC.
Also, I notice that the IBM JVM only support Java 5. Java 6 went GA almost a year ago, and was available in Beta long before that. So even a company with IBM's resources can't provide a JVM that runs the latest Java software. How can some OSS volunteer group hope to do so?
Linux being third-place is not necessarily a bad thing, considering the number of operating systems available out there...
It's a bad thing in terms of getting software vendors to pay attention to you. Which is why Sun resisted porting Java to Linux for such a long time. They do now (probably because they finally got serious about supporting Linux on their servers), but only for x86. It would take more than a few disgruntled Mac/Linux users for there to be a PPC port.
Basically, you didn't rebut any of my arguments, you just picked nits with they way I expressed them. Really, that makes you look like... No, let's not go there again.
You justify storing license plate data because it "has uses". You don't qualify the statement. If data being potential useful is sufficient justification for violating a person's privacy, then you justify any intrusion.
I actually agree with you that being in public cuts back on your reasonable expectation of privacy. But that's a separate argument. You're not talking about what constitutes a violation of privacy, you're talking about what justifies violating privacy. And the fact that the intrusion might detect a crime someday doesn't cut it.
Sure some SMTP servers were open, but not the smart ones.
Dude, when I started using the internet in 1994, I was able to telnet into any SMTP server. Richard Stevens even used this fact in his book on TCP/IP, to demonstrate how SMTP worked.
Oops, one little irony I just noticed. You denounce John Curran as a troll, using ARIN figures to refute his argument. Hey, guess who's the chairman of ARIN? One guess.
I know John Curran as a troll on the PPML who brings up "IPV6 internet cutoff" every so often.
A troll is somebody who throws out an argument that they know to be invalid for the fun of watching the resulting raised hackles. Just having an opinion you don't care for doesn't make somebody a troll. I could just as easily call you a troll for refusing to face what many leading authorities consider to be a very real crisis.
Basically you're arguing that any data gathering that might be useful for preventing or solving a crime is legitimate. So I guess you'd have no objection to the government putting video surveillance in your home? Think how safe you'd be! Besides, you might be working for Al Qaida or Tony Soprano! How do we know you aren't?
Give us a break. So nobody's bothered to implement a proper Java for a third-place OS running on an obsolete hardware platform. Next you'll be complaining that Java isn't available for your C64!
People seem to think it's some kind of evil plot when a software vendor doesn't support their favorite platform. The fact is, every platform you support adds a lot to your development and QA costs. If there's no business case (and there certainly isn't for any PPC platform), why should they spend the money.
And don't hold your breath waiting for some OSS folks to port Java to PPC/Linux. Even OSS people have to eat.
Slashdot Mirror
My answer was meant to be flip. No upper case is just one of many issues (long convoluted sentences, weird logic...) that make me disinclined to have a conversation with you. If you want folks to listen to your opinions, you need to show a little more care and patience in expressing them.
If you learned to use the shift key, your resume would probably come across better.
Yeah, I'm sure Google developers have too much self respect not to let bugs go unfixed, or at least not the really glaring ones. But I've seen programmers skimp on their bug fixing because they had a kewl new feature they wanted to work on. And this with a deadline bearing down on them! Though in fact, to these guys, meeting deadlines wasn't a big priority.
At Google, do they even have deadlines? Not from what I can see.
By "acceptably mature" I suppose you mean "usable, and with no nasty glitches". Maybe you, as a technogeek can live with that. But if Google actually cares about not losing mindshare to Yahoo, "acceptably mature" is not enough.
I've said it many times before, but maybe this time people will stop and think before dismissing me as a troll.
Google does not know how to produce mature applications. They only hire brilliant people (or people who are good at passing themselves as brilliant; and yes I do have specific individuals in mind) and they let people work pretty much without supervision. Plus, they have a rule that all developers must spend a fixed percentage of time on unassigned projects!
So basically, their developers never have to do anything they don't really want to do. I've worked in organizations that fostered this kind of working environment (though usually not intentionally) and here's what happens: developers spend all their time finding intellectually challenging work to do, and just ignore all the boring stuff. So you get lots of kewl new features, but nobody's squashing bugs or polishing the GUI, or doing any of the other boring chores you need to polish the rough edges off a product.
You mention Yahoo maps versus Google maps. For a long time, the technology behind Google maps was way superior to Yahoo's. In some ways, it still is. (Yahoo doesn't let you change your route with a simple drag.) But Yahoo has always been ahead of Google in the boring-but-necessary stuff, like providing simple drop-down lists of your memorized locations. Google didn't even have memorized locations for a long time, and when they finally implemented it, they used a weird keyword system that's a pain to use.
Google really needs to hire some relatively stupid plodders to go in and clean up stuff. Hey, I'm available!
FORTRAN's failings have to do with it being the first high-level language, and thus the one on which language designers made all their worst mistakes. They have nothing to do with the limitations of old hardware.
Yeah, Perl has gotos (computed and otherwise) but it also has block structure. Which is why few Perl programmers ever have occasion to write a goto. (I don't think I ever have.) Perl's readability problems are exactly the opposite of FORTRAN's. Where FORTRAN's designers knew too little about artificial language theory, Perl's designers know way too much! Indeed, Larry Wall started out as a linguist, and can't seem to stop dreaming up clever language constructs. The result is a language that has a nasty tendency to bring out the poet in the programmer. Why is that a bad thing? Because, as any English 101 student will tell you, reading poetry is hard work.
Memory is not the issue here. Turbo Pascal was designed to run in a single 64K 8086 segment, and Pascal is the quintessential block-structured language. The real problem is that the designers of FORTRAN were totally ignorant of the principles of language design. They could hardly be otherwise: FORTRAN was the very first high-level language.
But here's a sobering thought: Dijkstra launched his attack on the goto statement in 1968. Every programmer who's grown up with block structured languages would take it as a given that Dijkstra was right. But at the time, the concept was extremely controversial, and there was a lot of resistance — as evidenced by the fact that Crowther and Wood were still using computed gotos in 1976!
My point being that there was a time when people didn't feel a need to secure their SMTP servers.
It may be obvious to you that SCO is history, but it's not obvious to everybody. Maybe they think the decision will be overturned on appeal. Maybe they think UnixWare is still worth something. Maybe they know something you don't — or think they know something.
Maybe they're just stupid. One of the cliches of investment is that you can only get rich by buying when "there's blood in the streets". In other words, you buy when everybody sells. People often lose a bundle by applying that strategy indiscriminately. It's the same kind of half-assed logic that makes people think they can get rich playing roulette.
Or maybe SCO is sending out "hot stock" spam...
If you're a Bushie, it's called a "Faith-Based Initiative." If you live in the real world, it's called pandering to your political base.
Well, the analogy with Germany/Flawed is pretty flawed. (It doesn't get that cold in Armonk.) And I do wish that people wouldn't use flamebait as a synonym for "dumb".
Nor did I say you did. But you used the word, and that's just as rude. Good manners is not something you can claim on a technicality.Yeah, yeah, I know all about embedded Java. I used to work for the Java part of Sun. (I even have some Java software on my cell, though I haven't bothered with any of it since shortly after I got the phone.) But you're talking a special embedded version of Java. Which Sun supports because they get big license fees for doing it.
Go to the Java download page. Pick a Java SE or EE bundle and click its "download" link. Look at all the different platforms supported. Where's the ARM package? The Freescale package? There isn't one. So how did Sony Ericsson get a Java runtime onto my cell phone?
What they did was go to Sun and ask to license one of their embeddable versions of the Java runtime. These runtimes, unlike the regular runtimes, aren't freely available. (They also use older versions of the JVM, so you can't use all the language features of Java 6.) You have to jump through a few hoops just to get an evaluation copy.
There is, I just discovered, an embeddable Java (from Sun) for the PPC. So why does Sun support Java for embeddable PPC but not Linux/PPC? Because there's no money in it. Like I said before, the embeddable world and the desktop world are completely different marketplaces.
None of which is responsive to my main point, that IBM only supports Java for POWER not PPC. And the instructions on the page you link don't actually work. But never mind. Let's just stipulate that I was wrong about IBM supporting Java on PPC. (I've found some references to them doing so, but nothing recent.) But if your aim is to understand my arguments (as opposed to jumping on every real or imaginary mistake I make) then you will recall that I my original "vile" post was in response to a guy who complained that PPC/Linux wasn't supported. His assertion may have been wrong, but I stand by the argument I made in response: no software vendor can afford to support every platform.
You just gave an example of that yourself. Somewhere, somebody wants to run a Java 6 app on his zSeries mainframe and complaining to his IBM rep that they don't support Java 6. His rep is telling him that there isn't enough demand for Java 6 yet to justify porting it to all of IBM's hardware. Which is the same argument I'm making"Paying attention to Linux" is not the same thing as "creating and supporting all your applications on Linux". And it's even further from "creating and supporting all your applications on Linux/PPC." There might somebody be a x86/Linux version of Microsoft Office (MS's reasons for not doing it in the past seem to be political.) But I'll bet my bottom dollar that there will never be a PPC/Linux version
Hey, here's another example. Sun is more than "interested in" Linux: they sell a lot of x86-based systems to folks that plan to run Red Hat or SUSE on them. And they will provide support for such a configuration. They also sell SPARC-based systems. (Indeed, there are still folks at Sun who'd be happier if they only sold SPARC-based systems.) But do they support Linux/SPARC? They do not. The market isn't big enough.
"Loading the runtime" basically amounts to transferring the libraries from disk to RAM. So startup time has nothing to do with the supposed efficiency gain for native code compared to byte codes. (Which is mostly not true anyway, but that's another issue.) What it does have to do with is the size of the files being loaded. Translating the libraries to native code wouldn't necessarily make them smaller. Indeed, it would probably make them bigger.
As long as we're discussion personalities, go look up the word "patronizing".
Anyway, now that we've thoroughly abused each other, let's look at your arguments:Fine, I should have qualified my statement: "obsolete on desktop systems". Though that's just a little pedantic.
When I started using microcomputers in the late 70s, the leading desktop CPU was the Zilog Z80. That processor is still widely used in embedded applications (many of the credit card swipers use it) but nobody wants a desktop system with an 8-bit processor any more. Also "obsolete", at least for our purposes. We're talking about personal computers (in the broad sense); what's going on in the embedded world is a whole different thing. People don't play Java games on their TiVo.The IBM JVM supports POWER. Which of course IBM has to support, since they sell a lot of POWER-based systems. But POWER and POWER-PC are different chips, even though one is derived from the other. I'm guessing that it's wouldn't be terribly hard to make POWER software run on the POWER PC. But the fact is, nobody's taken the time to do it. Which was exactly my point: there isn't a lot of incentive to support PPC.
Also, I notice that the IBM JVM only support Java 5. Java 6 went GA almost a year ago, and was available in Beta long before that. So even a company with IBM's resources can't provide a JVM that runs the latest Java software. How can some OSS volunteer group hope to do so?It's a bad thing in terms of getting software vendors to pay attention to you. Which is why Sun resisted porting Java to Linux for such a long time. They do now (probably because they finally got serious about supporting Linux on their servers), but only for x86. It would take more than a few disgruntled Mac/Linux users for there to be a PPC port.
Basically, you didn't rebut any of my arguments, you just picked nits with they way I expressed them. Really, that makes you look like... No, let's not go there again.
My argument is "vile"? You're the one that's making personal comments.
You justify storing license plate data because it "has uses". You don't qualify the statement. If data being potential useful is sufficient justification for violating a person's privacy, then you justify any intrusion.
I actually agree with you that being in public cuts back on your reasonable expectation of privacy. But that's a separate argument. You're not talking about what constitutes a violation of privacy, you're talking about what justifies violating privacy. And the fact that the intrusion might detect a crime someday doesn't cut it.
Oops, one little irony I just noticed. You denounce John Curran as a troll, using ARIN figures to refute his argument. Hey, guess who's the chairman of ARIN? One guess.
Basically you're arguing that any data gathering that might be useful for preventing or solving a crime is legitimate. So I guess you'd have no objection to the government putting video surveillance in your home? Think how safe you'd be! Besides, you might be working for Al Qaida or Tony Soprano! How do we know you aren't?
Give us a break. So nobody's bothered to implement a proper Java for a third-place OS running on an obsolete hardware platform. Next you'll be complaining that Java isn't available for your C64!
People seem to think it's some kind of evil plot when a software vendor doesn't support their favorite platform. The fact is, every platform you support adds a lot to your development and QA costs. If there's no business case (and there certainly isn't for any PPC platform), why should they spend the money.
And don't hold your breath waiting for some OSS folks to port Java to PPC/Linux. Even OSS people have to eat.