Hi my name is fuseteam but some of you may know from telegram as Tobiyo Kuujikai. this will be my first topic, i've been thinking how to write this up for a while. no, i'm not japanese i suppose i should start at the beginning.

When i first heard of ubuntu touch i was pretty excited to see a OS i could be in control of, as i never like how android worked and such. heh i only switched to android from symbian when my trusty old nokia 5800 just didn't hold enough battery anymore. like many the idea of using my phone as a "PC" really fascinated me, especially since at the time i had a laptop with 3GB of RAM and smartphone were beginning to get just as much RAM. you can imagine my disappointment when canonical announced the drop..... as i was a information technology and having a (fairly amateurish) understanding of programming i grew desperate and began searching for how to get in contact and do something. i eventually stumbled upon the unity8 telegram group and from there i found the other ubports groups. after some activity and getting to know the community i was eventually offered a device to get to know the os and the rest is (telegram) history.

now why am I talking about all this? what up with the title?
my expectation was that this will enable a "PC in my pocket" a "palmtop" at this point i had some experience with ubuntu on the desktop, i attempted to apply my meager experience to ubuntu touch and see what i can do. you can imagine my surprise when things didn't work as i had come to know it. as i got to know more of the community i found way to do what i wanted to do and have had a lot of fun with it. i even ended up editing the keyboard on the device with vim, breaking and fixing things. one of my goto method to restore things when things go "really bad" has become ssh in and run sudo system-image-cli -b 0 --progress=dots. i have used this more times then i can count. and that on its allowed the readonly rootfs to grow on me, even to such a degree i somewhat want it on desktop xD

