[kragen]

i want to love dotnet-core, especially since godot switched from mono in godot 3 to dotnet-core in godot 4, but so far i haven't been able to

currently debian has a mono package but no dotnet-core package. i'm not sure why this is; usually when debian lacks a popular nominally open-source package like this, it's either because it fails to build from source, or because it has some kind of tricky licensing pitfall that most people haven't noticed, but diligent debian developers have

does anyone know why this problem exists for dotnet-core?

also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?

[MarkSweep]

.NET Core is available for Debian, you just have to add Microsoft's APT source [1].

Fedora [2], Ubuntu [3], and FreeBSD [4] build .NET from source themselves. A lot of work has been done to make it possible to build .NET from source [5] without closed source components, so it might just be a matter of someone being motivated to create the package for Debian.

[1]: https://learn.microsoft.com/en-us/dotnet/core/install/linux-...

[2]: https://src.fedoraproject.org/rpms/dotnet8.0

[3]: https://launchpad.net/ubuntu/+source/dotnet8

[4]: https://github.com/freebsd/freebsd-ports/tree/main/lang/dotn...

[5]: https://github.com/dotnet/source-build

[jwrallie]

When using Microsoft repositories you need to explicitly opt out on telemetry collection.

I think telemetry collection alone should be a good reason for Debian to consider repackaging it. I don’t want telemetry to be collected on my GNU/Linux machine, thanks Microsoft, but you already have so much telemetry from my Windows machine, please leave my other machines alone.

[neonsunset]

I hate to defend telemetry of all things but in this particular case the criticism is unfounded and lacks context:

https://dotnet.microsoft.com/en-us/platform/telemetry

https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...

In any case, Debian would use https://github.com/dotnet/source-build and dotnet/dotnet, and could easily include the argument or a patch for this. It’s unlikely to be an issue. My bet it was not in Debian because there was no one to take initiative yet or there was but that person has faced a backlash by people in Debian who are similar to vocal minority here that posts FUD because of their little personal crusade.

[jwrallie]

Your second source mentions you have to change a variable in bash to opt out for telemetry, I fail to see where the FUD is.

[kragen]

yeah, debian does generally make spyware explicitly opt-in. even https://popcon.debian.org/stable/index.html is explicitly opt-in

i think the links you provide make it clear that the criticism is not unfounded

[kragen]

yes, i know about the microsoft apt source

as for building from source, i see, thanks! or maybe it's unresolved legal concerns? nobody so far in this thread has known of any, though

[MarkSweep]

I found someone requesting that it be added to Debian:

https://bugs.debian.org/cgi-bin/%3Ca%20href=%22bugreport.cgi...

So far no one has mentioned licensing being an issue.

[kragen]

that's great! possibly the link you meant was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078132

that seems to be from only a few weeks ago though

it doesn't seem to have come up on debian-legal in the last year or so https://lists.debian.org/debian-legal/ but debian-legal is also kind of a shadow of its former self

[InfiniteRand]

Notably in that bug report the reporter says they cannot maintain it (not that I blame them, not a small work)

[Mogzol]

I doubt it is due to legal concerns if Ubuntu, Fedora, and FreeBSD are all distributing their own builds.

[kragen]

you could easily imagine fedora distributing their own build of software whose licensing fails to comply with the debian free software guidelines; bundling proprietary software used to be common in linux distributions in fact

[k_roy]

"legal concerns" is not the same as philosophy differences.

[mdasen]

You can add add Microsoft's repo to install it on Debian: https://learn.microsoft.com/en-us/dotnet/core/install/linux-....

Does Debian require packages to work on all of its architectures? If so, that could be the issue. .NET Core only supports x86, x64, and Arm64 (I think Arm32 has been discontinued and RISC-V is experimental at this point).

It's possible that they object to .NET Core having certain license restrictions on the Windows port (https://github.com/dotnet/core/blob/main/license-information...). .NET Core is mostly MIT or Apache licensed, but the Windows SDK has some additional terms. Skimming the third party licenses, that doesn't seem like an issue (mostly MIT/BSD/Apache or similar).

I think the licensing situation is an interesting question: if you have software that's 100% open source when compiled for your OS, but requires non-free stuff to run on Windows, is it ok to include in Debian? It looks like none of the non-free stuff (like WPF) gets distributed with the non-Windows SDK builds. Binaries created from your code only depend on MIT-licensed stuff on macOS and Linux, but might depend on something closed-source when targeting Windows - though it looks like almost all of that stuff is either WPF (so you wouldn't be able to develop on Linux/Mac anyway since those libraries wouldn't be in the SDK on those platforms) or were removed as a runtime dependency in .NET 7. It looks like `Microsoft.DiaSymReader.Native` might be the only thing left. Maybe that's what is holding it back?

> also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?

"Reasonable" can be a lot of things to a lot of different people. People have been working on RISC-V support. Samsung seems interested in it. But I probably wouldn't recommend it at the moment - and Mono doesn't really have RISC-V support either.

[kragen]

to be clear, my question about debian is not about whether i can install dotnet-core in debian; it's about why it isn't in debian's repositories rather than microsoft's. microsoft, to understate the case somewhat, doesn't provide the stringent protections for users that debian does

