> or bundle up an ASP.NET app with an embedded server

You can do that today: http://docs.asp.net/en/latest/conceptual-overview/dotnetcore...

I have been reading about ASP.NET 5 with much interest, but I'll probably engage with it more seriously in six months or so. It was still pretty flaky when I tried to get an OS X environment up and running last week.

It's also a bit confusing whether this "Kestrel" embedded server is production-grade (like Golang, or the embedded server options for Spring Boot in the Java world)... or whether it's meant for development only (https://www.nuget.org/packages/Kestrel).

It's amazing that CoreCLR is coming to multiple platforms within the next year or so... but what IS the production deployment story for Linux going to be, seriously? What is the development story for OS X? (VS Code looks interesting, but surely they're going to have to port the "real" Visual Studio, right?)

Don't get me wrong, I'm not a naysayer! Since I've started exploring .NET, I've found C# to be an improved version of Java that I'd really like to work with. F# seems like a more coherent alternative to Scala. Documentation, availability of learning resources, and community friendliness are outstanding. Still, I'm not 100% convinced yet of the cross-platform reality living up to the extraordinary hype. It really is too soon to judge, but I'm definitely watching closely and believe that the next 6 to 12 months will be crucial.

There's a pretty interesting video of how the Office team uses C++ for their cross-platform efforts from CppCon 2014: https://www.youtube.com/watch?v=3HROqnw-nf4

I chuckled at this as well, so I filed an issue: https://github.com/ResearchKit/ResearchKit/issues/9

Should be fixed by now :)

PowerShell web access might be a good alternative: http://blogs.technet.com/b/askperf/archive/2012/11/05/window...

You don't need this. You just need Enter-PSSession [ipaddress], which allows you to interact with it like ssh. You need to enable powershell remoting first though.

Sort of. Enter-PSSession is backed by http or https [1] and is not as good as ssh. You can interact with PowerShell, but you can't interact with command-line programs launched from PS.

[1] Grep for "http" on this page: http://ss64.com/ps/enter-pssession.html

Most stuff I use have PS cmdlets so its not really an issue with me.

Yes, but only if both PCs are in the same domain. Getting PowerShell remoting to work in other environments requires a lot of configuration.

That's not true. I had it working over the internet, separate domains with public/private certs fairly easily.

I'd be interested in how you set it up, can you maybe share it somewhere?

Guides like https://wprogramming.wordpress.com/2011/07/11/remote-pssessi... don't seem "fairly easy" to me (that's why I said it requires a lot more configuration compared to Enter-PSSession when both parties are in the same domain).

There's a lot of waffle in that. If you actually look at the commands his asking you to enter, it isn't that much.

It's essentially, Enable-PSRemoting

And commands 1 to 3 in the following guide after Enable-PSRemoting. Try to ignore the waffle. You probably do want to to disable HTTP though.

http://www.sirchristian.net/blog/2013/03/11/using-powershell...

Trying to get SSH to work with certs can involve just as much or more stuff than that.

Maybe i'll write a super simple guide, just listing the bare commands, since the documentation/tutorials for powershell seem non-existent despite being pretty powerful..

If only that was cross platform like SSH is.

> The 2008 R2 development system we have needs to be rebooted every two week, due to Windows Updates [..]

Windows Updates are published once a month (except for very critical fixes), so I wonder how that is possible in your environment?

I'm a bit surprised that you don't seem to have an equivalent of the Handysignatur [0] (eID based on mobile phone) we have in Austria. It's getting more and more popular here, I guess because all you need is a mobile phone (who has a card reader after all?).

I find it incredibly convenient as it gives you immediate access to a growing list of e-government services [1], as well as signing PDFs and even things like a service for cancelling subscriptions online [2].

[0]: https://www.handy-signatur.at/hs2/home.aspx?language=en

[1]: https://www.handy-signatur.at/hs2/?site=infos/applications

[2]: http://www.online-kuendigen.at/

Correct me if I am wrong, but these services seem to be designed by the private sector for people to use, while the government implements it, where it makes sense. Meanwhile in Germany these services are designed by the government and implemented by the private sector and are therefore hopelessly outdated and bureaucratic.

Handy-signatur.at seems very convenient. You know, something must be wrong, when even Austria is moving faster than you ;-) I guess our most realistic bet to get something like this to work here is to count on the European Integration and wait for other systems to take over.

Because it is a lot of work and takes time to integrate the pieces MS open sourced :)

There are also a few cases where the code needs to be tweaked so it works correctly on Mono and the platforms it runs on.

No, it should run on the 4.5 profile just fine as backwards compatibility in the .NET APIs is very good.

Please note that this is still a draft and the .NET 2.0/3.5 assemblies will likely reappear as reference assemblies (i.e. containing only method signatures in IL, so you can build against those profiles but not run on them).

I added a note to the page to make this clear.

HN mods: can we get a "(draft)" note added to the submission title as well?

thanks Alex

There's already a PowerShell implementation for *nix: https://github.com/Pash-Project/Pash

It depends on what one's definition of "is" is. From the top of the link:

  An Open Source reimplementation of Windows 
  PowerShell, for Mono.

Mono is not *nix and PowerShell provides direct access to [nearly?] the entire Windows OS.

More from the project page:

  Status

  Alpha. This project is useful in certain constrained 
  applications, e.g. the NuGet Console in Xamarin Studio.

I just wanted to point out that there's nothing that inherently ties PowerShell to Windows (as expected, it's just a shell after all).

> PowerShell provides direct access to [nearly?] the entire Windows OS

PS has access to the .NET Framework which abstracts the OS APIs, not really to Windows directly.

There's also chatter that MS is already working on porting PowerShell to CoreCLR/.NET Core (the cross-plat, open-source version of .NET).

The abstraction layer is 'thinner' with Windows. With *nix we're dealing with serializing text with regexes or parsers or both coming in and deserializing to text on the way out.

It's a bit of a Turing tarpit when it comes to non-inherency.

Couple of points:

1. PowerShell reimplements older commands as aliases, e.g. ls is an alias for Get-ChildItem. You'd not be relying on existing shell functionality.

2. I don't know much about it, but wouldn't the upcoming Linux IPC improvements being made to support kdbus do away with needing to handle message passing in the way you describe?

PowerShell's get-childItem returns something on which get-methods can be called. How will the improved IPC create an easy systematic way of creating meaningful responses to "get-methods" system-wide?

dbus makes use of a type system to describe messages passed over it. kdbus is an implementation of dbus at the lowest level of the OS. The IPC improvements to support kdbus will be made at the kernel level. At a higher level, systemd will make use of these same processes, so it's not purely internal to the kernel. Therefore, there's no restriction on building an object-oriented approach to interfacing with the OS, which is what PowerShell uses.

Perhaps my logic is off, or my view is missing key information, but from my novice perspective it seems to make sense.

If you're interested, this page has more information on the type system used in dbus: http://dbus.freedesktop.org/doc/dbus-specification.html#type...

I think it would require rewriting a lot of existing 'nix code to achieve the level of OS integration that PowerShell provides for Windows, that's aside from the level of integration PowerShell has with many Windows applications [e.g. Office].

Microsoft has been integrating interprocess communication into Windows since DDE in version 2.0 almost 30 years ago. Then more than a decade of OLE. Then more than a decade of .NET. At this point it and the reflection it enables are baked into the toolchain and pretty much comes along for free on a project. *nix has many advantages but everybody rowing in the same direction is not among them.