3 ms·
Why?
by cheez 9y ago
Why?
- orf 9y agoWhy not? Have we reached the peak OS development, and any more is pointless?
- trimbo 9y agoI think peak OS development was in the 70s and 80s. Every hardware vendor also had their own OS, or several. The System V OSes were just different enough to be annoying. To name a few: UNICOS, NeXTStep, HP-UX, RSTS, ULTRIX, VMS, AIX, SunOS, Solaris, IRIX, A/UX, MacOS, ProDOS, Amiga OS.
- rmusial 9y agoLinux isn't capabilities based, or real time by default. Google likes permissive licenses. Android, while good, was a knee-jerk by Google in reaction to the iPhone. If you've got the resources of Google, why not try to build something in house that scratches some long standing itches and at the same time get ownership over the OS that could power everything from your phones to laptops?
- tziki 9y agoAndroid was in development far before iPhone was released.
- vvanders 9y agoYeah, and Danger was doing a lot of interesting stuff in the space as well. They were the first to do push based email and IM in a context outside of business AFAIK.
- drewvolpe 9y agoThe original version of Android looked like and worked like a Blackberry: small screen with a physical keyboard and a D pad for navigation (no touch control). When the iPhone was announced in 2007, they realized that on-screen keyboards and multi-touch control were the future, so they did a complete redesign, moving to an interface similar to the iPhone. Here's a quote from one of their engineers talking about the iPhone announcement: “As a consumer I was blown away. I wanted [an iPhone] immediately. But as a Google engineer I thought ‘We’re going to have to start over’” Chris DeSalvo said. “What we had suddenly looked so… nineties. It’s just one of those things that are obvious when you see it.” http://bgr.com/2013/12/19/original-iphone-android-story/ http://bgr.com/2013/12/19/original-iphone-android-story/
- blinkingled 9y agoNothing to do with OP's point of Android being based on Linux even before the iPhone. [Every time this story is told, I like to remind - note how fast Google were able to pivot / adapt when Microsoft with their crazy resources and Engineering might took way longer. (Even beyond that MS had to change the way apps were developed for WP.) Fact is Google/Danger/Android were in a fundamentally good position mobile OS design wise way before the iPhone. After the iPhone - they looked at the possibilities of multi touch soft keyboard UI and were able to get there and surpass fairly fast.]
- addicted 9y agoTo be fair Google knew about the iPhone well before Microsoft did (they worked closely with Apple in the beginning for Maps and search). But even adjusting for that it took MS 3-4 years after the iPhone to just get Windows Phone 7 out, and that was also clearly a rushed release, because they had to throw everything out for Windows Phone 8.
- rmusial 9y agoCorrect, Google bought Android in 2005 but went back to the drawing board in 2007 when iPhone came out. Now Google has a chance to take some time and try some new things out.
- cma 9y agoThey didn't totally go back to the drawing board. Comparing with the original demo they mainly just added touch stuff. The first android phones still had the same blackberry-esque selection ball even though they also had added capacitive touch. I believe after rage from Jobs they left out multitouch zooming at first and did something double tap based, even though MS had done it before Apple (without capacitive) and Minority Report has shown it.
- bitmapbrother 9y agoIf you look at both devices you'll notice that Android essentially looked and operated the same. The only changes were to add additional support for touch screen devices such as the virtual keyboard. I would hardly call this going back to the drawing board. There was no need as they already had all of the software pieces in place.
- alecco 9y agoControl.
- Lutia 9y ago> Why? Not having to deal with Linux's refusal of maintaining a stable driver API and ABI for a start. The number one reason that stops Android from getting updates on smartphones is that hardware manufacturers don't want the burden of constantly making small changes to their proprietary drivers to follow new linux kernel changes, something that they don't have to worry about when they make drivers for, say, Windows PCs. Even Google's own phones, like the Nexus and Pixel, are stuck because of this. They receive updates faster than non-Google phones, but they do not receive more than 2 years of feature updates (with an additional year of security updates courtesy of Google backporting fixes from newer android builds to the older kernel). Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state.
- catern 9y ago>Fuchsia is not going to be burdened by Linux kernel dev policies of constantly breaking APIs and their requirement for driver developers to open source their stuff, obey the kernel coding preferences (like when they rejected AMD's driver because of the HAL) to get them mainlined so that they can finally be kept in a maintained state. And as a result, its drivers will be far lower quality and much less stable, and the system as a whole will pay the complexity cost of working around the awful code that hardware vendors churn out.
- quotemstr 9y ago> And as a result, its drivers will be far lower quality and much less stable I don't buy it. Windows provides stable driver ABIs and works just fine. A lot of the changes to the Linux driver API are gratuitous, and isolating driver development from the whims of the core won't actually hurt. If anything, a stable ABI will help, since a smaller, well-defined boundary between the kernel core and drivers allows for things like Vulkan-like validation layers, better debugging, better sandboxing, and even transparent thunking to userspace. Will some drivers be shitty? Of course. But many drivers won't be, and drivers will be less shitty overall when they can spend more time on being good drivers and less time dealing with GFP_FOOBAR becoming GFP_BARFOO. Conventional wisdom is that backward binary compatibility i some huge unreasonable burden. This conventional wisdom is wrong; if anything, maintaining a stable ABI imposes some discipline that focuses development effort and that forces you to modularize your system.