131–140 of 140 posts
When the hell are we going to get electron and node.js apps on chromeos. Those are far more important than these crappy blown up phone apps
However, I don't see any technical challenges in supporting Electron apps as well, other than constraints in RAM, performance and security of the Electron platform.
By looking at the comments this article is creating confusion. So I thought I might provide an overview of the two things happening with ChromeOS. 1) Android apps have been enabled on many Chromebooks using a locked container that shares a Linux kernel with ChromeOS. You do NOT have access to the container mechanism that is being used. It ONLY supports a container locked by Google. It is NOT using Docker also. This i…
There's also another option. Many Chromebooks and Chromeboxes allow you to install a new bios and run a normal Linux distro without ChromeOS at all. Handy if you like the cheap hardware but aren't interested in ChromeOS. See https://johnlewis.ie
Basically a commercial gnu/linux.
Earlier quoted context omitted.
Conversely, a ChromeOS device is much less locked down than an iOS device, since you can run full Linux (with root) in a chroot on a ChromeOS device.
We may be doomed to an infinite regress here. After all, a Chromecast is more locked down than an iPad... Someone considering running chrooted Linux on a Chromebook is going to be more interested in a Mac than an iPad, so IMO that's the more useful comparison. I did run Crouton on a ChromeOS device and came to regret it. ChromeOS devices don't run a mainline kernel, they run something that Google provides which event…
But I sort of agree with you too. I'm running Linux desktops rather than Chrome machines for that reason.
I wonder how hard it would be to get this working on, say, Fedora... At the very least, one would need to replace what sounds like a surfaceflinger wayland proxy.
Very easy with ChromeOS 67. Just boot, launch a chrome window and type Ctrl alt t. Then type vmc start dev. Then you can use whatever distribution you want as you have full GNU/Linux. Only works on Pixelbooks but Google will extend and will share more at Google IO. You can even package up gnu/Linux applications. One click and they run in a container but on a second Linux kernel. So Android shares the ChromeOS kernel…
Not a surprise to anyone who has followed Linux kernel security for the past years...
Earlier quoted context omitted.
To be fair you can't go very far without running into garden walls in Apple land. It doesn't just apply to development. Want to change your launcher / dialer / etc? WALL! Want to run a different web browser (an ACTUAL web browser complete with JS / CSS engine). WALL! Want emulators or adult-themed apps? WALL! Want to develop for iOS or macOS on Windows or Linux? WALL! The list goes on and on...
ChromeOS is significantly more locked down than macOS, developer mode notwithstanding. Firefox for iOS may use WebKit, but Firefox for ChromeOS isn't even a thing.
Can you explain as this does not appear to make any sense?
Btw, also Google gives source code in addition.
Or are confusing strong security with a wall? They are different.
Earlier quoted context omitted.
Conversely, a ChromeOS device is much less locked down than an iOS device, since you can run full Linux (with root) in a chroot on a ChromeOS device.
We may be doomed to an infinite regress here. After all, a Chromecast is more locked down than an iPad... Someone considering running chrooted Linux on a Chromebook is going to be more interested in a Mac than an iPad, so IMO that's the more useful comparison. I did run Crouton on a ChromeOS device and came to regret it. ChromeOS devices don't run a mainline kernel, they run something that Google provides which event…
Plus going to be far more secure and optimized for the hardware.
Earlier quoted context omitted.
There's also another option. Many Chromebooks and Chromeboxes allow you to install a new bios and run a normal Linux distro without ChromeOS at all. Handy if you like the cheap hardware but aren't interested in ChromeOS. See https://johnlewis.ie
Much better to use gnu/Linux on chromeOS. That way you get updates for drivers, security, etc. Basically a commercial gnu/linux.
I can't wait for the day that phone operating systems development environments are a docker pull away. It's encouraging to see Google approaching my ideal workflow using containerisation. Apple systems are great until you run into the garden walls and are forced to use closed-source single platform software like Xcode. Chrome OS and Android are a lot more open in many respects. Hopefully efforts like this continue wi…
Believe it or not, there are a lot of these kinds of projects out there, mostly obscure, probably by necessity because in fact it is a lot of work to maintain such a system. But, due to the abhorrent nature of the OS vendors, sleeping at the wheel, there is no choice other than to build another, OS-like, system on top.
And where that is always happening, and still will for quite a while I hope, is in the games engine department. Sooner or later, games engines become operating systems, become hosts for spreadsheets and collaboration and other such nonsense...
All this is to say, I have my xcode builds running in a VMWare container, they're safely backed up and replaceable, etc., and all they do anyway is build the target hosts: android, ios, linux, windows, macos, etc. for the .. separated through an abstraction layer .. application.
The use of Lua, I think, is a good example. Lua on all the mobile platforms, would deflate the whole thing...
Earlier quoted context omitted.
To expand on andrewaylett's comment, that it is open source doesn't automatically mean "100% hardware compatibility." Even for the linux kernel, someone somewhere has to figure out how to get it to boot on every piece of hardware. It's not magic. The nice thing is that if the first person who gets it working can just 'git push' their code to kernel.org, then the next person doesn't have to redo all that work.
You're correct in sentiment. But one can't git push to Linux master without having the patch reviewed and merged by a maintainer.