DEV Community: LiveG Technologies

What's new in LiveG OS V0.2.0: multiplatform support and plenty more

James Livesey — Tue, 29 Aug 2023 10:06:45 +0000

After almost a full year of working on developing new features for LiveG OS, we're excited to announce the latest Alpha release of LiveG OS that is now available for a range of devices, including for the Raspberry Pi, the PinePhone, and both x86-64 and ARM64 computers. This new release realises our goal of making LiveG OS a truly multiplatform operating system, and one of only a few operating systems that can run on both desktop and mobile device form factors.

Our latest episode of LiveG Showcase demonstrates all the new features included in this new release, which is now available on YouTube. In this post, we'll be giving you a summary of these new features.

Multiplatform support

This release of LiveG OS is the first to run on the Raspberry Pi. LiveG OS runs particularly well on the Raspberry Pi 4 and the Compute Module 4, but it also runs on the Raspberry Pi 3. The system runs smoothly on the Pi 4 and is more-or-less as fast as it is on conventional x86-64 computers, but you may experience slowness and higher power consumption when running it on older models such as the Pi 3.

In addition to the Raspberry Pi, LiveG OS now also runs on the PinePhone smartphone by PINE64. This makes LiveG OS officially available for mobile devices alongside the current option for running it on the desktop. LiveG OS won't run on the PinePhone Pro just yet — anyone who wishes to volunteer to bring LiveG OS to the PinePhone Pro should check out our LiveG OS Bootstrap Toolchain repository on GitHub and also join our Discord community.

You can try out this release of LiveG OS now for the Raspberry Pi and PinePhone — and even x86-64 and ARM64 computers — by downloading an OS image for your platform from our website. It's simple: after downloading the image, use a tool such as balenaEtcher or the Raspberry Pi Imager to flash the image onto an SD card, then boot it on your device and follow the setup instructions presented inside LiveG OS.

Installable web apps

Progressive web apps — or PWAs — can now be installed in LiveG OS thanks to the new option to install websites as web apps in our Sphere web browser. Any website can become an app in LiveG OS, and website can take advantage of extra features such as maskable app icons through the use of a web app manifest.

Web apps open up large opportunities that can allow LiveG OS to compete with today's major operating systems, as PWA technologies enable a large range of existing apps to be installed to LiveG OS, such as Mastodon, Twitter, YouTube — and even our own apps, like LiveG Docs. The OS-independent compatibility that web apps have make PWA technologies an ideal platform for LiveG OS, and LiveG OS's own system apps — and even its desktop environment, gShell — are themselves made using web technologies.

App menu search, power and app sorting options

Apps that are installed now show up in the app menu in LiveG OS. The app menu now also includes a number of useful features that make searching for apps easier. You can now sort apps alphabetically by choosing the alphabetical view option, or you can search for apps by using the search bar.

App shortcuts also appear when using the search bar, making it easy to access certain features of apps. For example, you can search for network options in Settings by typing 'network' into the search bar.

Finally, there are options to lock, shut down or restart LiveG OS in the power menu. This removes the need for the LiveG OS Debug Environment to shut down the system, which has now itself been removed in this release.

Tab-based interface in Sphere

Browsing the web has become much easier in the Sphere web browser now thanks to the new, tab-based interface in Sphere. The tab-based interface work similarly to what is seen in other modern browsers, allowing users to have multiple webpages open at once without needing to open multiple windows.

The tab-based interface is also available on mobile by pressing the tab list button. We hope to release an API for the tab-based interface in the future for web apps to allow them to take advantage of this paradigm: for example, the file manager app we hope to release soon would benefit from a tab-based interface to make file management across multiple folders much easier to perform.

Gesture-based app switcher navigation on mobile

On mobile, the app switching experience has been improved through the addition of swipe gestures to quickly jump between apps. Swiping up from the LiveG logo at the bottom now reveals the app list — just like what happens when you double-tap the logo. Swiping left and right on the logo will switch between apps listed adjacently to the current-viewed app without needing to show the app list, reducing the time it takes to switch between apps.

The addition of this new gesture-based navigation method brings LiveG OS closer to the experiences seen on other major mobile operating systems.

Update system

