Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

[Aaron J. Seigo]

On Sunday 30 March 2008, Mark Constable wrote:
> On 2008-03-30 10:38, Aaron J. Seigo wrote:
> > That's true of every single dependency we have in KDE. Hardly anybody
> > bats an eye when we pull in Yet Another Library, so doing so now is
> > really hypocritical.
>
> Obviously, the difference is that the current KDE dependencies are
> mostly C/C++ libraries. Many and varied they may be but they are
> generally not interpreter environments.

this is a largely irrelevant distinction to make. and yes, we already use them 
in various places, including amarok.

> > > Qt/KDE is pure binary code with minimal interpreter dependencies
> > > and I, for one, do not want to have to install perl, python, ruby,
> > > mono, java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how
> > > ever many other scripting environemnts just to run a basic desktop
> > > system.
> >
> > * Dependencies are handled for you when installing from packages, and
> > simply cause items to be skipped when they are not available. So "more
> > work" is not at issue.
>
> The MB outlined above is download bandwidth, installation is 3 to
> 4 times that size. Then are we talking about python 2.4 or 2.5 or
> maybe 3.0, ruby 1.8.5 or 1.8.6, perl 5 or 6, and on and on.

the python and ruby installs on my system do not take 3-4x that size. in fact, 
the download sizes you quote there are larger than the size they take on disk 
here according to rpm.

and remember: you probably already have perl and python on your system. why 
don't you check?

> Sub $100 hardware and sub 100k modem/mobile links may outnumber
> 1st world PCs in the coming years

your concerns, thankfully, do not meet up with the reality of these systems.

as i've repeated a few times now, the current crop of hardware that targets 
this area is well capable of running python/ruby applications and many of 
them already come with python installed right now. in fact, the olpc uses 
python extensively. if today's systems are capable of it, then tomorrow's 
systems will only be able to do it better.

as for the network link issue, that's why these systems come preloaded with 
the neede software. they aren't going to be downloading and installing kde 
apps either. they'll come on the disk already installed or on physical media. 
so the network link thing is pretty irrelevant for the base system.

if anything, such languages are *better* for these systems because there are 
bound to be various hardware and OS sofware variances that make shipping 
binaries harder. shipping python/ruby apps makes this a non-issue.

> and C/C++ code is always going 
> to perform better no matter what hardware baseline is considered.

well, the "always" part is arguable, but what's really important is if they 
perform _well enough_. if the user can't tell, then it doesn't matter. and 
for many apps, such as guidance, that's pretty obviously the case.

> > * We're not talking about all languages: we're specifically discussing
> > Python.
>
> Fine, then setup a well defined kdepython area in the main repos
> and make sure any dependencies for python apps do not leek outside
> that area. Then, as a packager, I can easily avoid build, distrib
> and support time for anything to do with python. No problem.

as a kde packager, you don't have to worry about python itself. that's 
provided by the OS. the only thing i can see if the bindings. and yes, we 
would actually like packagers to start distributing those as opposed to 
hiding them from the world.

as for distrib and support time, in practice that time approaches 0.

again, doing the cost/benefit it's very aparent that the benefits immensely 
outweigh any costs associated, which are actually pretty minimal.

now, if the bindings are too difficult to package, then that is something we 
could work on. i don't know if that is the case (i would expect not, but you 
never know), but should be solvable if it actually is.

> Sure, you are specifically discussing python right now but then
> it'll be ruby, then...

i get the sense you aren't reading my emails. =) i'll repeat myself once more, 
and then consider this part of the conversation done: it's not a slippery 
slope into a world of many languages. python and ruby are the obvious 
candidates as we actually have applications written in both and those are the 
two languages with actual meaningful interest in the desktop side of the 
f/oss world. java *may* enter into it, but i doubt it in the f/oss side (in 
the corporate / proprietary area, it might be different). so this is a 
strawman argument, please stop raising it as if it were a real issue.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080330/7647df73/attachment.pgp