Re: Adding disk firmware programming capability to camcontrol

2011-10-28 Thread Lyndon Nerenberg (VE6BBM/VE7TFX)
 The linux hdparm program is so paranoid about this that you have to use 
 extra arguments like --yes-really-destroy-my-disk-drive to do this.

I concur. Loudly.  The ability to brick your hardware is just too
large to not make people go through the I tell you three times
dance.  It's not like people will do this often enough that the
pain will be fatal.  And if it is, they ought to be bright enough to
know how to automate the process.

--lyndon

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Another take on adduser

2003-01-22 Thread Lyndon Nerenberg {VE6BBM}
A couple of months ago I wrote a shell implementation of adduser.
One of the things that bothered me about the old version was the
way its policy and configuration pretty much duplicated that of pw(8).
Being able to set inconsistent policy like this is not good. Also,
pw already implemented all of the functionality adduser required, so
why reinvent this?

My adduser simply presents a (somewhat) user-friendly front end to
pw. It prompts for the data, does some very simple validation on it,
then invokes pw to do the real work. It reads policy information from
pw.conf rather than having its own configuration file, and it takes no
command line arguments what so ever. (If you're smart enough to start
specifying the types of arguments the old adduser supported, you're
smart enough to just use pw. Ditto with the batch functionality.)

If anyone is interested in exploring an alternative implementation, the
code is at ftp://orthanc.ab.ca/lyndon/freebsd/usr.sbin/adduser/.  It's
functional, but still needs edge case testing and some code cleanup.

--lyndon

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message