but as i was doing some things in a unsupported way there were some caveats, every time i refreshed my rootfs i lost all my favorite commandline utilities! but i can't complain right? apt is not supported, i get to keep the pieces..... as time went on however it does start to become tedious to reinstall things but hey i can't complain i am doing unsupported things, enter nix. someway somehow i stumbled on nix and from there i talked with quite a few regular contributors such as NotKit, Jonatan, Myii, Kugi, Dalton, Kugi and probably many more and learn quite a lot
did you know that while the rootfs is readonly, some paths are actually writable: for example /home is completely writable. in hindsight it has to be, how else would our userdata survive refreshes and ota updates! it turns out there is a file (that isn't writable) that mounts basically keeps track of all those paths in /etc/system-image/writable_paths this file is processed in dash mounting the folders and thus preserving /userdata! from there i discovered nix is actually pretty easy to set up!

• remount readwrite
• create the directories /nix and /etc/nix
• add the paths to /etc/system-image/writable
• remount readonly
• reboot
  everytime it disappears just readd the paths, recreate the directories and reboot, easy yes? wait nix is missing title, this post isn't about nix........is there caveat? yes zero packages for armhf! nix would compile the packages which could take hours, and lots of space. heck i have this sneaking suspicion it even trying to compile a new kernel! surely there must a different way! and there is, from there there's the possibilities to package the apps in a click and ship everything it needs, but that that worked! but it still felt messy, it would create a bunch of stub apps which literally just tells the user to add a certain path to PATH to be able to run the application........ it works! but we can do better! at that point i began toying with the idea to build an app but then it hit me. i learn deb packages are archives, that apt has a download-only option that apt can be configured to work independent from the rootfs and that dpkg can extract debs to any arbitrary directory, crackle was born.

orginally i intended to propose a path like /home/pkgs to be a standard PATH as to have some sort of eventual multi user config, but with growing security concerns and little push from some in the community it now installs in the xdg home directories: ~/.cache, ~/.config and ~/.local/share

so will this be a replacement for libertine? no. a lot of work has been put into libertine, years of work. a little bash script surely can't replace that! so what is my goal? in my experience and understanding libertine doesn't cut it..... why not? libertine is a whole desktop ubuntu container 1.5 GB just to run little old vim and given i use vim to experiment on device, the isolation from rootfs is little much. so my initial goal was to be able to install the utilities i use to hack on the phone and preserve them all on a readonly rootfs. But given how similar many utitliies function this extends beyond vim but probably not all the way to gui applications, those are really complicated. it is however possible to fetch a package and all its dependencies with this tool however to make it "self-contained" possibly make a crude click of out of it but that a whole other beast. well that was a mouth full lemme try to keep the rest short with the question i can already hear:

sooo what packages already work?

according reports and my own (crude) tests the following packages appear to work:

• vim
• git
• nmap
• htop
• mc
• transmission-cli
• shellcheck
• xz-utils
• curl
• tmux
• byobu
• patchelf
• tree
• sshfs

packages that don't work

• man
• locate
• many others i have yet to test

does it really not work with gui applications?

well it can work but it very fiddly and mostly unusable
it would be better to try those in libertine or at least bundled in click and access properly through xmir (xwayland one day)

wait slow down why is it called crackle?

the name is play on physics which itself is reference to a very old commercial
in physics snap is a derivative of jerk which is a derivative of acceleration, i guess the "acceleration" of acceleration
pop is the "acceleration" of snap
but wait about the "speed" of snap? well that's crackle!
what? is all greek? no worries have this nice video instead: https://www.youtube.com/watch?v=q6TIsxTdrCU

will this work for all commandline utitlities?

no idea, probably not. it comes down to what the utitlity needs, sshfs for example fails because of "operation not permitted" (likely related to the way fuse should be setup) while man fails because it just has to have its config file in /etc it just refuses otherwise and probably the way it wants to be setup, locate also has a similar issue with it just wanting the certain files in certain locations. i'm only one little guy i can only test and use so many applications

where is the sauce?

the source is at https://github.com/tuxecure/crackle, its also on gitlab at https://gitlab.com/tuxecure/crackle-apt/crackle. the github is a mirror of gitlab. the scripts used to setup the environment and such is at https://gitlab.com/tuxecure/crackle-apt/cracklebin

so can i do anything i can do with apt with it?

uhhhhhhhh no at this stage the following commands are available

• crackle install <package>
• crackle download <package>
• crackle clean
• crackle show <package>
• crackle search <package>
• crackle update
  yes that complete when it comes to apt like commands, there is no way to upgrade or remove packages at this stage, tho i suppose you could use crackle install to upgrade single packages it also has a couple of unique commands
• crackle setup this is used to "install" crackle and setup up its initial environment more details in the next section
• crackle crack <package> this can be used to extract a package and its dependencies in /home/phablet/packages/<package>

How do i get crackle?

currently you can get a hold of it by downloading the literally downloading the code (as a zip) from github or gitlab and extract it. then you cd into the folder and run ./crackle setup note this will use crackle (recursive!) to install both git and patchelf
git to download the scripts from cracklebin and patchelf so those scripts can patch binaries where needed. git can also be used to fetch newer version with git pull later

much bugs, where report?

for now bugs can be reported on gitlab
or you can contact me on telegram @fuseteam

so wait why is readwrite rootfs overrated?

for me i made it unnecessary to remount the rootfs. As crackle made it possible to "install" 90% of the utilities i tend to use in the terminal without remounting the rootfs, so for me a readwrite rootfs is overrated granted i do still remount to readwrite to hack on the os crackle might not be suited for your use, but it doesn't mean there is not way, there is always libertine and if that doesn't suit your fancy i would like to encourage you to either help improve libertine, or to explore what options are out there and how to get it working on Ubuntu Touch I believe there are a lot of possibilties and with that this post is way too long, so i'll sign off here

honestly i don't think we should only focus on what users can donate. there are more ways to contribute, as already mentioned, including volunteering to lessen the load on "the core team".

As Dalton mentioned in the last Q & A "i've seen the mentality change from 'what can we do together?' to 'what can the foundation do for me?'" "foundation" can also be replaced with "the core team" the meaning is the same. If we want to grow we need to adopt the mentality that brought us this far which is "What can we do together?" and there's more we can do that just technical things like contributing code or donating money, we can also promote the project and perhaps interest companies with the same value to become sponsors, like volla, smoose and pine64, or ways to collaborate on the system. The field of ways we can help is huge, let's utilize it!

ok i think i generalized the firefox repo to the limit;

• the meat of the builder is in builder.sh.
• the template files are placed in the correct location with the specific name while the environment for building is setup with prebuild.sh (hmmm maybe i can move that to build.sh)

• the package specific stuff are saved in pkg.d

• the actual package to build is specificied in clickable.json any package in the ubuntu repos can be specified, no command line apps tho those won't magically launch in the terminal (i ain't a magician sorry :P)
• package maintainer info can be set in manifest.json, the package name will be set with prebuild.sh
• apparmore permissions can be set in apparmor.json

Limitations:

• as mentioned earlier it needs to be unconfined due to needing xmir, as such only the xmir branch has an actual working click, the master branch would launch on wayland but this particular version has broken wayland support, if the package has wayland support confined may be possible
• any package which has an all package as a dependency will fail to build, cause i'm a noob
• no command line apps! we have crackle for that nudge nudge
• no touch (so far), no OSK (so far), no content hub, no media hub
• no per device scaling, currently scaling is set with the environment variable GDK_DPI_SCALE=2
• i have no idea how to handle the above 2
• i also have no idea how to handle settings schema's at all

ah the cat's out of the bag; i wouldn't even call what i have a beta at this point, it is an pre-alpha click package.
basically i'm downloading the firefox deb package with apt, extracting it and packaging that result as a click.

It does not pop up the keyboard, it has no touch support out of the box and it does not integrate at all with the os. it just launches and the interface is somewhat scaled.
It is also unconfined due to needing xmir atm, which not available to confined apps.

to get the keyboard to pop up we need to either get maliit-inputcontext-gtk3 working in the click or ship it with the rootfs.

i'm currently more focused on generalizing my work so others can benefit of it. the build script is based off work by mateo salta, maciek sopyło and my crackle script altered to fit the needs of a custom clickable builder

the firefox click can be found at gitlab.com/debclick/ufirefox.
i created the debclick group to organize all similar experiments under one umbrella, if anyone wants access hit me up

