271–280 of 315 posts
Earlier quoted context omitted.
If it wasn't so linux distribution unfriendly…
Oh yeah so unfriendly. sudo dnf install dotnet-sdk-8.0. sudo apt install dotnet-sdk-8.0 sudo apk add dotnet-sdk-8.0
Works like a charm.
Any more irrelevant things to say?
Earlier quoted context omitted.
If it wasn't so linux distribution unfriendly…
In what ways?
Which means anything you write with it can't be included in any distribution.
It's quite limiting. Basically it's only useful for proprietary software shipped by 3rd party.
Earlier quoted context omitted.
> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.
https://www.freshports.org/lang/dotnet pkg install lang/dotnet Not everything works, and support is community-maintained, but “mostly doesn’t run” does not reflect actual state of affairs.
Earlier quoted context omitted.
> C# as a language has always been cross-platform. Not really. Like, it notionally ran on FreeBSD, but nontrivial programs never actually worked until recently, and even now they mostly still don't.
The lack of an available runtime implementation, or the transitive dependencies of the dynamically linked reference assemblies, does not preclude the compiled assembly from being cross-platform. The assembly within the file built by a C# compiler contains IL code that can be extracted by cross-platform tooling. There’s nothing OS-specific at that layer. We are talking about the language, not the runtime implementatio…
Earlier quoted context omitted.
https://www.freshports.org/lang/dotnet pkg install lang/dotnet Not everything works, and support is community-maintained, but “mostly doesn’t run” does not reflect actual state of affairs.
"Nontrivial programs mostly don't run" is my real experience. I was quite hopeful at first but the culture is very much to use windows libraries even when you don't really need them, and not really care about anything that isn't windows.
As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics without a fallback and or without using newer crossplat APIs, but this is predominantly specific to SIMD code and a rather niche case that concerns my work.
There are some Nuget packages which come packaged with native dependencies, and some of the ancient and unmaintained ones do come with like a single win-x86 .dll inside, but this is a "things you sometimes encounter with C/C++" and in general is a rare occurrence.
Nowadays, the packages that have native dependencies either simply expect the host to have them installed (like you install, say, gstreamer), or come with dependent packages per-platform (and the matrix gets quite big: [x86, x64, arm64] x [linux, osx, win]). Like https://github.com/sandrohanea/whisper.net
But then again, this has to do with a specific package and its owner, if that's what you meant.
Note that there is no culture issue, there is poor framing and a strawman one. "I had issues on a niche target" is not mutually exclusive with cross-platform. Would you say lack of support for SunOS is a damning evidence of "pro-windows agenda"? (whatever it is, I use macOS and Linux hosts mainly and surprisingly and funnily enough, there is work to support SunOS as well)
The thinly veiled "but linux/unix!" low effort replies are unfortunate and tiresome. They don't strike me as a productive attitude that seeks to make things work.
Earlier quoted context omitted.
> RavenDB Ok, that actually sounds interesting. Still haven't heard of anyone using it, and closed-source makes it a non-starter, but I'm vaguely interested. Even then though, sounds like their client libraries are only .NET? > As for identity, you sound really silly when you consider it is literally built-in to ASP .NET itself, and can be expanded upon to your hearts desire, plus there's no shortage of available ide…
> And look how that worked out for them. Worked out pretty well to be fair, their old UI actually worked perfectly on Linux via Moonlight. Moonlight was more usable than Flash on Linux which was an unstable mess. > There are plenty of linters for C#, sure. But no-one would write a general linter in it. It was an example that came to mind because that was how Facebook first started adopting OCaml - a linter is a small…
Up to a point - it lints the things you might need in a C# application. But it's very much a tool for the MS/Windows/C# vertical - even using it in Rider isn't really their focus. If JetBrains was building the linter they used for all IDEA-family IDEs in C#, that would be interesting.
> Azure DevOps
Right, that's the kind of thing I'm talking about. Is anyone using that who's not already bought into MS/Windows/C#, is that a market they sell to at all? Can you even run it on anything other than Windows? It sounds like not, which rather proves the point.
"microsoft didn't really care much about building a community or getting it to work natively in other OSes/toolchains" still rings true IMO. C# has some great stuff if you're fully onboard with the MS stack, but they've taken at most baby steps towards fitting into other environments. (If anything it feels like they expect the rest of the world to fit in with them - if you want to bring e.g. Postgres into your MS/Windows/C# world that's relatively well supported, but going the other direction is much less so)
Earlier quoted context omitted.
> And look how that worked out for them. Worked out pretty well to be fair, their old UI actually worked perfectly on Linux via Moonlight. Moonlight was more usable than Flash on Linux which was an unstable mess. > There are plenty of linters for C#, sure. But no-one would write a general linter in it. It was an example that came to mind because that was how Facebook first started adopting OCaml - a linter is a small…
> Except ReSharper lints for other things too. Up to a point - it lints the things you might need in a C# application. But it's very much a tool for the MS/Windows/C# vertical - even using it in Rider isn't really their focus. If JetBrains was building the linter they used for all IDEA-family IDEs in C#, that would be interesting. > Azure DevOps Right, that's the kind of thing I'm talking about. Is anyone using that…
Moreover, the ecosystem mainly gravitates to Roslyn analyzers which run within build system and, naturally, integrate with Roslyn LSP. They work regardless of IDE or text editor you choose.
In fact, quite a lot of them come out of box, with the basic set enabled by default to prevent you from obvious mistakes, automatically fixing code to use terser syntax or avoiding footguns when using low-level APIs where applicable, and a lot more opt-in for a specific scenario or a workload.
Earlier quoted context omitted.
"Nontrivial programs mostly don't run" is my real experience. I was quite hopeful at first but the culture is very much to use windows libraries even when you don't really need them, and not really care about anything that isn't windows.
Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? This is the only way for this statement to be true. If it's something niche, the question is to the package maintainers, as usual, if it's actively maintained that is. As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics with…
Not a specific single program (not package) just my general experience of how "find useful-sounding program written in C#" -> "download it, try to run it" usually goes. I could probably dig up the name of the most recent thing I tried it with if you really want (I think it was a video renaming tool) but there's no useful discussion to be had about what a random 1-person project happens to support or not.
> But then again, this has to do with specific package and its owner.
> Note that there is no culture issue, there is poor framing and a strawman one.
If most package owners act a certain way that's what culture is. I doubt either of us has the time to do a statistically valid survey of what's out there. Maybe your experience is different, but let me ask: are you actually using C# programs on non-Windows, and e.g. reporting bugs in them? And finding maintainers take them seriously when you do?
> Would you say lack of support for SunOS is a damning evidence of an anti-OSS culture?
I think projects that assume the whole-world is Linux and don't support e.g. FreeBSD or Illumos (I assume that's what you meant by SunOS?) are very much anti-OSS, and complain loudly about them when I encounter them, yes. Obviously there are levels of "not supported" here, but "well, your patch sounds ok so I'll merge it, can't promise we won't break FreeBSD again in the future since we don't have the resources to test it" is still better than I've gotten from most C# projects when I've tried.
Earlier quoted context omitted.
Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? This is the only way for this statement to be true. If it's something niche, the question is to the package maintainers, as usual, if it's actively maintained that is. As a sibling comment pointed out, .NET assemblies within Nuget packages are by-definition portable, unless they use platform intrinsics with…
> Do you have a specific scenario and a package name in mind when you say "Nontrivial programs mostly don't run"? Not a specific single program (not package) just my general experience of how "find useful-sounding program written in C#" -> "download it, try to run it" usually goes. I could probably dig up the name of the most recent thing I tried it with if you really want (I think it was a video renaming tool) but t…
What is the name of the software that you expected to run on the OS of your choice? I briefly looked through your Github profile hoping to find it but it seems it mostly consists of Scala, Java and a few other non-.NET projects. I assume you haven't had the opportunity to use .NET tooling yet. Are you interested in getting .NET SDK to run on FreeBSD?
Was "the evil" software just an ancient WinForms application?
Earlier quoted context omitted.
Oh yeah so unfriendly. sudo dnf install dotnet-sdk-8.0. sudo apt install dotnet-sdk-8.0 sudo apk add dotnet-sdk-8.0
apt install dotnet-sdk-8.0 Building dependency tree... 0% Error: Unable to locate package dotnet-sdk-8.0 Error: Couldn't find any package by glob 'dotnet-sdk-8.0' Works like a charm. Any more irrelevant things to say?