Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s not-so-secret new OS

techspecs.blog

Post reply on HN
Print view View original

541–550 of 561 posts

Re: Google’s not-so-secret new OS

#541

Post by e12e »

flukus wrote: post #531
e12e wrote: post #182

Earlier quoted context omitted.

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.

What does acme do to help on touch screens? I while ago I toyed around creating a vim keyboard for android, instead of having a virtual keyboard popup it show commands/motions instead. I abandoned the idea, but if text edition on a touch screen ever becomes feasible then I think the virtual keyboard has to go.

> What does acme do to help on touch screens?

Unlike emacs or vim, acme leverages the mouse/gui for powerful editing - and I believe (multi)touch screens have the potential to be better guis than than screen+mouse. For one thing mice generally utilise at most three fingers and one hand - and IMNHO while eg blender/photoshop combine mouse and keyboard - the combination is awkward and not very intuitive.

I think (but am far from certain) that acme is a more promising approach.

Re: Google’s not-so-secret new OS

#542

Post by regularfry »

flukus wrote: post #374
regularfry wrote: post #283

Earlier quoted context omitted.

It's why I got out of the MS ecosystem. I bought quite heavily into WPF for the Vista launch, and it was obvious that was a dead end within a couple of years. Not only that, but I could see exactly the same thing happening to all the other neat stuff I was planning to look into at the same time. That was not the way to encourage my long-term membership of the Visual Studio clan.

> and it was obvious that was a dead end within a couple of years As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.

I was specifically doing 3D stuff in WPF. That end of things didn't get much love after the initial release (or if it did, it came too late for me).

Re: Google’s not-so-secret new OS

#543

Post by douche »

regularfry wrote: post #542
flukus wrote: post #374

Earlier quoted context omitted.

> and it was obvious that was a dead end within a couple of years As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.

I was specifically doing 3D stuff in WPF. That end of things didn't get much love after the initial release (or if it did, it came too late for me).

How were you doing it? It's definitely possible to embed DirectX in a WPF control, and not particularly hard to do, with SlimDX or SharpDX, in my experience.

Re: Google’s not-so-secret new OS

#544

Post by leoc »

jpfr wrote: post #118
vii wrote: post #53

It's awesome that Google is doing this and in public too https://fuchsia.googlesource.com/ Unfortunately, the hard part of an operating system isn't in a cool API and a rendering demo. It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. People don't like dropped frames when they plug in USB :) Writing devi…

Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise... [1] https://en.wikipedia.org/wiki/Rump_kernel

> Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1].

"Linux is a free set of buggy device drivers." https://news.ycombinator.com/item?id=8470638 .

Re: Google’s not-so-secret new OS

#545

Post by digi_owl »

leoc wrote: post #544
jpfr wrote: post #118

Earlier quoted context omitted.

Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise... [1] https://en.wikipedia.org/wiki/Rump_kernel

> Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1]. "Linux is a free set of buggy device drivers." https://news.ycombinator.com/item?id=8470638 .

More and more it seems to be the prevailing attitude even within the Linux "community".

Just observe how systemd is overruling and countermanding Linux behavior any chance it gets.

Re: Google’s not-so-secret new OS

#546

Post by ferdbold »

nialv7 wrote: post #430
MarkMc wrote: post #74

It bothers me that Google does not seem particularly interested in doing the one thing that would make their Android platform absolutely dominant: Allow Chrome to run Android apps on Mac and Windows. Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a li…

> have a relatively simple way to develop software which runs on 99% of laptops and 85% of smartphones and tablets. We already do. It's called a webpage.

You could argue that webpages were never meant to host the kind of rich experiences and workflows native applications are known for. We just made it that way through years and years of momentum.

Re: Google’s not-so-secret new OS

#547

Post by josefx »

K0SM0S wrote: post #502
jonathanstrange wrote: post #321

Earlier quoted context omitted.

The problem is not technical and never was, it's that Apple and Microsoft would do anything to maintain an 'application barrier' that makes genuine cross-platform coding as hard and inconvenient as possible. It's all about developer lock-in and control over the customer, even more today than it used to be in the 90s.

How would you caracterize Microsoft's open-sourcing of the .NET stack, support to run it on Windows and RHEL (actually support to run RHEL on Azure), VS code universal electron app, the whole Office 365 paradigm, and multiple apps like Remote? It seems to me that the 'new' Microsoft (since Satya Nadella took leadership) is changing their closed/proprietary stance on many topics. Not everything of course, they still h…