the clicks build from the master branch do not launch as they lack proper wayland support.
the clicks from the xmir branch do launch and are unconfined, and suffers from all the issues associated with xmir

always based on the latest LTS

if it's any help, the work on rebasing on 20.04 is underway was we speak

Documentaion is everywhere, not centralized, I think we should have a place where you can get all the documentation, including known working APN settings

the centralized documentation is at docs.ubports.com if something is missing there it can be added by submitting a merge request at https://github.com/ubports/docs.ubports.com
granted APN settings are very carrier-specific not sure how to organize such a documentation

@flohack who what where how when?

@mardy niiice, thanks for your work i'll test it out too~ sadly my battery is rather old to be a reliable battery test and my touch screen isn't in the best state either but i'll be sure to report any other issues!

@josele13

What kind of companies would be interested in an OS that doesn't have a locked bootloader or unencrypted phone rom?
In those companies will they see that UT is easier to use than android?
Do we have all the android options to be attractive?
Will these companies be able to use our country's banks or government apps?
Will the employees of these companies be able to make video calls?
Will they be able to talk from the car to another employee via bluetooth?
Will they be able to pay for food at the bar from their mobile phones?

yes these are important questions, but we must've forgo what we can do to make it more attractive
for example if there's a missing app, what can we do to convince the app developer or the company behind it to support Ubuntu Touch. if there's a missing functionality what can we do to fix it whether that's ourselves if we can program or by attracting a developers with the skills.

so rather than "what makes it attractive to companies?" the question becomes "what can we do to make it attractive to companies?" and by extension "what can we do to move Ubuntu Touch forward?"

i have no publish a ready to use zip file in the release section of the github mirror along with some rudimentary usage instructions

@matteo haha glad to hear, tho install is a bit of a overstatement it's really just a script making use of what is available on UT out of the box

@fakeshell yeah no easy task, and we'll migrate to systemd anyway xd

@fakeshell snaps won't work, cause no systemd. Flatpak has no osk support atm, among other missing integrations including portal support

@applee the thing is some halium operating systems don't use ofono, they use modemmanager iirc xd

@applee ah i need to read more thanks. tho i still don't know if "aiming to standardize middleware to talk to android daemons" means it's a part of halium or not

@applee i'm fairly certain both the kernel and ofono are outside of halium, but i can't say that with absolute certainty. i agree the best way to understand it would be to try porting yes. i too wish i could make time for it

@applee thanks for the links, i've been following the groups as well, and now i found a short description on telegram that made it click for me:

Halium is basically custom version of Android build specifically to run services that speaks to Android hardware

edit: i just noticed i already posted that did that description not suffice?

edit2: ok so i found an (older) image of the diagram florian showed

my current understanding is that the bluebox is "halium" although in florian's diagram the bluebox is considerably larger hmm

@josele13

What kind of companies would be interested in an OS that doesn't have a locked bootloader or unencrypted phone rom?
In those companies will they see that UT is easier to use than android?
Do we have all the android options to be attractive?
Will these companies be able to use our country's banks or government apps?
Will the employees of these companies be able to make video calls?
Will they be able to talk from the car to another employee via bluetooth?
Will they be able to pay for food at the bar from their mobile phones?

yes these are important questions, but we must've forgo what we can do to make it more attractive
for example if there's a missing app, what can we do to convince the app developer or the company behind it to support Ubuntu Touch. if there's a missing functionality what can we do to fix it whether that's ourselves if we can program or by attracting a developers with the skills.

so rather than "what makes it attractive to companies?" the question becomes "what can we do to make it attractive to companies?" and by extension "what can we do to move Ubuntu Touch forward?"

@mardy niiice, thanks for your work i'll test it out too~ sadly my battery is rather old to be a reliable battery test and my touch screen isn't in the best state either but i'll be sure to report any other issues!

honestly i don't think we should only focus on what users can donate. there are more ways to contribute, as already mentioned, including volunteering to lessen the load on "the core team".

As Dalton mentioned in the last Q & A "i've seen the mentality change from 'what can we do together?' to 'what can the foundation do for me?'" "foundation" can also be replaced with "the core team" the meaning is the same. If we want to grow we need to adopt the mentality that brought us this far which is "What can we do together?" and there's more we can do that just technical things like contributing code or donating money, we can also promote the project and perhaps interest companies with the same value to become sponsors, like volla, smoose and pine64, or ways to collaborate on the system. The field of ways we can help is huge, let's utilize it!

@cliffcoggin hi, i'm way late but i found a nice short explaination of halium that finally made it click for me. i'm posting it here because perhaps @AppLee might find it usefull to add it to his short description:

"Halium is basically a custom version of Android build specifically to run services that speaks to Android hardware"

as these services make use of Android libraries halium also uses a wine-like "compatibility layer" to load those libraries in Linux called "libhybris"

as a closing note i would like to encourage you to not be discouraged when you feel like you don't understand much. i can tell you that few of the regular contributors understand the entire system completely. even the most knowlegable contributors started with zero understanding of the system, nay even the devs at canonical each "specialized" in specific parts of the os, while not knowing much about other part