Well, I’d rather use it for Control. But maybe if keyboards would put Control where it belongs, next to Space (it should go Super Alt Control Space Control Alt Super), then it wouldn’t be necessary to have Control where most keyboards have Caps Lock.
Because of the frequency of use. Control is used almost all the time, in Windows, Linux & emacs. As such, it should go into the easiest-to-strike location, right next to the spacebar where the thumb can strike it in conjunction with other keys.
Alt/Meta is used less often, so it should receive the less-convenient spot. Alt should be used for less-frequently used functionality, and to modify Control (e.g. C-f moves forward one character; C-M-f moves forward one word).
Super should be used least of the three, and ideally would be reserved for OS-, desktop-environment– or window-manager–specific tasks, e.g. for switching windows are accessing an app chooser. Since it’s used less than either Alt or Control, it belongs in the least-convenient spot, far from the spacebar.
If we were really going to do things right, there’d be a pair of Hyper keys outboard of super, reserved for individual user assignment. But we don’t live in a perfect world.
I doubt the ABI chances have been solved with the /vendor partition. As I understand it, this change just allows for a clear separation between what is and isn’t the core Android system. Manufactures can still have binary blobs in /vendor and not release their customizations and plugins kept there. ABI breakage happens at the Kernel level, and can only be solved in the Android world if Google forced all manufactures to one standard Kernel for all devices.
The GPL is also something they can’t solve either. This is probably the saddest part of the Fuchsia project, and echos Google releasing Chrome after drumping so much money into Firefox. They support the OSS tool, but then dump them because they want their own control and licensing. Their new tool is still OSS, but with a license that’s better for them. I wrote about how companies embrace/use OSS a while back:
We’ve seen a large number of Google devices coming to market (tablets, phones, notebooks). I wouldn’t be surprised if they were on their way to an “Apple”-like hardware mode where we have a 3rd, proprietary, but fully integrated environment to choose from. MSFT has the same sort of model going, with the Surface line of things, so it could be that we have an all out war between MSFT and Google for the next generation of business machines. I mean, look at the product lines:
Office: Covered by both, with MSFT having the product to beat
Email/Calendaring/Collaboration/etc: Exchange / Sharepoint vs Apps for Business
Managed “IT” services: Windows Server (run yourself, with domains etc) vs. Apps for Business
Apple isn’t a threat to MSFT in this space, though it has a lot of similar, consumer grade, products.
Obviously, there’s a bootstrapping problem for Google here, but, I’m sure there’s nothing stopping the Fuchsia team from running a Dalvik VM, or making Android apps run seamlessly on it, and I’d fathom that that’s part of the plan for adoption, with Dart/Flutter being the answer to C#/.NET.
Google recently killed off Chrome Apps, so it seems that extending the Chromebook beyond running android apps, and Chrome Extensions (very limited as far as I can tell) will lead to an eventual death for the Chrome OS line of products.
So, you have the ability to take what you’ve learned from Chrome OS, integrate all the hosted “cloud” stuff seamlessly into a full feature operating system that has better native app abilities? Seems like a lot of potential to gain market share, especially, as they are doing so in the open, where “what’s this Fuchsia thing?” is being asked about, people can look at, play with it, and audit the design, source code, and, of course, write blog posts about how it’s broken. Basically, they’re in a really good position here, technically, and from a marketing standpoint. It markets itself! And jeesh! Think of all the baggage they are eliminating by starting fresh.
Black hats are salivating, and keeping track of all the errors that are being made in commits, just hoping that they become exploitable in some future, after aging a couple years without being touched….
See the linked article in the article about how Google likes to build two of everything. I figure it’s essentially a hedge. If it turns out to be awesome in some way that Linux can’t be, they can move to it. If it turns out they need to do something they can’t do on Linux, they have this other OS all ready to go. If it turns out that it doesn’t do anything as well as Linux-based systems already can, then they aren’t really out anything but some money and engineer time, which they have plenty of. Google likes to do this in a number of domains to ensure that they stay on top no matter which way the industry goes.
They have the money and time to do it? Or perhaps they are tired of trying to make the fragmented android / linux ecosystem work for them amd want to take a new approach they can fully control. Ui-wise I’m happy to see that it seems to have a functional out-of-the-box app launcher ala Kiss, though I guess any ui component will massively change in the future.
It’s not just me; this process is a bit weird, right? The network-based installation does make it easy to stream a fresh version of Fuchsia to the device, but it seems like a lot of work for purely development purposes. Plus, if you want to repeatedly put software on a piece of hardware, the transmission medium of choice is usually USB.
Errrrrrrrr, a fair amount of initial setup but way way way less work in the long run.
It is also very interesting that Flutter has native support for Fuchsia. I really love this framework and it is currently my favorite way of developing apps for Android. Granted it is still early days for the framework.
I’d be interested in seeing what they’re doing here that’s e.g. not simply a LCD reimplementation of Unixy ideas. If all they wanted was a stable ABI and a friendlier license, they could just use a *BSD as the base; instead, it seems they’re rebuilding. Perhaps this is just NIH thing, but if it means they spend a bunch of smart people’s time on new ideas, I’m pretty open.
Finally a proper use of the caps lock key:
Well, I’d rather use it for Control. But maybe if keyboards would put Control where it belongs, next to Space (it should go Super Alt Control Space Control Alt Super), then it wouldn’t be necessary to have Control where most keyboards have Caps Lock.
I always map Caps Locks to Ctrl, so whenever I’m on someone else’s laptop I keep flipping into caps when I mean to copy/paste/break/etc.
What’s the premise for “should” here?
Because of the frequency of use. Control is used almost all the time, in Windows, Linux & emacs. As such, it should go into the easiest-to-strike location, right next to the spacebar where the thumb can strike it in conjunction with other keys.
Alt/Meta is used less often, so it should receive the less-convenient spot. Alt should be used for less-frequently used functionality, and to modify Control (e.g. C-f moves forward one character; C-M-f moves forward one word).
Super should be used least of the three, and ideally would be reserved for OS-, desktop-environment– or window-manager–specific tasks, e.g. for switching windows are accessing an app chooser. Since it’s used less than either Alt or Control, it belongs in the least-convenient spot, far from the spacebar.
If we were really going to do things right, there’d be a pair of Hyper keys outboard of super, reserved for individual user assignment. But we don’t live in a perfect world.
as a vi user, i would have said “use escape” but then remembered my caps-lock key is remapped to escape.
I’m curious as to Google’s motivation for Fuschia: what does it offer over Linux?
They’ll be able to use a license other than the GPL and have a stable ABI. This would please a lot of device manufacturers
Isn’t the Linux ABI somewhat stable? Isn’t that a sticking point for Linus, not breaking userspace?
The syscall interface is stable. The ABI for kernel modules/drivers is not.
If this is the main objective, didn’t they “solve” this with Android’s new hardware abstraction layer?
Rebuilding from the ground up seems like a huge amount of work when we can build up piecemeal stuff pretty nicely
I doubt the ABI chances have been solved with the /vendor partition. As I understand it, this change just allows for a clear separation between what is and isn’t the core Android system. Manufactures can still have binary blobs in /vendor and not release their customizations and plugins kept there. ABI breakage happens at the Kernel level, and can only be solved in the Android world if Google forced all manufactures to one standard Kernel for all devices.
The GPL is also something they can’t solve either. This is probably the saddest part of the Fuchsia project, and echos Google releasing Chrome after drumping so much money into Firefox. They support the OSS tool, but then dump them because they want their own control and licensing. Their new tool is still OSS, but with a license that’s better for them. I wrote about how companies embrace/use OSS a while back:
http://penguindreams.org/blog/the-philosophy-of-open-source-in-community-and-enterprise-software/
We’ve seen a large number of Google devices coming to market (tablets, phones, notebooks). I wouldn’t be surprised if they were on their way to an “Apple”-like hardware mode where we have a 3rd, proprietary, but fully integrated environment to choose from. MSFT has the same sort of model going, with the Surface line of things, so it could be that we have an all out war between MSFT and Google for the next generation of business machines. I mean, look at the product lines:
Apple isn’t a threat to MSFT in this space, though it has a lot of similar, consumer grade, products.
Obviously, there’s a bootstrapping problem for Google here, but, I’m sure there’s nothing stopping the Fuchsia team from running a Dalvik VM, or making Android apps run seamlessly on it, and I’d fathom that that’s part of the plan for adoption, with Dart/Flutter being the answer to C#/.NET.
Google recently killed off Chrome Apps, so it seems that extending the Chromebook beyond running android apps, and Chrome Extensions (very limited as far as I can tell) will lead to an eventual death for the Chrome OS line of products.
So, you have the ability to take what you’ve learned from Chrome OS, integrate all the hosted “cloud” stuff seamlessly into a full feature operating system that has better native app abilities? Seems like a lot of potential to gain market share, especially, as they are doing so in the open, where “what’s this Fuchsia thing?” is being asked about, people can look at, play with it, and audit the design, source code, and, of course, write blog posts about how it’s broken. Basically, they’re in a really good position here, technically, and from a marketing standpoint. It markets itself! And jeesh! Think of all the baggage they are eliminating by starting fresh.
Black hats are salivating, and keeping track of all the errors that are being made in commits, just hoping that they become exploitable in some future, after aging a couple years without being touched….
See the linked article in the article about how Google likes to build two of everything. I figure it’s essentially a hedge. If it turns out to be awesome in some way that Linux can’t be, they can move to it. If it turns out they need to do something they can’t do on Linux, they have this other OS all ready to go. If it turns out that it doesn’t do anything as well as Linux-based systems already can, then they aren’t really out anything but some money and engineer time, which they have plenty of. Google likes to do this in a number of domains to ensure that they stay on top no matter which way the industry goes.
Linux has accumulated a lot of irrelevant features (attack surface) over time?
They have the money and time to do it? Or perhaps they are tired of trying to make the fragmented android / linux ecosystem work for them amd want to take a new approach they can fully control. Ui-wise I’m happy to see that it seems to have a functional out-of-the-box app launcher ala Kiss, though I guess any ui component will massively change in the future.
Errrrrrrrr, a fair amount of initial setup but way way way less work in the long run.
It is also very interesting that Flutter has native support for Fuchsia. I really love this framework and it is currently my favorite way of developing apps for Android. Granted it is still early days for the framework.
I’d be interested in seeing what they’re doing here that’s e.g. not simply a LCD reimplementation of Unixy ideas. If all they wanted was a stable ABI and a friendlier license, they could just use a *BSD as the base; instead, it seems they’re rebuilding. Perhaps this is just NIH thing, but if it means they spend a bunch of smart people’s time on new ideas, I’m pretty open.