"Very Disruptive" Change Hurts ARM Linux Support

[blackiwid]

So please stop the anti-fsf-flaming. Nobody forced linus to use this lisence. If he would not have used this lisense, today Linux would not be that big thing, if he would have used bsd lisense it logicaly would be where bsd is today, and we would have something similiar to linux maybe hurd that would have its relevance.

Yes Yes I know you primary users or some propriatary software developers here, dont care or would want to have it under bsd, but that are not the people that made linux to that what it is.

90% of the linux developers build there stuff drivers... for linux because of the lisence. If the lisence would not have mattered why else? They could have all worked on bsd and today bsd would be the big "kernel".

So most linux developers like(d) the freedom idea behind gpl more than the idea behind bsd, you can have here a different opinion but it stays what it is most linux devs did vote for that type of freedom, because they worked on linux instead of on bsd.

So back to the concrete problem. Its a very small problem, because only on very old machines it slows them down, and its no real big problem because they have several options, 1. use old kernels, 2. there will shure be some patched kernels 3. I think there will be a rewrite or something out soon.

So even if linux would want a bsd or a own-lisense like gpl2 but without that, the work if it even would be possible to relisence the gpl would be way more work than just rewriting this bit of code.



What I find a bit disturbing is more the fact that its really a big problem, if you have a gpl that forces you to use gpl if you use it for distrubtion with changes or no changes... it sounds good, at least for me but the lisense text cant be the at least nearly best solution to keep the freedom of people forever.

Because the wordl and the technologie changes. So maybe you think gpl3s changes are not importent, but lets say its 2015 and we have gplv7 and some good stuff did get targeted with that updates, with the gpl-v2 without the + you cant at all switch to that.

So no matter what you find good maybe you think it should be more free in the sense that bsd things it... you could not change it in this direction.

So for both sides it gets extremly hard to get something changed... I mean no matter what if you are a free software guy, if you really want a really free system, and want maybe also only upload your source code under the gplv3 PLUS lisense you have to completly write a new kernel, and cant se code parts from linux. The same for the industrie that wants bsd fork. <- but that last one was the goal behind the gpl lisense. the first one not.

So my question is then, is the development into the linux kernel a kind of black hole, so we have to rewrite everything from 0 in 10 or 20 years, because gpl2 will be completly annuled?

The only idea I would have that a complete rewrite could be more step by step would be that you fork the linux kernel under its gpl v2 lisence, and then part by part put stuff into userspace, till only the most important performence critic stuff would be in the kernel itself, and then rewrite a replacement of this linux-"lite" kernel under a gplx+ lisense. Or replace it with something like hurd.

or am I wrong and it would be easy, when lets say 5000 people would want to make hurd the new thing, port over radeon + network drivers nouvou intel drivers?

[TheOne]

Damn, I run a Globalscale Dreamplug as my main fileserver.
...

I'm on the same boat and the dreamplug is a pretty nice device for what it does despite been armv5. I guess we are stuck with kernel 3.8 unless some one distributes newer kernels with necessary modifications. This sucks, is like been left behind in the dust.

Not only the dreamplug is affected but almost all these devices based on the kirkwood armv5 chip: http://www.plugcomputer.org/development-kits/

[WorBlux]

That clause has a stark resemblance to:



FSF is being a bunch of nitwitty asshats here, without a freakin' shadow of doubt.

There is a difference. The GPL says, you can't sure us for damages arising out of this software.

The soft-point readme says, you gotta pay us back if any of your customer of clients sue us successfully. Though converting it to the GPL could be enough to satisfy the requirement.

[Sonadow]

The mailing list claims that Linus does not approve of the removal of the features and is prepared to fight his way to prove that there is no license incompatibility.

Good luck with that Torvalds. As much as I see the FSF as a bunch of luddites and foggies, i doubt he's going to win this.

[wargames]

ARM = cheap

Considering ARM chips are cheap (no pun intended), what's the problem ? Most phones ship with ARMv7 or higher these days. Floating point emulation ? Come on, we are in 2013.

[Sidicas]

That clause has a stark resemblance to:


THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.


FSF is being a bunch of nitwitty asshats here, without a freakin' shadow of doubt.

USE OF THIS SOFTWARE IS RESTRICTED TO
PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ALL
LOSSES, COSTS, OR OTHER PROBLEMS THEY INCUR DUE TO THE SOFTWARE, AND WHO
FURTHERMORE EFFECTIVELY INDEMNIFY JOHN HAUSER AND THE INTERNATIONAL COMPUTER
SCIENCE INSTITUTE (possibly via similar legal warning) AGAINST ALL LOSSES,
COSTS, OR OTHER PROBLEMS INCURRED BY THEIR CUSTOMERS AND CLIENTS DUE TO THE
SOFTWARE.

