421–430 of 509 posts
Earlier quoted context omitted.
This is wild, apparently this stuff is in the Debian repos now? https://learn.microsoft.com/en-us/dotnet/core/install/linux-... So you can just apt install dotnet-sdk-8.0. This must be the most unfriendly Linux install documentation I've ever seen though, it was not easy to find the names of those packages.
> This is wild, apparently this stuff is in the Debian repos now? It's been there for several years now, hasn't it?
Earlier quoted context omitted.
The shift is slow, but it has been ongoing for years, and is pretty much wrapping up now. .NET 5 was released in November, 2020 and that was the "beginning of the end" of the shift over. For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not tha…
It sounds like .NET is on the way toward becoming the Java competitor it set out to be.
They've now abandoned that strategy, and instead they use it as a way to maintain lock-in at the IAAS/PAAS level (Azure).
Earlier quoted context omitted.
But….net is everything! And also nothing ! It’s a product? It’s a suite! It’s a system ! Visual Basic .net ! What ?
It's the Microsoft way to apply the same name to bunch of unrelated products. everything is .net, azure, 365, now also copilot.
Earlier quoted context omitted.
Search his tweeter feed or Mastodon for anything MAUI.
Links are a thing :)
https://x.com/migueldeicaza/status/1610665502598127616?lang=...
Earlier quoted context omitted.
.NET/C#'s competitor JVM/Kotlin does provide a UI framework (Jetbrains Compose) that runs on iOS, Android, Windows, Mac, Linux, and the web. That's what you have to compare against, and .NET/C# falls flat .
No and it's not even close. Kotlin only has a single Jetbrains Compose (I presume Kotlin Multiplatform is the same thing). It is also subject to the quirks and specifics of JVM implementations, build-systems and package management. Kotlin native partially bypasses this, but its performance is a factor of 0.1-0.01x vs OpenJDK (if there is new data - please let me know). This is very unlike NativeAOT which is on averag…
Win32? Silverlight/Blend? XAML? MAUI? They're all windows only.
Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms.
I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option.
Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time.
While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform.
> subject to the quirks and specifics of JVM implementations, build-systems and package management
That's a massive advantage over the arcane package management and build systems of .NET
Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem.
I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
Earlier quoted context omitted.
.net Core still has Windows Forms thoguh? At least I (for kicks) migrated one of my old .net 4.something projects to .net core and it still works and shows the classic Windows Forms GUI. It's (of course) not portable
.Net Core on Windows has support for loading assemblies that reference COM interfaces and the win32 API, along with other things that aren’t supported elsewhere like C++/CLI. That’s why loading System.Windows.Forms still works, it’s not part of .Net 5+, but it can still load the assemblies on Windows (they still use GDI, etc under the hood).
Earlier quoted context omitted.
This is wild, apparently this stuff is in the Debian repos now? https://learn.microsoft.com/en-us/dotnet/core/install/linux-... So you can just apt install dotnet-sdk-8.0. This must be the most unfriendly Linux install documentation I've ever seen though, it was not easy to find the names of those packages.
> This is wild, apparently this stuff is in the Debian repos now? It's not. Microsoft provides its own apt repository you need to add first.
$ apt search dotnet
p dotnet-apphost-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-host - dotNET host command line p dotnet-host-7.0 - dotNET host command line p dotnet-host-8.0 - .NET host command line p dotnet-hostfxr-6.0 - dotNET host resolver p dotnet-hostfxr-7.0 - dotNET host resolver p dotnet-hostfxr-8.0 - .NET host resolver p dotnet-runtime-6.0 - dotNET runtime p dotnet-runtime-7.0 - dotNET runtime p dotnet-runtime-8.0 - .NET runtime p dotnet-runtime-dbg-8.0 - .NET Runtime debug symbols. p dotnet-sdk-6.0 - dotNET 6.0 Software Development Kit p dotnet-sdk-6.0-source-built-arti - Internal package for building dotNet 6.0 So p dotnet-sdk-7.0 - dotNET 7.0 Software Development Kit p dotnet-sdk-7.0-source-built-arti - Internal package for building dotNet 7.0 So p dotnet-sdk-8.0 - .NET 8.0 Software Development Kit p dotnet-sdk-8.0-source-built-arti - Internal package for building the .NET 8.0 p dotnet-sdk-dbg-8.0 - .NET SDK debug symbols. p dotnet-targeting-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-templates-6.0 - dotNET 6.0 templates p dotnet-templates-7.0 - dotNET 7.0 templates p dotnet-templates-8.0 - .NET 8.0 templates p dotnet6 - dotNET CLI tools and runtime p dotnet7 - dotNET CLI tools and runtime p dotnet8 - .NET CLI tools and runtime p libgtk-dotnet3.0-cil - GTK.NET library p libgtk-dotnet3.0-cil-dev - GTK.NET library - development files
Earlier quoted context omitted.
It hasn't. Powershell is probably one of great things to come out of Windows Server. I still use it with *nix machines and it powers some sidecars at work. If you are stuck with Windows Server, it's only thing that gives you a fighting chance of being able to do anything NotClickOps (tm) Sure, it's got some unique characteristic that more traditional shell users dislike but that's just a matter of taste.
It irks me that the default for servers still seems to be 5.1 which is anemic and seems to have really weird quirks and syntax differences from later versions. As if the default silent jsondepth thing was not enough converfrom-json hash tables have case insensitive keys. Really? Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x b…
It's just best to think about Powershell 5.1 and Powershell Core 7.x like Py2 -> Py3. Most of code works as is, some doesn't, and you should use latest when you can.
>Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x by default things broke because users never cared to check sensitivity of key names.
Azure Functions are nightmare in its own. Not sure how much of that is Powershell fault vs Azure Functions.
>It’s also slow even for interpreted language standards.
Actually, it's blown Python out of the water at work. It's startup time can be painful as it's interpreting everything but once it gets going, it really moves. We use it to churn through 4GB CSV at work replacing a Python script, it's much much faster.
>I’ll seriously never use powershell for anything serious ever again even though I admit syntax and design feels kinda nice.
Your loss. Despite the few problems I run into, I really like it and wish more *nix people gave it a try. It's much better then bash nightmares I've seen.
Earlier quoted context omitted.
I’m a Unix person and I know nothing about Windows Server. How has PowerShell made it less competitive?
Priorities could have been better spent on bringing headless, WSL, ssh, and Terminal up to speed twenty years earlier.