Mark II Update - March 2020

Hardware Mark II
1

Originally published at: http://mycroft.ai/blog/mark-ii-update-march-2020/

As a small startup focused on getting a product into people’s hands as soon as possible, we have generally focused on pushing features. You write a few tests, everything seems to work, so you ship it and move on. At the time everything works well enough, and you have enormous goals, so you let a few things slide and jump into adding the next feature.

However every time you let something small slide, you leave behind a small bug. None of these are big issues so you fix some, brush others aside, and soldier on. Over time bugs start to get harder to diagnose. A bug report comes in, you investigate, think you’ve spotted it, but actually it was caused by another bug elsewhere in the software stack.

At this point it’s tempting to throw a patch onto it and get back to the “real work” shipping features. But the longer you leave it the harder it gets to maintain, and you actually spend more time chasing more complex bugs than if you addressed the underlying issues.

We have started to travel down this path. When writing complex software It’s almost impossible not to. However, the Mark II hardware delay has given us a fresh perspective. We need to solidify our existing stack by doing the boring hard work that will make it more robust, be more adaptable to new hardware platforms, and provide a reliable and seamless experience for the Mark II.

March Focus

The key focus for March has been improving our test frameworks. Our overarching goal for these tests is to build an automated way to ensure a user’s interactions with the voice assistant software are always meeting expectations.

Mycroft-core has always utilized unit tests to ensure specific functions operate as expected. Skills have also had integration tests to verify that for a given utterance the right Skill is invoked and that it responds appropriately. These tests have generally been written to check on the primary functions and “happy paths” for success. They test known and correct input returns the correct output. They do not always test what happens when something unexpected happens.

To this end we’ve been expanding our use of Behave. This is a Behavior Driven Development (BDD) framework that we have been using in our Selene Backend. For those interested, we’ll be posting a full introduction to our implementation of this framework, which we’ve labeled “Voight-Kampff”, on our blog shortly.

The better we can test the software, the quicker we can move in development, and the more reliable the Mark II will be for you.

April Focus

The next milestone the dev team will focus on is improving the reliability and consistency of packaging and deployment through the use of container technologies.

Currently to install Mycroft you must clone a Github repository and run an installation script. After answering some questions our scripts will setup your system, install dependencies from your operating system, the Python Packaging Index, and some directly from Github. This all works most of the time. The challenge being that differences in the system underneath can cause unexpected issues during installation or use.

Some of these mechanisms are also less robust than others. Whilst it is rare, if an error occurs during some git processes, it can cause corruptions in the git tree that require manual interventions to fix. Asking a Mark II customer who purchased a consumer ready device to “prune their orphaned git objects” is just not going to cut it.

Enter Snapcraft by Canonical. Snaps are containerized applications for Linux. Packaging up all of the dependencies for your application within the Snap itself makes it self-contained. This removes the possibility of dependency conflicts, ensures consistent and repeatable builds, and makes the application platform agnostic. Using Snaps means we are also able to harness Snapcraft’s release processes for updating devices and verifying the installs.

As the Snapcraft ecosystem is new to us, we’ve started by Snapping some component technologies first. This will allow us to properly understand the technology and package up useful Mycroft components that can be used in the final Mycroft-core Snap. Mimic1, our on-device text-to-speech engine, has been Snapped and is currently in testing. Precise, our wake word spotter, is up next. Then both of these will be published in the Snapcraft Store for use in the official Mycroft AI Snap.

If you are interested in the Snap packaging system and want to help us out, please join us in the Linux Packaging channel on Mycroft Chat.

4 Likes
2

I really like what I read here. I posted it to my Mastodon feed, and of course since all my friends are nerds the first thing they asked was, “Why Snap over Flatpak or AppImages?” I’m assuming this is going to be pretty much transparent for Mark I owners. Will we have to change installations that have been manually installed on PCs?

3

Comparison there and do devlopers still have to pay Canonical?

4

Yeah it’s a great question @linuxrants I think we’ll do a dedicated blog post because I’m sure others will be wondering the same thing. Thanks for the extra material too @StuartIanNaylor .

Personally I think Snap, Flatpak and AppImage all have their slight technical pro’s and con’s but none that I’ve seen are enough to say “no, definitely can’t use that”, or conversely “yes, it has to be this one”.

Currently I use PureOS that is squarely in the Flatpak camp and I recently backed the Elementary led “AppCenter for Everyone” campaign which is also Flatpak only. But we’re looking at the broader adoption and reach of these technologies so it has to go beyond distro preferences. Probably the thing that pushed Snaps over the line is that it can reach more people both on desktop installs and embedded hardware via Ubuntu Core.

Snaps have also been easier for us to get started with as we’ve been partnering with Canonical for a few years and are able to tap into their expertise. We also had an existing Snap to work from as a community member made one a few years ago, it just didn’t get maintained and our platform has evolved a lot in those few short years. The Snapcraft community has been helpful, though I’m sure if we reached out to the Flatpak or AppImage communities that they would be equally welcoming.

There does seem to be a lot of accusations flying around that Canonical are trying to do something nefarious and control everything. My understanding is that there is no payment required by developers or users and anyone can run their own Snap Store if they want to.

I can also see a future where we release a Flatpak and/or AppImage too but it wouldn’t be in the next six months, and would only happen if there was enough interest in the community. If anyone has experience in those platforms and is keen to push things quicker then please get in touch.

Also interested in other peoples opinions on the packaging platform debate. What is your preference? Do you currently use them, tried one and hated it? Have you packaged something yourself?

5

I really don’t have a preference and its my usual bloat comment as its in essence just another type of installer that docker and various other methods already do if not as simple.
It seems with ubuntu and -bians type distro’s to add boot time but seems popular for snap on those, so snap, but mweh, not bothered really.

6

I do prefer dockerize everything, yet I run mycroft on its own environment, as it’s quite easy to install, but I understand is necessary a user-friendly installer, so this is a good news.

I always thought AppImage is far more “portable” and easy to run than any other method (like the old and good .run files) is perhaps the more “windows” approach, so linux newbies will feel at home running one of that.

Flatpak is also great, and is the de facto system on Plasma’s Discover. So users of any distro (using KDE) would expect to find Mycroft there. Just Neon or Kubuntu users will find Mycroft in Discover as I guess Kubuntu’s discover has snap support.

But I tend to flee from snaps as they are high tiered to Ubuntu and it creates a filesystem per application messing a lot your df -h output!! (another fact I recommend avoid using ubuntu), yet they work pretty well on arch now, I wonder if it works well in other distributions, but knowing Canonical’s efforts to be non-LSB compliant (hello netplan!), I would bet is tricky to install at best on other debian-based distros and redhad-based distros would refuse to work with snaps.

Resuming, that’s a very good idea to create an easy to install Mycroft experience, but I would have chosen another system above snaps. Definetively.

1 Like
7

Right! Please don’t get me wrong, but I am actually a little disappointed with this blog post as being “They Mark-II” update post.

I really consider this a “Mycroft software” update post. The disappointment comes because I do not see any update on where we are currently at at the Mark-II timeline. Adding to that, the April focus again does not tie into that timeline as well. (Left alone, we skipped the February update all together)

1920×1080

Let me start by apologizing for this post as I haven’t even backed the Mark-II campaign so don’t really have a saying in this. I just really, REALLY want one. :smiley:

However I can imaging that if you have backed the campaign back in the days, you would like to read about where we are at, at the earlier released timeline of the Mark-II rather than the tasks being performed behind closed door, software wise. (I also don’t see how the packaging of the software would delay the decision being made about the hardware partner, of which we are still patiently awaiting the big pres release to be announced)

Again, don’t get me wrong, I am not trying to bash here as I understand the difficulties involved. Just want to speak out loud, that the blog post is not really a Mark-II update in my humble opinion.

Anyhow, keep up the good work!

3 Likes
8

I think the docker ommision actually hinders adoption as likely Mycroft would get more presence as many ‘popular’ opensource projects heavily utilise docker because it is extremely easy to administer. Hass.io to OMV (Open media vault) there is a plethora of docker based homeserver opensource that utilise docker.

I am a little confused as snaps, flatpack and the likes seem to generally be for desktop applications and docker rules the roost on background services and servers which I am more akin to see Mycroft as.

I really do think it would be advantageous to provide an official docker image whilst snaps I really don’t have much interest in.

Make a snap of the Mycroft KDE desktop but an official Mycroft docker image would be sweet.

All it would need is the a base of the official Arm debian docker image and mycroft-core install on top that can be pushed to docker-hub. I was surprised that an official raspbian docker image doesn’t exist but it is of little difference for Mycroft.
Then just a simple

docker run -d -p 8181:8181 \
      --restart unless-stopped \
      -v "$HOME/.config/mycroft/profiles:/profiles" \
      --device /dev/snd:/dev/snd \
      mycroft/mycroft-core:latest \
      --user-profiles /profiles \
      --profile en

Also an X86 image but its so easy to pull the debian base and install mycroft-core but prob should have a Mycroft tag and ownership.

You can even specify on the card --device /dev/dri/card0 if you wished and haven’t used docker for a while and in my old addled brain its all gone, but could do an example.
It is so very simple that it would be great just to have a official Mycroft one.

9

Well, if the idea is to reach the maximum users out there, I think the package should be as agnostic and independent of other packages or systems. That’s why I upvoted for AppImage.

Docker, while is supercool and I have all my services running on top of it, well, is not designed for the average Joe. Not to say that rpi can be used by everyone, but again, most of the average Joe wouldn’t know what to do with a SoC.

Is true that there is a huge community of docker out there, as there is also a huge community of ansible, and Mycroft could post an official ansible playbook. But again, those communities are for tech people, and many linux tech people are aware nowadays of Mycroft. As I don’t know to whom is target the package, I’m assuming is with the idea to present as a desktop consume product for the newbie-to-average user.

From the 4 systems, just AppImage can execute the package alone without the need to install third-party applications like docker, snapd, or flatpak. Doesn’t need to rummage with network and publish ports like docker, nor have a specific distro like snap. Just make the package executable and double click, and that’s all. Then Mycroft can update itself without the need to rummage with another installer or stopping containers and so.

On the other hand, Flatpak is a mix between docker|snap and AppImage: you need to have flatpak installed, but is available in every distro (not like snap) and don’t need to set up ports, networks, NATs, volumes, environment variables or other stuff like in docker. And can be upgraded via a simple flatpak update command or through the GUI. Can be very useful if you use Plasma Desktop, where Discover has flatpak as package manager by default (and main Mycroft GUI integration is done with the folks at KDE).

Just my two cents.

10

My point is many common homeservers have dockerservices that you click and go for average Joes.
But to be honest when it comes to linux and opensource its not really the domain of average joes but many are already catered for.

Not having a docker image means other opensource offerings haven’t included mycroft in their addon repos for point & click gui average joes.
From HASS, OMV to Kodi it seems to be docker is predominant not any other and with the current market a desktop emphasis is a bemusing choice, but hey.

The desktop itself in comparison to mobiles and devices isn’t even a landing zone for average joes.
Its either heavily windows/gamer based or a techbased linux niche.
A quick google of 2020 usage, device, mobile and desktop sales will settle that one and it paints a picture that seems very different to any rationale for a desktop emphasis especially if you are going to mention terms such as average Joe.

PS there is a docker image anyway https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/get-mycroft/docker#installing-via-building-the-docker-image

11

Well, you and me have in mind two different concepts of what an “average Joe” is.

For me, one of these user wouldn’t have a home server, and when you them what a “docker” is, most probably they answer is something carried on a ship to transport goods.
They don’t either know what to do with home automation servers like HASS or setup files servers, media servers or whatsoever.

Many of the average Joe, but, know what Linux is, at least en Europe. At least that word sound to them as “like Windows but with a black screen”, referring is an Operative System. They know how to install software in their Windows systems and have been slowly introduced into open source thanks to VLC, Firefox, P2P tools, etc.

Some of them, the most curious, can even have tried a LiveUSB distro like Ubuntu to try out Linux. That was specially true when Microsoft released Windows 8 and Windows 10. And probably will be another wave when Windows 10 will force to install every piece of software through their shop, making steam and other third-party installation services unavailable. Or when privacy violations will be carried systematically on Windows. That last is just a guess, of course.

For that kind of user, a newly come user to the vast Linux ecosystem of software. They probably will start with the software preinstalled on its chosen distro. So as mycroft isn’t pre-installed on any distro, they can eventually search something like “Cortana in Linux”, and they eventually will find Mycroft, and if I were a newbie, and only installed software through my Linux store, I would do the same, search on the store. If that didn’t work, I would search on the web for the official Mycrfot web page and see in the downloads sections, like I was used to doing in Windows. I would expect to download an “installer”, and with just “two clicks” that installer should do the work.

I wouldn’t want to deep into docker, and if I had chosen Manjaro (a very good distro for newcomers nowadays, considered even better than Mint or Ubuntu lately), wouldn’t have snapd installed.

That’s why I say about AppImage. Because is an all-in-one package, with all the dependencies bundled in it, without the need of install anything else. A la Windows.

On the other hand, if you know what means all those words: HASS, Jellyfin, Synology, DNS, DHPC, Z-Wave, BTsync, Apache, python, etc… for me, that is not an average Joe, but a common Linux user. And yes, for the common linux user, it could be convenient has a docker image, but as I said, it can be also convenient an Ansible playbook, because a common linux user won’t be afraid of compile its own mycroft instance from sources as explained on documentation.

The point is, and may I be wrong, make a ‘product’ viable for as more type of users as possible, including complete noobs, and that will be a good test for some day create a Mycroft windows executable to reach the infamous Windows user base.

And again, I’m not against docker. I love docker and use docker for all my services on my Proliant G8. I have a Mark I and mycroft installed on every desktop (work and home) through git cloning the repo. But I admit that both docker and source code, are not the most friendly ways to newbies, and an “installer” is the most adequate way to get everyone, both experienced and inexperienced linux users can have it installed easily.

1 Like
12

The average joe does not use Linux you have a focus for something that is a figment of your imagination.

That is not me but but actual usage quotas from a plathora of market reasearch and overall that small niche of linux desktop is also reducing as mobiles & ‘Devices’ become predominant.
You are saying average joe and the basic truth is that is a complete missrepresentation as there very little ‘average joe’ about the demographics of the userbase here.

The docker image is not for them but in order of precedence that a working docker image is viable so that it can spread the usage of Mycroft by becoming a default container for the many non-average joe user applications out there, would be beneficial for the project.

It got nothing to do with knowing what it is its purely using and adopting and that is extremely unlikely with the future of the linux desktop as AI, devices and displays become a home mesh of technology where the new king is the supply of now cheap and easily available smartphones.

Have a snap for Mycroft but with all honesty its actual useage is likely to be small and not at all by standard joes as they have a mobile and likely a amazon or google AI already, as average Joes tend to be that other term of consumer.

13

I was speaking about the average user of a computer, neither smartphones nor smartwatches, smarttvs, consoles, fridges, or whatever piece of hardware capable to connect to the Internet: just computers. You also were speaking about those kind of users, because as far as I know, docker isn’t released for android yet.

And as this starts to sound to me as a flame war and I didn’t intend to start one, I’m going to end my comments here.

2 Likes
14

I don’t know why some of the earlier comments by @StuartIanNaylor have been flagged, but I agree that docker seems like an obvious choice that is being omitted from the decision process.

There needs to be clarification about the use case. There’s debate going on here about average Joe’s vs average Linux users. My view: Average Joe’s are the people who will buy the Mark II device off the shelf. A packaged, working solution that you buy, plug in, and use. And in that case the (perceived) difficulty of using docker is irrelevant, because the device will be configured to auto-magically boot, pull the latest image from the registry and launch the MyCroft container. With device and volume paths properly specified, all on it’s own with no intervention. If a user has to ssh into the Mark II to relaunch a container to get the service working, then the product has failed.

Then there’s the Linux users and hobbyists, who will install Mycroft on a variety of hardware (RPi’s, NUCs, Respeaker, [insert SBC of choice here] etc etc). In this case, is the Mycroft device more like a desktop PC or a server? While it doesn’t totally fit the description of either, I would argue it’s closer to a server. You don’t use a keyboard and mouse, it’s always on, it provides a service. Doesn’t that make docker the clear choice? Because as previously stated in the comments, appimage/flatpak/snap seems more a desktop solution.

Head over to somewhere like /r/selfhosted on Reddit, the kind of place you’ll find a hive of the type of people who would perform their own custom install of MyCroft. Sort the threads by top, all time, and you’ll see some pretty common trends in the stacks being used. HomeAssistant, Plex/Jellyfin, Sonarr/Radarr/Lidarr, SABnzbd+Deluge/QBit/Transmission. And the other common trend you’ll see, is that docker is a common method of choice for installing and hosting those components. There may be mix of docker vs conventional install (Win32 or Repos) but is there a mix of docker vs appimage/flatpak? No.

If (hobbyist) users are going to expect to install and host this as a service, then use the method that the IT community are already used to for containerising services: Docker.

For the “average Joe”, ie Mark II purchasers, the choice of Docker over Snap is irrelevant, they’ll never see, know, or care about the choice of packaging.

1 Like
15

That is very much it anyway without the need for the average joe in the deal.
My point for docker isn’t the need it should be available for average linux users or joe that its needed so that mycroft becomes like any container and transportable so that any Linux user with an element of administration and technical skill can make services and offerings available.

There is huge interest in private opensource home software be it Voice AI or Home Assistant.
To be private and cloud free of big data is hugely important to many and why its really important to have ready docker containers to be easily included in other projects and get Mycroft known by this new herd and available to be implementated in all leading product.

We live in an era of devices where the desktop has steadily declined and totally agree with @Fellhahn that desktop top usage is likely to be small but usage of docker unknown to them could be by very many.

Docker is really important to me as I quite like Mycroft and would like to see the project do well.
Not because as a user I want to use it.

I am trying to provide a docker image that is self contained as the current version that expects an outside pulseaudio server sort of breaks much of the rationale for a self contained container.

16

Hi all,

Stuart’s posts got flagged by community members as off-topic and the system automatically hid them. I’ve restored these as it does seem that it’s been raised as an alternative to Snaps.

To be clear, there is an existing docker image, you can find this on our Github or on DockerHub. There is no intention that a Snap package would replace this. It’s just another way that people can use Mycroft. If there are ways to improve the Docker image, that is great, we’re always happy to get suggestions or pull requests.

Snaps are predominantly associated with the desktop and if desktop users find it helpful that’s excellent. But they are really just a packaging system and can be used as a general distribution mechanism. So as Fellhahn pointed out the vast majority of people that will make use of our Snaps probably won’t know (or care) that it’s a Snap package. They will have a device that updates reliably and in the unlikely event something goes wrong it automatically reverts to the last working configuration. Having a device that “just works” is what I think they really care about.

1 Like
17

Yeah I forgot about that docker image but the one we have doesn’t seem to work and it seems to be flawed as a container as it expects an external pulseaudio server and sort of breaks the expectations of self contained containers.
It doesn’t seem easy or robust but having a think how to have persistant audio config easily.

But it was opinion sharing of much what @Fellhahn said that I am not expecting it to be a choice beween the 2 but as feedback is a mycroft snap going to be a thing.
For me no as generally don’t have much interest in desktop or snaps.

But I have been doing some reading of late about ubuntu core and maybe snaps might be a thing but it was the desktop and average joe emphasis that sidetracked me.

https://docs.ubuntu.com/core/en/stacks/audio/pulseaudio/docs/install-pulseaudio

I dunno guess will have to read up more about whats new in ubuntu core and snaps as prob bit out of the loop as didn’t see them much more than canonical app-images.

18

I’m going to do a blog post about the decision too. There’s been quite a bit of interest as to the why and some good questions raised which we want to explore further. So any other specific questions about Snaps are very helpful as I’ll cover it all in the post.

19

Agree with that. That was always my starting point.

And you made a good point for the headless SoC, where a flatpak/snap/appimage installer has a very little use, yet as far as I know all of them has command line versions and you could use them as well on a headless machine. And once installed, mycroft doesn’t care if you HASS/Plex/etc are dockerized, it only needs to reach the services.

I agree also a huge part of the Rpi community uses the SoC as a headless machine, and they are used to docker. But as you say, they are hobbist and many of them, linux users themselves, so I don’t see the point to speak about a docker image when a) there is one already, 2) there is a picroft image and c) as they are linux hobbist, there is the official method based on source clone.

Agree again with you Mycroft doesn’t fit as a server nor a desktop, because it’s a smart speaker, a smart assistant. But I disagree is closer to a server.
You argue that because don’t need a keyboard or mouse to interact. But a microphone or speakers on a server has no use at all, so…
I would rather prefer to think what uses offers Mycroft. Mycroft can interact with your HA/tell you the weather forecasts, play some music, etc and other stuff which would act as a “service” but on the desktop, it can start programs, search the web, dictate emails for you to review, and other and future uses which will improve the desktop experience. So I wouldn’t tie mycroft as a server service, but rather as an assistant, for both servers and desktops. That’s why I think a Desktop installer is a good idea.
As Mark II has a screen, I would like to think the installer would include a GUI as well to include all the MarK II features (and even more) for all the users who don’t use Plasma.
Besides, Linux desktop users will improve the desktop experience acting as ‘guinea pigs’ for in a future open this to Windows desktop users.

20

Its a headless OS but generally its almost been termed if its not a desktop its a server.
Magicmirror is termed as a server app but actually its client based in working mode is single threaded.
You can connect multiple times but you will just get the same.

Mycroft is a headless application or AI framework or service, but it doesn’t really matter.

Its a bad idea to envisage a framework to a particular product as the Mark II is just a product with a GUI that utilises a deployment of Mycroft and that still doesn’t mean its a desktop.

The mobile market started the slow death of the desktop and we are in a new era of AI and ML devices of new forms of input.
Displays are now mobile and can be cast to like magic from products as simple as a watch or whatever the next new device is going to show a fancy new vajazzle.

Voice and augmented reality interfaces are now and the desktop started dying quite a while ago.

Mycroft seems to have a heavy Pi base and that generally means Raspbian.
Snaps seems very ubuntu core orientated which will have a whole range of GUI’s that represent some of the new devices that will be for many the final nails for common desktop use.

The desktop is a retro argument in regards to snaps which they are pushing heavily for ubuntu core so guess for devices snaps is a good thing.
Hopefully this isn’t another Ubuntu phone but from wpe-webkit to QT the desktop as we know it isn’t a direction many are looking.

Dunno as at first in terms of snaps I was just like why? But with the topic brought to light and some googles ubuntu is pushing this for ubuntu-core.
Which leaves me in my usual state of bemused and confused, so don’t know.