(04-30-2016, 07:29 AM)nomadewolfThe more, the merrier, in this case. Wrote: The more, the merrier, in this case.
Everyone has their own preference, and Linux all about choice.
Where's the point to hack together another crappy OS image if there are development tasks that need real attention? Less is more in this case and instead of producing 'just another Linux thing' real devs should start to do real work.
As an example for such an aforementioned crappy OS image let's have a look at this featured Ubuntu OS image:
http://wiki.pine64.org/index.php/Pine_A6....2C_Pine64
I've no idea who created this image and
why since it just sucks completely. It's already outdated (both kernel and u-boot need updates but since there's no documentation no user of these images does even know that there are necessary updates available!). Since the history is not cleared we can have a look what's different between this 1.8 GB image and
longsleep's 160 MB original:
Code:
ubuntu@localhost:~$ history
1 bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
2 sudo bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
3 su
4 sudo curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh
5 ls
6 sudo curl https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh
7 ls
8 sudo curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh > uboot.sh
9 ls
10 ls -a
11 sudo chmod 755 uboot.sh
12 uboot.sh
13 ./uboot.sh
14 sudo ./uboot.sh
15 sudo curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh > uboot.sh go
16 sudo curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_kernel.sh > kernel.sh
17 sudo chmod 755 kernel.sh
18 sudo ./kernel.sh
19 sudo reboot
20 sudo apt-get update
21 sudo resize_rootfs.sh
22 df -h
23 sudo apt-get upgrade
24 sudo apt-get install xbuntu
25 sudo apt-get install xubuntu
26 ls
27 cd /etc
28 ls
29 cd apt
30 ls
31 vi ./sources.list
32 ls
33 cd
34 sudo apt-get install ubuntu
35 sudo apt-get update
36 sudo apt-get install xubuntu-desktop
37 sudo reboot
38 ls
39 mv uboot.sh update-uboot.sh
40 mv kernel.sh update-kernek.sh
41 sudo apt-get update
42 sudo apt-get upgrade
Obviously only the
xubuntu-desktop package has been installed and the image has been resized from 3.8 to 8 GB for whatever reasons. And 2 of longsleep's update scripts have been put (renamed wrongly) in ubuntu's home:
Code:
-rwxr-xr-x 1 ubuntu ubuntu 1877 Apr 21 04:09 update-kernek.sh
-rwxr-xr-x 1 ubuntu ubuntu 2261 Apr 21 04:08 update-uboot.sh
So why is there a 'need' to create an outdated 1.8GB ubuntu image? Ah, Desktop environment, of course. X-Windows, this sort of stuff. With a kernel that's only able to drive displays with 1080p60
We do have 2D acceleration already available for this Ubuntu image (
provided also by longsleep as an launchpad PPA that already added to this image). So why the heck are the two necessary packages
NOT installed already?! It takes an additional
Code:
sudo apt-get install libump xserver-xorg-video-fbturbo
to get the available 2D acceleration. How many users know this?! This is developer's work thrown in the bin!
Next issue: HW accelerated video decoding: We have this available/useable
since the Mid of March. The kernel features are ready so why isn't a movie player included that makes use of libvdpau-sunxi to get true HW acceleration? Why is 'export VDPAU_DRIVER=sunxi' missing in an
approriate start script? What's the purpose of a desktop image that doesn't make use of developer's hard work to get HW acceleration running?
Next issue: Networking troubles when using more than one Pine64:
Code:
root@localhost:~# cat /boot/uEnv.txt
console=tty0 console=ttyS0,115200n8 no_console_suspend
kernel_filename=pine64/Image
initrd_filename=initrd.img
ethaddr=8e:21:0d:2e:ad:67
The 'ethaddr' line
must not exist in uEnv.txt when providing an OS image! The value here has to be calculated randomly on first boot and then used to provide unique MAC addresses on all Pine64 in the network. With this image you get already in ARP/network troubles when used with more than one device.
At this point I already got so sick of this image and stopped testing. The other Ubuntu OS image featured in the wiki is known to contain even more mistakes. Why should this change when people start to combine just another boring arm64 Linux rootfs with longsleep's real work?
There are so many unresolved issues and any further fragmentation (both 'community wise' and regarding available OS image variants) will prevent resolving them. And my main argument against any more OS image is that their announcements/documentation always suppress
necessary information.
All these OS images are based on the linux-sunxi community's and longsleep's work. For all of the OS images the limitations he clearly wrote apply (eg.
http://forum.pine64.org/showthread.php?tid=376). Not also providing the list of limitations with another OS image is simply fooling users (have a look through the forums how many people think their Pine64 is DOA simply because the kernel each and everyone uses at the moment does not negotiate a display when it's not 1080p60)
If you want to do something useful look at enabling Bluetooth, build mpv/mplayer packages that make use of HW accelerated decoding (less OS images --> less packages!), look into the HDMI issues, package the
necessary fixes to GPIO libraries and so on. There's so much
real work to do!