SoylentNews is people
SoylentNews
Microsoft may have sidelined its effort to allow Android apps to run unmodified on Windows 10. But Windows users have been able to do this on PCs for over a year at very low cost - thanks to a cunning virtualization project.
DuOS, or AmiDuOS, is an emulator that provides excellent compatibility for Android apps on the desktop. And perhaps unsurprisingly it survived an interesting history of tussles with Google before staking its claim.
[...] If this is the shape of things to come, it poses some intriguing strategic questions for Microsoft. Microsoft risks losing the developer client base that it has been able to take for granted for two decades. Windows has a huge app gap, and is marginal in mobile and tablets. Ideally, Microsoft wants developers to write to a Universal API that is compatible across Windows PCs and ARM-based mobile devices such as tablets and phones. But the apps have already been written, in Java, for Android.
Credit: Posted by RS Wood on comp.misc
Related: Steve Balmer: Use Android to Save Windows Phone
(Score: 3, Interesting) by RamiK on Tuesday December 08 2015, @09:48PM
Android should have been more of a true Linux OS...But no, we get stuck with a crappy tablet OS with an outdated JVM concept.
I was up there with you on the Inferno points right up until you started championing a broken 1970s UNIX kernel design over the broken 1990s Jvm.
Google did nothing wrong with Android. They set out to write a commercial OS for throwaway cellular phones and they did just that. They never tried to design a good general purpose OS that solves any particular problems other then the market demands for a familiar, free OS that OEMs can use without getting in bed with MS or Apple and newbee programmers can write silly games and GUIs to without any investments in skill-sets others then the ones they already picked up in collage.
As for what Google could be doing... Well, they can't make EE engineers start using anything but C to write kernel drivers. They can't make coders use anything but Javascript to write GUIs for*. So, the best they can do now is fill-in the gaps by making sure Golang is gluing the two together in a cross-platform, back/front end model. Once there, they could transition a whole user-land across different kernels and systems without upsetting anyone except Microsoft's share holders... But that's a concern for another day ;)
* Fun trivia: the GUIs in Fallout 4 are written in Actionscript. And they're written in that familiar Javascript quality assurance. Whereby, key-bindings are hard-coded and you can crush the engine by doing certain actions out-of-order or just hitting the buttons too fast. There's even exploits for buying and selling items in a specific order that provide the players with unlimited game currency...
compiling...
(Score: 3, Informative) by LoRdTAW on Wednesday December 09 2015, @12:04AM
I'm sure it was an honest mistake on your part but if you see that I'm advocating Inferno, I damn well know Unix is broken. You are forgiven ;-)
Wait... By saying broken 1970's Unix kernel design, do you mean the POSIX standard/Unix architecture or something else pertaining to the Linux kernel design itself? And the JVM is not a kernel so you can't really compare the two other than they both kinda suck. I'm not calling you ignorant. I'm just missing your point.
The reason I wished for a GNU/Linux OS was to allow the GNU/Linux & Android projects to be developed in parallel. I suppose my original point was why can't we have our cake and eat it too? Meaning, why can't we have a simple to use phone OS with the underpinnings of a commonly used, hackable OS? Then we can develop applications on a much more common ground with the only difference being CPU arch and GUI. The rest could be standard OSS libs and tools. Running Android apps On linux would be much easier and the two could form a new Desktop/mobile ecosystem(buzzword alert!). I know, I know. Wishful thinking. right? Is it too much to ask for a proper sshfs client or shell for that matter? Unix might suck but we are bloody stuck with it.
My only wish is Google opens an operating system research laboratory, puts Rob Pike in charge of it and they reexamine the ideas behind Plan 9 and Inferno and make something that will save us from the Apple, MS and Red Hat OS kludges.
(Score: 2) by RamiK on Wednesday December 09 2015, @03:23AM
Wait... By saying broken 1970's Unix kernel design, do you mean the POSIX standard/Unix architecture or something else pertaining to the Linux kernel design itself?
I'm referring to the laundry list of what Plan 9 is that Linux isn't. It's an outdated, broken design and I'm personally not comfortable advocating it over an equally broken design such as the Jvm.
And the JVM is not a kernel so you can't really compare the two
As far as I'm concerned, any layer of abstraction aiming at isolating the next layer \ it's users from the previous layer \ hardware is comparable. The Jvm is comparable to the linux kernel since they both manage memory and aim to abstract hardware using their own metaphor. Some programming language could even fit this classification provided their memory management model was designed isolated from the OS rather than a part of it. So, C won't fit since it's runtime largely depends on what the OS and architecture is doing but Go and Java do.
The reason I wished for a GNU/Linux OS was to allow the GNU/Linux & Android projects to be developed in parallel.
So, like, Windows 8? Look, we have Qt, Gnome and EFL on linux just to name a few... A dozen more specialty libraries times a dozen more cases. "developed in parallel" would just have meant more libraries not the same libraries.
My only wish is Google opens an operating system research laboratory, puts Rob Pike in charge of it and they reexamine the ideas behind Plan 9 and Inferno and make something that will save us from the Apple, MS and Red Hat OS kludges.
Plan 9 was pretty much the end all to be all OS. It's only flaw was the overbearing weight of 9P. It's one thing to decide internally on keeping all your kernel and network interfaces exposed to the user-land in a uniform, network-transparent protocol. But, it's a whole other thing to start weaving it into the user-land to the point your text editor has it's windows and menus mountable in the file system and it was the only way to customize it.
Sometimes, I dare say, It was nearly as bad as Java: My joke of the day was that I'll need to write a ./ctl/in, a ./out and a ./err in an "hello world" for it to be a proper Plan 9 software :D
Regardless, Go fits the bills here. It's it's own little OS. Complete with it's own concurrency and memory management. I don't care if my runtime targets hardware or software defined logics nowadays anyhow considering Intel has Micro-controllers embedded in the motherboard and secret magic sauce firmwares ROMs burned right in the CPU.
Why, even our x86 assembly is broken apart into machine code and not in a 1:1 fashion since there are thousands of possible machine instruction. And later, it's further broken apart into even lower level RISC like microcode... So, Go's on-top of the OS's drivers but still native code seems quite minimal and reasonable when compared to all of that and the Jvm.
compiling...
(Score: 2) by LoRdTAW on Wednesday December 09 2015, @05:44PM
I like your thinking. Believe me, I know we have a software bloat problem. A really big one. My suggesting Linux was merely one of practicality, something that would be taken seriously by the current industry.
As for plan9, someone needs to make it happen. The only second system that did the inverse of second system effect, it was actually much, much simpler and fixed the broken unix model.
Ever read up on the styx on a brick project? Really neat stuff right there. 9p really can do it all. Wish my phone exposed its file system via 9p so I can view my pictures via phone/camera/pictures/ instead of the idiotic MTP protocol, another fuking brain dead protocol that masquerades as a storage device but isnt. FFS, How many file protocols do we need? Then my phone connects via USB to my car radio but I can't control the music player unless it's the app that comes with the dumb radio. Why? yet another fucking protocol. Just expose the audio and player controls as files via 9p and your done. At that point everything can be controlled by shell scripts if need be. What is the current song playing: cat phone/musicplayer/playing. Skip to next track: echo next_track > phone/musicplayer/control. Need the audio stream: mediaplayer phone/audio/audio_stream. Want to adjust the 3 band EQ: echo "3, -1, 4" > phone/musicplayer/eq. Want to save the eq setting: cat phone/musicplayer/eq > fav_eq.txt. Bought an IP security camera and want to see the video: vlc ipcamera1/video. And the list of what it can solve goes on and on and on. Might not cover every case. But can certainly cover a vast majority of little day to day things that drive me up the wall needing a plethora of mutually incompatible libraries that need linking and software to use them. The computing world would be a much better place. Sorry for the rant but I'm tired of the shitty software world.