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@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@googlemail.com <mailto:nix.or.die@googlemail.com>> wrote:
Bozhidar Batsov wrote: > VMiklos wrote: >> Hello, >> >> Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov <lordbad@e-card.bg <mailto:lordbad@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@archlinux.org <mailto:pacman-dev@archlinux.org> http://archlinux.org/mailman/listinfo/pacman-dev <http://archlinux.org/mailman/listinfo/pacman-dev>
------------------------------------------------------------------------
_______________________________________________ pacman-dev mailing list pacman-dev@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@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev