Can you do it without shutting down X, and all running X applications? Is that really so different than than a reboot?
Well, it depends how you use the system.
If you're familiar with Windows and use Linux mostly like a Windows workstation, running only GUI programs, and running only daemons that are inextricably linked to a GUI, then no.
My system is generally running mldonkey, a host of daemons and scripts (fetching mail, sending mail, obtaining weather data, logging uptimes, a couple of servers) and it isn't even a "server" machine. I use GNU screen, so just because I happen to have a shell open in an xterm doesn't mean that I can't log out at any time. Most of the software I use (barring firefox and gkrellm) is terminal-based, so most of that sits in GNU screen. I use irssi (not x-chat), slrn (not pan). Occasionally I'll have the GIMP open, but I'm not an artist, so this is usually not the case. I use the X11 version of xemacs for the additional keys available, but xemacs doesn't need to be hooked up to a single X session (actually, it can display itself on multiple X servers at once), and shutting down X doesn't have to kill it.
So, really, the only piece of software that needs lose state during a restart of X is my webbrowser. It's difficult to describe this to most Windows users, because they have a very strong and repeated set of experiences that "real software runs in a GUI".
A reboot also means that I have to reauthenticate myself to my encrypted filesystems, which is the other reason that I prefer to avoid it.
So I would say that, yes, a reboot of my system is very different from restarting X.
The real cause of most reboots are attempts to replace active user-mode executables (EXE or DLL). Executable files cannot be replaced while they're running. This makes it practically impossible to update system DLL's without a reboot, since they're going to running in some process all the time.
Yup. This is a major design flaw in the Windows kernel that dates way back. It's a significant part of the reason that you don't have to reboot Linux for anything other than a new kernel, but Windows frequently needs to be rebooted for user-level application installations.
It's on my list of "stupid design decisions made in Windows" (where "Windows" == NT family, not 9x family).
Other goodies are:
* "pageable kernel memory pools" (sounds like a good idea, but significantly increases complexity of writing kernel code and ease of introducing lockup bugs) over Linux's approach of just unloading modules
* Microsoft's decision to not support "real" links, just shortcuts, in their user-mode software.
* Allowing application software to "block" a shutdown.
* Not allowing Windows to run without VM.
* Not designing Windows to be able to run off of read-only media.
* Godawful shell (not fundamental to the OS, and hopefully will fixed in Longhorn) and virtual terminal, to the point where most Windows users hate the terminal.
* Bad VM algorithms. I don't know what they use, but try running low on memory on a Windows box and the system becomes bloody unusable.
(From a developer standpoint)
* Poor sockets implementation (which is still the only reasonably portable networking API under Windows -- even IOCP lacks a IOCP-able connect() up until WinXP) with no way to kick select() awake, no local-domain sockets and lots of other flaws and irritations that have to be worked around by the Windows sockets programmer.
* Never precisely specifying API behavior -- MSDN is more of a tutorial or basic user guide to the API than a true specification. Look at a Linux man page and you generally have pretty strong guarantees on the behavior of the function provided, and that isn't even the specification (those which the function conforms to are listed and you can read a hard specification of guaranteed behavior).
This is worthwhile if an organization is small enough that it is not worthwhile to have a dedicated person for each task.
If you only need software written a small amount of the time, sure, it's stupid to have a full-time programmer who just drinks coffee the time he isn't working on the payroll. If "one person unit" is a larger unit than you require (or you only need any one task some of the time) it's stupid to hire a specialist. As you said, get a jack-of-all-trades.
That doesn't mean that it's a good idea to run out and eliminate all the software developers at a random software dev house with IT workers. The reason why is that it's cheaper to hire someone that doesn't have as large a skillset if you don't need that full skillset, and a specialist will likely be better within their field.
For example, lets say that a company does 50% database work and 50% kernel development work. If that company is small and one person can do both, sure, it's probably very worthwhile to get someone that can do database and kernel work. He isn't going to cost what one person that can do database work plus one person that can do kernel work will cost. Same goes with work that is very "bursty", if you might have two months of just database work and then two months of just kernel work.
I assume that this is your case, as you have mentioned "try to keep busy".
It would be fucking stupid, though, to get two people that know kernel and database work in a case with steady workload, because people that know both are going to be expensive and probably not be as good in either field as someone that does nothing but one or the other. You'd be much better off with one kernel and one database guy.
Sometimes I press the off switch and some asshat program pops up a window and says that it won't terminate until I move the mouse to some little point on the window and click it. I can't do that because I've already turned the monitor off. I come back hours later and the fucking machine is still ON!
Yes. This, I would say, is misbehavior on the part of a program. If a program refuses to shut down until something is saved, it is buggy. It can save that data to an "unsaved documents" folder if it wants and bring it up next boot, but this behavior is not correct with respect to handling the user's wishes.
Linux is the worst PC operating system in this regard. Press the off key and the system reacts like you're trying to shut down the Defense Department. Page after page of scrolling lines indicating that this and that mickey-mouse section of the OS is exiting. Who gives a fuck? Just turn off! Now!
Three points:
First, Linux prints out some text describing what is being shut down. I don't see what is wrong with it. This, in and of itself, does not hurt you.
Second, you want the system instantaneously off. I agree that this would be nice, but currently programs store a tremendous amount of state in volatile RAM, and it simply is not feasible to shut off instantly -- it is not a technical problem that the OS can solve (if you are unwilling to do a hibernate, which someone else suggested -- presumably not, since if you were your problem would already be solved). You can execute a hard power-off on modern PCs, where you hold down the power button for five seconds, and the legs are yanked out from under the OS and all applications. If you are using journalling filesystems, an option under Linux, you need not worry about filesystem corruption in such a case, though applications may be partway through writing a file, and you may thus lose the data that you are working on. No general-purpose OS does a full shutdown immediately.
Third, Linux distributions, unlike Windows, *do* always shut down when you hit the power key (barring bugs in the script that the OS runs when shutdown is initiated or bugs in the kernel). It does not let an application block the OS from shutting down -- if the application takes too long to shut down, it's going to be blown away by the OS. If the user wanted to save some data in an application, presumably they wouldn't have pushed the soft power button. There is some text printed out describing the daemons shutting down, but what I see as the real problem, the fact that a program can block a user-initiated shutdown, only exists on Windows, and is not a Linux problem.
I just can't see why you're particularly upset with Linux here, which I view Linux is superior to most other OSes on this point.
I'm not trying to flame, I just haven't seen this be an issue with games in a long time.
That's because NAT has been around for long enough that you can't write a game that doesn't cope with it.
This means, however, that all of them have to use TCP (inbound, at least), a system that was never designed for real-time data. (Unless you're a network guru and know what "port forwarding" is.)
Today's games have high budgets. It's worth it to spend the extra money doing some development on your network code to produce something that outperforms TCP for your particular application. Unfortunately, people with NAT cannot take advantage of this.
Still not convinced? VoIP's a big up-and-coming application, and the same limitations apply to it.
How about security? You feel comfy behind that NAT box, after all. Well, think about that for a moment. What's the point? You can make a box that can do the exact same filtering that the NAT mechanism forces on users. The difference is that they can do more with IPv6 -- you can stick everything directly on the Internet, you can have a firewall that limits a few things, you can have an system that out-of-box blocks everything that a NAT box would plus operates as a transparent HTTP proxy. NAT is an ugly hack, a workaround, and the only reason that it's still here is because there's still enough IPv4-only hardware out there (which is on its way out, as systems are replaced).
I remember seeing someone charged with desecration of a corpse, so at least in some places in the States, it is.
Seriously, I don't care. You're dead, you don't care, and if it makes someone happy, go to.
'course, some people refuse to be organ donors, so what can I say...
Techies have had many, many opportunities to make encryption support easy to use and transparent in products, and it hasn't happened. If they had, lots of people would use encryption; because they haven't encryption can be used as a discriminating factor between the ordinary and the dubious.
Slashdot Mirror
Can you do it without shutting down X, and all running X applications? Is that really so different than than a reboot? Well, it depends how you use the system. If you're familiar with Windows and use Linux mostly like a Windows workstation, running only GUI programs, and running only daemons that are inextricably linked to a GUI, then no. My system is generally running mldonkey, a host of daemons and scripts (fetching mail, sending mail, obtaining weather data, logging uptimes, a couple of servers) and it isn't even a "server" machine. I use GNU screen, so just because I happen to have a shell open in an xterm doesn't mean that I can't log out at any time. Most of the software I use (barring firefox and gkrellm) is terminal-based, so most of that sits in GNU screen. I use irssi (not x-chat), slrn (not pan). Occasionally I'll have the GIMP open, but I'm not an artist, so this is usually not the case. I use the X11 version of xemacs for the additional keys available, but xemacs doesn't need to be hooked up to a single X session (actually, it can display itself on multiple X servers at once), and shutting down X doesn't have to kill it. So, really, the only piece of software that needs lose state during a restart of X is my webbrowser. It's difficult to describe this to most Windows users, because they have a very strong and repeated set of experiences that "real software runs in a GUI". A reboot also means that I have to reauthenticate myself to my encrypted filesystems, which is the other reason that I prefer to avoid it. So I would say that, yes, a reboot of my system is very different from restarting X.
The real cause of most reboots are attempts to replace active user-mode executables (EXE or DLL). Executable files cannot be replaced while they're running. This makes it practically impossible to update system DLL's without a reboot, since they're going to running in some process all the time.
Yup. This is a major design flaw in the Windows kernel that dates way back. It's a significant part of the reason that you don't have to reboot Linux for anything other than a new kernel, but Windows frequently needs to be rebooted for user-level application installations.
It's on my list of "stupid design decisions made in Windows" (where "Windows" == NT family, not 9x family).
Other goodies are:
* "pageable kernel memory pools" (sounds like a good idea, but significantly increases complexity of writing kernel code and ease of introducing lockup bugs) over Linux's approach of just unloading modules
* Microsoft's decision to not support "real" links, just shortcuts, in their user-mode software.
* Allowing application software to "block" a shutdown.
* Not allowing Windows to run without VM.
* Not designing Windows to be able to run off of read-only media.
* Godawful shell (not fundamental to the OS, and hopefully will fixed in Longhorn) and virtual terminal, to the point where most Windows users hate the terminal.
* Bad VM algorithms. I don't know what they use, but try running low on memory on a Windows box and the system becomes bloody unusable.
(From a developer standpoint)
* Poor sockets implementation (which is still the only reasonably portable networking API under Windows -- even IOCP lacks a IOCP-able connect() up until WinXP) with no way to kick select() awake, no local-domain sockets and lots of other flaws and irritations that have to be worked around by the Windows sockets programmer.
* Never precisely specifying API behavior -- MSDN is more of a tutorial or basic user guide to the API than a true specification. Look at a Linux man page and you generally have pretty strong guarantees on the behavior of the function provided, and that isn't even the specification (those which the function conforms to are listed and you can read a hard specification of guaranteed behavior).
This is worthwhile if an organization is small enough that it is not worthwhile to have a dedicated person for each task. If you only need software written a small amount of the time, sure, it's stupid to have a full-time programmer who just drinks coffee the time he isn't working on the payroll. If "one person unit" is a larger unit than you require (or you only need any one task some of the time) it's stupid to hire a specialist. As you said, get a jack-of-all-trades. That doesn't mean that it's a good idea to run out and eliminate all the software developers at a random software dev house with IT workers. The reason why is that it's cheaper to hire someone that doesn't have as large a skillset if you don't need that full skillset, and a specialist will likely be better within their field. For example, lets say that a company does 50% database work and 50% kernel development work. If that company is small and one person can do both, sure, it's probably very worthwhile to get someone that can do database and kernel work. He isn't going to cost what one person that can do database work plus one person that can do kernel work will cost. Same goes with work that is very "bursty", if you might have two months of just database work and then two months of just kernel work. I assume that this is your case, as you have mentioned "try to keep busy". It would be fucking stupid, though, to get two people that know kernel and database work in a case with steady workload, because people that know both are going to be expensive and probably not be as good in either field as someone that does nothing but one or the other. You'd be much better off with one kernel and one database guy.
Sometimes I press the off switch and some asshat program pops up a window and says that it won't terminate until I move the mouse to some little point on the window and click it. I can't do that because I've already turned the monitor off. I come back hours later and the fucking machine is still ON!
Yes. This, I would say, is misbehavior on the part of a program. If a program refuses to shut down until something is saved, it is buggy. It can save that data to an "unsaved documents" folder if it wants and bring it up next boot, but this behavior is not correct with respect to handling the user's wishes.
Linux is the worst PC operating system in this regard. Press the off key and the system reacts like you're trying to shut down the Defense Department. Page after page of scrolling lines indicating that this and that mickey-mouse section of the OS is exiting. Who gives a fuck? Just turn off! Now!
Three points:
First, Linux prints out some text describing what is being shut down. I don't see what is wrong with it. This, in and of itself, does not hurt you.
Second, you want the system instantaneously off. I agree that this would be nice, but currently programs store a tremendous amount of state in volatile RAM, and it simply is not feasible to shut off instantly -- it is not a technical problem that the OS can solve (if you are unwilling to do a hibernate, which someone else suggested -- presumably not, since if you were your problem would already be solved). You can execute a hard power-off on modern PCs, where you hold down the power button for five seconds, and the legs are yanked out from under the OS and all applications. If you are using journalling filesystems, an option under Linux, you need not worry about filesystem corruption in such a case, though applications may be partway through writing a file, and you may thus lose the data that you are working on. No general-purpose OS does a full shutdown immediately.
Third, Linux distributions, unlike Windows, *do* always shut down when you hit the power key (barring bugs in the script that the OS runs when shutdown is initiated or bugs in the kernel). It does not let an application block the OS from shutting down -- if the application takes too long to shut down, it's going to be blown away by the OS. If the user wanted to save some data in an application, presumably they wouldn't have pushed the soft power button. There is some text printed out describing the daemons shutting down, but what I see as the real problem, the fact that a program can block a user-initiated shutdown, only exists on Windows, and is not a Linux problem.
I just can't see why you're particularly upset with Linux here, which I view Linux is superior to most other OSes on this point.
I'm not trying to flame, I just haven't seen this be an issue with games in a long time.
That's because NAT has been around for long enough that you can't write a game that doesn't cope with it.
This means, however, that all of them have to use TCP (inbound, at least), a system that was never designed for real-time data. (Unless you're a network guru and know what "port forwarding" is.)
Today's games have high budgets. It's worth it to spend the extra money doing some development on your network code to produce something that outperforms TCP for your particular application. Unfortunately, people with NAT cannot take advantage of this.
Still not convinced? VoIP's a big up-and-coming application, and the same limitations apply to it.
How about security? You feel comfy behind that NAT box, after all. Well, think about that for a moment. What's the point? You can make a box that can do the exact same filtering that the NAT mechanism forces on users. The difference is that they can do more with IPv6 -- you can stick everything directly on the Internet, you can have a firewall that limits a few things, you can have an system that out-of-box blocks everything that a NAT box would plus operates as a transparent HTTP proxy. NAT is an ugly hack, a workaround, and the only reason that it's still here is because there's still enough IPv4-only hardware out there (which is on its way out, as systems are replaced).
That sort of thing would only sound plausible...in Japan.
I remember seeing someone charged with desecration of a corpse, so at least in some places in the States, it is. Seriously, I don't care. You're dead, you don't care, and if it makes someone happy, go to. 'course, some people refuse to be organ donors, so what can I say...
Techies have had many, many opportunities to make encryption support easy to use and transparent in products, and it hasn't happened. If they had, lots of people would use encryption; because they haven't encryption can be used as a discriminating factor between the ordinary and the dubious.