You will *ALWAYS* be able to wait a few months and get faster hardware than you could have before.. it is a matter of support- if a company is only partially serious about supporting linux, they can release a driver that doesn't work, keep it in beta, then eventually have it fade out to obsolecence because they don't keep it up-to-date with libc, linux kernel, etc. If you release the source (or documentation on the part, as Matrox did) then the users become maintainers, at least in the linux world where the users have good heads on their shoulders. Look at the SBLive!, the damn thing still won't work for me and they are on their third release. I paid $120 for it, and I am almost ready to buy a $12 sound card and scrap the thing, so that I can at least listen to CDs in Linux. That said, nVidia released rather undocumented, obfusciatory (thats the word of the day) source, and nobody is maintaining it because you can't really understand what it does. You can't add things to it, for instance DRI support or AGP support, because those features aren't in the original code, so there is no way to know what the setup registers are. I'd prefer to vote with my money NOW and get a G400 Max, and then if other vendors wise up (and make a significantly faster/better part) then buying that part later as an upgrade. G400 Max is blazingly fast in Linux with GLX, and has people actively handling bugs, not releasing source and dissappearing into the ether like nVidia did, or having one person who doesn't even work for them handle all bugs in their spare time like 3Dfx.
You could do something similar to Jini as far as distributed lookup services in C++, but I would like to see you make the networked printer serve off drivers that are platform independant. Open Source has something rather close to this, called the source.tgz file. That is hardly automatic (and requires hacking for every platform, ESPECIALLY with device drivers which may hack hardware, use system APIs, or rely on byte order)
the DATE type used in microsoft products is a double. So while you lose precision as you go on (in a couple thousand years it will not be accurate to the millisecond) it never wraps around until a "Very high number" (expect the universe to be ended by then)
blackdown has always gone on the Sun code.. it was just that before they had to jump through the hurdles for every new release, whereas now they are given access to things like the Java Compatibility Kit (available only for paying licensees usually) so that they can officially be Java on Linux. A very nice move, but to get that the Linux Blackdown team had to negotiate a bit, including working under a slightly more stringent license than the SCSL.. I know they were under a tough license before the SCSL came out, I don't know if they were ever 'upgraded' though
It gets really discouraging sometimes to watch people battle against one another with competing technologies.. especially since usually the ones battling in the open are the ones who are actually doing the least amount of productive 'work' helping their own side.
I too hope that both Java and Linux find their niches, and find a peaceful co-existance. Some people run Windows to play games, I do it because I need solid java development tools. And, of course, to play games =)
Yeah, ok.. remember the processor speed of a Super Nintendo? Like 8 MHz? Its great how a 266 MHz computer with 64 Megs of ram can emulate a console that was made 9 years ago..
I believe the AWT stuff is in a separate lib(checking... jawt.dll in the Windows JRE). It is just loaded at runtime if you use an AWT class. Under windows this is dynamic, on other OSes it depends on the implementer I think (but I would sure hope it is dynamic)
Since they own the Java trademark, how do they ensure they will not lose value by doing this? If people can arbitrarily compile broken versions of java and release them, how do they make sure that the average consumer (who can't get applets stop crashing with Slackware Java) understands that it isn't a problem with java, it was that the Slackware version has bugs?
How do you prevent the GTK/QT porters from splitting off their own version of java once Sun refuses to include their changes in the 'official' java release? Creating two, non-interoperable versions of the language?
If you can figure out a way to release java Open source without having people able to release incompatible versions of java, devaluing both the language and Sun's investment in the language, be sure to tell me. The two are totally in conflict, which is why you'll note that Sun's source license is Open source EXCEPT for this issue
Yup.. *grin* if only people could see how annoying those little inoperabilities are and how much of a headache they are.. and realize just how much worse they would be if there could be "Joe's Cup-O-Joe Java" based on his distribution of the compiled java source..
The two issues I have seen is GUI breakage between different OSes and Video cards on Windows (things breaking moving from 95 to 98 to 98SE to NT4 to Windows2k where the AWT stuff won't even start for me) and thread problems, although my threading is pretty basic so they haven't been _my_ threading problems.
Its still all pretty developmental, but then again (oh I am going to get flamed for this...) look at GCC 2.7.2.3 vs. 2.95.. can't compile so much code that uses the old ASM, compiles a ton of code incorrectly, the generating of incorrect code is the worst.. and a rather incomplete C++ implementation. I feel sorry for the C++ people, because there is just _so much_ in that damn language.. its fine for developing with usually, but writing a compiler.. ughh
Go to alphaworks.ibm.com and see how much they are 'jumping ship'. Look into the HP java stuff. Don't just talk out of your butt. These companies are all still VERY big on java, and yes they are gaining interest in Linux too, for some of the same reasons (possibilities for the future, clean design, openness*)
*Where openness does not mean Open Sourced, but Open in a more classical sense.
So in other words, C is platform-independant for the 9% of desktop computers that aren't running Windows?;-) Oh yeah, forgot to take out the macintosh market too.. wow, what portability...
Not saying you can't have portability in C, just that it is lots of hard, grueling work. Whereas with java, portability is something you only lose based on usage of non-Pure packages (like the one I'm writing right now... *grin*)
I have never gotten a SINGLE program to use configure correctly on Windows. I have also had problems with it on Linux, with GIMP, GTK, GNOME, and several other programs.. Linux/x86, isn't that their development platform even?
C++ is processor-portable sourcecode. It is not platform independant, you still have to find out every platform's details and hack those in. That does not compare at all to platform independant and binary-portable code of java.
If you are going to compare anything being better than java, choose perl, or Emacs LISP (which is by the way one of the things Java bytecode is based on from my understanding).
except all your changes to the java source are nil, you cannot get Sun to accept your patches because they could then not do their massive relicensing (since you own some of the code). You would have to license it all to them. They also would have to defend the copywrite and trademarks very vigurously, because of people getting the source to compile on linux, releasing it 'hey, I got java to compile, it runs my hello world program super-fast!' and it doesn't run anything else at all. In other words- without a stricter license than the GPL they lose control of the language growth, the value of their trademark, and the perceived value of their code (which is VERY high, many enterprise applications using java). What is the benefit to them again over the SCSL? To make the Linux community happy? ha! Guess what, the FreeBSD community would be pissed off at having it GPL'd as well, so there would still be open source initiatives to do a clean-room implementation of java. Wow, we've come so far... Also finally, note that the GPL specifically ALLOWS for linking against system files, for instance.. with Internet Explorer, in a DLL.
most corporate IT departments have a five-year upgrade cycle. Which means, if they switch now, it will be five years before they reevaluate alternatives anyways
(Heard about the USS Wyld Stallyn) Captain Bill:Whoa, you totally bones that Klingon in the Head, First Officer Ted! First Officer Ted: Yeah, he was a real bonehead!
They are a hardware company. Making their OS under the GPL would totally screw them. Of course they have no problems with linux on the PPC because it encourages people to buy their hardware to run it (they are a minority in the market), but they aren't going to give up the source for their GUI so that people can take cheap x86's and run OS X.
To use USB, there must be a computer (or at least an intelligent hub) in order to allow transmisions; you can't just go camera to camera. FireWire makes no such demand: you can easily connect two cameras directly, with no hub whatsoever.
Yes, but you cannot connect any firewire device to any other- they are universally compatible. For instance, you can't plug a Firewire DVD into your camcorder to tape your favorite movie while in blockbuster (hurry! hurry!)
With computer control, you get the ability to have drivers upgraded for new devices, that is if they device doesn't conform to standards already in place (like the human interface device standard)
5. FireWire guarantees speed.
FireWire can say to a device, "You need a constant 200 Mbps data flow? Sure!" Whereas with USB, it's more like, "well, if your friends don't hog the bus too much, I'll see what I can do." No promised rates.
There is a guaranteed rate, but it is computer-controlled, not device controlled. If the operating system cheats you, you can't blame the standard right? But on the other hand, the standard is a bit weak on how a new device is supposed to convince the OS to negotiate more space than the leftovers it has. I haven't read the IEEE specs, so I don't know if they account for renegotiation.
Re:FireWire and USB are not one in the same.
on
Is firewire dying?
·
· Score: 2
There has to be communication logic in both places though. At least with USB you can have one 'dumb' device like a keyboard or mouse that only takes commands to itself over USB, runs them through the mechanism, and gives back a state value or binary from the eeprom. If you have mutual data transfer going on between two devices, they both have to be smart.
For instance, I hook a USB-enabled hard disk up to my computer, and all it does is look at the driver and send seek messages, read/write messages, etc to it. With firewire, the device has to be smart enough how to load and save files from itself. A Firewire DVD player, for instance, has to send _encrypted_ video over the wire, and the connecting host has to have the logic to decrypt the data. This is a good example of devices getting very complicated and how not having a device in control limits forward-compatibility (supporting devices you haven't seen yet)
Firewire is cool (although it looks to be little more than a network with device-powering built in). USB is cool too, it was designed with manufacture of cheap devices in mind. The implementation of USB is much cheaper right now, both in devices and on the motherboard, so Firewire's main advantage is speed and disadvantage is price. While I see Apple doing much to market its advantage, they are also doing things like charging for usage, which makes the price differential even higher.
Unfortunately it is hard to compare a USB device against a Firewire device since they are completely different markets, but you can add a USB-enabled microcontroller to your hardware to make it USB-compatible for under a dollar. Firewire costs a more than that just to license.
Re:You don't want USB 2.0 for pro stuff
on
Is firewire dying?
·
· Score: 1
Thats simply not true based on their internal design specs. Hubs supporing USB 2.0 are switched, they have mini host controllers inside of them and proxy the packets from 1 Mbps or 12 Mbps up to the final speed.
As someone pointed out, it is general mockery - if your sole argument against the BSD license is that 'people don't have to return modifications/ improvements to my code' and then relicense the BSD and make modifications, you are essentially DENYING the original author the right to use your modifications. It is hypocritical to first say 'I think it is a right for my software to always remain free' and then directly violate that freedom with respect to the original author (even though he never requested it in the first place)
Slashdot Mirror
You will *ALWAYS* be able to wait a few months and get faster hardware than you could have before.. it is a matter of support- if a company is only partially serious about supporting linux, they can release a driver that doesn't work, keep it in beta, then eventually have it fade out to obsolecence because they don't keep it up-to-date with libc, linux kernel, etc. If you release the source (or documentation on the part, as Matrox did) then the users become maintainers, at least in the linux world where the users have good heads on their shoulders. Look at the SBLive!, the damn thing still won't work for me and they are on their third release. I paid $120 for it, and I am almost ready to buy a $12 sound card and scrap the thing, so that I can at least listen to CDs in Linux. That said, nVidia released rather undocumented, obfusciatory (thats the word of the day) source, and nobody is maintaining it because you can't really understand what it does. You can't add things to it, for instance DRI support or AGP support, because those features aren't in the original code, so there is no way to know what the setup registers are. I'd prefer to vote with my money NOW and get a G400 Max, and then if other vendors wise up (and make a significantly faster/better part) then buying that part later as an upgrade. G400 Max is blazingly fast in Linux with GLX, and has people actively handling bugs, not releasing source and dissappearing into the ether like nVidia did, or having one person who doesn't even work for them handle all bugs in their spare time like 3Dfx.
The correct use is "GNU/Legos", get it right
:)
You could do something similar to Jini as far as distributed lookup services in C++, but I would like to see you make the networked printer serve off drivers that are platform independant. Open Source has something rather close to this, called the source.tgz file. That is hardly automatic (and requires hacking for every platform, ESPECIALLY with device drivers which may hack hardware, use system APIs, or rely on byte order)
the DATE type used in microsoft products is a double. So while you lose precision as you go on (in a couple thousand years it will not be accurate to the millisecond) it never wraps around until a "Very high number" (expect the universe to be ended by then)
mostly functional..?
*grin* I'm actually a hybrid - I like everything but the middle ;-)
blackdown has always gone on the Sun code.. it was just that before they had to jump through the hurdles for every new release, whereas now they are given access to things like the Java Compatibility Kit (available only for paying licensees usually) so that they can officially be Java on Linux. A very nice move, but to get that the Linux Blackdown team had to negotiate a bit, including working under a slightly more stringent license than the SCSL.. I know they were under a tough license before the SCSL came out, I don't know if they were ever 'upgraded' though
It gets really discouraging sometimes to watch people battle against one another with competing technologies.. especially since usually the ones battling in the open are the ones who are actually doing the least amount of productive 'work' helping their own side.
I too hope that both Java and Linux find their niches, and find a peaceful co-existance. Some people run Windows to play games, I do it because I need solid java development tools. And, of course, to play games =)
Yeah, ok.. remember the processor speed of a Super Nintendo? Like 8 MHz? Its great how a 266 MHz computer with 64 Megs of ram can emulate a console that was made 9 years ago..
I believe the AWT stuff is in a separate lib(checking... jawt.dll in the Windows JRE). It is just loaded at runtime if you use an AWT class. Under windows this is dynamic, on other OSes it depends on the implementer I think (but I would sure hope it is dynamic)
How do you prevent the GTK/QT porters from splitting off their own version of java once Sun refuses to include their changes in the 'official' java release? Creating two, non-interoperable versions of the language?
If you can figure out a way to release java Open source without having people able to release incompatible versions of java, devaluing both the language and Sun's investment in the language, be sure to tell me. The two are totally in conflict, which is why you'll note that Sun's source license is Open source EXCEPT for this issue
The two issues I have seen is GUI breakage between different OSes and Video cards on Windows (things breaking moving from 95 to 98 to 98SE to NT4 to Windows2k where the AWT stuff won't even start for me) and thread problems, although my threading is pretty basic so they haven't been _my_ threading problems.
Its still all pretty developmental, but then again (oh I am going to get flamed for this...) look at GCC 2.7.2.3 vs. 2.95.. can't compile so much code that uses the old ASM, compiles a ton of code incorrectly, the generating of incorrect code is the worst.. and a rather incomplete C++ implementation. I feel sorry for the C++ people, because there is just _so much_ in that damn language.. its fine for developing with usually, but writing a compiler.. ughh
*Where openness does not mean Open Sourced, but Open in a more classical sense.
Not saying you can't have portability in C, just that it is lots of hard, grueling work. Whereas with java, portability is something you only lose based on usage of non-Pure packages (like the one I'm writing right now... *grin*)
C++ is processor-portable sourcecode. It is not platform independant, you still have to find out every platform's details and hack those in. That does not compare at all to platform independant and binary-portable code of java.
If you are going to compare anything being better than java, choose perl, or Emacs LISP (which is by the way one of the things Java bytecode is based on from my understanding).
except all your changes to the java source are nil, you cannot get Sun to accept your patches because they could then not do their massive relicensing (since you own some of the code). You would have to license it all to them. They also would have to defend the copywrite and trademarks very vigurously, because of people getting the source to compile on linux, releasing it 'hey, I got java to compile, it runs my hello world program super-fast!' and it doesn't run anything else at all. In other words- without a stricter license than the GPL they lose control of the language growth, the value of their trademark, and the perceived value of their code (which is VERY high, many enterprise applications using java). What is the benefit to them again over the SCSL? To make the Linux community happy? ha! Guess what, the FreeBSD community would be pissed off at having it GPL'd as well, so there would still be open source initiatives to do a clean-room implementation of java. Wow, we've come so far... Also finally, note that the GPL specifically ALLOWS for linking against system files, for instance.. with Internet Explorer, in a DLL.
most corporate IT departments have a five-year upgrade cycle. Which means, if they switch now, it will be five years before they reevaluate alternatives anyways
(Heard about the USS Wyld Stallyn) Captain Bill:Whoa, you totally bones that Klingon in the Head, First Officer Ted! First Officer Ted: Yeah, he was a real bonehead!
They are a hardware company. Making their OS under the GPL would totally screw them. Of course they have no problems with linux on the PPC because it encourages people to buy their hardware to run it (they are a minority in the market), but they aren't going to give up the source for their GUI so that people can take cheap x86's and run OS X.
Oh man, now you are going to give me bad dreams...
To use USB, there must be a computer (or at least an intelligent hub) in order to allow transmisions; you can't just go camera to camera. FireWire makes no such demand: you can easily connect two cameras directly, with no hub whatsoever.
Yes, but you cannot connect any firewire device to any other- they are universally compatible. For instance, you can't plug a Firewire DVD into your camcorder to tape your favorite movie while in blockbuster (hurry! hurry!)
With computer control, you get the ability to have drivers upgraded for new devices, that is if they device doesn't conform to standards already in place (like the human interface device standard)
5. FireWire guarantees speed.
FireWire can say to a device, "You need a constant 200 Mbps data flow? Sure!" Whereas with USB, it's more like, "well, if your friends don't hog the bus too much, I'll see what I can do." No promised rates.
There is a guaranteed rate, but it is computer-controlled, not device controlled. If the operating system cheats you, you can't blame the standard right? But on the other hand, the standard is a bit weak on how a new device is supposed to convince the OS to negotiate more space than the leftovers it has. I haven't read the IEEE specs, so I don't know if they account for renegotiation.
There has to be communication logic in both places though. At least with USB you can have one 'dumb' device like a keyboard or mouse that only takes commands to itself over USB, runs them through the mechanism, and gives back a state value or binary from the eeprom. If you have mutual data transfer going on between two devices, they both have to be smart.
For instance, I hook a USB-enabled hard disk up to my computer, and all it does is look at the driver and send seek messages, read/write messages, etc to it. With firewire, the device has to be smart enough how to load and save files from itself. A Firewire DVD player, for instance, has to send _encrypted_ video over the wire, and the connecting host has to have the logic to decrypt the data. This is a good example of devices getting very complicated and how not having a device in control limits forward-compatibility (supporting devices you haven't seen yet)
Firewire is cool (although it looks to be little more than a network with device-powering built in). USB is cool too, it was designed with manufacture of cheap devices in mind. The implementation of USB is much cheaper right now, both in devices and on the motherboard, so Firewire's main advantage is speed and disadvantage is price. While I see Apple doing much to market its advantage, they are also doing things like charging for usage, which makes the price differential even higher.
Unfortunately it is hard to compare a USB device against a Firewire device since they are completely different markets, but you can add a USB-enabled microcontroller to your hardware to make it USB-compatible for under a dollar. Firewire costs a more than that just to license.
Thats simply not true based on their internal design specs. Hubs supporing USB 2.0 are switched, they have mini host controllers inside of them and proxy the packets from 1 Mbps or 12 Mbps up to the final speed.
Please describe what 'GNU' stands for. Do not use any acronyms in your answer. I kinda like GPV :) I might use that from now on.
As someone pointed out, it is general mockery - if your sole argument against the BSD license is that 'people don't have to return modifications/ improvements to my code' and then relicense the BSD and make modifications, you are essentially DENYING the original author the right to use your modifications. It is hypocritical to first say 'I think it is a right for my software to always remain free' and then directly violate that freedom with respect to the original author (even though he never requested it in the first place)