People sometimes ask - why the name “CUBE”, as our player hardware is not shaped like a cube?
Simply put: CUBE is inside. The player hardware is only one part of a much larger whole: the CUBE platform. The name CUBE highlights that there are three dimensions to the platform. The playback device is one of these dimensions. The other two are:
- CubeOS and Cube Apps that run on the playback hardware, allowing it to deliver all kinds of applications
- the CubeMC backend and its Apps, that manage the CubeOS and Apps installed on each playback unit.
CUBEOS, like the Android operating system, can be used on different hardware devices. In fact, since CUBEOS (like Android) is based on the linux kernel, CubeOS is inherently portable to many of the same kinds of hardware devices that support Android; and also to other kinds of devices like Raspberry PI. CubeOS, like Android, makes available an ecosystem of Apps, which in turn allows the hardware to perform all kinds of functions. There is of course a major difference between CubeOS and Android: Android is designed entirely for the consumer, while CubeOS is designed completely for the service provider – with consumer interaction options. For example, the consumers who have the Android devices in hand, are in control of those devices – they are the ones that must typically “push the button” to do App installs, or to trigger updates of Android itself.
By contrast, CubeOS is designed for the service provider, who might have thousands of units deployed in the field, so they can have complete control over those devices remotely. With CubeOS, service providers can push updates remotely to units without customer intervention: those can be content updates, app updates, or even updates to CubeOS itself. Because it is consumer centric, Android engineering is focused primarily on what is important to the consumer, on consumer devices like phones, tablets and watches. A key example is conserving battery life. Such concerns are often not only irrelevant in the service provider market, but create technical barriers to what is possible.
Because CubeOS is service-provider-centric, CubeOS engineering is focussed on what is important to service providers.
Examples include: sophisticated remote management and diagnostic tools, networking technologies that can self-diagnose and self-heal, the ability to monitor live playback remotely, and the ability to push real-time commands to units even when they are behind firewalls or proxy servers.
CUBEOS (like the other elements of the CUBE platform) has been in development for several years. New versions of CUBEOS are constantly being released. These constant improvements are remotely updated to all relevant units in the field. These updates are executed transparently, without any impact on service. Often time our customers are not even aware of these updates, however they are constantly delighted by the continual improvements. We are now at CUBEOS 6.0 (or CUBEOS Onyx). CUBEOS 6 (Onyx), when paired with the right kind of hardware, provides a toolset that is unmatched in the service provider industry.
