In a perfect world, some ARMv5TE device will run perfectly with the 3.10.7 kernel of Slackware ARM current, like an x86 system under Slackware.

BUT, we live in an imperfect world and some ARM devices find full support only on their Android kernel, 2.6.32.x or 3.0.8.

Slackware ARM 14.0 works perfectly with the Android kernel 2.6.32.9, under WM8650 platform.

What processor is, surprise, surprise!, an ARMv5TE. For those who do not know, ARMv5TE is the standard Slackware ARM platform, like i486 is for Slackware x86.

BUT, Slackware ARM current refuse to work with this kernel, which is, ironically, also completely open source as custom drivers, because of its GLIBC, who like an minimum kernel version as 3.1.0.

Also, Slackware ARM current works perfectly against GLIBC from the version 14.0.

I consider this is an epic mistake! And the Slackware team should urgently reconsider the situation of Slackware ARM current on the 2.6.32.x and 3.0.x kernels that are supported by Android.

And, YES! Slackware ARM current should and must support these Android kernels, not to copy ad-literal the Slackware x86(_64) version!

Slackware ARM is a software project; it should focus on providing the most current stable software platform. If your hardware is not supporting more recent kernels you should stay on the older software platform; IMHO.

We have see this too often in the OSS world to not have learned this lesson; if you wait for vendors to get their act together on driver compatibility etc, you get paralyzed. If you allow that to happen your software platform becomes uninteresting and you never get drivers or support.

If you need newer packages on the 14.0 platform grab them from the current source tree and build them against the libc in 14.0.

Of course, but this is also to consider the platform that will work. If you make a plane that is unable to fly, what's the point?

When Google prefers to stay in 2.6.32 and 3.0.8, for the millions of devices that are sold, do not think it's epic that You ask to at least an 3.1 kernel?

Basically, you have a 2.6.32.x kernel that works perfectly (because Android is basically a Linux based on busybox, plus the graphical user interface) and a modern kernel 3.10.7, which does not have video drivers, sound, ethernet, etc..

My device has one month old, and is a mini-laptop. Do you think it's time to throw it, because it's too old for Slackware ARM? Or to stay in some years old software, because the developers think that GLIBC compiled with --enable-kernel=3.1.0 is funny?

How about the developers should recompile their GLIBC with --enable-kernel=2.6.31 , which offer more fun to users, for real?

In other words, you suggest me, to make a fork of Slackware ARM, for use the modern Slackware on my netbook?

Yes, maybe I am able to do this, but today are sold hundreds of thousands android netbooks. I'm not sure that all of their owners are able to recompile Slackware, even if they are able to customize a kernel package.

Finally, In my opinion, trying to enter forced an gratuit incompatibility with the main vendor where you are able to get a functional kernel for you hardware platform, is a huge mistake.

1 members found this post helpful.

I agree completely with the op, this sound like stopping to support x86 platform when x64 come out. Maybe one day it will happen but how many years has passed ?
Slackware ARM it's now more like a toy than a distribution don't kill it completely. I don't think that Pat would ever do something like this, it's just pointless.

that's just unfair (better, read "bullshit"), you are saying this because probably you are not even using it: I do and I find it to be a functional Slackware for my arm devices (I'm not even considering the added value of the amount of dedicated documentation added by Stuart).
If you do use it and you have to criticize it about something, please elaborate and try to be specific.
actually, for what matters, in the x86/x86_64 glibc.SlackBuild is --enable-kernel=3.2.29

but, hoping I'm not missing something, I see no probs in rebuilding your own glibc with whatever --enable-kernel option you prefer, if you need it.

you can't blame distributions if vendors just can't keep up.

But Slackware x86/x86_64 do not have to deal with closed source or unported drivers for video, sound, ethernet, etc... But that have support ONLY on specific KERNEL which you have "to steal" from RHEL, if you want something basic like sound.

The main problem is that I talk about GLIBC, and no, you do not have the chance to rebuild your GLIBC, if the Slackware ARM current default kernel is not compatible with your hardware platform, because using the "right" kernel, stealed from Android, every application will gracious fail with "KERNEL TOO OLD".

I said also that an GLIBC rebuilding I can estimate to spend something like 12 hours, that, with all your Linux in a slow SDCARD?

Firstly, your approach sucks. You write some diatribe based on a number of incorrect assumptions. Instead of politely asking something like this:
"I see that -current requires a minimum kernel version of 3.1. I'd like to run it on my Android which is stuck on Linux 2.6. Is there a reason that 3.1.0 is needed; is there a possibility to change this?"

I have absolutely no interest in even going back in my mind to determine if it *is* required now. However, bare in mind that at some point, glibc will _require_ a newer kernel release (not just because I compiled it to), and most likely your device will still be stuck at an old kernel.
What you need to also consider is that these Android devices are meant to be used as-is. They're not for developers, so unless someone's particularly interested in the device, the support won't make it into the kernel.org kernels and you'll be stuck on an old Kernel release forever and a day.

Secondly, if you check the change log, you'll find that I *reverted* to an older minimum kernel so that the Raspberry Pi users could upgrade, since I thought that RPi users had a newer kernel than they did, because it's categorised as supported. Nowhere on the web site or in any of the documentation does it or has it ever said that Android devices, running an old Linux kernel is supported, and I have never recommended using Slackware ARM with someone else's Linux kernel and modules. If it was, I'd have probably not caused these devices to be rendered unusable with -current.

