3 ms·

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 tr

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 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 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.

lmm 2y ago
> 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 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.
- neonsunset 2y ago
  For the sake of productive conversation, I'm going to ignore irrelevant and imagined issues and will focus on the one that can be addressed. 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?
  - lmm 2y ago
    > I assume you haven't had the opportunity to use .NET tooling yet. I've used it some, not to the same extent, and generally at work - another one of those cultural differences I've found is that most JVM/etc. companies are at least theoretically on-board with open-sourcing their non-core libraries, whereas in .NET land there's much less willingness to do that. The actual tooling is good (the best I've used in some ways), but that's only one piece of the puzzle. > Are you interested in getting .NET SDK to run on FreeBSD? The SDK itself runs great. I'm more interested in being able to drop in a small program that solves a problem for me - like, that's the way I started with Ruby or OCaml or Go or Erlang, there was a standalone thing that I could pick up and use as part of my system, I didn't have to rearchitect everything or buy into the whole ecosystem or change my workflow. I don't even know Erlang at all, but it's running in my stack in that I'm running Riak (with the Java driver), and that gives me a place where it's already adding value and I could dip my toe further into it if I wanted. That's the thing I've never found from the .NET world - a reason to run it in my system that doesn't require me to fully buy into it to get started. (I guess in theory SQL server could be that, but it's non-opensource and doesn't have any compelling selling point over the substitutes. Part of it's honestly probably just marketing, but that goes for any new language/tool - the most persuasive thing is hearing other people having success with it in a similar situation) > Was "the evil" software just an ancient WinForms application? Quite possibly, but I remember command-line tools also not working - just these random one-developer tools have no reason to publish versions for other platforms, and it's not the natural workflow, so they don't. Probably the issues are minor (like, I remember one that was using some windows-only part of the standard library to do something incredibly basic like base64 decoding - I'm sure someone who uses .NET every day would take 30 seconds to swap that out with using the right part of the .NET core standard library instead. But it doesn't make for an easy onramp)

lmm 2y ago

> 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 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.

neonsunset 2y ago
For the sake of productive conversation, I'm going to ignore irrelevant and imagined issues and will focus on the one that can be addressed. 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?
- lmm 2y ago
  > I assume you haven't had the opportunity to use .NET tooling yet. I've used it some, not to the same extent, and generally at work - another one of those cultural differences I've found is that most JVM/etc. companies are at least theoretically on-board with open-sourcing their non-core libraries, whereas in .NET land there's much less willingness to do that. The actual tooling is good (the best I've used in some ways), but that's only one piece of the puzzle. > Are you interested in getting .NET SDK to run on FreeBSD? The SDK itself runs great. I'm more interested in being able to drop in a small program that solves a problem for me - like, that's the way I started with Ruby or OCaml or Go or Erlang, there was a standalone thing that I could pick up and use as part of my system, I didn't have to rearchitect everything or buy into the whole ecosystem or change my workflow. I don't even know Erlang at all, but it's running in my stack in that I'm running Riak (with the Java driver), and that gives me a place where it's already adding value and I could dip my toe further into it if I wanted. That's the thing I've never found from the .NET world - a reason to run it in my system that doesn't require me to fully buy into it to get started. (I guess in theory SQL server could be that, but it's non-opensource and doesn't have any compelling selling point over the substitutes. Part of it's honestly probably just marketing, but that goes for any new language/tool - the most persuasive thing is hearing other people having success with it in a similar situation) > Was "the evil" software just an ancient WinForms application? Quite possibly, but I remember command-line tools also not working - just these random one-developer tools have no reason to publish versions for other platforms, and it's not the natural workflow, so they don't. Probably the issues are minor (like, I remember one that was using some windows-only part of the standard library to do something incredibly basic like base64 decoding - I'm sure someone who uses .NET every day would take 30 seconds to swap that out with using the right part of the .NET core standard library instead. But it doesn't make for an easy onramp)