I'm generally willing to take statements from Google at face value; they've done unpopular things (killing Reader, etc.), but in my experience haven't been deceptive about them.
I hope they realize how valuable a reasonably secure, "stateless" OS like Chrome OS is for many applications. Chrome OS is far from perfection in this space (and there are a lot of easy ways to make it better, and some hard ways to make it vastly better), but it is head and shoulders above anything else for a lot of deployment models right now.
Handing me a Chromebook with reasonable assurances the "dev switch" hasn't ever been switched is one of the general purpose full-TCB devices I'd accept from someone and mostly trust. (obviously hardware hacks, or switch was thrown and reflashed and disabled/reset). It's also a cheap/awesome way to manage fleets of machines in education and corporate/kiosk/etc. environments -- you CAN achieve that with Mac OS or Windows, but it requires a lot of work.
In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting himself infected with malware requiring regular visits from me or geek squad to wipe his system. When he was ready for his most recent upgrade, I tried him on Mint, but he didn't like the interface. Then I suggested a Chromebook. He LOVES IT. He says it's the best machine he's ever owned. One year later, and not a single issue with malware.
I don't worry about him getting infected. If instead of a Chromebook, he had gotten some Android tablet with an OS stuck at 4.x, he's likely be infected by now.
Android and Chrome OS serve different use cases. Even if Android manages to fix their upgrade issue, I doubt it will ever be as secure as Chrome OS. From the blog, "guaranteed auto-updates for five years", sounds like a few people at Google get this. Fingers crossed.
The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps".
I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state.
These probably don't matter much for individuals but do matter for enterprise. If this existed, even if it were just keys to approve/sign updates and still required google services for a lot of the functionality, would be awesome.
> "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps"
That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's.
I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.
Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage).
It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.
> Why wouldn't you be able to treat them as identical?
If a given machine can have arbitrary software installed on it, then that machine can behave differently than other machines in the fleet.
If all machines in your fleet can only install and/or run software signed with the company key, then the company can ensure that the software load for all machines remains the same and -thus- all machines behave identically.
> How would being able to change the sync/verification server make Chromebooks vulnerable...
If the software repo and/or verification server can be changed by a third party, and the trusted keys installed in the machine can be changed, then it's trivial to pwn such a machine. If only the servers can be changed, then it requires loss of control of one's signing keys to pwn such a machine. [0]
[0] Or -obviously- a sufficiently bad privilege escalation bug can pwn such a machine.
Where do they make money on that? The margins on the devices are so slim and go to the OEMs, which Google mostly isn't. I don't think they charge any money for OEMs licensing the OS, and if they do it's likely a pittance. The only way Chromebooks make money for Google is as a gateway to Google services, and allowing people to fork ChromeOS like that puts that revenue source in jeopardy.
> I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state.
Isn't the verified boot portion of the firmware not reflashable without hardware modifications[1]? Even if the dev switch has been flipped before, a verified boot is a verified boot and the machine should be in a good state.
I haven't looked at that since the early ChromeOS machines, so has something changed about that?
There are some corner cases requiring physical access (you could physically replace the RO firmware, or fake the switch). I don't think it does full remote attestation validation of the local OS before talking to cloud services, although it does some other stuff. I should look into that more.
But really, what I want is the ability to put my own enterprise key in there, in a write-once area, and do exactly what Google does now.
he's likely be infected by now - What kind of infections would these be viruses/malware? Other day there was security expert who mentioned how Android security was bad, but did not mention any specific cases. My dad uses a 4.x device. Many other as well( India where low end has 4.x devices). But i don't see these user complaining about viruses or malware. Considering that they would usually complain about virus affecting their windows os. Is there anyway to know if the devices are infected?
Even Android have a much better security model than your traditional desktop OS. Except if the malware includes a root exploit (in this case, all bets are off), the traditional "malware" in Android is limited to basically what the user allows it. However malware including root exploits should be rare, at least if the user only install applications using Google Play. Using applications from other sources, specially to get "free versions" of paid applications can be really bad.
Unless the user are a completely moron, without enabling access for Accessibility, a malicious app can't, for example, read everything on the user screen, or capture the information the user types (the user would need to explicit allow it by turning on keyboard servicesin this case). This means that a malware can't sniff login information, or read the user e-mail. However they can still get valuable information (if the user did not read the permissions that Android asks before performing installation), like user contacts.
> Handing me a Chromebook with reasonable assurances the "dev switch" hasn't ever been switched
Why would you distrust it if the dev switch has been switched? As long as the write-protect screw hasn't been turned, you can trust the root of trust when the dev switch is switched back.
Consider one thing though, "trusted computing" as a concept comes from the military. It is a computer the generals can put into the field and trust it to not leak classified info (be it the enemy, or the soldiers learning that their lives are being wasted).
So when you use such a computer, you have to ask yourself "trusted by whom?". Because it is also a lovely starting point for the *AA's to cram the file copying cat back in the bag.
In the War on General-Purpose Computing, a trusted computing base is a powerful weapon. There are multiple sides that want to wield it against you. The company you work at will want to be the owner of your work machine. OEMs will want to own your private machines. MAFIAA will want to be the owner of whatever you use to consume media. Most of the applications of TC seem to be harmful to society. I'm yet to hear a reason for why I, as an user, should like to have a TC platform.
> I'm yet to hear a reason for why I, as an user, should like to have a TC platform.
When you are in control of the trusted keys loaded in your machine, this allows you -the computer user- to defend against several classes of attacks, including many Evil Maid attacks.
Many Linux distros and most open source security software projects sign their releases for a really good reason.
"Trusted Computing" takes this a step further by pushing this signature verification into a tamper-resistant part of the computer, and verifying everything on the system, including (on some systems) the bootloader and the UEFI firmware.
It's only when the end-user doesn't have control of the trusted keys loaded into his computer that TC becomes something that can be used for great evil.
This is always the issue with mechanisms of control like "trusted computing" and cryptography in general. The question is, "who is in control?"
Cryptography can be used to control you (for example, signed BIOS), or you can use it to be in control (encrypted email). I think that "trusted computing", when properly implemented, could be a powerful tool for users.
In this case, the concept of a "trusted computing base" is different from "Trusted Computing".
Google could easily market the combined OS as "Chrome OS" rather than Android. In fact that might be a good idea if they're going to make the experience/distribution model more Google-led like it is with Chrome OS.
It could also mean that the two operating systems are going to be merged at a base level but keep distinct userlands, like iOS and OSX.
The point this article was trying to make, is that Chrome OS is under LTS constraints at the UX and userland-API level for its present enterprise users (schools, mostly, but also some corporations.) Under these constraints, the kernel, display-server stack, etc. might get switched out in some future version, but educators who are dependent on their present workflows using specific apps+extensions will be able to continue to use them with no change. Any "merger" with Android will be at a level that is transparent both to the user, and to the Chrome app/extension developer.
This would be very interesting. Imagine plugging your android phone into a dock and getting the ChromeOS GUI instead of Android but having access to all the same data and services. Now imagine we could run crouton and get full access. You could really turn your phone into your main device/dev machine (at least for light workloads).
Kind-of-sort-of like what Microsoft demonstrated with the new windows 10 phones, but a souped up version.
Motorola did come out with a 'Webtop' in 2011 before they got acquired by Google [1].
The laptop dock gave you an Ubuntu desktop to do work in. They even ended up opening up the code (but it was pre-ICS so good luck making that up to date).[2]
'ubuntu desktop' meaning a very crippled system that only allowed access to Firefox. Which was rarely updated and even then not for long. There were some efforts to patch it up to make a more full system but I don't believe anyone was ever successful.
I think that was the general idea, but as I recall the phones did not review very well which is a bummer since you can't just pick a device you want and install ubuntu phone on it.
No. Canonical held a crowdfunding campaign to produce one but did not meet their goals. As I understand it, Ubuntu's desktop environment, Unity 8, isn't ready yet either.
You can run linux/gnu concurrently with most android phones today, just not so easily[1] and not as polished and with the caveat that there is no GPU acceleration[2]. There are a few apps that do it but AFAIK Linuxdeploy is the best.
1. meaning rooting and flashing a 3rd party kernel for starters.
2. intel's next atom version for smartphones due 2016 could well solve this-- currently they use powerVR GPUs in smartphone atom chips, which like all current smartphone GPUs lack OSS drivers. (And being x86 sublimetext would actually work too-- where is the ARM bulid!!.. it would make this so useful)
No chance. The whole idea behind both Android and Chrome OS is to push the user away from root access and leave Google as the one with root access on your device.
> The whole idea behind both Android and Chrome OS is to push the user away from root access and leave Google as the one with root access on your device
Except that you already can "have root access" and can "potentially run any linux app that compiles to ARM" today with ChromeOS and Nexus devices. In this very thread people are talking about running Crouton on chromeos devices and running Ubuntu Phone on nexus devices. In neither case do you need some kind of jailbreak to do so.
All that's needed for the GP's idea is for Android to take a page out of ChromeOS's playbook and allow a devmode that can run alongside of official Google Android.
There isn't a very meaningful distinction between "has root access" and "can get root access at any time by pushing out a binary update that your device will automatically install".
Nexus devices (i.e. the one with the most Google backing) can be completely re-flashed with a firmware that won't accept updates from Google's servers (e.g. with CyanogenMod). If you want an Android device free from their "imperialism", they've always offered one.
I think it's very clear from this post that they do plan to combine them -- but that the goal is to make a combined technical base featuring the best of ChromeOS and Android (which makes sense), not to kill ChromeOS and replace it with Android (which doesn't).
True; ignorance suggests that they weren't well aware of what would sell a story.
Notice, reading the original WSJ article, exactly which (and how few) statements are attributed to unnamed Google sources or statements, and which are speculation or third-party commentary.
I still think Android will be Virtual Machine and Chrome OS will be the OS for both phones and Chromebooks 5 years from now. I also think we will see a move away from Java so what do I know?
I think the idea is Google are just aligning there Core Linux base between all there products allowing for a whole range of improvements from resource sharing to a even better security. and it may even allow them to upgrade Android at a better update rate, with reports that the Google Pixel C a Tablet running Android is getting updates every 6 weeks.
i would also like to point out Microsoft has basically done the same thing with the Windows 10 Core its now on XBOX ONE, Windows Phone, PC and even a Raspberry Pi runs this core but they all have there own user space setups/gui.
This would, imho, be the best possible outcome of this: libchromeos becoming the underpinning for all Google's consumer OS projects, and then having a distinct userland slapped on top of it. Especially if it meant the device-specific stuff all happens in the brillo/core layer, and we can slap a chromeos, iot, or android layer on top of it regardless of the device.
Want to turn your nexus player into a desktop computer? replace the androidTV user layer with the ChromeOS user layer. Want to turn your chromebook into a media centre? do the opposite. turn an old phone into a home automation server by replacing android with the IOT layer.
On the more interesting side, I had no idea about the Chromebit. So now to find out how to get one since the page linked in the article is a "sign up to stay in loop". But after some more digging seems like it is already out, or maybe just previewed earlier this year to some bloggers?
I found out about it a few weeks ago. It was announced in the Spring, supposed to come out in the summer, then nothing other than maybe it'll be less than $100 and available Q4 2015. Hearing Google say it'll be a few weeks is reassuring.
I just bought a Chromecast to play with for a digital signage solution, but this could be better.
I couldn't find any specs on how it is powered. From the very little research I've done, it seems like power over HDMI is possible, but maybe I'm wrong on that. Would be nice to get it down to just the stick.
>the Chromebit contains a quad-core ARM Cortex A17 Rockchip CPU and a quad-core ARM 760 Mali GPU, drawing as little as 3 watts of power, and the Chromebit contains 2GB RAM and 16GB flash storage. 802.11ac and Bluetooth are on board, with the latter meant for connecting a keyboard or mouse; an additional USB 2.0 port is for hooking up a drive or other peripherals. There’s no microSD slot on this one.
I am no expert on the HDMI spec, so I'm unsure exactly what features are required, but I have seen some TVs that can power the chromecast right from the HDMI port, but other ones that require USB power. My cheapish Vizio LCD TV can't power the chromecast over HDMI, at least.
If the TV has a USB port, the Chromecast can be likely powered from that. It works on both of the TVs that I have (neither of which are high-end by any means), even though one of the TVs only claims 500mA of output on that port.
The vast majority of HDMI ports provide the amount of power required by the base spec: 0.275W (55mA @ 5V). DisplayPort 1.2 provides 1.65W (500mA @ 3.3v).
Neither is sufficient to power the newest Chromecast dongle, but you can get far more juice out of a standard DP 1.2 port than you can from a standard HDMI port.
Notice that they never say Android is here to stay - Maybe Chrome OS will become the Phone/Tablet OS under a new guise?
Google's working on a new UI layer and potential backwards compatibility for older Android apps, which points in that direction:
- Chromium developers are working on a DART-based Mobile UI framework and execution engine, Flutter (http://flutter.io/). It's looking to be far better than the existing Android UI system - built for touch and 120fps from the start. This uses the Dartium VM and a bridge to allow the DART apps to use all the native features of the platform, it's much more than just another web framework. Development on this is very active right now, clearly a sizable team working fulltime - and they're building new developer tools also. There was a talk on this a while ago: https://www.youtube.com/watch?v=PnIWl33YMwA .
- Google has built a Runtime to allow existing Android Java-based apps to run on Chrome OS, and is currently testing this and working with developers to get their apps to run on it. It doesn't make much sense to invest in building that out just for chromebooks, since the experience on a Chromebook with Android apps is pretty awful (can't resize etc), but it makes total sense if it's going to be how legacy Java/Android apps run on the new Chrome based phone OS.
The sad truth is that Android simply isn't a very well engineered system - it's been improved over time, but problems persist - like the complex update process leading to unsatisfied users and security problems, poor UI performance (even now, Android can barely do simple animations at a steady 60fps on the latest Nexus devices, and has little hope of allowing for the beautiful animations the Material Design team has come up with), and poor battery life. Google's also at a dead-end with Java given the ongoing legal battles, and with Apache Harmony dead they have to maintain the standard library implementation themselves.
On the other hand, Chrome OS performs great, has awesome battery life on Chromebooks, is quite possibly the most secure end-user OS ever, and Chromebooks get speedy updates for at least 5 years. I know which one I'd choose as the basis for a merged OS.
Of course, if the merge is more Chrome OS than Android, they'd be saying exactly what they're saying now - The last thing they want is an Osbourne effect hitting the current Android phones.
That's because no one seriously thinks for a minute that Android is not here to stay. When you hear about the dominant global mobile operating system (share, not profit) and a niche desktop operating system "merging" it's not difficult to work out which one is more at risk.
This announcement is aimed strictly for business consumption and has nothing to do with technology. Google will be inundated with hardware developers (OEM's) and large Chrome OS buyers (distributors, educational groups) saying "the Microsoft sales people are telling me you're abandoning Chrome OS. This is very disturbing to us as we've made a significant investment in your technology!" This is their effort to rebut some of that FUD which may or may not be FUD.
It would presumably be fud in the sense that to merge ChromeOS and Android wouldn't require all that much in order to provide the functionality people use ChromeOS for. If it provides Chrome + pnacl + support for installing/running Chrome apps, it won't even have to be visible to people that the system underneat is largely Android unless they want to know.
I have a ChromeBook, and to be honest, I have no idea what the filesystem is like, even. As much as the geek in me wants to play around, the pragmatic in me recognises that I bought it to have a light, low maintenance way of running a web brower + ssh on the go, and is too busy doing other stuff than poking around...
So assuming that people will be able to keep running the same apps, with a similarly clean launcher, there's every reason for them to sell that as "ChromeOS isn't going anywhere" even if they may or may not be fibbing from a purely technical point of view.
These are good points, but I view their efforts on ARC more as them expanding the Chrome store's app catalog than Chrome OS completely eating Android.
And as an aside, I think many developers simply don't devote the effort to fully developing their Android apps for Chrome OS. I have an (albeit simple) Android app I publish on Chrome OS, and it's my product's most popular platform. So it gets special attention, and supports resizing with the fairly undocumented "resize" value in the app's manifest:
Never thought this way, this is actually a great idea. I mean, even if Android runs Androids apps natively, in most cases developers still needs to include Android support library, to provide backwards compatibility with older versions of Android.
So since we need Android support library anyway, why not simply include the complete runtime (like ARC), in base of a really simple and slim OS, like ChromeOS with Flutter UI. This new OS would get direct updates from Google, like ChromeOS. To get legacy support of apps designed for Android, simple repackage every existing application with ARC. Win-win situation, right?
like the complex update process leading to unsatisfied users - unsatisfied tech users? Don't thin the normal public care or knows about the version of Android they are running.
Eddystone has a couple different modes. One of them is to transmit a URL, but beacons can also be configured to transmit a UID. Not all Eddystone beacons will be transmitting a URL.
That said, I believe Physical Web does use the Eddystone-URL mode.
But will it still use glibc Linux (Gentoo) or it will switch to bionic Android one? That was the main point, and not the confusion that Chrome OS is disappearing.
Can we please get a gradual plan for looping in the rest of the mainline linux ecosystem?
The desktop market may be shit, but it's there and google could still go after it if they wanted to. At some point Apple is going to realize that the major market it hasn't dominated yet is... the PC, and it's ripe for attack now that alternative computing footholds are so well established in mobile from the Microsoft days of yore.
I'm sure for the vast majority of Chrome OS users, the technology powering their device is of no significance compared to a reliable and consistent UI.
plus who cares? Chrome OS could just be a stripped-down android, and the world would be fine. Actually I though they were already mostly the same (I have a chromebook, but no android device, I don't know what's the difference, appart from the fact that my chromebook gets regular updates)
There are flavors of android including vendor modified or changed specifications. They can be subtle, like a pay as you go phone carrier, or major like what Amazon has done with Fire. Each of these changes introduces security issues outside of Google's control.
With a Chromebook you get the ChromeOS from Google regardless of the vendor who made the hardware.
While we’ve been working on ways to bring together the
best of both operating systems, there's no plan to
phase out Chrome OS
Comes from a worry about chromebook sales, not any presence or lack of a technical plan to merge or combine components from the two.
I would bet this is actually: 'YES, we are merging something with something technically, we're just going to keep two brands for now'.
For all the reasons in the other thread, it's both good and bad in different ways; but I would be astonished if you don't see wide support for Android apps on chromebooks in the near future; and that does require some kind of Android runtime.
so what does this really mean, Chrome-OS will not be "folded" into Android? Can't have a concrete answer after reading it through though.
MS Windows is trying to rule all platforms with one OS, so does iOS, even Ubuntu is trying the same, maybe Google though they need one OS to rule it all as well?
The green Android robot logo kind of sucks, and I bet there's an internal campaign amongst some marketing/branding goons to try and kill it off in the name of beauty and elegance.
Or just taken out of context. Since both Android and Chrome OS run on Linux, a small userland, and a display server, maybe there is some effort within Google to bring these two more together to reduce maintenance cost.
Disclaimer: I don't know how much the code bases differ now.
Fairly substantially. ChromeOS is a fairly standard Linux distro under the hood, albeit with not using X11 or directfb for their rendering layer, while Android uses a different libc, rendering layer, etc.
> Smells like there is a lot of friction and uncertainty inside Google...
Since they didn't make announce their plans of merging operating systems (and thusly just wanted to reassure people that ChromeOS wasn't going away), why does it make it seem like there is "a lot of friction and uncertainty inside Google"?
Seems like you're making a huge leap with little information supporting such a claim. If you have more information than what is it?
> Confused public statments do hint at internal confusion.
Why is it a "confused public statement" because they didn't directly respond to the rumor? They most likely didn't want to. Do you have a criteria for what makes a "confused public statement" and any data showing that it correlates with "internal confusion"?
>Why is it a "confused public statement" because they didn't directly respond to the rumor?
Because the post is about the rumor. They say "hey guys, we heard there's a rumor. anyway chrome is awesome, so remember that. bye."
Making a full blog post about a question while avoiding an answer makes for a very confused statement. If you don't see how then I'm not sure I can help.
I don't have a source for confusion correlating with confusion.
> If you don't see how then I'm not sure I can help.
I think you're trying to see something that may not be there. The entire purpose of the blog post was to assure existing and future ChromeOS users that it wasn't going away and they did that. They didn't comment on the merger rumor itself but they addressed one of the major concerns many of the news outlets were discussing.
That's not confused at all. That's very controlled.
> I don't have a source for confusion correlating with confusion.
This is Hacker News, not reddit; come back with your data if you're going to make a claim about "confused" press releases indicating "internal confusion".
> They didn't comment on the merger rumor itself but they addressed one of the major concerns many of the news outlets were discussing.
No news outlet could seriously interpret 'merge' as 'cease to exist'. So they only addressed a secondary nonsensical rumor while ignoring the core of the issue. That leads to very particular and obfuscatory wording. Confused wording.
>This is Hacker News, not reddit; come back with your data if you're going to make a claim about "confused" press releases indicating "internal confusion".
So the standard of evidence is an impossible study that nobody would even want to run.
I can't assume that press releases have anything to do with what companies are actually preaching internally.
Then what exactly did they ever mean by "merging Chrome OS and Android" if Chrome OS remains a stand-alone OS, as well? And I'm not just talking about the recent WSJ article, either. They've mentioned the merger multiple times since Chrome OS first came out.
Either way, I could care less about the "merger" (which nobody seems to be able to define anyway), but I do care about them being serious about making Android a real competitor to Windows on the desktop, by taking advantage of the huge native app and developer ecosystem they have there (which by definition is non-existent on the browser-based Chrome OS).
In other words: keep Chrome OS or kill it. Whatever. Just get serious about Android on a PC. And please don't begin with the assumption that the tablet interface is enough for that - you know, like you just did with Pixel C? Like that. Don't do that!
after having worked for 15 years in several BigCo-s here i'd suppose that there are a bunch of S/EVPs there and they do what they typically do - whenever they see 2 things walking and quacking similarly [in their non-very discriminant "big picture" opinions] they immediately, like Pavlov dogs, starts to salivate for re-organization and mull the words like "synergy", "duplication", "efficiency", "unification of user experience across the whole range of devices", etc... I mean it is obvious to anybody that these 2 OS-es have majority of similar components that can be made common between them (anybody in Chrome or Android reading that phrase - i'd understand if you choked on your coffee right now :)
> Then what exactly did they ever mean by "merging Chrome OS and Android"
They never said that. The WSJ said it, citing unnamed sources who were supposedly familiar with what was going on.
> They've mentioned the merger multiple times since Chrome OS first came out.
They've said a number of things in the past which suggested a either convergence or increased commonality over the long-term, but increased commonality has, in fact, been occurring, so its not inconsistent with that.
I hope they realize how valuable a reasonably secure, "stateless" OS like Chrome OS is for many applications. Chrome OS is far from perfection in this space (and there are a lot of easy ways to make it better, and some hard ways to make it vastly better), but it is head and shoulders above anything else for a lot of deployment models right now.
Handing me a Chromebook with reasonable assurances the "dev switch" hasn't ever been switched is one of the general purpose full-TCB devices I'd accept from someone and mostly trust. (obviously hardware hacks, or switch was thrown and reflashed and disabled/reset). It's also a cheap/awesome way to manage fleets of machines in education and corporate/kiosk/etc. environments -- you CAN achieve that with Mac OS or Windows, but it requires a lot of work.
I hope they don't kill it in the future.