10 years ago I would be really excited, as I could expect some groundbreaking tech like search engine or revolutionary approach to something, like Gmail (no ads sent to users, great UI, hige disk space).
Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...
Yes, now when Google's social enforcement algorithms label you an impediment, they can not only delete your YouTube video business and cut you off from your email, calendar, and Google Docs, they'll be able to turn the heat off in your house. The march of progress.
Five years ago, I would have thought you were trolling, but now you are right. With this scorched earth mentality exercised by the big companies, this is a very real possibility.
What scared me quite a bit was Apple blocking all services when an Apple Card wasn't paid. That leads me to believe that Google could via an algorithm's decision disable a Nest thermostat during winter. I don't see IoT as anything but a risk.
> What scared me quite a bit was Apple blocking all services when an Apple Card wasn't paid.
I'm not trying to sway your opinion of Apple, but you should know that Mr. Curtis's Apple ID problem was discovered to be unrelated. Apple doen't disable Apple ID services because of missed Apple Card payments.
??? Your linked article says the situation is even worse. Not just Apple Card, you can have Apple services disabled if you owe money to any part of their ecosystem.
"I'm sorry, I'm having trouble understanding now."
I mean, yeah, I can toggle the light switch to get it to turn on, but then it gets screwed up and I need to go into the app to reset it when the internet comes back on.
I don't even want to think about a smart thermostat. My dumb thermostat from 10 years ago let's me set timers which is all I really need.
While I've never had issues with turning on and off lights via Alexa -> Smart Plugs, I have had my Echo Dot unable to play my wakeup alarm due to internet blips. Really? That particular function couldn't store some data in some sort of local storage? Like, I don't want the thing to be able to tell me Rick Springfield's biggest hits in order of Billboard chart performance while offline... I simply want my alarm sound to play at 6am.
Yes, while one could make the case that I should purchase and plug one more thing into my wall. Would it be impossible to place a small amount of memory on the board that remembers alarm settings? If this thing is built as a convenience, I don't want to have a bunch of other devices for convenience (a radio, a noise generator, an intercom....)
You don’t want a remote-controlled smart (actually: dumb) home. You want a fully local solution, then you can add remote, internet-dependent functionality like alexa to it. That way your primary mode of control will always work.
Agreed. I'll add to that a healthy application of the Principle of Least Astonishment. If you have a light, there should be an obvious light switch nearby that turns the light on and off, and does so even if your home automation system is offline for whatever reason.
"Smart" devices should, wherever possible, function as dumb devices if for whatever reason they can't be smart. There are a whole lot of devices that simply become bricks.
"An escalator can never break: it can only become stairs. You should never see an Escalator Temporarily Out Of Order sign, just Escalator Temporarily Stairs. Sorry for the convenience."
Very true— I would definitely imagine that escalator brakes are a thing that fail closed in the absence of power, but clearly there are failure modes (probably a rare confluence of multiple concurrent failures) where this kind of thing can happen, such as that incident in Rome in 2018:
I've never understood the desire to control systems by speaking to them in code words. Speaking monopolizes a shared channel, requires diverting your conversation, and is really slow.
For practically anything that involves using code words to tell the computer what to do there are better input methods, like physical switches, or purely automated.
This is slightly off-topic, but in your opinion what are some of the reasons people prefer to use voice input with code words over the other options ?
Physical switches rely on light as a handshaking method.
When the light is off, the switch is invisible and you have to guess at where it is, or where you need to be walking (hitting your shins on things, or stepping on lego)
Using a non-light based interface means it works just as well when the light is on and off, vs being a broken experience for half of the usecases
1. Hands are dirty/unavailable (like other mentioned cooking)
2. The physical controls are physically across the room
3. The physical controls can't be located easily (lost remote, dark room)
Another point, the cognitive load of speaking a command is different than pecking through menus on a phone or finding the right button on the remote/device. It may be easier to just speak out load depending on your state if mind.
If you're interested in getting more quickly and WANT to write software, you can have the Raspberry Pi control most televisions over HDMI-CEC using libcec [0], and then you just need the voice recognition stuff mentioned above (Rhasspy [1]).
I had to do something similar (minus voice controls) to keep my existing remote's volume controls working with an analog volume device [2].
Agreed. I've been really happy with Ikea's Tradfri line. It's all on Zigbee, works without internet and doesn't need an "Ikea account". However lights and blinds only for now, plus they have perpetual shortages.
And get some motion detectors. Your lights should come on when someone enters the room and the light is below a threshold. I usually hit the off switch by the door when I leave, otherwise if no one is present the lack of movement will dim and then turn the lights off. It's 2021 people!
We use the motion detection to turn on lights and usually turn off manually. I've set up ours to remain on until a fair amount of inactivity. In two years it's only turned off once whilst we were watching a movie.
This is how the Honeywell stuff seems to work, at least for my thermostat. As long as there is some local wifi, thermostat and controlling unit will work, even if you cannot contact them from the internet.
The unit is event-driven, so no, you would just lose the ability to change its current programming. Regardless, it can be bypassed on the actual boiler heater, it's just a thermostat. It's a decent set of compromises, definitely better than anything going "no internet, no service".
In my case: No power would mean I have nothing to control anyway. The only reason my local network is down would be my power down. That happened twice in the last 16 years.
I've actually had a really positive experience using a smart thermostat. The main benefit is having a temperature schedule, which my previous dumb thermostat didn't have. It's also handy being able to adjust the temperature from my phone whenever I'd like to. I find controlling it by voice kind of pointless. On the phone, you can easily see what it's currently at, then adjust it for the next e.g. hour, after which it'll switch back to the default schedule.
I agree being able to change the temperature settings from a phone would be convenient, but they've had "smartish" thermostats capable of relatively complex temperature schedules for at least 20 years.
No need for an internet connection or mega corp data collections.
can smartish ones detect when you leave home and turn down the heat until you get back? My nest can. This is great because my schedule is not the same every day.
Most dumb thermostats also have next-hour-override functionality, though I will say I had a Nest at a previous house and also thought it was pretty decent. In particular, it was nice being able to turn it way down when going away, but then crank it back up when heading home but still 30 mins away.
You don’t really need anything “smart” for this. This is basically simple remote with timer. My $50 thermostat has adjustable schedule with override capability. No machine learning needed. The only thing that’s missing is the phone capability but I think that would be easy to add.
Totally agree. I still don’t get the appeal of “smart” whatevers.
> No machine learning needed
Now this reminded me of the windows 10 update announcement proudly declaring that they were going to start using ‘machine learning’ to figure out if you were using your computer to minimise the disruption from their automatic updating. I’m still baffled by it. Why not solve the actual problem at hand - updates being really slow, risky/buggy, settings altering, and very disruptive even when scheduled, and users not having enough control over updating? I’m pretty sure ‘machine learning’ isn’t needed to determine whether a computer is being used.
I have smart thermostats, specifically the AVM Fritz! ones. They only require their own router (which, where I live, is a common thing to have) and use DECT to talk to the router (you can find DECT usb sticks that work on Linux, the protocol they talk isn't super complex). They run about 2-10 years on a single battery, depending on use.
And they're fully offline, the router has an API I can control them from (HomeAssistant instantly picked up both thermostats and lets me control them), pretty much everything I want.
AVM's smarthome story is miles ahead of Google/Apple/etc. Same for IKEA's smarthome stuff. If you need offline capable things, use those.
Check out Home Assistant. Not sure how well voice controls work with it but my automation is flawless so far. Really seems to help using local only open source firmware where I can and Zigbee for any sensors that aren't hard wired in (mostly for battery efficiency.)
I just read yesterday that Home Assistant is now automatically included in Raspian (Raspberry Pi targeted OS). I run my home and shop automation on Pi's but ultimately a NUC is probably a better long term solution.
I have openhab in place for issues like this. Enjoy the smart home with a local connect-to-everything controller/bridge. Runs on a Pi, as a VM, ...
Works great!
In my experience it brings minor conveniences: yelling at Google or Alexa to turn on the kitchen lights when your hands are greasy, or dimming the lights with your phone when you're sitting on the couch with a cat on your lap. None of these are huge selling points, but once in place they're nice.
If done right, though, the system just degrades gracefully to a normal set of switches.
I'm in a rental, so instead of smart switches I just use smart bulbs. For like <$10/bulb, I've got full RGB/colour temperature adjustable.
Most are configured so turning them on turns them on full brightness and pleasantly warm. The one in the bedroom and the baby's room are configured to turn on dim and warm, and if you do another quick off-on flick of the switch they'll come on at full brightness.
So they... work like normal light bulbs. Except they're all remote controllable from your phone. So if the baby falls asleep on top of you and the light's on you can turn it off without getting up and waking her up.
From there, I added some basic z-wave sensors in a few spots in the house. If you get up in the middle of the night to use the bathroom, as soon as you step in the hall the motion sensor picks up that (1) someone is moving in the hallway and (2) the hallway is currently really dark; and it turns the hall light on a really dim red. Enough you can see where you're going without killing your night vision. Then a minute after it stops sensing motion it turns off.
If you walk into the one end of the basement where the washer/dryer/workshop/storage/etc are, all of the lights will come on for you, and a couple minutes after it stops sensing motion they all turn back off. If you want them to stay on you can just flip the switch off-on to turn them all on and keep them on. So now if you just wander over to let the dog out, grab a tool from the shop, throw a load of laundry in, etc, the lights are just automatic. No need to try and balance a laundry basket while you screw around with light switches.
The room my office is in does the same thing except uses my computer's lock state for presence detection. So when I walk in the lights come on, when my computer unlocks it keeps them on. When I lock my computer it goes back to the regular program. At any point I can pull my phone out and flip them over to the super bright, super harsh light when I need it for doing fine work instead of working at my computer.
Just a lot of little, basic conveniences. And it's amazing how futuristic it feels to just wander around the house and have lights turn on and off for you as you do.
It all runs locally in a VM on my server, with all the smart devices entirely isolated from the internet. If the internet's out... nothing changes. If my server/WAP/whatever dies, then my house just goes back to working like a normal house.
> I mean, yeah, I can toggle the light switch to get it to turn on, but then it gets screwed up and I need to go into the app to reset it when the internet comes back on.
That doesn't sound right. All the Zigbee/Z-Wave switches I use maintain proper state through HA, even if they lose connectivity for a period of time.
I added a bunch of Shelly Wi-Fi relays to my house and I can see temperatures of every room, tell the heater to turn on etc, from anywhere in the world, with full self-hosting if I want it.
I have been presently surprised with Google Assistant in this regard, the integration with my TV (with new Google TV Chromecast) is amazing and a lot of time I don't bother to pick up the remote. (Saying things like "Play xyz on TV", switches on the TV, figures out the right app and starts playing the show saving me 4-5 actions on the remote)
We put Etekcity remote controlled sockets in a few places and stopped there. That being said, apparently you can buy a radio module to control them from a raspi, but we haven't gone there yet.
> Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...
Since Chrome came along, the 'Web' became less free from the start and the moment Google forked WebKit (called Blink) to use it in their own browser, it has turned the web more into a walled garden each time apps use specific Chrome features and it is getting worse. Even in that early decade, we knew about how Google and others were tracking us since the PRISM program leaks.
Later DRM was added with reasons and votes unknown, devs have to keep telling users to switch from any other browser to Chrome to use their apps and now this forked engine is in tons of Electron apps with Microsoft jumping in and using it in their Edge browser. The time to complain was 10 years ago and now it is almost too late.
Now Google is doing it again with Fuchsia which will eventually replace ChromeOS and Android. Fuchsia is highly dependent on Flutter and those apps will run on Fuchsia devices on day 1. There is an extremely low chance of that being abandoned so I'm afraid it will continue.
There's so much here that I don't really know where to start. Maybe some history could be useful?
When Chrome came along, the dominant browser was Internet Explorer 7. It had been out for two years when Chrome 1.0 was released. Before IE7, the world ran IE6 for five years. Web development was largely stagnant. That was the world that Chrome came into.
Before DRM support was added to browsers, you needed to install plugins to watch protected content. Despite what detractors might think, the content producers were never going to go YOLO and release their content without any protection. There are a lot of us that are happy that we can watch Netflix, Prime or whatever in our browsers.
That a ton of desktop apps use Electron is an indictment of the state of native toolkit. Saying that Fuchsia is highly dependent on Flutter is like saying Linux is highly dependent on GTK. With that said, maybe your crystal ball on the future of Fuchsia isn't so clear.
And so, the web has just switched hands from one behemoth to another. Nothing has changed since then. Now everyone depends on Chromium for almost everything. That is the point.
The alternatives have no chance in doing anything about it. Firefox is entirely dependent on Google for funding (and has been for years), Microsoft recently switched to Chromium for Edge and Safari is again years behind (Just like IE.). There are only really two competitors here. (Apple and Google once again!)
So let's sit back and just watch Google continuously adding more superfluous features into the Web like Web(USB, Bluetooth, NFC, etc) and the web-devs will force you to use Chrome again (which indirectly helps Electron apps); leaving the rest of the non-Chromium browsers in the dust.
> Saying that Fuchsia is highly dependent on Flutter is like saying Linux is highly dependent on GTK.
False equivalence.
You're the one that just compared a kernel with full operating system. Oh dear. I'm definitely sure that the device in the article is running Flutter right now.
> With that said, maybe your crystal ball on the future of Fuchsia isn't so clear.
Given that Fuchsia also has the intention of running unmodified Android apps as well, my crystal ball could not be any more clearer of its future. Perhaps you getting confused on your last sentence was an indication that your crystal ball has just malfunctioned.
There's a massive difference. Back then you had a single company that kinda-sorta didn't care about the web. They already had an application platform they were happy with. There wasn't really an incentive for them to evolve it once they had the dominant position. The web was stagnating for years.
Nowadays we actually have multiple players that are very active in the development of the web. The situation is not at all comparable.
> So let's sit back and just watch Google continuously adding more superfluous features into the Web like Web(USB, Bluetooth, NFC, etc) and the web-devs will force you to use Chrome again
Superfluous to you. If developers are using it, then it's obviously filling some need. What do you say to developers who are asking for those features? "Sorry, that's not compatible with my idea of what the web is. Go write a {Windows,Linux,MacOs} application and tell your users to download it".
It always comes back to this. People want progress in the areas they care about, but no progress in other areas.
This is the bigger risk. I don't see Fuchsia as a walled garden OS as it's pretty well designed to avoid that. Userspace everything with a microkernel makes for a nice small security footprint for IoT devices that can be perpetually updated.
The issue is how long google keeps up "perpetual".
Fuchsia, like Chrome, has been open-source for years, and all commits and reviews as well as the bug tracker are public. It is a very different model from how Android releases work.
Chrome is not open-sourced, Chronium is. I cannot rebuild Chrome with full protection against tracking, for example, but with all other parts unchanged.
Android "open sourced" as well, but literally nobody runs AOSP, stock OSS apps are staled for years, Google makes a lot to make system barely usable without proprietary parts from Google Services.
That's a fair point, and the distinction between Chrome and Chromium is indeed relevant. Sorry for the confusion, see my sibling comment about how it applies to Fuchsia (ie. what is open source and what may not be).
What I really meant to say, though, is that Fuchsia is taking an approach to inclusiveness and open source which is much more similar to the one of Chromium than Android. You may find out more on https://fuchsia.dev/fuchsia-src/concepts/principles/inclusiv...
So, if I buy a device that runs Fuchsia (say, this Nest Hub), is enough of Fuchsia FOSS that I can run my own copy of it with e.g. a different UI and without Google services? This is true of Android devices by necessity as the kernel is GPL (bootloader locking aside); is it true of Fuchsia devices?
As for bootloader locking, Google releases some Android devices with unlockable bootloaders. Can we expect the same of Fuchsia devices?
There are several parts to your question, let me try and answer each of them as I understand them.
Fuchsia is built with a minimal core (sometimes called a microkernel) and many user-space services interacting with each other over an IPC protocol (called FIDL). The open-source part of Fuchsia, available on fuchsia.dev, is a standalone system which you can build and run on supported architectures. It contains all the services required to start a user interface, interact with the network, etc. Currently, the main supported hardware architecture for people wanting to build their own version of Fuchsia is the Intel NUC: https://fuchsia.dev/fuchsia-src/development/hardware/intel_n....
For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated. For more information on services and packages, you can read https://fuchsia.dev/fuchsia-src/concepts/software_model and the pages linked from it.
Some of those services are drivers; others may be in charge of communicating with Google Services or customizing the UI; and not all of them are necessarily open-source. So if you wanted to build your own version of Fuchsia for a Nest Hub, you'd need to replace the closed-source components. As far as the Nest Hub is concerned, I'm not sure what the exact status is. I believe a significant part of the drivers have been developed in the open (which is how 9to5google was able to guess in the past that we would be targeting this platform), but take this with a grain of salt, I didn't work on drivers. The part that interacts with Google Services is closed source. I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they?
Finally, as you note, the bootloader can be locked on retail devices, preventing you from reflashing the system with your own build unless it is signed by an authorized key (mostly for security reasons, as far as I understand it). This is a product decision that is not related to Fuchsia itself, it depends on each manufacturer. I don't think it has ever been supported to reflash a Nest Hub, and the migration to Fuchsia shouldn't change that.
> For a retail devices, such as the Nest Hub, vendors can build a custom system with additional or different services from what is found in the open-source release. Thanks to stability of the FIDL interfaces, those closed-source services do not prevent the core system from being updated.
This is helpful so long as the interface does not change; do you anticipate ever having to change it or do you think it's pretty final at this point?
Regarding drivers, it's interesting that they're userspace services interacting with the rest of the system via IPC. Are there any sort of security guarantees to protect against malicious services? (Obviously a proprietary driver could do its job incorrectly, but if they can't otherwise mess with other parts of the system that's helpful.) EDIT: I suspect that as it's a capability-based system, there is a decent amount of isolation between drivers and the rest of the system, but I just want to be sure.
> I'm not sure this is much different from the situation with Android: not all drivers or UI used on Android devices are open source, are they?
Regarding Android drivers: my understanding is they sometimes do have proprietary userspace components. Any kernel-side components are necessarily FOSS however, as they are derivative of the Linux kernel and therefore GPL. (This doesn't mean that they're always easy to use though, as manufacturers seldom upstream them and the Linux kernel is a huge project.)
On the Android UI, you're correct; most often the UI on an Android phone is not FOSS. I suspect this is because, as that part of Android is permissively licensed, the device vendors don't have to release it. So they don't.
I've had mixed feelings with Fuchsia from a licensing perspective for that reason. On one hand, having a stable interface might make it easier to deal with proprietary drivers, provided that interface is locked in amber and never changes. On the other hand, Fuchsia's permissive licensing makes it more likely that manufacturers will make all their drivers proprietary, because they clearly do whenever they can. (At least the ARM vendors do; the x86 vendors seem to be a lot more open to working in public.)
For non-driver interfaces, similar stability commitments may be shared over time, as the platform matures and we get more users.
> Are there any sort of security guarantees to protect against malicious services?
Fuchsia is based on capabilities, ie. handles to access resources, and those include memory regions. So a driver will only be able to access the parts of memory that you delegate to it. I don't know enough about drivers to provide a detailed security analysis, but I think it provides far more isolation than what you have in a monolithic kernel such as Linux.
> Fuchsia is based on capabilities, ie. handles to access resources, and those include memory regions. So a driver will only be able to access the parts of memory that you delegate to it.
Ah thanks - Fuchsia drivers having capabilities to specific memory regions mostly answers my concerns at that level I think.
Well, I guess I'll continue to be both interested in it from a technical perspective and conflicted about it based on licensing.
While the platform may be open source, the product may not be. We have products which are completely open source, but the one being used for the Nest Hub is not. This is similar to the idea where you may use Linux for the bottom half of an OS, but the top half may be something else entirety. Different products may make different decisions, but a common core is used amongst all products.
The BSDs have lots of drivers too, but it's rare you see them coming to an embedded board first (and rarer you see BSPs published for them from vendors.)
In this case, unlockable means it can be unlocked. As a native American English speaker, I have not seen unlockable used as "cannot be locked", but both definitions are in the Oxford dictionary.
If I understand correctly, a locked bootloader prevents you from installing a different OS or rooting a device you might "own".
"Unlockable" == "The option exists for the user to unlock the bootloader if they wish to do so."
Even as a native speaker, it can get awkward explaining 'unlockable bootloaders' because the impliction is that they're first locked if they can be later unlocked... when there are also locked bootloaders that CANNOT be unlocked.
It's better to just assume 'unlockable' means 'not restricted.'
>We’ve been tracking the development of Fuchsia since 2016, starting from an ambitious experimental UI, to running on Google’s many internal testing devices for Fuchsia, ranging the full gamut of Google’s smart home and Chromebook lineup.
Your implication is that Google is not treating Fuchsia as a 'throw it over the wall' project, but as one with community participation. How many of your colleagues are from outside of Google? How often do you work with non-googlers as you develop it?
Are you regularly reviewing code submitted by your colleages at Samsung?
The fact that you're confused by the concept of working with people outside your company doesn't bode well for the open-sourceness of this project.
The fact it's more permissive with its license already does not bode well. Just like with Chrome, there could be a myriad of forks that can be closed source themselves and so without easy means to peek inside what they're really doing, and although many distributors did the bare minimum with Android due to its Linux kernel's license, there was something.
Or: "Join the independent" is a slogan of the open handset alliance, users are required to install Google Play and related services on all applicable devices.
>Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...
There's no need to wonder. Fuchsia's been designed to do all those things and more.
Starting with a modular design that caters to device manufacturers that allows them to provide only part of the operating system. The days of devices with full os's are coming to an end.
Cloud based constant device syncing between all devices
>Dependency on Web Apps
Google and device manufacturers will have full control over the microkernel and bootloader
Honestly, I'm not excited at all. I've been dreading fuchsia since it was first announced. Everything about the os is designed around google having complete control over the os itself and everything on your device.
Yep. I would guess the main driver for Fuchsia is that being a microkernel, drivers can be userspace things. So less work for Google to manage phone vendors. And the Fuchsia version of "AOSP" is easier to keep their secret sauce out of since there's no Linux GPL wrangling.
Nah, it's an hardware-related project, so it will get entrenched even if it's fundamentally different from other hardware-related Google projects.
Eventually you'll be able to buy Google devices that run Android, Google devices that run ChromeOS, and Google devices that run Fuchsia. It will be confusing, but that's fine, because it will all work great as long as you stick to Google's cloud-based services, which is what really matters.
Directly or indirectly, OS fragmentation actually helps Google's business model.
It sucks. They tried to pull me into the walled garden by ending Works With Nest and I still hate that I had to change to a different solution. The Nest thermostats are great, but having to go through the internet for any automation sucks.
Moreover, they can arbitrarily ban you from their walled gardens and you're more or less screwed.
When their control your email (GMail), business infrastructure (Google Business Apps / Servers etc.), Google Play (matters if you're a developer)... basically your entire digital existence.
I really hope we add more regulations to protect people online. While it's not clear for everyone, your digital existence is an essential part of being part of the society.
> Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...
I've been worried about it since they announced it which feels like it was 10 years ago.
With how Google is acting, I am fairly certain that I well never willingly buy a device that runs Fuchsia. I will have to find a better alternative device/OS or keep my current Android phone going forever.
There is however a huge issue of being locked-in to only officially-sanctioned OS versions, and I fully expect Google to try and completely replace everything that is still open in Android with proprietary replacements, making the Fuchsia-based phone OS the only accepted version.
As an example of the lock-in, the primary mobile payments app where I live has the following list of requirements/restrictions:
- Android or iOS only (there is no PWA or other web-based version)
- Minimum version is currently Android 6.0 or iOS 11
- Device must not be jailbroken or rooted
- Device must not run a non-official ROM, such as LineageOS
The use of this app is pervasive in society here, if you buy/sell anything second-hand, people will expect you to use it and will be surprised, annoyed, and/or suspicious if you prefer to use cash instead.
And this is by far not the only app with these restrictions. Banking apps, streaming services, there are a large number of apps with these restrictions, all under the guise of security concerns. Thankfully most of them have web-based versions or alternatives, but it can present enough of a hurdle that even tech-savvy people either will not or cannot use anything but a recent Android or iOS device.
Almost as bad are websites that would work perfectly well in a mobile browser, but practice "soft" lock-in by condescendingly pointing you towards the official Play Store/App Store if you try to load the site in a mobile browser. Facebook Messenger is a huge and obvious offender here, there is nothing about instant messaging that wouldn't work perfectly well in a browser, after all the desktop version at messenger.com works just fine.
I think you are wrong that Gmail was revolutionary. It was a good service, but nothing special in my opinion.
But yes, the license would allow Google to close the system down whenever they want. Still curious to know how Fuchsia would be a better choice for a system.
Its so weird how fast history is forgotten. Gmail was a galactic leap forward in terms of mail clients. At school there was a grey market to sell gmail invites at 20 dollars per
It really is. Things get comfortable and people assume that's always how it was.
Like cell phones. Wow, over a decade of them and if you had one 15 years ago you were considered a early adapter, and 20 years ago you were way ahead the curve. If you had one in the 90's, wow.
we've got so much storage and so many/good sensors, yet the software kinda pushes you to use the device for watching dumb videos and/or to argue worthlessly with other random people, so that you can get served ads in the meantime.
- Thermostat adjuster ("smart" thermostats saved us running a wire for a second-floor zone, so, whatever, we've got them, they're OK)
- Level
- Document scanner
- Note taking/reading device
- Timer (kitchen; any board or party game that has an hourglass that you've misplaced)
- iPod-alike for the car (replaces burned CDs)
- Alarm clock
- Takeout/delivery orderer
- Check depositing device
- Shopping list displayer
- Navigation aid
- Taxi hailer
- Probably other stuff I'm forgetting
I don't think I'm even particularly "in to" using it as much as some people do—I can't bring myself to trust Apple Pay to work, so it doesn't replace my wallet and in fact I think I've only used that feature once ever; I don't really game on it; I read on an e-ink reader or on a huge iPad, not my phone; I don't do any "smart home" stuff aside from the thermostat; my use of Siri is limited to setting reminders and alarms, and putting addresses into navigation to save having to type them; in about a decade of smartphone ownership I think I can count the movies or episodes of something that I've watched on my phone on one hand; I don't do workout tracking or any of that sort of thing.
[EDIT] oh, right, camera, obviously. It replaces the family camera and camcorder of my youth, completely.
What else do you think people ought to do with them? They're pretty small, so e.g. reading a book is a bit difficult, and using them as general purpose computers is difficult because they lack a keyboard (and thus an easy way to program them).
>The UI was pretty shitty, and not much better than Hotmail.
UI performance was great due to early use of ajax. If you had bad connection, which was extremely common in 2000's, then it worked way better than any alternative.
Of course, now it's the other way around, static websites are fast and SPAs can be dogshit slow.
It does 'grouping' at maximum. Try reading a mailinglist in the gmail webinterface. A reply on a reply should be indented one level, not being shown at the same level as the mail it replies to.
A gigabyte mailbox space was revolutionary when many competitors only gave 20 megabytes for free (and you could pay and upgrade to 150 megabytes or so).
That was an example where a simple change in a number turned into a qualitatively different service.
I came here for a technical discussion about Fuchsia and it's microkernel approach instead this is mostly fill with complains about Google as a company.
Is there a social justice forum I can visit where I may be able to have a technical discussion about Fuchsia?
I think the discussion cannot be really detached, since Google has strong ambitions that will undeniably influence features and capabilities of their OS.
But as for the microkernel approach, I think the advantages are on the table, but they are theoretical. Until now, no OS with a micro architecture was successful at getting significant market share.
What would your requirements at an OS like this be? For me, it would be extensibility and the minimalist approach.
Don't know the implementation details, but it sounds a lot like a time when people loved OOP too much, or later disliked it just as much.
I work in the embedded area and it is true that these approaches are more successful here. But I think that is due to real pressure for memomy and speed or real time applications. That isn't really the case for general purpose devices like PCs. Those have an unlimited amount of memory and CPU power.
The irony is that hypervisors and containers have basically taken away whatever benefits monolithic kernels might have.
OS X and Windows are much better in this regard than GNU/Linux/BSDs with their ongoing efforts to move all drivers to userspace, even though they will never be fully pure microkernels when done with it.
He, true. Although I wonder if microkernels tend to expose more lower level function in user mode that could be relevant to overall system security. The big problem is probably memory access, which would be prohibited in user mode, but maybe there are other security implications (I couldn't answer that question).
Other than improved security that may also be protected by a hypervisor, you might still gain more stability when pushing drivers to user mode. Or your hypervisor has a bug and allows a guest to gain privileged kernel access. Not a security expert, so this is mainly guess work.
Could you say something, how the kernel is different from linux for example? Why would I want to choose Fuchsia for a smartphone, for example. Where is the advantage?
Some things that Fuchsia was able to do thanks to starting from scratch:
- The system is based on capabilities, a security model which is based on explicit tracking of permissions. It wouldn't be possible to change Linux to be capability-based because the ambiant-authority model has been used pervasively since it was conceived 30 years ago.
- Fuchsia provides a stable binary interface (like Windows, but unlike Linux). This lets you update your system while keeping some components unchanged, eg. binary drivers from a hardware manufacturer that wouldn't provide updates for them anymore. I think Linux could technically change this, but they have historically been unwilling to, and it is unlikely to change in the future.
The micro-kernel architecture is definitely a game changer for this, compared to Linux...
Linux tried different things to reload dynamically the drivers & core stuff, without rebooting the computer, but I always had diverse issues after some hours...
When the goal is, to support a broad range of devices - and the vast majority of hardware manufactors are not into open hardware - it is probably easier, to convince them of supporting Fuchsia by writing firmware and drivers - if they do not have to deal with the GPL and the kernel driver integration, like it is the case with linux. They just write their driver once against a stable API.
That makes things easier.
And google are not driven by free software ideals - but rather buisness pragmatism. But I don't see this design choice as an attack on free software.
I dont know about that. The Linux/GPL model has had mixed success in the embedded space - most vendors still ship their code as binary blobs making it difficult or impossible to update the LInux kernel, which has security and other implications. But, there have been some vendors embracing the open source model to some extent at least, and a lot of third party work in supporting upstream kernel development of drivers.
I dont think it would be fair to call Fuchsia a step backwards in this respect - vendors that ship closed source binaries for Fuchsia are almost certainly shipping closed source binaries for Linux as well.
- Fuchsia provides a stable binary interface (like Windows, but unlike Linux).
Does it?
Fuchsia is a brand new OS, at least from the perspective of the world. One reason my interest in it died quite early on, despite being an aficionado of new operating system designs my entire life, was finding stuff like this in the docs:
Well, I think it is no surprise that in the beginning things change.
Everytime you do something new and big - you do find things that do not work out as designed. So you change the design. Which is allright for me, with a prerelease.
But now with the official release - I do expect some stability.
I don't know a lot about Capsicum, but from what I remember (and see from their website) it adds capabilities to FreeBSD but doesn't make them mandatory. As such, it is a tool to build compartimentalized applications. It does not provide a comprehensive solution to sandbox existing applications, and does not remove the ambiant-authority model. It is a better, safer chroot(). Fuchsia, on the other hand, is built on top of capabilities from the ground up, ensuring that you don't even have a concept of "file descriptor" or "centralized filesystem" to begin with.
I think the cause of this phenomenon is that most HN readers are not qualified to comment on Fuchsia, are ignorant of any and all facts about it, but are also compelled to comment. So you get this thread, and most threads here. Actual technical exchange between people who are both not obviously wrong is rare here.
I disagree, I think the state of this discussion thread is about what should be expected given what Fuchsia is and how the project is run.
Firstly, there is little technical discussion of Fuchsia here because there's actually very little to discuss. Fuchsia is, design wise, a pretty ordinary operating system differentiated from Linux mostly by using a microkernel. If you've ever looked at SEL4 then you've got the gist of what's going on here. I'm not aware of any obvious ways Zircon differs from any other microkernel design. Like all such systems it has an inter-component RPC layer (called FIDL) which if you've ever used the Android Binder will look familiar. And it's got a component system. In some ways these upper layers are reminiscent of COM and the whole OS has a bit of a Windows NT 3.1 architectural vibe. That's about all there is to say on the matter.
Fuschia is an oddly unambitious platform. Here's a representative quote from the docs:
"There is no concept of inter-package dependencies because transitive dependency closures have unbounded resolution time"
This statement is technically correct but practically incorrect: when users complain about dependency resolving package managers, they are complaining about out of date packages, broken dependency graphs, centralized repositories and other things. The fact that dependency resolution can be NP-complete in artificially constructed worst case scenarios never comes up because in the real world, dependency resolution takes a few seconds and the problems surface elsewhere. But they found an excuse to avoid doing anything hard or new in the world of software distribution, so they took it.
Elsewhere people promote its ABI stability compared to Linux. Maybe, but this is Google we're talking about. Constantly obsoleting stuff is literally built into their incentive structures, so we should double check that right?
120 results for deprecated already! Nobody even uses this OS yet and they already changed their mind about APIs all over the place.
The same lack of ambition is visible if we look at the Architectural Principles section of their site. Their principles are: "Secure, Updatable, Inclusive, Pragmatic". That's it. "Secure because capabilities" is a very old discussion with not much to add, and the rest is vague or just not that interesting.
Those principles brings us to the final reason the HN discussion is so lacking in technical depth.
The OP complains that the discussion here is all about politics and wonders in jest if there's a social justice forum where they might find technical discussion of the project. Amusingly the OP's wish is easily satisfied by the Fuschia website itself. Fuschia is by far and away the most ideologically biased operating system project you will have ever had the misfortune to encounter. It is something the world has never seen before, an entire operating system controlled by the hard left. Every single page in the docs has a giant banner across the top saying "Google is committed to advancing racial equity for Black communities". Note the demand for equity, not equal opportunity. Classical liberalism is dead here, tokenism is in. Of only 4 so-called architectural principles one of them is "Inclusive". They make a brave effort to pretend this is actually about technology by claiming that being just a microkernel+RPC is inclusive because they don't provide any language runtimes for the users (i.e. spinning missing features as a form of moral purity). Then it all falls apart and they go back to talking reducing harm and bias via language control - another tenet of hard left thinking.
So let's imagine we're looking for something better, fresher, bolder than Linux, macOS or Windows. We look at Fuschia. What we see is an extremely conservative OS design in which the most modern ideas in it pre-date Linux itself. We see an overwhelmingly political project, run by a company that has in the last year been systematically erasing from its platform crazy wack-jobs like, er, doctors and professors simply because they disagreed with the WHO. And we see that there's no discussion, anywhere, of any features that end users might actually care about.
That's why there's no discussion of technology in this thread.
Googlers thinking non-Googlers are unqualified to comment on anything seems like a fairly common theme to me.
I really wonder what caused this kind of ideological entitlement. Was it a company culture that never said "no"? Was it the constant talk of how Googlers are just smarter and more brilliant than everyone else? Genuinely curious.
It was the part where people decided to ignore what was actually being presented, and instead derailed every possible conversation about google into their predetermined track. Not you specifically, but this entire fuschia thread.
What is someone to think when every time their work is presented publicly the comments are all completed unrelated to what was presented? You too would conclude that group is unlikely to present meaningful feedback or thoughts.
Perhaps it would useful for Google and googlers to "read the room" - as it were - and consider why a lot of people have such strong reactions to Google's conduct and methods, why a lot of people are distrustful of anything that comes out of Google (and FAANG in general), and why the reactions are so strong from privacy advocates and the open source/free software crowd in particular, in context of where and how Google started and where it is now.
I'm not sure what you are suggesting here. Should the developers that work on specific input methods for fuscia be "reading the room" and instead spend their time switching to work on ad tech, where they can influence it? Google has 10's of thousands of engineers, wedging ad tech discussions into the output of every last one of them seems completely and utterly unrelated to the article.
I would humbly suggest that people working for companies that have become notorious for customer-unfriendly behavior and a complete disregard for privacy, reconsider whether that is something they wish to continue to contribute to, or not. Do they wish to contribute to the coffers of a company that will use every possible means available to erode privacy, to extract maximum value from open source without giving one iota back, and to enforce more and more corporate censorship on the open web.
Advertising and a complete disregard for privacy is in every part of Google's DNA, you cannot possibly claim ignorance of it, simply because you are in a department not directly working on advertising. That is equivalent to covering your ears with your hands and going "la la la I can't hear you".
That is why it gets brought up in every discussion about Google, because one bad apple really does spoil the entire bunch, their bad behavior in regards to privacy and a complete lack of customer support taints the entire organization, and everyone who works for Google has sold their respectability for a Silicon Valley paycheck.
Everyone who works in tech needs to take a good long hard look in the mirror, and decide for themselves whether they're OK with everything their employer is doing, and if not, perhaps consider why they choose to still work there.
Hacker News is still the best place for such discussions. There's just a lot of low-effort noise from people who force every topic to conform to their existing knowledge areas.
> Hacker News is still the best place for such discussions
In general it is, but I too have noticed this trend more specifically in Google-related threads. Most other subjects don't suffer from this as much, but almost every Google one devolves into jokes about when X will be canceled.
There’s no clear line here - it’s systems all the way down.
When a new component is added to the critical path, its vital to ask “What happens if my account gets flagged? How much of my life can Google shut down with a single bit flip?”
That's clearly not what I said. I was responding directly to my parent comment which said we should try to separate a work from the context in which it operates. It was not a value statement on Fuchsia OS, anyone who worked on it, or anyone on Google. It was simply a statement on separating work from the context in which it operates.
Why would you choose to pretend you know less than you do?
Things are made by people and each individual person has their own background, circumstances and ideas. The culture of Bell Labs abetted (but did not cause) Unix and the sharing of source code. The lack of pressure to generate profit within Bell allowed Unix to use an unusual licensing model, which led to it being widely available in universities.
Context does not totalize - it allows and directs. Google has a business plan and a culture that promotes some things and prevents others. It's not a conspiracy - they're quite public about most of it. There are things that are possible at Google that are less possible elsewhere. We can, as participants and observers in culture, speculate about what is more possible and less possible in a Google OS project. To not do so would be blindfolding ourselves.
If you want to talk about something "outside" of its cultural context (if such a thing is possible), you certainly can - but will your conversation partners set the same things outside the context? Better to be explicit than blindly implicit imo.
Minority? I feel like i can't read anything about google on HN without half the converstion being unrelated to the technology and strictly related to ads. The minority are the people that think "wow cool, another new shiny toy to investigate!".
Because then work just becomes a more boring riff on the Nuremberg defense. You can't just be like "I'm just paid to write code and so will completely ignore any and all ethical issues with what my company does with it."
There's a reason the ACM code of ethics has "everyone is a stakeholder" and "avoid harm" as the top two overriding principles.
I can understand arguments about keeping political issues unrelated to your work and working relationships out but you this isn't that.
>Because then work just becomes a more boring riff on the Nuremberg defense.
Writing code to build Fuchsia OS does not involve great violations of morality and ethics that call out for something like the 'Nuremberg defense'.
>I can understand arguments about keeping political issues unrelated to your work and working relationships out but you this isn't that.
Where's the dividing line? Wasn't it Basecamp that had a large portion of their workforce quit because they couldn't be activists at work? Was that them mitigating the 'Nuremberg defense'? What about the recent issue with a principle of an elementary schools calling on parents to boycott Israel [1].
There are very few jobs in modern America that have these great ethical dilemmas. There are, however, plenty of people that are willing to engage in hyperbole and politicize every space they can. That's a much bigger problem.
> Writing code to build Fuchsia OS does not involve great violations of morality and ethics that call out for something like the 'Nuremberg defense'.
Respectfully, while I don't think that Fuchsia warrants invoking the Nuremberg, I do think that it is highly likely to enable violations of morality and ethics down the line. The way I see Fuchsia, it's basically an effort to undermine the Linux kernel and switch it out for something with an MIT-style license. I see this as objectively immoral.
Linux is the de-facto open source kernel for the majority of people, and the fact that the open source kernel uses GPL (which strongly prefers end user freedoms) is one of the few things that holds the tide of privacy violations, user disempowerment and proprietary tech capture of our infrastructure, institutions and societal conventions. A world without a strong GPL base is a morass that drags down useful developments.
Quite frankly, I see no reason for Fuchsia to exist, and plenty of reasons why it shouldn't exist (not least because Google is in control). It should be boycotted. The society will be better off for it, though it may make a few billionaires cry.
You’re doing exactly what you condemn in your post. I said a boring riff specifically because I wanted to highlight that there’s a huge magnitude difference while being able to use the most common term for the particular line of reasoning.
You’re right, writing an OS for Google isn’t some world shaking ethical conundrum and it certainly wouldn’t be enough to turn down a FAANG salary and the experience for. But that doesn’t mean that the company’s corporate strategy for the product (i.e. the entire reason the project is funded) is suddenly irrelevant and you can wash your hands of it. If the business reason for pushing this OS is so that Google can have a desktop OS with lock-in to their services and have data collection at the deepest level like they do with Android then that doesn’t meet the bar for avoiding harm and that as engineers we ought to be empowered to push back or outright say no to to buildings things that hurt our users.
Nothing about this has anything to do with Israel or Pizzagate, or Black Lives Matter. Politics encompasses far far more than the things you see on CNN. I’m not saying that people should be advocating for random political causes they care about in the workplace. I’m saying that people should be able to act politically for things that are literally their work.
* Pushing for accessibility features being a requirement to ship is political.
* Pushing for telemetry to be anonymized is political.
* Pushing for ML datasets to include people with dark skin so they actually work is political.
* Pushing for data collection being opt-in is political.
* Refusing to build a product that interferes with EMT radio frequencies is political.
Unfortunately, every new project coming from Google now has a couple of decades of baggage, directly caused by the unexpected / manipulative cancellation of projects.
While I am not Google-free at the moment, especially email, I have long ago learned to avoid trusting any Google product to stay stable, or even available.
And that doesn't even scratch the surface of the decades of "everything we do is tuned to collect as much data as we can steal without getting caught, and using it to our benefit in any way we can hide from you, our users."
Cynicism is pretty much the norm now, and is going to color everything Google does forever.
I'm sure there are forums and github sites with actual technical details, but that's only a fraction of what gets traded here. YMMV.
I've only recently started fiddling with Fuchsia and I'd be interested to see it running on a device and see how truly usable it could be in the real world. It seems the community is pretty active online which is a good thing: I raised a concern about building Fuchsia on non-Debian based distros and potential solutions(one of which I tested and workes) and I had 4 or 5 replies in a couple of hours. And while the thread has turned into yet another "bash Google" thread, I'd like to thank the engineers for their work and hoping to see more in the future. As I said I haven't tested it on an actual device but if it is as lightweight and versatile as advertised, it has the potential to become incredibly big and valuable. I guess only time will tell.
Around December or January I tried to get Fuchsia going in QEMU to play around a bit and maybe contribute back some code, but nothing quite worked as I expected. Based on this experience I had figured they were still years off from shipping but I'm pleasantly surprised to see that I was (obviously) wrong.
Congrats to the team and looking forward to seeing it work as intended!
It's actually pretty standard to fork QEMU when you want to emulate a custom kernel/board. QEMU is a good common emulation platform, but in no way it can emulate correctly every quirks of a custom pci or even PIC device expected by the system.
I'm not expert in QEMU, but to my understanding, it would make sense to fork QEMU to support a new hardware/board/platform, but not so much to support a new "software"/"firmware" on top of an already existing and used board platform.
I had a brief look at the setup information and there’s nothing that makes it clear why there’s yet another piece of highly Google-specific (though presumably open source) software that people would need to learn to use while they learn about Fuschia.
FEMU is really AEMU, it forked from QEMU many years ago for a variety of reasons.
Today this configuration offers Vulkan support, which will hopefully make it's way back to QEMU eventually.
We use both QEMU and FEMU in our work, if you checkout Fuchsia you will find prebuilts of both in //prebuilt. QEMU provides broader control over hardware and broader emulation features, often useful to the kernel and driver teams. FEMU provides Vulkan graphics, more useful for teams working on GUI applications.
Any pointers to any hardware / dev boards that one can run fuchsia on? I remember seeing Intel NUCs being used in the past, is there a recommended hardware configuration for developers now?
Not to discredit the effort, but saying you've released your own fork of QEMU to run your own OS, creates an impression that you're perfectly happy to (prefer to?) create a parallel universe for yourself, with your own tools and its own ecosystem... Which will obviously all be controlled by Google. Not very good optics, IMO.
If you want promote Fuschia as a useful, general purpose computing platform (and not just an attempt for Google to avoid the GPL), you probably want to work upstream with existing projects to improve support generally instead of creating your own suite of forks.
Yet Google's Browser engine is a fork of WebKit and surprise it is used in Chrome, Electron and QtWebEngine and everyone is using it.
As Fuchsia is highly dependent on Flutter and the whole ecosystem will be able to run Flutter apps on day 1, I would bet that this is going to be the Android replacement in this decade.
This is how old google would have worked. Now that google is all grown up they take a more cost conscious approach. How the mighty have not so much fallen, as sunk.
I'm almost more excited because of the proxy network affect this will have on microkernel popularization and alternatives like Dahlia OS (https://dahliaos.io/) that are looking to be independent distros of Fuchsia.
I understand peoples concern about a walled garden situation here, but I'd argue to only become worried if Fuchsia suddenly stopped being committed to openly and someone needed to maintain a fork. The working code for both the microkernel and the OS is all open source.
What is interesting about Fuchsia is how Google first created Flutter and made it popular for Android/iOS and to a lesser extent the web. And now they start releasing Fuchsia OS/devices and developing apps/software for it will immediately feel familiar to many mobile developers.
This could help adoption instead of yet another GUI framework to learn from scratch.
Huawei is doing the same kind of approach, make android apps compatible with their Harmony system.
I think everybody has learned from Microsoft and Samsung's experience trying to launch a new ecosystem without support for current application android ecosystems.
Similarly, free software running on proprietary Unix OSes became (during the years 1983 through 1991) very popular before any free Unix kernel started getting traction.
Congratulations to the team, this is a big milestone. I worry that this will permit Google to disengage from the linux community, but I'm optimistic that it will result in improved device security.
This is exciting to see (in a neutral way, I'm not rooting for it) because I wonder how large fuchsia will grow and if it will contend with Linux. Why wouldn't Google want to push containers running it's brand spanking new os without 30+ years of cruft on gcp. And if it has performance/security why wouldn't developers start moving over.
That’s true. But unfortunately all that baggage comes with lots of genuinely useful stuff too. Starting from scratch rarely works, unless you’re willing to put in a lot of time and effort, and are in it for the long haul, and people that want to start from scratch rarely are, and google doesn’t have a good track record in these matters either.
They have an OS running on a consumer device that connects to the wifi where you can play media, browse the web, and run flutter apps, so it seems like they already put the time and effort.
It even self-updates, so in some sense it's already ahead of the standard linux distributions!
Which standard distribution are you running that doesn't self-update? All of the ones I use (Fedora, Centos, Debian, Ubuntu, Qubes) do this and have done for years.
Ubuntu doesn’t update itself, out of the box. It just mentions the availability of updates in the MOTD. And upgrades to new distributions are completely manual and user-initiated.
Normally I'd agree about Googles track record. But they HAVE to innovate in the android/mobile space. It would be their death as opposed to just dropping a random messaging app.
And they did all the "from scratch" work. It would be short sighted to not let zircon at least have the potential to replace Linux.
Apple vertical integration strategy recently took a big step forward and googles response may well be this.
We should judge on what has been finished rather than what has been started. After people start to work with it, that's when the real costs will start to be incurred.
Apple are an interesting case in that they have done this very very gradually over many many years - building on top of existing tried and tested platforms where possible.
Google seem to be dominant in android/mobile despite their crappy OS. Whether they're threatened or not, this does need to be improved. This may or may not be due to Linux - to me it seems to be more the case that it's again their failure to stick to things that's the most frustrating aspect of using Android - but maybe using Linux means they spend more development time doing that than dealing with features. Perhaps they're just trying to emulate Apple's strategy alá cargo cult.
Hmm, looks like Fuchsia still uses Dart/Flutter for the front end. My experiences have been positive (although I’m sure someone will be happy to explain how my opinion of Flutter is wrong) so I’m glad to see it.
I'll gladly come in with the other end of the argument :)
Dart? A half-baked language with quite a lot of unexpected gotchas that can cause you to lose days trying to find why something isn't working (only to notice a lib author forgot to add a return for one branch of the code, or the code works differently depending on what runtime it's on).
The Flutter ecosystem is constantly breaking, the plugin system was broken for at least a year and "in migration" where most of the stuff you do is either "broken for future" or "is going to be broken in future". Dependencies are in a circular hell where updating one thing might make you update the whole project, but then your project might not be compatible with the current Flutter version so you'll have to nuke your directories and call 'flutter create' again in the project so it recreates stuff with the new templates.
Also don't get me started on issues.
Had a crash span for over 6+ months on all devices with low-budget Adreno GPU-s, most of the issues were "closed automatically" because of inactivity or because they declared it does not follow the template google requires for the issue, altho there is dozens of them reported, they held a hotfix for months on end in a branch with other changes because it was " a lot of work" to merge it downstream. Had a talk with the Flutter team about reconnecting to isolates on one conf, one dev's answer was "oh yea that's problematic, maybe just the best is for the user to restart the app".
It's classic Google behaviour wrapped in a "new cool thing" package.
Flutter is a great thing if you wanna build a cheap app fast and never worry with maintaining it ever again.
If you're going for something long-term, avoid it like plague.
Dart / Flutter is nice, the problems with it back in the day were mostly just the fact that it was (previously) competing with JavaScript on the front-end.
Congrats to the Fuschia/Zircon team! It's very exciting to see a freshly-architected OS appear on the scene, with a non-copyleft license, a big company behind it (so hardware vendors will actually write drivers for it), and direction set by one company (instead of 10+ as is the case with Linux/Android). Can't wait to play around with it :-)
according to ars technica [1] they removed the ui layer from the repo... is that accurate and does that mean we are in for a macos type situation where the real treasure (the ui bits) are locked away?
What problem does Fuchsia solve? Google already has at least three other operating systems to use.
On the other hand, Google has never seemed particularly shy about starting something new rather than work on something old. I'm thinking of their messaging systems that they start every couple of years.
Also, the branding isn't great. The top image in the linked story immediately makes me think this has something to do with T-Mobile.
It's capability based, so instead of this weird hodgepodge we have in the Linux world that resulted in Docker containers it's natively a part of the OS design.
Also its not GPL, so we will see actual binary drivers instead of GPL <> proprietary shims in Linux that need to be recompiled on kernel upgrade.
So it solves a lot of problems for Google and can replace Android/Chrome OS/Cast OS.
> Also its not GPL, so we will see actual binary drivers instead of GPL <> proprietary shims in Linux that need to be recompiled on kernel upgrade.
That could be prevented by hardware manufacturers manning up and releasing their source code in full. If the community cared about that hardware, it'd eventually get upstreamed into the kernel, or at least actively maintained as a patchset.
They haven't worked on the base stuff of Android and ChromeOS. Both use Linux software abandoned by upstream, e.g. ChromeOS uses upstart and have their patched non-mainline kernels.
This requires lots of extra work, then even doubled since they have 2 platforms. Wanting to have one mature platform for both makes sense to me.
My wild guess is it reduces the amount of privileged code. In Linux the entire kernel (all 20 million lines of it), can do what it damned well pleases, and auditing 20M lines of code is mission impossible. You could think of it in terms of Windows/OSX/Linux Distro vs Android / iOS / WinPhone. In the former, this is nothing stopping one application stomping over anothers data. The result has been endless uninstallable viruses and malware. The latter force complete almost isolation between applications. What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.
Fuschsia, being a micro kernel, puts each functional unit (device driver, network protocol driver, file system, crypto functions, yada yada) into its own isolated process, so the damage a rogue function unit can do is more limited. Interaction between functional units must happen via the Fuschsia kernel (they can't talk directly), and surprise surprise Fuschsia heavily polices those interactions using the "capabilities" provided by the kernel. Capabilities are are very similar to user assigned permissions.
That seems obvious and attractive, but keeping those processes isolated and policing those permissions incurs a overhead, or perhaps more accurately the cost of communication between two isolated processes is much higher than non-isolated (think processes communicating with pipes vs memory sharing threads). In Linux that overhead is still visible as the syscall overhead, which is large enough that high performance applications go out of their way to avoid it. io_uring is another attempt to avoid it. Microkernels multiplies that overhead by many times. Possibly worse, that overhead is getting worse with the advent of spectre like cache timing attacks forcing cache's to be invalidated on a context switch.
In my very brief look at Fuschsia is looked refreshingly clean, small and well thought out. But then all many projects do. Sadly it started like as a C++ code that is now moving towards (as in is now 50%) Rust. To be true to it's safety goals it should all be Rust. And it doesn't seem to bring much new stuff to the table. seL4 has been in the same space for the same reasons for years how. So I don't see how Fuschsia's introduction will change the basic equation that's lead to the dominance of monolithic kernels.
What both seL4 and Fuschsia both desperately need is some magical hardware solution to "isolated process communication" overhead, one that also addresses spectre. Mind you, if a way to isolate code with bugger all overhead came along, it's so attractive I suspect they would be in a race with the existing monolithic kernels to exploit it.
> What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.
Taken to its extremes (which Google has been moving Android towards), unfortunately it also breaks a number of existing workflows.
If you follow the documentation, any multi-file formats (HTML documents with their assorted resources – JS/CSS/images/links to other HTML files/..., playlists, videos with externally stored subtitles, multi-part archives, ...) are broken on recent Android versions if you need to handle them in an external app, e.g. if you're writing a file explorer which then naturally needs to call out to other installed apps for actually opening those files.
It really depends on the polish of Fuchsia for Nest Hubs. Getting a few more FPS out of the 1st gen hardware is something I'm actually hoping for because it's gotten really slow and I rarily touch the screen anymore because of the lag.
Seriously, this device is only a few years old and it runs like a 2013 windows netbook. Apps crash all the time, bluetooth glitches, unresponsive UI, etc.
I'd still call this a success for rust in the wild, if a huge entrenched company like Google would include it so much for a big OS play, even if it shares that room with more established languages.
I am planning on not purchasing any new google smart home hardware. I am annoyed that my nest thermostat no longer has a way to interface with their API. I purchased it right before the Google acquisition and I would have gone with an Ecobee if I knew the Nest would be inaccessible to a regular user.
I believe having an open API is an important part of smart home hardware, even if most users don't use it.
Does anyone know if Fuchsia, or any higher-level environment built on top of it like this new software for the Nest Hub, includes a screen reader for blind users? This will be necessary before Fuchsia can be considered a full replacement for Android, Chromium OS, etc.
As explained in the article, the release of Fuchsia should not change any supported feature (please report a bug via the "send feedback" option if you notice otherwise!).
Thanks for the response. I know what the article said, but I also tend to assume that accessibility will be overlooked or treated as not very important.
I'm tempted to buy a first-generation Nest Hub, maybe off eBay, to find out for myself.
Given that this describes my family and we have a first gen Nest Hub I expect to be able to soon report whether Fushcia is as accessible as the prior Linux stack.
Thanks. If you find that there's a regression in accessibility with this update, I'd appreciate it if you would email me (my email address is in my HN profile), to make sure I get the message even if I forget to check this thread, so I can help sound the alarm.
I can't say I've ever thought about the OS on my Nest Hub. It's a digital picture frame, and it plays YouTubeTV/Music while I'm in the kitchen. It occasionally answers a question - what will this new OS change?
The badbadbad part is that this won't be open, and it'll force adoption of restricted hardware that will no longer be usable by the AOSP. Prolly 5 years out, but still; pour one out for unlocked Android-compatible hardware at any price. Gonna hafta go full tinfoil hat and get a PinePhone.
You must have not noticed that Chrome is the new IE, or that they recently revoked API keys that open source Chromium forks (including ones that just disable certain features, so they are 99% the same as official Chrome) have been using for years to allow them to sync bookmarks and the like.
Safari is the new IE. It's stagnated in the same way IE did, which has slowed the progression of web standards. How long did it take to get input type="date"?
Apple's attack on PWAs also shows they wish to neuter the web to encourage use of their app store (where they take a 30% cut) instead.
> "or that they recently revoked API keys..."
The code is open-source, but they aren't obligated to grant access to their services.
> Safari is the new IE. It's stagnated in the same way IE did, which has slowed the progression of web standards.
Chrome is not like IE in that it stagnates the web. It's like IE in that it reinforces the dominance of nearly the entire web by a single company - Google.
Chrome, also much like IE, has a stranglehold on what makes it into new web standards and what doesn't. That the web standards are technically open is irrelevant, if Google de-facto rules the whole standardisation process. What they decide goes, goes. What they decide doesn't go, doesn't. The W3C standards process is neutered at best, and corrupt at worst.
Hypothetically, even if they weren't the dominant W3C stakeholder, their market share gives them control over the experience and control of an enormous amount of users. They can trial and enforce FLoC, Manifest v3, and other changes that take away user control. Once user expectations get readjusted, culture around such toxic features shifts and they become acceptable. I'd be surprised if that's the end of it.
Some websites only get tested on/built for Chrome ("works best with IE"), because "everyone only uses, develops and tests on Chrome anyways". Non-Webkit/Blink browsers are collateral damage. Most webby runtimes like Electron, and most third party browsers, will also embed some variant of Blink these days. This leads to browser engine monoculture, and is capital-B Bad. Firefox managed to outmanouver IE by being bug-for-bug compatible enough, but these days, web standards are two orders of magnitude or more complex. The effort needed to build a new, compatible browser engine is more akin to building something like Wine[0] from scratch.
[0] winehq.org
> The code is open-source, but they aren't obligated to grant access to their services.
Of course they aren't. But this is after letting open source projects do it for years. What changed now, all of a sudden? Besides, the open browsers that are more-or-less straight-up Chromium forks usually are not materially different. Just a different logo and maybe some telemetry ripped out, big deal. The kind of person that uses Google sync in a fork is the kind of person who already's in deep into the Google ecosystem. They really don't have a reason NOT to let people use FOSS-specific API keys, especially since any abuse they might get because of these is so miniscule it's not worth mentioning.
> "The W3C standards process is neutered at best, and corrupt at worst."
Bear in mind the W3C hasn't been driving standards for many years. The WHATWG has been effectively in charge of steering that process. They're made up of all large browser vendors, which is why they had the effective power to do this.
While Google is a key player in the WHATWG, they're definitely not the only ones proposing and testing new features. Both Apple and Mozilla also test new APIs. Mozilla is the most reserved, but Apple hasn't been shy about testing new features either. It's why we have prefers-color-scheme now.
> "They can trial and enforce FLoC, Manifest v3, and other changes that take away user control."
I don't see how FLoC takes away user control, personally. It should be trivial to opt out of a cohort if you wish. It's an over-engineered solution but it's one that strikes a compromise between ad networks and users' privacy concerns.
Why should we compromise at all, you ask? Because millions of small businesses rely on ads to stay afloat. Decimating the ad networks overnight will have far more casualties than Google's coffers. We need to transition the ad ecosystem to one that's privacy-conscious.
Manifest v3 is a massive API change so you'll need to be more specific there. If you're referring to their content blocking API, it's essentially a more powerful version of Safari's content blocker. They've addressed most of the criticisms people had early on (eg. dynamic rules, header blocking). They're switching to a declarative model to prevent malicious extensions from tracking users.
> "Most webby runtimes like Electron, and most third party browsers, will also embed some variant of Blink these days. This leads to browser engine monoculture, and is capital-B Bad."
I agree that monoculture is bad, but it's a product of their own success. Blink and V8 are more portable than Gecko or even Trident, and that allows them to be embedded in applications like Electron.
Servo would have been Mozilla's answer to this, but that doesn't seem to be in the cards now.
> "The effort needed to build a new, compatible browser engine is more akin to building something like Wine[0] from scratch."
I agree. Personally I'd like to see certain APIs (like IndexedDB) deprecated to reduce that complexity, but the web has a strong focus on preserving backwards compatibility.
> "What changed now, all of a sudden?"
I can only speculate, but I wouldn't be surprised if there was a legal concern. ie. these users are using our services but haven't agreed to our terms of use.
And yanked them out from underneath the adopters whenever it wasn't fun anymore.
I don't trust in anything Google anymore except that internal politics and profit motive will override anything beneficial eventually. Look at Chrome if you're not sure what I mean.
Yea I can see that with chrome. They created useful in that time that any opensource benefit others. After that they started writing their own spec for chrome, made youtube slow on firefox using shadow dom api etc.
These I think google is more evil that microsoft. But many people enjoy free service thats why they are not complaining.
This is the correct answer. Do not allow a subtly different technical design distract you from the largest switcheroo here: this is a single-vendor enterprise OS delivered under the guise of open source, it comes with all the trappings of a single-vendor enterprise OS.
Let's not be too quick to forget when Android first started out, all the idealism about the wonders of a free software mobile OS. A decade later, it's almost impossible to buy an Android phone that hasn't been strongarmed (no pun intended) into including Play Services, Chrome and Gmail, often including through threats to the manufacturer's unrelated businesses.
We're older and wiser, avoid this garbage like the plague, and don't fall for all the same old tricks.
Android would be dead in the water today if it wasn't for Play Services. Developing for Android is still painful today because but Play Services at least meant that you could expect a certain range of features spanning multiple major releases of Android.
I'm pretty sure that Play Services wasn't something Google really wanted to have but were forced to implement because so many OEMs just shit the bed w/r/t their Android forks.
Only because they didn't licensed Android in a way that would have prevented that in first place, nor have proper clauses on their Play Store contracts.
These licenses are totally meaningless when Google make anti-competitive threats to their partners for attempting to exercise that license. They benefit from all the marketing of their vendor ecosystem in the public eye using the open thing, while quietly holding a gun to everyone's head in the background. That is the absolute antithesis of what "genuine open source" is supposed to be about, it is a marketing ruse and you've fallen for it.
My point is that it's totally possible to have an Android phone without any proprietary Google software components, thanks to Android being open source.
Same with Fuchsia - its license should allow to make a fully FOSS privacy-respecting variant, and maybe it would be something I could recommend to my friends or family to replace Windows on their desktop for example (if Fuchsia becomes popular enough). At least such option exists, unlike in the case of Windows, so I don't see Fuchsia as a bad thing.
I'm not familiar enough with Android internals, but as I understood from a quick research this means that it will be possible now to upgrade the Android Runtime through the Play Store (which was handled by phone manufacturers?). Is it a problem for distributions without the Play Store like GrapheneOS or LineageOS? Why?
I guess GNU Hurd [1], jokingly speaking, but correct from an architecture (ukernel) point of view.
The real community-driven alternative is Linux, which started and still is a monolithic kernel, but the multiple features it got along the years may make the distinction even less clear [2]. It seems it will also accept some Rust code in the future, so the difference may drop even in languages used. [3]
Redox OS is pretty cool, but without at least one big corporate sponsor it won't be able to amass the ecosystem needed to be viable for most use-cases. That said, I believe it's almost self-hosting now, so definitely a real OS that you can run software in today.
Why would anyone want to into this? From industry perspective it baffles me how Google divided an conquered not one but multiple platforms: (Android, Google TV, Google Auto).
From the user perspective I don't need another toy OS. I was able to develop Linux Kernel modules on my 486dx with 8MB of RAM. I was able to use excel, word on it.
Right now I have a mobile phone with better hardware than my work PC from only few years back (8GB RAM, 512GB UFS storage powerful multicore CPU). Still Android only allows me to click colourful buttons and simple apps, it has not progressed at all in the last decade.
Samsungs of the world, please come together, build a non-profit consortium and develop an open platform with real OS with full capabilities.
Today, instead of excitement, I am wondering how this thing is going to push me in some walled garden, how I will be tracked, how my data will be fetched and sold, what will be the trick used to move people away from free Web...
Maybe I am wrong, I hope I am wrong.