I'm trying Vivaldi on Ubuntu MATE now to see how efficient it is over here vs on Raspbian. Maybe there's a way to create swap on an external drive for Firefox to work. I have tried researching ways to create swap via file or partition, but none of them persist across reboots. Perhaps someone could be kind enough to give instructions? It's just that I prefer Firefox and have used it for so long. Plus all my data is on it... EDIT: Even Vivaldi is slow with more than one tab open on Ubuntu. On Raspbian, not so much. Actually, even with the 1GB swap Vivaldi also froze the whole system with three tabs open, one of which being settings. Didn't notice this on Raspbian. There's some good groundwork with Ubuntu MATE, but it's just not as optimized, at least not yet. From what I remember 16.04 was fast on my Pi 2B.
I was able to install the official Ubuntu Server 18.04 for RPI3 and then install Mate desktop on it. So far, I only faced one problem which I struggle to resolve. I setup x11vnc server and get severe graphical artifacts that renders the desktop almost unusable.
I opened an issue here on the x11vnc Github page: https://github.com/LibVNC/x11vnc/issues/88
But could this be an issue with Ubuntu 18.04 on rpi3 somehow? I tried changing the x11vnc parameters but they all end up with the same corruption more or less. Can anyone replicate this on the RPi3B+?
need to know if 18.04 is going to be supplied or that mate will be abandoned on the raspberry pi
because support is running out
It is looking likely that there won't be a 18.04 mate image anytime soon. However, as people have demonstrated this does not mean that you can't run mate 18.04 on a pi.
Support is not running out on 16.04. You won't get security updates on mate desktop packages, but I bet there has never been a security update in the lifetime of 16.04 on these packages. Bugs won't get fixed, but you've lived with these bugs for 3 years. So you are not loosing anything.
Firefox etc will continue to receive updates. Whether these new versions work or not who knows? It could be argued support for armhf finished a long time ago when Firefox stopped working.
Hmm. If I were to get ba Pine64 board with 4GB RAM or some alternative to the Pi (down the line of course), I wonder if it'd have the free system resources and community support the Pi 2 had on 16.04. Those were the golden days.
What have you contributed to the community?
I don't now much about pine64. The only image that I know of for the pine64 is kde neon. The Pi can run this too AArch64 on Raspberry Pi 2 (rev 1.2), 3B, 3B+
Pine64 looked good until I read it violates the GPL. Not a good choice.Plus that means it can only run up to a certain kernel version. The CPU is what's violating the GPL. I can't code, sadly, but I've contributed some money out of the little I make.
Just curious: How can the CPU of the board violate the GPL?
It's clear that donating money to Ubuntu MATE isn't having any impact on the development of the Pi images. Apparently, there are issues which are preventing the creation of an 18.04-based image for the Raspberry Pi. I've tried creating 18.04-based images on an x64 Ubuntu 18.04 host, and it fails to install the desktop environment. It hangs at 'Setting up ifupdown' and doesn't go any further.
The only issue preventing the creation of Pi images is time. I don't know Martin, but it is clear that he is prioritising spending time with his family and pursuing new interests, and who can argue with that? He has previously committed a lot of time to UM, and this must of helped to land him a job at Canonical. Who wants to spend their free time doing the same stuff as their job? It needs somebody else to take over the creation of pi images.
UM receives a lot of money each month. I don't know what happens to this now, but it used to be the case that it was 'donated' back to people who had worked on the project. So if somebody were to create an image that could be recreated and distributed then they would be contacted and offered money. That is how it used to work anyway. Whether you agree with that (I don't) is another matter.
This is potentially easy money for somebody. I've already posted on how to create an installer (which is IMHO what should be produced). It is even simpler now with the 3B/3B+ being officially supported in packages. A lot of the custom stuff disappears. Just build them like the old omap4 installer.
Last night I experimented with live build on a x64 host and it worked fine.
I have a Raspberry Pi 3 running Ubuntu Server with the Xubuntu desktop setup. I'll use that to build images.
Ubuntu MATE 18.04 and Firefox Quantum running on the Raspberry Pi 3. Expect an image to be released on the Ubuntu-ARM64-RPi GitHub page soon (although it could take up to a couple of days because my internet connection when uploading large files is rubbish) This will work on the Pi 3B+ as well.
Sweet!.....thanks for the effort. I REALLY appreciate it.
I've put together a sample script for anybody wishing to create armhf installers for the pi. This uses live-build to kick out an armhf installer hdd image.
Please link me to this script, I'm wondering if I could adapt it for arm64.
I'll post it this evening, but I've already posted scripts on how to build an arm64 installer. You'll need similar custom preseed scripts because arm64 ubiquity doesn't have flash-kernel-installer (otherwise you would have to rebuild/adapt ubiquity some other way).
EDIT: I've made the above sound a bigger deal than it is. flash-kernel-installer doesn't do much, and flash-kernel will probably be run multiple times by the installer anyway.
For arm64 I think you should forget about bionic and look at disco. You could build a generic installer for that using grub2.
To be honest, I don't see the point in pushing arm64 at pi users. For one thing a lot of pi python stuff doesn't work on arm64. For the niche users who need it, then they can install via the mini iso or server image.
I've already made an ARM64 Disco image with GRUB2 and the generic kernel (not an installer through) but I'm aware of multiple bugs in the image and I don't really plan on maintaining it. I might create a script on how I made it for anyone who's interested in maintaining the image and using it to make their own images.
I haven't got around to testing this:
https://1drv.ms/u/s!AvHY_kl4hMB4gQmqrT5rpI3vVSBY
For arm64 you need different preseed files (see earlier links).
EDIT: Sigh, you always spot a mistake when you post something without testing it...
release_ver=$(distro-info --series $PROJECT -r | awk '{print $1;}')
should be
release_ver=$(distro-info --series $SUITE -r | awk '{print $1;}')
Being pedantic ${LB_BOOTSTRAP_QEMU_STATIC} should probably be added to config/binary_rootfs/excludes