VirtualBox Being Removed From Trisquel
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Parabola recently found a serious freedom problem with VirtualBox in which a non-free compiler is needed: https://labs.parabola.nu/issues/375#note-1
It appears that upstream is not interested in fixing this: https://www.virtualbox.org/ticket/12011
Parabola has removed VirtualBox from their repositories. I understand that Trisquel and other distros will be too.
So, just an FYI in case people wonder why it disappeared from the repository.
Actually, further clarification shows this is only for version 4.2. Since Trisquel has an older version (4.1) it can be kept for now...
Well, it doesn't work anyway. Thus it would be better to remove it.
I am a member!
Hmm.. So a piece of fully free software is removed because a small piece of that free software needs a fully open-source, OSI approved compiler to build properly...
Right.. Right. Yeah, right, that makes sense.
Ehm... is this trolling? The FSF didn't approve of the license in question. Only the OSI did. The FSF's reason for rejecting it is a damn sound one, too.
"Ehm... is this trolling?"
Yes, dudeski seems to be critical of most everything [0] in their comments.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
> Debian-legal may provide you with a clause-by-clause analysis, but
> let me point out just one particular gem:
>
> the moment you use openwatcom to compile any work-related piece of
> software (thus not "Personal Use"), you need to make the source of
> openwatcom publicly available for 12 months.
I am a member!
Right.. Yes, I see. It's got a silly, completely unenforcable clause in there. Heh. Suppose my immediate vaguely childish reaction is akin to who gives a shit.. The code is still out there. You can grab it, stare at it and modify it.
Then again, the FSF always sees things entirely in black and white, so guess it's hardly surprising only the OSI gave this one a go-ahead.
Well, can always just grab the deb file straight from Oracle.
On 30/08/13 05:40, erikthorsen wrote:
> Right.. Yes, I see. It's got a silly, completely unenforcable clause
> in there. Heh. Suppose my immediate vaguely childish reaction is akin
> to who gives a shit.. The code is still out there. You can grab it,
> stare at it and modify it.
>
> Then again, the FSF always sees things entirely in black and white,
> so guess it's hardly surprising only the OSI gave this one a
> go-ahead.
Oracle is known to enforce copyrights, especially where a commercial
entity is involved.
Andrew.
I am a member!
Firstly, Oracle (while admittedly being a big douchy at times) has nothing to do with OpenWatcom, other than using it as a compiler for the VirtualBox BIOS, so this is already nonsense.
But let's pretend for a moment the OpenWatcom project wanted to try enforcing this.. How exactly would they do so?
Firstly they'd have to build in some serious spyware to keep track of where and how it was used.. Then they'd have to somehow track down the actual users and whatever basement they're sitting in..
And then they'd have to run down all those users and make sure they keep the relevant source code on a server somewhere for the next year.
Should probably be at gunpoint for dramatic effect.
It's an open-source project whos last stable release was three years ago, and in this context it's only used to compile a ruddy bios.
Apologize for not being able to work up any worry about this.
Still much better than, you know, the bios in your actual hardware.
On 30/08/13 20:08, erikthorsen wrote:
> Firstly, Oracle (while admittedly being a big douchy at times) has
> nothing to do with OpenWatcom, other than using it as a compiler for
> the VirtualBox BIOS, so this is already nonsense.
If VirtualBox won't fully compile without non-free (or controversially
licensed) software than this is certainly an issue. Compilers are large
and complex, so it's not easy to workaround either.
Trisquel, by the way, is supposed to be self-hosting, i.e. every package
should be able to be built from scratch, as the developers wrote it,
with entirely free software.
> Apologize for not being able to work up any worry about this. Still
> much better than, you know, the bios in your actual hardware.
I wonder why Watcom didn't release their software under an existing
software license?
Maybe we should get specific. The license in question requires that,
say, if a person or company compiles something using that compiler and
deploys it they will have to publish the source code. I doubt they care
about individual programmers. But, according to the FSF at least,
companies deserve software freedom as well. There was discussion of the
license in 2006 on the Debian bug tracker, so the license itself has
been around for a while. One Debian developer had concerns about the
patent license as well. You can read about it here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
Andrew.
Perhaps we should add a tutorial on the wiki on how to use qemu
I think that's a good idea. I tried out qemu once, but I was never able to figure out how to make it work. I'm sure I'm not the only one.
I only tried qemu with Debian GNU/Hurd.
I can not judge the state of the Hurd Kernel but AFAIK it is quite limited compared to a vanilla Linux kernel. My experiences under GNU Linux are quite good. We run a virtualisation cluster with three big servers under Debian with KVM as hypervisor with good results.
dudeski said:
"Yes, I see. It's got a silly, completely unenforcable clause in there. Heh. Suppose my immediate vaguely childish reaction is akin to who gives a shit.. The code is still out there. You can grab it, stare at it and modify it."
YOU are certainly free to distribute code with a 'silly, unenforcable clause' and accept the legal risk of such distribution.
You are NOT free to expect others to do the same, particularly in the case where others doing the same will not subject YOU to the legal risks.
I am a member!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I agree with Trisquel's view that unless/until this is resolved upstream, Virtualbox should be removed from the repositories. As dudeski said, it is easy enough for users to grab the deb file straight from Oracle if they so desire.
In the meantime, we'll need another solution. Perhaps qemu, as a_slacker_here suggested. Is this comparable to VirtualBox? What about KVM/XEN etc.? Is there anything free with a nice GUI?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iF4EAREIAAYFAlIfyC4ACgkQgijxUCZnvltMgwEAj6/xb6N7/y1HWF0ezp7IMyDt
lwAlA+lnF7OOXb4FyTMBAMRx8v5H6zsIfN63wn5ozliN6TGPJXatVDVg8v0/j9N4
=1HPx
-----END PGP SIGNATURE-----
I tried QEMU once, and it seemed like it was decent, though I didn't figure out how to actually use it.
People use VB from the Ubuntu and Trisquel repos? They are usually old versions and Oracle offers official repositories for most distros on http://www.virtualbox.org
Ok. It's bad, but is possible to have the old version (4.1) with the future versions of Trisquel?
I am a member!
So only the new version is dependent on a non-free compiler and they don't want to fix that? It seems like a major issue and I'd think most distributions would want to exclude it. Isn't this an issue for Debian as well? Or is it just going to end up in the non-free repository?
There are a lot of issues with VirtualBox as it is. Otherwise it might be worth forking. The reason it is such a pain as it is for Trisquel users is because the code quality isn't good enough for a kernel portion that it needs to get into the mainline kernel. If it was you wouldn't need to mess about to get it working on Trisquel 6.
I have to say though it is too bad because VirtualBox has had a free version for a while now.
@jxself: You should be more accurate. The VBox team is not uninterested in fixing this.
The reply from their VBox ticket:
...
We would be glad to fix this, but we lack the resources to do so as our BIOS code has simply outgrown what bcc (which we were using before and which was always very limiting) can do. We have failed to find another free 16-bit x86 C compiler up to the job, and OpenWatcom is free according to OSI, which under the circumstances we considered sufficient.
...
VBox is owned by Oracle and thus the developers are payed for doing their work. If one is able to fix the issue, they will happily add the fix.
Also IMO there is very little benefit in using VirtualBox instead of QEMU / KVM unless you depend on special tools (e.g. Vagrant for automated deployment of VMs). There are tons of free frontends for managing KVM machines. The only benefit I can see for VBox is for very special use cases with complex network environments (e.g. virtualized HA environments with multiple dedicated NICs / networks for double heartbeat connections).
Let's start a fund raiser for poor little Oracle so they'll get enough resources!
/sarcasm
Sarcasm does not help here. Also Oracle has a proven record to do NOTHING for open-source. Also see how the (re)sell rebranded RHEL for their own purposes.
Note that the VirtualBox guys were always quite open to the free software community but Innotek was bought by Oracle...hence end of game.
"It does work, but not out of the box; try this:
https://trisquel.info/en/wiki/installing-virtualbox
and you may have to repeat the same steps after updates sometimes."
These steps don't work for me unfortunately.
"I think that's a good idea. I tried out qemu once, but I was never able to figure out how to make it work. I'm sure I'm not the only one."
You are not. I'm having the same problem. Qemu seems to be a bit complicated to use, which is why I'd prefer to use VirtualBox if possible.
Here is quite some comprehensive overview:
http://www.linux-kvm.org/page/Management_Tools
Although there are a lot of large-scale frontend included.
Personally I found virt-manager quite nice:
http://virt-manager.org/
At least if you can live with NAT-mode for the guests. Generating a bridge plus TAP devices to give your VMs IP-adresses from your LAN is generally a bit harder to do. This is where VBox shines because of it's network capabilities.
In the end starting a KVM machine is not more than a single command specifying RAM used, which virtual HDD to use, how many cores and so on. For most of the time I am using pure bash files to start my machines.
Probably you don't use the default kernel (Linux-libre 3.2) from Trisquel. If you use the kernel-belenos (3.5) or from PPA (3.4 or 3.10) it doesn't works.
Here's short guide on how to use QEMU.
sudo aptitude install qemu qemu-img create -f qcow2 hdd.qcow2 10G qemu-system-x86_64 -m 512M -cdrom trisquel_6.0_amd64.iso hdd.qcow2
There are three steps above.
First we install QEMU by the package called qemu.
Second we create an disk image file, which will be used by QEMU as a virtual hard disk. The image file will be in qcow2 format (-f qcow2), will be named "hdd.qcow2" and will provide 10 gigabytes of virtual disk space.
Third we run a virtual machine. The virtual machine will have 512 magabytes of RAM (-m 512M). It will have a Trisquel 6.0 installation disk loaded (-cdrom trisquel_6.0_amd64.iso). It will also have a hard disk (hdd.qcow2).
That's the basics. You should keep in mind that some CPUs have special vitalization functions, that are used for QEMU. If you don't have them, then QEMU will complain the it could not access KVM kernel module. It will still run, but it will be suboptimal. This is the case with my computer. QEMU runs very slow on my computer, but runs good on other computers.
grep -E '(vmx|svm)' /proc/cpuinfo
Run the above to check if your computer has the needed vitalization functions. If it doesn't display anything, then it doesn't have those functions.
I want to share something with you:
It exists a graphical frontend for qemu if you are in a hurry:
I would be glad if this information helps somebody
- Vous devez vous identifier ou créer un compte pour écrire des commentaires