Nonetheless, the more forks, the better. I think Chromebooks are great.
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).
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*).
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.
(By the way, npm is not available right now).
Only problem I have with my Chromebook is the screen stinks.
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.
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 started by checking out, building and getting frecon to run from here:
This gets you input and display using Linux KMS and DRM.
Next, dig into Ozone code and dig into the drm platform code to figure out how Aura (the window manager) builds.
That's basically where I'm at - I have a KMS screen init'ed and am able to push pixels. I'm still working on getting GL wired in correctly myself.
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.
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 -- r6p0 seems to be newer than when I tried last, maybe you also saw this one -- 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 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 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. 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.
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?
Huh? What's a "Nayu"? How is that a fitting name?
(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.
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).
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.
I think the Crouton project has a section with more details about the setup, because people want to mix chroot windows and Chrome windows. Maybe relevant: https://github.com/dnschneid/crouton/wiki/crouton-in-a-Chrom...
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.
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?
Do I understand correctly that this removes the need to hold down a special key combination every time you boot?
No, you still have to hold Ctrl-D every time you boot.
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 (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.
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.
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.
For the record, the write protect is just a screw on Chrome OS devices and doesn't need to be desoldered.
Edit: no firmware flashing needed. I use standard SeaBIOS
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 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.
Can anyone explain why this name is fitting?