>what we need is a wireless killer app without these concerns thwarting it
How about VOIP? Wouldn't it be interesting if you could just by a handset and start calling people for free? Perhaps at some point you'd want to make a long distance call and couldn't find a path across the free P2P network (or you wanted a QOS guarantee) which would use your paid subscription, but for a call across town, why not?
2 words: seek time. If you're copying a bigass file to/from the server, yes the network will probably be more of a bottleneck than a modern drive on a modern controller. This is probably the most likely actual use case - MP3s, downloaded installers, movies, or whatever.
However when it comes time to copy that directory with 10,000 1KB files in it to the server, network latency and disk seek time suddenly matter quite a lot, and theoretical maximum throughput doesn't matter quite so much. Also, chances are that a home file server wouldn't be a dedicated appliance with no other responsibilities, so it's worth looking into RAID performance for other overlapping duties that the server may have.
OK, I'll bite. How is binary compatibility different from API compatibility? I suspect that this may differ from language to language and from static to dynamic linking...?
Are you talking about the difference between a new OS that supports older binaries with binary interfaces but which no longer provides an SDK to use the deprecated API? If so then I guess binary compatibility would be a subset of API compatibility - in C, binary compatibility would just mean that the linker would need to be able to do its thing, but API compatibility would mean that header files would also be needed.
I say that this may be a language-dependent issue because there are languages and binary formats for which the compile-time interfaces are in the same file as the runtime implementation. In these cases, the third layer (above the implementation and declared interface) is human-readable documentation, and just withholding that would be all you could do to try to get people to stop using the old API. But if they had documentation from another source (yard sale, eBay, etc.) they could still compile against the implementation files since those have the required interface info embedded in them. I'm thinking in particular of.NET assemblies and Java classes but there are probably plenty of other examples out there.
You know that trojan wasn't actually found in the wild, right? They took a proof-of-concept that someone had created and announced that their virus app could detect it.
Perhaps parent^2 should have said "no trojans in the wild"...?
It is a pretty sad argument, though. There's always that one kick-ass application that only runs on Win32, such as Visual SourceSafe or Outlook or IE 6.0 or Access or MSN Messenger. Pity the poor Mac users who can't experience all that the Windows platform has to offer.
The poster is probably talking about the iTunes Music Store functionality. I upgraded to OS X pretty early so I didn't keep track of iTunes on OS 9, so I could be wrong about that. But the music store UI isn't just plain old HTML and probably uses some new thing that is Cocoa-only.
The conspiracy to force you to upgrade is probably more like a conspiracy not to spend tons of money backporting libraries to OS 9 just so the software can work. I'm sure if they could check a checkbox and build an OS 9 version of the latest iTunes with no effort, they would. There are plenty of other reasons to upgrade to OS X.
So if folks are using DiVX but not AVI, what encapsulation are they using to keep their DiVX encoded movies in? Are you even aware that AVI and Quicktime are file formats rather than codecs?
Also I strongly disagree that "the industry" has settled on DiVX. "The industry", meaning the folks who actually have movies to sell legally, settled on MPEG 2 in the form of DVDs. I haven't seen any remotely successful online digital movie ventures, so it's hard to say what The Industry has or has not settled on.
If you expand "the industry" to mean "the other industry" that sells lots and lots of videos and images online, then please be explicit. (They certainly are.)
Re:Yeah, and what's that going to cost in the U.S.
on
200mbps DSL On Its Way?
·
· Score: 3, Informative
The phenomenon you are experiencing is called "deregulation". It's what happens when monopoly telco lobbyists write the legislation that creates a fair competitive environment for other companies to compete with said telcos. Of course, the actual legislation is anything but fair. See also: Covad vs. the "baby bells".
This is sort of like the power "deregulation" that took place in California and led to rolling blackouts and ultra high electricity and gas prices, and required a statewide bailout of the monopoly power company, Pacific Gas and Electric.
When anybody in a suit starts to wax romantic about free markets, competition, and deregulation, look for the crossed fingers behind their back and wads of dollar bills sticking out of their pockets. What they really want is to replace a regulated monopoly with an unregulated monopoly, and an inefficient government bureacracy with an unaccountable corporate pyramid scheme that leads to offshore accounts, unprecedented executive payouts, and bankruptcy (followed by an emergency government bailout). See also: Enron, Worldcom.
Real competition would be great, but that's not what we've got. What we have is legislated, goverment-subsidized monopolies paying protection money to Congress with one hand and waving a "Free markets now!" sign with the other.
Of course, the bold new twist on this scheme is to first announce that you're going to replace a government bureaucracy with an efficient outsourcing contract, and then just award the contract to your friends with no bidding process (or a secret bidding process), claiming that national security (or the interest of fair competition) forced the bidding process to be secret or to be skipped altogether. Then you can sidestep all sorts of rules and laws and replace huge sections of the government with unaccountable private corporations, and you get deniability even if you own stock in said corporation. See also: Halliburton, Bechtel.
>Imagine a HD TiVo, recording and watching 3 different shows/movies at the same time, pumped through your DSL line.
Or imagine broadcast TV or cable, doing the exact same thing but with DRM'd content just the way that the owners of the content like it. You want ShareReactor + eMule over a T3 and they want DirecTV. They have lawyers and lobbyists and you have...?
Imagine all the cease and desist orders you could get over that much bandwidth.
Let's face it, folks, the last mile is NOT the problem. What exactly would you use it for? There are some very rich, powerful people damming a river, and dredging the river downstream isn't going to make the water flow much faster. For everyone to have ultra broadband would be the ??AA's worst fucking nightmare.
I dunno... maybe the picture it paints is one where people are upgrading their browser because they got nailed by malware and the fix is only available for IE 6+. Maybe that will lead people to use something else when they get nailed again and there's no fix for IE 6 yet.
...and USB and SCSI and gigabit Ethernet and commodity SMP and IPv6 and...
Parent^2 was probably a troll, or maybe just ignorant, but in case anybody agrees, consider this:
If you ever take a look at the various visualization projects that show the breakdown of the Linux kernel, like this one, what you'll find is that a huge amount of code is dedicated to things that didn't even exist in 1983, and probably not in 1993 either. Most of them are hardware drivers and filesystems and networking standards that get built as modules, so you wouldn't necessarily care that there's IRDA or HFS or MIPS support, but it's there.
You really need to study the details of the Microsoft monopoly lawsuit, and study up on antitrust law in general, because it's obvious that you haven't.
Microsoft has a monopoly. That has been proven in a court of law. What has also been proven in a court of law is that they abused this monopoly by using anti-competitive practices to make sure that they were in complete control of what was and wasn't installed on top of Windows by system vendors.
Your argument is the same one that Microsoft used. "Poor, poor users - if we let competitors or OEMs change Windows, the poor users won't get the best, most consistent user experience!" Of course this is question-begging: this argument assumes that Microsoft provides the best, most "consistent" user interface, and there's no evidence to the contrary because no one is allowed to rip out chunks of Windows and replace them with Gecko and VLC etc. or just leave those apps out, because Microsoft will revoke their OEM license.
What an end user can do with one PC to tailor it to their needs is not the issue. What an OEM is being prevented from doing on behalf of all of their customers is the issue.
As for Apple somehow having an iTunes monolpoly, you're confusing PC vendors (none of whom have a monopoly, at least in the US) with Microsoft, and anti-competitive practices with competitive practices. If Apple were able to strongarm all PC vendors into not installing WMP or RealPlayer or WinAmp or MusicMatch (etc. etc.) as a condition of installing iTunes, using an iTunes (or other Apple product) monopoly as leverage, that would be comparable to Microsoft's illegal anticompetitive monopolistic practices. Instead, the news that one PC vendor has chosen to preload iTunes doesn't mean that WMP will not be installed, and doesn't in any way give Apple a monopoly on music apps or denote illegal anticompetitive practices.
Hear, hear. Systems (software or otherwise) that offer something of monetary value for free, and provide no mechanism whatsoever to prevent people from exploiting them, are going to get exploited. Shocking!
Maybe it wasn't obvious to blog and wiki programmers that the ability to post a comment or edit a wiki page was worth money. It isn't worth a lot per post, but because these are online systems, they are very susceptible to bots that can post in huge volume. All of those posts together can alter a site's placement in Google search results, and that's definitely worth money.
Instead of whining about Google being influenced by attacks that use your Wiki or blog, how about making it hard for bots to post in the first place? Is that really an important feature that you can't live without?
Also, in the process of looking at the source to figure out how to make the above URL, I found these comments in the HTML starting at line 45:
"DO NOT CHANGE THIS AGAIN THERE NEEDS TO BE A WAY FOR MEMBERS TO RETURN TO THE CONTENT" (some HTML code removed here) "DO NOT EDIT ABOVE THIS LINE GO FUCK YOURSELF - The Management"
Nice. It's always good to see design arguments that have escalated into profane insults embedded in one's publicly visible HTML source. The least they could do would be to use the scripting language's comment syntax so those little love notes wouldn't be visible to anybody looking at the source code...
>I fail to see the point in spending between $2000-$5000 for one of these displays. I don't care how many languages it speaks or what O/S it runs.
Hmm... yup, looks like I guessed right. You've only been a Slashdot user for a week, haven't you? First post 7 days ago.
Give it time.
Soon you won't even care what it does; as long as it runs Linux or has a Transmeta CPU in it, you'll want one. $5000 will seem completely acceptable for a TV set, so that you can play a pointless but cool-looking eye-candy demo on it for both of your friends, who will be soooo impressed. At the same time, the prospect of spending more than $20 on a date, doing anything not directly related to computers, or of owning any clothes other than jeans and t-shirts will start to seem like pointless wastes of money.
"Organic" farming (which is a regulatory term in some jurisdictions, not just a marketing word) and "genetically modified organisms" are unfortunately ambiguous terms that don't differentiate between food that is and is not made with those techniques, if you stick to the strict literal definition of those terms. However, don't make the mistake of thinking that this means that there is no meaning to these terms.
"New methods are just faster" - perhaps. Roughly how long would it take for DNA from an insect to work its way into a plant, through natural pollination?
It isn't very smart to take a brand new organism that has never existed before and declare it completely and totally safe to eat and superior in every way to its predecessor. GMOs are neither necessarily bad nor necessarily good. Only time, scientific testing, and risk analysis (example: famine without GMO crops vs. plenty of food but increased risk of disease with a GMO) can tell for sure.
The key issue is that manufacturers of GMOs are lobbying very hard to hide the fact that what they're selling has been unnaturally modified and has only had a few years (at the most) of testing for safe human consumption. They have lobbied in the US to make it illegal to label foods as GMO. What does that say to you about how safe they are? You can be as libertarian as you like, but the idea of a free market is based on an ideal of voluntary transactions based on a fully informed buyer and seller. Hiding this kind of information from buyers is shady at best. If GMOs are safe, nay superior, then label them with pride.
Microsoft's JVM was objectionable for two reasons.
First, Microsoft chose to leave out a required part of Java called RMI (Remote Method Invocation, which is a Java-only technology that is otherwise similar to CORBA). That means that if you wrote a 100% Pure Java application that was carefully coded to spec and happened to use RMI, it would run on any Java VM except Microsoft's. The typically alleged reason for leaving this out is that RMI also competes with DCOM. Interestingly, Microsoft offered the RMI functionality as a downloadable add-on, but Sun argued (successfully) that this wasn't good enough since the rest of the Microsoft VM was shipping with every copy of Windows.
Second, Microsoft added some language features (not just classes, but keywords and bytecodes if I remember correctly) that were not part of standard Java, and their J++ development environment used these without warning the user that they were coding for Microsoft's Java implementation only, as opposed to writing portable code.
It's important to note for the sake of comparison that Apple has made it possible to write non-portable Java applications that will only run in Mac OS X and which depend on the Cocoa API. The reason Sun isn't suing Apple for doing this is that Apple's JVM will run 100% Pure Java applications with no problem. That's the requirement that Sun makes.
The key distinction here is implementing a superset vs. subset of the spec. Microsoft shipped an implementation of a subset of the spec, and added stuff that was not in the spec. Apple ships an implementation of the *whole* spec, and has added stuff that's not in the spec. Adding stuff is allowed. Removing stuff is not allowed.
Heck, even Netscape added their LiveConnect API to their JVM, but that was OK because (copious bugs notwithstanding) their JVM would run 100% Pure Java applications.
On another topic, WABA is pretty interesting. I messed around with it (and a bunch of other mobile Java-ish environments) back in 2001. Basically WABA uses Java bytecodes but not the Java class library, so they can't call it Java without getting sued by Sun (subset + use of the Java name == lawsuit). Sun has its own J2ME (Java 2 Micro Edition) spec and runtime and SDK, which is missing some classes from the Java 2 Standard Edition class library. (Some classes are there but are reduced in functionality.) WABA isn't even J2ME compliant - for example, WABA lacks threads entirely. But, because you can just use a Java compiler on a nice juicy desktop environment and point that compiler at the WABA library, WABA lets you keep using some of your familiar J2SE/J2EE tools. With a desktop-based WABA interpreter, you even get to debug using a runtime that is too big and slow to run on a resource-limited device, but which has lots of cushy features that you'd want during development. (Eventually I decided that I really didn't enjoy trying to get stuff working on any of the available platforms because the SDKs were either missing really important features, or were just too buggy or hard to develop for.)
>If Sun GPLed Java (the VM, compiler, libraries, etc.), they could then move people to writing software in Java, and actually have Java products which they could sell for money, which would be a serious revenue stream, and should have been the plan from the start.
Um, they already do make and sell commercial software written in Java, and have for years. Whether it was a good idea to write the Solaris installer in Java, or whether they're actually making any money selling their app server, are different questions. But for Sun to *try* and write good Java applications that make money is not a novel concept.
You're also assuming that Sun makes no money on the work those people are doing, which isn't quite true. When I download the JVM and use it to build an app, then no, I'm not paying for it. But when Sun sells a server to someone who thinks that Java only runs on Solaris, or when they think that Sun's really expensive application server is necessarily much better than Tomcat or JBoss, then those people are making money.
If they GPL it and IBM were to take the lead in advancing Java's development, then those confused IT buyers would buy IBM gear and WebSphere instead.
It seems to me that Sun's Java strategy for quite a while has been to use Java as a loss leader for hardware, preying on the confused masses that haven't ever bothered to look at Java on Windows or Linux, and who just assume that it must run best on Solaris. It's stupid, but it apparently works.
However, as developers continue to shout that Linux is a dandy platform for Java applications (as is Mac OS X, as is Windows...) and as IT buyers keep reading again and again that real companies are actually using Linux and not going belly-up or crawling back to Microsoft or Sun on hands and knees begging for foregiveness, they are starting to get the idea that maybe they don't have to run Java on Sun gear.
>But JIT is STILL interpreting in the same sense perl code is interpreted (even if there are utils to compile perl as well), the code is compiled on the fly as it's loaded and then executed. AFAIK JIT compiling is really just an efficient method of interpreting.
No, this is incorrect.
Perl 5 initially parses the source code into an in-memory parse tree that is not processor-native machine language, nor is it bytecodes. It's a pre-parsed tree structure of tokens from the source code. The Perl 5 interpreter then executes this parsed tree.
The Java compiler bytecode compiles Java source code into Java bytecodes and typically writes them to disk in.class files, for later execution when you run that Java program. These bytecodes are not just chunks of text from the source code; they are also not processor-native. They are instructions for an imaginary CPU (the Java "virtual machine"). Compare this to Perl, in which you usually compile from source each and every time you run the program.
It is possible to compile from Perl source to Perl bytecodes for later execution too, but I haven't seen anybody actually bother with this. Even if you did, what Perl does is to re-constitute the parse tree from the bytecodes, and then it interprets that.
The classic Java interpreter then treats these pre-compiled Java bytecodes as the program, emulating the imaginary CPU in software by calling functions that are part of the interpreter to handle each of the bytecodes.
According to O'Reilly's Programming Perl, Chapter 18: "Pass 4: Code Generation This pass is optional; it isn't used in the normal scheme of things." and "Please be aware that the code generators are all extremely experimental utilities that shouldn't be expected to work in a production environment. In fact, they shouldn't even be expected to work in a nonproduction environment except maybe once in a blue moon."
Yes, it's possible to generate native code from Perl source, but they way you do it is to first generate C source code, and then run that through a C compiler. In general use, though, Perl is parsed into a tree of in-memory tokens, and those are then interpreted.
This is not at all the same as what a JIT compiler does. The JIT compiler in Java encounters a chunk of bytecodes (which were previously compiled from Java source code), transforms them into a chunk of processor-native instructions, and then runs them. It doesn't run the bytecodes; if they say to add X and Y and store them in Z, a JIT compiler creates code that would do that, and then the VM runs that native code. The main drawback with a JIT compiler is that compiling from bytecode to native code adds a bit of a lag. Multiply this across a big application, and the lag is pretty serious. The benefit is that if you call that chunk of code 100,000 times during a program, the first iteration is delayed while the code is JIT compiled, but then the 100,000 iterations of that code are done by native code, so overall it's faster.
The HotSpot compiler (once experimental, now a standard part of the Java VM) has a few performance tweaks, including a sort of hedged approach to interpretation vs. JIT compilation. Basically it interprets the code the first few times and keeps track of how many times the code is called. After that, it JIT compiles it. The idea here is to make sure that it's worth the overhead of JIT compiling.
By the way,.NET uses JIT compilation too, and it works similarly: you compile to files full of MSIL bytecodes, and treat that as your compiled program. When you go to run it, the.NET JIT compiler turns those MSIL bytecodes into native instructions which are run.
One big reason why compiling to native code and caching that is not done is that it breaks the Java (and.NET) security model. The verifiers that check your code for adherence to the secur
The problem is that this approach still gives Sun the opportunity to do what it did to JBoss - play games with cost and availability of that test suite.
Oh, you want to release a Java derivative? Sure, you can license the test suite for only $100,000.
Yes, we got your check for $100,000, and we sent the CD with the test suite. You never got it? We definitely sent it. Want us to send another? OK, that's another $100,000. Oh, shucks. It seems that we ran out of them and have to make some more. Please allow 6-8 months for delivery.
>if Java has enough functionality already then nobody will really feel the need to add anything else
Yeah, right. Someone will always feel the need to add something else. Open source Java and on day one, somebody will release a derivative with real, actual memory pointers that utterly break the security model. Someone else will release a derivative with multiple inheritance. Yet another group will put in design by contract. Someone else (IBM?) will rip out Swing and AWT as much as possible and just leave SWT. Someone else will make all primitives into objects, etc.
Those modified versions may not necessarily be a bad thing (no matter what Sun thinks), but the idea that there could be One True Language that makes everybody happy if they just remember to put all of the right features in and none of the wrong ones is silly.
I had a book that described how to do this and had sample code. I'm pretty sure it was Understanding the Apple//e by Jim Sather, but it might have been a different book. (BTW, I no longer have that book and am looking for a copy if you have one. I've had no luck finding it via Amazon or eBay etc.)
In case anybody cares, here's how it worked: The Apple II series was designed so that the CPU and video hardware alternated reading from memory. The memory was twice as fast as the CPU needed it to be (quite different from today's situation!). If you wanted to know what the byte value was that the video hardware had just read, all you needed to do was to read from a memory-mapped I/O address that didn't actually put anything on the data bus. There were a few I/O addresses that worked like this; just putting that address on the address bus (by reading from or writing to that address) would make something happen; the data wasn't important, so the I/O hardware would just leave the data bus alone. If you read from such an address you'd get the data that was still being put on the data bus by the RAM from the previous video hardware access.
The way to make this work for mode switching was to use a second idiosyncracy of the video hardware. For some reason (probably simplicity of implementation), during the horizontal retrace interval at the end of each scan line, the video hardware kept stepping through video memory, reading one byte at a time. Thus, there were a few undisplayed bytes that would appear on the data bus during the horizontal retrace interval, in memory that was basically just wasted. So, you could put a multi-byte signature in that area of exactly one line in display memory, and spend all of your CPU time in a loop waiting to see this signature appear. When it did, you knew which line had just been displayed, and could immediately switch video modes in the middle of the screen. You could use a few of these to display multiple video modes (low res graphics, hi res graphics, and text) on the screen in different vertical bands.
The only problem is, there's hardly any practical reason to want to do this. The CPU cost was so high that it was hard to use it for anything.
>Not so long ago, most music appealed to most of the population.
That's an interesting opinion, but the history of rock and roll is one of kids liking music that their parents considered awful and immoral. From swing to Elvis to the Beatles to psychedelic music to disco to punk to new wave to heavy metal to hip hop... every one of these styles was considered shocking by the old and exciting by the young. Jazz and ragtime are probably about the same. I wouldn't be surprised if it were true going back hundreds of years.
>Now, however, I challenge you to find any mainstream music that is halfway palatable to anyone over the age of 30. Dido. Macy Gray. John Mayer. Thievery Corporation. OutKast. Black Eyed Peas. Norah Jones. Sarah McLachlan. These are some of my over-30 friends' favorite musicians. Whether you want to accept it or not, people DO like these artists and DO buy their albums and ARE older than 30. Just look at the iTunes Music Store's top 100 albums of the day list, or Amazon.
I challenge you to prove that "mainstream" music (let's use sales volume to define mainstreamness here) is only bought by teenagers.
Who do you think is buying XM-enabled car stereos, SACD players, 60s and 70s band reunion CDs (and the $75+ tickets to their concerts)? Do you think that jazz, classical, and country music are all teen-supported too? Diana Krall is #20 in the iTunes Music Store's "Today's Top Albums" list, and #5 on Amazon.
I think you're confusing advertising with sales. Pop music (which is mostly hip hop now) needs lots of ads because, generally speaking, the artists are one hit wonders and constantly need to be introduced to people.
OTOH, Dean Martin is at #5 on the iTunes Music Store's top albums list today. Alanis Morrissette is #2 and #77, Morrissey #12, Bob Marley #39, Cat Stevens #46, Tom Petty's and the Heartbreakers Greatest Hits #54, Dark Side of the Moon #92, ABBA Gold #98. I doubt anyone has run a Cat Stevens or Tom Petty and the Heartbreakers ad in the last 10 years.
On Amazon, in the top 25 are Alanis (#8), Eric Clapton (#10), Wilson Philips (#14), Prince (#16), Loretta Lynn (#23), and three soundtracks (Love Actually, Shrek 2, and Wicked). You could buy the top 16 albums without having to buy anything by Usher.
The problem is not that someone has a loaded gun pointed at your head. The problem only comes when that person pulls the trigger. By all means, let them become a felon. The jail time will teach them a lesson.
Slashdot Mirror
>what we need is a wireless killer app without these concerns thwarting it
How about VOIP? Wouldn't it be interesting if you could just by a handset and start calling people for free? Perhaps at some point you'd want to make a long distance call and couldn't find a path across the free P2P network (or you wanted a QOS guarantee) which would use your paid subscription, but for a call across town, why not?
2 words: seek time. If you're copying a bigass file to/from the server, yes the network will probably be more of a bottleneck than a modern drive on a modern controller. This is probably the most likely actual use case - MP3s, downloaded installers, movies, or whatever.
However when it comes time to copy that directory with 10,000 1KB files in it to the server, network latency and disk seek time suddenly matter quite a lot, and theoretical maximum throughput doesn't matter quite so much. Also, chances are that a home file server wouldn't be a dedicated appliance with no other responsibilities, so it's worth looking into RAID performance for other overlapping duties that the server may have.
OK, I'll bite. How is binary compatibility different from API compatibility? I suspect that this may differ from language to language and from static to dynamic linking...?
.NET assemblies and Java classes but there are probably plenty of other examples out there.
Are you talking about the difference between a new OS that supports older binaries with binary interfaces but which no longer provides an SDK to use the deprecated API? If so then I guess binary compatibility would be a subset of API compatibility - in C, binary compatibility would just mean that the linker would need to be able to do its thing, but API compatibility would mean that header files would also be needed.
I say that this may be a language-dependent issue because there are languages and binary formats for which the compile-time interfaces are in the same file as the runtime implementation. In these cases, the third layer (above the implementation and declared interface) is human-readable documentation, and just withholding that would be all you could do to try to get people to stop using the old API. But if they had documentation from another source (yard sale, eBay, etc.) they could still compile against the implementation files since those have the required interface info embedded in them. I'm thinking in particular of
>they will become increasingly irrelevant like IBM has.
Have a chat with Sun, BEA, HP, SCO, Oracle, Linus, or any bank about how "irrelevant" IBM is. I think you're in for an eye-opener.
You know that trojan wasn't actually found in the wild, right? They took a proof-of-concept that someone had created and announced that their virus app could detect it.
Perhaps parent^2 should have said "no trojans in the wild"...?
It is a pretty sad argument, though. There's always that one kick-ass application that only runs on Win32, such as Visual SourceSafe or Outlook or IE 6.0 or Access or MSN Messenger. Pity the poor Mac users who can't experience all that the Windows platform has to offer.
The poster is probably talking about the iTunes Music Store functionality. I upgraded to OS X pretty early so I didn't keep track of iTunes on OS 9, so I could be wrong about that. But the music store UI isn't just plain old HTML and probably uses some new thing that is Cocoa-only.
The conspiracy to force you to upgrade is probably more like a conspiracy not to spend tons of money backporting libraries to OS 9 just so the software can work. I'm sure if they could check a checkbox and build an OS 9 version of the latest iTunes with no effort, they would. There are plenty of other reasons to upgrade to OS X.
So if folks are using DiVX but not AVI, what encapsulation are they using to keep their DiVX encoded movies in? Are you even aware that AVI and Quicktime are file formats rather than codecs?
Also I strongly disagree that "the industry" has settled on DiVX. "The industry", meaning the folks who actually have movies to sell legally, settled on MPEG 2 in the form of DVDs. I haven't seen any remotely successful online digital movie ventures, so it's hard to say what The Industry has or has not settled on.
If you expand "the industry" to mean "the other industry" that sells lots and lots of videos and images online, then please be explicit. (They certainly are.)
The phenomenon you are experiencing is called "deregulation". It's what happens when monopoly telco lobbyists write the legislation that creates a fair competitive environment for other companies to compete with said telcos. Of course, the actual legislation is anything but fair. See also: Covad vs. the "baby bells".
This is sort of like the power "deregulation" that took place in California and led to rolling blackouts and ultra high electricity and gas prices, and required a statewide bailout of the monopoly power company, Pacific Gas and Electric.
When anybody in a suit starts to wax romantic about free markets, competition, and deregulation, look for the crossed fingers behind their back and wads of dollar bills sticking out of their pockets. What they really want is to replace a regulated monopoly with an unregulated monopoly, and an inefficient government bureacracy with an unaccountable corporate pyramid scheme that leads to offshore accounts, unprecedented executive payouts, and bankruptcy (followed by an emergency government bailout). See also: Enron, Worldcom.
Real competition would be great, but that's not what we've got. What we have is legislated, goverment-subsidized monopolies paying protection money to Congress with one hand and waving a "Free markets now!" sign with the other.
Of course, the bold new twist on this scheme is to first announce that you're going to replace a government bureaucracy with an efficient outsourcing contract, and then just award the contract to your friends with no bidding process (or a secret bidding process), claiming that national security (or the interest of fair competition) forced the bidding process to be secret or to be skipped altogether. Then you can sidestep all sorts of rules and laws and replace huge sections of the government with unaccountable private corporations, and you get deniability even if you own stock in said corporation. See also: Halliburton, Bechtel.
P.S. Welcome to the USA!
>Imagine a HD TiVo, recording and watching 3 different shows/movies at the same time, pumped through your DSL line.
Or imagine broadcast TV or cable, doing the exact same thing but with DRM'd content just the way that the owners of the content like it. You want ShareReactor + eMule over a T3 and they want DirecTV. They have lawyers and lobbyists and you have...?
Imagine all the cease and desist orders you could get over that much bandwidth.
Let's face it, folks, the last mile is NOT the problem. What exactly would you use it for? There are some very rich, powerful people damming a river, and dredging the river downstream isn't going to make the water flow much faster. For everyone to have ultra broadband would be the ??AA's worst fucking nightmare.
I dunno... maybe the picture it paints is one where people are upgrading their browser because they got nailed by malware and the fix is only available for IE 6+. Maybe that will lead people to use something else when they get nailed again and there's no fix for IE 6 yet.
...and USB and SCSI and gigabit Ethernet and commodity SMP and IPv6 and...
Parent^2 was probably a troll, or maybe just ignorant, but in case anybody agrees, consider this:
If you ever take a look at the various visualization projects that show the breakdown of the Linux kernel, like this one, what you'll find is that a huge amount of code is dedicated to things that didn't even exist in 1983, and probably not in 1993 either. Most of them are hardware drivers and filesystems and networking standards that get built as modules, so you wouldn't necessarily care that there's IRDA or HFS or MIPS support, but it's there.
Yeah. God damn those on-topic posters.
You really need to study the details of the Microsoft monopoly lawsuit, and study up on antitrust law in general, because it's obvious that you haven't.
Microsoft has a monopoly. That has been proven in a court of law. What has also been proven in a court of law is that they abused this monopoly by using anti-competitive practices to make sure that they were in complete control of what was and wasn't installed on top of Windows by system vendors.
Your argument is the same one that Microsoft used. "Poor, poor users - if we let competitors or OEMs change Windows, the poor users won't get the best, most consistent user experience!" Of course this is question-begging: this argument assumes that Microsoft provides the best, most "consistent" user interface, and there's no evidence to the contrary because no one is allowed to rip out chunks of Windows and replace them with Gecko and VLC etc. or just leave those apps out, because Microsoft will revoke their OEM license.
What an end user can do with one PC to tailor it to their needs is not the issue. What an OEM is being prevented from doing on behalf of all of their customers is the issue.
As for Apple somehow having an iTunes monolpoly, you're confusing PC vendors (none of whom have a monopoly, at least in the US) with Microsoft, and anti-competitive practices with competitive practices. If Apple were able to strongarm all PC vendors into not installing WMP or RealPlayer or WinAmp or MusicMatch (etc. etc.) as a condition of installing iTunes, using an iTunes (or other Apple product) monopoly as leverage, that would be comparable to Microsoft's illegal anticompetitive monopolistic practices. Instead, the news that one PC vendor has chosen to preload iTunes doesn't mean that WMP will not be installed, and doesn't in any way give Apple a monopoly on music apps or denote illegal anticompetitive practices.
Hear, hear. Systems (software or otherwise) that offer something of monetary value for free, and provide no mechanism whatsoever to prevent people from exploiting them, are going to get exploited. Shocking!
Maybe it wasn't obvious to blog and wiki programmers that the ability to post a comment or edit a wiki page was worth money. It isn't worth a lot per post, but because these are online systems, they are very susceptible to bots that can post in huge volume. All of those posts together can alter a site's placement in Google search results, and that's definitely worth money.
Instead of whining about Google being influenced by attacks that use your Wiki or blog, how about making it hard for bots to post in the first place? Is that really an important feature that you can't live without?
Here's a link that spares you the need to scoll past a bunch of ridiculous speculation:
t hreadid=42736#post627583
http://forums.appleinsider.com/showthread.php?s=&
Also, in the process of looking at the source to figure out how to make the above URL, I found these comments in the HTML starting at line 45:
"DO NOT CHANGE THIS AGAIN
THERE NEEDS TO BE A WAY FOR MEMBERS TO RETURN TO THE CONTENT"
(some HTML code removed here)
"DO NOT EDIT ABOVE THIS LINE
GO FUCK YOURSELF - The Management"
Nice. It's always good to see design arguments that have escalated into profane insults embedded in one's publicly visible HTML source. The least they could do would be to use the scripting language's comment syntax so those little love notes wouldn't be visible to anybody looking at the source code...
>I fail to see the point in spending between $2000-$5000 for one of these displays. I don't care how many languages it speaks or what O/S it runs.
Hmm... yup, looks like I guessed right. You've only been a Slashdot user for a week, haven't you? First post 7 days ago.
Give it time.
Soon you won't even care what it does; as long as it runs Linux or has a Transmeta CPU in it, you'll want one. $5000 will seem completely acceptable for a TV set, so that you can play a pointless but cool-looking eye-candy demo on it for both of your friends, who will be soooo impressed. At the same time, the prospect of spending more than $20 on a date, doing anything not directly related to computers, or of owning any clothes other than jeans and t-shirts will start to seem like pointless wastes of money.
"Organic" farming (which is a regulatory term in some jurisdictions, not just a marketing word) and "genetically modified organisms" are unfortunately ambiguous terms that don't differentiate between food that is and is not made with those techniques, if you stick to the strict literal definition of those terms. However, don't make the mistake of thinking that this means that there is no meaning to these terms.
"New methods are just faster" - perhaps. Roughly how long would it take for DNA from an insect to work its way into a plant, through natural pollination?
It isn't very smart to take a brand new organism that has never existed before and declare it completely and totally safe to eat and superior in every way to its predecessor. GMOs are neither necessarily bad nor necessarily good. Only time, scientific testing, and risk analysis (example: famine without GMO crops vs. plenty of food but increased risk of disease with a GMO) can tell for sure.
The key issue is that manufacturers of GMOs are lobbying very hard to hide the fact that what they're selling has been unnaturally modified and has only had a few years (at the most) of testing for safe human consumption. They have lobbied in the US to make it illegal to label foods as GMO. What does that say to you about how safe they are? You can be as libertarian as you like, but the idea of a free market is based on an ideal of voluntary transactions based on a fully informed buyer and seller. Hiding this kind of information from buyers is shady at best. If GMOs are safe, nay superior, then label them with pride.
Microsoft's JVM was objectionable for two reasons.
First, Microsoft chose to leave out a required part of Java called RMI (Remote Method Invocation, which is a Java-only technology that is otherwise similar to CORBA). That means that if you wrote a 100% Pure Java application that was carefully coded to spec and happened to use RMI, it would run on any Java VM except Microsoft's. The typically alleged reason for leaving this out is that RMI also competes with DCOM. Interestingly, Microsoft offered the RMI functionality as a downloadable add-on, but Sun argued (successfully) that this wasn't good enough since the rest of the Microsoft VM was shipping with every copy of Windows.
Second, Microsoft added some language features (not just classes, but keywords and bytecodes if I remember correctly) that were not part of standard Java, and their J++ development environment used these without warning the user that they were coding for Microsoft's Java implementation only, as opposed to writing portable code.
It's important to note for the sake of comparison that Apple has made it possible to write non-portable Java applications that will only run in Mac OS X and which depend on the Cocoa API. The reason Sun isn't suing Apple for doing this is that Apple's JVM will run 100% Pure Java applications with no problem. That's the requirement that Sun makes.
The key distinction here is implementing a superset vs. subset of the spec. Microsoft shipped an implementation of a subset of the spec, and added stuff that was not in the spec. Apple ships an implementation of the *whole* spec, and has added stuff that's not in the spec. Adding stuff is allowed. Removing stuff is not allowed.
Heck, even Netscape added their LiveConnect API to their JVM, but that was OK because (copious bugs notwithstanding) their JVM would run 100% Pure Java applications.
On another topic, WABA is pretty interesting. I messed around with it (and a bunch of other mobile Java-ish environments) back in 2001. Basically WABA uses Java bytecodes but not the Java class library, so they can't call it Java without getting sued by Sun (subset + use of the Java name == lawsuit). Sun has its own J2ME (Java 2 Micro Edition) spec and runtime and SDK, which is missing some classes from the Java 2 Standard Edition class library. (Some classes are there but are reduced in functionality.) WABA isn't even J2ME compliant - for example, WABA lacks threads entirely. But, because you can just use a Java compiler on a nice juicy desktop environment and point that compiler at the WABA library, WABA lets you keep using some of your familiar J2SE/J2EE tools. With a desktop-based WABA interpreter, you even get to debug using a runtime that is too big and slow to run on a resource-limited device, but which has lots of cushy features that you'd want during development. (Eventually I decided that I really didn't enjoy trying to get stuff working on any of the available platforms because the SDKs were either missing really important features, or were just too buggy or hard to develop for.)
>If Sun GPLed Java (the VM, compiler, libraries, etc.), they could then move people to writing software in Java, and actually have Java products which they could sell for money, which would be a serious revenue stream, and should have been the plan from the start.
Um, they already do make and sell commercial software written in Java, and have for years. Whether it was a good idea to write the Solaris installer in Java, or whether they're actually making any money selling their app server, are different questions. But for Sun to *try* and write good Java applications that make money is not a novel concept.
You're also assuming that Sun makes no money on the work those people are doing, which isn't quite true. When I download the JVM and use it to build an app, then no, I'm not paying for it. But when Sun sells a server to someone who thinks that Java only runs on Solaris, or when they think that Sun's really expensive application server is necessarily much better than Tomcat or JBoss, then those people are making money.
If they GPL it and IBM were to take the lead in advancing Java's development, then those confused IT buyers would buy IBM gear and WebSphere instead.
It seems to me that Sun's Java strategy for quite a while has been to use Java as a loss leader for hardware, preying on the confused masses that haven't ever bothered to look at Java on Windows or Linux, and who just assume that it must run best on Solaris. It's stupid, but it apparently works.
However, as developers continue to shout that Linux is a dandy platform for Java applications (as is Mac OS X, as is Windows...) and as IT buyers keep reading again and again that real companies are actually using Linux and not going belly-up or crawling back to Microsoft or Sun on hands and knees begging for foregiveness, they are starting to get the idea that maybe they don't have to run Java on Sun gear.
>But JIT is STILL interpreting in the same sense perl code is interpreted (even if there are utils to compile perl as well), the code is compiled on the fly as it's loaded and then executed. AFAIK JIT compiling is really just an efficient method of interpreting.
.class files, for later execution when you run that Java program. These bytecodes are not just chunks of text from the source code; they are also not processor-native. They are instructions for an imaginary CPU (the Java "virtual machine"). Compare this to Perl, in which you usually compile from source each and every time you run the program.
.NET uses JIT compilation too, and it works similarly: you compile to files full of MSIL bytecodes, and treat that as your compiled program. When you go to run it, the .NET JIT compiler turns those MSIL bytecodes into native instructions which are run.
.NET) security model. The verifiers that check your code for adherence to the secur
No, this is incorrect.
Perl 5 initially parses the source code into an in-memory parse tree that is not processor-native machine language, nor is it bytecodes. It's a pre-parsed tree structure of tokens from the source code. The Perl 5 interpreter then executes this parsed tree.
The Java compiler bytecode compiles Java source code into Java bytecodes and typically writes them to disk in
It is possible to compile from Perl source to Perl bytecodes for later execution too, but I haven't seen anybody actually bother with this. Even if you did, what Perl does is to re-constitute the parse tree from the bytecodes, and then it interprets that.
The classic Java interpreter then treats these pre-compiled Java bytecodes as the program, emulating the imaginary CPU in software by calling functions that are part of the interpreter to handle each of the bytecodes.
According to O'Reilly's Programming Perl, Chapter 18:
"Pass 4: Code Generation
This pass is optional; it isn't used in the normal scheme of things."
and
"Please be aware that the code generators are all extremely experimental utilities that shouldn't be expected to work in a production environment. In fact, they shouldn't even be expected to work in a nonproduction environment except maybe once in a blue moon."
Yes, it's possible to generate native code from Perl source, but they way you do it is to first generate C source code, and then run that through a C compiler. In general use, though, Perl is parsed into a tree of in-memory tokens, and those are then interpreted.
This is not at all the same as what a JIT compiler does. The JIT compiler in Java encounters a chunk of bytecodes (which were previously compiled from Java source code), transforms them into a chunk of processor-native instructions, and then runs them. It doesn't run the bytecodes; if they say to add X and Y and store them in Z, a JIT compiler creates code that would do that, and then the VM runs that native code. The main drawback with a JIT compiler is that compiling from bytecode to native code adds a bit of a lag. Multiply this across a big application, and the lag is pretty serious. The benefit is that if you call that chunk of code 100,000 times during a program, the first iteration is delayed while the code is JIT compiled, but then the 100,000 iterations of that code are done by native code, so overall it's faster.
The HotSpot compiler (once experimental, now a standard part of the Java VM) has a few performance tweaks, including a sort of hedged approach to interpretation vs. JIT compilation. Basically it interprets the code the first few times and keeps track of how many times the code is called. After that, it JIT compiles it. The idea here is to make sure that it's worth the overhead of JIT compiling.
By the way,
One big reason why compiling to native code and caching that is not done is that it breaks the Java (and
The problem is that this approach still gives Sun the opportunity to do what it did to JBoss - play games with cost and availability of that test suite.
Oh, you want to release a Java derivative? Sure, you can license the test suite for only $100,000.
Yes, we got your check for $100,000, and we sent the CD with the test suite. You never got it? We definitely sent it. Want us to send another? OK, that's another $100,000. Oh, shucks. It seems that we ran out of them and have to make some more. Please allow 6-8 months for delivery.
>if Java has enough functionality already then nobody will really feel the need to add anything else
Yeah, right. Someone will always feel the need to add something else. Open source Java and on day one, somebody will release a derivative with real, actual memory pointers that utterly break the security model. Someone else will release a derivative with multiple inheritance. Yet another group will put in design by contract. Someone else (IBM?) will rip out Swing and AWT as much as possible and just leave SWT. Someone else will make all primitives into objects, etc.
Those modified versions may not necessarily be a bad thing (no matter what Sun thinks), but the idea that there could be One True Language that makes everybody happy if they just remember to put all of the right features in and none of the wrong ones is silly.
I had a book that described how to do this and had sample code. I'm pretty sure it was Understanding the Apple //e by Jim Sather, but it might have been a different book. (BTW, I no longer have that book and am looking for a copy if you have one. I've had no luck finding it via Amazon or eBay etc.)
In case anybody cares, here's how it worked:
The Apple II series was designed so that the CPU and video hardware alternated reading from memory. The memory was twice as fast as the CPU needed it to be (quite different from today's situation!). If you wanted to know what the byte value was that the video hardware had just read, all you needed to do was to read from a memory-mapped I/O address that didn't actually put anything on the data bus. There were a few I/O addresses that worked like this; just putting that address on the address bus (by reading from or writing to that address) would make something happen; the data wasn't important, so the I/O hardware would just leave the data bus alone. If you read from such an address you'd get the data that was still being put on the data bus by the RAM from the previous video hardware access.
The way to make this work for mode switching was to use a second idiosyncracy of the video hardware. For some reason (probably simplicity of implementation), during the horizontal retrace interval at the end of each scan line, the video hardware kept stepping through video memory, reading one byte at a time. Thus, there were a few undisplayed bytes that would appear on the data bus during the horizontal retrace interval, in memory that was basically just wasted. So, you could put a multi-byte signature in that area of exactly one line in display memory, and spend all of your CPU time in a loop waiting to see this signature appear. When it did, you knew which line had just been displayed, and could immediately switch video modes in the middle of the screen. You could use a few of these to display multiple video modes (low res graphics, hi res graphics, and text) on the screen in different vertical bands.
The only problem is, there's hardly any practical reason to want to do this. The CPU cost was so high that it was hard to use it for anything.
>Not so long ago, most music appealed to most of the population.
That's an interesting opinion, but the history of rock and roll is one of kids liking music that their parents considered awful and immoral. From swing to Elvis to the Beatles to psychedelic music to disco to punk to new wave to heavy metal to hip hop... every one of these styles was considered shocking by the old and exciting by the young. Jazz and ragtime are probably about the same. I wouldn't be surprised if it were true going back hundreds of years.
>Now, however, I challenge you to find any mainstream music that is halfway palatable to anyone over the age of 30.
Dido. Macy Gray. John Mayer. Thievery Corporation. OutKast. Black Eyed Peas. Norah Jones. Sarah McLachlan. These are some of my over-30 friends' favorite musicians. Whether you want to accept it or not, people DO like these artists and DO buy their albums and ARE older than 30. Just look at the iTunes Music Store's top 100 albums of the day list, or Amazon.
I challenge you to prove that "mainstream" music (let's use sales volume to define mainstreamness here) is only bought by teenagers.
Who do you think is buying XM-enabled car stereos, SACD players, 60s and 70s band reunion CDs (and the $75+ tickets to their concerts)? Do you think that jazz, classical, and country music are all teen-supported too? Diana Krall is #20 in the iTunes Music Store's "Today's Top Albums" list, and #5 on Amazon.
I think you're confusing advertising with sales. Pop music (which is mostly hip hop now) needs lots of ads because, generally speaking, the artists are one hit wonders and constantly need to be introduced to people.
OTOH, Dean Martin is at #5 on the iTunes Music Store's top albums list today. Alanis Morrissette is #2 and #77, Morrissey #12, Bob Marley #39, Cat Stevens #46, Tom Petty's and the Heartbreakers Greatest Hits #54, Dark Side of the Moon #92, ABBA Gold #98. I doubt anyone has run a Cat Stevens or Tom Petty and the Heartbreakers ad in the last 10 years.
On Amazon, in the top 25 are Alanis (#8), Eric Clapton (#10), Wilson Philips (#14), Prince (#16), Loretta Lynn (#23), and three soundtracks (Love Actually, Shrek 2, and Wicked). You could buy the top 16 albums without having to buy anything by Usher.
The problem is not that someone has a loaded gun pointed at your head. The problem only comes when that person pulls the trigger. By all means, let them become a felon. The jail time will teach them a lesson.