Re: Video editing in Linux?

From: Ian Molton (spyro_at_f2s.com)
Date: 11/05/04 

Date: Fri, 05 Nov 2004 17:14:51 +0000

SjT wrote:

> Whether it worked or not isn't the issue, i think that got a lot of
> non-computing types into buying a computer.

I dont. lets agree to differ...

> No i'm referring to games that appeared in gamestores, and even petrol
> stations, most people who had quake or Doom had copied them from their
> mates and were games for those already into their computers.
>
> *** like reader rabbit and jungle book for the families kids etc.

Those games pushed neither the OS, nor the hardware. my 486 can still
play the majority of that type of game, even the ones written today.

> XP seems to enjoy processing it an awful lot. :)

XP enjoys processing stuff. I like that concept. it explains a lot ;-)))

>>Why not use an linux/openoffice system **in parallel** for a bit?
>
> Cause it's too much to ask from the users, i would get silly questions
> like 'Wheres my dog gone?!'

so transition YOURSELF across, get the experience, THEN help the others.

>>the philosophy behind much of the linux kernel is to avoid putting large
>>(therefore buggy) code into the kernel (where its failure can bring down
>>the system), and instead put the minimum needed for high performance
>>into the kernel, and the rest into a library (dll if you like) that
>>provides a nice interface for applications.
>
> Does that mean that once its in the kernel you can't take it out then?

What do you mean by that?

> Configure script is always included with the source i presume?

for the majority of packages.

>>make invokes the make program, which builds the package according the
>>the makefiles created by the configure script
>>make install copies the components you just built to the right places on
>>your system.
>
> Ok yeah i can see that, is there any GUI's that make this easier if
> most installs work along those lines?

I saw a gui for this kind of thing once. They crop up from time to time.
thing is they dont offer anything really over the command line way...

>>if you get errors during the make phase you are probably SOL unless you
>>can hack the code yourself.
>
> Errors there would be down to my distro yeah?

Hard to say. a well written and properly working configure script should
ensure that make never fails, however theres nothing saying that Suse
correctly installed all the little things configure relies on, or that
the creator of the configure script or the tests it runs got everything
right.

it occasionally happens, and its a pain if it does. you probably wont
see it on non-bleeding edge packages though.

> I can't see what difference a distro can make personally, as i thought
> they all ran on the same linux kernel.

the kernel is a single 1-4MB file on the PC. the rest of the OS can
total 20-500MB depending on what you install. the kernel is the least of
your problems.

>>Well on linux you'd install the driver for the soundcard, and then
>>rosegarden...
>
>
> Whatabout JACK and ALSPA - or is ALSPA my soundcard driver (Plus other
> things)?

you mean LADSPA? if rosegarden requires them you will need to install
them. if they are optional you wont but will suffer reduced functionality.

> Do you know if JACK routers the sound from ALSPA to rosegarden.. i
> can't see why its essential otherwise?

I dont know what it does really I havent ever used it. seems like some
kind of virtual patch cable from what someone else said.

> So why would anyone choose to compile into the kernel?! it seems
> madness to want to do so when it's both harder and unbeneficial.

There are reasons. a normal user would probably not wat to compile into
the kernel.

eg. a business might deploy 50000 identical PCs, and choose to use a
non-modular kernel so they would only need to maintain one file on their
boot server.

security concious types dont like the module loading facility to be
available, although I consider their approach to be somewhat of a red
herring given things like /dev/kmem exist.

> With that in mind it's pretty secure,
> unless they accept unpatched source code to make it into the final
> release.

Which they wont, of course. Im glad you can see how it works now though.

[wine]
> And whatabout shared dll's that each app uses then? do you make a fake
> windows/system32 folder somewhere?!

Yep, although its not really fake.

linux keeps all its "dlls" (called shared libraries or .so files) in
*/lib. you do the same with the windows dlls.

you can choose to install them system-wide or just for your user, or a
hybrid mix of the two.

Quantcast