Google’s not-so-secret new OS

Post by flukus » Thu, Feb 16, 2017, 2:05 AM UTC

e12e wrote: post #182

goldenchrome wrote: post #123

Earlier quoted context omitted.

Phones and desktops are completely different form factors with different constraints. Running an Android app on Windows would be a horrible experience.

I don't know. I think many "tablet" apps would work fine on the Surface 4 (if they got scaling right). I still think touch screens is the future - also on desktops (there either in tablet form or "drafting table" form). I think editors more like acme and less like vim might rise up. Along with new input types like the power bar and surface wheel.

Post by drewg123 » Thu, Feb 16, 2017, 2:31 AM UTC

kiallmacinnes wrote: post #518

drewg123 wrote: post #441

Earlier quoted context omitted.

"Linux's lack of a driver ABI." RedHat Enterprise Linux actually solved this with their kABI. This allows vendors to ship binary driver RPMs for kernels in the same RHEL major version (eg, RHEL 4, RHEL 5, etc). However, this entails a major effort on the part of RHEL, as it forces them to carefully backport improvements from upstream in a slow and careful way, so as to avoid breaking binary compatibility. The RHEL kA…

So, taking a tangent here... If you fork, and that includes backporting security fixes upstream won't, you need a new version. Obviously, you can't just take .28, apply a fix, and call it .29... But you have to do something.. ideally something that indicates binary ABI compat with upstream .28, (so software vendors can just decide, your .28, you get .28 features. Maybe something like SemVer needs a model for versioni…

Post by i336_ » Thu, Feb 16, 2017, 3:04 AM UTC

izacus wrote: post #415

bb101 wrote: post #255

Earlier quoted context omitted.

I wonder how much of the performance issues are related to Android being Java vs iOS being C? The old Blackberry OS was also implemented in Java and I remember well the spinning hourglass and the odd pauses in its UI.

Not much, modern devices and modern Android runtime is fast enough that GC and Java aren't a problem. There's bunch of other issues around though, mostly coming from the fact that devices use problematic and slow I/O controllers, apps do blocking I/O and OEMs add bloat and misconfigure behaviour of the OS to prioritize their services at the expense of apps you're actually using. But bad I/O is the killer (e.g. fun th…

Post by flukus » Thu, Feb 16, 2017, 3:44 AM UTC

Certhas wrote: post #448

flukus wrote: post #363

Earlier quoted context omitted.

> There's one design decision in Linux that makes this slightly harder than it needs to be in this situation: Linux's lack of a driver ABI. This is just an excuse. The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. We see the exact same results on certain OS's that do have stable ABI's. You've probably made a transaction recently on a device that uses an o…

So if we had a stable ABI the manufacturer writes a driver, ships, and forgets about it, and the driver just continues working when I update the OS. Thus, with what you describe, the argument can be made that the Linux driver model doesn't appropriately take into consideration the incentives and needs of hardware manufacturers.

Post by lmm » Thu, Feb 16, 2017, 8:34 AM UTC

flukus wrote: post #536

lmm wrote: post #423

Earlier quoted context omitted.

> The reality is the manufacturers still have the mentality that once something is sold their responsibility ends. Not my experience. I have three hardware devices that worked on Windows, Linux and FreeBSD 5-10 years ago, and now only work on Windows and FreeBSD. (Amusingly enough one of them is a windows CE device)

Isn't that another example of manufacturers not supporting their hardware? Are the windows/FreeBSD drivers still maintained or do they just still work?