Is this right? The DOJ under Clinton-Reno pretty much had the MS antitrust thing sewn up years ago, but as soon as the Bush admin came to power, they changed the top brass at the DOJ and the suit was essentially dropped.
But here it is years later, and the same DOJ under the essentially the same Bush admin wants to go after Google?
The real question I've been wondering about... is Microsoft REALLY going to eventually try to rebuild Yahoo (which uses BSD and PhP) with Windows servers and ASP.NET?
Because if it does, that's not only going to be a HUGE job, but it'll probably encourage the departure of a LOT of good open-source programmers to go over to Google or some other worthy LAMP-style startup or competitor!
I should also mention the merger between PRR (Pennsylvania Railroad) and NYC (New York Central) in 1968 which turned out to be the most famous merger failure ever at the time. A big reason was the failure of the 2 "cultures" to mesh. (my handle PRR is based on the PA railroad)
Could the same thing.. a failure of corporate cultures MS and Yahoo to mesh...also doom this if it goes through?
As big screens get cheaper, is it plausable that something like the Wii-mote would make it easier to surf from the couch?
I mean, the traditional TV remote with the 4 arrow keys is sorta like a Tab key, whereas a motion-sensor/IR device like the Wii-mote allows better "pointing" directly at links (without "tabbing" through them) from a distance.
How about a full (or near full) screen version of YouTube optimized for a Wii-mote device on a large screen LCD or Plasma?
My gut feeling is that this whole thing will probably resolve fairly plainly, with the writers getting an incremental increase in pay and digital/web rights or whatever.
However, it is interesting to think of the "Unintended Consequences" angle... that this strike really forced writers and tech impresarios to get together in a way unlike before. Who knows the result?
Maybe this really will be the beginning of a significant snowball to switch over from the old "TV centric" way of watching to a "Net centric" way... which in turn might be yet another thing helping push for fatter pipes, denser screen resolutions, faster processing, etc.
Yep, the RIAA restrictions combined with NO record companies producing commercial recording available on DAT essentially relegated it to being a quasi "Pro recording" medium with only a small niche market... much smaller than it might have been without that intervention.
But by 1999, CD burners were cheap enough that anyone could *cough* "backup" *cough* a music CD. That would have killed DAT as a piracy medium right there.
By the middle of this decade high-speed home internet and P2P's would have happened anyway.
It was a good racket while it lasted... put 10 songs on a disk and sell it for $15, even though only one or two songs are any good, and you have to buy the whole thing to get them.
I see where Gene says that downloading should have been stopped early on. It makes no difference, it would have eventually happened anyway.
Anyone remember DAT cassettes? The record industry legislated them out of existance with a special tax. So what? Recordable CD's eventually came along and would have made DAT's obsolete anyway.
If Java goes GPL it may obviously attract a lot of folks from the Linux community. However, the Linux community has a lot of emphasis on C (and C++) coders who are into native compilation. Sun's agenda has been for Java to be "WORA" with lots of emphasis on VM's, bytecode, etc.
Will Java going GPL open up the floodgates to lots of Linux C/C++ coders who are more into native compilation, and not Sun's "WORA" agenda of VM's and bytecode?
Is there anyone else out there who thinks that Sun put too much emphasis on "WORA" with Java with bytecode objects (.class files) run through a JIT compiler, which tended to have generally slower startup times and larger files, as opposed to Sun offering the option of native compilation with their SDK for native executables?
Would Sun offering native compilation for Java have helped?
Let's hope all the major distros eventually adopt these true-type fonts as the defacto defaults. I had no problems doing the ttmkfont trick myself, but I'm sure it was a bit confusing for many newbies. This will make Linux/Gnome/KDE/etc much more easier for the non-tech crowd to adopt!
Since the Bitstream people were kind enough to be the first to donate a good TTF for use with Linux, would it be likely that Gnome/KDE would standardize on Bitstream Vera as the default (true type) font for their desktops?
Any word on the Bitstream Vera fonts?
on
KDE 3.1 Released
·
· Score: 1
Ever since the announcment last week of Bitstream making their Vera TTF's available to the Gnome foundation as well as any other Linux-related group who wants to package them... has there been any word on the KDE lists/forums about any plans to incorporate those fonts into future versions of KDE?
Eclipse and Jet look promising on the client side
on
The Future of Java?
·
· Score: 1
While many have their doubts about Swing and the notion of JIT compiled bytecode being a memory hog and a bit sluggish on the client side, there's some good stuff being developed:
The Eclipse project is working with the SWT which uses the native widgets of the host operating system, to provide a good responsive GUI
http://www.eclipse.org/
Companies like Excelsior are producing native compilers which speed things up (and reduce memory consumption) even morseo. JET also supports SWT, giving native compilation combined with the host OS native widgets. In some cases, you don't even need the JRE for your compiled Java apps!
I'm familiar with both RH and Mandrake, and as far as I can tell, RH is still using 386 packages instead of 586 like Mandrake. Why is this? You would think that nearly everyone has a CPU appropriate for 586 stuff by now. What's up?
Any plans in the near future for RH to go to 586 packages?
I get the TigerDirect catalog every few weeks, and I'm amazed at how inexpensive all the x86 hardware has become.
Last week I went into a local CompUSA, and they had some Apple reps there among the Macs taking questions. I commented on how I love the OS, but the hardware is just too expensive for me. (I'm sure this is the comment they get trained to answer the most) Her reply was "Why, it's not that expensive at all now, a G4 only costs $1600." To which I politely smiled and thought to myself how I could build a couple AMD boxes for that much.
Otherwsie, I really like being able to launch a terminal (within the OSX GUI) with a shell (ksh?) in it, just like Linux!:)
Hardly anyone will use Java for traditional client-side apps because it's got a longish startup time, uses a lot of memory, and Swing sometimes generally has a sluggish feel when running.
Why? Because of using byte-code objects running (interpreted) through a JVM. And why was that? WORA! Sun wanted bytecode object "applications" to be able to run on any OS that had a JVM.
If Sun had the option in it's JDK of allowing compiling apps to native code, they would have run faster, and with a smaller memory footprint. But the source would have to be recompiled for each OS, which went against Sun's WORA religion.
There are some native compilers out there now (GCJ, Exclesior JET, JOVE) which are pretty good, but fairly obscure. If Sun had gotten behind offering a native compilation option from the beginning, Java might have had a chance on the client side.
As much as I like Linux/KDE, I find myself too frequently having to reboot into Windows because of some commercial app that there's no Linux equivalent for as yet.
The biggest problem I would suppose for app developers (aside from Linux market share) is that there's no one standard API for Linux desktop apps because of all the competing distros. At least with Win and Mac the app developers have a clearer API to work with.
If I could get MacOSX for cheap x86 hardware, I'd switch in a second!
Not to start a flamewar but... I currently use RH7.2. However, the thing I'm mostly using it for is KDE and regular desktop stuff. Would I be better off using MDK because it's apparently built more closely with KDE in mind? (It is, isn't it?)
Also, my M/B and CPU are fairly recent (1.4Ghz Athlon w. DDR) and apparently MDK is tweaked more towards i586/i686 compared to RH?
(I posted this in another thread) Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
You would think that Sun, of all folks, would do a separate desktop based around Swing to showcase their Java technologies just as Trolltech contributes to KDE to showcase their Qt.
Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.
It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.
There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.
Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.
Java is the Virtual Machine. Without it, no Java
the binary output
Java is a LANGUAGE. You can compile it down to native code like GCJ or Jove can do, or you can bytecode compile it to a bytecode object like the Sun/IBM JDK for use with JVM-JIT compilers (what Sun calls a "binary output".class file is really a bytecode object... not a true native binary in the classic sense)
the primary intent of the platform
The primary intent of the "platform" was beating M$. Look at all the Java propaganda, what is the feature that always gets mentioned first? (particularly Sun) WORA! Java is not bytecode compiled and run on JVM's primarily for pure technical reasons... it's done so mainly because Sun wanted to come up with something to beatup M$ in the marketplace, and a development tool which produced extremely portable apps (not so centric to one OS) was supposedly that magic bullet. However, in order to achieve that agenda, native compilation couldn't be part of it because recompilation just doesn't fit the definition of WORA as Sun sees it. It would have to be bytecode compiled and that object run on whatever platform has a JVM. Instead of the menory and speed constraints of being bytecode-complied for WORA, Java has been relegated mostly for use on boxes with lots of ram and cpu... servers! Swing has failed on the desktop due to speed/memory issues and even IBM has decided to go with SWT which uses native widgets. Wake up! I like the Java LANGUAGE, but all I'm saying is let's look past this WORA/JVM stuff and see what happens with a Sun-backed native compiler... at least for Swing on the desktop.
Stop being so beholden to WORA and having this bytecode object "binary" which can run on many platforms. Recompiling the src for different platforms is not that big of a deal and not too far from WORA.
Will Sun ever make a native compiler for Java which allows for binary executables?
The advantage of native compilation (as the GCJ folks already know) is a bit of improvement in performance, as well as a reduction in startup time amd memory usage because JVM/JIT compilation is not needed (though the runtime still is). Sun has already put a lot of optimization tricks into Hotspot, so putting all that into a native compiler shouldn't be too hard. Native compilation would probably be most beneficial for desktop apps using Swing.
Slashdot Mirror
Is this right? The DOJ under Clinton-Reno pretty much had the MS antitrust thing sewn up years ago, but as soon as the Bush admin came to power, they changed the top brass at the DOJ and the suit was essentially dropped.
But here it is years later, and the same DOJ under the essentially the same Bush admin wants to go after Google?
Ok, what's up?
The real question I've been wondering about... is Microsoft REALLY going to eventually try to rebuild Yahoo (which uses BSD and PhP) with Windows servers and ASP.NET?
Because if it does, that's not only going to be a HUGE job, but it'll probably encourage the departure of a LOT of good open-source programmers to go over to Google or some other worthy LAMP-style startup or competitor!
I should also mention the merger between PRR (Pennsylvania Railroad) and NYC (New York Central) in 1968 which turned out to be the most famous merger failure ever at the time. A big reason was the failure of the 2 "cultures" to mesh. (my handle PRR is based on the PA railroad)
...also doom this if it goes through?
Could the same thing.. a failure of corporate cultures MS and Yahoo to mesh
Anyone watching GOOG? (Ironically on Yahoo Finance)
As of hign noon EST it's down about 8.5%
As big screens get cheaper, is it plausable that something like the Wii-mote would make it easier to surf from the couch?
I mean, the traditional TV remote with the 4 arrow keys is sorta like a Tab key, whereas a motion-sensor/IR device like the Wii-mote allows better "pointing" directly at links (without "tabbing" through them) from a distance.
How about a full (or near full) screen version of YouTube optimized for a Wii-mote device on a large screen LCD or Plasma?
My gut feeling is that this whole thing will probably resolve fairly plainly, with the writers getting an incremental increase in pay and digital/web rights or whatever.
However, it is interesting to think of the "Unintended Consequences" angle... that this strike really forced writers and tech impresarios to get together in a way unlike before. Who knows the result?
Maybe this really will be the beginning of a significant snowball to switch over from the old "TV centric" way of watching to a "Net centric" way... which in turn might be yet another thing helping push for fatter pipes, denser screen resolutions, faster processing, etc.
Yep, the RIAA restrictions combined with NO record companies producing commercial recording available on DAT essentially relegated it to being a quasi "Pro recording" medium with only a small niche market... much smaller than it might have been without that intervention.
But by 1999, CD burners were cheap enough that anyone could *cough* "backup" *cough* a music CD. That would have killed DAT as a piracy medium right there.
By the middle of this decade high-speed home internet and P2P's would have happened anyway.
It was a good racket while it lasted... put 10 songs on a disk and sell it for $15, even though only one or two songs are any good, and you have to buy the whole thing to get them.
I see where Gene says that downloading should have been stopped early on. It makes no difference, it would have eventually happened anyway.
Anyone remember DAT cassettes? The record industry legislated them out of existance with a special tax. So what? Recordable CD's eventually came along and would have made DAT's obsolete anyway.
If Java goes GPL it may obviously attract a lot of folks from the Linux community. However, the Linux community has a lot of emphasis on C (and C++) coders who are into native compilation. Sun's agenda has been for Java to be "WORA" with lots of emphasis on VM's, bytecode, etc.
Will Java going GPL open up the floodgates to lots of Linux C/C++ coders who are more into native compilation, and not Sun's "WORA" agenda of VM's and bytecode?
Is there anyone else out there who thinks that Sun put too much emphasis on "WORA" with Java with bytecode objects (.class files) run through a JIT compiler, which tended to have generally slower startup times and larger files, as opposed to Sun offering the option of native compilation with their SDK for native executables?
Would Sun offering native compilation for Java have helped?
Thank you Bitstream!
Let's hope all the major distros eventually adopt these true-type fonts as the defacto defaults. I had no problems doing the ttmkfont trick myself, but I'm sure it was a bit confusing for many newbies. This will make Linux/Gnome/KDE/etc much more easier for the non-tech crowd to adopt!
Since the Bitstream people were kind enough to be the first to donate a good TTF for use with Linux, would it be likely that Gnome/KDE would standardize on Bitstream Vera as the default (true type) font for their desktops?
Ever since the announcment last week of Bitstream making their Vera TTF's available to the Gnome foundation as well as any other Linux-related group who wants to package them... has there been any word on the KDE lists/forums about any plans to incorporate those fonts into future versions of KDE?
While many have their doubts about Swing and the notion of JIT compiled bytecode being a memory hog and a bit sluggish on the client side, there's some good stuff being developed:
The Eclipse project is working with the SWT which uses the native widgets of the host operating system, to provide a good responsive GUI
http://www.eclipse.org/
Companies like Excelsior are producing native compilers which speed things up (and reduce memory consumption) even morseo. JET also supports SWT, giving native compilation combined with the host OS native widgets. In some cases, you don't even need the JRE for your compiled Java apps!
http://www.excelsior-usa.com/jet.html
I'm familiar with both RH and Mandrake, and as far as I can tell, RH is still using 386 packages instead of 586 like Mandrake. Why is this? You would think that nearly everyone has a CPU appropriate for 586 stuff by now. What's up?
Any plans in the near future for RH to go to 586 packages?
I get the TigerDirect catalog every few weeks, and I'm amazed at how inexpensive all the x86 hardware has become.
:)
Last week I went into a local CompUSA, and they had some Apple reps there among the Macs taking questions. I commented on how I love the OS, but the hardware is just too expensive for me. (I'm sure this is the comment they get trained to answer the most) Her reply was "Why, it's not that expensive at all now, a G4 only costs $1600." To which I politely smiled and thought to myself how I could build a couple AMD boxes for that much.
Otherwsie, I really like being able to launch a terminal (within the OSX GUI) with a shell (ksh?) in it, just like Linux!
Hardly anyone will use Java for traditional client-side apps because it's got a longish startup time, uses a lot of memory, and Swing sometimes generally has a sluggish feel when running.
Why? Because of using byte-code objects running (interpreted) through a JVM. And why was that? WORA! Sun wanted bytecode object "applications" to be able to run on any OS that had a JVM.
If Sun had the option in it's JDK of allowing compiling apps to native code, they would have run faster, and with a smaller memory footprint. But the source would have to be recompiled for each OS, which went against Sun's WORA religion.
There are some native compilers out there now (GCJ, Exclesior JET, JOVE) which are pretty good, but fairly obscure. If Sun had gotten behind offering a native compilation option from the beginning, Java might have had a chance on the client side.
As much as I like Linux/KDE, I find myself too frequently having to reboot into Windows because of some commercial app that there's no Linux equivalent for as yet.
The biggest problem I would suppose for app developers (aside from Linux market share) is that there's no one standard API for Linux desktop apps because of all the competing distros. At least with Win and Mac the app developers have a clearer API to work with.
If I could get MacOSX for cheap x86 hardware, I'd switch in a second!
Not to start a flamewar but... I currently use RH7.2. However, the thing I'm mostly using it for is KDE and regular desktop stuff. Would I be better off using MDK because it's apparently built more closely with KDE in mind? (It is, isn't it?)
Also, my M/B and CPU are fairly recent (1.4Ghz Athlon w. DDR) and apparently MDK is tweaked more towards i586/i686 compared to RH?
(I posted this in another thread) Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
You would think that Sun, of all folks, would do a separate desktop based around Swing to showcase their Java technologies just as Trolltech contributes to KDE to showcase their Qt.
One of the best articles on native compilation is this performance report
Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 threads which discuss native compilation.
Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.
It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.
There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.
Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.
Java is the Virtual Machine. Without it, no Java
.class file is really a bytecode object... not a true native binary in the classic sense)
the binary output
Java is a LANGUAGE. You can compile it down to native code like GCJ or Jove can do, or you can bytecode compile it to a bytecode object like the Sun/IBM JDK for use with JVM-JIT compilers (what Sun calls a "binary output"
the primary intent of the platform
The primary intent of the "platform" was beating M$. Look at all the Java propaganda, what is the feature that always gets mentioned first? (particularly Sun) WORA! Java is not bytecode compiled and run on JVM's primarily for pure technical reasons... it's done so mainly because Sun wanted to come up with something to beatup M$ in the marketplace, and a development tool which produced extremely portable apps (not so centric to one OS) was supposedly that magic bullet. However, in order to achieve that agenda, native compilation couldn't be part of it because recompilation just doesn't fit the definition of WORA as Sun sees it. It would have to be bytecode compiled and that object run on whatever platform has a JVM. Instead of the menory and speed constraints of being bytecode-complied for WORA, Java has been relegated mostly for use on boxes with lots of ram and cpu... servers! Swing has failed on the desktop due to speed/memory issues and even IBM has decided to go with SWT which uses native widgets. Wake up! I like the Java LANGUAGE, but all I'm saying is let's look past this WORA/JVM stuff and see what happens with a Sun-backed native compiler... at least for Swing on the desktop.
Stop being so beholden to WORA and having this bytecode object "binary" which can run on many platforms. Recompiling the src for different platforms is not that big of a deal and not too far from WORA.
Will Sun ever make a native compiler for Java which allows for binary executables?
The advantage of native compilation (as the GCJ folks already know) is a bit of improvement in performance, as well as a reduction in startup time amd memory usage because JVM/JIT compilation is not needed (though the runtime still is). Sun has already put a lot of optimization tricks into Hotspot, so putting all that into a native compiler shouldn't be too hard. Native compilation would probably be most beneficial for desktop apps using Swing.