Does Microsoft use this for anything in production?
> LIKQ is powering Academic Graph Search API, which is part of Microsoft Cognitive Services.
121–130 of 192 posts
Does Microsoft use this for anything in production?
> LIKQ is powering Academic Graph Search API, which is part of Microsoft Cognitive Services.
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…
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.
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/
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.
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...
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/…
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.
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…
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.