LiveG OS now has an update system, making it easier for users to download and install new system updates in the future when they are made available. Users can now update the system through the Settings app, where they can also configure the update circuit under advanced options, allowing them to take advantage of cutting-edge features not yet present in stable releases.

The update system is designed to not be distracting or disruptive to its users — users can be assured that their system will not restart unless they tell it to, and updates are not forced on users (though users are strongly recommended to update when possible to benefit from security patches). The system is also designed to be robust against unexpected system shutdowns such as power outages with a number of rollback mechanisms implemented to recover the system in these scenarios back to the previous update.

New options added to Settings

Alongside the new update system, we've also added a few additional options to the Settings app to make LiveG OS more useful.

Users can now configure their Wi-Fi networks and supply authentication options for them, such as Wi-Fi passwords. LiveG OS allows authentication for a range of security standards, including WEP, WPA, WPA2, and the enterprise standards, otherwise known as 802.1x.

There are also new options to configure the keyboard layout for LiveG OS. This is particularly useful as LiveG OS can already be used in the French language, and so we've needed a way for users to switch to the French AZERTY layout and not just British QWERTY. We've also included support for the US QWERTY layout, as well as Chinese pinyin text entry, which uses the Input Method Editor to provide text suggestions.

Keyboard layouts also work on mobile, and we hope to soon have a way of quickly switching between layouts without having to go into Settings.

Another new addition to Settings is our interaction and privacy options. These options make it easier to choose how LiveG OS will interact with our online services, such as when the update system will check for updates. You can choose to enable all the options, which integrates LiveG OS nicely with our online offerings, or if you don't feel you need our online services, then you can switch the options off.

LiveG OS Setup improvements

And finally, there have been a few improvements to the out-of-box setup system — or OOBS, as we call it — including another power menu and an accessibility menu for enabling accessibility options such as Switch Navigation while users are setting up their device, in addition to a new setup step for configuring interaction and privacy options so that you can easily turn on or off these options before you use the system.

Additionally, there are now animated graphics included in the OOBS steps that make setting up LiveG OS just a bit more interesting and visually appealing.

Future plans

So that's a run-down of the new features that have been included in LiveG OS — no wonder it's been a while since our last release. However, we recognise that there is still a lot to be done to LiveG OS before it becomes daily-drivable.

Our main focus for developing the next update will be to build some new system apps, such as a calculator; a file manager; apps with cellular features such as SMS texting and phone calling; and a few other useful tools that will bring LiveG OS in-line with other systems functionality-wise.

It's also worth noting some of our 'side projects' that we've been working on for LiveG OS, and we're excited to be integrating them fully into the system soon: these are the Typeset Engine code editor that we hope to integrate into an IDE; LiveG Search that will soon be getting a new crawling and indexing system; and Formulaic, our expression evaluation engine that we hope to implement into a system calculator app.

It's a bit early to say this just now, but we're thinking about also integrating Linux apps into LiveG OS, so you can easily use your favourite Linux applications right in gShell, much like you can do on ChromeOS. I know that once this feature has been implemented, I'd definitely install LiveG OS onto my next laptop and use it for everything! We might not see this for version 0.3.0, but it's certainly on our radar.

So, that's a look at some of the new features in the latest Alpha release of LiveG OS. You can download LiveG OS now, which is available in English and French for a variety of platforms.

You can support us financially by donating to our Open Collective, where we use the donations we get to advance our projects. You can also support us by joining our Discord community where you can help us with the development of our projects.

Follow us on Mastodon and Twitter to keep in the loop with the latest updates to all our projects, and subscribe to our YouTube channel where you can find videos on various aspects of LiveG, including release announcements and development guides.

This article was originally posted on The LiveG Blog.

LiveG OS: how we built our own multiplatform operating system

James Livesey — Fri, 04 Nov 2022 13:20:00 +0000

Some time ago, we released our first edition of LiveG OS, an open-source operating system that is designed to run on both desktop and mobile devices.

It's based on a modified version of Debian Linux with our own web-based desktop environment on top, and is designed to run Progressive Web Apps in a more integrated experience than what other operating systems provide.

You can learn more about the OS on mobile devices on our last post, Project Prism: on the road to building an open smartphone.

