That's very true, but a lot has changed since the case against Microsoft. It's not all too incredible that the future of computing will be dominated by mobile handheld devices which will mostly be based on ARM. Most of these will probably be general purpose computers marketed as "Android tablets" or "iOS tablets", despite that those computers could just as well run any other OS. Although the judgment was important at one time, I would say that it probably won't be as important in the future.
FreeBSD works similar to Linux in that regard. Nvidia's driver is available if you want it, but you don't have to use it and the OS certainly doesn't include it by default.
The main difference is that when Nvidia came to FreeBSD the FreeBSD developers (unlike the Linux kernel counterpart) appreciated that a big hardware vendor wanted to support their OS.
You are right about that. But the main point is still there. Why should there be a difference between x86 hardware and ARM hardware? Both are general purpose computers, and pointing to the CPU architecture is not a reason for locking down the hardware to only run a specific OS.
Sure. But why should hardware be locked down just because the x86 is replaced with ARM? It doesn't matter if it's an iPad, Surface or Galaxy Tab. You should be able to install any OS of your choice. The vendor can of course choose to only support their preinstalled OS, but they should not put artificial barriers in the way of replacing that OS with something else.
I would go as far as saying that just calling it a tablet OS doesn't mean that you should lock down the hardware to only run that OS. I want to be able to install any OS on my Android tablets without having to jump through holes in order to root them. It's not just about running Linux, being locked down to only run Linux is almost as bad as being locked down to only run Windows.
Any computer (even those called "tablets" by marketing people") should be able to run any OS of your choice. Locking a device to only run a specific OS (Android, iOS, Windows RT) is unethical and should not be allowed.
What about the Surface based on x86? Is that also an ARM consumer tablet, or is it a PC? You can build a "PC" based on ARM too. Calling something a tablet doesn't take away that it's still a general purpose computer.
Sure but it's not just about running Linux, it's about running any operating system of your choice. Somehow the computer industry thinks that just because you build a general purpose computer based on ARM you can only run one specific OS made just for that device on it. That's why you're calling it Android devices. But it's a computer and could just as well run Windows RT, or FreeBSD, or MyFirstOS.
Of course they can. I was just replying to the following:
Anybody selling a system that prevents the user from using free software or OSs deserves a big, fat, nasty, very expensive, tour of courts all over the world.
Sure, but so far they have not been interested in using secure boot technology on their Mac systems. That you're using UEFI doesn't mean that you have to use secure boot, just that you can choose to implement secure boot on top of UEFI. The original poster should have said 'as you oppose secure boot' instead of UEFI, that would have made more sense.
Boy, am I glad I own an iMac, iPad and iPhone... um, wait...
At least the iMac doesn't use secure boot, and as far as I know Apple has no plans to implement it on any of their Macs.
iPhone and iPads are a different story.
Where is the walled garden and vendor lock-in? Ubuntu distributes a lot of software to its users, that doesn't take away any rights to run any other software. Just build it from source or install a prebuilt binary.
Interesting statistics, but seriously Steve Jobs died in 2011. And even if he was still alive he personally would not be responsible or connected to any form of crime wave in New York.
This is actually a serious problem for those of us that are looking at the Nexus 4 since it is made by LG. Kind of a bummer that Google allowed this to happen.
I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library.
Because it relies on the kernel API compatible with 2.6.16 and later.
The Hurd project isn't mentioned anywhere in the mailing list post.
It's my understanding that the Hurd project uses a customized version of glibc.
Did you read the parent's post? How exactly do you restrict an account used for backups on a Linux system? I'm not saying yours is a bad idea, but this was a poor context to use it in.
Backups are a perfectly valid reason for password-less logins, and a really embarrassingly bad case to use for privilege separation in UNIX.
If you have to use SSH for this kind of job you can create a separate key especially for this job so that it's only valid in the context of making backups. You can also restrict what you can do on the remote endpoint (OpenSSH has support for that) so that it can only be used for the purpose of creating backups. That means that you can have your main ssh keys encrypted, and still use SSH for automatic backups without having to decrypt the key file.
Slashdot Mirror
That's very true, but a lot has changed since the case against Microsoft. It's not all too incredible that the future of computing will be dominated by mobile handheld devices which will mostly be based on ARM. Most of these will probably be general purpose computers marketed as "Android tablets" or "iOS tablets", despite that those computers could just as well run any other OS. Although the judgment was important at one time, I would say that it probably won't be as important in the future.
FreeBSD works similar to Linux in that regard. Nvidia's driver is available if you want it, but you don't have to use it and the OS certainly doesn't include it by default.
The main difference is that when Nvidia came to FreeBSD the FreeBSD developers (unlike the Linux kernel counterpart) appreciated that a big hardware vendor wanted to support their OS.
You are right about that. But the main point is still there. Why should there be a difference between x86 hardware and ARM hardware? Both are general purpose computers, and pointing to the CPU architecture is not a reason for locking down the hardware to only run a specific OS.
Sure. But why should hardware be locked down just because the x86 is replaced with ARM? It doesn't matter if it's an iPad, Surface or Galaxy Tab. You should be able to install any OS of your choice. The vendor can of course choose to only support their preinstalled OS, but they should not put artificial barriers in the way of replacing that OS with something else.
I would go as far as saying that just calling it a tablet OS doesn't mean that you should lock down the hardware to only run that OS. I want to be able to install any OS on my Android tablets without having to jump through holes in order to root them. It's not just about running Linux, being locked down to only run Linux is almost as bad as being locked down to only run Windows.
Any computer (even those called "tablets" by marketing people") should be able to run any OS of your choice. Locking a device to only run a specific OS (Android, iOS, Windows RT) is unethical and should not be allowed.
A device that forces you to run Android is still a locked down device. You should be able to run any available OS of your choice without "rooting" it.
Locking down a device so that it can only run one OS is always bad, no matter if it's Android, iOS or Windows RT.
What about the Surface based on x86? Is that also an ARM consumer tablet, or is it a PC? You can build a "PC" based on ARM too. Calling something a tablet doesn't take away that it's still a general purpose computer.
Sure but it's not just about running Linux, it's about running any operating system of your choice. Somehow the computer industry thinks that just because you build a general purpose computer based on ARM you can only run one specific OS made just for that device on it. That's why you're calling it Android devices. But it's a computer and could just as well run Windows RT, or FreeBSD, or MyFirstOS.
Anybody selling a system that prevents the user from using free software or OSs deserves a big, fat, nasty, very expensive, tour of courts all over the world.
Sounds pretty much like what Apple has been doing for a few years now on the mobile side. How's it going with that lawsuit?
Sure, but so far they have not been interested in using secure boot technology on their Mac systems. That you're using UEFI doesn't mean that you have to use secure boot, just that you can choose to implement secure boot on top of UEFI. The original poster should have said 'as you oppose secure boot' instead of UEFI, that would have made more sense.
Boy, am I glad I own an iMac, iPad and iPhone ... um, wait ...
At least the iMac doesn't use secure boot, and as far as I know Apple has no plans to implement it on any of their Macs.
iPhone and iPads are a different story.
Where is the walled garden and vendor lock-in? Ubuntu distributes a lot of software to its users, that doesn't take away any rights to run any other software. Just build it from source or install a prebuilt binary.
Interesting statistics, but seriously Steve Jobs died in 2011. And even if he was still alive he personally would not be responsible or connected to any form of crime wave in New York.
This is actually a serious problem for those of us that are looking at the Nexus 4 since it is made by LG. Kind of a bummer that Google allowed this to happen.
Why convert? UNIX is C, period.
It's a lot of C, but not all C. According to the FreeBSD mirror on GitHub the FreeBSD distribution contains the following types of code:
C 78.2%
C++ 12.9%
Shell 5.1%
Perl 1.2%
Other 2.4%
Apparently the MacBook Air is good enough for Linus.
http://techcrunch.com/2012/04/19/an-interview-with-millenium-technology-prize-finalist-linus-torvalds/
I read the mailing list post and they do mention the minimum Linux kernel version needed to work with this C library, but it doesn't say why. I'm curious as to what new features they are using that are not in early 2.6.x kernels. For that matter I'm curious as to whether Hurd works with this C library.
Because it relies on the kernel API compatible with 2.6.16 and later.
The Hurd project isn't mentioned anywhere in the mailing list post.
It's my understanding that the Hurd project uses a customized version of glibc.
Correct. The absence of edit functionality is sometimes a bit irritating. Thanks for pointing it out. :-)
But it's also a bit sad that 210 MB is considered tiny.
Did you read the parent's post? How exactly do you restrict an account used for backups on a Linux system? I'm not saying yours is a bad idea, but this was a poor context to use it in.
Backups are a perfectly valid reason for password-less logins, and a really embarrassingly bad case to use for privilege separation in UNIX.
If you have to use SSH for this kind of job you can create a separate key especially for this job so that it's only valid in the context of making backups. You can also restrict what you can do on the remote endpoint (OpenSSH has support for that) so that it can only be used for the purpose of creating backups. That means that you can have your main ssh keys encrypted, and still use SSH for automatic backups without having to decrypt the key file.
Turned out someone had a cron job that checked certain files for modifications, including authorized_keys. So it was detected fairly quickly.
With great power comes great responsibility, or whatever it is that sudo sais the first time you run it.
Then I would create a separate key for that service and restrict what it was allowed to do on remote end.