Date: Sun, 9 Aug 2009 07:52:31 -0600 From: Chad Perrin <perrin@apotheon.com> To: freebsd-questions@freebsd.org Subject: Re: FreeBSD for the common man(or woman) (was: > upgrade 7.2 Message-ID: <20090809135230.GA21588@kokopelli.hydra> In-Reply-To: <20090808195518.7eb8e5ee.freebsd@edvax.de> References: <20090806120011.8528A106567E@hub.freebsd.org> <182370.92452.qm@web65511.mail.ac4.yahoo.com> <20090808164600.GA11570@kokopelli.hydra> <20090808195518.7eb8e5ee.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--J/dobhs11T7y2rNN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 08, 2009 at 07:55:18PM +0200, Polytropon wrote:
> On Sat, 8 Aug 2009 10:46:00 -0600, Chad Perrin <perrin@apotheon.com> wrot=
e:
> > Yeah, I hate that stuff. The GNU project is kind of like the Microsoft
> > of the open source community, that way.
>=20
> Be happy that there at least is an info manual. In many cases, there
> is NO local documentation, neither in man or info format. The usual
> cases of documentation, often found in different Linusi, but as well
> in some "modern software" on FreeBSD, are:
> - bury the documentation in an arbitrary web location
> - use a Wiki for documentation
> - let the users write the documentation
> - don't document anything.
An info page is almost as bad as nothing, as far as I'm concerned. The
GNU project has this bizarre idea that everybody in the world should use
everything it produces and *nothing else*, no matter how painful it all
is to use -- and assumes everybody should be using emacs, so obviously
the baroque emacs-inspired interface to info pages is "ideal".
Debian actually tended to be pretty good at manpage coverage of software
and files on the system, but FreeBSD still manages to do at least
slightly better most of the time -- and, for some reason, few of the
other Linux distributions took advantage of the manpages produced by the
Debian project.
>=20
> Fortunately, there are even "GUI only" projects that keep up with
> the good manpage tradition. Have you ever tried "man opera" or
> "man gmencoder"? On the other hand, most KDE stuff doesn't have
> a manpage - of course, I can understand it. From their point of
> view, the question would be: Who would want to read documentation?
> Answer: Nobody. So why spend time to create it?
This is one reason among many I have no interest in using KDE software.
>=20
> > The FHS isn't a Unix standard. It's a Linux distributions standard.
>=20
> It aims to be.
To be . . . which one? I'm sure its proponents want it to take over the
world, but frankly, I hope it fails miserably. They're actually doing
things that break backward compatibility with older "standard" ways of
doing things just for the sake of political expediency, which definitely
gets my hackles up.
>=20
> > In the specific case of creating /etc/opt, you shouldn't really be
> > damaging anything, but there's a very good reason that stuff is in
> > /usr/local/etc -- so that when using separate filesystems for separate
> > parts of the hierarchy, you don't separate the stuff installed in
> > /usr/local from its configuration data.
>=20
> Especially in an environment with "elevated security", there are
> resons to separate things filesystem wise. File permissions and
> mount options are a topic there, and symlinking across partitions
> is a no-go in such settings.
That's another excellent point.
>=20
> > The FHS doesn't apply to FreeBSD (or any other BSD Unix, or any
> > commercial UNIX system, for that matter), so it's not "breaking"
> > anything.=20
>=20
> Just have a look at how Solaris, HP-UX or AIX organize things in
> terms of directories. You'll be surprised every day where you
> can find stange things. :-)
Hell, I've been surprised at the strange places Red Hat keeps things
sometimes, even when Linux distributions were my daily business.
>=20
> > Then again, I go out of my way to make sure I use network-attached
> > PostScript laser printers, and they tend to be very well supported by
> > CUPS on BSD Unix and other Unix-like OSes.
>=20
> Postscript capable network printers have the advanage that they don't
> need any support. PS is the default output format for printing, so
> there's no need to mess around with filters. Most office class printers
> even include a spooling mechanism for the printer jobs, so this
> takes away more work from the OS. You simply use the system's lpr
> command to shove data into the printer, and it does the rest by itself.
I kinda like having the ability to manage my printer spool from the
system where the print job was created, though, using the same interface
I used to configure the printer and send jobs to it in the first place.
>=20
> > Don't forget that `man man` will tell you stuff like how to access a
> > manpage in a particular section of the Unix Manual:
> >=20
> > man n foo
> >=20
> > . . . where "n" is the section number and "foo" is the manpage in that
> > section you want to read.
>=20
> It's worth mentioning that there are manpages that don't refer to a
> particular binary, file, interface or function, but instead provide
> information about maintenance operations and general introduction.
> An example is
>=20
> % man intro
>=20
> There are other manpages that give hints for compiling the system,
> such as "man build", and others.
Indeed. Another is:
man security
--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
Quoth James Madison: "If Tyranny and Oppression come to this land, it
will be in the guise of fighting a foreign enemy."
--J/dobhs11T7y2rNN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
iEYEARECAAYFAkp+1J4ACgkQ9mn/Pj01uKVC5QCfSlQtLGwWi1l8urtrW3DdZhWg
Gr4An2tBaiM7NHjCvfTcKohTo2u65dZp
=O2Oh
-----END PGP SIGNATURE-----
--J/dobhs11T7y2rNN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090809135230.GA21588>