Submitted by Python is becoming popular, and using Python within a distribution in every aspects has just become real. Pardus is extensively built on Python, starting from init subsytem through installation, hardware configuration and system management. Read on to see how Pardus developers started with Python and built a mature system using Python APIs.
Using Python Everywhere: a Case Study with Pardus
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’ve always thought writing a configuration system in Python. Yet seems like I was lazy and they were not.
“In the current release of Pardus, package installation, system startup, display configuration, network and firewall configuration, user management, time and settings are all carried to the Comar. Scripts and graphical user interfaces are coded and running. More subsystems like power management and storage management are in progress.”
This is also very efficient for network administration. (i.e: you’ll not need to care about internal details when adding a user to a remote machine). If somehow “mainstream” distributions adopt these technologies, Active Directory like functionality will be default on Linux servers in no time.
I agree, although I would prefer that they work on improving Python’s efficiency a bit before it becomes more mainstream. Eventually it should run on the JVM or on Parrot, with some effort.
Python does run on the JVM using Jython.
Python does run on the CLR using IronPython.
Python actually has a lot of optimised C code in a lot of it core modules which makes it one of the fastest “dynamic” languages.
“Python actually has a lot of optimised C code in a lot of it core modules which makes it one of the fastest “dynamic” languages.”
Please don’t confuse “written in C” with “it must perform well.” There are so many other variables that factor into performance besides what language is used.
That being said, the numbers for IronPython compared to vanilla Python are quite dramatic (google IronPython performance) and it’s written entirely in managed code (C# actually).
“the numbers for IronPython compared to vanilla Python are quite dramatic”
Try to do your own benchmarks before believing in those numbers… I did, and CPython beat IronPython in all my tests, hands down.
Please don’t confuse “written in C” with “it must perform well.” There are so many other variables that factor into performance besides what language is used.
Nobody was, I know I wasn’t. The point is that it is generally “fast enough”. If you want “raw” speed choose a different language.
While it may be one of the faster scripting languages (tied with Perl), it is still about 20 times slower than C. (All benchmarks are bogus but to get a sense of order of magnitude, see the Computer Language Shootout.)
That having been said, language performance probably doesn’t matter that much in GUI or system control applications because most of the time will be spent waiting on the user or whatever sub-program is spawned to start or stop a service.
it is still about 20 times slower than C
That’s probably right, but the end user doesn’t see any difference between 20 ms and 1 ms.
That’s probably right, but the end user doesn’t see any difference between 20 ms and 1 ms.
They do when the operation is done a couple of thousand times.
They do when the operation is done a couple of thousand times.
If it’s done a couple of thousand of times in a loop, yes. But, most code doesn’t have to go through that.
Take Pardus’s bootscripts: If you are running them a couple of thousand of times you really need a UPS.
That was actually kind of the point of my post. There have been tests on this and if an application responds faster that 100ms (IIRC) is perceived as instantaneous by users. If if your application (as with many GUI applications) takes only 20ms to respond, there is no point in writing it in C. But if your IDE takes 20 seconds to dynamically recompile your code, then the factor of 20 is probably worth it.
Python does run on the JVM using Jython.
Python does run on the CLR using IronPython.
Python also runs on a JIT dynamic recompiler called Psycho.
Depending upon what you are doing psyco can make anything from no difference at all to an amazing one.
A while back I coded a very simple prime number generator in both C and Python. Both were coded the same way. I just used a basic “gcc -O3” for compiling the C code.
The C version was about 10x faster than the Python version. (Not too bad, all things considered.)
But when I turned on psyco, the python version ran about half as fast as the C, which I think is pretty impressive.
A horribly simplistic “benchmark”, I know. But I thought it was pretty neat to see Python do so well in a tight loop. 🙂
Unfortunately, x86 is the *only* architecture currently supported. (Not even X68_64 is supported.)
-Steve
Using Python and selectively writing your critical code in C is the typical method I use and have seen amazing results.
I had written a pure brute force perfect number tester in Python. In order to have it scale across the target platform (8 cores), I used Python threading and wrote the actual calculation code in C. This enabled me to write my all my complex code in Python but defer to C for the heavy calculations, and also get around the single process issue with Python. I was able to increase performance by an enormous amount (I can’t currently remember the factor) and also scale across many cores. The C module was ~20 lines long; everything else was Python.
No need to try and optimize the whole lot of your code in most cases (psyco). Just profile and rewrite the key areas.
I’ve always thought writing a configuration system in Python. Yet seems like I was lazy and they were not.
This is the second major attempt at a Python-based administration system for Linux. The first formed the basis of Gentoo. It totally rocks in terms of functionality, although it’s definitely a bit slow at times. This is mostly because they never quite figured out a good caching design.
Basically, an admin system is frequently going to be I/O-bound, and this is where the user is going to perceive slowness. Pick whichever language is easiest to write and maintain. Python is certainly among the very best in these respects. But you have to figure out a way to minimize and hide the cost of I/O. If you don’t cache effectively, it wouldn’t matter if you wrote it in hand-optimized assembly.
Using python for more things makes it much more worth the hdd space and memory it requires.
The problem with having python,ruby,perl,php,mono,java etc. available to programmers is that they tend to replicate much of each other’s functionality and are all rather large because they all have really large standard libraries.
Pardus is an excellent distribution, really. One of the best out there IMHO.
The use of Python is a good idea. Performance (meaning speed) is not an issue. It does, however, require more memory than if things were written in C/C++, but still quite less than if they were written in Mono or Java.
It’s funny that Python is one of the languages that “can save Gnome” (as they put it sometimes, referring to several higher level languages as opposed to C) and here it’s, I wouldn’t say saving, but serving a KDE based distro quite well too.
If higher level languages have to get more popular on the desktop, my vote goes for Python. Java is a great language, but it just uses too much memory. And Mono…well, I’m just not a fan of Mono.