We created NayuOS for multiple reasons. We use Chromebooks, because they are great for developing web applications, but are afraid of standard ChromeOS capturing too much data (some passwords, history of browsing).
Another reason is that it is very difficult to use ChromeOS is China. It is the same for ChromiumOS.
Chinese internet is not very reliable (see http://www.nexedi.com/NXD-Internet.China). We needed reliable network. So we embedded in NayuOS a technology called Grandenet (http://www.grandenet.cn/) that provides IPv6 wherever we are.
This way, we can reliably connect to our company servers when we travel.
Also, we thought that it would be useful to have a local git command line, because we could not find any good web equivalents for this particular tool (Gitlab or Github are nice for reviewing code, but command line is required for rebasing and cleaning up the repository).
Then, we also included Flask on NayuOS in order to run a simple and configurable DAV server (the WebDAV server is not included yet, but git clone-able), which is useful when doing JavaScript development.
It looks as if they are just removing all the connections to Google services and making the chromebooks developer friendly with things such as git and npm preinstalled.
On Chromium OS derivatives, there is a "guest" mode, which is not linked to any Google account and is like a browser "Private Browsing" (Firefox) or "Incognito mode" (Chrom*).
We want to use it daily, and are doing this and by using/developing JavaScript applications, and by adding our favorite packages to NayuOS.
There is no way to add custom packages on Chrome OS (and we don't want to use Chrome OS because of privacy issue anyway).
We also share the binary images for some Chromebooks (not all right now, sorry). This is not the case for Chromium OS, that you have to build yourself.
I've been playing around with Freon on ChromiumOS - it's really a nice solution to pushing pixels fast and I prefer its simplicity to that of Wayland or Mir. The performance I get out of an ARM GPU is very good.
Only problem I have with my Chromebook is the screen stinks.
How have you been playing with Freon, if you don't mind my asking? Specifically wondering, does it expose some GLES context that you can work in, is that passed through, or is that reserved for the compositor... if you have anything at all to share I'd be interested in that.
My tale of woe, which is really OT in this thread, is that I've been trying to get an Enlightenment WM to operate in accelerated mode on my Samsung Exynos-based chromebook that has a Mali T-604 graphics chip.
Enlightenment says it can support accelerated mode with either an OpenGL or GLES driver, so my impression is this should be technically possible (even if it can never be done in an X server running alongside Freon). I have got free-standing Xorg to run very fast on ALARM Arch Linux, using framebuffer driver, and Arch which provides a decently recent Enlightenment... but damned if I'm able to get the two to talk together and let the WM acknowledge the graphics capabilities of the hardware.
I know this has nothing to do with Freon but I am curious what you're doing with it nonetheless, and I saw an opportunity and thought I might be able to corner someone with more knowledge and get some answers at the same time.
To be clear, Freon is just a name for the graphics access model. There's no free-standing freon library per se (All is scattered as bits and bobs between Chrome, ozone and aura)
I've been building a generic windowing system, basically just a pet project to get a custom Aura window manager running on Ubuntu without chome OS.
I have a similar tale of woe as you. I bought my Samsung xe303 specifically as a kind of budget Macbook Air to run desktop Linux on (I currently use an EeePC which is roughly half as powerful). I haven't tried Enlightenment, have to give that a go; the only window manager I could find that supported GLES was KWin, which actually runs but is quite unstable. I've also experimented with various OpenGL wrappers, with varying success.
It's a pain because it's a really nice bit of kit but I haven't managed to make it practical as a desktop machine. I also would be interested in what it's possible with Freon.
I am really surprised there isn't a "just works" prebuilt image for ARM Chromebooks. Its absence suggests to me that nobody has figured this out, yet.
I know some of the Enlightenment core guys, and of course some of them work for Samsung; I've brought it up to them and it's safe to say that this is not a priority business case for them. They are all great folks, but with Samsung driving the train, I think this is no longer exclusively a volunteer project or necessarily strictly a labor of love for everyone anymore.
That being said, it should work. I've successfully installed the dev kit from ARM-MALI support which provides Ubuntu + Mali T604 drivers on an SD card or USB (this was a herculean effort, despite the instructions in question being made specifically for the specific device I have).
I haven't repeated this experiment, but I'd like to try again. I'd feel the chances it would work would be higher on Arch, where software is kept more up-to-date than on the ancient kernel and OS that ARM documentation suggested (it's Ubuntu, but not the current release, or even the current LTS release.)
You probably already found this page[1] -- r6p0 seems to be newer than when I tried last, maybe you also saw this one[2] -- the best "from-scratch" resource I've found that results in a working graphics driver, but good luck getting a modern release of E20 to compile on that... perhaps it could be upgraded without breaking everything.
This thread[3] I haven't visited for a while, but that chronicles my journey pretty well, at least prior to the point where I was trying ALARM or Arch Linux for ARM.
The arch install guide[4] is probably your best bet for what you wanted. I was able to get framebuffer driver installed and hosting the fastest yet (non-accelerated) enlightenment version 20 without compiling anything, and without any really complicated setup steps. I haven't found anyone who is using the accelerated drivers on Arch, the reason might be that they are closed-source and compiled for a specific (obsolete) kernel version.
There are scripts for compiling enlightenment, if you were going to set out to compile it from git head for yourself, by the way[5]. Don't worry they're called "e-nineteen" -- the latest git head is in fact e-twenty. They should work on any recent Ubuntu or Debian release, don't know about Arch, but you will at least need to take out the line that checks for a specific Ubuntu release to get that to work. May need some specific compile-time flags for efl or enlightenment also. I read something about sun-xi the Open-Source GLES driver for Mali, but it seems to be intended for other chipsets than the T604.
I would thereby hazard a guess that you're right, and in fact nobody has figured this out yet.
The doc I linked on [2] looks like it's been updated within the last 2 months, this seems to be where they are keeping the most current notes. Probably updated for the new r6p0 driver. I'd start there, if I was working on this right now.
It also looks like they moved on to 14.04, or my memory about which LTS release was used was incorrect; in any case, there is at least a ghost chance that the current Enlightenment will compile in this context, and at worst these docs will help show you which kernel you need to use in order to make the graphics drivers work.
Maybe these instructions and kernel drivers can be adapted to a current release of Arch for ARM?
NayuOS is related to the chinese word "Nayu" which implicitely means "Open the Universe".
Nayu is also the name of Nexedi subsidiary in China, in Shanghai Free Trade zone.
I always wondered why I saw many dozens of references to the Wayland project (from writers who think it might be a good idea to replace X) and no references, until today, to the idea of turning ChromeOS into something more like a regular Linux-based desktop/laptop OS.
(ChromeOS does not rely on X but rather has its own windowing system developed by Google.)
Writers hopeful about Wayland love to talk about how Gnome or KDE already supports of will soon support Wayland, despite the fact that for a desktop/laptop OS, support from one of the major browsers is much more important than support from Gnome or KDE. (Yes, I know that Gnome includes a web browser: that browser will not work however with all or even most of the sites a typical user needs to visit.) And it is far from certain whether any of the major browsers will ever run on Wayland (without XWayland or some other large X-compatibility library that relies on X) whereas of course one of the major open-source browsers already runs reliably on the windowing system and low-level graphical libraries in ChromeOS.
Firefox works on Wayland now. So, unless you have redefined Firefox as a non-major browser, "is far from certain whether any of the major browsers will ever run on Wayland" is flatly wrong. Also: https://github.com/01org/ozone-wayland
And the obvious point is that turning ChromeOS into a full linux distribution defeats the point of ChromeOS itself: to have very few "moving parts", and only those necessary to launch Chrome. Also, the bulk of the work "for wayland" is not wayland itself: it is KMS/Mesa/glamor/libinput, which are already used by ChromeOS (except for libinput, I think).
Can I run Firefox on Wayland without X, i.e., without XWayland or some other compatibility layer which includes most of X's source code files?
If so, do you know where I can download it?
>turning ChromeOS into a full linux distribution defeats the point of ChromeOS itself: to have very few "moving parts".
Just because that is why Google created ChromeOS does not mean that those of us uninterested in Google's vision cannot bend it or parts of it to other purposes. It is after all distributed under open-source licenses.
That is a shame. Given that Wayland should be a huge improvement over X this will lead to either: i3 withering and eventually ceasing to exist, or a fork of i3 that works with Wayland.
Also what is wrong with systemd (with regards Linux - the BSD's can handle their own init systems just fine on their own)? On my systems systemd has been wonderful.
...But wayland can't replace X. As I understand it, wayland is linux specific, and so saying X will die is saying that no other unix needs graphics.
As for what's wrong with systemd: Where to start! Journald is the root of all evil, it puts way to much stuff in to pid 1, the developers want dbus in the kernel (which is an awful, awful, awful idea), and the project is encouraging higher level software, that has to business being system dependent, link to a library that is linux-only by design. And that's only to tip of the iceburg. Its default's animostiy, its design is an atrocity, the implementation a catastrophe, the only question left to ask is: Where did they go RIGHT?
Likewise. I've been very impressed. The one place it seems to have trouble consistently is with X applications that want to have floating dialog windows. So many moving parts there, I'm hesitant to lay the blame on Sway.
Making it targeted only for Chromebooks makes it really inaccessible for masses. I would prefer to use my Thinkpad anyway, and not to throw another few hundred bucks on a Chromebook that is technically inept.
Why couldn't you provide a generic image with Linux firmwares added? Like ArnoldTheBat does (and Neverware for its CloudReady, but its a closed product) with his build: http://arnoldthebat.co.uk/wordpress/chromiumos-special-build... Things like "It was not reliable because of problems due to unsupported hardware (such as trackpad issues, ...)" will fly away and you will get a new blood of users and devs to your project. Probably you could also tweak kernel config for better hardware compatibility or set of kernel features, since all in all its a fork and you have total control over it.
I also have an acer c720; I totally de-chromed mine, and installed xubuntu 14.04, sounds like you may have done the same? I've been very happy with it, however the other day I was contemplating upgrading to 16.06 when it comes out, but the thought of going thru all the steps again (to reinstall the os) and the prospect of getting something wrong is a strong deterrent imo. Although most steps are documented, it's still a distraction from what I want to be doing, ie developing software.
More than pre-installing packages I think it would be great to have a (working) package manager by default. That way users are able to choose whatever floats their boat.
I've been using Linuxbrew[1] (a Homebrew clone for Linux) on a Chromebook for a while, and it's the reason why I can actually use it for something else than browsing. It's a perfect fit if you need to install development tools or libraries.
Sweet its cool to see people building off of the Chromebook idea. This says its geared towards developers, however I can't find what exactly that means?
On the face, it looks like it comes with some important tools like git, npm, nodejs, ... preinstalled. Some tools for handling detachable crypto filesystems also might come in handy.
The Chromebook is actually a very developer-friendly platform, with a few notable exceptions; one of these is the dearth of software and difficulty of installing things in the developer-mode user's Crosh root shell.
This one neatly sidesteps that (from what I can tell) by installing a few tools you will probably need, and making every user logon happen in Guest mode. Therefore you'll have to get accustomed to connecting your external (possibly encrypted) user files if you want to do development work.
Basically take the popular paradigm of doing all of your "overhead/setup" work on vagrant hosts with chef scripts, and flip it over on its head.
Nexedi is an international company with offices in France, Germany, Japan and China (http://www.nexedi.com/contact), and NayuOS is made with much Free Software love. :)
Can you install this without opening up your Chromebook and flashing new firmware? Last time I looked into running anything but ChromeOS it seems you have to desolder a hardware write protection.
And if this works without that, do other non-google OSes work as well? My device is a Asus C300 without the SeaBIOS legacy emulation or anything like that.
Since NayuOS is still based on Chromium OS you should only need dev mode enabled to run it. It'll boot the same way that Chromium OS does. Legacy boot is only necessary for a traditional Linux distro that isn't using the Chrome OS format for kernel images.
For the record, the write protect is just a screw on Chrome OS devices and doesn't need to be desoldered.
With my Chromebook it was just a simple screw on the board. I have Ubuntu 14.04 on mine - the Arch Wiki has really good info on the general process and HugeGreenBug's Ubuntu flavor is customized for Chromebook
Edit: no firmware flashing needed. I use standard SeaBIOS
Nice idea. No idea if it's even remotely realistic but if you can add Docker then you can run pretty much everything. There are some ways of adding Docker to Chromebooks but then you lose all security benefits at the moment.
ChromeOS and ChromiumOS are both Gentoo-derivatives.
I just installed Gentoo on my fleet of chromebooks. One install image, takes about 5-10 minutes to modify/flash/partition/image a device. A lot less headaches, and runs screamingly fast. I have 12 users, all with the same stock image, running KDE Plasma 5.5 with Libreoffice and JACK running transparently in the background (A Poettering-free[0] experience).
Unless you're _really_ new to linux, and _really_ afraid of building a kernel, Gentoo is a powerful way to learn an operating system, and you'll end up with a stronger and more personal distribution than anything Redhat or Canonical could offer.
Nonetheless, the more forks, the better. I think Chromebooks are great.