Live data from Hacker News

Microsoft open-sources Graph Engine

graphengine.io

121–130 of 192 posts

Re: Microsoft open-sources Graph Engine

#123

Earlier quoted context omitted.

Not specific to GraphEngine, but you could store all meta-data about the device separate from the time-series itself. The composite metric name (key?) would then include the measurement name and the entity name (device name in this case).

That is one possible solution. But, for queries we will need some kind of JOIN at runtime. I do store the entity data separately in a transactional row store. For analytical queries, we use a column store. For this, I have to include the entity data (context) for each fired event. The whole Compute & Storage semantics are different. If only, we had a persistent data-aware compute & storage graph engine that supported…

Storing time-series in a columnar format (blobs o time-values) and entity data in row format sounds good to me.

If you look at data historians (PI et al), that's how they lay out the data: metrics storage is separate from the asset store, or Asset Framework as it's called.

Re: Microsoft open-sources Graph Engine

#124
post #44

Interesting - Linux Foundation with IBM, Google and others announced last week JanusGraph [0]. Janus provides optional persistent storage option also. What are the good use cases for these ? [0] http://janusgraph.org/

There is also people doing distributed machine learning with other systems: http://myrighttocode.org/blog/artificial%20intelligence/part...

Re: Microsoft open-sources Graph Engine

#125
post #74

Earlier quoted context omitted.

Does that include developing/compiling GE (and GE apps) on Linux/BSD?

Yes, we will continue working on bringing both the core runtime and the toolchain (TSL compiler, data management tools, more computation modules, language bindings etc.) online and ready for the *nix world.

http://youtubedoubler.com/kkPq

Re: Microsoft open-sources Graph Engine

#126
Firefox gives an SSL error:

www.graphengine.io uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER

And SSL Labs shows the site is vulnerable to the POODLE attack (and has an incomplete cert chain):

https://www.ssllabs.com/ssltest/analyze.html?d=www.graphengi...

Re: Microsoft open-sources Graph Engine

#127
post #111

Earlier quoted context omitted.

> I guess you don't use I think he was talking about programming the apps, not just using them. From the looks of it (after reading the comments here and nothing more, so excuse me if I'm completely wrong) it may be a real inconvenience from the dev perspective: I can somehow understand the "no 127.0.0.1 communication" policy, but I expect to communicate with a spawned process via stdin/stdout pipes.

You have the same issue in other sandbox models. Old style IPC leads to information leaks and is another attack vector. You cannot do that on Android for example, Google explicitly removed UNIX V IPC from their Linux fork. You are expected to use TCP/IP or Android RPCs, assuming the app has android.permission.INTERNET permission. Also using fork/exec() on Android isn't a good idea, http://stackoverflow.com/questions/…

> You have the same issue in other sandbox models.

Would what PC-BSD does with jails qualify as an exception?

> So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile sandbox models.

Now I'm curious - weren't people complaining when the other sandbox systems were designed/created? It really looks a bit inconvenient (I'm referring to the SO explanation of what Android Chrome does), so I'd expect some reasonable opposition. It could be that with time people got used to the restrictions and don't complain that often anymore.

To be honest, I like PC-BSD model, but that's probably not a good idea for platforms where the resources are constrained. It works ok on the desktop, though - I didn't work with PC-BSD itself for long, but I did the same with Docker on Linux (for web browsers) and the performance hit wasn't that bad IIRC.

Re: Microsoft open-sources Graph Engine

#128

Earlier quoted context omitted.

> I love Windows but I seriously will not touch UWP until they loosen up the sandbox restrictions so that I can do regular IPC with a win32 desktop app. The whole reason for the UWP sandboxing is to make it so that users can confidently install UWP applications with some assurances that it isn't spyware/malware/blackmailware that will take over their PC or steal their personal information. UWP is Microsoft's answer t…

> They aren't going to just dump it all because you and a few others find the priviledge model inconvenient. > But, no, it won't allow unchecked IPC... And I'm not asking for either. How about just giving the user a simple permission like they have for allowing UWP apps to access your Microphone, Camera, Bluetooth, etc? Seems a little silly that my UWP app can access everything on my network except for my own darn co…

[deleted]

Re: Microsoft open-sources Graph Engine

#129
post #110

Earlier quoted context omitted.

This shouldn't be downvoted. There is definitely at the minimum Microsoft employee vote brigading at this point. HN needs to start making upvotes, downvotes, and time of vote public.

Accusations of astroturfing or shillage without evidence are a serious breach of civility on HN. Since you've done it before and ignored our request to stop, we've banned your account. All: both astroturfing and groundless insinuation thereof are against HN's rules. For more, see https://news.ycombinator.com/item?id=13610097 upthread.

Check the time of votes for users that vote on Microsoft opensource vs normal time of day of votes for those users. You'll notice a bit of difference. But yeah, I really need to get off this site anyway. Its just sad at this point.
Post reply on HN