[pacman-dev] Maelstrom(Pacman in C#) project brief

older
[pacman-dev] Pacman doesn't handle...

Bozhidar Batsov

20 Jul 2007 20 Jul '07

12:37 p.m.

My implementation of pacman's functionality codenamed "Maelstrom" has reach a usable state. I actually managed to graduate thanks to it, as it was my graduation task, so now I'm an engineer from the Technical University of Sofia, Bulgaria. Currently my project supports most of pacman's capabilities + a few more, but I was thinking what is the community's opinion on the subject - is there any point in developing another pacman... I'd like to hear from you, because I was thinking to do a complete overhaul of Maelstrom to make it more sturdy and elegant and to release it to the general public, but maybe that will be pointless if no one thinks there is the need of another implementation of the package management system. Here are some finer points of the maelstrom project: 1. This is not a client for libaplm - it is a complete framework written from scratch without even consulting the original source code. It consists of a couple of libraries and two clients - one console app and one written in GTK#. Everything is 100% percent coded in C# 2.0. 2. Instead of the current db format - files hierarchy located under /var/lib/pacman, maelstrom relies of a RDBMS for it's bookkeeping, though it creates the entries in pacman's DB as well for backwards compatibility. 3. I can initially import in it's DB the current state of pacman's DB. 4, It understands the format of pacman.conf and parses it natively. Here are a couple of screenshots: ftp://78.128.17.199/sync.png ftp://78.128.17.199/refresh.png ftp://78.128.17.199/whirl.png

Show replies by date

VMiklos

20 Jul 20 Jul

12:59 p.m.

Hello, Na Fri, Jul 20, 2007 at 03:37:26PM +0300, Bozhidar Batsov pisal(a):

...

1. This is not a client for libaplm - it is a complete framework written from scratch without even consulting the original source code.

what's the point of this? why not just using the lib bindings? thanks, - VMiklos

Xavier

1:12 p.m.

On Fri, Jul 20, 2007 at 02:59:07PM +0200, VMiklos wrote:

...

Hello,

Na Fri, Jul 20, 2007 at 03:37:26PM +0300, Bozhidar Batsov pisal(a):

...
1. This is not a client for libaplm - it is a complete framework written from scratch without even consulting the original source code.

what's the point of this? why not just using the lib bindings?

I think at least one of the reason is there : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008460.html

Bozhidar Batsov

1:13 p.m.

VMiklos wrote:

...

Hello,

Na Fri, Jul 20, 2007 at 03:37:26PM +0300, Bozhidar Batsov pisal(a):

...
1. This is not a client for libaplm - it is a complete framework written from scratch without even consulting the original source code.

what's the point of this? why not just using the lib bindings?

thanks, - VMiklos

------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Three main reasons: 1. The bindings do not reflect the true nature of a C# application. 2. By reimplementing everything there is the slight possibility that you'd do something better than it was done in the original - if it happens, it can be retrofitted there. 3. It is much more fun do it all... P.S. Everything would have been much easier had the format of the database been thoroughly explained somewhere. I had to guess and ask a lot before I could achieve a working state of things.

Xavier

2:08 p.m.

On Fri, Jul 20, 2007 at 04:13:34PM +0300, Bozhidar Batsov wrote:

...

2. By reimplementing everything there is the slight possibility that you'd do something better than it was done in the original - if it happens, it can be retrofitted there. 3. It is much more fun do it all...

I've searched a bit about other implementations, I found at least two of them : 1) libpypac + apport client, used in Enlisy distribution http://bbs.archlinux.org/viewtopic.php?id=34051 http://bbs.archlinux.org/viewtopic.php?id=14911 http://home.gna.org/libpypac/ http://enlisy.org/ - http://enlisy.com/en/ This one looks up to date. Does anyone know about technical details, how it compare to pacman ? features implemented, performance, code readability, etc. 2) Pry http://bbs.archlinux.org/viewtopic.php?id=20447 that one looks pretty much dead. Maybe there are others also, but this is apparently not the first time it has been done. About your project, I'm not sure that a dependency on mono will be appreciated for the core software of Arch. Not to mention this particular language is Microsoft's baby, so I would find that rather funny, but it may be just me :) I personnaly wouldn't mind if pacman used a higher language though, unless someone with impressive C skills rewrote it from scratch. Because I'm not a huge fan of the current codebase..

...

P.S. Everything would have been much easier had the format of the database been thoroughly explained somewhere. I had to guess and ask a lot before I could achieve a working state of things.

Help is welcome ?

Bozhidar Batsov

2:40 p.m.

Xavier wrote:

...

On Fri, Jul 20, 2007 at 04:13:34PM +0300, Bozhidar Batsov wrote:

...
2. By reimplementing everything there is the slight possibility that you'd do something better than it was done in the original - if it happens, it can be retrofitted there. 3. It is much more fun do it all...

I've searched a bit about other implementations, I found at least two of them : 1) libpypac + apport client, used in Enlisy distribution http://bbs.archlinux.org/viewtopic.php?id=34051 http://bbs.archlinux.org/viewtopic.php?id=14911 http://home.gna.org/libpypac/ http://enlisy.org/ - http://enlisy.com/en/

This one looks up to date. Does anyone know about technical details, how it compare to pacman ? features implemented, performance, code readability, etc.

2) Pry http://bbs.archlinux.org/viewtopic.php?id=20447