debian doesn't require packages to work on all of its architectures. luajit, for example, has not been ported to riscv64, mips64el, or ppc64el https://packages.debian.org/sid/luajit, though lua5.1 is https://packages.debian.org/sid/lua5.1. what the debian policy manual says about architecture-specific packages seems to be https://www.debian.org/doc/debian-policy/ch-controlfields.ht...:

> Specifying a specific list of architectures indicates that the source will build an architecture-dependent package only on architectures included in the list. Specifying a list of architecture wildcards indicates that the source will build an architecture-dependent package on only those architectures that match any of the specified architecture wildcards. Specifying a list of architectures or architecture wildcards other than any is for the minority of cases where a program is not portable or is not useful on some architectures. Where possible, the program should be made portable instead.

i don't think the license you link to would be a problem in itself, because it only applies to certain files which are not useful for running dotnet-core on debian anyway. debian has lots of packages from which non-free-software files have been removed. i don't know anything about diasymreader?

with respect to esp32 and ch32v003, what i meant to point to was not the risc-v architecture (some esp32s are tensilica!) but the limited memory space; jit compilation is not a good fit for 2 kibibytes of ram or even 520 kilobytes of ram

[Const-me]

> Arm32 has been discontinued

.NET 9.0 preview still includes ARMv7 builds for Linux: one based on glibc library, another one for Alpine.

[ozim]

I would say it is .Net Foundation job to prepare and submit the package not Debian maintainers.

[kragen]

if you want your package to be in debian, you are going to have to find a debian developer who is willing to take responsibility for maintaining it. microsoft is already providing .deb packages on their website, at least binaries

[ozim]

But it is not Microsoft like I mentioned but .Net Foundation.

They could get one of their people to become Debian maintainer.

[kragen]

getting one of your people to become a debian developer is similar in difficulty to getting one of your people to become a senator or a citizen of switzerland

[TillE]

That's not how Linux distros work. The OS maintainers make their own packages.

[chungy]

It sure wouldn't hurt if they hired a Debian Developer to do it right, or maybe work through the process of turning an employee into a Debian Developer.

[ptx]

Debian developers can do it right because they're not affiliated with the vendor, so they can disable user-hostile features and settings that the vendor enables by default.

[kragen]

i don't think debian developers are actually prohibited from becoming employees of the vendor, but i think that if they get caught pushing malware, their dd status is likely to be revoked, and the process that allowed them to become dds is likely to be reviewed. any dd can generally push a change to any debian package to the archive; it's a major level of trust. that's why it's generally not realistic to try to get one of your employees to become a dd

[Goz3rr]

Even with AOT compilation, as someone who loves C# and also does embedded development in C I would personally say a garbage collected language like C# has no place there.

[kragen]

not everything running on a 20-mips 32-bit microcontroller with 2 kibibytes of sram needs to be hard real time and failure-free, and of course the esp32 has hundreds of kibibytes

and, correct me if i'm wrong here, but doesn't c# allow you to statically allocate structs just as much as c does? i'd think you'd be able to avoid garbage collection about as much as you want, but i've never written much beyond 'hello, world' in c#

[runevault]

c# has the concept of value types (which structs are), which are stack allocated. Generics have seen more and more instance of getting a Value type like Value Task for stack allocated async objects. But if you add a class as a member of the struct that is going straight to the heap with all the GC stuff that entails

[kragen]

what about global or static variables of value types? i mean in theory you could stack-allocate whatever you want in your main() method and pass pointers to everything, but that sounds unusably clumsy. but with global variables and/or class variables there would be no problem except for things that inherently require heap allocation by the nature of the problem

[neonsunset]

Static fields may be placed on Frozen Object Heap. The values of static readonly fields may not exist at all if the ILC's static constructor interpreter can pre-initialize it at compile-time and bake the value into binary or codegen. Tiered Compilation does a similar optimization but for all cases. This is with JIT though which is not usable in such environment.

Otherwise, statics are placed in a static values array "rooted" by a respective assembly. I believe each value will be contained by a respective box if it's not an object. This will be usually located in Gen2 GC heap. My memory is a bit hazy on this specific part.

There is no concept of globals in .NET the way you describe it - you simply access static properties and fields.

In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - very different tradeoffs, much like no-std in Rust. As mentioned, there is NanoFramework. Another one is Meadow: https://www.wildernesslabs.co which my friend is using for an automated lab for his PhD thesis.

Last mention goes to https://github.com/bflattened/bflat which supports a few interesting targets like UEFI. From the same author there's an example of completely runtime-less C# as well: https://github.com/MichalStrehovsky/zerosharp. It remains a usable language because C# has a large subset of C and features for manual memory management so writing code that completely bypasses allocations is very doable, unlike with other GC-based alternatives.

[kragen]

i see, thanks! that's exactly the information i was looking for

[runevault]

there are ways (byref I think?) to pass references to stack variables around. And Statics depends. Static const even with stuff like strings would just compile directly into the binary, regular static still has to end up on the Heap.

[fulafel]

GC is fine for many (most?) applications there. For example sensor stuff, display, networking, turning your lights on and off, etc.

[davidhyde]

I believe that you would use dotnet nano for something like that. I used it (or some previous version of it) once many years ago and was very impressed with the productivity and ease of use it offered. Ultimately the lack of community surrounding it drove me to other technologies. Might have changed since then though, who knows!

https://www.nanoframework.net/