Home

Python in Pardus Linux

Pardus Linux is a case study of functional Python. It's a Linux distribution built from semi-scratch, the main focii being package management and init subsystems - places where C and shell script make poor sense. A funded group has finally tackled these issues.

A package management software deals a lot with sets, lists, and dependency graphs....We have extensively used functional operators (map, filter, reduce) and list comprehensions, even metaclasses are used in a few places.

Someone nudge Guido. Scheme or Oz might have been the better choice, but give them credit. They admit frankly to social acceptance issues.

By Mark Evans at 2007-06-19 22:55 | Logic/Declarative | Object-Functional | Python | XML | other blogs | 12654 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More

A perennial Linux problem is outdated packages. Sometimes a very minor version upgrade is just what you need. Unfortunately packages grow stale while source code advances. Distributors cite lack of time, compatibility tests, stability tests, etc. The real story is that packaging is too much work. So it consolidates around major releases in a big push. Code developers complain that it's not their responsibility, but again, the real story is that it's too much work. Otherwise one would see pre-built pacakages with each code delta. Those would most help driver bugs in USB, bluetooth, sound, etc.

Packaging should not be hard. There are source-based distributions, I know. Pardus handles source and binary.

On the topic of init code, I would like more attention on external boot drives (UUIDs) and hotplugging, less on /dev nodes and drive letters and string matches. Kernel folks offer shell-style pattern matching as the answer; but Prolog rules might have been better. The proposition that Linux advances by confining system rules to legacy shell script design patterns on a syntax plane is rather debatable. When can we leave shell script behind? That will be an advance indeed.

By Mark Evans at Tue, 2007-06-19 22:56 | login or register to post comments

Refactoring lambda in Python

Don't take it too seriously ;)

Before lambda elimination ( example from the docs ):

files_all = set(map(lambda x:(x.path, x.hash), files.list))

After lambda elimination using a generator comprehension:

files_all = set((f.path, f.hash) for f in files.list)

By Kay Schluehr at Wed, 2007-06-20 06:34 | login or register to post comments

Comparing the FP bolt-ons

lambda was never as important as list comprehensions anyway. The real sin of Python was not going fully Stackless.

By Mark Evans at Wed, 2007-06-20 07:42 | login or register to post comments

NixOS

See also NixOS . I believe it has already been mentioned on LtU, but anyway...

By reinier punkt de at Wed, 2007-06-20 06:45 | login or register to post comments

That's a different motivation,

pure functional for its own sake. Pardus selected Python for other reasons (popularity, libraries, ease of learning) and still discovered themselves deploying FP techniques.

By Mark Evans at Wed, 2007-06-20 07:50 | login or register to post comments

Just a thought, couldn't the

Just a thought, couldn't the package management problem be better solved if there was some kind of connection/extension/modification/hybrid with version control systems and repositories?. I could potentially see the dependency & version problem disappear.

By snk_kid at Wed, 2007-06-20 08:57 | login or register to post comments

Er, well, yes, but...

Combination configuration management, build, test, and packaging systems tend to wind up being hideous monsters that hide in the shadows until you least expect it (or are running close to a deadline), then jump out, rip your hair off, and run away laughing. That said, if done right they dramatically productivity because problems show up almost immediately. Which is why they are either a feature or misfeature of most commercial config management, etc., systems, monsters and all.

Version dependencies are a problem with distributed development as done in the Linux world because most of the development groups have no particular relationship with the packagers, and can't do that kind of integrated development anyway. The responsibility for integration-related issues falls on the packager, where it goes from a problem to a major problem if the packagers do not have enough coordination.

There is no real way to make the problems disappear because the origin of many of the problems is in development and no one really wants to closely tie development and packaging, but a coordinated packaging environment can change the problems from something like "I upgraded GNU hello, and now my system won't boot!" to "GNU hello v27 has been out for 8 months, why don't you have a package for it?"

By Tommy McGuire at Wed, 2007-06-20 17:57 | login or register to post comments