Pardus, the python-based distro

DaNiMoTh · 2008-02-29 10:31:04

Pardus is a GNU/Linux distribution developed in Turkey, as a product of the Pardus Project. It was named after the Anatolian Leopard.
Pardus is an easy-to-install and use operating system, with many enhancements to desktop usability, compatibility and security. With Pardus 1.0 (and the now-released Pardus 2007 version), users can connect to Internet, read e-mails, securely communicate with others and exploit the computer's multimedia capabilities by listening to music and watching movies.
Ladislav Bodnar, the creator of DistroWatch, wrote in his round-up of Linux in 2006 that Pardus is one of the distros he was most impressed by this year "...thanks to unique package management ideas, innovative start-up sequence and general desktop polish..."[1]
Pardus is open source and freely distributed as a GPL (General Public License) product. It can be installed in Turkish, English, Spanish, German, Dutch or Brazilian Portuguese.

From http://en.pardus-wiki.org/Pardus:Contents

The thing that is impressive is their package manager, PiSi ( http://www.pardus.org.tr/eng/projects/pisi/index.html )
Feature:

* Implemented in Python
* Efficient and small
* Package sources are written in XML and Python
* Fast database access implemented with Berkeley DB
* Integrates low-level and high-level package operations (dependency resolution)
* Framework approach to build applications and tools upon
* Comprehensive CLI and a user-friendly Qt GUI (distributed separately)
* Extremely simple and fast package construction

Has anyone tried it? How is?

sweiss · 2008-02-29 10:39:49

XML, eh? A good enough reason for me to stay away from it

DaNiMoTh · 2008-02-29 12:30:54

sweiss wrote:

XML, eh? A good enough reason for me to stay away from it

why?

sweiss · 2008-02-29 12:56:46

Just kidding. But it seems XML is misused and has become practically a buzzword.
Look at how simple and efficient PKGBUILDs are. No need for XML.

INCSlayer · 2008-02-29 14:00:26

i used pardus for a while and it was a nice little distro although abit to neat for me i want to be able to get into the underbelly and poke around from time to time

Last edited by INCSlayer (2008-08-15 10:03:22)

KimTjik · 2008-02-29 14:37:20

Pardus is alright and could potentially become a great distro for new users of Linux. I have it running on a machine that isn't my personal one, and it did very well for a long time (it's still installed, but because of a xorg problem and outdated software Fedora 7 64bit has been running the show for a year on that computer).

Pros:
* rolling distribution
* nicely polished, with well organized menus
* software are well customized to work smoothly and well in Pardus
* PISI gui is a lot easier to search than for example synaptic for a new user
* to use a KDE desktop its very fast even on an older computer
* new users of Linux surely appreciate that multimedia codecs are installed by default

Cons:
* the rolling feature might break the system, which isn't great in view of its user base
* by default PISI force you to make a "pacman -Syu"; there are ways to get around this on the command line but it's not explained very well (at least not in English)
* the above is a bigger culprit than in Arch, because its customization makes it sometimes harder to fix
* documentation has become better, but unless you know Turkish it could be difficult to find all the answers
* some software in the repository are too outdated

To sum it up: I think it has a lot of potential, especially in view of its governmental support in Turkey. Pardus seems to keep a low key profile which is positive, but if it wouldn't have been for some supporters from Germany and Netherlands for example, it could still have been a well kept secret (that's at least how I understand the situation).

Arch fits my needs better, but I keep an eye on Pardus, because it could very well be a good alternative when folks ask me to install Linux for them.

Last edited by KimTjik (2008-02-29 14:41:13)

DaveCode · 2008-08-15 06:37:17

Noticing some Arch dev comments about pacman's future w.r.t. Python/C++ at

http://bbs.archlinux.org/viewtopic.php?id=38024

I was about to mention Pardus. It seems like if Arch decides to rewrite pacman, Pardus is worth a solid look. One can separate the PiSi/COMAR softwares from the rest of Pardus.

The main points are

(a) Pardus has institutional funding and charter, so they are not going away, and have full-time programmers;
(b) they are taking an entirely fresh look at packaging (and other) issues, not layering on old stuff; and
(c) using Python, a better choice nowadays than C or C++.

It's unclear how much they investigated pacman when designing PiSi. I don't worry about XML, that's just a syntax, and Linux already has hundreds of syntaxes, nobody complains. Mostly XML is machine generated and machine parsed. There are plenty of GUI tools to manufacture it, too, just like HTML tags (try nvu).