In this post, we're going to show you how we built our OS, from downloading the initial Debian base image to producing a full ISO file that can be distributed and loaded onto installation media such as USB drives to run on real hardware. We also have a LiveG Developer Guide on YouTube that gives a more in-depth explanation of how we do this:

Right now, our OS only supports modern PCs running x86-64 processors (so your typical Intel or AMD processor of today). You can download a copy of LiveG OS right now to try out on modern PC platforms — or in a virtual machine on QEMU or VirtualBox, but it's still in an early Alpha stage, so don't expect it to do too much yet (there's still a lot of missing features).

For platforms such as the PinePhone or Raspberry Pi, we're planning to bring support to these devices over the next few weeks. Exciting stuff indeed!

With all that talk about LiveG OS out of the way, let's dive into how we actually build LiveG OS!

Building our desktop environment

Our desktop environment, gShell, is what provides a user interface that the user can interact with. Being written as an Electron app itself, it's the part that also runs the Progressive Web Apps inside webview elements.

I won't go too much into gShell's architecture, but for the purposes of this post, all you need to know is that we build an AppImage file using electron-builder to supply that file to our OS bootstrapping process (which is what we'll be moving onto next).

Building the OS itself

The OS build process is all automated, and relies on a bunch of bash scripts so that we can make a reproducible and robust copy of LiveG OS everytime we run them. This also lets us make different builds for different platforms while still producing a similar end result.

We keep all of those bash scripts in a GitHub repository, alongside all the other useful files (mainly for configuring parts of Debian) needed to build a complete operating system. There's a bunch of information on how to build LiveG OS yourself in its readme.

In short, we essentially run this command in bash to start building everything:

./bootstrap.sh

That's it — we can then sit back, and relax! Let's take a look at what this script exactly does by breaking it up into a series of simple steps:

1. Determine what platform to build for

Like I said earlier, we're hoping to support various platforms very soon, like the PinePhone and Raspberry Pi — in addition to our currently-supported x86-64 version.

Our bootstrap.sh file handles this by storing what platform we want to build for (as well as the architecture and QEMU emulation info) in a bunch of global variables. We can choose what platform to build for by passing it as the first argument to the script's command.

export PLATFORM="x86_64"
export QEMU_ARGS=""

if [[ "$1" != "" ]]; then
    export PLATFORM=$1
fi

case $PLATFORM in
    x86_64)
        export ARCH="x86_64"
        ;;

    *)
        echo "Invalid platform specified" >&2
        exit 1
        ;;
esac

if [[ "$2" == "--env-only" ]]; then
    echo "Applied environment variables for execution of other scripts only"
    return
fi

2. Start a web server so that QEMU can access files

We use QEMU to virtualise the system so that we can test it out and also configure it and set it up during the build process. One thing that we need to be able to do is let our virtual machine access our host's files. The way to do that is to start a web server that can be accessed over the local network by the virtual machine.

This web server is started when bootstrap.sh calls server.sh, which starts the server in the background:

pushd host/$PLATFORM
    pkill -f "python3 -m http.server"
    python3 -m http.server 8000 &
popd

We then continue through bootstrap.sh as soon as the server has started.

3. Download a minimal base copy of Debian

Since LiveG OS is based off of Debian, we need to grab a copy of it so that we can make our own customisations off of it. We just simply use wget to download the Debian installer ISO file into a repo folder:

mkdir -p cache/$PLATFORM
wget -nc https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso -O cache/$PLATFORM/base.iso

4. Boot the base copy of Debian and install it onto a new virtual disk

Once we've got our copy of the Debian installer downloaded, we need to run it in a QEMU virtual machine and install it onto a new virtual disk. This is done in boot.sh:

    echo "Creating new base installed image (this might take about 30 minutes or longer)..."

    qemu-img create build/$PLATFORM/system.img 4G

    ./bootkeys.sh &

    qemu-system-$ARCH \
        -enable-kvm \
        -m 1G \
        -cdrom cache/$PLATFORM/base.iso \
        -hda build/$PLATFORM/system.img \
        -netdev user,id=net0,hostfwd=tcp::8002-:8000 \
        -device virtio-net-pci,netdev=net0 \
        -monitor tcp:127.0.0.1:8001,server,nowait \
        $QEMU_ARGS

    cp build/$PLATFORM/system.img cache/$PLATFORM/baseinstall.img