that one looks pretty much dead.

Maybe there are others also, but this is apparently not the first time it has been done. About your project, I'm not sure that a dependency on mono will be appreciated for the core software of Arch. Not to mention this particular language is Microsoft's baby, so I would find that rather funny, but it may be just me :)

I personnaly wouldn't mind if pacman used a higher language though, unless someone with impressive C skills rewrote it from scratch. Because I'm not a huge fan of the current codebase..

...
P.S. Everything would have been much easier had the format of the database been thoroughly explained somewhere. I had to guess and ask a lot before I could achieve a working state of things.

Help is welcome ?

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

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...

VMiklos

22 Jul 22 Jul

6:57 p.m.

Hello, Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov 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

Xavier

7:50 p.m.

On Sun, Jul 22, 2007 at 08:57:53PM +0200, VMiklos wrote:

...

Hello,

Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov 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?

How is a package manager a low level tool? And speed doesn't seem to be the primary concern of pacman, seeing the inefficiency of many things it does. (mostly the backend, but also doing many things multiple times, and not using appropriate data structures). I can only agree with the last point, it's indeed not cool to make a huge framework necessary in base, especially if it's only used by one app.

VMiklos

23 Jul 23 Jul

6:12 p.m.

Hello, Na Sun, Jul 22, 2007 at 09:50:01PM +0200, Xavier pisal(a):

...

How is a package manager a low level tool?

think of pacman.static, you can even run it without having glibc installed - VMiklos

Xavier

6:37 p.m.

On Mon, Jul 23, 2007 at 08:12:19PM +0200, VMiklos wrote:

...

Hello,

Na Sun, Jul 22, 2007 at 09:50:01PM +0200, Xavier pisal(a):

...
How is a package manager a low level tool?

think of pacman.static, you can even run it without having glibc installed

I agree this is very practical. I remember that when I was on Gentoo years ago, I broke python once, and that wasn't so cool. :) But it shouldn't be too hard to have something for automatically restoring python & emerge (in any cases, python can still be compiled / installed manually). So in any cases, I don't think a package manager is a low level tool. It's just that writing it at a low level indeed have several advantages. I'm just wondering if the inconvenients aren't bigger. I just believe that writing nice C code require more skills, and that there are less people able to do that. So if there were active developpers that could clean up all the messy parts, it wouldn't matter. Otherwise, using a higher level language might help in my opinion.

Bozhidar Batsov

7:35 a.m.

VMiklos wrote:

...

Hello,

Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov 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

------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

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. So having mono around won't be anything more that having perl or python say. But the C# source code is better structured, more secure and almost as fast as the C code(at least on a semi-modern machine), while the length of a similar application written in C and C# will be 3 to 5 times smaller in the C# version and the source itself would probably be easier to understand by people reading your apps. Mono is not large at all - the entire framework is about 25MB when packaged. I don't think that it want squeeze on an install cd.

Georg Grabler

7:52 a.m.

I can give you another point why NOT using alpm at the current state: - API Interfaces still change a lot (all 2-3 weeks) - The interface still is "ugly" - A lot of functionality is missing for a proper GUI client to be written You have done a great work on the C# implementation. I actually dislike the thought of having mono on the base, not for the reason that c# is anything good or bad, but for the reason that c# / mono isn't complete. I wouldn't even consider it as feature complete, they're always behind the current C# standards, often for a year. I lately tried to port an application to GTK# (a quite complex client), but it already failed on backend system functionality. The program is completely .NET 2.0, and SHOULD work out with mono. I found some articles / post on their groups that this is a bug of mono - i don't think a framework should come in a stable version with broken functionality, neither it should need more than half a year (as it's for now already) to get fixed. I can see C# making the deal into one of the main linux application development languages, but the time hasn't come yet. All of the applications you mentioned were either broken when i tried them (muine), had a bad or even worse performance (beagle) Currently, i also don't see any advantage of C# compared to python. In linux i see disadvantages, since there isn't too much software around, and not too many libs you can use. Also, we would set on a language which is not very popular in the linux community. As i know, C# has not even open standards. Yours, STi

Bozhidar Batsov

8:11 a.m.

"As i know, C# has not even open standards. " - that is not true, the specification of the language is open and freely available and it was used to build the original mono C# compiler. But you're right - mono is not feature complete yet, but is very close to being 100% compatible with .NET 2.0. The project's web site claims this will happen around the end of October. My biggest difficulty during the development cycle was the lack of documentation for the project. Monodoc would claim that something is not yet implemented, but when I look through mono's class hierarchy I'd see what I was looking for... My greatest concern is actually your remark about the popularity of the language in the linux community. Personally I have never in my life used C#/.NET with windows(for the simple reason that I don't have windows anywhere). But I felt in love with mono from the start. I had done development in Pascal, C, C++. Perl, Java, Python, Lisp, Prolog and some others. I didn't think that I would enjoy C#, but I was wrong. Its a great language, and .NET Framework is very capable environment so I believe that it can empower a package management system even better than pacman + alpm. But time will tell... Georg Grabler wrote:

...

I can give you another point why NOT using alpm at the current state: - API Interfaces still change a lot (all 2-3 weeks) - The interface still is "ugly" - A lot of functionality is missing for a proper GUI client to be written

You have done a great work on the C# implementation. I actually dislike the thought of having mono on the base, not for the reason that c# is anything good or bad, but for the reason that c# / mono isn't complete. I wouldn't even consider it as feature complete, they're always behind the current C# standards, often for a year.

I lately tried to port an application to GTK# (a quite complex client), but it already failed on backend system functionality. The program is completely .NET 2.0, and SHOULD work out with mono. I found some articles / post on their groups that this is a bug of mono - i don't think a framework should come in a stable version with broken functionality, neither it should need more than half a year (as it's for now already) to get fixed.

I can see C# making the deal into one of the main linux application development languages, but the time hasn't come yet. All of the applications you mentioned were either broken when i tried them (muine), had a bad or even worse performance (beagle)

Currently, i also don't see any advantage of C# compared to python. In linux i see disadvantages, since there isn't too much software around, and not too many libs you can use. Also, we would set on a language which is not very popular in the linux community. As i know, C# has not even open standards.

Yours, STi ------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Georg Grabler

8:32 a.m.

"As i know" meant actually i didn't know, and it was based on speculation and things i heard. Fact is, that .NET is released in 3.0, and we're not even 2.0 compatible yet. Don't get me wrong, I've been developing in several languages too, C# is just yet another language I've spent two years with (beta till 1.1, lately 2.0 for the reason it's used for a specific client in our company). I wouldn't say C# code is well structured, neither i'd say it's nicer to read than most current and popular interpreter languages (python in example). It's often leaking memory, also, the applications always eat tons on memory. Profilers are completely missing, what makes tweaking a lot of harder. I don't think it can empower a package manager, for the reason of compatibility. C/C++ can be embedded into other languages (Java, Lisp, Perl, Python, TCL/TK, Prolog, LUA, Ruby and others, while in C# you need to stay native. That's also a speculation, but i havn't seen any binding system or proper interface OUT of C# into other languages yet (the library way, not the service way). On 7/23/07, Bozhidar Batsov wrote:

...

