GNU HURD was just updated.
https://www.gnu.org/software/hurd/news/2016-05-18-releases.html
does anyone actually use this kernel? like do you guys really want to be Richard stallmans husbando that bad?
Aren't they participating in Google Summer of Code?
Or as I've recently taken to calling it, GNU plus HURD.
Someone tell a retard what the difference between Hurd and Linux is
>>54626293
Hurd is a microkernel, which basically means that it's shit.
>>54626100
I ran HURD on a VM a while ago. Translators are really cool, I wrote a couple toy ones.
>>54626312
I think your appraisal is incorrect. Linux is terrible -- it's gotten to be bloated, buggy, and full of hacks like c-groups, systemd, and pulse audio. I've used MemeBSD for a couple of years now because it's so much smaller.
The problem is that a Microkernel is complicated. Such complications aren't worth it if you're only supporting one architecture with a small set of hardware configurations -- supporting essentially only ThinkPads. In this case, the monolithic kernel is definitely superior. The problem is that a modern operating system can't get away with such limited support. This has caused kernels like Linux to become bloated messes.
TL;DR: you can't scale a monolithic kernel.
>>54626377
>TL;DR: you can't scale a monolithic kernel.
>After Linux has been scaling for years
>systemd, and pulse audio
Nothing to do with the kernel. Those are userspace things.
>c-groups
What the hell do you have against control groups?
>bloated
You don't have to compile EVERYTHING in, you know.
I run linux-libre and it's pretty nice. Never tried HURD
>>54626100
>Version 0.8
>>54626425
>Nothing to do with the kernel. Those are userspace things.
They're work arounds to bad interfaces exposed by the kernel. The reason why they're so poor is because of fundamental weaknesses in the kernel system, like the "Advanced Linux Sound Architecture."
>What the hell do you have against control groups?
That they accomplish what FreeBSD already had via Jails, in a most non-Unix manner. Again, this is a result of the poor coordination between kernel systems and userspace systems. BSD's don't have this problem, and thus have a better solution.
>You don't have to compile EVERYTHING in, you know
Linux contains 15 million+ LoC. This necessarily implies a much more complicated internal system than a smaller kernel. Therefore, the advantages of a monolithic architecture are completely lost.
>>54626425
https://en.wikipedia.org/wiki/Criticism_of_Linux
Notice the amount of criticisms from Torvalds himself. Linux is becoming unmaintainable, and I do not believe it is a suitable basis for our computing moving forward. I don't think GNU believes this either, hence the rapid advancements of HURD the last couple years.
>>54626511
Not the guy you replied to, but I'll respond to you pointwise for another perspective:
>bad interfaces from kernel
Really varies by interface. Sound and audio has traditionally been shit, but other interfaces are pretty comfy to work with.
>cgroups
Are shit in my opinion as well. BSD jails are great and schroots (not chroot - schroot, which is a more secure variant) work fine as is. Redoing it as control groups is a dumb idea, but now there are a fuckload of people backing it.
>lots of code = complex
I'd say 95% of the kernel's code is #ifdef preprocessor directives wrapping huge blocks of code which can be eliminated.
Of these, I'd say roughly half is hardware support, which is nice to have and can be eliminated if you like, and half is different configurations for kernel-space things like memory allocation, process scheduling, etc. I completely understand your complaint here and agree. At some point, Linus or one of the other maintainers should fork the kernel and clean out all the shit used by 5% of the users and let it be maintained like the 2.6 series kernel.
>>54626603
These steps would move Linux back into fitting into Torvald's vision. It certainly would make Linux based systems much more enjoyable to use.
However, I don't think this can ever happen. There's increasing pressure on kernel developers to optimize more for power consumption, and currently kernel politics are too conservative to support such radical refactoring. This is a result of having such a large use-base. In a way, Linux has a larger use-base than Windows; Windows isn't used in nearly as many environments. Monolithic kernels are not adaptable enough to reliably mold into their surroundings. Too many groups want too many different things out of Linux. It simply can't cater to everyone's needs.
A microkernel architecture allows various needs to be catered to more easily. Yes, there is a significantly larger implementation complexity, but the final product is much more malleable and will work better than a monolithic kernel, but only after a certain point in complexity. I think we're seeing the monoliths surpass this complexity point, resulting in a renewed interest in microkernels.
Does anyone here actually use GNU with the HURD kernel? Is it really that bad compared to GNU/Linux?
>>54626823
Hurd has no drivers.
>>54626591
>Linux is becoming unmaintainable, and I do not believe it is a suitable basis for our computing moving forward.
Forgive me if this is a dumb question, but what exactly does this mean in practical terms? Do you think we're going to see a rise of non-Linux OSes in the future? Would this effect individual desktop users, or just servers (which are obviously still the predominate users of Linux in the world)?
>>54626838
>Forgive me if this is a dumb question, but what exactly does this mean in practical terms?
It becomes harder to maintain code and to change code without introducing new bugs.
>Do you think we're going to see a rise of non-Linux OSes in the future?
The future is a long time.
>>54626829
>Hurd has no drivers
Could some sort of Linux-to-Hurd driver compatibility layer thingy be devised?
>>54626884
Hurd uses linux drivers from before the 3.0 version which was in 2011.
>>54626838
Exactly what
>>54626881
said.
>>54626100
>GNU HURD was just updated.
Welcome to 1995
>>54626736
Why couldn't somebody just split out their own thing and cut the aforementioned chunks of code out, while still maintaining compatibility with main development? Couldn't they sidestep the politics you're talking about this way?
>>54626511
I use ossv4 which is a lot better than alsa, but not as supported unfortunately. Wish someone would rewrite the audio stack.
>>54626312
http://blog.darknedgy.net/technology/2016/01/01/0/
get educated
captcha: 3100 MACH
>>54627121
I admire the fact that you decided to just post a screenshot of an image search instead of choosing one and upload it.
That lack of effort diserves a (you)
Main concern for microkernels is the overhead. However stability is just damn sexy. After recently watching a minux demo where it recovered from an injected fault I could see the value of running a server with security and uptime in mind on minix.
>>54628354
Found the vidya
https://youtu.be/vlOsy0PZZyc
>>54628407
Kind of sad seeing Tannenbaum in this state.
What exactly separates a pure microkernel(ie running basically everything in userspace) from a hypervisor?
>>54628407
Wonder if a fork bomb would crash it...
>>54628657
Hypervisors host other kernels, and manage their allotted hardware.
>>54628882
The way I see them a microkernel is kind of like a type of hypervisor. Each application is running in a sort of virtualized environment like a freebsd jail or solaris zone and when the applications are communicating with one another it's similar to a cluster or an intranet.
>>54626591
This.
You can't possibly expect the free software community has the same mindset of maintaining the unmaintanable corporations like Microsoft have.
Is not that the Linux kernel has a bad model, the fault is on the massive code is being feed upon (nothing rivals on the collaboration).
near future dream os:
a gnu guix system distribution
gnu mach kernel with hurd
shepherd init (previously dmd)
wrapped in wayland and stumpwm (rewritten in scheme)
running emacs
>>54629173
Oh my, that is exactly what I thought when I saw this thread.
>>54629173
>wayland
you should just make Emacs work as the whole graphics stack
>>54627924
My guess would be because that somebody would actually have to be a large group of somebodies putting in tens of thousands of man-hours into dredging through millions of lines of code and figuring out what can and can't be stripped out.
>>54629237
I would like to.
To do it right would require interfacing Emacs and TeX in a way that's still beyond me for now.
I assume it itself could use the Wayland protocol.
Every time I've tried to approach this though, it becomes a chicken or the egg problem and I don't know where/how to proceed.
It'll happen, but maybe not for a while.
>>54629353
maybe you should start with building your own simple WM in wayland
then you will have a feel for what it should be like on the front end
then to make it work on the front end, you can figure out the backend
>30 year old kernel
>still in alpha stage
>>54626122
Not even rms uses it.