This takes about 30 minutes to go through installation without KVM, but if you've got KVM enabled, then it only takes about 4 minutes. It's worth enabling KVM for!

Running the Debian installer

Don't forget that this is all automated — we as the developer don't need to touch a single thing. The way we do this is provide a preseed file, preseed.cfg to the virtual machine that the Debian installer uses to automatically provision the system. Without this, we'd have to manually enter what username and password we want to use, what timezone we are in, what network interfaces to enable, and so on — we don't want to have to do that every time...

5. Mount the virtual disk and add some files to it

We next need to mount the disk so that we can change some of its files and add a script that runs at startup. This is done in the boot.sh script:

echo "Mounting disk image to \`build/$PLATFORM/rootfs\`..."

sudo umount build/$PLATFORM/rootfs || /bin/true
mkdir -p build/$PLATFORM/rootfs
sudo mount -o loop,offset=1048576 build/$PLATFORM/system.img build/$PLATFORM/rootfs

We can then write files to the mount point and they'll be saved to the virtual disk image file upon unmounting.

After mounting the disk, we write some files to it, including ones to automatically log in the default user account (so that we can then start up our desktop environment), to change the hostname, as well as to change some branding details:

sudo tee build/$PLATFORM/rootfs/etc/issue << EOF
LiveG OS \n \l
EOF

sudo tee build/$PLATFORM/rootfs/etc/os-release << EOF
NAME="LiveG OS"
VERSION="0.2.0"
ID="livegos"
ID_LIKE="debian"
PRETTY_NAME="LiveG OS V0.2.0"
VERSION_ID="0"
HOME_URL="https://liveg.tech/os"
SUPPORT_URL="https://docs.liveg.tech/?product=os"
EOF

We also copy firstboot.sh to the mount point and configure the system so that the next time we boot it up, the firstboot.sh script is run (this lets us perform further customisations that are only possible when the system is booted):

sudo cp firstboot.sh build/$PLATFORM/rootfs/root/firstboot.sh

sudo tee -a build/$PLATFORM/rootfs/root/.bashrc << EOF
./firstboot.sh
EOF

Finally, we unmount the virtual disk image so that we can boot it.

6. Start up the system and execute the `firstboot.sh` script

We start up the system, again in boot.sh, by executing this QEMU command:

qemu-system-$ARCH \
    -enable-kvm \
    -m 1G \
    -hda build/$PLATFORM/system.img \
    -netdev user,id=net0,hostfwd=tcp::8002-:8000 \
    -device virtio-net-pci,netdev=net0 \
    $QEMU_ARGS

This script installs some necessary dependencies via APT for our desktop environment to work. It also adds our very own LiveG APT Repository that we maintain to install packages not present in the Debian APT repo, including custom Linux kernel builds for devices such as PinePhones.

Booting up in QEMU with the firstboot.sh script running

The script also copies in the AppImage binary for our desktop environment itself, as well as some config files for GRUB and fstab that are copied during the LiveG OS Out-of-Box Setup process when you want to install LiveG OS to an internal storage device.

The script finally cleans up some parts of the system, which essentially consists of changing config files to prevent itself from running at startup at the next boot, and instead starting the desktop environment at boot. The system then shuts down so that bootstrap.sh can continue.

7. Mount the virtual disk again to copy more config files

This stage copies config files to the virtual disk, which includes isogrub.cfg, which configures GRUB to boot correctly in a Live CD/ISO environment, as well as isofstab and the initoverlay.sh script. This is all done inside the makeiso.sh script run by the host machine.

This process of making an ISO file is not required for some platforms — for the PinePhone and Raspberry Pi, we won't need to build an ISO file, since the virtual disk image will be copied directly onto an SD card or eMMC storage and is bootable from there.

initoverlay.sh is very important for the ISO file to be able to run — the ISO image's filesystem is read-only, which makes starting our desktop environment (to perform installation by the user onto a target disk) difficult. This script adds a filesystem overlay mapped to /tmp to make the whole root filesystem temporarily writeable. All changes are discarded in the ISO environment when the system shuts down, but being temporarily writeable to RAM is useful for running certain programs.