"As i know, C# has not even open standards. " - that is not true, the specification of the language is open and freely available and it was used to build the original mono C# compiler. But you're right - mono is not feature complete yet, but is very close to being 100% compatible with .NET 2.0. The project's web site claims this will happen around the end of October. My biggest difficulty during the development cycle was the lack of documentation for the project. Monodoc would claim that something is not yet implemented, but when I look through mono's class hierarchy I'd see what I was looking for... My greatest concern is actually your remark about the popularity of the language in the linux community. Personally I have never in my life used C#/.NET with windows(for the simple reason that I don't have windows anywhere). But I felt in love with mono from the start. I had done development in Pascal, C, C++. Perl, Java, Python, Lisp, Prolog and some others. I didn't think that I would enjoy C#, but I was wrong. Its a great language, and .NET Framework is very capable environment so I believe that it can empower a package management system even better than pacman + alpm. But time will tell...

Georg Grabler wrote:

...
I can give you another point why NOT using alpm at the current state: - API Interfaces still change a lot (all 2-3 weeks) - The interface still is "ugly" - A lot of functionality is missing for a proper GUI client to be written

You have done a great work on the C# implementation. I actually dislike the thought of having mono on the base, not for the reason that c# is anything good or bad, but for the reason that c# / mono isn't complete. I wouldn't even consider it as feature complete, they're always behind the current C# standards, often for a year.

I lately tried to port an application to GTK# (a quite complex client), but it already failed on backend system functionality. The program is completely .NET 2.0, and SHOULD work out with mono. I found some articles / post on their groups that this is a bug of mono - i don't think a framework should come in a stable version with broken functionality, neither it should need more than half a year (as it's for now already) to get fixed.

I can see C# making the deal into one of the main linux application development languages, but the time hasn't come yet. All of the applications you mentioned were either broken when i tried them (muine), had a bad or even worse performance (beagle)

Currently, i also don't see any advantage of C# compared to python. In linux i see disadvantages, since there isn't too much software around, and not too many libs you can use. Also, we would set on a language which is not very popular in the linux community. As i know, C# has not even open standards.

Yours, STi ------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Gabriel C

1:24 p.m.

Bozhidar Batsov wrote:

...

VMiklos wrote:

...
Hello,

Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov 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

Georg Grabler

1:38 p.m.

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 wrote:

...

Bozhidar Batsov wrote:

...
VMiklos wrote:

...
Hello,

Na Fri, Jul 20, 2007 at 05:40:40PM +0300, Bozhidar Batsov < 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 http://archlinux.org/mailman/listinfo/pacman-dev

Bozhidar Batsov

1:55 p.m.

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* 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 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...

Georg Grabler

2:20 p.m.

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 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* 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 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

Bozhidar Batsov

2:32 p.m.

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@e-card.bg mailto: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* mailto: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 > mailto: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 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 mailto: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 mailto:pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

Georg Grabler

3:30 p.m.

I rather tend the other way. Gnome gets the better environment, and by far more support by commercial distributions. Anyway, the KDE guys are doing a good job, and i think they might have the state of the most modern DE for linux again, once KDE4 is released. I enjoy KDE, since i never could work productively in Gnome. There are a lot of great tools around for gnome, but i don't care any longer if the tool is QT or Gnome / GTK, since pierres gave me the hint of qt-curve. I just use the ones i like better (in this case, Firefox in example). I don't want a flamewar about the better DE now, both, Gnome and KDE have their things i prefer and dislike, even XFCE and Enlightenment are quite good. I think the people are satisfied with the pacman interface for their console, and are missing good GUI clients for it. That's why they pay more attention to Whirlwind, as i do. Don't get under the wheel, you did a great work on this. As long as it stays compatible to pacman (keeps updating the pacman database), i don't see a problem with any kind of gui or client for pacman. Yours, Georg On 7/23/07, Bozhidar Batsov wrote:

...

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

...
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 mailto: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* mailto: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 > mailto: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

Georg Grabler wrote: 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 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 mailto: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 mailto:pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

VMiklos

20 Jul 20 Jul

2:16 p.m.

Hello, Na Fri, Jul 20, 2007 at 04:13:34PM +0300, Bozhidar Batsov pisal(a):

...

1. The bindings do not reflect the true nature of a C# application. 2. By reimplementing everything there is the slight possibility that you'd do something better than it was done in the original - if it happens, it can be retrofitted there. 3. It is much more fun do it all...

sure, reinventing the weel is fun ;) - VMiklos

6131

Age (days ago)

6134

Last active (days ago)

List overview

Download

20 comments

5 participants

participants (5)

Bozhidar Batsov
Gabriel C
Georg Grabler
VMiklos
Xavier