Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Aaron J. Seigo
aseigo at kde.org
Sun Mar 30 20:49:14 CEST 2008
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
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080330/7647df73/attachment.pgp
More information about the release-team