In theory: no. But you obviously need some form of driver to work with your networking card. In theory you could build your own rj-45 connector and control it using gpio pins (voltage might need some adjustments though). The program controlling these pins does not need to be part of the kernel, although it obviously needs the required drivers to use the gpio pins. In practice your network driver is obviously part of the kernel in some form.
There is also layer 2 and 3, pure software functionality in the kernel, for networking between NICs and containers and generally acting like a router (including stuff like WireGuard VPN). If this code wasn't in the kernel, advanced networking would involve a lot more context switches and thus lost performance.
>If this code wasn't in the kernel, advanced networking would involve a lot more context switches and thus lost performance.
Yes, although it is still possible to do it outside the kernel, which is what OP asked.
No, and it shouldn't be. That's what a microkernel is. Microkernels are older than C and Unix.
https://en.wikipedia.org/wiki/RC_4000_multiprogramming_system
Not him but if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?
A monolithic kernel: >won't try to use hardware that's in an invalid state and needs to be power cycled >won't try to keep chugging along when doing so is admittedly possible but would be completely useless because some hardware is offline
How is a microkernel better than this?
It's more clever, sure, and more resilient. But why would you *want* that resilience?
Why would you actually *want* your computer to intelligently avoid power-cycling for as long as possible, thus prolonging the time the hardware spends not functioning?
I guess I can understand that. If all the nodes are acting as one computer at a kernel level, it would be bad for all the nodes to crash and reboot at the same time just because one node's root disk came loose.
>But why would you *want* that resilience?
Some devices need to run unmaintained as long as possible, or will kill someone if they malfunction. In these cases a microkernel design is preferable.
Beyond that it just leads to shitty performance and more complexity.
>Not him but if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?
Are you being sarcastic? Have you ever had a USB drive fail or turned off a printer? Would you want the "whole OS to screech to a halt" in those situations? Consider that on computers higher end than PCs, you can replace drives while it's in use and they have RAID, so you can just swap out a drive that fails instead of the whole thing dying.
>>won't try to use hardware that's in an invalid state and needs to be power cycled >>won't try to keep chugging along when doing so is admittedly possible but would be completely useless because some hardware is offline
Because "some hardware" is not the whole computer. Do you want a bad SD card or hard drive to make your whole computer completely useless, or do you just want an error message that says the device doesn't work so you can replace it with another one?
>Why would you actually *want* your computer to intelligently avoid power-cycling for as long as possible, thus prolonging the time the hardware spends not functioning?
How is power-cycling going to fix broken hardware? If you have hardware that doesn't work, turning off the power would do nothing, except kill everything else you're doing on your computer with no chance to save or fix anything. In case it is a problem that can be fixed by power-cycling, a microkernel will let you do it for just that one device.
Going back to OP, do you want an internet problem to kill your whole OS? How bad do you want your OS to be? Do you want a temporary wifi disconnection to make your OS crash? Are you just trolling me?
>do you want an internet problem to kill your whole OS?
so microkernels solve problems no one has. noted.
2 years ago
Anonymous
I wasn't replying about microkernels, but "if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?" You don't need a microkernel for that.
Yes, good points. So it sounds like for a typical desktop use case, ideally, some drivers are better implemented outside the kernel, and some inside.
Consider: >or hard drive
Yes. If I'm using a desktop computer, and my hard drive that I'm booting my OS off of malfunctions, I want it to make my whole computer crash and reboot. That would be ideal. If there's a boot drive malfunction and my computer doesn't immediately reboot, I'll be stuck unable to do anything whatsoever until I can figure out I have to reboot my computer and possibly fix my drive. Worse still, this might happen while I'm using a productivity tool running from RAM, and who knows how long I'll be working away and periodically hitting ctrl+S before I realize nothing is actually getting saved, and there's nowhere *to* save to, and there can't *be* anywhere to save to either, because even if I plugged something else in, the removable disk drivers are now inaccessible and can't run. Consider, also, the GPU. *On a desktop computer*, if the GPU malfunctions irrecoverably, I would usually like my computer to reboot. Can't debug much with a black screen.
2 years ago
Anonymous
>Yes. If I'm using a desktop computer, and my hard drive that I'm booting my OS off of malfunctions, I want it to make my whole computer crash and reboot. That would be ideal. If there's a boot drive malfunction and my computer doesn't immediately reboot, I'll be stuck unable to do anything whatsoever until I can figure out I have to reboot my computer and possibly fix my drive. Worse still, this might happen while I'm using a productivity tool running from RAM, and who knows how long I'll be working away and periodically hitting ctrl+S before I realize nothing is actually getting saved, and there's nowhere *to* save to, and there can't *be* anywhere to save to either, because even if I plugged something else in, the removable disk drivers are now inaccessible and can't run. Consider, also, the GPU. *On a desktop computer*, if the GPU malfunctions irrecoverably, I would usually like my computer to reboot. Can't debug much with a black screen.
You only need cpu, gpu, ram and internet , the rest don't need to be in the kernel, you can connect remotely
2 years ago
Anonymous
I'd argue, for a desktop or laptop, internet doesn't need to be in there either. For a server it makes sense. But you're also still missing boot drive. I really strongly feel the continued sane operation of a session is logically contingent on the continued availability of the boot drive. Even if you're in ssh or rdp, the frick are you going to do when you're working in geany or whatever and suddenly discover /bin stopped existing 2 hours ago.
2 years ago
Anonymous
>I'd argue, for a desktop or laptop, internet doesn't need to be in there either. For a server it makes sense.
every computer should also be a server >But you're also still missing boot drive.
you can boot from internet >I really strongly feel the continued sane operation of a session is logically contingent on the continued availability of the boot drive. Even if you're in ssh or rdp, the frick are you going to do when you're working in geany or whatever and suddenly discover /bin stopped existing 2 hours ago
there is no difference between a local drive failing or a remote one,
2 years ago
Anonymous
>there is no difference between a local drive failing or a remote one,
There's a very big practical difference between some auxiliary drive failing when you don't need it versus the drive you thought you were actively working on having failed 2 hours ago and you're still sitting there working none the wiser.
2 years ago
Anonymous
>the drive you thought you were actively working on having failed 2 hours ago and you're still sitting there working none the wiser
holy shit, if the drive had some problem, do you think the system will simply not tell the user that some error occurred?
2 years ago
Anonymous
Yes.
I do think that.
I think that because I've experienced that quite recently.
My portable linux install developed a bad sector and would periodically drop offline while I was working and I did not get a pop-up about it
No, only the core GPU driver interaction. Though in practice the network card/ethernet/ip stack is usually in the kernel exposed through operating system apis.
Yes.
In theory: no. But you obviously need some form of driver to work with your networking card. In theory you could build your own rj-45 connector and control it using gpio pins (voltage might need some adjustments though). The program controlling these pins does not need to be part of the kernel, although it obviously needs the required drivers to use the gpio pins. In practice your network driver is obviously part of the kernel in some form.
There is also layer 2 and 3, pure software functionality in the kernel, for networking between NICs and containers and generally acting like a router (including stuff like WireGuard VPN). If this code wasn't in the kernel, advanced networking would involve a lot more context switches and thus lost performance.
>If this code wasn't in the kernel, advanced networking would involve a lot more context switches and thus lost performance.
Yes, although it is still possible to do it outside the kernel, which is what OP asked.
No, and it shouldn't be. That's what a microkernel is. Microkernels are older than C and Unix.
https://en.wikipedia.org/wiki/RC_4000_multiprogramming_system
Not him but if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?
A monolithic kernel:
>won't try to use hardware that's in an invalid state and needs to be power cycled
>won't try to keep chugging along when doing so is admittedly possible but would be completely useless because some hardware is offline
How is a microkernel better than this?
It's more clever, sure, and more resilient. But why would you *want* that resilience?
Why would you actually *want* your computer to intelligently avoid power-cycling for as long as possible, thus prolonging the time the hardware spends not functioning?
microkernels are better for distributed systems
I guess I can understand that. If all the nodes are acting as one computer at a kernel level, it would be bad for all the nodes to crash and reboot at the same time just because one node's root disk came loose.
exactly
>But why would you *want* that resilience?
Some devices need to run unmaintained as long as possible, or will kill someone if they malfunction. In these cases a microkernel design is preferable.
Beyond that it just leads to shitty performance and more complexity.
>Not him but if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?
Are you being sarcastic? Have you ever had a USB drive fail or turned off a printer? Would you want the "whole OS to screech to a halt" in those situations? Consider that on computers higher end than PCs, you can replace drives while it's in use and they have RAID, so you can just swap out a drive that fails instead of the whole thing dying.
>>won't try to use hardware that's in an invalid state and needs to be power cycled
>>won't try to keep chugging along when doing so is admittedly possible but would be completely useless because some hardware is offline
Because "some hardware" is not the whole computer. Do you want a bad SD card or hard drive to make your whole computer completely useless, or do you just want an error message that says the device doesn't work so you can replace it with another one?
>Why would you actually *want* your computer to intelligently avoid power-cycling for as long as possible, thus prolonging the time the hardware spends not functioning?
How is power-cycling going to fix broken hardware? If you have hardware that doesn't work, turning off the power would do nothing, except kill everything else you're doing on your computer with no chance to save or fix anything. In case it is a problem that can be fixed by power-cycling, a microkernel will let you do it for just that one device.
Going back to OP, do you want an internet problem to kill your whole OS? How bad do you want your OS to be? Do you want a temporary wifi disconnection to make your OS crash? Are you just trolling me?
>do you want an internet problem to kill your whole OS?
so microkernels solve problems no one has. noted.
I wasn't replying about microkernels, but "if certain hardware hiccups then isn't it better for the whole OS to screech to a halt?" You don't need a microkernel for that.
Small kernels that communicate with message passing are better for that
Yes, good points. So it sounds like for a typical desktop use case, ideally, some drivers are better implemented outside the kernel, and some inside.
Consider:
>or hard drive
Yes. If I'm using a desktop computer, and my hard drive that I'm booting my OS off of malfunctions, I want it to make my whole computer crash and reboot. That would be ideal. If there's a boot drive malfunction and my computer doesn't immediately reboot, I'll be stuck unable to do anything whatsoever until I can figure out I have to reboot my computer and possibly fix my drive. Worse still, this might happen while I'm using a productivity tool running from RAM, and who knows how long I'll be working away and periodically hitting ctrl+S before I realize nothing is actually getting saved, and there's nowhere *to* save to, and there can't *be* anywhere to save to either, because even if I plugged something else in, the removable disk drivers are now inaccessible and can't run. Consider, also, the GPU. *On a desktop computer*, if the GPU malfunctions irrecoverably, I would usually like my computer to reboot. Can't debug much with a black screen.
>Yes. If I'm using a desktop computer, and my hard drive that I'm booting my OS off of malfunctions, I want it to make my whole computer crash and reboot. That would be ideal. If there's a boot drive malfunction and my computer doesn't immediately reboot, I'll be stuck unable to do anything whatsoever until I can figure out I have to reboot my computer and possibly fix my drive. Worse still, this might happen while I'm using a productivity tool running from RAM, and who knows how long I'll be working away and periodically hitting ctrl+S before I realize nothing is actually getting saved, and there's nowhere *to* save to, and there can't *be* anywhere to save to either, because even if I plugged something else in, the removable disk drivers are now inaccessible and can't run. Consider, also, the GPU. *On a desktop computer*, if the GPU malfunctions irrecoverably, I would usually like my computer to reboot. Can't debug much with a black screen.
You only need cpu, gpu, ram and internet , the rest don't need to be in the kernel, you can connect remotely
I'd argue, for a desktop or laptop, internet doesn't need to be in there either. For a server it makes sense. But you're also still missing boot drive. I really strongly feel the continued sane operation of a session is logically contingent on the continued availability of the boot drive. Even if you're in ssh or rdp, the frick are you going to do when you're working in geany or whatever and suddenly discover /bin stopped existing 2 hours ago.
>I'd argue, for a desktop or laptop, internet doesn't need to be in there either. For a server it makes sense.
every computer should also be a server
>But you're also still missing boot drive.
you can boot from internet
>I really strongly feel the continued sane operation of a session is logically contingent on the continued availability of the boot drive. Even if you're in ssh or rdp, the frick are you going to do when you're working in geany or whatever and suddenly discover /bin stopped existing 2 hours ago
there is no difference between a local drive failing or a remote one,
>there is no difference between a local drive failing or a remote one,
There's a very big practical difference between some auxiliary drive failing when you don't need it versus the drive you thought you were actively working on having failed 2 hours ago and you're still sitting there working none the wiser.
>the drive you thought you were actively working on having failed 2 hours ago and you're still sitting there working none the wiser
holy shit, if the drive had some problem, do you think the system will simply not tell the user that some error occurred?
Yes.
I do think that.
I think that because I've experienced that quite recently.
My portable linux install developed a bad sector and would periodically drop offline while I was working and I did not get a pop-up about it
Watch the second video (erlang), although this is a language, the way it works is similar to a distributed microkernel system
Yes i know. I understand erlang. I really quite like it. But it didn't save my 2 hours of work down the drain
Because you use a monolithic kernel (linux)
Like Erlang, if one process stops working it doesn't affect the whole system and is easy to hot-swap to fix quickly.
?t=568
No, only the core GPU driver interaction. Though in practice the network card/ethernet/ip stack is usually in the kernel exposed through operating system apis.
Guys, i know that TCP is implemented at OS level, but where is HTTP implemented? In the browser or where? Share your knowledge pls.
yeah browser
Nope. The TCP/IP stack can be run from userspace. Linux and other OSes supports running drivers from userspace as well.