Quote:
Originally Posted by ottavio
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.
|
Thanks for explaining your view point - now I understand how you see this, and I agree *when* I consider it from that view point. However, I agree with Ponce's last comment - you'd need to look for another distribution:
Firstly I'm not going to fork Slackware ARM, as it'd then not be 'Slackware'. Secondly, I'm not personally interested in providing support for tablets or smart phones - I'm happy with whatever's already on such a device and I can't ever imagine using Slackware on such a device - it just doesn't make sense to me (for at least some of the technical reasons you have identified, but also because Slackware provides for, and comes from an x86 world of desktop, keyboard and monitor; and it's just fortunate in some regards, that this is the exact same setup I started ARMedslack on in 2001 - albeit an ARM desktop machine; so the use case aligned perfectly). Thirdly, even if I did have an interest in this, the amount of sustained development effort would be immense and would circle back to your comment about x86 following ARM's path -- which just wouldn't happen.
I'm an ex Red Hat employee and have a number of good friends from that time, who now work for Canonical (Ubuntu) (Canonical absorbs many ex Rad Hat employees btw) - who as you probably know, are making a SmartPhone. The amount of developers and *effort* involved daily in their work is staggering. Slackware does not have paid developers whose time is 100% on Slackware. Also, consider that for Patrick, anything he takes from a 3rd party - if that person goes away then the onus is on Patrick to maintain it or find someone else to maintain it: so it's not easy for him to add in some complex functionality (this applies to anything) that everyone gets used to having, then wonder how to maintain it, or consider a very risky user-base abandonment as a result of chopping it out.
Quote:
Originally Posted by ottavio
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.
|
That's true to some degree (it took over ten years for one to arrive!), but there are still ARM desktop-like machines being produced - the Trimslice has been supplanted with another desktop type device which has an internal SDD.
When I first started porting Slackware to ARM, the sole intention was to have it on my StrongARM RiscPC - an ARM based desktop machine. This was simple because I could provide a kernel and instructions. There was only one device with minimal scope for adjustment, so it was easy for people to install and use. Now there's a plethora of devices to contend with. Even now I'm supplying a generic ARM7 kernel, I have no way of knowing whether it'll run on the devices I've supported in the kernel config (apart from the Tegra20 since I have that device)- the luxury of x86's standardisation just doesn't exist.
Therefore I shifted the aims of the Slackware ARM distribution to be this:
* Provide support directly for the devices I'm personally interested in hacking around on.
* Other devices can be supported by those whom have an interest - eg Raspberry Pi - and can have those 'supported' as a community.
* The user land packages are free for people to do what they want with it - chop it up to make it fit their needs.
If I mentally hop in to your view point and look towards the future: assuming that desktop PCs continue to decline (all stats suggest that's the case, and you only have to look at your own usage patterns and that of your friends) and the majority of users move to tablets as their primary device, then indeed it would seem to place Slackware into a greater niche; but that's a bigger discussion.
I hope this insight helps understand where Slackware and Slackware ARM is and why making particular changes isn't straight forward.
