Actually if you look at your settings you'll find you can have several different things happen when a service crashes.
Generally the first thing the service does is try to RESTART itself quietly, if that fails numerous times it then tells you about it and gives you the chance to RELOAD it, if that fails it shuts down the box unless you tell it otherwise.
This is what happened with blaster and the RPC service, the service wasn't set to notify you by default, just to take down the system.
Actually all of these would be good things if you ask me:
Knowning when the ladies are in heat... that can't be bad at all. Evolution took this out because we don't need it to survive.. what we need and what we want aren't always the same thing.
Extra furrowed forehead which gives better vision, better vision sounds good. The cosmetic affect after all is irrelevant, when everyone has this it won't "look bad" anymore.
Yup, the gui is better for looking at pretty pictures or working with things which are by nature visual (the web, graphics work, games... decent games on the command line simply impement their own built in gui).
There are certain times the gui can be faster (selection of 30 files in directory that is 12 levels deep and when there is no text pattern to the selection). Arbitrarily looking through files for something other than a text based pattern is also faster in the gui... it's a visual thing and the gui does visual better after all.
highlight/middle-click is indeed a nice feature. What is NOT a nice feature is the seperate buffer.
BOTH of the extra buffers should be eliminated. All that is needed is one buffer, or better yet, for it to be selectable. Three options for X. Single buffer with and without middle-click, dual-buffer.
Personally I love highlight copying, it's much faster, middle click pasting is NOT faster than what I can achieve with my pinky already on ctrl and my forefinger already on the v before my mouse gets where it's going. (pretty much everytime, keystrokes are faster than mouse movements or clicks).
*sigh* I guess I'm already spoiled by highlight copying but don't want to give up the advantages of the keystrokes either and want the ability to mix the two.
Surely you can't deny for instance, that in a text box like the one we type our comments in, there is no reason for your fingers to ever leave the keyboard.
"Surely you can't deny for instance, that in a text box like the one we type our comments in, there is no reason for your fingers to ever leave the keyboard."
I challenge you to beat my time copying and quoting that text if you have to touch a mouse. Try it both ways and claim the mouse is faster (assuming you know the most basic keys for manipulating the text, like pressing home and then shift+end to highlight a line and shift down to highlight two, etc).
Now try to claim you've never highlighted something with the mouse and wanted to alt+tab to a text editor or word processor and ctrl+v the text in because it's faster than positioning the mouse and middle-clicking.
The way I see it, there are: 1. ctrl+v 2. middle-click 3. right-click paste 4. edit-paste 5. ctrl+x 6. right-click cut 7. edit+cut 8. ctrl+c 9. highlight 10.edit+copy 11.right-click copy
11 fundemental copying/cutting/pasting functions, What sense does it make to have 9 of them operate on the same buffer but pick two random ones to operate on a different buffer and be incompatible with all the others?
Yes I know what the site and documentation say. You are correct full support is not marked stable yet.
In REALITY I've been using full blown NTFS write support for 2yrs without a single corruption.
Now that is without doing anything particularly fancy, I wouldn't go trying to run your system on it. I generally treat it as FAT32 in terms of what I expect to work or even try.
No symlinks, no attempting to do anything with permissions, and of course you wouldn't touch any NT system or operating files or folders, just data.
Sometimes permissions are nuked (the reason for the above) but of course those files can be reowned by the NT administrator and I'd hardly call it corrupted.
No it's not ready for the masses, but if you've got 2 Neurons floating around and managing to spark now and then (unlike the masses) and a bit of common sense then NTFS write support works just fine. Especially in a dual boot scenerio like we are talking about where data-exchange between OS's is all that's needed.
Yup, been using it for about 2yrs now without a hitch.
The part which is no longer marked experimental isn't full write support however. A couple people corrected me on that and I double checked and their correct.
However you can still turn on NTFS write support and NTFS write support has worked great for me since I'd say about midway through the 2.4 kernel series. No special trick, just turn it on and use it.
A few disclaimers, i'm not even sure I've used it since using a 2.6 kernel, I'm not sure I haven't either to be honest but I know I never had a problem from the default rh9+freshrpms updates kernel on up. Aside from NT passhack floppies I'm not sure I've used anything but a redhat kernel (I don't know of any redhat specific patches for it though).
Second, I KNOW I've never tried to chown/chmod or create symlinks. Creating files and directories I've done without problems. Resizing files??? Not sure what you mean here, if you mean opening a text file and adding more to it yes.
Deleting files is not an issue. Basically I've used it as a transfer partition on dual boot systems (both ways), for data recovery (in read scenerios and to transfer from the bad drive to the good ntfs partition so write as well).
Not sure I've even tried to read an NTFS compressed or encrypted partition as well.
Really I've had no problems. Everything I've tried has worked but my needs have never included actually mounting the drive and using it as a true linux mount. Just a place to copy that latest windows only app I want to take a peek at or my latest svcd images if low on space on my home system. At work I use NTFS write all the time to recover data.
My general rule of thumb is to treat an NTFS partition like a fat32 partition. And of course you probably wouldn't want to touch windows system files on the drive since you'll likely lose permissions on them but if that's corruption I'm the easter bunny, the administrator can own the files.
ok apparently I misinterpreted as much as the mac guy, at least on what your talking about.
I was wondering how that really matched, and could only see the delay thing.
I suppose they could be talking about application switching, I read it as having different context related functions occured based on the length of time a click occured on an icon. Like a tap results in selection, a tap that sticks (like dragging without the drag) brings up a menu similar to right clicking, and a double tap opens the app.
I'll re-read it, I'm sure one of us is right. If it's worded badly enough they could swing the patent either way, depending on who they feel it's more valuable to sue.
You missed the point. The patent is for causing a function to happen when you click and hold down the button for a length of time.
The grandparent was jesting that it was easy to replicate by loading up enough applications (thus slowing a windows system to a crawl, since windows, including nt/2000/xp doesn't handle multi-tasking very well). Then you press alt-tab and after enough time passes you get the next application, thus (kinda) replicating the functionality in the patent.
Apparently you missed this and thought he was just asking if there was a key command for application switching in MacOS. Completely missing the whole thing about being able to bog down the system so that there was a delay between the switches.
So if you load up say, 5 instances of IE, 6 instances of photoshop and a 3d game, is there a noticable delay when switching between applications on OSX?
Ok, it's obvious to get my fellow *nix geeks to buy into this philosophy I need concrete examples of improved functionality.
1. Everyone knows the problem with obliterating urls and broken apps. Yes there are ways around most of it and other ways of doing things, that's not the point.
2. It's faster, I challenge you to use one hand to do faster what I can do with two in parallel. While using the mouse my fingers can rapid fire their corresponding functions. Generally the my fingers are ready to ctrl+v faster than my mouse gets to where the paste is going... since like most users I actually only have two fingers on the mouse it takes longer to move a finger to the middle button than it does to press the v key.
3. If you actually wanted to, although it's a tad clunky you can right-click+copy and right-click+paste. Even in windows or MacOS I can copy and paste without ever touching the keyboard. In fact this is how your average windows or mac user actually does it.
Actually I don't know of anywhere else this is the convention... but close.
In Mozilla/firebird ctrl+u blasts the entire line, so long as the cursor is in the location bar... BUT it doesn't matter where in the location bar, the cursor can actually be at the beginning and ctrl+u will STILL blast the entire line.
In bash, emacs, etc ctrl+u blasts all characters to the left of the cursor, not the entire line (unless the cursor is at the end of the line).
I'd disagree, I like middle-click just fine, but it would be better to add support to the terminals for the control, right-click and edit menu options and drop middle-click if it was one or the other.
middle-click is x windows only, the others are the de facto standard in the graphical world (not just windows).
Ctrl+U in windows, or when you don't have the cursor in the location bar is view source.
If you have the cursor (as in the blinking text cursor, not mouse) anywhere in the location bar it clears the full bar.
CTRL+U works in other apps as well, although elsewhere it generally nukes the line up to the cursor, instead of the whole line whereever the cursor is.
Unfortuntely there's no linix equivelent. Although I can switch between applications using alt-tab, it doesn't really seem to matter how many I open (short of completely exhausting ram+swap and thus crashing the machine) there is no noticeable time delay when switching.
Must be the overhead of the gui on the mac, surely it's not a BSD thing.
"The only brokenness is the number of old apps that don't use the selection and clipboard correctly. If you stick to well-written applications you really don't even need to know about the selection/clipboard duality. But you'll be more effective if you do understand and exploit it."
No, the brokeness is working in an unfamiliar manner compared with EVERY other graphical system in existance without ANY actual gain.
I really don't see how you'd exploit it, it offers nothing that multiple clipboard support doesn't already offer. The best you could hope for is to cope with it.
A well written application would what, copy the data from either method to the clipboard for both? Seems a little pointless to me this way.
Or support both methods... great but what if a person uses the keyboard for some things and the mouse for others and sometimes needs to switch between the two modes of working? Not knowing about the two imcompatible implementations would be a tad troublesome there I imagine.
"I have two different systems for heating food in my kitchen. Is that broken? No, and neither is X cut-n-paste, for the same reason. The two different systems are separate, distinguishable and serve different purposes."
Let's hit this in reverse;) Serve different purposes? Gee, I thought they were just incompatible methods for doing the EXACT SAME THING, that would be selecting information, making a copy of it to a buffer, and pasting it into another application. Correct me if I'm wrong that's NOT the purpose of the clipboard in ANY implementation.
Distinguishable. Well I suppose if you ignore that fact that the same commands were implemented in numerous guis before X/Gnome/KDE and have a De Facto if not published behavior on which the X/WMofchoice methods don't improve in any fashion.
Let's come up with something a bit closer to home than appliances which are seperate devices and perform seperate functions. After all the only reason you have two is that although what they do is vaguely related in the sense of preparing food via heat, they are otherwise unrelated. All Microwaves behave more or less similarly and all ovens as well.
Here, closer we have(takes a minute to come up with something else broken in this fashion and decides he needs to make up a scenerio), Twelve modems of identical look, feel, weight, shape, size, color, and capabilities.
All the modems need to have a function to dial. 11 of the modems use the command ATDT# for this purpose, the last modem has a similar command, still ATDT, but it has three jacks (the other not being used and hidden under the plastic casing of the modem). While ATDT is implemented, instead of the standard behavior, ATDT1# dials out on one of the jacks and ATDT0# dials out on the other jack.
This is pretty much the same thing, while the behavior the copy and paste commands is a de facto standard, there are two+ implementations under linux which each implement a portion of it and are incompatible with eachother and none of them are compatible with the de facto standard. The only gain is the other port (clipboard) but it's hidden underneath the plastic where you have to hunt for it. There are also plenty of other modems which add superior functionality and DON'T break the standard.
Due to memory concerns you'd want to limit the size of clipboards as well as the number, or perhaps limit the total clipboard contents size for an unlimited number of clipboards.
There is no reason that both the limit and the number couldn't be set in a configuration file. Having clipboards be generated on the fly probably wouldn't be such a hot idea, it'd add uneeded complexity back into the concept.
I'd agree, though I believe the number should be static, I believe the static number should be user defined rather than hardcoded. Much like multiple desktops.
A good solid implementation should be ok, particularly with a keystroke combo to switch between clipboards.
10 was a random pick meant to be so ridiculously high that nobody could whine it wasn't enough. Personally I doubt I'd use more than 3 and generally wouldn't even use 2. I'd think 5 would actually probably be enough to keep the power clipboarders at it... any more than that would get confusing.
Slashdot Mirror
Actually if you look at your settings you'll find you can have several different things happen when a service crashes.
Generally the first thing the service does is try to RESTART itself quietly, if that fails numerous times it then tells you about it and gives you the chance to RELOAD it, if that fails it shuts down the box unless you tell it otherwise.
This is what happened with blaster and the RPC service, the service wasn't set to notify you by default, just to take down the system.
At least until you bench an operation which requires REAL performance ;)
Actually all of these would be good things if you ask me:
Knowning when the ladies are in heat... that can't be bad at all. Evolution took this out because we don't need it to survive.. what we need and what we want aren't always the same thing.
Extra furrowed forehead which gives better vision, better vision sounds good. The cosmetic affect after all is irrelevant, when everyone has this it won't "look bad" anymore.
Improved hearing, this is bad?
Yup, the gui is better for looking at pretty pictures or working with things which are by nature visual (the web, graphics work, games... decent games on the command line simply impement their own built in gui).
There are certain times the gui can be faster (selection of 30 files in directory that is 12 levels deep and when there is no text pattern to the selection). Arbitrarily looking through files for something other than a text based pattern is also faster in the gui... it's a visual thing and the gui does visual better after all.
For everything else, the cli is obviously faster.
Yes, my mind automagically inserted the wrong key there.
highlight/middle-click is indeed a nice feature. What is NOT a nice feature is the seperate buffer.
BOTH of the extra buffers should be eliminated. All that is needed is one buffer, or better yet, for it to be selectable. Three options for X. Single buffer with and without middle-click, dual-buffer.
Personally I love highlight copying, it's much faster, middle click pasting is NOT faster than what I can achieve with my pinky already on ctrl and my forefinger already on the v before my mouse gets where it's going. (pretty much everytime, keystrokes are faster than mouse movements or clicks).
*sigh* I guess I'm already spoiled by highlight copying but don't want to give up the advantages of the keystrokes either and want the ability to mix the two.
Surely you can't deny for instance, that in a text box like the one we type our comments in, there is no reason for your fingers to ever leave the keyboard.
"Surely you can't deny for instance, that in a text box like the one we type our comments in, there is no reason for your fingers to ever leave the keyboard."
I challenge you to beat my time copying and quoting that text if you have to touch a mouse. Try it both ways and claim the mouse is faster (assuming you know the most basic keys for manipulating the text, like pressing home and then shift+end to highlight a line and shift down to highlight two, etc).
Now try to claim you've never highlighted something with the mouse and wanted to alt+tab to a text editor or word processor and ctrl+v the text in because it's faster than positioning the mouse and middle-clicking.
The way I see it, there are:
1. ctrl+v
2. middle-click
3. right-click paste
4. edit-paste
5. ctrl+x
6. right-click cut
7. edit+cut
8. ctrl+c
9. highlight
10.edit+copy
11.right-click copy
11 fundemental copying/cutting/pasting functions, What sense does it make to have 9 of them operate on the same buffer but pick two random ones to operate on a different buffer and be incompatible with all the others?
We'll simply have to agree to disagree I suppose.
Yes I know what the site and documentation say. You are correct full support is not marked stable yet.
In REALITY I've been using full blown NTFS write support for 2yrs without a single corruption.
Now that is without doing anything particularly fancy, I wouldn't go trying to run your system on it. I generally treat it as FAT32 in terms of what I expect to work or even try.
No symlinks, no attempting to do anything with permissions, and of course you wouldn't touch any NT system or operating files or folders, just data.
Sometimes permissions are nuked (the reason for the above) but of course those files can be reowned by the NT administrator and I'd hardly call it corrupted.
No it's not ready for the masses, but if you've got 2 Neurons floating around and managing to spark now and then (unlike the masses) and a bit of common sense then NTFS write support works just fine. Especially in a dual boot scenerio like we are talking about where data-exchange between OS's is all that's needed.
Yup, been using it for about 2yrs now without a hitch.
The part which is no longer marked experimental isn't full write support however. A couple people corrected me on that and I double checked and their correct.
However you can still turn on NTFS write support and NTFS write support has worked great for me since I'd say about midway through the 2.4 kernel series. No special trick, just turn it on and use it.
A few disclaimers, i'm not even sure I've used it since using a 2.6 kernel, I'm not sure I haven't either to be honest but I know I never had a problem from the default rh9+freshrpms updates kernel on up. Aside from NT passhack floppies I'm not sure I've used anything but a redhat kernel (I don't know of any redhat specific patches for it though).
Second, I KNOW I've never tried to chown/chmod or create symlinks. Creating files and directories I've done without problems. Resizing files??? Not sure what you mean here, if you mean opening a text file and adding more to it yes.
Deleting files is not an issue. Basically I've used it as a transfer partition on dual boot systems (both ways), for data recovery (in read scenerios and to transfer from the bad drive to the good ntfs partition so write as well).
Not sure I've even tried to read an NTFS compressed or encrypted partition as well.
Really I've had no problems. Everything I've tried has worked but my needs have never included actually mounting the drive and using it as a true linux mount. Just a place to copy that latest windows only app I want to take a peek at or my latest svcd images if low on space on my home system. At work I use NTFS write all the time to recover data.
My general rule of thumb is to treat an NTFS partition like a fat32 partition. And of course you probably wouldn't want to touch windows system files on the drive since you'll likely lose permissions on them but if that's corruption I'm the easter bunny, the administrator can own the files.
ok apparently I misinterpreted as much as the mac guy, at least on what your talking about.
I was wondering how that really matched, and could only see the delay thing.
I suppose they could be talking about application switching, I read it as having different context related functions occured based on the length of time a click occured on an icon. Like a tap results in selection, a tap that sticks (like dragging without the drag) brings up a menu similar to right clicking, and a double tap opens the app.
I'll re-read it, I'm sure one of us is right. If it's worded badly enough they could swing the patent either way, depending on who they feel it's more valuable to sue.
You missed the point. The patent is for causing a function to happen when you click and hold down the button for a length of time.
The grandparent was jesting that it was easy to replicate by loading up enough applications (thus slowing a windows system to a crawl, since windows, including nt/2000/xp doesn't handle multi-tasking very well). Then you press alt-tab and after enough time passes you get the next application, thus (kinda) replicating the functionality in the patent.
Apparently you missed this and thought he was just asking if there was a key command for application switching in MacOS. Completely missing the whole thing about being able to bog down the system so that there was a delay between the switches.
So if you load up say, 5 instances of IE, 6 instances of photoshop and a 3d game, is there a noticable delay when switching between applications on OSX?
Okay, that covers my account. How much does everyone else get in their hotmail account?
Ok, it's obvious to get my fellow *nix geeks to buy into this philosophy I need concrete examples of improved functionality.
1. Everyone knows the problem with obliterating urls and broken apps. Yes there are ways around most of it and other ways of doing things, that's not the point.
2. It's faster, I challenge you to use one hand to do faster what I can do with two in parallel. While using the mouse my fingers can rapid fire their corresponding functions. Generally the my fingers are ready to ctrl+v faster than my mouse gets to where the paste is going... since like most users I actually only have two fingers on the mouse it takes longer to move a finger to the middle button than it does to press the v key.
3. If you actually wanted to, although it's a tad clunky you can right-click+copy and right-click+paste. Even in windows or MacOS I can copy and paste without ever touching the keyboard. In fact this is how your average windows or mac user actually does it.
Actually I don't know of anywhere else this is the convention... but close.
In Mozilla/firebird ctrl+u blasts the entire line, so long as the cursor is in the location bar... BUT it doesn't matter where in the location bar, the cursor can actually be at the beginning and ctrl+u will STILL blast the entire line.
In bash, emacs, etc ctrl+u blasts all characters to the left of the cursor, not the entire line (unless the cursor is at the end of the line).
I'd disagree, I like middle-click just fine, but it would be better to add support to the terminals for the control, right-click and edit menu options and drop middle-click if it was one or the other.
middle-click is x windows only, the others are the de facto standard in the graphical world (not just windows).
Never heard of using shift anything to cut/paste myself.
keyboard
ctrl+x should cut
ctrl+v should copy
ctrl+p should paste
mouse
select+rightclick+copy should copy
''+''+cut should cut
''+''+paste should paste
This of course isn't just windows behavior, but the behavior of the known gui world.
Ctrl+U in windows, or when you don't have the cursor in the location bar is view source.
If you have the cursor (as in the blinking text cursor, not mouse) anywhere in the location bar it clears the full bar.
CTRL+U works in other apps as well, although elsewhere it generally nukes the line up to the cursor, instead of the whole line whereever the cursor is.
Unfortuntely there's no linix equivelent. Although I can switch between applications using alt-tab, it doesn't really seem to matter how many I open (short of completely exhausting ram+swap and thus crashing the machine) there is no noticeable time delay when switching.
Must be the overhead of the gui on the mac, surely it's not a BSD thing.
"The only brokenness is the number of old apps that don't use the selection and clipboard correctly. If you stick to well-written applications you really don't even need to know about the selection/clipboard duality. But you'll be more effective if you do understand and exploit it."
;) Serve different purposes? Gee, I thought they were just incompatible methods for doing the EXACT SAME THING, that would be selecting information, making a copy of it to a buffer, and pasting it into another application. Correct me if I'm wrong that's NOT the purpose of the clipboard in ANY implementation.
No, the brokeness is working in an unfamiliar manner compared with EVERY other graphical system in existance without ANY actual gain.
I really don't see how you'd exploit it, it offers nothing that multiple clipboard support doesn't already offer. The best you could hope for is to cope with it.
A well written application would what, copy the data from either method to the clipboard for both? Seems a little pointless to me this way.
Or support both methods... great but what if a person uses the keyboard for some things and the mouse for others and sometimes needs to switch between the two modes of working? Not knowing about the two imcompatible implementations would be a tad troublesome there I imagine.
"I have two different systems for heating food in my kitchen. Is that broken? No, and neither is X cut-n-paste, for the same reason. The two different systems are separate, distinguishable and serve different purposes."
Let's hit this in reverse
Distinguishable. Well I suppose if you ignore that fact that the same commands were implemented in numerous guis before X/Gnome/KDE and have a De Facto if not published behavior on which the X/WMofchoice methods don't improve in any fashion.
Let's come up with something a bit closer to home than appliances which are seperate devices and perform seperate functions. After all the only reason you have two is that although what they do is vaguely related in the sense of preparing food via heat, they are otherwise unrelated. All Microwaves behave more or less similarly and all ovens as well.
Here, closer we have(takes a minute to come up with something else broken in this fashion and decides he needs to make up a scenerio), Twelve modems of identical look, feel, weight, shape, size, color, and capabilities.
All the modems need to have a function to dial. 11 of the modems use the command ATDT# for this purpose, the last modem has a similar command, still ATDT, but it has three jacks (the other not being used and hidden under the plastic casing of the modem). While ATDT is implemented, instead of the standard behavior, ATDT1# dials out on one of the jacks and ATDT0# dials out on the other jack.
This is pretty much the same thing, while the behavior the copy and paste commands is a de facto standard, there are two+ implementations under linux which each implement a portion of it and are incompatible with eachother and none of them are compatible with the de facto standard. The only gain is the other port (clipboard) but it's hidden underneath the plastic where you have to hunt for it. There are also plenty of other modems which add superior functionality and DON'T break the standard.
Due to memory concerns you'd want to limit the size of clipboards as well as the number, or perhaps limit the total clipboard contents size for an unlimited number of clipboards.
There is no reason that both the limit and the number couldn't be set in a configuration file. Having clipboards be generated on the fly probably wouldn't be such a hot idea, it'd add uneeded complexity back into the concept.
I'd agree, though I believe the number should be static, I believe the static number should be user defined rather than hardcoded. Much like multiple desktops.
It is another silly patent, but a mouse fits the description.
Even time delay would be silly, but the patent specifically lists launching different functions with multiple clicks.
Yes going back and checking your right. Only part of it is marked stable.
However I stand by what I said, in the two years I've been using NTFS write support routinely I haven't seen one hint of this corruption nonsense.
In ancient times it did, as I said I've been using it for a couple years without any issues whatsoever.
But apparently someone wants this hushed up because I've been modded troll in 3 places for comments which mention that *shrugs*.
A good solid implementation should be ok, particularly with a keystroke combo to switch between clipboards.
10 was a random pick meant to be so ridiculously high that nobody could whine it wasn't enough. Personally I doubt I'd use more than 3 and generally wouldn't even use 2. I'd think 5 would actually probably be enough to keep the power clipboarders at it... any more than that would get confusing.
Or put the cursor anywhere in the location bar and press CTRL+U. This nukes the line in the bar (in mozilla/firebird on *nix).
Quite handy for broken text links on slashdot since it gives you the chance to correct them before trying to load the page.
In Mozilla/Firebird (on linux at least) you just click anywhere in the bar and press CTRL+U.