We need to start boycotting the #Linux kernel, with the way it's BFDL (no longer benevolent) is behaving. I mean read this:
> Torvalds answered that the kernel project only wants serious developers. That includes having access to enough resources to function in this world.
This is so Eurocentric, so Americanized that it doesn't realize how much work people from the "Third World" have done for #FreeSoftware and the kernel. It's extremely offensive.
@divyaranjan When was he ever "benevolent"?
- replies
- 1
- announces
- 0
- likes
- 1
@SpaciousCoder78 I'm not a fan of BSD licensing. But yeah it's also an alternative.
@divyaranjan @janneke I could help come up with a list of low-level things to hack on (mostly glibc, possibly Hurd or Mach), things we would need for the Shepherd or for Guix for proper support.
@civodul @divyaranjan @janneke what is the LLM policy on gnu Hurd?
@tusharhero @divyaranjan
You do know he is a big time douche.
@divyaranjan It would be nice to have different kernels except hurd and linux, something like NetBSD would be nice. It uses GCC at least and much more portable than Linux.
The last time I have used Hurd the limitation was smp support, that was blocking multithread usage. It runs fine on 2 threads or something like that, but if you bring 12-16 it doesn't. But maybe there are workaround for that or I used outdated HURD kernel from Debian project.
@w96k Yes, we should also be compatible with NetBSD kernels. Basically we need alternatives other than linux that are usable.
@divyaranjan @janneke That is a question you should take directly to the #hurd developers.
I'd be very interested in that list @civodul, given my work on scheme native mach support (nlnet proposal pending). Currently I am able to parse existing mig interfaces and call foreign libraries. Next to that I am working on composing and sending mach messages directly from scheme.
@regtur Wo0t!
Of the top of my head: timerfd and signalfd, clock_nanosleep with CLOCK_THREAD_CPUTIME_ID (for Fibers).
We would also need to have a shared interface for process virtualization between the Hurd and Linux (process namespaces). Porting the Linux namespace interface to the Hurd is probably not feasible/desirable though; perhaps a better approach would be a common, higher-level interface that works on both.