We're talking about wired connections here, in particular, the advantages of a standard connector over a proprietary "dock" connector. So I find that AirPlay is not relevant in this discussion; but since you brought it into, I'll tell you my opinion. A USB connector is found on ANY recent TV set, AirPlay isn't. A USB connector is found on (almost) ANY car stereo, AirPlay isn't. A USB connector is found on ANY standalone printer, AirPlay isn't. AirPlay depletes the phone's battery, a USB cable doesn't; a USB cable will work with products from any manufacturer, AirPlay won't. A standard plug lowers the costs, so my point is that thanks to this, I can afford to connect my phone to just about any consumer electronics device out there, instead of needing to pay the premium price of an AirPlay-enabled one.
Yeah, the iPhone can offer tethering ether via WiFi, bluetooth, or over USB.
I don't doubt that, we were talking about the fact that Android devices can do that with a standard cable and with no special drivers required. I believe this is better.
Knowing that almost any hotel will have a dock for an iPhone so that I can connect without a cable is far from a hindrance.
Bad news for hotel owners then: Apple is changing the dock connector on the next iPad, so they'll have to upgrade their equipment. Another reason why proprietary connectors are bad.
Also I am really wondering how your device charges while you are running video out to a TV...
By draining power from the USB cable, as specified by the USB standard?
Well said. I also like the fact that I can connect an android phone to a printer and print photos. Or connect an android phone to a TV and watch video clips. Or connect an android phone to a car stereo and play mp3s. Or connect an android phone to a PC and access the internet. And the phone will recharge while doing any of the above. Where the USB MSD protocol fails, MTP can do better. A "dock" would only be a hindrance, and limit the possible form factors of Android devices.
This is not applicable to non technical users which happens to be Ubuntu's intended target audience.
If you can use the graphics mode CD, you can use the text-mode CD. The questions are the same. Otherwise you shouldn't be installing an operating system, really.
Windows is rather expensive for a glorified boot loader
On the other hand, a working dvd reader is extremely cheap.
Upgrading takes ages compared to installing especially running on old hardware or netbooks. Finding old Ubuntu images is not trivial. It's very user unfriendly to make people download hundreds of MBs of patches when installing their new OS.
Beggars can't be choosers. Finding old ubuntu images is trivial. You'll need to download the packages anyway, it doesn't change if you download them in the form of an ISO image or as individual files. You might even save some bytes in the latter case, because the ISO can contain packages you don't need.
Not all old machines support booting from USB. This is especially true for machines sold in the CD era.
They can boot GRUB via floppy or CD. Then GRUB can load the installation kernel on a USB drive via its builtin USB 1.1 support.
Most people don't own one of those. Maybe you have a circle of nerdy friends who would have one, but that does not apply to the majority of people.
Most people own a working DVD reader or an USB-booting BIOS. I have no friends.
Fixed-length bitmap buffers cannot be "parsed". All the kernel has to do is to check that the referenced memory does exist, which is a kernel's primary job, and then load it into the VGA registers.
True type fonts need to be decoded, parsed, and interpreted.
You still have so many choices for installing Ubuntu, that you won't find in many non-FOSS products:
- You can use the alternate text-mode Ubuntu installation CD.
- You can boot Windows and then install Ubuntu from there, using the Windows installer.
- You can install an older version of Ubuntu and dist-upgrade it in place.
- You can boot the USB image using a GRUB floppy or CD image.
- You can borrow an USB dvd reader for the first installation (hey, if you have defective hardware, you might expect to be required to have the proper tools to overcome your problems).
The document in that case would be the patent(s) that Oracle holds.
Patents don't contain field of use restrictions by themselves, so for now we can't say that OpenJDK contains field of use restrictions.
Isn't that the same thing, ultimately? I mean, if Oracle says "this is free and open, but if you use it in firmware of your mobile device, we'll sue you over this patent" - isn't that effectively restricting the field of use?
Definitely, but this is not happening now. You can speculate that this might happen in the future (as you could do with *any* open source product at this point - Android, WebM, SQLite, Apache...) but in the case of OpenJDK, this would violate the GPLv2.
Well, 3 x = 6 means that x = 2 only implicitly, but this doesn't make it less true:) . Above all, no lawyer seem to doubt the fact that the GPLv2 patent grant covers the users of the product itself in the USA, due to the estoppel thing. The doubts are whether the grant covers derived works (thus it's not a problem for OpenJDK itself), or over its validity in countries other than the USA which require an explicit declaration for patent grants (but this has not been proven in court yet).
Interestingly enough, even if Stallman's opinion holds true, it would only apply to implementations derived from OpenJDK - any clean room reimplementation (such as Harmony) would run afoul of the patents, as the grant would not apply to it.
Exactly. This is a problem for other implementations, not for OpenJDK.
OpenJDK is released under the GPLv2 and therefore it has no field of use restrictions.
How so?
Because there is no document by Oracle specifying "field of use" restrictions for OpenJDK. The only license applied to OpenJDK is GPLv2, and GPLv2 does not contain field of use restrictions.
Releasing something under GPLv2 does not equate to a patent grant by the original code author, since he cannot, by definition, violate any GPL provisions (as they only apply to someone who would otherwise be in danger of copyright infringement, which is never the original author).
We were talking about field of use restrictions, not patents. Anyway, GPLv2 does include an implicit patent grant in section 6. In the intentions of the GPL authors, sections 6 and 7 were expressly meant to prevent a patent owner from limiting the redistribution of software he had licensed under the GPL. Whether the specific wording they used is lawyer-proof in every country of the globe or not, I'm not qualified to tell. Stallman believes so; but he used a stronger wording in GPLv3, just in case.
Does copyleft mean that if you use something what you release has to also be open source and free?
In this particular case no, because OpenJDK is released under the GPLv2 license but with the GNU Classpath Exception:
As such, it can be used to run, create and distribute a large class of applications and applets. When GNU Classpath is used unmodified as the core class library for a virtual machine, compiler for the java languge, or for a program written in the java programming language it does not affect the licensing for distributing those programs directly.
Do we know why they won't open source the compliance tools?
I think that certification was one way for Sun's to monetize Java while offering it for free.
Does that effectively prevent other implementations of Java from existing? Do we know why Oracle wants that?
Other implementations can exist (that's why Apache Harmony was there until now), but you can't call them "Java" without paying Oracle for the compliance certification. I think it's more or less the same thing as the Unix trademark - Mac OS X can call itself Unix because Apple paid for the certification, Linux although largely Unix-compatible can't call itself Unix because the certification process isn't feasible for open source software.
I am no license expert, but I think that Oracle owns key patents that might cover implementations of the Java platform; OpenJDK is safe because it's released by Oracle under the GPL, but third-party implementations might not have the same protection.
If you install Windows live essentials, sometime like after two days a sneaky pop up appears in the notification area, with a pre-checked "Yes, make bing the default search engine for this computer" box. If you dismiss it quickly, as most users will do, you get Bing injected.
Yes, that's what I do. I had some trouble when trying to have upstart run a daemon as an underprivileged user using su -c. I ended up dropping su and making the daemon binary setuserid.
Putting 32-bit libraries into lib32 and 64-bit ones in lib64 is OK. It's the unsuffixed "lib" directories that are problematic. In Debian/lib64 points to/lib if I'm not wrong, which goes against the FHS, that for binary compatibility reasons requires/lib to contain the 32-bit libraries.
Aren't you forgetting something in the picture? "Common files" for example. Or the whole world stuffed inside System32 (even on x64). Then you have to take into account side-by-side component installation, which happens somehow in C:\WINDOWS\winsxs. And the 64-bit / 32-bit directory split on the disk doesn't end the whole story: there's the filesystem redirection mechanism, that makes 32-bit programs see C:\WINDOWS\SYSWOW64 as C:\WINDOWS\SYSTEM32. A similar hack is in place for the registry, where 32-bit keys are actually stored in the 64-bit registry but under a key called Wow6432Node. I don't know how, but in my Windows Vista installation a 32-bit application had managed to create a real 64-bit key called Wow6432Node and this resulted in an infinitely recursing registry. And let's not talk about how manageable the registry is, even when it works.
A "breaking change" is what happens when something that just worked is replaced by something that promises the moon but then doesn't work, spits 8 pages of stderr with not a single line useful to debug what's going wrong, and comes with no documentation whatsoever aside from a couple blog posts which are unuseful anyway because they have become obsolete a couple of git commits after they were published.
I'll send you a DECtape with my system log next time I'm hit by those kind of "fixes".
Junctions can only point to directories. The full symbolic links implementation was added in Vista as you can read in Vista's release notes.
I think that the common feature both junctions and symbolic links are built on, reparse points, was added earlier. But then I can point to the elegance of a system from the 70s where every file or directory can become a "reparse point", and indipendently of the underlying file system.
You have a point if you say that the / -/usr split is less relevant today because it has been somehow superseded by the use of an initrd/initramfs. Most distributions require or take advantage of an initramfs. But that is much worse from a complexity point of view, because it involves a copy of a different subset of the file system (not only the/bin and/lib directories) which has to be duplicated on the real / file system (if you want to unmount the initrd - wipe the initramfs), often has a different ABI (e.g. uclibc vs. glibc) and has to be kept in sync with the main copy (e.g. when you add new kernel modules, new firmware). It's even invisible to the average user.
It's done for a very good reason (better network boot, boot from usb devices, more flexibility in general) but I don't think the average user can deal more easily with an initrd than he can with a plain/usr mount point. So it's not being done for simplicity as they say here. Especially if you consider that the added simplicity (moving two dozens files from a folder to another) is hindered by the complexity which would need to be added for compatibility reasons (don't think that scripts starting with #!/bin/sh would disappear overnight).
They only have to "recommend" two things for this maneuver to stop being a problem.
Provide the absolute warranty that the feature can be disabled on any PC-compatible machine;
Provide a standardized, user-friendly way to disable the feature.
Anything less than this, is an unacceptable competitive advantage for Microsoft against its closed-source competitors. I'm not even talking about the user's freedom and open source software here.
Note: by "disabling the feature" I actually mean either disabling the feature completely, or allow it to work with other vendors' signatures.
One thing I dislike is the fact that it crashes and burns if the services it's trying to manage fork a number of times that is different from what you've specified in the relevant config file. I find it unelegant and prone to problems.
Slashdot Mirror
I don't doubt that, we were talking about the fact that Android devices can do that with a standard cable and with no special drivers required. I believe this is better.
Bad news for hotel owners then: Apple is changing the dock connector on the next iPad, so they'll have to upgrade their equipment. Another reason why proprietary connectors are bad.
By draining power from the USB cable, as specified by the USB standard?
Well said. I also like the fact that I can connect an android phone to a printer and print photos. Or connect an android phone to a TV and watch video clips. Or connect an android phone to a car stereo and play mp3s. Or connect an android phone to a PC and access the internet. And the phone will recharge while doing any of the above. Where the USB MSD protocol fails, MTP can do better. A "dock" would only be a hindrance, and limit the possible form factors of Android devices.
The sequence of pixels is not stored in a file, it is already loaded in a buffer of the required length and in the machine format.
This is not applicable to non technical users which happens to be Ubuntu's intended target audience.
If you can use the graphics mode CD, you can use the text-mode CD. The questions are the same. Otherwise you shouldn't be installing an operating system, really.
Windows is rather expensive for a glorified boot loader
On the other hand, a working dvd reader is extremely cheap.
Upgrading takes ages compared to installing especially running on old hardware or netbooks. Finding old Ubuntu images is not trivial. It's very user unfriendly to make people download hundreds of MBs of patches when installing their new OS.
Beggars can't be choosers. Finding old ubuntu images is trivial. You'll need to download the packages anyway, it doesn't change if you download them in the form of an ISO image or as individual files. You might even save some bytes in the latter case, because the ISO can contain packages you don't need.
Not all old machines support booting from USB. This is especially true for machines sold in the CD era.
They can boot GRUB via floppy or CD. Then GRUB can load the installation kernel on a USB drive via its builtin USB 1.1 support.
Most people don't own one of those. Maybe you have a circle of nerdy friends who would have one, but that does not apply to the majority of people.
Most people own a working DVD reader or an USB-booting BIOS. I have no friends.
Please provide an example of how I can parse a sequence of pixels.
True type fonts need to be decoded, parsed, and interpreted.
The two things are completely incommensurable.
There's nothing wrong with that as long as you set the appropriate operational limits.
Oh, and as an extra precaution, you might consider not parsing them in ring 0.
Microkernels don't do drivers and file systems.
You still have so many choices for installing Ubuntu, that you won't find in many non-FOSS products:
- You can use the alternate text-mode Ubuntu installation CD.
- You can boot Windows and then install Ubuntu from there, using the Windows installer.
- You can install an older version of Ubuntu and dist-upgrade it in place.
- You can boot the USB image using a GRUB floppy or CD image.
- You can borrow an USB dvd reader for the first installation (hey, if you have defective hardware, you might expect to be required to have the proper tools to overcome your problems).
The document in that case would be the patent(s) that Oracle holds.
Patents don't contain field of use restrictions by themselves, so for now we can't say that OpenJDK contains field of use restrictions.
Isn't that the same thing, ultimately? I mean, if Oracle says "this is free and open, but if you use it in firmware of your mobile device, we'll sue you over this patent" - isn't that effectively restricting the field of use?
Definitely, but this is not happening now. You can speculate that this might happen in the future (as you could do with *any* open source product at this point - Android, WebM, SQLite, Apache...) but in the case of OpenJDK, this would violate the GPLv2.
Well, the wording is definitely very vague, and it doesn't even explicitly mention patents (hence "implicit"). Apparently, some lawyers think that it's rather limited in scope.
Well, 3 x = 6 means that x = 2 only implicitly, but this doesn't make it less true :) . Above all, no lawyer seem to doubt the fact that the GPLv2 patent grant covers the users of the product itself in the USA, due to the estoppel thing. The doubts are whether the grant covers derived works (thus it's not a problem for OpenJDK itself), or over its validity in countries other than the USA which require an explicit declaration for patent grants (but this has not been proven in court yet).
Interestingly enough, even if Stallman's opinion holds true, it would only apply to implementations derived from OpenJDK - any clean room reimplementation (such as Harmony) would run afoul of the patents, as the grant would not apply to it.
Exactly. This is a problem for other implementations, not for OpenJDK.
OpenJDK is released under the GPLv2 and therefore it has no field of use restrictions.
How so?
Because there is no document by Oracle specifying "field of use" restrictions for OpenJDK. The only license applied to OpenJDK is GPLv2, and GPLv2 does not contain field of use restrictions.
Releasing something under GPLv2 does not equate to a patent grant by the original code author, since he cannot, by definition, violate any GPL provisions (as they only apply to someone who would otherwise be in danger of copyright infringement, which is never the original author).
We were talking about field of use restrictions, not patents. Anyway, GPLv2 does include an implicit patent grant in section 6. In the intentions of the GPL authors, sections 6 and 7 were expressly meant to prevent a patent owner from limiting the redistribution of software he had licensed under the GPL. Whether the specific wording they used is lawyer-proof in every country of the globe or not, I'm not qualified to tell. Stallman believes so; but he used a stronger wording in GPLv3, just in case.
All versions of .NET are proprietary. A subset of .NET 2.0 is an open standard. .NET 3.0, 3.5 and 4.0 are proprietary.
Does copyleft mean that if you use something what you release has to also be open source and free?
In this particular case no, because OpenJDK is released under the GPLv2 license but with the GNU Classpath Exception:
Do we know why they won't open source the compliance tools?
I think that certification was one way for Sun's to monetize Java while offering it for free.
Does that effectively prevent other implementations of Java from existing? Do we know why Oracle wants that?
Other implementations can exist (that's why Apache Harmony was there until now), but you can't call them "Java" without paying Oracle for the compliance certification. I think it's more or less the same thing as the Unix trademark - Mac OS X can call itself Unix because Apple paid for the certification, Linux although largely Unix-compatible can't call itself Unix because the certification process isn't feasible for open source software.
I am no license expert, but I think that Oracle owns key patents that might cover implementations of the Java platform; OpenJDK is safe because it's released by Oracle under the GPL, but third-party implementations might not have the same protection.
OpenJDK is GPL, therefore it contains an implicit patent grant (for what concerns Oracle patents).
It's the TCK that has a restrictive license, i.e. Oracle wants money if you want to call your implementation of Java with the Java name.
If you install Windows live essentials, sometime like after two days a sneaky pop up appears in the notification area, with a pre-checked "Yes, make bing the default search engine for this computer" box. If you dismiss it quickly, as most users will do, you get Bing injected.
Yes, that's what I do. I had some trouble when trying to have upstart run a daemon as an underprivileged user using su -c. I ended up dropping su and making the daemon binary setuserid.
Putting 32-bit libraries into lib32 and 64-bit ones in lib64 is OK. It's the unsuffixed "lib" directories that are problematic. In Debian /lib64 points to /lib if I'm not wrong, which goes against the FHS, that for binary compatibility reasons requires /lib to contain the 32-bit libraries.
Aren't you forgetting something in the picture? "Common files" for example. Or the whole world stuffed inside System32 (even on x64). Then you have to take into account side-by-side component installation, which happens somehow in C:\WINDOWS\winsxs. And the 64-bit / 32-bit directory split on the disk doesn't end the whole story: there's the filesystem redirection mechanism, that makes 32-bit programs see C:\WINDOWS\SYSWOW64 as C:\WINDOWS\SYSTEM32. A similar hack is in place for the registry, where 32-bit keys are actually stored in the 64-bit registry but under a key called Wow6432Node. I don't know how, but in my Windows Vista installation a 32-bit application had managed to create a real 64-bit key called Wow6432Node and this resulted in an infinitely recursing registry. And let's not talk about how manageable the registry is, even when it works.
I'll send you a DECtape with my system log next time I'm hit by those kind of "fixes".
edit: And Windows XP *was* released a decade ago.
I think that the common feature both junctions and symbolic links are built on, reparse points, was added earlier. But then I can point to the elegance of a system from the 70s where every file or directory can become a "reparse point", and indipendently of the underlying file system.
It's done for a very good reason (better network boot, boot from usb devices, more flexibility in general) but I don't think the average user can deal more easily with an initrd than he can with a plain /usr mount point. So it's not being done for simplicity as they say here. Especially if you consider that the added simplicity (moving two dozens files from a folder to another) is hindered by the complexity which would need to be added for compatibility reasons (don't think that scripts starting with #!/bin/sh would disappear overnight).
Anything less than this, is an unacceptable competitive advantage for Microsoft against its closed-source competitors. I'm not even talking about the user's freedom and open source software here.
Note: by "disabling the feature" I actually mean either disabling the feature completely, or allow it to work with other vendors' signatures.
One thing I dislike is the fact that it crashes and burns if the services it's trying to manage fork a number of times that is different from what you've specified in the relevant config file. I find it unelegant and prone to problems.