News for hackers. Stuff that matters.
Re:Docker and Microsoft partner to drive adoption of distrib... by joelthelion on Wednesday October 15, 2014 @10:19AM (#8458516)
Out of curiosity, why are your applications running on Windows?
Re:Docker and Microsoft partner to drive adoption of distrib... by amarraja on Wednesday October 15, 2014 @10:28AM (#8458575)
Current client is a Windows/.NET shop. There are some parts which use Linux, but that is more infrastructure, all the apps run Windows -- and rather well too!
Re:Docker and Microsoft partner to drive adoption of distrib... by yohanatan on Wednesday October 15, 2014 @02:47PM (#8460807)
Since when do applications 'run' operating systems?
Re:Docker and Microsoft partner to drive adoption of distrib... by observer1101 on Wednesday October 15, 2014 @04:03PM (#8461350)
Since at least 1999 or so when VMware showed up :)
Re:Docker and Microsoft partner to drive adoption of distrib... by yohanatan on Wednesday October 15, 2014 @05:19PM (#8461831)
:) VMWare is an application that runs operating systems, yes.

But a) original poster is talking about a web application; not a virtual machine or hypervisor and b) VMWare itself still requires an underlying operating system-- one could argue that this case is actually an operating system running another operating system with a thin adapter layer in between (i.e., the VMWare application).

Re:Docker and Microsoft partner to drive adoption of distrib... by frostmatthew on Wednesday October 15, 2014 @06:36PM (#8462230)
> VMWare itself still requires an underlying operating system

VMware is a company, not a product - the product you're [probably?] referring to is ESX[1], which does not require an underlying OS - it's a Type 1 hypervisor (it runs on bare metal).

[1] https://en.wikipedia.org/wiki/VMware_ESX

Re:Docker and Microsoft partner to drive adoption of distrib... by yohanatan on Wednesday October 15, 2014 @11:34PM (#8463230)
I was actually referring to 'VMWare Workstation'. This company apparently has a habit of putting the company name inside all of its product names. That doesn't preclude one from referring to each its product offerings by short name.
Re:Docker and Microsoft partner to drive adoption of distrib... by SideburnsOfDoom on Thursday October 16, 2014 @04:42AM (#8463980)
The point that observer1101 is almost certainly trying to make is that "Apps run operating systems" in the sense that deploying an app oten entails creating a VM for the sole or partial purpose of hosting that app. The app dictates the OS, not vice versa any more. And observer1101 is right - that trend may have had a minor beginning in 1999, but it has grown very strong since. Azure or AWS is basically the business of running operating systems in VMs on demand for apps.
Re:Docker and Microsoft partner to drive adoption of distrib... by yohanatan on Thursday October 16, 2014 @04:13PM (#8467378)
Yes, I fully understand and agree with all of that. However, I think it is still not accurate to say that apps run operating systems. More accurate to say that apps embed operating systems or are themselves bundled with operating systems (such that they can run on bare metal). And, MirageOS (http://www.openmirage.org/) takes this concept to its logical conclusion.
Re:Docker and Microsoft partner to drive adoption of distrib... by amarraja on Wednesday October 15, 2014 @05:47PM (#8462001)
Haha, my bad. They run on Windows
Re:Docker and Microsoft partner to drive adoption of distrib... by SEJeff on Thursday October 16, 2014 @07:43PM (#8468564)
Clearly you've never heard of MirageOS or erlangonxen. Look them up. The app is the operating system in those.
Re:Docker and Microsoft partner to drive adoption of distrib... by yohanatan on Thursday October 16, 2014 @11:14PM (#8469253)
You're wrong on both counts. I mentioned MirageOS in the other thread, in fact. MirageOS merely links in the minimum portion of the operating system required to support a particular application. I still would not consider that to be 'the app running the operating system'; i.e., if you examine the application's call stack (with a kernel debugger and OS symbols) at any point in time, there's still going to be a lot of 'OS' stuff below the main entry point to the application.