Microsoft open-sources Graph Engine(graphengine.io) |
Microsoft open-sources Graph Engine(graphengine.io) |
Then don't buy from those people. Simple
[1] https://www.graphengine.io/docs/manual/index.html#what-is-ge
MS is on a roll. My bias since 1996 is being eroded with each OSS release they have, and multi-platform targeted support.
I started using VSCode regularly as my main Rust IDE, and I feel dirty for liking it. It's seemless across macOS and Linux.
Doubt it.
In my personal opinion, they're just playing catch up and trying to grab a piece of the pie in the Server space that opensource have been gobbling up.
Linux got web server, cloud, scientific computing, big data (hadoop, spark, etc..), etc...
I believe they're releasing these open source so they can get people on their Azure cloud and get people into their microsoft ecosystem instead. They're emulating what makes Linux so popular, a good ecosystem and also opensource software.
I do not think they will give up Window for free or even opensource at all.
They was willing to lose the internet for desktop. Their mentality was everything goes through the desktop. Google and the internet proved them wrong and made app OS agnostic via webapp. They neglected search engine for desktop and Google ate it up. That's how crazy it is.
There's also a theory of how they dominated Gaming via DirectX so they can keep their OS popular. I doubt they would give up DirectX and gaming lead via opensource.
I think it's a good strategy but I personally love open source ecosystem much more than Microsoft and have trust issues with them in the past.
They're just playing catch up just like Bing vs Google, IE vs Mozilla, etc.. There's still money to be made even though there are clear leader in each space Microsoft neglected.
It does have something to do with SQL Server vs the world -- and that is life as usual at Microsoft.
Microsoft had a big leadership role in XML standardization at the W3C but has had little to do with RDF. (ex. Oracle contains a forward-chaining triple store optimized for geospatial work, SQL Server does not.)
The Microsoft SQL server team would naturally oppose any effort to make a competing database. They've tried to deep six the JET engine that powers Microsoft Access because (i) people want access, and (ii) Microsoft SQL server Express/Compact/whatever is not an effective replacement.
Thus, there is not a lot of room under Microsoft's umbrella for a competitive project, but "yet another open source graph database" is not seen as a threat.
Why not?
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. You can't even send an HTTP request to a little node.js Web server running on your desktop right now. Fuck that. I'm not buying into it.
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 to years of criticism they received for the way process permissions work on Windows. They aren't going to just dump it all because you and a few others find the priviledge model inconvenient.
> You can't even send an HTTP request to a little node.js Web server running on your desktop right now.
If your node.js web server was network accessible you could. But, no, it won't allow unchecked IPC as that directly defeats the whole point of sandboxing to begin with.
Personally I haven't used UWP much either, but that has nothing to do with sandboxing and everything to do with poor performance and UI issues (e.g. window controls, built in UI elements, etc). I still find the Windows 10 UWP Calculator horrible to use, it was a MASSIVE downgrade over the old one.
Moreover, win32 desktop apps can use the AppService mechanism exposed by UWP apps (but cannot host an AppService themselves, just connect to UWP-hosted AppServices)
One day my GNU/Linux installs will also only run sandboxed applications.
I guess you don't use either an iOS or Android device, because you cannot do regular UNIX IPC on them.
I assume that Microsoft is not going to be naive enough to do the same.
IMO Microsoft's interest in openness revolves around remaining a viable option in the cloud era. They need to protect their investment in the .NET ecosystem and MS-centric development workflow, which means making it easy for people to run .NET programs on *nix-based VPSes and containers.
The kernel? The more platforms the better?
* Intellectual Property.
* The concern about opening a can of security vulnerabailities and the associated negative press, is probably on their minds.
Still, I wish they would open source the components they can, if only as a gesture.
It is wishful thinking to believe that "they want to be more open, but just can't". They are open sourcing only where they are weak, and that's just not true of the OS (or Office or SQL Server, for that matter).
They are evolving the framework to be faster and cross-platform based on external pressures but in the last few years they have managed to overtake several of the other language/framework options to again be one of the top choices for new projects.
They aren't catching up, they're leading the way.
While I still haven't bought an MS product since 1996, I don't think I have a problem with using their OSS. I see it as supporting companies when they do the right thing.
Honestly Apple's tightening up of the control on their platform in recent years, like requiring LLVM bitcode with apps on some of their devices which only works if it's Apple LLVM generated bitcode, has me swinging the opposite direction from them.
It would go a long way for my perseption of Apple if they either drop the LLVM bitcode requirement, or at least standardize on a non-proprietary version.
What are the good use cases for these ?
Is there a better way to this ?
Ideally, we should persist the Object Graph directly without any data conversion. I see a difference in - How we compute and How we store data.
tracking goods (amazon uses a gigantic graph database to track everything in its warehouses throughout the goods' lifecycle)
network analysis
Could you elaborate on this? Are there any articles/papers on this topic?
I'd like to see the Spanner+Cyc GIS-capable global distributed real-time graph engine with FPGA accelerated OLAP support MS Research is probably sitting on, because we can almost / pretty-much hack that together with OSS now.
I welcome open source, eventually, I believe that it will eat commercial software, if the right economic incentives are in place. Microsoft may be signaling this to the market.
Never Forget.
Microsoft has changed over the years and is not the same company in 1997. It used to hate FOSS projects and now they contribute to them. MSFT used to hate Linux and now they embrace it adding Ubuntu support to Windows 10.
Sure never forget, but if you see changes for the better, learn how to forgive. If they go back to the way they were in 1997, just speak up about it.
Microsoft adapted to tablets with Surface and they seem to do well for artists using pressure sensitive pens.
Here is the github page:
*Edit: checking the site on my phone now and it seems to load, pretty poorly designed site though IMO, unbalanced layout but at least it loads now.
EDIT: I've created a wiki page for computational graphs. https://en.wikipedia.org/wiki/Computational_Graph. Add your input.
> LIKQ is powering Academic Graph Search API, which is part of Microsoft Cognitive Services.
"Fool me once..." I guess, or as we say in France "Cold water scares the scalded cat".
Does it do streaming data such as Flink or Storm? Or is it batch-optimized?
What languages does the compute engine support?
https://github.com/Microsoft/GraphEngine/blob/master/LICENSE...
Actual astroturfing, when it occurs, is an abuse of HN that we crack down hard on. Defending this community against gaming and abuse is a huge priority for us. Any user who thinks they might be seeing it happen on HN should email us right away (hn@ycombinator.com) so we can investigate.
Imaginary astroturfing—the bug that causes some users to be certain that those who disagree with them can only be nefarious shills because otherwise the pure reason of their own point of view would be fully accepted—is also an abuse of HN. This one is orders of magnitude more common, and it is poison. It eats away the heart of civil, substantive discourse, the assumption of good faith on the part of others.
Therefore we ban astroturfers, and we also ban users who accuse others of astroturfing or shilling without evidence. An opposing view does not count as evidence, and playing this card as a rhetorical device in an argument breaks the HN guidelines.
We detached this subthread from https://news.ycombinator.com/item?id=13607640 and marked it off-topic.
All: both astroturfing and groundless insinuation thereof are against HN's rules. For more, see https://news.ycombinator.com/item?id=13610097 upthread.
HN really needs to do something about Microsoft's vote manipulation - it's becoming quite blatant at this point.
> Recall that in our general definition a feed-forward neural network is a computational graph whose nodes are computing units and whose directed edges transmit numerical information from node to node.
> Each computing unit is capable of evaluating a single primitive function of its input. In fact the network represents a chain of function compositions which transfor m an input to an output vector (called a pattern).
From: https://page.mi.fu-berlin.de/rojas/neural/chapter/K7.pdf (1996)
Another ancestor would be the Data-Flow paradigm:
> .. programming paradigm that internally represents applications as a directed graph, similarly to a dataflow diagram. Applications are represented as a set of nodes (also called blocks) with input and/or output ports in them. These nodes can either be sources, sinks or processing blocks to the information flowing in the system. Nodes are connected by directed edges that define the flow of information between them.
From: https://paginas.fe.up.pt/~prodei/dsie12/papers/paper_17.pdf (2012)
I'm somewhat aware but it seems like the idea of a computational graph is the most generic computational idea I can think of and I'm surprised it's not more explored.
> Another ancestor would be the Data-Flow paradigm:
Oh yeah, data flow is definitely another one.
Automata can be represented as graphs- that's the main idea. When you look at the typical automaton diagram with states and transitions- that's a graph (with states as vertices and transitions as edges).
I think the confusion arises from the fact that, while automata can be represented as graphs, graphs can represent a much broader array of processes and objects (e.g. belief networks or semantic networks). I guess you can represent pretty much anything as a graph.
So "computational graph" as I understand it, just stresses the point that what is represented is a unit of computation (a.k.a. an automaton a.k.a. a grammar a.k.a. a language etc. etc.) rather than some other kind of graph.
Exactly. I think that the fact that the nodes represent a unit of computation is enough for it to be different from normal graphs I think.
EDIT: Slightly more useful link - https://www.graphengine.io/docs/manual/TSL/MPProtocol.html#h...
Thanks
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 transactional & analytical workloads.
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.
Just because Microsoft is no longer the monopoly-du-jour, doesn't mean they aren't still a monopoly...
Just because they have been making (successful) forays into open-source, does not mean they won't still fiercely protect (with whatever means at their disposal) their monopoly cash cows (Windows and Office).
The "standartization" of Office Open XML wasn't all that long ago, after all (ECMA in 2006, ISO in 2008).
And yet on the server Microsoft does not have a monopoly.
Consider that the main reason Microsoft has a profitable business selling server software is because of their desktop monopolies through many diverse paths.
Sure, I'll consider doing so when an Office user can set OpenOffice as the default format, or at least when they open an OpenOffice file, that Office will save that file as OpenOffice by default.
I guess this comes down to Microsoft failing basic verification.
You can set OpenOffice or LibreOffice for document default types in Windows.
I like Libreoffice because it does more file standards than MS Office. Someone emailed a Word Perfect document to a group my wife was in and MS Office could not open it. So I used LibreOffice to open it and convert it to Doc format for my wife so her group can use it.
TL/DR: Badly.
OK, it looks like it has been possible to set the default file types to Open Document Formats for several years, I just hadn't noticed.
But I naively thought that with that capability would come support for more MS Office features when saving in ODF, or at least that features not supported by MS Office in ODF would be disabled or hidden if ODF is set as the default to keep users from shooting themselves in the foot.
How silly of me:
https://support.office.com/en-us/article/Differences-between...
https://support.office.com/en-us/article/Differences-between...
https://support.office.com/en-us/article/Supported-features-...
Basically, even if you set ODF as the default, if you use a feature that is not supported (such as putting a table in a presentation slide) everything looks fine until you hit save. Saving the file saves a downgraded version of your work (a table on a slide is converted to an image), and you probably only get one warning pop-up that says "some features may not be supported". I bet the still-open file continues to look and act fine. No, the problems with the saved file are only apparent much later.
Imagine the user's surprise when they re-open their presentation deck file (remember, created and saved in MS Office) the next day and many aspects of their work on that presentation were never saved or have been downgraded to uselessness...
And that doesn't even address the fact that many of these "unsupported" features are ones that ODF actually supports perfectly well, but that Microsoft just hasn't implemented for saving in ODF.
My, what an exceptionally lovely user experience that is. It just oozes good faith and sincerity of effort toward interoperability, doesn't it?
I'm only familiar with one domain of enterprise software and that's ERP software. I'd like to see a %age number for "vast majority" but let's just say I'm struggling to think of ERP software based on the .NET stack outside of the Microsoft products (which are not exactly a success story). SAP is based on Java/ABAP, Oracle is based on Java, Salesforce is mostly Java (and those already cover >50% of the worldwide market). I think Infor uses both Java and .NET but maybe someone else can chime in. About the only .NET shop I can think of is IFS.
Zero of the FLOSS ERPs that I know use .NET for obvious reasons (mostly Java as well, some Python and the occasional Perl etc.). Maybe some will in the future but who knows. I'd also argue that most new ERP will likely be written with a "web-first" mindset which might mean .NET but is more likely to mean more traditional web stacks (imo)
Microsoft products are certainly used all over the place (most notably SQL Server in SAP products) but I think for this sub domain Java is king. Since ERP is a decent chunk of enterprise software I don't think it's likely that a "vast majority" of enterprise software is indeed based on the .NET stack.
That's the issue. I'm not talking about ERP (or any other) software offered by vendors. Many corporations build their in-house line of business/ERP/backend apps in .NET.
What data are you basing this statement on? I'm genuinely curious because the vast majority of indicators I've seen clearly show that Java is by far the #1 enterprise language. Greenfield projects are probably far more likely to choose .Net but for now, there is a hell of a lot more important legacy Java code that will never be practical to port.
I believe that C#/F# are the future of managed enterprise languages (Roslyn, CoreCLR/FX, and quite soon RyuJIT are far superior to Java equivalents, imo) but I highly doubt their adoption is anywhere near Java.
I can't say that there is a disparity. If anything, the parts that are documented are usually better documented in the Windows world, and there are very good books about most components. (To be fair I never read a book on anything unix apart from Lion's). There is a large amount of stuff online for either, but I often have the feeling that correct examples are less frequently found for, esp., Linux.
And unlike some other platforms what is written tends to match reality, and stay relevant for a long time (for better or for worse).
ASTs?!
AppService is largely useless for IPC between UWP and Win32 since the UWP app can't initiate a request to the Win32 app.
Another thing you can't do, which is really annoying: UWP won't let your code start an external process and use standard i/o pipes to communicate with it.
The only possibility is to use files for IPC and you'd have to have your Win32 app listen for changes in the file or directory, then open it up and read the data. However UWP can't listen for changes in those same files, so it's a real PITA.
All of the options are listed here - http://stackoverflow.com/questions/12341707/communication-be...
You can also use a loopback exemption, but it requires installing a fake root certificate (no thanks!) - http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Conf...
or
It can via the ContentChanged event see this example:
http://stackoverflow.com/questions/39737147/how-can-i-watch-...
> Give it a try. You can't send requests to `localhost` or `127.0.0.1` at all.
Luckily getting the local IP address is easy enough from UWP: http://stackoverflow.com/questions/33770429/how-do-i-find-th...
That will work since it is treated like all other network traffic. localhost and 127.0.0.1 are considered privildged routes since you can bypass the firewall and exploit local processes to escalate.
As it turns out, pretty much everyone on the thread is right. Localhost is special on a network: it's the only machine that that you're guaranteed actually exists, and is therefore qualified as a high-value target for the bad guys.
I hadn't heard about the printer creating a local HTTP server, but it sure doesn't surprise me one bit.
At the same time, we could identify companies with real products that we wanted in the WinRT ecosystem but where the company already had an architecture that assumed that they could connect to localhost. It was a very painful call, but in the end we decided that security was more important than these companies.
We decided against a checkbox because users already have too many checkboxes, and mostly don't understand any of them.
If knowing the current local IP address gives you access to localhost, that would be a bug. More likely, you see that it works because you're running in a debugger, where the access to localhost is restriction isn't currently enforced.
And for goodness sakes everyone -- stop restricting yourself to IPv4! IPv6 is a real and growing thing! We made a bunch of fixes in Windows just so that the WinRT network APIs would work perfectly without ever knowing or caring whether you were going over IPv4 or IPv6.
Using an external IP address is a terrible solution for communicating with another process on the same machine. As soon as you disconnect from the network, it will stop working.
The Win32 app can connect to the UWP AppService, on PC you can also bundle a desktop app in your package and start it when the UWP app is launched. This desktop app can then act as a bridge between your UWP app and the "legacy" world, offloading the "dirty" stuff to the slave desktop app. It actually works, I used this for getting the taskbar to blink in my side-project for a messaging app.
is there anything like this, but working the other way around? I want to be able to forbid ordinary Win32 programs from accessing loopback/localhost.
I believe that their next strategy is to release a full Windows OS (with Win32) that runs on ARM which lets Win32 apps run via an emulator. In this environment, Win32 apps will most likely run like crap and as a matter of course Microsoft is going to keep pushing everybody (developers and users) toward the model that they think will make them the most money.
It's really no problem for my career because I stopped exclusively using Microsoft's tech years ago and I'm comfortable using Linux or a Mac if necessary (but really, I can't stand their UI and I think Apple is even worse than Microsoft in many, many ways). I just like the Windows UI the best and I'd like to be able to build stuff for it in the future....but not if they are working towards taking away my freedom to control my own computer.
Windows RT was about as popular as Windows 1.0. I think Microsoft views the upcoming ARM-based "Cloud Windows" (whatever the branding is going to be) as the second iteration of this idea, and hopes to really gain traction a few years later.
The RT was a stopgap measure to try and force windows onto a Architecture it wasn't ready for. Most of it didn't work at all which is why it failed.
I don't care, as I would rather see a modern sanboxed OO ABI make Win32 drink beers with Carbon.
It was a time limited free upgrade for people who already had a valid windows license. I don't think it it was free.
I think eventually Windows being source available is possible but I doubt it will be free in a meaningful way.
WSL is a elimination of the Linux user mode programming environment. The fact that that requires implementing Linux kernel functionality is simply an artifact of the lack of a more modular design (or really any up front design) in Linux.
Curiously the recommended syscall mechanism on x86 is by calling __kernel_vsyscall in the vDSO. If everybody did that then you could just make your own loader with your own custom vDSO that could implement the syscalls in userspace. However sometimes (especially statically built) programs still makes syscall directly with int 80h, which are slow to trap in userspace or may not even be possible depending on the os.
Now it would have been fantastic if calling through the vDSO had simply been the only documented way of doing a syscall on x86_64, but the kernel developers at that time decided not to do that, so now on x86_64 the syscall instruction is always used directly, and we can't even trap that on any x86_64 OS because most of the time all that happens is either some unrelated syscall is executed, or an error is returned from the kernel back to the calling process without any traps.
Yes, proper security means you will be inconvenienced. In the same way that you would be inconvenienced if your bank called you to confirm that $10000 wire you didn't initiate. It's inconvenient that you have to take a call and resolve the issue, but it's a hell of a lot better than finding out at some indeterminate point in the future that $10000 is missing from your account.
Sudo is also (relatively) easy to configure: "this command line can be run under sudo by anybody", "this command must not be run under sudo even if they know their password", etc.
UAC is always-in-your-face about everything, often unexpectedly - it hijacks your desktops at inopportune times, and there's no way to tell it "Yes, this software can do this again for the next 15 minutes without asking me again".
UAC is very, very far from being the graphical popup equivalent of sudo. If it had been, people would not have complained as much. (Someone always complains. But in the case of UAC, most of the complaints are justified)
"UAC is always-in-your-face about everything..."
Not true: UAC only pops up for apps that need to access a file/registry key, etc. that affects system-wide behavior
"... often unexpectedly - it hijacks your desktops at inopportune times ..."
This isn't true: UAC pops up precisely when an app is launched that needs to access/modify a system-wide resource. If you're running apps that OFTEN need to access system-wide resources, you could choose to run them as admin and avoid the UAC pop-ups ... while also hoping that those apps are not malicious or over-enthusiastic about "helping".
"and there's no way to tell it "Yes, this software can do this again for the next 15 minutes without asking me again"."
There kinda is - just run the app as Admin. It'll then run with admin rights until you close it.
Of course, without specific examples of what you see as erroneous behavior, I've posted what are, I am sure, inadequate responses to your specific issues. If you'd like to share you specifc issues, I am sure we could have a more fruitful dialog and who knows, I may be able to carry your case internally to see if we can improve things in future OS releases (no guarantees here other than my trying my best).
That said, it was ironic that people complained about security in a Windows release.
Until you can run power tools (compilers, IDE's, web servers, system tweakers) as UWP apps it will be inferior to win32.
This is why no one is investing in UWP apps, you don't want to spend months/years developing something only to find out that the app is crippled because of a limitation you weren't aware of.
> 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 computer via localhost, doesn't it?
Unfortunately for historical reasons localhost (127.0.0.1) are treated almost like a named pipe. Meaning a LOT of Win32 (and UNIX-style) applications treat data over that path as "trusted."
For one specific example, I've used a HP driver that installs a local webserver for no good reason, and if you can send a specially crafted request it will execute that request in the SYSTEM context. All you need is localhost access and knowledge to pull it off (this is not exploitable remotely).
A lot of software has been designed with the assumption that localhost is trusted and they have therefore used it for IPC. This is exactly what you're attempting to do too. But let me ask you this, what happens if a third party UWP application tries to use your localhost backdoor? Does it allow UWP malware? How are you going to verify that only YOUR UWP application connects to your Node.js instance?
File IPC allows you to limit it to just your UWP application because presumably the file will be within that UWP application's unique storage block. It might be a pain but at least the ultimate result is secure.
Why do that? Indeed one could just call Windows 10 API from its existing client [1], but it seems that you would miss out on the easy install/update from the Store and other benefits a UWP app provides.
[1] https://blogs.windows.com/buildingapps/2017/01/25/calling-wi...
Also take a look at our Command-line blog (https://blogs.msdn.microsoft.com/commandline) for LOTS more about Console & Bash/WSL, including the page where I pull together our various learning resources into one place: https://blogs.msdn.microsoft.com/commandline/learn-about-bas...
Regarding roadmap, to be honest, we don't really have one, but we do have a primary mission which we're laser-focused on: Make Windows Subsystem for Linux able to run the vast majority of tools developers need to get their work done.
We've taken a somewhat unusual, but HIGHLY valuable approach of building features based almost entirely on feedback from the community. We prioritize syscall implementation based on the frequency with which we see failures due to missing, incomplete, or incorrect syscalls. This way, we focus on delivering the most bang for the buck.
This said, now that our syscall coverage is starting to edge towards covering the majority of mainstream dev tools, we're starting to look at more strategic, features including improving disk perf & support for networking, device, etc.
We'll be publishing more details in a few weeks on our blog above (and, of course via https://twitter.com/richturn_ms) on where we're going to invest effort beyond Creators Update. Look forward to hearing from y'all ;)
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.
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/16179062/using-exec-with-...
Which I doubt that would still work on Android 7 by the way.
On iDevices, the same applies.
https://developer.apple.com/library/content/documentation/Se...
So people are complaining about Microsoft adopting what is already best practices on the other desktop/mobile 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.
How did you decide that it was too many? Also, if users don't understand any of them, what's the big deal about one more checkbox?
This was a bad decision IMO and it's the kind of thing that is causing nobody to use UWP. There are so many stories out there of people trying to use UWP for their project and then turning back when they realize how restricted the sandbox is.
Honestly, doesn't it seem a bit absurd that UWP apps can talk to anything else on my network except for Win32 processes on my own computer?
If Windows Phone were a thing, I'd probably be building UWP apps already. Mobile devices are the only place where I accept these types of restrictions, but it's mostly because I have no choice. If Microsoft comes out with a phone that can run Win32 apps, I'd switch to that in a heartbeat because then I could get full Chrome with extensions and I'd be able to do things like run uBlock, quick javascript switcher and all my other favorite extensions. (Yay freedom!)
Most other checkbox security choices at least can be explained. A word processor probably doesn't have any legitimate reason to use Bluetooth (for example), and therefore a customer has a chance of making a reasonable choice.
But for localhost access -- my word, there's no rhyme or reason for it. As a simple example, I worked on a statistical package back in the 90's (yay RS/1!) that was implemented as two programs on Windows. One was the GUI client and the other the statistical server. There's nothing about "statistics" that obviously screams, "must have localhost permissions" :-)
Ordinary person argument is flawed. So called ordinary person doesnt even know what a network card is.
As for the other sandbox models, the only people I have seen complaining thus far, has been in sites like HN, I never heard any of our customers complaining about those restrictions, or caring about them.
> Curiously the recommended syscall mechanism on x86 is by calling __kernel_vsyscall in the vDSO.
There are times when this doesn't work. Syscall resumption and cancellation come to mind. Also, __kernel_vsyscall is a hack to make fast syscalls work on the awful 32-bit x86 architecture, not a nice feature.
> it would have been fantastic if calling through the vDSO had simply been the only documented way of doing a syscall on x86_64
There is no __kernel_vsyscall or similar feature on x86_64.
> we can't even trap that on any x86_64 OS
You can on Linux using seccomp.
It's a pretty nice feature in the context of being able to make compatibility layers on other OS'ses in userspace which was the discussion here. Or would be if it was always used. Why doesn't it work for syscall resumption and cancellation?
> There is no __kernel_vsyscall or similar feature on x86_64.
Yes that was exactly what I was complaining about.
> You can on Linux using seccomp.
Yes but why would I want to make a linux compatibility layer on linux?
For resumption, a signal that interrupts a resumable syscall points RIP to an explicit int 80 instruction in the vDSO. This behavior would be a bit unfriendly to emulate.
For cancellation, the only good implementation of cancellation that I'm aware of (musl's) relies on syscalls being an actual atomic instruction so that a signal handler can tell whether a syscall actually happened. __kernel_vsyscall is an opaque function and can't be used like this.
> Yes but why would I want to make a linux compatibility layer on linux?
For sandboxing? For experimentation? Or how about to make a compatibility layer emulating something else that runs on Linux?