[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Any possibility of getting this software installer coded and in fedora (9 or 10)?



Mark wrote:
2008/2/11, Jeff Spaleta <jspaleta gmail com>:
On Feb 11, 2008 11:20 AM, Mark <markg85 gmail com> wrote:
Oke that makes sense. and what about a c/c++ frontend? that's what i
actually want to do with java just as a step between it. Just asking
and seeing if that might be a good possibility. I won't make that
anytime soon because i have no c/c++ knowledge at the moment or
anytime soon (as in 1+ years or so).
Again.. is there a reason you can't work directly with the existing
packagekit developers?  Having 15 thousand different frontends sure
sounds like a bad idea.  Packagekit development has momentum, its
going places, they have multiple frontends for situations that make
sense.

If you want to make best impact, you'll find a way to work with them
to improve the frontends they are already working on.

Unless your ideas for what your application is actually going to do
for users is inconsistent with what packagekit developers are already
trying to achieve... there is little utility in striking on on your
own.  If your primary goal is to impact the experience for users
generally, you'll get their faster by enhancing what is already being
worked on.

If you just want to do this for self-education or personal usage, then
do whatever you want, you'll succeed at the goal regardless of how you
actually implement your code.

-jef

Well.. i personally think that programs that need to be fast (package
management needs that in my opinion) can't be written in python simply
because it's not the fastest language if you go for performance. but i
understand why people use it and am thinking of learning it and that's
mainly because python is relatively easy to learn and very powerful.


He calleth down the thunder :)

Python's particular performance characteristics aside, package management front ends are going to be mostly disk operations (not very language dependent even in the worst of cases) and yum operations (handled in a library, so really not your code anyway) so this argument is a bad one.

I do think there are some particular issues with python that have hurt pirut/pup (poor concurrency support leading to weird drawing issues when yum is crunching things) but there's no reason that can't be coded around.

--CJD

I might learn python sometime.. or not..
i'm not sure about it all.
Anyway if i start with something like this to get that mockup as a
working app than i will ofcause edit one of the existing frontends
(likely PackageKit).

Perhaps anyone can code those mockups in python? ^_^



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]