Don't worry, by the time it is complete and mature, it will be complex and full of quirks too.
I'm not convinced that even Google has the resources to build something like that successfully. Except perhaps if they target a very specific use case.
I'm not convinced that even Google has the resources to build something like that successfully. Except perhaps if they target a very specific use case.
Google CAN'T do something small, simple and elegant, partly for the very reason that they're too big.
Had Go been released at AT&T and it would have shared the same fate as Limbo.
This is beyond belief. What companies are using Go with the hopes of being acquired by Google? Does anyone honestly believe that Google's acquisitions teams know or care about programming languages? Any business that acquires companies on that basis is doomed to failure, as is any company that hopes to be acquired on that basis.
So, quite a lot if that experience is anything to go by.
They obliged with a full crate of first generation Motorola phones, each one preloaded with a 30 day free Verizon plan. Every person who took that class got one, and surely all of them made it back into the school's hands at the end of the quarter.
(I'm not sure how many people actually ever compiled and executed any go binaries on arm that year; we all learned Go, and it was a great class! But as far as the class, the phones were completely unnecessary. I think that they did make a more relevant class where the phones were able to be used again the year after that.)
Systems does mean that. There are 2 broad categories of software you can write. One is software that provides a service to the user directly. That is an application. The other kind is software that provides a service to applications. That's systems software. Do you think there's something wrong with this notion? It's pretty well accepted over the decades:
I'm certain you can find complexities and bloat in there too, if you look.
OS X has tons of weird quirks and compatibility mindfucks going back to their transition from OS 9 (all those .DS_Store and _filename files for "resource forks")
Backwards compatibility is #1 reason for increasing complexity. Apple is sometimes good in cutting away compatibility for the sake of cleaning up, but there are still weird issues poking now and then
hell the whole NSEverything is a compatibility thing with NextStep, which is long dead.
Which is the worst of both worlds.
It might not be backwards compatible but from a developers perspective it is nice to be able to reuse old knowledge.
I think Apple has been much better than MS or Linux in continously modernizing and upgrading what they have. On windows and linux things tend to become dead ends as new flashy APIs appear.
Sure old win32 and motif apps might still run but nobody really develops using these APIs anymore.
On windows I first use win32, then MFC, then it was WinForms. Then all of that got depricated and we got WPF, silverlight and then I sort of lost track of what was going on. Meanwhile on Linux people used tcl/tk for GUIs early on. And there was motif, wxeindows. KDE and Gnome went through several full rewrites.
If we look at MacOS X as the modern version of NeXTSTEP the core technology has been remarkable stable.
Sure they have broken compatibility plenty of times but the principles and API are at their core the same.
One just needs to look into the right spot.
I don't have much experience with them but I think VxWorks and QNX are good examples of simpler OSs. I do have some experience with Minix3 and it is certainly one. I guess the BSDs stand somewhere in the middle.
In theory it makes me wonder if iphone's storage is slightly faster than the latest galaxy or if the process by which one loads an iphone app is slightly faster/more efficient than the one by which an android app is loaded or if the tiny selection of apps the reviewer picked are just better optimized for iphone. Nobody smoked anyone and nothing of note was learned by anyone. So much so that I wonder why you bothered to watch said link or paste it here.
I said half an OS because its built on technologies like linux and java not because its half assed even though it is.
Certain apps were slower to load on the Samsung device. Additionally, the Samsung device encoded the 4K siginificantly video faster and took round 1 by 14 seconds and round 2 by 16 seconds.
>In theory it makes me wonder if iphone's storage is slightly faster than the latest galaxy or if the process by which one loads an iphone app is slightly faster/more efficient than the one by which an android app is loaded or if the tiny selection of apps the reviewer picked are just better optimized for iphone. Nobody smoked anyone and nothing of note was learned by anyone. So much so that I wonder why you bothered to watch said link or paste it here.
The iPhone X has faster storage and a significantly faster SoC. A 30 second win by the Samsung phone is what I could call getting smoked.
>I said half an OS because its built on technologies like linux and java not because its half assed even though it is.
And iOS is was a decedent of MacOS which itself is a decedent of NeXTSTEP. It also uses a language 11 years older than Java. So it sounds like iOS also meets your criteria of being "half assed".
Didn't Mach start out as a replacement kernel for BSD? Building a Unix on top of Mach is like building a truck over truck chassis.
In late 80's/early 90's there were various projects that attemted to build unix on top of that as true micro kernel architecture with separate servers for each system service. Performance of such design was horrible and there are two things that resulted from that that are still somewhat relevant: running whole BSD/SysV kernel as Mach task, which today means OS X and Tru64 (at the time both systems had same origin as both are implementations of OSF Unix) and just ignoring the problem which is approach taken by GNU/Hurd.
Worth noting that's because Mach IPC is extremely slow, an order of magnitude slower than L4 family.
Next's VP of Software Engineering, Avie Tevanian, was one of the Mach project leads. Richard Rashid, who lead the Mach project ended up running Microsoft Research's worldwide operations.
Their work on a virtual memory subsystem got rolled back into BSD.
https://en.wikipedia.org/wiki/Mach_(kernel)
The Computer History Museum has an interesting long form interview with Avie:
Part 1: https://www.youtube.com/watch?v=vwCdKU9uYnE Part 2: https://www.youtube.com/watch?v=NtpIFrOGTHk