[pacman-dev] Maelstrom(Pacman in C#) project brief
Georg Grabler
ggrabler at gmail.com
Mon Jul 23 10:20:12 EDT 2007
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> 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>> 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>> 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>
> > http://archlinux.org/mailman/listinfo/pacman-dev
> > <http://archlinux.org/mailman/listinfo/pacman-dev>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > pacman-dev mailing list
> > 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
> http://archlinux.org/mailman/listinfo/pacman-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20070723/eb4b91e4/attachment.htm>
More information about the pacman-dev
mailing list