On Sat, 25 Nov 2006, Bulk wrote:
> Actually one thing I never learned was C/C++ or OOP for that matter.
>
> But the trio of ./configure, make & make install is not very hard to do.
Yup.
First start off though, with ports. Start with "man ports"
Ports automates fetching, untaring, patching, configuring, building,
package making, installation and undoing these things. It works
together with pkg_add (etc). It is *slick*. I believe it started
on one of the other BSD's, similar systems exist on Free- and Net-
and presumably the little brothers like Dragonfly. It is similar
to Debian packages, and somewhat similar to RedHat's rpm stuff.
It has less cruft than rpm, though.
There are many reasons to use ports (or a binary package) rather
than "rolling your own":
(1) packages/ports handles dependencies. If port foo needs
package/port bar, packages/ports will take care of this.
(2) The patches and the defaults used in config, and defaults
in the Makefiles are OpenBSD specific, and take careful account of
where things "should" go on the usual OpenBSD system. As a system
grows, trust me, having this consistency is a real blessing. In
general, things go under /usr/local.
(3) Some attention has been prepared to security in the ports.
Not as much as in the core distribution, but more than if you just
got the stuff and did it by hand.
(4) Uninstalling is automated. This can be a pain to do
by hand if the package being uninstalled has complicated dependencies,
or if some other package/port depends on it. (The latter case is
the one that will bite you.)
(5) The file structure provides a consistent place to store
source files and built packages.
The chief drawback to ports/packages is that it is not rare to discover
that you cannot get the most recent version of the application you want.
This is because of the work that the port maintainers have to do to
whip them into shape.
> I guess you went with the Linux compatibility thing. The only thing I've ever
> done with OBSD, until last week, was using it for building firewalls. So I'm
Nope, I don't use it; I was recommending it if you needed to run Linux
versions of certain software. Mozilla is tempting me. (I use
OpenBSD on all my machines -- I'm a retired software engineer/system
admin/general jerk (I still jerk from time to time), so I am using
OpenBSD for desktop/X. OpenBSD keeps from getting promoted from
General Jerk to Field Marshall of Jerks.
> not at home with how to use the ports etc. (I came from a SCO/SGI/Linux
> background.) Plus it seems an outpoint to use them, as they could easily ruin
> the security. Especially if run on a firewall. :)
In general, you would do your port/package work on a machine behind the
firewall, simply because that machine would be protected from badguys
a bit better than the firewall.
But if program foo's existence on a firewall would compromise it, then
it will compromise it whether it got there from packages/ports or
was sprinkled on the disk by the code fairies.
> What I would definitely appreciate are more detailed instructions to get to
> apply the etherape patch and so on. I.e. what I know about compiling under C
> is to run the three steps. I can debug failed dependencies and add them but
> not yet familiar with the BSD particulars (if they differ). So I don't know
> where I might fail.
Start with "man patch", and also read "man diff".
Set up a toy user and toy directory, and create some toy files to
play with, using patch, using diff to make the patches. Make a
file "foo.c", fill it with text (doesn't have to be C code, it can
be anything, say a poem). save it (cp foo.c foo.c.saved), now alter
it. Make a diff with diff and the -u (Unified Diff) options
$ diff -u foo.c.saved foo.c >foo.c.patch
(Put the old version first in the diff).
Now make another directory, say toyuser, cp foo.c.saved toyuser/foo.c;
cp foo.c.patch toyuser; then cd there yourself, and pretend your
a user. You have an old file "foo.c" and you've gotten a patch
from somewhere and you need to patch it.
$ patch foo.c foo.c.patch # usually does the job.
For our purposes, patch is just a way to run diff backwards. I
find that diff -u produces the most readable and reliable patches.
The problem with etherape will be applying the patches in the middle
of building the port. maybe I'll get detailed on this later. It
can have a glitch or two.
Maybe I'll make a log of doing it from scratch (man script).
> > etherape did work OK with the patches mentioned. I needed to get into
> > the "preferences" and twiddle a little before the display made any
> > sense at all.
>
> Ah, I just installed X and ran the xorg config and fired it up with startx.
> Not legibility problems at all. (My video card is probably different from
> yours :)
I have high standards for legibility. Font sizes and colors. I'm
an old, nearsighted with presbyopia, and for some reason bright
green causes me immediate (5 seconds) eyestrain, and I can't focus
it. I run a big old NEC Accusync monitor at 1600x??, with large size
TruType anti-aliased fonts as much as possible... I have special
eyeglassees for the computer. I gripe when a program or website
is hard to read. (Damn kids use dark grey type on black background
at around 6pts to be kewl. It's a way they have of repelling "adults".
I'll not get into the use of bogus typefaces right now.)
Dave
--
"Confound these wretched rodents! For every one I fling away,
a dozen more vex me!" -- Doctor Doom
_______________________________________________
Openbsd-newbies mailing list
[email protected]
http://mailman.theapt.org/listinfo/openbsd-newbies
