Re: Video editing in Linux?

From: SjT (NOT_at_yahoo.com)
Date: 11/05/04 

Date: Fri, 05 Nov 2004 13:55:46 GMT

Ian Molton <spyro@f2s.com> Kissed me, Licked me, then left me a note:

>> But i expect that was using a port in the 7001-7009 range?
>
>Why?
>as it happens, 50507 (default is 6346 on gnutella, btw)

Sorry i thought you was using bit-torrent, totally missed the gnutella
reference.

>> I don't mean the technology i mean the useability, plug and play was
>> the big buzz word and it invited people to a ride of pure hell! :D
>
>Huh? as you JUST said, the usability wasnt there. admittedly this was
>*partly* not the fault of windows (ISA and ISAPnP sucked), but it was
>certainly not plug and play (plug and pray at best).

Yeah i'm referring to how MS advertised the OS, it was a case of 'Look
this is going to be piss easy for you to use buy one' and they kept
repeating it for each OS until they got it right.

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

>> Yeah, but the majority of windows based games were using the Directx
>> drivers.
>
>Are you suggesting that doom and quake werent the games that broke us
>into 3D gaming? the rest came later. indeed the 3DFX card that started
>it all was built for quake...

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.

>> The ISP hasn't a clue why and i wondered then whether there was some
>> processing that XP was screwing up on.
>
>possibly but theres really not much overhead in pppoe (or pppoa).

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

>> But can you blame them for using such a standard platform?! I would be
>> *** scared to switch over to openoffice and a linux server here, i
>> would love to do it to see how it compares, but things like
>> compatibility issues with other companies would scare me to death.
>
>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?!'

>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?

>> Yeah i did google it, but i'm totally lost. You must appreciate that
>> this is an absolute world of difference from windows.
>
>Fair enough. you have to appreciate that 'I looked at this and cant
>really understand it, heres where I looked <URL>' will illicit a more
>friendly reply than '<name of thing> EEEK! what the ***?'

I have been reading about them on google as i'm doing my research up
front, but theres so much to take in just to install an audio app.
I've gone from installing the application, to making sure i've got the
right apps installed first to completely disregarding the distro that
i have and getting another.

I have no other word than EEK! to describe how i am feeling, i only
want a bit of advising as i'm sure when i actually go through step my
step i shall be ok, but the whole time i've got to consider all the
other stuff like where i will be getting the files from and the
digital signatures etc. It is a lot to take in.

>tar [z,j]xvf archive.tar.[gz,bz2]
>cd archive_name
>./configure
>make
>make install (you probably want to become the root user first)
>
>the ./configure runs a script in the working directory, which detects
>all kinds of information about the system - what CPU, OS, what libraries
>you have, etc.

Configure script is always included with the source i presume?

>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?

>'checking for LADSPA... yes'
>'checking for ladspa.h... no'
>'Error: LADSPA found but has no headers. install the LADSPA development
>headers'

Ahhh ok, so it checks for all that then, thats quite cool.. rather
helpful too.

I remember in the past when i had problems with my connection i could
not get any information about what was going wrong so i was totally
stuck, i enabled the kinternet logging facility and received diddly
squat.. but thats an old issue which i shouldnt have now.

If i get something, even if its just a code at least i can work it out
from there.

>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?

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

>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)?

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

>> They seem to suggest that compiling into the kernel is the better
>> option though as there are far more links to that?
>
>There is no performance penalty. the only difference is that you dont
>need to reboot if you compile the driver as a module.

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.

>> Then, modify the code to add your malicious code and send that file
>> with the original diff file you made previous?
>
>the maintainer is still going to read it though. whay do you think
>tacking the malicious bit on the end is any less visible than if it were
>part of the patch - patches are plaintext.

I was under the impression that you sent the source code and a patch
file detailing the changes, but as another poster has specified you
actually send the patch file alone and if they accept it they can add
the patch to their source code. With that in mind it's pretty secure,
unless they accept unpatched source code to make it into the final
release.

I thought the patch file was more a reference rather than the actual
file used to make the patch.. It takes some understanding as i'm
totally uneducated with the principles.

>> I.e. you run windows executables rather than having a window
>> displaying a windows machine, i.e. a windows desktop?
>
>correct - you can even have them use the linux window manager etc.

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

-- 
Playing: FIFA 2005.... Thats it atm
Awaiting: PES4 & HALO2 (Yawn yes i know)