Microsoft Support of PHP on Windows(news-web.php.net)
news-web.php.net
Microsoft Support of PHP on Windows
https://news-web.php.net/php.internals/110907
130 comments
I didn't even know that Microsoft were the ones creating the official PHP builds, and now that I do, I have no idea why they were in the first place. Especially not when PHP is software that's owned by a company that has had the resources to pay for normal CI/CD pretty much since PHP became big enough for Zend to hire staff.
The Microsoft guys did more than providing a CI. They cleaned up in regards to windows, whatever devs using Linux only did. Also they spent some time tuning the stack and continuous updates to the stack.
Zend had nice marketing, but had been only one contributor under many. Far from owning PHP.
Zend had nice marketing, but had been only one contributor under many. Far from owning PHP.
PHP was part of the IIS packaging and was marketed as a seamless integration option. That's probably why they worked on builds themselves.
> seamless integration option
My experience with PHP on Windows has been continously terrible. Was there some trick I missed? I have never seen any options in a vanilla IIS to enable PHP.
My experience with PHP on Windows has been continously terrible. Was there some trick I missed? I have never seen any options in a vanilla IIS to enable PHP.
I’ve been out of the PHP game for a decade or so but Windows, Apache, and PHP always worked no problem. Maybe Windows, IIS, and PHP is a more fickle stack?
I have a tough time believing Microsoft wasn't intending their special builds of Windows PHP for IIS.
That makes a lot more sense. And really just feels like Microsoft's current trend continuing: Dropping human-curated in-house QA and assistance in favor of automation and community contribution.
Not only that, with wsl2 on windows being in the mainline windows, developers have a very good alternative. I don't this is a coincidence... Running actual PHP servers on windows is a rarity, and not worth it to support it officially on Windows. Azure is able to run it all, so they don't really care anymore what platform you're targeting, as long as windows is a viable development platform, and Azure a potential deploy target.
This is about PHP For Windows [1], which build is currently supported by Microsoft. The original title "Microsoft Support of PHP on Windows" might be not sufficient but at least not inaccurate. (EDIT: The submission title has been updated since this post.)
[1] https://windows.php.net/
[1] https://windows.php.net/
Doesn't seem like a big deal. In this case I believe "MS support" is just compiling PHP for Windows and making them available at the PHP for Windows site.
I'm sure someone will pick this up. Or maybe it ends up being something like Apache where you have to find other places in the ecosystem which provide binaries for Windows. Or just compile the thing yourself.
https://windows.php.net/download/
There's vague Tweets here...
https://twitter.com/dalehirt/status/1281300688102801408
Seems Dale in moving on to different things and there's nobody to replace him?
You can see his Github activity here...
https://github.com/dalehhirt
ETA: Looks like a lot of this info has already been located and posted in the mentioned Reddit thread.
I'm sure someone will pick this up. Or maybe it ends up being something like Apache where you have to find other places in the ecosystem which provide binaries for Windows. Or just compile the thing yourself.
https://windows.php.net/download/
There's vague Tweets here...
https://twitter.com/dalehirt/status/1281300688102801408
Seems Dale in moving on to different things and there's nobody to replace him?
You can see his Github activity here...
https://github.com/dalehhirt
ETA: Looks like a lot of this info has already been located and posted in the mentioned Reddit thread.
Do people really use Windows as a production server for PHP? Most people I know use Windows as a dev machine, which I guess will still be supported.
Yes. In my experience, it usually comes down to "Our Windows admins don't know Linux, so it'll be easier for them to manage a server if it's running Windows!"
Except they never do, because they don't know PHP on Windows either and are afraid of breaking things, and the customer ends up with a PHP/Wordpress installation that is 4 years out of date. Luckily, most of those are internal-only apps, but it still sucks.
Except they never do, because they don't know PHP on Windows either and are afraid of breaking things, and the customer ends up with a PHP/Wordpress installation that is 4 years out of date. Luckily, most of those are internal-only apps, but it still sucks.
This is very accurate.
Where I used to work, we developed and supported a SaaS app based on PHP with PostgreSQL and Apache. We had two self-hosting customers who ran on Windows Server with SQL Server for the exact reasons mentioned, and they were our most troublesome customers. Performance tuning (and hence regular complaints that 'our' app was horribly slow) was a particular issue - mostly due to their admins' lack of relevant experience on both the stack...and Windows Server(!). The whole setup was a pain because we got so much flak, despite the premise of 'self-hosting' being that the customer had sufficient smarts to support the infrastructure and stack and we'd just support the functional and development aspects of the app.
One customer also had the system so locked down that for remote admin we had to connect to a jump box via VPN + RDP and then jump from that to the server with another RDP connection. Fetching large log files through that setup was a challenge.
Partly for our sanity, we persuaded one customer to let us migrate them to a Linux server; that went very well and really cut down on angst all round even though we then took responsibility for platform support.
Where I used to work, we developed and supported a SaaS app based on PHP with PostgreSQL and Apache. We had two self-hosting customers who ran on Windows Server with SQL Server for the exact reasons mentioned, and they were our most troublesome customers. Performance tuning (and hence regular complaints that 'our' app was horribly slow) was a particular issue - mostly due to their admins' lack of relevant experience on both the stack...and Windows Server(!). The whole setup was a pain because we got so much flak, despite the premise of 'self-hosting' being that the customer had sufficient smarts to support the infrastructure and stack and we'd just support the functional and development aspects of the app.
One customer also had the system so locked down that for remote admin we had to connect to a jump box via VPN + RDP and then jump from that to the server with another RDP connection. Fetching large log files through that setup was a challenge.
Partly for our sanity, we persuaded one customer to let us migrate them to a Linux server; that went very well and really cut down on angst all round even though we then took responsibility for platform support.
I don't blame the customer in these cases. The product shouldn't have been sold, or at least not sold with support, if the consumer was going deviate from build specs.
In my limited experience, this is the sales team saying 'anything' to get the sale.
In my limited experience, this is the sales team saying 'anything' to get the sale.
[deleted]
I've never seen a windows server in production used to run PHP, and I've been doing PHP dev for a long time.
Same here. I have been using PHP since it was publicly available after having used Perl for years (and even having written my own 'php' in perl before php; I did not know at the time that php was basically the same thing; a bunch of $source ~= s/(.)<\?(.)\?>(.*)/print $1;eval($2);print $1/isgm; kind of expressions) cgi-bin and even in heavy Windows shops end of the 90s, I have never seen it hosted on Windows.
I guess you have never worked for consultants that have government clients..lol.
I once seen a production server running a WordPress site on Windows.
The logic behind it was that the client had some other websites running on some .NET CMS (not .NET Core), so it made sense for them to run WordPress on the same one instead of getting another one.
The logic behind it was that the client had some other websites running on some .NET CMS (not .NET Core), so it made sense for them to run WordPress on the same one instead of getting another one.
Why not?
Manufacturing Execution Systems run on Windows; when virtually all your servers are Windows because of the apps you need to run, setting up a few Linux servers for minor apps for internal use only is not worth, so PHP in fast-CGI more under IIS is a very simple and effective solution.
Having support people with good expertise on both Windows and Linux is expensive, having 2 separate teams in expensive (if you need high uptime), especially when the ratio Windows to Linux is just 10:1 or 20:1. Keep it simple, run PHP on Windows.
EDIT: I forgot to mention the pseudo-SSO called Windows Integrated Authentication that works with just a few clicks on Windows, probably a lot more key presses (typing) in Linux.
Manufacturing Execution Systems run on Windows; when virtually all your servers are Windows because of the apps you need to run, setting up a few Linux servers for minor apps for internal use only is not worth, so PHP in fast-CGI more under IIS is a very simple and effective solution.
Having support people with good expertise on both Windows and Linux is expensive, having 2 separate teams in expensive (if you need high uptime), especially when the ratio Windows to Linux is just 10:1 or 20:1. Keep it simple, run PHP on Windows.
EDIT: I forgot to mention the pseudo-SSO called Windows Integrated Authentication that works with just a few clicks on Windows, probably a lot more key presses (typing) in Linux.
[deleted]
I have experience with using PHP on a Windows server, both with Apache and IIS.
With Apache, it's an unstable mess. IIS on the other hand works extremely well with PHP, we've had virtually 0 issues in more than 10 years using it for many different projects.
With Apache, it's an unstable mess. IIS on the other hand works extremely well with PHP, we've had virtually 0 issues in more than 10 years using it for many different projects.
My experiences are the polar opposite of yours, but you shouldn't be downvoted for being wrong. :)
I dont think he is entirely wrong I had similar experience except in my case whether I used IIS or Apache with PHP didnt matter as much with my particular apps.
IIS is fine if it works just like Windows apps generally are fine when they work its the odd time where it breaks that you are mystified about the whole thing.
IIS is fine if it works just like Windows apps generally are fine when they work its the odd time where it breaks that you are mystified about the whole thing.
If I had to run a PHP app at work today, it'd be on Windows. Why? Because no one app justifies the amount of additional maintenance overhead of supporting an additional operating system. If your entire IT workflow is built on Windows, it's really the only sane choice.
And no, it probably wouldn't be WSL, it'd be using this. Because not everyone I work with is comfortable with Linux tooling and who knows if our management tools can see what's going on with it.
And no, it probably wouldn't be WSL, it'd be using this. Because not everyone I work with is comfortable with Linux tooling and who knows if our management tools can see what's going on with it.
The sane or lazy choice? Right tool, right job; would be the right choice.
Wrong. When you have dozens of systems to manage that can all have security vulnerabilities, the less burden involved in keeping everything up to date and secure. Uniqueness breeds unique and unforeseen problems. (The modern way to describe this is to make servers like cattle, not pets.)
In a Windows environment, the best tool for the job is almost always another Windows box. Arguably, sure, PHP is a poor choice for a Windows environment, but IT/operations rarely has the luxury of deciding what line of business apps other departments use.
In a Windows environment, the best tool for the job is almost always another Windows box. Arguably, sure, PHP is a poor choice for a Windows environment, but IT/operations rarely has the luxury of deciding what line of business apps other departments use.
thats certainly one point of view. i would still call it lazy though.
I do for several large projects.
But, I do not run IIS. Use Apache instead.
I have webservers running windows server, and databases servers on centos.
Main reasons familiarity started as a windows application developer, the gui in my case window explorer feels easier for the tasks that I need do.
I have setup webservers on linux as well, Just I work faster in windows can fix things easier then having to google with linux when things go wrong. I prefer the windows file permissions
Main reasons familiarity started as a windows application developer, the gui in my case window explorer feels easier for the tasks that I need do.
I have setup webservers on linux as well, Just I work faster in windows can fix things easier then having to google with linux when things go wrong. I prefer the windows file permissions
Where I intern, we do development on Windows machines with WAMP, but of course everything is served from Linux instances in the cloud.
I always run it in a virtual machine when I'm developing on Windows or OS X.
Shouldn't WSL do the trick? Especially with WSL2 I found no need to use a dedicated virtual machine to use Linux applications in Windows.
WSL2 _is_ a dedicated virtual machine for Linux on Windows. It runs under Hyper-V.
That was wsl1, wsl2 is much tighter integrated than just thinking of it as a VM running in hyper V.
WSL 1 was not a virtual machine. It was a re-implementation of the Linux kernel API within the Windows kernel. As such, it's probably more comparable to CoLinux (if that's still a thing).
It's not really about running linux applications as much as running your application in the same or similar environment to what you are ultimately deploying on.
Exactly, I could run in WSL but I run in Docker or VirtualBox to emulate the production environment.
[deleted]
[deleted]
I'm most curious about what happens to the official SqlServer drivers for PHP.
At work, we have an on-premise customer support application that relies on PHP being installable on Windows, and requires the official SqlServer drivers for PHP (since they are the ones that...work).
We have many customers on Windows infrastructure; PHP on Windows Server is definitely a real use-case.
So lacking a PHP option would definitely be an issue for us!
But also: In all of Microsoft, is PHP on Windows really just relying on one person????????
At work, we have an on-premise customer support application that relies on PHP being installable on Windows, and requires the official SqlServer drivers for PHP (since they are the ones that...work).
We have many customers on Windows infrastructure; PHP on Windows Server is definitely a real use-case.
So lacking a PHP option would definitely be an issue for us!
But also: In all of Microsoft, is PHP on Windows really just relying on one person????????
The beautiful thing about php is it might just work even without updates. There are quite a few extensions which are not updated for almost 10 years and they still work on newest php versions
Who use Microsoft build of PHP ?
Back when I was still coding PHP on Windows, I just used the XAMPP bundle to get the entire web stack up and running in minutes. Granted, that was 10 years ago, I'm neither coding PHP nor coding on Windows now, so I'm a bit out of the loop.
Back when I was still coding PHP on Windows, I just used the XAMPP bundle to get the entire web stack up and running in minutes. Granted, that was 10 years ago, I'm neither coding PHP nor coding on Windows now, so I'm a bit out of the loop.
> Who use Microsoft build of PHP?
Surely I'm not the only person who has worked on PHP application that needed to stay running while it was being converted, piece by piece, to ASP.NET? Of course these days with dotnet Core this can all be done on Linux or the traffic routing can be trivially handled by nginx...
I'm trying to think of an answer to "We've got to do this on Windows!" but nothing realistic is coming to mind that doesn't involve legacy-ware that is over ten years old -- which is still beyond the scope of this general discussion.
Surely I would think that "PHP on Windows" going forward would be a feature delivered from WSL and not on Windows itself.
Surely I'm not the only person who has worked on PHP application that needed to stay running while it was being converted, piece by piece, to ASP.NET? Of course these days with dotnet Core this can all be done on Linux or the traffic routing can be trivially handled by nginx...
I'm trying to think of an answer to "We've got to do this on Windows!" but nothing realistic is coming to mind that doesn't involve legacy-ware that is over ten years old -- which is still beyond the scope of this general discussion.
Surely I would think that "PHP on Windows" going forward would be a feature delivered from WSL and not on Windows itself.
In my company some small internal web sites and simple apps run PHP on Windows; we always got the PHP zip from php.net and manually configured about 15 parameters to suit our needs, this was once per minor release, so about once a year (monthly updates did not need any config change).
I am using PHP for scripting anything that does not require an exe, but more complex than a batch file, it is the default scripting solution (I connect to SQL server a lot from these scripts).
I built an internal web app a few jobs ago around 2015.
Windows server vm, IIS, PHP 7, and sql server. This replaced an asp app.
My only major issues were SQL driver or coding. I did struggling with session timeouts for a while.
I really wish I had known about nginx back then. Even if it were just to show a "down for maintenance" screen while doing a release.
Edit: I upgraded to php 7 in early 2016 before the app officially launched
Windows server vm, IIS, PHP 7, and sql server. This replaced an asp app.
My only major issues were SQL driver or coding. I did struggling with session timeouts for a while.
I really wish I had known about nginx back then. Even if it were just to show a "down for maintenance" screen while doing a release.
Edit: I upgraded to php 7 in early 2016 before the app officially launched
SQL driver works just fine, and "down for maintenance" takes seconds to put in IIS, no PHP needed. Not perfect, but working.
I had trouble years ago when the php 7 version first came out. It was fine after a few months.
Maybe XAMPP bundles that Microsoft build of PHP.
There's IIS.
I would guess most Windows PHP users would just install WAMP (https://www.wampserver.com/en/).
XAMPP, WAMP, Appserv.
Well, now that you can embed a Debian (or other) very easily, I guess it doesn’t make a lot of sense to continue compiling PHP for Windows ?
And there were always some traps (mostly because of the lack of case sensitive file names), so I feel it’s better to not use it anymore at all (the edge cases must be very low)
And there were always some traps (mostly because of the lack of case sensitive file names), so I feel it’s better to not use it anymore at all (the edge cases must be very low)
Originally Microsoft managed PHP offering on Azure (Azure App Service) was running only on Windows.
Nowadays Azure App Service also supports Linux, so there’s no so big need for PHP on this side.
Nowadays Azure App Service also supports Linux, so there’s no so big need for PHP on this side.
If there was only one programming language to directly support, I guess this would not happen. But the landscape has changed (personally, I switched from php to python like 15 years ago).
If you read the next to mails, it seems they will still help, just not work directly to support it from Microsofts end.
Why does PHP need support from within Microsoft to be supported on Windows anyway? What I grasp from that email is that they support the development and build process in some way. Sure enough that could be done by someone else within the community. What's the fuss about?
Being an open source project most of the work is likely sponsored by companies who have some kind of interest in supporting the project.
I don’t think Microsoft is doing anything that could not be technically done by somebody else.
I don’t think Microsoft is doing anything that could not be technically done by somebody else.
> I don’t think Microsoft is doing anything that could not be technically done by somebody else.
This is generally true. PHP had Windows support early on and builds provided by community.
Having Microsoft backing it meant there were people with more time for it and some Windows-specific optimisation could be done, by people with access to true Windows experts. This gave a boost in the early days of their involvement.
This is generally true. PHP had Windows support early on and builds provided by community.
Having Microsoft backing it meant there were people with more time for it and some Windows-specific optimisation could be done, by people with access to true Windows experts. This gave a boost in the early days of their involvement.
>Sure enough that could be done by someone else within the community.
Sure, and usually in a hasty fashion, when they have time, understaffed, as is the case with many ports.
Instead, Microsoft wants this to be more high quality, to attract PHP devs to the platform and get PHP-based business on Azure/Windows, integrate it with their Windows dev tools, build goodwill etc, so they fund this and have some people working on it.
Sure, and usually in a hasty fashion, when they have time, understaffed, as is the case with many ports.
Instead, Microsoft wants this to be more high quality, to attract PHP devs to the platform and get PHP-based business on Azure/Windows, integrate it with their Windows dev tools, build goodwill etc, so they fund this and have some people working on it.
It makes sense to me. You can use WSL, and run PHP on Linux.
What does this actually mean? The PHP release engineer who replied didn’t make it sound like it was a major deal (of course, if it is a major deal, this may just have been an initial ACK statement).
Technologically it's not a big deal for developers who want to run PHP on Windows because WSL can do that. It might affect people who have, say, a .NET app running on Windows in Azure who wanted to put a Wordpress marketing site on the same server. As of PHP8 they'll have to either use an 'unofficial' PHP build for Windows or move the PHP site to a second server.
Politically though, it might be a big deal. Microsoft don't think supporting a native Windows build of PHP is worthwhile. That could say something about the server-side scripting language landscape changing. On the other hand, it might just say that it costs a few hundred thousand dollars of engineering time every year and they believe that could be allocated better. There's no way to know from a single post.
Politically though, it might be a big deal. Microsoft don't think supporting a native Windows build of PHP is worthwhile. That could say something about the server-side scripting language landscape changing. On the other hand, it might just say that it costs a few hundred thousand dollars of engineering time every year and they believe that could be allocated better. There's no way to know from a single post.
With WSL getting popular, between that and native build, there's two different versions of PHP to support on Windows in practice. And, given that WSL maps closer to production environments for most use cases, it's clear that it's the more important one.
I guess the just have to make to many modifications to run 8.0 on Windows. Maybe the JIT does nor work properly/easily on windows?
Nevertheless nowadays there is WSL and Docker so you don‘t really need a windows native executable.
Nevertheless nowadays there is WSL and Docker so you don‘t really need a windows native executable.
There already PHP8 build on Windows: https://windows.php.net/qa/
As I understand it, it's not a major deal now that WSL (Windows Subsystem for Linux) means you can run Linux software natively within the Windows environment.
So, it's no longer necessary for PHP (or anything else Linux-y) to be natively supported on the Windows OS; anyone can just boot up WSL and run it there, where it will work better anyway.
So, it's no longer necessary for PHP (or anything else Linux-y) to be natively supported on the Windows OS; anyone can just boot up WSL and run it there, where it will work better anyway.
[deleted]
I guess they also have know-how on how to do the Windows build now.
I remember before the windows.php.net day --- setting up PHP on Windows is much more of a mess that most people just use some kind of bundle (XAMPP, WAMP, etc)
I remember before the windows.php.net day --- setting up PHP on Windows is much more of a mess that most people just use some kind of bundle (XAMPP, WAMP, etc)
For now, probably not much, not even for PHP on Windows. I guess someone else will compile it. It would be a bigger deal for the few who run PHP on Windows, if WinCache or the SQL Server driver were dropped.
* Used to run PHP on Windows, because $WORK had a tiny deployment that didn't need an extra server. In retrospect, getting a small cloud vm would have worked better, but letsencrypt wasn't around back then.
* Used to run PHP on Windows, because $WORK had a tiny deployment that didn't need an extra server. In retrospect, getting a small cloud vm would have worked better, but letsencrypt wasn't around back then.
Sorry if this is a dumb question, I don't really use Windows any more... so i'm not super familiar with how things work today.
With the new Linux subsystem, does Windows even need separate support for PHP anymore?
With the new Linux subsystem, does Windows even need separate support for PHP anymore?
> With the new Linux subsystem, does Windows even need separate support for PHP anymore?
For Windows client, maybe not.
But some people run PHP on Windows Server in actual production scenarios (using either Apache or IIS) and those people absolutely need a native solution: WSL[2] has too much overhead.
SHOULD you be using PHP on Windows Server? Likely not, but it is more common than you'd think, I've personally worked at multiple companies that had a Wordpress based site running on IIS for example. This was pre-Cloud though so YMMV.
For Windows client, maybe not.
But some people run PHP on Windows Server in actual production scenarios (using either Apache or IIS) and those people absolutely need a native solution: WSL[2] has too much overhead.
SHOULD you be using PHP on Windows Server? Likely not, but it is more common than you'd think, I've personally worked at multiple companies that had a Wordpress based site running on IIS for example. This was pre-Cloud though so YMMV.
There's the UniServer https://www.uniformserver.com/ - a complete WAMP stack with quite a bit more, plus it is pre-hardened for use on the public web, ready for deployment and production. It's humorous how many WAMP developers work in public with their development hooks open, allowing outsiders to peer in and they are unaware. UniServer does not allow that.
The fact they haven't really updated their front page in years would make me nervous about using such a thing (PHP 5.6 came out 6 years ago and it reached EOL December 31st, 2018) and it took a closer look to see the project was still being updated with a new release just a couple months ago. I'm not trying to crap on the entire project, far from that! A more secure by default alternative to XAMPP/WampServer for Windows is great! But first impressions do matter.
Besides alternatives like WSL 2, someone can also produce a winget[1] package.
[1] https://devblogs.microsoft.com/commandline/windows-package-m...
[1] https://devblogs.microsoft.com/commandline/windows-package-m...
Must be the fact that they can not make money from it.
Kind regards https://www.good2manage.com
At least they warned.
What does this mean for PHP on Azure App Service plans? Are they just going to use a different version?
I guess with WSL maturing, most people will use that instead to run PHP on Windows
Is WSL maturing? It seems like it has abandoned its original goal for WSL in WSL2 https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux#WS...
Windows is not a server OS. It's a desktop OS you can use to talk to Linux servers. That's why they gave us WSL and that nice terminal I'm looking at.
Not Windows 10 but Windows Server is a server OS. Usage is probably declining but it's still in use in most companies somewhere for file storage, authentication (AD), databases (SQL Server) or even web servers.
Yep. We are forced to use it because we are a small company with a budget for one real server, and both our accounting and shipping management solutions are Windows-only. I'd wipe it and switch to Linux in a heartbeat if that weren't the case, as the only other functions the server handles are file storage and AD, both of which can be done on Linux.
Maybe not for hosting but I think the Active directory server at the heart of just about every company would disagree with your statement.
FreeIPA is a nice FOSS alternative.
You would be surprised about the number of Windows Servers out there. Yes Linux and other Unixes are the winners in the server space but there is a very significant amount of Windows servers in the wild.
Still used by around 30% of websites: https://w3techs.com/technologies/overview/operating_system
Perhaps interestingly that's about the percentage of sites running WordPress...
why?
tinus_hn(2)
gear54rus(1)
What they did for PHP supporting Windows?
Microsoft and PHP has never been a good combination, it’s like .NET on Linux
2010 called and wants its opinion back.
No, seriously. Haven't you heard about ASP.NET Core and the like? Even Azure is actively pushing Linux + .NET Core these days.
No, seriously. Haven't you heard about ASP.NET Core and the like? Even Azure is actively pushing Linux + .NET Core these days.
They are recommending a managed k8s cluster, although that k8s cluster can run "windows containers", but if the goal is "don't use aws" then they have to be pushing this way.
I am guessing you have not heard of .NET Core which has been running on Linux for a while. Not to mention Microsoft bought Xamarin which maintained Mono and mysteriously Mono was relicensed as MIT license. Though I am suspecting Mono might shut down given the amount of coverage towards consolidating all .NET platforms into just .NET with .NET 5.
Microsoft even fully embraced the community built package manager and they release important packages under it. You no longer need to upgrade your whole .NET platform (with some exceptions) just to use new packages from Microsoft that boost the ecosystem.
I have used .NET Core on both Ubuntu and Mac (which has its own Visual Studio - not Code) and it runs just the same.
Microsoft even fully embraced the community built package manager and they release important packages under it. You no longer need to upgrade your whole .NET platform (with some exceptions) just to use new packages from Microsoft that boost the ecosystem.
I have used .NET Core on both Ubuntu and Mac (which has its own Visual Studio - not Code) and it runs just the same.
>.NET on Linux
Why so unreasonable claims?
It's works very well
Why so unreasonable claims?
It's works very well
.NET on Linux is all good these days, as long as you stick to more recent versions.
I've worked on .NET Core services that ran in Ubuntu containers since the preview versions of .NET Core 2.0 (that was around spring/summer 2017) and since then .NET on Linux has been great. You get some config issues sometimes and weird use cases like if you use a closed and password protected 3rd party NuGet source, but it doesn't take that long to resolve those. I'm on a Mac nowadays and the same applies.
Fact: PHP can run on .NET on Linux thanks to the PeachPie compiler and Dotnet Core.
Microsoft will, in all likeliness, be shifting from the NT kernel to a unix-like kernel in the near-ish future. I wouldn't be too concerned.
Would calculator quietly start working on top of WSL at some point?
Why would they want to do that? Why adopt something that is on its way to the museum?
childintime(1)
> Why would they want to do that? Why adopt something that is on its way to the museum?
The Unix kernel is one of the most widely deployed in the world. I don't think it's going anywhere in the next 100 years.
The Unix kernel is one of the most widely deployed in the world. I don't think it's going anywhere in the next 100 years.
> The Unix kernel
Which one? Linux?
By that logic Windows NT kernel won't go anywhere in 100 years either, since it runs on nearly a billion devices.
Which one? Linux?
By that logic Windows NT kernel won't go anywhere in 100 years either, since it runs on nearly a billion devices.
Neither is MVS going anywhere, even though it has evolved into z/OS.
I'm pretty sure there will be a workloads running on NonStop well into the 21st century too.
So, there's no reason to think we will be free of Windows anytime soon either.
I'm pretty sure there will be a workloads running on NonStop well into the 21st century too.
So, there's no reason to think we will be free of Windows anytime soon either.
Linux was heavily inspired by Unix but it's not Unix in any sense.
Rest of Unix certified implementations are however not widely deployed. I don't see many AIX, Solaris production machines anywhere since everyone often deploys Linux instead.
Same story applies to *BSD family.
The only thing that keeps the Unix identity on those system is the Posix interface which is also extremely outdated on modern systems and it's kept around as a legacy.
Rest of Unix certified implementations are however not widely deployed. I don't see many AIX, Solaris production machines anywhere since everyone often deploys Linux instead.
Same story applies to *BSD family.
The only thing that keeps the Unix identity on those system is the Posix interface which is also extremely outdated on modern systems and it's kept around as a legacy.
Linux is Unix in the sense it implements most of the same core ideas in a similar way. The same applies to macOS, which is a layer of BSD on top of a Mach microkernel. All those systems have much more in common between themselves than anything else.
macOS is actually a certified UNIX, the rest being enterprise OSes most people will never see.
[deleted]
Key takeaway:
>This message means Microsoft aren't going to produce official builds for PHP 8 onwards.
>This message does NOT mean that nobody will.