> How would you caracterize Microsoft's open-sourcing of the .NET stack

Giving anyone not on Windows a second rate experience? Core as the name says provides only a subset of the Windows .Net framework and most .Net code in the wild is written with the implicit assumption that it runs on the Windows framework.

> VS code universal electron app

Instead of making their main IDE a proof of concept for .Net Core they wrote a Web3.50/NodeJS IDE. I am very sensitive to high latency IDEs so that is something I wont ever touch.

> the whole Office 365 paradigm

Trying to keep up with the competition, Google Docs ring a bell?

> since Satya Nadella took leadership

Nadella 2014. Linux on Azure 2012. Office 365 2011. Mono based on Microsoft’s promise not to sue 2004. Open sourcing parts of .Net is really the only thing you can assign to Nadella, everything else was still done by the good old triple E leadership.

Re: Google’s not-so-secret new OS

#548

Post by mncharity »

saghm wrote: post #171
mncharity wrote: post #68

> I don’t see the average garbage-collected language using a virtual machine allowing for a target higher than 60fps realistically. But... " average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust. Nor Javascript. I get greater than 60 fps with my existing Vive three.js WebVR-ish electron/chromium linux stack. Even on an old laptop with integrated gra…

> But... "average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust. I'm curious; what would be an example of something you would describe as an "average garbage collected language using a virtual machine"? Java would certainly be the first language I'd think of for that description.

In addition to the 2 nice previous answers (though I'd not include CPython myself, as writing high-performance CPython means writing/using C libraries; and note that Lua and LuaJIT are different)...

I italicized "average", and wouldn't include Java, because most languages are very small efforts, and thus are different than the top few. A person-century or person-kiloyear of optimization effort has an impact. Observations that "implementations of strategy X generally have characteristic Q" can be true, but there's a hidden context there of "severely resource-limited implementations of X".

But two caveats:

Sometimes you are trapped. In CPython and PyPy (but not in Jython or IronPython), parallelism remains defined by the GIL.

Language implementation tooling sucks less than it used to. Now even toy languages have JIT and rich compilation infrastructure.

Aside: In the late 80's, before ARPA was hit by Bush I, project managers had a great deal of autonomy. There was discussion of "what more neat things could we do to accelerate progress?" One observation was that JIT expertise was highly localized, and we could either wait many years for it to slowly spread, or pay someone to stand on people's desks and catalyze its being written up. But that kind of micro-grant didn't yet exist, and time ran out on creating it. Society chose option 1, but a human generation has now passed, and we finally have accessible JIT infrastructure. So, yay?

(In fairness, note autonomy and "old boy network"ness was a less happy thing for potential researchers at other than the few main research institutions. Some change was needed, it's just not clear it required societally critical tech to remain largely unfunded for decades. We don't even have a (language) wiki. Though even national science education improvement efforts have failed (but oh so close) to attempt one.)

Re: Google’s not-so-secret new OS

#549

Post by regularfry »

douche wrote: post #543
regularfry wrote: post #542

Earlier quoted context omitted.

I was specifically doing 3D stuff in WPF. That end of things didn't get much love after the initial release (or if it did, it came too late for me).

How were you doing it? It's definitely possible to embed DirectX in a WPF control, and not particularly hard to do, with SlimDX or SharpDX, in my experience.

Declarative 3D data in XAML, not touching DirectX directly at all. Viewport3D at the root, then doing the right magic to get the sort order of the objects right (working around the built-in logic, in other words).

Re: Google’s not-so-secret new OS

#550

Post by dfox »

josefx wrote: post #524
dfox wrote: post #481

Earlier quoted context omitted.

And the Metal plaf was the least ugly of the three that were originally shipped with JVM (other two tried to match how AWT would look on Windows and Unix). But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that. One thing that strikes me as weird is that almost any widget set that does it's own drawing or even just it's own a…

> But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that. A quick check of wikipedia backs my memory, the Java classes were just a thin wrapper around the native components. AWT was mostly bad because it was limited, it does not even have a Table. > even the basic look because various UI components use wrong size, are placed…

The part about sizing being wrong was not that much about AWT (although IIRC it also has this problem, at least on Unix, where it looks decidedly non-motif) as about just about any non-native toolkit that tries to look native. Windows does not have layout manager, but has API for getting preferred sizes for various low-level UI parts (in Windows 3.1 small part of of this was even user configurable).
Post reply on HN