8. Produce an ISO image with GRUB on it

We finally need to package the mounted root filesystem from the host into one distributable ISO file. This is done by running grub-mkrescue in makeiso.sh:

sudo grub-mkrescue -o build/$PLATFORM/system.iso build/$PLATFORM/rootfs --directory=build/$PLATFORM/rootfs/usr/lib/grub/i386-pc -- \
    -volid LiveG-OS-IM \
    -chmod a+rwx,g-w,o-w,ug+s,+t,g-s,-t /usr/bin/sudo -- \
    -chmod a+rwx /usr/sbin/initoverlay --

It also gives the ISO a volume name of LiveG-OS-IM so that it can be identified by GRUB later on, and it also changes permissions for the sudo and initoverlay commands so that they can be executed.

The final ISO image running in QEMU

That's it! If you wish to use any of this code (you're welcome to use it for your own projects), then be sure to make it available under the LiveG Open-Source Licence — AKA attribute us and also provide a copy of the licence alongside your own code.

I hope you've enjoyed reading up on how we build LiveG OS, and I'll be looking forward to releasing downloads for the OS for PinePhones and Raspberry Pis soon!

In the meantime, you can visit our GitHub organisation to see our various ongoing projects. You can also find us on Twitter or Mastodon, and you can join us on Discord where we have a weekly meeting on Tuesdays on what we're planning to do next with LiveG. We've got plenty of videos on LiveG OS on YouTube to watch, and if you're wanting to support us, the best way to do that is to donate to our Open Collective. All of this info is available on our website, liveg.tech.

Thanks for reading, and we'll see you soon!

Project Prism: architecture overview

tramcrazy — Fri, 08 Apr 2022 15:42:08 +0000

Earlier this week, our CEO James wrote about our ambitious plans to build a truly open smartphone - based on web technologies. This is the first in a series of posts about the project, where we'll be covering our progress on different sections of this complex project. If you haven't read that first post, you should do so now - then you'll have a better understanding of our project.
Read the post here

Before we get started...
Hi! My name is tramcrazy, and I am CISO at LiveG. That means that I oversee all our cybersecurity systems and check code for issues. I also work on documentation.

At the foundation of gShell (the software running on the Prism) is Linux. We love Linux's open-source nature and the huge community that has grown around it in the last 30 years. It was the sensible choice for Prism. The specific version of Linux running on Prism is Mobian (mobian-project.org), which is a version of Debian designed for mobile phones. The underlying OS of Mobian could change in the future, because gShell runs in Electron which works on all operating systems.

Above Mobian is the X11 window system. This is the graphical user interface (GUI) of choice on Prism, and provides the desktop environment needed for gShell to function.

Above Mobian and X11, we have gShell itself. This runs in an Electron runtime which uses HTML, CSS and JS to provide a full mobile experience, along with NodeJS for the backend.

This is the full hierarchy of the Prism phone's OS, with extra explanation where needed:

Linux Kernel
 L X11 Xsession
   L gShell (Electron runtime)
     L OOBS (Out-of-box setup) - a first-time setup menu like the ones you might be familiar with on iOS or Android.
       L Basic power menu - a simple power menu providing options to shutdown or reboot.
     L Lock screen - a screen showing the current time, the user's background, and notifications. It also checks the password and switches to the user environment.
       L Notifications - a standard notifications drawer with various messages, some with actions to be performed inside the user environment.
       L Incoming call screen - this pops up when somebody is calling you, and handles the UI during the call.
       L Basic power menu
     L User environment - the environment used by the user once they have unlocked their phone. This lets the user open apps and perform other functions.
       L User-specific power menu - this is based on the basic power menu, but it includes time-critical functions like showing a bus pass or paying for an item.
       L Home screen - this screen lets the user launch apps, and its appearance can be customised.
       L Notifications
       L Incoming call screen
       L App switcher - this lets the user switch between running apps, and it contains the running apps inside webview tags.
         L Running privileged system apps - these are special apps which do not run inside webviews and have full access to the system, including managing system settings and displaying child webpages with no restrictions.
           L (example) Settings
           L (example) Sphere browser
         L Running unprivileged apps - these are standard apps, running inside webview tags, and they use an API to request permissions from the user. Often, these are third-party apps.
           L (example) Calculator
           L (example) Notes

