I am not sure if uninterruptable sleep is considered "living", but fun experiment.
Show HN: A “living” Linux process with no memory
71–80 of 117 posts
Re: Show HN: A “living” Linux process with no memory
#72Earlier quoted context omitted.
I saw this reply earlier! It was gone by the time I tried writing a response, but I don't feel like it's too far afield at all: it's a really nice response. (And thanks for doing that! It's always nice to see people volunteering for genuinely helpful things like this.) It doesn't seem like it was your fault, and it's understandable that you're frustrated. I don't, however, agree that anything written in Python 2 is c…
> Python 2 is nicer to write from some perspectives, and, for example, the idea of somebody who didn't like Perl 6's changes being told to write Perl 6 instead of Perl 5 or else they were being harmful doesn't really make sense either. Except Perl 6 (Raku) is now marketed as an entirely separate language , whereas Python 3 is the version of Python that has superseded Python 2.
Raku's renaming was recent. It took 19 years to happen. Python 3 still has time to be renamed!
Re: Show HN: A “living” Linux process with no memory
#73Earlier quoted context omitted.
...use the hammer that didn't arbitrarily break compatibility, then? (Note that the original analogy pointed out that they couldn't be mixed, anyway: "or even take advantage of the nails you've hit!") This is like complaining that the well is poisoned when you're the one who put arsenic in it. This also isn't even an open source project, so it's not like you can mix and match anyway.
I didn't make python 3, and "stick on python 2 forever" doesn't seem like the solution here as far as I can tell. > This also isn't even an open source project, so it's not like you can mix and match anyway. Again focusing on the execution of one specific project, as-is, is beside the point of "get everyone on the same hammer".
I didn't make python 3
No, but you're complaining about a person using Python 2, the one that didn't arbitrarily break compatibility, while promoting the use of Python 3 because not being compatible is bad.
Again focusing on the execution of one specific project, as-is, is beside the point of "get everyone on the same hammer".
I agree with this.
Re: Show HN: A “living” Linux process with no memory
#74As someone who doesn't understand much of what's going on here, what resources would you suggest I study to improve?
It kind off depends on what exactly you don't understand, but a book about Operating Systems and Linux Programming are probably what you want to read. They'll teach you about threads, segfault, the meaning of uninterruptible sleep, signals, the /proc/ directory, etc.
Can you suggest a book about Operating Systems?
Re: Show HN: A “living” Linux process with no memory
#75I've now seen a similar case multiple times in the wild - if a process has a thread in uninterruptible sleep (e.g., blocked on a bad disk or a stuck network filesystem) and you kill it, the process dies, but the kernel waits forever for that thread before informing the parent process. The parent doesn't get SIGCHLD, and wait() doesn't return. (So, for example, your favorite init/supervisor won't restart the process o…
For anyone who was wondering, I found a post explaining why threads can be in "uninterruptible sleep" in the first place: https://eklitzke.org/uninterruptible-sleep
On this article, one of the tricks you can do to avoid the hung NFS client reboots is to quickly alias the NFS server IP onto the local device (ip addr add ...). This basically causes the networking layer to act like the NFS server went away but also return a RST (reset) network packet to that effect, allowing the failure to propagate upwards to the rest of the stack and unhang.
Re: Show HN: A “living” Linux process with no memory
#76how does the FUSE filesystem interact with the c program running? I don't see the C program attempting to r/w to that x directory
Re: Show HN: A “living” Linux process with no memory
#77Earlier quoted context omitted.
It kind off depends on what exactly you don't understand, but a book about Operating Systems and Linux Programming are probably what you want to read. They'll teach you about threads, segfault, the meaning of uninterruptible sleep, signals, the /proc/ directory, etc.
Can you suggest a book about Operating Systems?
"Operating System Concepts" by Silberschatz, Galvin and Gagne, is a classic. It covers the basics: processes, syscalls, filesystems. (it's what we read in our OS course in university)
Re: Show HN: A “living” Linux process with no memory
#78Earlier quoted context omitted.
> I got hired. So, for money.
I've had projects that - eventually and incidentally - brought me money, but were not started or done for money.
The thing about the "money" argument is that one could just as strongly claim that you went to 1st grade "for money".
Re: Show HN: A “living” Linux process with no memory
#79Earlier quoted context omitted.
For anyone who was wondering, I found a post explaining why threads can be in "uninterruptible sleep" in the first place: https://eklitzke.org/uninterruptible-sleep
On this article, one of the tricks you can do to avoid the hung NFS client reboots is to quickly alias the NFS server IP onto the local device (ip addr add ...). This basically causes the networking layer to act like the NFS server went away but also return a RST (reset) network packet to that effect, allowing the failure to propagate upwards to the rest of the stack and unhang.
Unplugging the ethernet cable usually also works.
Re: Show HN: A “living” Linux process with no memory
#80Earlier quoted context omitted.
I've had projects that - eventually and incidentally - brought me money, but were not started or done for money.
The thing about the "money" argument is that one could just as strongly claim that you went to 1st grade "for money".
And at the end, we end up with the capitalists dream: "I was born... for money"