They're not the same, not even close. The first one from the GPL says the software comes with no warranty to the point where permitted by law for the user's country...

The second one says you can't use this software in countries that have laws which require somebody else to be held responsible if the user is victimized..

So the second one is more restrictive and so the FSF is perfectly right in saying it's not GPL compatible and it is more restrictive than the GPL.

I *really* hate it when people try to go and screw around with licenses because they always screw it up. This ranks right up there with the other guy who snuck something into the license that said the software could not be used for "evil". Leaving "evil" to be undefined, it meant that opressive countries could block free software for legal reasons because it was "evil" in going around the government's Internet censorship...

If you want to mess with a license, you need to consult a decent legal team first.. Too many programmers think they're geniuses at everything when they're not. Have mercy on the poor distro packagers who have to deal with situations of manipulated licenses. Don't touch the license.

[uid313]

Drop older hardware

Well recently hardware support for old i386 were dropped.
Does anyone really use ARMv4 and ARMv5?
Everyone is using ARMv7, except Raspberry Pi which is using old ARMv6.

So does this really affect anyone?
And those affected can continue run Linux kernel 3.8 for quite a while.

[hwertz]

Damn, I run a Globalscale Dreamplug as my main fileserver.

I'd recently just spent some time learning how to update the u-boot and configure & compile a new linux 3.8 kernel. It's a Marvell Kirkwood - running a Feroceon 88FR131 - an ARMv5te processor. It doesn't have a hardware FPU and any FP ops are currently done with emulation. Until now, I was looking forward to the 3.9 kernel release as I heard changes had been merged to provide CPU frequency stepping for this processor so it would use a tiny bit less power and give off slightly less heat when it's idle.

Assuming I did upgrade to the 3.9 kernel when it's out of RC, does anyone know what I could expect would break without software FP emulation?
I noticed that RealNC stated somewhere in this thread:


I know before I updated the kernel to 3.8 it was running a custom version of 2.6.33-7. I upgraded mainly because the default install consistently segfaulted when I was trying to use file encryption (I remember trying at least eCryptFS, encFS and one other). I would imagine encryption algorithms are likely to use FP operations and I'm wondering if that custom 2.6.33-7 didn't have software fp emulation compiled in which caused the issue? Does that sound plausible?

I would assume between 2.6.33 incorrectly used some ARM6 or ARM7 instruction or FP or something, and the 3.9 will still correctly avoid those instructions when built for FPUless ARM.

As for the kernel support -- Ubuntu ARM is based on Debian ARMHf (hard float) and so would I guess work with 3.8 but not 3.9. Debian's normal armel support is softfloat, and I'd guess most ARM distros are softfloat. I assume there's basically 2 differences: 1) Some GCC flags (whether to shoot out FPU instructions or the equivalent softlib calls). 2) A few apps like ffmpeg probably have VFP and FPU on/off flags.

[Kamikaze]

What does this mean for me?

Damn, I run a Globalscale Dreamplug as my main fileserver.

I'd recently just spent some time learning how to update the u-boot and configure & compile a new linux 3.8 kernel. It's a Marvell Kirkwood - running a Feroceon 88FR131 - an ARMv5te processor. It doesn't have a hardware FPU and any FP ops are currently done with emulation. Until now, I was looking forward to the 3.9 kernel release as I heard changes had been merged to provide CPU frequency stepping for this processor so it would use a tiny bit less power and give off slightly less heat when it's idle.

Assuming I did upgrade to the 3.9 kernel when it's out of RC, does anyone know what I could expect would break without software FP emulation?
I noticed that RealNC stated somewhere in this thread:

This is handled by userspace FP library nowadays, so the change doesn't really break anything in the long run.

I know before I updated the kernel to 3.8 it was running a custom version of 2.6.33-7. I upgraded mainly because the default install consistently segfaulted when I was trying to use file encryption (I remember trying at least eCryptFS, encFS and one other). I would imagine encryption algorithms are likely to use FP operations and I'm wondering if that custom 2.6.33-7 didn't have software fp emulation compiled in which caused the issue? Does that sound plausible?

[randomizer]

There is a difference between saying (paraphrased) "If you use this code, you agree to indemnify XYZ..." and (paraphrased) "Use of this software is restricted to people who will indemnify XYZ...". One makes the implicit assumption that if you use the code, you have already agreed to indemnify the original authors. The other states that you cannot use it unless you do so. This is probably what the FSF is having issues with.