As you can see, the architecture of gShell is complex and uses multiple layers. If you have any questions, leave them in the comments. You could also check out our gShell repository on GitHub.

Project Prism: on the road to building an open smartphone

James Livesey — Wed, 06 Apr 2022 10:35:44 +0000

That's right ⁠— we're on an ambitious plan to build an open smartphone that puts Progressive Web Apps (PWAs) at the core of our ecosystem. Check out our video for an in-depth review of our project so far:

How are you making this?

Currently, the Prism is based on the PinePhone, with a few modifications to the hardware (the back shell is one of the main customisations to the phone, allowing you to see inside), in addition to the software (using our own Linux-based mobile operating system).

We 3D-printed the back case, which admittedly took quite a few attempts; but the end result is awesome!

// Detect dark theme var iframe = document.getElementById('tweet-1492914671569063949-597'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1492914671569063949&theme=dark" }

The main interface uses our own user environment, called gShell. It uses Adapt UI (web demo), which is the user interface design language and framework which we developed in-house over the course of a few months.

gShell itself is essentially just a really complex single-page website, all running locally inside an Electron process. This not only simplifies development and allows us to quickly prototype designs, but it also provides good support for animations and all of the polish that you'd expect on the modern smartphones of today.

I took a few photos and posted them on Twitter to show you what gShell looks like in real life:

// Detect dark theme var iframe = document.getElementById('tweet-1492916198442422276-474'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1492916198442422276&theme=dark" }

Of course, being Electron, it is possible to run gShell in its simulator mode on a desktop. This makes prototyping iterations of gShell and its associated apps much easier, and as a result, much faster; simply because it's more convenient to launch gShell on a development machine than it is to update the actual Prism itself to perform a very short test.

Accessibility

As with the physical world, accessibility is also extremely important in the digital world, too. Ensuring that both software and hardware is usable by everyone is a key aspect of developing successful products, and failing to do so can cause users to be excluded from being able to effectively operate your platform.

It's no wonder that we have baked accessibility support right into the Prism from the very start of our project: we've been ensuring that our product will be accessible for future assistive technologies that we will later build into gShell. However, it's not just ensuring compatibility that's important: we've also added some accessibility features into the phone from early on in order to ensure that the whole user interface is usable in its current state.

We've built in an often-overlooked assistive technology that often gets neglected in upcoming operating systems: Switch Navigation. It essentially allows the user to control their whole device using just at least one button, known as a switch. A demonstration of it is available at 15:09 in our video.

Here's a photo of what one of the features of Switch Navigation looks like:

The implementation of Switch Navigation in gShell has been inspired by quadriplegic YouTuber Christopher Hills, who makes extensive use of iOS's Switch Control feature daily. Switch Control in iOS provides very similar functionality to our Switch Navigation. Christopher's videos have been monumental at raising awareness of this versatile assistive technology, which has enabled him to pilot drones, edit and produce production-quality videos, and more. His videos have given us a great insight into the daily uses of Switch Control, which we hope to integrate into Switch Navigation.

Localisation

Localisation is also an important part of platform development, since it allows users who speak languages other than English to use our products, and truly make our products globally usable. Our main methods of localisation are through the Adapt UI framework, which provides the localisation infrastructure needed to translate our apps and make them available in different locales.

Adapt UI also ensures that apps and systems are laid out according to the rules of selected languages — in Arabic, for example, text is written from right to left, and so we need to factor this into our layout when Arabic is selected:

Feel free to play around with our localisation demo and see how the layout changes depending on the language chosen!

Conclusion

This is a brief overview of Project Prism so far. I go much more in-depth in the video at the start of this post, so be sure to check it out!

If you'd like, come and visit our GitHub organisation to see our various ongoing projects with regards to the Prism. Why not star a few of our repos you find interesting — or, if you're keen — contribute to our projects? Your contributions are welcome; even if they are simple bug reports or documentation enhancements!

That's about it — thanks for reading about LiveG Project Prism!