I provide two kernels for ARMv5 devices - Kirkwood Plug Computers and the Versatile machine which emulated by QEMU. These kernels provide *only* support for their intended platforms - they are not multi platform kernels, and would never support your Android device -- so your comment about them not providing support is an "epic" misunderstanding on your part. Given that currently the ARMv5 support is not multi platform, you'll never seen a kernel in Slackware ARM that can work on your ARMv5 android since I need to build individual kernels for each target device.

Celyr - your comment's just baseless. A 'toy' distribution? You have no understanding of the ARM ecosystem and how things hang together. If you'd bother to look at the supported devices and documentation, you'd find that it's installable with the regular Slackware installer on 4 device types. I'll leave it as an exercise to find out some more, should you be interested in venturing your mind in to the real world.

5 members found this post helpful.

Let me try to understand the logic here better. OP wants to run Slackware ARM on his device. But his device only runs on Android due to proprietary or non-mainline drivers. So he wants to use an Android kernel on Slackware ARM. But he can't run the Android kernel on Slackware-current, because of an ABI issue. Is this correct?

as I said before, I consider it a vendor choice, so it should be blamed.

consider that also additional steps needed to rebuild glibc are still depending from the same vendors choices: you can do it also in a virtual machine, if you have the need, and it will take the time it takes.

I can totaly understand Stuart's (drmozes) frustration to get his work understood and properly credited, especially considerered that the OP could have read the changelog, joined the mailing list and voiced his concerns there and probably in a more polite way.

However one good thing that I would like to pick from his post is that, in my opinion, in order for the ARM port to roam free and fly high, is to fork form the x86_64 directory structure and keep an eye (not just copy) on the Android/Linaro/Ubuntu ARM world, which has become the de facto standard, same as Slackware was the de facto standard Linux distribution in 1992-1993.

1 members found this post helpful.

Can you be more specific? The directory structure isn't particularly important - it's just a way to loosely categorise and order the packages. The build scripts aren't the same as those in the x86 tree and are independent: in some cases there are either subtle or significant differences in order to best suit ARM - gcc is such an example that springs to mind. In the case of glibc, in fact Slackware ARM has set a minimum kernel version much higher than x86 since armedslack 13.37 due to the (at the time) only supporting the Plug devices whose hardware support appeared in a far newer kernel than was the minimum required by x86's glibc. Slackware ARM's a port first and foremost, so I'll only make changes to the functionality and look/feel if absolutely necessary, sensible (according to what the project sets out to do - provide Slackware to desktop ARM machines and laptops), important then useful - in that order. Continuing with glibc, there's a reason why I chose a higher kernel release - and it stands alone from what ever is in the x86 configuration. To me, the idea is that if you know what minimum kernel versions your supported devices use in the last release of the OS, so as to permit a live OS upgrade. Then, try and minimise the extra bloat in glibc by not needing to compile in obsolete features in order to support kernels that your users won't be running. That's what setting the minimum kernel version is for.

There are a large number of idiosyncrasies in Fedora and Ubuntu with regards to various implementations and configurations, and these can be attributed to the general approach of those distributions. Given that I was able to get Slackware ARM running on the Chromebook in under 30 mins, and others have managed to get it running on a multitude of other devices, to me demonstrates that it's flexible enough to be used on a number of devices.

Stuart, just look at my previous posts, but I'll expand this further:

1) This is issue no.1. A modern Linux distribution should make the ARM architecture its main target. ARM devices are more widespread than PC's and laptops. If anything the x86_64 should catch up with ARM. Look at Windows 8, it's been developed with ARM devices in mind and it also works on PC's. We might not like Microsoft but they know a thing or two about target devices.

2) The ARM port should fork. That's it. The directory structure should be similar if not compatible with Android - a read only system partition, a 'cache' partition, and an external SD card. That's it. The concept of a file system that grows with time doesn't apply to smartphones and tablets.

3) The Chromebook is not the best example of a modern device. It's a unique device. It's an ARM netbook but netbooks are dead. The Chromebook is a thing of the past, a transition device between laptops and tablets.

I could go on. Nevertheless I support your hard work and I understand the limitations and the constrains you had to overcome during these years.

windows 8 is pure shit, so much that Mr. "developers, developers, developers" is gonna retire, so maybe you want to choose a different example.
what this has to do with Slackware? maybe you are thinking of a different distribution...

2 members found this post helpful.

I don't understand this logic at all. First off I would say the current tablet platforms ( IOS / Android )not having file system exposed to the user makes them simpler but it also is extremely confining in terms what applications can do and how they can share data.

As far as this readonly system, cache, and sd card business. Read Stuart's own post he is not targeting smartphones and tablets. Slackware has never worked anything like that out of box; something called Slackware should therefor not work like that.

Honestly Ottavio it sounds like what you and Darth really want is to run Android. If you were happily using Slackware ARM 14.0 its not as if its going to suddenly stop working the day 14.1, or 20.0 for that matter, is released. Nobody is expecting you to get rid of anything, and it should be little trouble building any higher level packages on 14.0 for good while yet. 14.0 will certainly be "supported" for a good while yet as well.

Finally keep up the good work Stuart your port is excellent!

1 members found this post helpful.

Actually, what it sounds like he's thinking of is 'Android'. Quite why Stuart would want to try and re-implement that is beyond me. I thought the whole point was to make a port of Slackware to ARM, not to be "modern" (whatever that means).

I don't buy the "netbooks are dead" line either. Desktop, laptop, netbook, tablet, smartphone all have their role to play and there is overlap at every step of the progression.


edit: Apologies chem, I went over some of the ground you'd already covered there - Hadn't read your post at that stage.

1 members found this post helpful.