The real issue is how easy/reliable does PiSi/COMAR make package maintenance - key to repository growth and quality. One of the main attractions of any distro, Arch included, is the breadth and up-to-dateness of the software.

By the way if you want to see how powerful Python can be with networking, look at the Twisted Matrix framework.

So it might be possible for Arch to stay very much good old Arch, while migrating to PiSi! If the two groups helped each other, that would be a fantastic outcome, and certainly less work than rewriting pacman in C++.

This is not to berate pacman, which I love!, only to say: IF you intend to change pacman, then joining with PiSi development might be the smart way to get the same ultimate results for less work.

ornitorrincos · 2008-08-15 09:08:08

Mostly XML is machine generated and machine parsed. There are plenty of GUI tools to manufacture it, too, just like HTML tags (try nvu).

and PKGBUILD are done in bash which is human writable, readable and easily machine parsed, and also notice that you don't need any gui to edit it comfortably, which allows some people to work in CLI mode or allows you not to hassle opening guis

By the way if you want to see how powerful Python can be with networking, look at the Twisted Matrix framework.

in my opinion python is powerful, but still slower than C or C++, and rewriting pacman in python could lead to a slower code unless some pacman aspects are redesigned(as far as I know the package database is a nice bottleneck), but here Xavier or Dan will be better informed.

btw, is this some kind of gentoo pun?

Last edited by ornitorrincos (2008-08-15 09:55:07)

Barrucadu · 2008-08-15 09:57:10

You shouldn't need a GUI to edit XML comfortably, it's no more difficult than bash when you get used to it - in fact, it's much simpler as there isn't a plethora of tools to remember.

ornitorrincos · 2008-08-15 10:02:45

is even better than the following line in makepkg?
source PKGBUILD

Garns · 2008-08-15 11:09:10

Barrucadu wrote:

You shouldn't need a GUI to edit XML comfortably, it's no more difficult than bash when you get used to it - in fact, it's much simpler as there isn't a plethora of tools to remember.

You have to remember the equivalent of the tool instead...
You add another layer of abstraction with xml. PKGBUILDS are easy to read, in most cases, when you can read shell scripts, while you would have to learn another "language" when you switch to xml. And you loose flexibility, unless you allow calling of cli commands from your xmls, which somehow defeats the purpose of the whole thing.

mrunion · 2008-08-15 13:45:15

Opinions only, but:

Eeww -- XML! Please avoid XML for pacman. Please? It's just bloated. PKGBUILDs are just fine the way they are. Heck, use JSON! That's easy too! But PLEASE -- no XML!

Last edited by mrunion (2008-08-15 13:46:31)

shining · 2008-08-15 14:15:37

mrunion wrote:

Opinions only, but:
Eeww -- XML! Please avoid XML for pacman. Please? It's just bloated. PKGBUILDs are just fine the way they are. Heck, use JSON! That's easy too! But PLEASE -- no XML!

1) pacman does not deal with PKGBUILDs. pacman deals with packages, created by makepkg from PKGBUILDs.
2) who ever announced PKGBUILDs would be converted to xml?

This topic is about Pardus. Since it is on the Archlinux forums, it seems fair enough to do a comparison behind both. But it does not go beyond that.

DaveCode · 2008-08-26 23:27:46

ornitorrincos wrote:

btw, is this some kind of gentoo pun?

I don't know what that means, sorry.

What I was trying to say: The whole XML/syntax issue is very unimportant. We're on the same page that ease of package maintenance is the critical thing.

Now, looking at Pardus, they have as an explicit goal to facilitate that, some years of work behind it already, involving a study of existing Linux systems.

The speed debate is like the syntax debate, in a sense. You have to look at the application domain and decide whether ease of writing/maintaining code is more valuable than speed.

Having programmed in both C++ and Python for many years I would definitely pick Python for package maintenance tasks, which do not run every day.

I think the Pardus folks made the right judgment call, though they had the benefit of starting from a clean slate. The idea I wanted to float was that Arch might piggy back on them IF, and only IF, there is some sort of movement to revamp pacman in Python. I was really trying to address people already mentally committed to migrating to Python. If, instead, you want to stay in C or C++, then stay in pacman's code base.

DaveCode · 2008-08-26 23:41:24

Postscripting that before leaving the topic here, I should add "Python vs. C++" is often framed either/or, but isn't. There is a spectrum of operational usage.

Python integrates nicely with C++. As one example, the Boost Python Library gives you, at the C++ level, a way to write "Pythonish" C++.

In optimal systems speed tuning happens only where it needs to happen, not in a "global" way by "choosing" C++ which ignores the mix-n-match options.

I can't really think of a particular area of package management that needs speed tuning (dependency calcs? network?), but if one exists, then that can be handled by BPL or plain C++ libs, and linked to the Python.

jdhore · 2008-08-26 23:54:18

I was playing with Pardus last night...It's made it into my top 3 distros...It's a MUCH smaller community than Arch (no real AUR-like place, not very active IRC/Forums/Wiki), but aside from the KISS philosophy of Arch, most things between the 2 seem quite similar.

DaveCode · 2008-08-27 02:36:11

jdhore wrote:

MUCH smaller community than Arch...but...most things between the 2 seem quite similar.

Right. That's why there's synergy. Each distro has what the other needs. Pardus has a new packaging project in Python, and Arch has a large user base, plus devs who want to revamp pacman, some using Python in the task.

I don't think that Arch should adopt other aspects of Pardus (haven't studied them). It's feasible to help improve PiSi/COMAR alone and adopt the results for Arch. I only brought it up after seeing some Arch devs talking Python.

I imagine Pardus repos would hold the PiSi packages, but if Arch people could use them, that would be the migration path. Eventually the Arch repos would also carry them. Some variant of all that was my general feeling of what could possibly happen. Possibly, Arch devs could build legacy Arch package support into PiSi for easy migration.

Certainly two groups working on one project is more productive than two groups working on what would amount to identical Python code.

Right now all that PiSi fundamentally lacks is security sigs, which is on their to-do list.

iphitus · 2008-08-27 05:16:36

DaveCode wrote:

jdhore wrote:
MUCH smaller community than Arch...but...most things between the 2 seem quite similar.
Right. That's why there's synergy. Each distro has what the other needs. Pardus has a new packaging project in Python, and Arch has a large user base, plus devs who want to revamp pacman, some using Python in the task.
I don't think that Arch should adopt other aspects of Pardus (haven't studied them). It's feasible to help improve PiSi/COMAR alone and adopt the results for Arch. I only brought it up after seeing some Arch devs talking Python.

There's no plans to rewrite pacman in python. Pacman runs great in C, and it's being actively developed in C.

KimTjik · 2008-08-27 09:30:15

When discussing Pardus and making comparisons with Arch remember that Pardus is a totally different creature. Pardus has government backing and the main team of developers aren't volunteers, even though they might be motivated by the same ideals as Arch folks.

I don't say that cooperation is a bad thing, on the contrary, but Pardus is probably not the best candidate. Pardus is to foremost deliver a Turkish distribution which can be used in educational institutes managed by the state. A good and commendable goal, but it also shows how futile cooperation would be since Pardus is forced to set different priorities than Arch.

shining · 2008-08-27 09:43:11

I am also afraid that DaveCode is way off base.

DaveCode · 2008-08-27 11:09:21

Hand-waving ("off-base") and officialdom ("plans") are just sad....what motivated all this was Arch insiders doing their own blue-skying,

"I recall phrakture talking about really really wanting to rewrite it in C++, and Dan was recently talking about a rewrite of libalpm as well. Who knows what's in the future for pacman?"
http://bbs.archlinux.org/viewtopic.php? … 99#p286999

Codemac also demanded "empirical evidence" and Pardus provides it.
http://bbs.archlinux.org/viewtopic.php? … 08#p287108
http://bbs.archlinux.org/viewtopic.php? … 89#p286889

I see government backing as a positive benefit. I don't track KimTjik on that. The goals of the two package manager projects are identical AFAICT. Can you identify specific differences in goals, beyond the language war issues?

Anyway it's open source, and can be forked, like Debian's Iceweasel flavor of Firefox - essentially the same code. The 3 ATI driver groups have 3 different drivers going for the same equipment, but all three groups are cooperating where they can.

Some *nixers just have a belief in bash and C. I do not - bash is an awful language and C is only really good for bit pushing at the driver level (which it was designed to do, as portable assembly). That's my experience after too many years writing both. And believe me, I got and remain *really* good at them.

So I was heartened to see Arch people talking about Python. Writing in Boost Python with seamless interplay between C++ and Python is a dream. But hey, it's your baby. If you think the Arch C code will be doing better things that PiSi in 2-3 years, follow that plan.

Thanks for the discussion, everyone.

KimTjik · 2008-08-27 11:52:42

DaveCode, who has talked about some kind of "language war issue"? I didn't, and I don't understand what the word "war" has to do with it. English isn't even my second language of choice, so I've no reason to fight for some English dominance.

