Text 11842, 69 rader
Skriven 2008-09-24 13:27:46 av Maurice Kinal (1:261/38)
     Kommentar till en text av James Bradley
Ärende: when men were men
=========================
Hey James!

> When I use that W32 formated USB drive to garner mencoder, I'll bet
> after decompression, and un-tarring, it'll still have binary stuff
> in it.

Forget the usb drive, I'd bet that most are using mencoder to grab an analog AV
signal and converting it to a digital format such as in the case of a PVR.  In
this example the raw data is the analog signal. A simular example would be a
using lame to convert an audio signal from a soundcard input - usually 16-bit 2
channel stereo but could be 24-bit these days - to mp3.  The original raw
signal is most often analog. No binary until mencoder and/or lame encodes it. 
In passthrough mode, the signal is most often analog.  That is the raw I would
refer to and in professional AV studios would be considerd the most important
data worthy of storage and backing up since it is what is used to produce the
sellable product, such as a CD for music (analog btw), or DVD movie. In the
case of messaging ascii is the norm in this neck of the woods AND if a modem is
employed then it is definetly still ascii regardless of the files being
transferred.  Modem programming is ascii code. Same with printers, VGA
monitors, etc.  Also scripting which can be executable without being binary. 
Also, also mencoder started out aas ascii based C source before it bacame a
binary executable and the source is required to make it work in the first
place.  My build script for it is also a bash scripted ascii file.  Those are
just as valuable to me, sometimes more valuable, than the final product. 
Puttilng them in any other format would render them as useless.

> Then, "Hold on, the executables all compiled for a PI!" After
> installing a base system, the next step on previous versions
> was to reboot into your own kernel *then* compile everything
> else.

Other than the P1, that is more or less what I do.  For 32-bit the default is
i486 and lately all my x86_64 has been core2 but it used to be nocona. I only
switched to core2 when I switched to gcc-4.3 a couple months ago. I am building
all toolchains this way but don't ever boot them.  I use chroot instead and
then within that create Slackware packages which are later put on a bootable
drive/partition with it's own customized kernel aimed at the targetted system. 
I did this for my neighbour Paul yesterday as he totally trashed his drive
trying to use stock Slackware scripts/sources to create pure 64-bit ones.  I
warned him it wouldn't work and after he saw my system restore that drive and
boot he became convinced I have the right idea.  Hotswapping sata drives is
what is really important in this example.  As for fdisk, I am using the one
from util-linux-ng-2.14.1 and have yet to see any problems with it. I think his
issue might be with e2fsprogs but now that he has my basic development system
onboard he can rebuild it and see if I was right. Offhand I think it was
e2fsprogs.

> When I harken back to a CL installation, you *know* there's trouble.

They are the best.

> I'm all for "ease of use", but I need to tweak too.

Is there any other way?

> I don't know why that has to be mutually exclusive.

Like I said in the last reply, user friendliness ALWAYS leads to total
corruption.  It never fails to fail.  You can count on it.

> Your aversion to Python, is that it is used for GUI development?

I wouldn't have minded if that were true.  I object to objective.  :-)

Life is good,
Maurice

--- BBBS/LiI v4.01 Flag
 * Origin: Prism bbs (1:261/38)