LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 08-24-2013, 07:12 AM   #1
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 553

Rep: Reputation: 103Reputation: 103
Exclamation Slackware ARM (current) epic mistake: the current Android kernels are kicked out!


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!

Last edited by Darth Vader; 08-24-2013 at 09:42 AM.
 
Old 08-24-2013, 07:51 AM   #2
chemfire
Member
 
Registered: Sep 2012
Posts: 67

Rep: Reputation: Disabled
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.
 
Old 08-24-2013, 09:27 AM   #3
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 553

Original Poster
Rep: Reputation: 103Reputation: 103
Quote:
Originally Posted by chemfire View Post
Slackware ARM is a software project; it should focus on providing the most current stable software platform.
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..

Quote:
Originally Posted by chemfire View Post
If your hardware is not supporting more recent kernels you should stay on the older software platform; IMHO.
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?

Quote:
Originally Posted by chemfire View Post
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.
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.

Last edited by Darth Vader; 08-24-2013 at 09:59 AM.
 
1 members found this post helpful.
Old 08-24-2013, 10:23 AM   #4
Celyr
Member
 
Registered: Mar 2012
Location: Italy
Distribution: Slackware+Debian
Posts: 314

Rep: Reputation: 77
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.
 
Old 08-24-2013, 10:48 AM   #5
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
Quote:
Originally Posted by Celyr View Post
Slackware ARM it's now more like a toy than a distribution don't kill it completely.
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.
Quote:
I don't think that Pat would ever do something like this, it's just pointless.
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.

Last edited by ponce; 08-24-2013 at 11:11 AM.
 
Old 08-24-2013, 11:14 AM   #6
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 553

Original Poster
Rep: Reputation: 103Reputation: 103
Quote:
Originally Posted by ponce View Post
actually, for what matters, in the x86/x86_64 glibc.SlackBuild is --enable-kernel=3.2.29
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.

Quote:
Originally Posted by ponce View Post
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.
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?

Last edited by Darth Vader; 08-24-2013 at 11:20 AM.
 
Old 08-24-2013, 11:19 AM   #7
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 116

Rep: Reputation: 85
Quote:
Originally Posted by Darth Vader View Post
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..
.
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.
Old 08-24-2013, 11:20 AM   #8
the3dfxdude
Member
 
Registered: May 2007
Posts: 304

Rep: Reputation: 66
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?
 
Old 08-24-2013, 11:21 AM   #9
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
Quote:
Originally Posted by Darth Vader View Post
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.
as I said before, I consider it a vendor choice, so it should be blamed.

Quote:
The main problem is that I talk about GLIBC, and no, you do not have the chance to rebuild your GLIBC, if the current kernel is not compatible with your platform, because 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?
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.

Last edited by ponce; 08-25-2013 at 01:14 AM.
 
Old 08-24-2013, 05:22 PM   #10
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
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.
Old 08-25-2013, 12:30 AM   #11
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 116

Rep: Reputation: 85
Quote:
Originally Posted by ottavio View Post
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.
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.

Last edited by drmozes; 08-25-2013 at 12:31 AM.
 
Old 08-25-2013, 04:42 AM   #12
ottavio
Member
 
Registered: Nov 2007
Posts: 312

Rep: Reputation: 46
Quote:
Originally Posted by drmozes View Post
Can you be more specific?
Stuart, just look at my previous posts, but I'll expand this further:

1)
Quote:
Originally Posted by drmozes View Post
Slackware ARM's a port first and foremost
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)
Quote:
Originally Posted by drmozes View Post
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.
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.
 
Old 08-25-2013, 05:33 AM   #13
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
Quote:
Originally Posted by ottavio View Post
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.
windows 8 is pure shit, so much that Mr. "developers, developers, developers" is gonna retire, so maybe you want to choose a different example.
Quote:
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.
Quote:
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.
what this has to do with Slackware? maybe you are thinking of a different distribution...
 
2 members found this post helpful.
Old 08-25-2013, 06:07 AM   #14
chemfire
Member
 
Registered: Sep 2012
Posts: 67

Rep: Reputation: Disabled
Quote:
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.
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.
Old 08-25-2013, 06:13 AM   #15
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Quote:
Originally Posted by ponce View Post
what this has to do with Slackware? maybe you are thinking of a different distribution...
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.

Last edited by GazL; 08-25-2013 at 06:14 AM.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] setup fails on most current Slackware-current March 26, 2012 AlleyTrotter Slackware 15 04-09-2012 06:05 AM
[SOLVED] Script to build always a current ISO image of Slackware (slackware-current) robertjinx Slackware 2 12-09-2010 02:00 AM
Using Slackware-Current kernels in Slackware-11 davimint Slackware 3 06-13-2007 03:23 PM
slackware current question on the current kernels davimint Slackware 3 06-03-2007 07:39 AM
DISCUSSION: Upgrade to Slackware -current without a -current CD truthfatal LinuxAnswers Discussion 0 09-19-2006 01:42 PM


All times are GMT -5. The time now is 02:19 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration