Maru: a pocket desktop
Maru, in its current state, is clearly not for everybody; it is currently running in a "private beta" and only works on the Nexus 5 handset. As luck would have it, your editor is in possession of both the hardware and the patience to wait until his number came up for a beta invitation. Playing with this system shows that there are some issues to deal with yet, but the idea has a lot of potential.
Installing Maru will be a familiar process to anybody who has flashed an Android device. The bootloader must be unlocked, and the owner needs to be cognizant of the fact that all data on the device will be overwritten; then it is just a matter of a couple of fastboot flash commands. Or it should be: that resulted in a phone that got stuck looping through the interminable "optimizing apps" process — amusing at first, but even your editor, who is easily amused, found it tiresome by about the fourth time through. Explicitly wiping the data area (using the TWRP recovery image) and starting over got past that issue.
The installation results in a standard — if severely minimal — Android "Lollipop" system; Maru has not made the move to the Marshmallow release. As is always the case with a third-party build, the Google apps are not there; they can be added from the Open GApps repository if desired — though it is somewhat assumed that the user knows how to do this. There are reports that only the "pico" version of Open GApps will actually fit on the device after the Maru installation; the 32GB device used here still had 26GB of free space, though, and was not so constrained.
Experiencing Maru as anything but an Android device requires some additional hardware in the form of a Bluetooth keyboard, a Bluetooth mouse, and a USB-to-HDMI dongle. The latter device plugs into the phone's USB port and allows the handset to drive an ordinary monitor (or television); the documentation advises buying one that allows for a power connection, since running in the desktop mode can drain the battery quickly.
Once the Bluetooth devices have been paired and the monitor connected, the
user is presented with an attractive XFCE desktop (for those who,
inexplicably, think that translucent terminal emulators are attractive, anyway).
At least, that happens
briefly. One of the first discoveries is that the desktop is only active
when the handset screen is on, and desktop activity does not keep the
handset from timing out and shutting down. So working on the desktop
happens in 30-second bursts, separated by (hopefully shorter) bursts of
profanity. Making the system usable
requires setting the timeout value to a high number, which may not be what
one wants when the desktop is not in use. This, perhaps, is part of why
running the desktop tends to drain the battery quickly.
With the external keyboard and mouse, the desktop works as one would expect. A lot of the basic utilities are present, and some not-so-basic ones (e.g. LibreOffice) as well. Anything else can be had in the usual manner from the Debian repository. The desktop is surprisingly responsive; even LibreOffice is able to launch within a few seconds. Building kernels is probably a poor idea, but the device clearly has the power to handle most day-to-day tasks.
There is no access to Android apps in the Debian desktop, of course, and the desktop never appears on the handset screen. The two are separate worlds living on the same device. The one exception is that the Android data area has been mapped into the Debian world, so that, for example, photos taken with the camera can be accessed on the Debian side.
If one pokes around with a shell, what one finds is an apparently complete Debian distribution running; it even has systemd running the show. The system has been thoroughly isolated from the Android system (some reports on the net say that LXC containers are being used). Except for the access to Android's data area, the Android side of things might as well not be there from Debian's point of view. The Debian system does run on the Android kernel, though (it's not in a virtual machine), so an enterprising attacker could probably find a way to break through that barrier.
Some parts of the system are not entirely at ease with this setup. Systemd, for example, duly logs that the time has been changed — every second. But as a whole it seems to work well.
Anybody looking for the source to Maru will, for now, be disappointed; it does not appear to be available. That might strike some people as surprising, given that it is, in the end, a distribution of Debian, much of which is covered by copyleft licenses. Back in February, Maru creator Preetam D’Souza announced that the distribution would be open-sourced, almost as if it were a new idea. Since then, though, there has been no visible progress on that front. Maru is, thus, quite clearly violating the GPL at the moment. One gets the impression of a small (i.e. one-person) project struggling to cope with a larger-than-expected level of interest. One of the best ways to do that, though, would be to get the source out there and let the community help. Hopefully this issue will be straightened out in the near future.
One might be tempted to ask where a distribution like this might be useful. The advantage of a smartphone is its portability; lugging around a keyboard, mouse, HDMI adapter, and, possibly, monitor tends to detract a bit from that. It is probably easier to just pack a laptop and be done with it. But if the peripherals are available in multiple locations, and all that needs to be carried is the handset, the appeal becomes a bit more clear.
What would be nice, of course, would be a higher degree of integration
between Android and Debian, making the device a bit less schizophrenic than
it is now. It would be useful, for example, if applications from either
side could appear on either the device screen or the external desktop.
That is asking a lot, though, considering just how foreign much of the
Android system is relative to a typical Linux desktop distribution. But,
perhaps, if the two cohabitate for long enough, they will eventually learn
to trust each other a bit more. In the meantime, Maru is an interesting
experiment in running a Linux desktop in an Android setting.
Posted Apr 18, 2016 12:14 UTC (Mon)
by larma (guest, #106468)
[Link] (4 responses)
So to summarize: Maru is an Android system that runs a LXC container that has a directory mounted to the Android mass storage, a virtual screen that is directed to the Android secondary screen (maybe using VNC?) and is running some pre-configured Debian distribution.
And now the funny thing: all this is already possible since long time ago. People were experimenting with Xvnc servers running in a Debian or ArchLinuxARM chroot environment and are able to use this VNC from remote systems or, with a VNC viewer app, even on the device screen itself. I myself did this on a rooted Android 2.3 smartphone over 3 years ago.
Posted Apr 18, 2016 12:27 UTC (Mon)
by smcv (subscriber, #53363)
[Link] (3 responses)
It isn't, but distributing a disk image containing the binaries for that Debian container, without the corresponding source code, is.
For the packages that are unmodified, pointing to the corresponding source on a Debian mirror might be sufficient for non-commercial distribution to not violate the GPL, but I assume there are at least some modified GPL packages here - most notably the Linux kernel.
Reputable Debian derivatives like Ubuntu and SteamOS are rather careful to have corresponding source code for everything they distribute.
Posted Apr 18, 2016 12:43 UTC (Mon)
by corbet (editor, #1)
[Link]
In any case, I mentioned the GPL issues because they are there, but the stated intent is to open-source the entire project. So hopefully this isn't an area of serious, long-term concern.
Posted Apr 18, 2016 12:57 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (1 responses)
Posted Apr 18, 2016 22:27 UTC (Mon)
by drag (guest, #31333)
[Link]
I expect that if you go to something like Docker's official container registry you will find vast numbers of copyright violations of one form or another. Violations of GNU userland, kernels, apache licensing violations, etc?
If somebody pulls in a Ubuntu container their app is it Canonical's job to provide the source code or is the person redistributing the resulting software binaries?
If you have Joe Blow posting a container for his blogging software it is technically going to be a violation if he doesn't provide written notice and provide all the source code along with the container. Lots of the times the only reference a container has is some github page and even then a lot of those projects never last very long.
With the commodization of operating systems that things like containers represent you see the costs of copyright compliance for various FLOSS items soring in comparison to the costs of actually building and distributing the software. Luckily most people don't seem to care because access to every bit of source code is not really a high priority and if it was they know where to easily get it. However there could be some pretty serious problems down the road if some critical copyright holder decides to try to force everybody to take his copyright very seriously.
Posted Apr 18, 2016 15:00 UTC (Mon)
by djs_tx (guest, #29646)
[Link] (4 responses)
Posted Apr 18, 2016 16:58 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (2 responses)
Posted Apr 19, 2016 12:45 UTC (Tue)
by djs_tx (guest, #29646)
[Link] (1 responses)
May seem like a minor difference but it is huge in terms of power draw and processing load on the phone. Almost all phones support USB OTG these days but none that I know of support charging while in host mode (without custom ROM / Kernel). So if it depended on host mode, the battery draw would be totally impractical.
Posted Apr 19, 2016 22:05 UTC (Tue)
by rahvin (guest, #16953)
[Link]
MHL is an open format, Slimport is proprietary. See: https://en.wikipedia.org/wiki/Mobile_High-Definition_Link
Posted Apr 18, 2016 17:11 UTC (Mon)
by faramir (subscriber, #2327)
[Link]
Posted Apr 18, 2016 15:21 UTC (Mon)
by pj (subscriber, #4506)
[Link] (2 responses)
Posted Apr 18, 2016 15:28 UTC (Mon)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Apr 19, 2016 10:54 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Apr 18, 2016 23:11 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (2 responses)
schizophrenia != dissociative identity disorder
http://psychcentral.com/lib/the-differences-between-bipol...
Posted Apr 19, 2016 10:29 UTC (Tue)
by ballombe (subscriber, #9523)
[Link]
Posted Apr 27, 2016 11:06 UTC (Wed)
by robbe (guest, #16131)
[Link]
Posted Apr 19, 2016 11:31 UTC (Tue)
by rvfh (guest, #31018)
[Link]
Running Ubuntu along Android on a phone has already been done, and with the Android display appearing as a window on the Ubuntu desktop, so you could access contacts, message, placing calls, and so on...
Posted Apr 22, 2016 0:15 UTC (Fri)
by freemars (subscriber, #4235)
[Link]
Posted May 2, 2016 6:11 UTC (Mon)
by sandeep.r (guest, #108547)
[Link]
You can also write a simple app which can hold a wakelock to keep the screen on, and perhaps write a simple widget to turn on/turn off the wakelock.
Maru: a pocket desktop
Maru: a pocket desktop
Actually, since it's running in a container, there is no Debian kernel package at all.
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop (virtual screen casting?)
throw the video display onto a large screen wirelessly.
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
Maru: a pocket desktop
#MarriedToAPsychologist
Maru: a pocket desktop
Maru: a pocket desktop
hacker ≠ criminal
Maru: a pocket desktop
Linux Luddites interviewed the. Maru developer, Preetam D’Souza, in their episode #76.Maru: a pocket desktop
http://linuxluddites.com/shows/episode-76/
Maru: a pocket desktop