Yes, the decision as to which files / folders get protection is arbitrary. It's called freedom of choice. You don't like the decision that a distro uses, then you can choose your own. You don't want any at all, then you can get rid of them all.
Things like protect.conf won't be added to many or any distributions since there are other ways to reach the same goals.
Yes, libtrash does offer much more effective coverage. However, there's nothing wrong with alsoo having this method.
If libtrash fixes the problem, why add another layer? (Libtrash or some other mechanism -- I'm not convinced libtrash is a complete or generally wise fix.)
In short, there is no harm that can come from having this functionality. If you don't like it, you can get rid of it, delete the protect.conf file, and it won't affect you at all. So, I don't see a good argument against it.
It's redundant; it has no value. If the goal -- recovery from an unintended goof or a bad choice when using rm -- can be made in a generic way, there won't be strange exceptions to explain to people. If the goal can be reached in a generic enough way, it may cover other cases such as my mistake using a recursive chmod in the wrong way or on the wrong target. Maybe the fix would handle all file operations?
It's true that your idea would delay someone from making a mistake. I doubt that it would prevent many people from overriding the prompt *again* and making the mistake anyway. At that point, we're back to recovering from the mistake not preventing it.
Do you have a way to make these decisions without having to result to personal and arbitrary preferences?
Well, the idea is that each distribution decides which folders / files go into protect.conf.
So, I'll take that as a 'NO'?:)
So, distros and ultimately end-users should only protect the really critical things.
How?
libtrash or some other method would offer much more complete protection. Protect.conf would cover only those cases specifically referenced, no more.
'rm -rf' does what it's designed to do. Aircraft -- even commercial passenger craft -- do have safety mechanisms that can be overridden. Pistols have trigger locks. If the person operating either crashes or blows a foot off...what more can I say?
Oh, so close. The problem with making exceptions is to know when to stop. Once people get used to the prompts and press enter 2x fast, do you add another level of prompts or a pause? (I've been in on projects where the answer to this is yes.)
'rm -rf/' is a poor example since making exceptions to it makes the command ambigious when the 'f' part is explicit.
A protect.conf-style mechanism would be a bonus if it and similar mechanisms could be disabled cleanly; kinda like training wheels can be unbolted.
At some point, it's OK to allow machines to not question commands. 'rm -rf/' has a clear result. 'rm -rf/sbin' is also clear, as is 'rm -rf/opt' and (in context) 'rm -rf "../myhome/appdir"', 'rm -rf./XF86config', and 'rm -rf.*'.
I have issued variations of the above many times, though usually after backing up the file or directory first, making a change to the copy, moving the targets around, and then running a test. The 'rm -rf' part comes in when one of the two directories is no longer needed.
Should all of these generate an additional confirmation promt? Why? Why not? Any of them could break a system for one or more users. Should FreeBSD, OSX, RH Linux, and Debian have different default directories to protect?
Do you have a way to make these decisions without having to result to personal and arbitrary preferences? (It could be done, though none come to mind at the moment. For example:../myhome/appdir might be config files, data, binaries, a mix of the above or empty. If empty, some app might fail when the directory is no longer there. Maybe the only important part is a subdirectory off of../myhome/appdir. How can you know?)
Personally, I like the fact that when I tell my system to go do something -- wise or not -- it does it. I've goofed using recursive commands before, though mostly with chgrp/chown/chmod. It is frustrating, though I know who's to blame and how to fix it. It is not arrogance or macho to have others who choose to use such powerful commands to offer them the respect they deserve.
There are ways to handle catistrophic mistakes that have less impact on the system (libtrash was given as an example), though it all comes down to the person pressing the keys. If that person can't be trusted -- even if that person is you -- you don't allow them to issue commands like 'rm' that honor options like '-rf'.
...means 'Remove everything in / including the directories and -- f -- force the removal without prompting'.
If someone wants confirmation, and then explicitly disables confirmation, and the tool goes and does exactly as it has been instructed, the person typing in the command has made the mistake not the tool.
Should yet another option be added to rm to disable the prompt for all circumstances? How many levels deep should these disable confirmation prompts go before they are really turned off?
I mean, seriously, most BIOSes are bigger than 1.44mb now!
How long then before mainstrean manufacturers start shipping a standardized small "boot" or "rescue" O.S in their bios, with some kind of user interface, core device drivers and a few tools, available at boot time either in addition to or as a replacement for the bios options screen.
2 comments;
1.44MB bios files can be pre-compressed and then decompressed on the fly. (Some PC BIOS utilities do this already.)
Some PC system BIOSes already have a stub BIOS loader. (Boot the system and select BIOS setup, update the BIOS.) The ones I've encountered still use a diskette for the BIOS image. If the new BIOS has a bug, the stub is still available to restore the old BIOS or upgrade to a fixed one.
From an OSS perspective, 20 different "Gnifty" apps may show up, but as long as at least one succeeds; then all is well for OSS. I don't really consider this idea that many will fail as any different than from the closed source world. Many companies have put out word processors...Where are they? Is that a blemish on closed-source software as a model?
Agreed...in addition, I've personally worked on many software projects intended to become commercial boxed products and about 1/3 of them are abandoned and never shows up at all -- not even as a feature or a substantial part of another product. Sure, a stub might appear though usually it does not or the stub gets removed at some point.
If an open source project is posted, it may be reused or taken over by others -- even if the initial abandoned version isn't worthy of much.
The closed project just dies. How many substantial projects does MS abandon in a year? My bet is well over the 1/3 rate I've seen.
So, the barrier to sucess in the boxed software commercial world is much higher since there are more ways to kill a project off before it even becomes a product.
Re:This is actually major news to some people
on
First HDTV Camcorder
·
· Score: 1
Hmmm...while I agree, there are workarounds -- COUGH! *filters* COUGH! -- excuse me. Where were we?
Yep, no question about the companies not being responsible for support of a configuration they did not ship.
After all, if you buy something from Penguin Computing you don't expect them to answer questions about x86 Solaris...they might, but there is no expectation that they are responsible to do so.
With a book-style licence, these issues are largely eliminated.
If I glue a book cover on a Bantam paperback, Bantam isn't responsible for the cover if it starts to peel at the edges or stain my hands.
Bantam is responsible if half way through reading the book I realize that the pages repeat themselves or the last page is just missing.
Would Bantam owe me a new book cover too? Probably not, though good arguments can be made either way.
It is not the slightest bit reasonable ever for a company to be able to control how you use their product after you have given them money in return for the right of such use.
I agree with you, though there are limits.
Microsoft's actions are absurd; even if they didn't have the lawyers or the monopoly, the use of that product is not up to them only the reselling of the content. When supporting it, yep they can limit that support to specific configurations, but not use. Even if the licence allows partial redistribution (runtime or complied results), where it is redistributed to is none of their business. If I want to use it on my toaster, they don't have any say. When they do speak up or threaten, they should be slapped down.
Additionally in your favor, I found it difficult to make an exception for satelite TV descramblers where you own the hardware and the content is literally raining down on you. Radar detectors fall in the same basic category. Laws that restrict this usage have a potential of erroding other rights. (That said, kudos to Hughes on using logic over lawyers in preventing folks from getting content gratis.)
Here's another more debaitable example and a corrilary. I've used it for years as a rule of thumb to see if a licence for content is reasonable;
Implied book licence
If you bought 1 tape of StarWars in the 90s, Lucas Films & Fox have a right to sue you into oblivion if you set up a business that did nothing but make copies of that tape or transfer it to other media for the next decade and resold the results.
OTOH, if you had a shop that allowed people to make backups or transfers -- even if your shop delt only with StarWars tapes -- there should be no restriction.
The spirit of the initial transaction 'buy this product and watch StarWars as many times as you want' is intact. Like a book, the seller should reasonably expect that for each copy sold only one copy will be in use at a time.
This means that if you make a copy and send one to your cousin in a comma, there's no problem. If she wakes up, there is a problem; both you and she can reasonably use the movie at the same time -- even if neither of you actually do so.
Yes, that is not how the laws are now (insert rant on DMCA nonsense). On the other hand everyone I know makes copies (many even thrust them on me as gifts). Ethically, I buy what I use if that's the expectation from the creator or agents of that creator; I have a copy of DMB's Lillywhite (unreleased) along with a bought copy of Busted Stuff (most of the same thing).
1. An hour long test only catches the most basic errors. You sleep, right? Run all tests and use that time to check it out. I've run memtest86 for a day and a half at times...and only toward the end does an error get detected -- sometimes not caused by the RAM but the memory subsystem (toss the board).
2. See above.
3. Yep. I only do it 1x a year or when something looks wrong or just strange. The more often the better.
4. Yep. Along those lines, a gentle shake test and compressed air has saved me many times; "So that's where that screw went!". (Yes, compressed air can be a bad thing, though I've found that it is worth the risk.)
None of these systems have ever had memory problems. They rarely, if ever, crash (or at least they didn't crash when I had them - some have passed on into the hands of friends). Maybe I'm just one really lucky bastard when it comes to RAM, but I've never had any problems buying the cheapest shit memory so that I could save a few bucks.
Out of sight, out of mind.
Being a former test lead for a memory diagnostic tool, I'd bet you had plenty of memory errors. When they occured, they didn't 'look' like memory errors, so you treated a different problem. Your fix 'worked', so you claimed sucess and moved on. Other errors might not have symptoms -- even if corrupton did occur -- so you didn't notice anything was wrong.
Basic example: One bit errors let alone other more complex defects can pass hardware parity checks (change a bit here and it flips a bit in a physically similar area).
The stats given by others -- ~30% failure on cheap memory and 0% on good within the first month -- are close to my experiences. IMNSHO, the intial numbers are the same (~30% & ~0%). Over the lifetime of a system +10% of both cheap and good memory tends to fail (or get wrecked by bad power).
To catch the +10% failure rate on non-ECC memory, and to catch memory subsystem errors in general, I run extensive tests on systems that can be taken down about once a year -- this is beyond any tests to diagnose flaky behavior.
Memtest86: It is excellent and as good as any other memory diagnostic software I've ever used when running all tests. As a matter of course, I add memtest86 to the boot menu on all x86 systems.
BIOS memory tests: The boot up memory tests are useful only to identify that the memory exists, so if possible I turn them off.
I only had a minute to try it this morning, but seems OK. If you use the point2Play, don't download the Binaries...the app does it for you and Point2Play won't work until you do. It will download the.tgz and install so using the RPMs or whatnot are kind of a waste.
Thanks, I just found that out. Now, the server's tanked and 'Get Latest Version' can't fetch the files. I'm removing the WineX3 RPM and will try again.
For all the complaints about WineX, it sure seems to be popular!
If you don't try it...you don't know! Well, OK, that's not entirely true. You can take some short cuts to see if Wine and/or WineX will ~likely~ work for you. A few select sites cover Wine and WineX program tips will give you a good idea.
Make no mistake, while Wine is getting damn good it is not perfect or even practical for all Windows software. Some software will probably never run under it, most will not run without some tweaking, so don't expect it to. OTOH, if you tried Wine even as late as a few months ago you might be surprised how things have changed. It all depends on what you 'need' to run.
Many of the main Wine sites have reviews of software and what works -- or how to get it to work. Keep in mind that if a comment is old, even a few weeks, it may not apply to the latest version of Wine. Usually this is a good thing, though some regressions do happen, so you might need a specific 'vintage' for a specific application.
That's terrible. I mean Microsoft releasing frequent patches for their products - and then the users are finding those patches so easy to download and install that they keep doing it!
[ponders, wonders, decides...yes! WACK WACK WACK WACK goes the Clue(tm)-brand clue bat against Jon Peterson's head.]
The issue isn't that it is easy, but that they have such an ineffecient and mostly uncachable mechanism for distribution.
The frequency of updates in relation to the bugs fixed isn't too much or too often. Microsoft is getting better, and most security issues are caused by the users, though some fixes still take months to show up.
Last Windows disk that said it'd work on PowerPC was NT4, IIRC. So you could try booting that. ^_^ You're on your own as far as support goes though.
Yep...and it worked so well that they included an x86 emulator and 32 bit libraries -- even on 64 bit Alpha processors that had no native 32 bit support!
The more things change...well, I guess they don't change do they.
Slashdot Mirror
Not to be totally humorless...though a good boot diskette or CD (*Knoppix*) would solve that problem too.
Things like protect.conf won't be added to many or any distributions since there are other ways to reach the same goals.
Yes, libtrash does offer much more effective coverage. However, there's nothing wrong with alsoo having this method.
If libtrash fixes the problem, why add another layer? (Libtrash or some other mechanism -- I'm not convinced libtrash is a complete or generally wise fix.)
In short, there is no harm that can come from having this functionality. If you don't like it, you can get rid of it, delete the protect.conf file, and it won't affect you at all. So, I don't see a good argument against it.
It's redundant; it has no value. If the goal -- recovery from an unintended goof or a bad choice when using rm -- can be made in a generic way, there won't be strange exceptions to explain to people. If the goal can be reached in a generic enough way, it may cover other cases such as my mistake using a recursive chmod in the wrong way or on the wrong target. Maybe the fix would handle all file operations?
It's true that your idea would delay someone from making a mistake. I doubt that it would prevent many people from overriding the prompt *again* and making the mistake anyway. At that point, we're back to recovering from the mistake not preventing it.
Flamebait, eh? So much for being honest!
Man, do I wish someone would tell the Mozilla team that...
Got a current example?
Well, the idea is that each distribution decides which folders / files go into protect.conf.
So, I'll take that as a 'NO'? :)
How?
libtrash or some other method would offer much more complete protection. Protect.conf would cover only those cases specifically referenced, no more.
'rm -rf' does what it's designed to do. Aircraft -- even commercial passenger craft -- do have safety mechanisms that can be overridden. Pistols have trigger locks. If the person operating either crashes or blows a foot off...what more can I say?
OK, move along...nothing to see there.
'rm -rf /' is a poor example since making exceptions to it makes the command ambigious when the 'f' part is explicit.
A protect.conf-style mechanism would be a bonus if it and similar mechanisms could be disabled cleanly; kinda like training wheels can be unbolted.
At some point, it's OK to allow machines to not question commands. 'rm -rf /' has a clear result. 'rm -rf /sbin' is also clear, as is 'rm -rf /opt' and (in context) 'rm -rf "../myhome/appdir"', 'rm -rf ./XF86config', and 'rm -rf .*'.
I have issued variations of the above many times, though usually after backing up the file or directory first, making a change to the copy, moving the targets around, and then running a test. The 'rm -rf' part comes in when one of the two directories is no longer needed.
Should all of these generate an additional confirmation promt? Why? Why not? Any of them could break a system for one or more users. Should FreeBSD, OSX, RH Linux, and Debian have different default directories to protect?
Do you have a way to make these decisions without having to result to personal and arbitrary preferences? (It could be done, though none come to mind at the moment. For example: ../myhome/appdir might be config files, data, binaries, a mix of the above or empty. If empty, some app might fail when the directory is no longer there. Maybe the only important part is a subdirectory off of ../myhome/appdir. How can you know?)
Personally, I like the fact that when I tell my system to go do something -- wise or not -- it does it. I've goofed using recursive commands before, though mostly with chgrp/chown/chmod. It is frustrating, though I know who's to blame and how to fix it. It is not arrogance or macho to have others who choose to use such powerful commands to offer them the respect they deserve.
There are ways to handle catistrophic mistakes that have less impact on the system (libtrash was given as an example), though it all comes down to the person pressing the keys. If that person can't be trusted -- even if that person is you -- you don't allow them to issue commands like 'rm' that honor options like '-rf'.
...means 'Remove everything in / including the directories and -- f -- force the removal without prompting'.
If someone wants confirmation, and then explicitly disables confirmation, and the tool goes and does exactly as it has been instructed, the person typing in the command has made the mistake not the tool.
Should yet another option be added to rm to disable the prompt for all circumstances? How many levels deep should these disable confirmation prompts go before they are really turned off?
- I mean, seriously, most BIOSes are bigger than 1.44mb now!
How long then before mainstrean manufacturers start shipping a standardized small "boot" or "rescue" O.S in their bios, with some kind of user interface, core device drivers and a few tools, available at boot time either in addition to or as a replacement for the bios options screen.2 comments;
1.44MB bios files can be pre-compressed and then decompressed on the fly. (Some PC BIOS utilities do this already.)
Some PC system BIOSes already have a stub BIOS loader. (Boot the system and select BIOS setup, update the BIOS.) The ones I've encountered still use a diskette for the BIOS image. If the new BIOS has a bug, the stub is still available to restore the old BIOS or upgrade to a fixed one.
Agreed...in addition, I've personally worked on many software projects intended to become commercial boxed products and about 1/3 of them are abandoned and never shows up at all -- not even as a feature or a substantial part of another product. Sure, a stub might appear though usually it does not or the stub gets removed at some point.
If an open source project is posted, it may be reused or taken over by others -- even if the initial abandoned version isn't worthy of much.
The closed project just dies. How many substantial projects does MS abandon in a year? My bet is well over the 1/3 rate I've seen.
So, the barrier to sucess in the boxed software commercial world is much higher since there are more ways to kill a project off before it even becomes a product.
Hmmm...while I agree, there are workarounds -- COUGH! *filters* COUGH! -- excuse me. Where were we?
After all, if you buy something from Penguin Computing you don't expect them to answer questions about x86 Solaris...they might, but there is no expectation that they are responsible to do so.
With a book-style licence, these issues are largely eliminated.
If I glue a book cover on a Bantam paperback, Bantam isn't responsible for the cover if it starts to peel at the edges or stain my hands.
Bantam is responsible if half way through reading the book I realize that the pages repeat themselves or the last page is just missing.
Would Bantam owe me a new book cover too? Probably not, though good arguments can be made either way.
Dolson, don't go overboard. If you disagree, there's plenty to comment on. Attacking the messanger doesn't help!
I agree with you, though there are limits.
Microsoft's actions are absurd; even if they didn't have the lawyers or the monopoly, the use of that product is not up to them only the reselling of the content. When supporting it, yep they can limit that support to specific configurations, but not use. Even if the licence allows partial redistribution (runtime or complied results), where it is redistributed to is none of their business. If I want to use it on my toaster, they don't have any say. When they do speak up or threaten, they should be slapped down.
Additionally in your favor, I found it difficult to make an exception for satelite TV descramblers where you own the hardware and the content is literally raining down on you. Radar detectors fall in the same basic category. Laws that restrict this usage have a potential of erroding other rights. (That said, kudos to Hughes on using logic over lawyers in preventing folks from getting content gratis.)
Here's another more debaitable example and a corrilary. I've used it for years as a rule of thumb to see if a licence for content is reasonable;
Implied book licence
If you bought 1 tape of StarWars in the 90s, Lucas Films & Fox have a right to sue you into oblivion if you set up a business that did nothing but make copies of that tape or transfer it to other media for the next decade and resold the results.
OTOH, if you had a shop that allowed people to make backups or transfers -- even if your shop delt only with StarWars tapes -- there should be no restriction.
The spirit of the initial transaction 'buy this product and watch StarWars as many times as you want' is intact. Like a book, the seller should reasonably expect that for each copy sold only one copy will be in use at a time.
This means that if you make a copy and send one to your cousin in a comma, there's no problem. If she wakes up, there is a problem; both you and she can reasonably use the movie at the same time -- even if neither of you actually do so.
Yes, that is not how the laws are now (insert rant on DMCA nonsense). On the other hand everyone I know makes copies (many even thrust them on me as gifts). Ethically, I buy what I use if that's the expectation from the creator or agents of that creator; I have a copy of DMB's Lillywhite (unreleased) along with a bought copy of Busted Stuff (most of the same thing).
Sounds like a defect in the system board, maybe the BIOS. Memory shouldn't vanish, even if bad.
Details on what I've seen and recommend are here.
1. An hour long test only catches the most basic errors. You sleep, right? Run all tests and use that time to check it out. I've run memtest86 for a day and a half at times...and only toward the end does an error get detected -- sometimes not caused by the RAM but the memory subsystem (toss the board).
2. See above.
3. Yep. I only do it 1x a year or when something looks wrong or just strange. The more often the better.
4. Yep. Along those lines, a gentle shake test and compressed air has saved me many times; "So that's where that screw went!". (Yes, compressed air can be a bad thing, though I've found that it is worth the risk.)
Out of sight, out of mind.
Being a former test lead for a memory diagnostic tool, I'd bet you had plenty of memory errors. When they occured, they didn't 'look' like memory errors, so you treated a different problem. Your fix 'worked', so you claimed sucess and moved on. Other errors might not have symptoms -- even if corrupton did occur -- so you didn't notice anything was wrong.
The stats given by others -- ~30% failure on cheap memory and 0% on good within the first month -- are close to my experiences. IMNSHO, the intial numbers are the same (~30% & ~0%). Over the lifetime of a system +10% of both cheap and good memory tends to fail (or get wrecked by bad power).
To catch the +10% failure rate on non-ECC memory, and to catch memory subsystem errors in general, I run extensive tests on systems that can be taken down about once a year -- this is beyond any tests to diagnose flaky behavior.
Memtest86: It is excellent and as good as any other memory diagnostic software I've ever used when running all tests. As a matter of course, I add memtest86 to the boot menu on all x86 systems.
BIOS memory tests: The boot up memory tests are useful only to identify that the memory exists, so if possible I turn them off.
Live near a Microcenter? $20 for the all-in-one 2 port Belkin KVM this month. I have one and am using it at 1280x1024 right now.
Does the FTC want my archive? I'll send the last few months worth if it is at all appreciated.
Thanks, I just found that out. Now, the server's tanked and 'Get Latest Version' can't fetch the files. I'm removing the WineX3 RPM and will try again.
For all the complaints about WineX, it sure seems to be popular!
Make no mistake, while Wine is getting damn good it is not perfect or even practical for all Windows software. Some software will probably never run under it, most will not run without some tweaking, so don't expect it to. OTOH, if you tried Wine even as late as a few months ago you might be surprised how things have changed. It all depends on what you 'need' to run.
Many of the main Wine sites have reviews of software and what works -- or how to get it to work. Keep in mind that if a comment is old, even a few weeks, it may not apply to the latest version of Wine. Usually this is a good thing, though some regressions do happen, so you might need a specific 'vintage' for a specific application.
That said, here's a good list;
Frank's Corner -- always deserves a mention
The official Wine Application Database sponsored by Codeweavers
Transgaming's WineX game list and search engine
Wine Headquarters -- also sponsored by Codeweavers -- is the main Wine site and has the detailed and oft quoted FAQ-o-Matic
For more information, check the links on any of these sites.
I'm grabbing the Point2Play RPM now, though the Transgaming site doesn't show any pics of it. Anyone use it yet? It wasn't in the beta release AFAICR.
[ponders, wonders, decides...yes! WACK WACK WACK WACK goes the Clue(tm)-brand clue bat against Jon Peterson's head.]
The issue isn't that it is easy, but that they have such an ineffecient and mostly uncachable mechanism for distribution.
The frequency of updates in relation to the bugs fixed isn't too much or too often. Microsoft is getting better, and most security issues are caused by the users, though some fixes still take months to show up.
Yep...and it worked so well that they included an x86 emulator and 32 bit libraries -- even on 64 bit Alpha processors that had no native 32 bit support!
The more things change...well, I guess they don't change do they.
Yeah, I like humor too.