4 ms·

I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. > whe

I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. > where they insist that they know better than the user and artificially constrain them "for their own good". I'm not sure where this comes from but if it's the intended design of linux (to not be able to kill tasks in the uninterruptible state), then that's their design. You're free to design your own operating system without this limitation -- though it likely means just taking the other side of the tradeoffs involved here. It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." And you could imagine other solutions that might liberate you from the dilemma entirely, but then that wouldn't be linux anymore.

deleted 8y ago
[deleted]
AnIdiotOnTheNet 8y ago
> I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. Defects happen. This is sorta like saying you don't need ASLR because the real defect is that some code allows buffer overflows. Things don't always work perfectly and when they don't you still need tools to deal with it. > You're free to design your own operating system without this limitation Such an OSS response to criticism. This attitude is awful and a big part of the reason software sucks. > It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.
- wyldfire 8y ago
  > The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option You are way oversimplifying the problem. Linux designers want a nice, stable OS with good performance. Introducing a new mode where signals can asynchronously interrupt a task means that you have to account for your kernel code to not only be safe when CPU interrupts occur, but now when user space signal handlers execute too. To be safe means that you'd need to sprinkle fences/barriers over lots of code. This flushes pipelines and unnecessarily forfeits performance. Performance aside, it's really hard to imagine the problems caused by asynchronous interrupts until they actually occur. As a designer, it's much simpler to just bar them for the critical region. Now, it's totally reasonable for us to discuss 'hey can we minimize these critical regions somehow, to make these problems less likely?' If you did a `kill -9 1234` and then your computer suddenly hit an NMI, whose bug would that be? The kernel's! You'd say "hey, kernel, wtf, I was just trying to reap this process and then my computer rebooted." And you'd be right. There's lots of design decisions made early on in linux that are likely baked in and hard to change without impacting user space. For you to declare it "the least-bad option" you have to be able to evaluate it from the designer's perspective. From the user's perspective, I agree that it's clearly not ideal. But there's much more at stake here. > idea among developers out there that the computer belongs to them and users are beneath them You're introducing some motives that just aren't there. Linux is all about enabling people. Perhaps we can agree that the death of general purpose computing is nigh [1], but it's not linux's fault. >> You're free to design your own operating system without this limitation > Such an OSS response to criticism. This attitude is awful I don't agree. But I will express regret that I didn't say instead "you're free to use another OS without this limitation" -- that's a more realistic option for a user. For a user to casually say "you made the wrong design decision here" without acknowledging the existence of the tradeoff is unfair. [1] https://boingboing.net/2012/08/23/civilwar.html https://boingboing.net/2012/08/23/civilwar.html
  - AnIdiotOnTheNet 8y ago
    Why does such a feature have to be safe? It's for an edge case where something is misbehaving badly, and your only alternative is a reboot. Why shouldn't the user be able to do this as long as they accept the risk? > Linux is all about enabling people Since we're talking about the kernel, I agree for the most part. Which makes it all the more annoying that "reboot" (and sometimes even that doesn't work and you have to smother the system with a pillow) is the only option in this circumstance. I can overwrite disks and memory at will, destroying who knows what data, but I can't kill a useless hung process because it might be unsafe? Admittedly I am ignorant of the details of the kernel implementation, but I have difficulty believing that there is nothing that can be done.

deleted 8y ago

[deleted]

AnIdiotOnTheNet 8y ago

> I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver. Defects happen. This is sorta like saying you don't need ASLR because the real defect is that some code allows buffer overflows. Things don't always work perfectly and when they don't you still need tools to deal with it. > You're free to design your own operating system without this limitation Such an OSS response to criticism. This attitude is awful and a big part of the reason software sucks. > It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.

wyldfire 8y ago
> The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option You are way oversimplifying the problem. Linux designers want a nice, stable OS with good performance. Introducing a new mode where signals can asynchronously interrupt a task means that you have to account for your kernel code to not only be safe when CPU interrupts occur, but now when user space signal handlers execute too. To be safe means that you'd need to sprinkle fences/barriers over lots of code. This flushes pipelines and unnecessarily forfeits performance. Performance aside, it's really hard to imagine the problems caused by asynchronous interrupts until they actually occur. As a designer, it's much simpler to just bar them for the critical region. Now, it's totally reasonable for us to discuss 'hey can we minimize these critical regions somehow, to make these problems less likely?' If you did a `kill -9 1234` and then your computer suddenly hit an NMI, whose bug would that be? The kernel's! You'd say "hey, kernel, wtf, I was just trying to reap this process and then my computer rebooted." And you'd be right. There's lots of design decisions made early on in linux that are likely baked in and hard to change without impacting user space. For you to declare it "the least-bad option" you have to be able to evaluate it from the designer's perspective. From the user's perspective, I agree that it's clearly not ideal. But there's much more at stake here. > idea among developers out there that the computer belongs to them and users are beneath them You're introducing some motives that just aren't there. Linux is all about enabling people. Perhaps we can agree that the death of general purpose computing is nigh [1], but it's not linux's fault. >> You're free to design your own operating system without this limitation > Such an OSS response to criticism. This attitude is awful I don't agree. But I will express regret that I didn't say instead "you're free to use another OS without this limitation" -- that's a more realistic option for a user. For a user to casually say "you made the wrong design decision here" without acknowledging the existence of the tradeoff is unfair. [1] https://boingboing.net/2012/08/23/civilwar.html https://boingboing.net/2012/08/23/civilwar.html
- AnIdiotOnTheNet 8y ago
  Why does such a feature have to be safe? It's for an edge case where something is misbehaving badly, and your only alternative is a reboot. Why shouldn't the user be able to do this as long as they accept the risk? > Linux is all about enabling people Since we're talking about the kernel, I agree for the most part. Which makes it all the more annoying that "reboot" (and sometimes even that doesn't work and you have to smother the system with a pillow) is the only option in this circumstance. I can overwrite disks and memory at will, destroying who knows what data, but I can't kill a useless hung process because it might be unsafe? Admittedly I am ignorant of the details of the kernel implementation, but I have difficulty believing that there is nothing that can be done.