[pacman-dev] Maelstrom(Pacman in C#) project brief
Bozhidar Batsov
lordbad at e-card.bg
Mon Jul 23 10:32:48 EDT 2007
Any feedback is most welcome and I read it all the way no matter how
long it is. BTW I personally enjoy python very much, but I'm a hardcore
GNOME user and dislike QT(although I confess that KDE is the better DE
for the moment). I'm just so used to GTK apps that I can't look at QT
apps for a long time without my head starting to hurt. It seems to me
that most people pay more attention to Whirlwind, but I want to assure
all the command-line addicts(like me) that maelstrom will have a very
capable console client. Actually I work on it far more than on the
gui(for now at least).
Best Regards,
Bozhidar Batsov
Georg Grabler wrote:
> So go for it.
> I bet a couple of users will like it, and use it, as they use other
> projects. I personally also would like it, for the simple reason that
> i'd have it easier to get people to use arch.
>
> I'm thinking about a friend of mine (as well as some guys at work
> here). He plays one computer game, which has a native linux
> distribution of the software, which runs perfectly on arch. He'd like
> to use Linux on his desktop. He's the typical office user (MSN, ICQ,
> Office, Printing, E-Mail and this Game).
>
> Thus, he is a typical windows user, and telling him how the
> application works is by far easier than giving him the hard truth
> about linux and commandline.
>
> I'll hopefully soon be working again on pyalpm and a pyQT client,
> hopefully Cx will help me some (or i can help them with their pyQT
> client project). Havn't had much contact, maybe he's lost in the few
> lines i wrote, since a lot of them are replaceable by new features the
> alpm gained in the past month.
>
> I'd never say that i wouldn't use the project myself. Maybe i like it
> in the end, and to be true, i already liked the interface you provided
> (screenshots).
>
> I just want to tell you, of course, a native one always was "cleaner"
> "nicer" and "sexy", but it definitely re invents the wheel, for the
> reason that the code will be written twice. Also, maybe you come up
> with ideas how things could be implemented in pacman, since you seem
> to have plenty experience, also in c/c++ development.
>
> I've chosen pyrex for the same reason as you the native re-write: i
> didn't like the procedural API interface of alpm - but it gets better
> every day. Even when i'm currently not working on my projects, i
> follow the development lists carefully.
>
> If you want that project - do it. As i said, a lot of people will
> appreciate it.
>
> Also, why i considered this memory leak things is, that i may would
> like some background application searching for updates, providing a
> systray entry if updates are available (as other tools do). Though,
> this would need a different / faster / less system consuming operation
> for checking updates (as taking the provided rss feeds), but it would
> be possible, and a very nice feature.
>
> Yours,
> Georg
>
> PS: i know i write too much, hope you even want to read it ;)
>
> On 7/23/07, *Bozhidar Batsov* < lordbad at e-card.bg
> <mailto:lordbad at e-card.bg>> wrote:
>
> Georg Grabler wrote:
> > That's a fine point, Gabriel.
> > I just thought the same about my servers, by reading your message.
> >
> > Especially virtual servers it would take enough space then.
> >
> > Arch isn't a focused desktop distribution. Anyway, the team is
> working
> > hard to make pacman / alpm better (providing a better interface). In
> > the current state, they work towards to get by default
> compatible swig
> > bindings (at least the approach seems to be quite clear and clean,
> > following the git), what means you can also build your application
> > upon the alpm binding for C#.
> >
> > I also think that re-inventing the wheel isn't what should be done,
> > especially not in such a "small" project. Of course, desktop
> > environments and applications also often re-invent features.
> >
> > What i really appreciate are the features your client seems to have.
> > That's a huge piece of work you've done, and basically what i'd
> like
> > to see for pacman. GTK/QT interfaces for the original ALPM, for
> every
> > kind of desktop user.
> >
> > I've been working some time now on pyalpm to make a compatible
> client.
> > I just don't get along, since my work still eats me up, and the
> > critsit won't end, as it seems.
> >
> > Yours,
> > Georg
> >
> > On 7/23/07, *Gabriel C* <nix.or.die at googlemail.com
> <mailto:nix.or.die at googlemail.com>
> > <mailto: nix.or.die at googlemail.com
> <mailto:nix.or.die at googlemail.com>>> wrote:
> >
> > Bozhidar Batsov wrote:
> > > VMiklos wrote:
> > >> Hello,
> > >>
> > >> Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov
> > <lordbad at e-card.bg <mailto:lordbad at e-card.bg>
> <mailto:lordbad at e-card.bg <mailto:lordbad at e-card.bg>>> pisal(a):
> > >>
> > >>> Well I have no intention to fork Arch. I strive to make a
> > product 100%
> > >>> compatible with the existing, but I want to offer
> through it a few
> > >>> things that are missing in pacman and a couple of newer
> > technologies. I
> > >>> don't think that mono is a bad thing just because .NET is a
> > Microsoft
> > >>> product. After all Miguel de Icaza has stated many times
> that
> > if he had
> > >>> mono 8 years ago there wouldn't be one line of C code in
> GNOME. I
> > >>> personally consider it to be a much better framework than
> > java. Style
> > >>> and consistency are almost perfect here. Pascal notation
> for
> > methods,
> > >>> camel for vars, great generics, great datatypes, security...
> > >>>
> > >> let's say you would write this in python or perl, we
> would have
> > the same
> > >> problem: pacman is a lowlevel tool, it should be fast and
> have
> > as less
> > >> deps as possible. mono can be a great tool but are you sure
> > it's nice to
> > >> have the whole mono framework in an install cd?
> > >>
> > >> - VMiklos
> > >>
> >
> > >>
> > > Not exactly so. For one thing there are many popular programs
> > build with
> > > mono today - beagle, f-spot, tomboy, muine and others so
> you are
> > likely
> > > having the framework installed anyway. There are talks
> that soon
> > mono
> > > will be accepted as an official dependency in GNOME.
> >
> > All the programs you are talking about are almost broken but is
> > not the point here.
> >
> > You think to much about 'installations with an DESKTOP/X'
> that is.
> >
> > *Why* do you think I would install _mono_ ( about 70MB bloat
> ) on
> > my _servers_ ?
> >
> > Just to run an PM ?
> >
> >
> > Gabriel
> >
> > _______________________________________________
> > pacman-dev mailing list
> > pacman-dev at archlinux.org <mailto:pacman-dev at archlinux.org>
> <mailto:pacman-dev at archlinux.org <mailto:pacman-dev at archlinux.org>>
> > http://archlinux.org/mailman/listinfo/pacman-dev
> > <http://archlinux.org/mailman/listinfo/pacman-dev>
> >
> >
> >
> ------------------------------------------------------------------------
>
> >
> > _______________________________________________
> > pacman-dev mailing list
> > pacman-dev at archlinux.org <mailto:pacman-dev at archlinux.org>
> > http://archlinux.org/mailman/listinfo/pacman-dev
> >
> I don't see how 70MB are so crucial, but everyone has different
> opinion
> on every subject. I have 370GB HDD on my home PC, and don't
> imagine that
> there are many PC's left with 5GB drives around so 70MB doesn't
> seen so
> much. As I previously stated bindings do not reflect the true
> nature of
> C# and produce fairly ugly code, so I prefer to do stuff natively. On
> the subject of possible memory leaks on behalf of mono, I'd like
> to say
> that this is not an app that runs 24/7(Maelstrom or Whirlwind). A
> typical session is over for a couple of minutes so there is little
> danger of leaks as they tend to manifest in longer running apps.
> And of
> course the goal of the project is not to reinvent the wheel, but to
> build a better wheel so out car could run faster and be equiped with
> more features - for example maelstrom has support for package
> categories, something which seems to be ignored in arch - they are
> implemented with filtering regular expressions and are very helpful
> especially for a GUI client. Color support in the terminal is
> native, no
> patches required, and the conf file is scheduled to be enhanced as
> well
> with additional options... So these huge 70MB may not go to waste
> completely in the end...
>
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org <mailto:pacman-dev at archlinux.org>
> http://archlinux.org/mailman/listinfo/pacman-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pacman-dev mailing list
> pacman-dev at archlinux.org
> http://archlinux.org/mailman/listinfo/pacman-dev
>
More information about the pacman-dev
mailing list