I only expressed a general view on how different the goals of Arch and Pardus are; http://www.pardus.org.tr/eng/info.html. If you would have followed my tracks you would also pretty soon find out that I've been promoting Pardus as an alternative to for example Ubuntu (... and some other *buntus). Pardus has improved a lot in the last two years, no doubt about that. Still documentation is culprit, if you aren't fluent in Turkish, which is crucial since Pardus partially has a very custom design. Believe me I'm testing Pardus on a constant basis - a box besides me is running Pardus - but some "standard" fixes for issues don't work in Pardus because Pardus doesn't always follow the standard structure. And that's a major difference in my opinion.

I'm not initiated enough to comment on the code language decision, and hence didn't comment it at all. Government backing is good, hence I wrote: "a good and commendable goal", but I also see a clash of interest when a purely community distro tries to cooperate with a government one. That's all. What is more pragmatic, at least in my view, would be "unofficial" interaction between developers on a personal basis, but not as an official commitment.

iphitus · 2008-08-27 13:15:10

DaveCode: I'm just stating the facts.

Pacman is C
There are multiple developers actively working on that codebase
There are no pacman developers working on a python based pacman replacement

There's a tonne of developers who love python, myself included. And dusty as you quote there -- but that doesnt mean we want to ditch a practical working codebase -- nobody you quoted are pacman devs. I'm very happy with pacman as it is now, and don't see any practical reason to dump the existing codebase and move to another. The present one works, it's mature, and is actively developed.

If C were only good for writing device drivers, then software developers would be swarming away from it -- this isn't the case. Most of the software you'll use on your Linux desktop is C/C++. The same goes on most other platforms too funnily enough. If you find it frustrating and complicated, that's your issue. Clearly, C is useful for more than device drivers...

Comparatively Pardus is not mature. Pardus uses an XML based package description, which means dumping our existing PKGBUILD architecture. You might not like bash, but it makes building a package absolutely trivial! Have you ever read a PKGBUILD? they're wonderful and simple. It's one of the great features that drew me to Arch. I saw a PKGBUILD and understood it _immediately_ without reading any documentation whatsoever. I dare you to say the same about RPM spec, or Pardus' XML. No XML based format could possibly come near the simplicity that is makepkg and PKGBUILDs.

I can see many _practical_ reasons against using their package manager, and no _practical_ reasons _for_ using it. I'm not even going to bother with the idealogical arguments, that's just a waste of time.

Last edited by iphitus (2008-08-27 13:16:15)

Obi-Lan · 2008-08-28 16:04:09

WHOA! Used by Turkey military and Turkey ministery of foreign affairs?

Arch Linux

#1 2008-02-29 10:31:04

Pardus, the python-based distro

#2 2008-02-29 10:39:49

Re: Pardus, the python-based distro

#3 2008-02-29 12:30:54

Re: Pardus, the python-based distro

#4 2008-02-29 12:56:46

Re: Pardus, the python-based distro

#5 2008-02-29 14:00:26

Re: Pardus, the python-based distro

#6 2008-02-29 14:37:20

Re: Pardus, the python-based distro

#7 2008-08-15 06:37:17

Re: Pardus, the python-based distro

#8 2008-08-15 09:08:08

Re: Pardus, the python-based distro

#9 2008-08-15 09:57:10

Re: Pardus, the python-based distro

#10 2008-08-15 10:02:45

Re: Pardus, the python-based distro

#11 2008-08-15 11:09:10

Re: Pardus, the python-based distro

#12 2008-08-15 13:45:15

Re: Pardus, the python-based distro

#13 2008-08-15 14:15:37

Re: Pardus, the python-based distro

#14 2008-08-26 23:27:46

Re: Pardus, the python-based distro

#15 2008-08-26 23:41:24

Re: Pardus, the python-based distro

#16 2008-08-26 23:54:18

Re: Pardus, the python-based distro

#17 2008-08-27 02:36:11

Re: Pardus, the python-based distro

#18 2008-08-27 05:16:36

Re: Pardus, the python-based distro

#19 2008-08-27 09:30:15

Re: Pardus, the python-based distro

#20 2008-08-27 09:43:11

Re: Pardus, the python-based distro

#21 2008-08-27 11:09:21

Re: Pardus, the python-based distro

#22 2008-08-27 11:52:42

Re: Pardus, the python-based distro

#23 2008-08-27 13:15:10

Re: Pardus, the python-based distro

#24 2008-08-28 16:04:09

Re: Pardus, the python-based distro

Board footer