There’s been some crowing recently about how wonderful it is, that a scripting language is no longer a dependency for an OS build.
My opinion is that this is a shame on many levels: it’s a shame because the time spent rewriting all of this code could have been better spent elsewhere, it’s a shame because this new code presumably has integrated a heap of new bugs and it’s a shame because the bar was raised for potential contributors to their codebase: if you don’t know C, you can’t write code for them.
Most importantly though, I believe that scripting languages have a better place in /usr/bin and as helper components for core OS functionality than some folks seem to believe.
I’ve been writing in Python for a few years now, first as part of our Xen port, now on IPS, and I think that the sorts of things most OS commands do is far easier to express, code and debug in Python than it is in C.
Perhaps it’s me, but I’m much more comfortable firing up an editor and debugging a script I can see, than I would be having to download and setup a complex build environment, compile sources (if that source is even available :-/ ) and drop binaries in place.
Excising Python from an operating system is like chopping off your arm. Sure, you’ve fewer dependencies now (the original reason cited for removing the code in question) – no need for wrist watches, and you won’t get worn patches on your jumpers at the elbow, etc. but I’m not convinced it was the right move.
Still, each to their own – this is merely my opinion.
Giovanni said:
Hint: Old school and old ways of thinking.
Milan Jurik said:
There is one unclear issue with scripting languages – maintainance. These languages are under heavy development in their syntax and semantics and they do not care so much about backward compatibility in long term. This can be real problem in future.
Paul F said:
My concern with using scripting languages as core components is about dependancies. If they’re handled well it’s OK, but too often they’re not.
A while back I was asked to install mailer.py for an SVN server. I thought, “This should be simple, right? I built Apache & Subversion, this should be a piece of cake.” I was wrong. The script itself was no problem, nor was Python itself. The problem was in the dependancies to actually run the script. I need to install the SVN python libraries, but those needed SWiK to build. I can’t recall why, but for some reason SWiK wasn’t available or usable on the machine, so I need to go build that. That in turn had it’s own dependancies. All in all I spent several hours just getting one script to run.
Don’t get me wrong, I think scripting languages are great tools. They’re far more productive than trying to write a simple utility in C or C++. But script authors needs to keep the dependances in mind. When I write a script that I intend to use as cross-OS or cross-distribution, I consciously decide to use as few dependancies as possible and to avoid fancy new features. Even if a library is available that has something useful available, I’ve often decided not to use it for just this reason. The pain up front is worth avoiding the pain of trying to make it work on every new system I have to deal with.
Giovanni said:
I believe the point here is that we are talking about using Python for core tools that will be shipped with a operating system release. In that environment, the vendor/project has control over which dependencies it wants to use and add to the final product.
However, most C/C++ code has dependencies as well. Perhaps it’s more likely to find scripts using a greater number of dependencies, but I wouldn’t have data to support that claim.
Your experience with mailer.py and SWIK doesn’t represent standard production use. You don’t install build dependencies in every server you plan to deploy your scripts to. If you were building C/C++ you’d still need to install GCC/SunStudio and other building tools (autoconf, automake, etc).
Garrett D'Amore said:
I expect this blog is partly in response to work I’ve been doing in illumos to eliminate *runtime* dependencies upon python.
The problem is, python isn’t well integrated into the core of the operating system at all. (At least not as a member of ON.) Nor should it be — it brings with it a large and complex dependency graph, and even the Sun/Oracle build was dependent upon *Gnome!*.
I think it should be possible to install a useful and functional operating system without having to pick up large runtimes like python, perl, or even Java.
This isn’t to suggest that Python isn’t a wonderful language for lots of other kinds of work. Heck, I use an editor that is largely based on a *lisp* runtime, and I happen to think the Java language is one of the best languages for real OO design.
But forcing everyone to install a large and complex runtime, with a dizzying dependency graph, to use the system just for the benefit of one or two critical system components that can trivially be implemented in C is a bad decision, IMO.
As with any task, I prefer the right tool for the job. For low level system utilities like the zfs command, beadm, or even system packaging, I think the benefit of a reduced dependency graph trumps the programmer “friendliness” of some of these other languages.
(If the python runtime were small, with minimal dependencies, and could reasonably be integrated into illumos-gate aka ON, directly, I might find myself having a different stance on it.)
Of course, others may just say I’m old and crufty. Maybe they’re right, but there is at least a method to my madness. :-)
Paul F said:
You’re correct that vendors have control over their dependencies, but I still think this is a concern. Dependencies are definitely an issue with native code as well, but scripting languages add an additional layer of complexity. The convenience of scripting languages and the depth of the third-party library support is a double edged sword. It makes it easy for the developer to pull in a library to perform a function, but it can also make packaging and deploying that tool more difficult. Perl actually provides it’s own package management tools that mimic much of the functionality provided by the OS.
I work in a largely Linux-based environment in my day job, and I support a huge variety of distributions. It’s not uncommon to use the package management system to install one package, and wind up installing a huge variety of seemingly unrelated packages to handle the dependencies. This seems to be an issue all the distributions I’ve ever used. I’ve played around with FreeBSD at home a little and I’ve seen it in the ports collection as well. I tried to install Kerberos, and it wound up compiling parts of Gnome to resolve dependencies.
This discussion started discussion core OS components. Today, even the core OS often includes many 3’rd party components. The days of monolithic single-vendor OSes seem to be over, except maybe for Microsoft. If more of these components were built using scripting languages, what would happen to the dependency tree? If we extrapolate further into the future, it seems like we’re heading towards dependency madness.
Tim Foster said:
Fair points all, but I’m not convinced by the larger dependency graph vs. ease of development/maintenance argument.
If a Python runtime brings in a GNOME dependency, then that suggests a poor factoring of the Solaris Python integration: something that should be fixed, no doubt. Widespread package refactoring is something we definitely want – we’re not done yet.
In this case, as best as I can see, pkg:/runtime/python-26 (itself only 43mb) depends on pkg:/runtime/tk-8, which then pulls in pkg:/x11/library/libx11 – does GNOME really come into the picture here? X does, and obviously that’s not good either.
‘pkg contents -t depend -o fmri,type [package]’ lets you easily follow the dependency chain of a given package.
It feels like fixing that dependency might have been a better investment in man-hours than ripping out Python altogether, the absence of which will only discourage the future inclusion of core OS utilities written in Python, despite it probably being the better tool for many jobs. Of course, they weren’t my hours, so I honestly can’t complain.
As for the general worry about maintenance and dependencies, we’re facing those already – with current onnv-based systems, we’ve got better tools to analyze system dependencies than we’ve ever had in the past.
Of these, pkgdepend(1) is the most notable, which does a great job at determining where dependencies really are at package publication time (unlike the user-declared dependencies of old in SVR4, which were largely based on folklore)
By shipping utilities which require a modern language runtime, we have a responsibility to keep that runtime current, but I believe that’s a good price to pay in this case, given the benefits that runtime provides.
UX-admin said:
“and I think that the sorts of things most OS commands do is far easier to express, code and debug in Python than it is in C.”
Unfortunately for the rest of us, you are dead wrong, and here is why:
first of all, don’t fix it if it isn’t broken; there are far more people on UNIX, and Solaris in particular, with C skills then there are superior script kiddies who know the latest programming language fad, in this case, Python.
C is a well understood, sufficiently low-level language to do anything in, from application programs to hardware manipulation. It offers flexibility. It offers portability. The price to pay for that is expertise in how to do those things correctly.
But I’d rather rely on expertise than on a programming language fad to run my OS and applications.
Further, Python is very poorly integrated with the OS, even on GNU/Linux, let alone on Solaris. Python’s build engine, is, to put it with heavy restraint – garbage. For instance, it cannot deal gracefully with anything other than GCC and default compile flags. Want to get that extra bit of performance with Sun Studio compilers and link with $ORIGIN? Forget it. It took me a MONTH of 8×5 working on the Python’s build engine just to compile it and link it properly to run on Solaris with -xO4 and $ORIGIN, among other things.
As if that in and of itself wasn’t bad enough, Python is not forward compatible: there is no guarantee that a program written for Python 2.4 will work in 2.5. Or 2.6. Or that a program tested on 2.6 will work in Python 3000. That is why every application written in Python on a certain version of the VM must be tested on every other version of that VM. And if the application was written on a newer revision of Python which includes new functionality in libraries, it will not work on the older one.
That is very poor design. And lack of professional engineering clearly shows.
I can’t afford such stunts with a programming language that should power my OS and my utilities and applications. It’s just way too critical.
One of the worst things about Python is that it is interpreted, and cannot be compiled into machine code, into assembler. Because of this, Python can NEVER run at close to bare metal speeds (OS layer overhead notwithstanding).
That’s a serious issue for performance and encapsulation of functionality.
Furthermore, Bourne shell family is well understood. AWK as a programming language is well understood, and it is extremely powerful in the right hands. Very easy to learn and with negligible requirements (“AWK was born on a slow machine with little memory.”)
These tools are well understood and have passed the test of time and stability of the last 40 years.
Why replace sh, ksh and AWK with Python?
Finally, if you are referring to the recent changeset in Illumos that removed an ARTIFICIAL DEPENDENCY on Python from zfs, it was one of the best things that I have seen in Solaris in a long time.
Kudos to Garrett & Co. for doing this.
Down with half-cooked, not well throught-through solutions lacking professional engineering, forward and backward compatibility and portability!
Back to C, back to shell, back to AWK!
Back to the roots!
Giovanni said:
@UX-Admin, thanks for the funniest comment ever.
UX-admin said:
“For low level system utilities like the zfs command, beadm, or even system packaging, I think the benefit of a reduced dependency graph trumps the programmer “friendliness” of some of these other languages.”
That’s right! I want a tool or an app which I can just take, pick up and hit the ground running, not be stuck trying to figure out and compile a ton of dependencies for, only to find out that the virtual machine of the programming language the app is supposed to run in is incompatible with the dependencies, which are newer!
Small, self-embedded and fast is what 99.99% of system administrators and developers need to get the job done.
When I am solving a problem, I want to be able to focus on solving a problem with tools that do not get in my way, instead of spending valuable time *bootstrapping* tools, just so I can *eventually* get to solving the problem!
UX-admin said:
“@UX-Admin, thanks for the funniest comment ever.”
You’re welcome. It might be funny to you, but I guarantee you it won’t be so funny once you get stuck in a position of trying to solve a problem, and find yourself building an entire toolchain in a programming language completely foreign to both you and the operating system, instead of working on the problem.
UX-admin said:
“Of course, others may just say I’m old and crufty.”
No, this comes from *experience*. You know that getting the job done means being lean & mean programming machine, using a proven toolset which withstood the test of time and is well understood.
Experience teaches us that programming languages – fads – come and go, but well thought out tools and programming languages are forever.
UX-admin said:
“In this case, as best as I can see, pkg:/runtime/python-26 (itself only 43mb) depends on pkg:/runtime/tk-8, which then pulls in pkg:/x11/library/libx11 – does GNOME really come into the picture here?”
I find it extremely alarming that you do not seem to see anything wrong with the fact that your “script” interpreter is 43MB, with… let’s see…
/usr/sbin/pkgchk -v ACMEpython |& wc -l
3428
3428 files?!? And that is of course my version of Python, because yours might differ significantly by content, depending on what I was successful in compiling and linking, and you were not, and vice versa.
In contrast:
-r-xr-xr-x 1 root root 81K Jun 26 2009 /sbin/sh
-r-xr-xr-x 3 root bin 167K Aug 7 2009 /usr/bin/ksh
-r-xr-xr-x 1 root bin 65K Oct 10 2007 /usr/xpg4/bin/awk
81KB, 167KB, and 65KB, respectively, single file environments, with minimal runtime dependencies.
UX-admin said:
“Of these, pkgdepend(1) is the most notable, which does a great job at determining where dependencies really are at package publication time (unlike the user-declared dependencies of old in SVR4, which were largely based on folklore)”
Again, where is this documented?
How far away are we from an “Application packaging developer’s guide”?
I haven’t forgotten asking you this question multiple times before, and receiving nothing but dead silence in response.
Tools and applications are only as good as their documentation.
If you want your tools to receive a better response, you must provide, not just good, but superb, detailed documentation.
Out here in the trenches, in the wild, we are not protected by the comfort of a development environment. We must solve problems and we must solve them quickly and efficiently; anything that the vendor didn’t solve, falls on us to do.
We honestly don’t have the resources to reverse-engineer how the greatest invention of your career works, nor do we have the resources to reverse engineer it only to be able to admire its cleverness and beauty, nor that of your favorite programming language du jour, whatever it might be.
We need documentation. And that documentation must be extremely detailed and must contain every example concievable; the more examples, the better.
Superb documentation, especially with something as critical as a software management subsystem, is not optional. We don’t spend time hacking on it every day like you do, so we the system administrators and system engineers, your target audience, are not as familiar with it as you are. Do not assume we are, because that assumption would be very wrong and incorrect.
Tim Foster said:
@UX-admin, I respectfully disagree.
As for the IPS documentation, we have man pages now – including a good one for pkgdepend(1) that includes an “EXAMPLES” section, but know that a larger guide is needed. What’s in the gate now can be viewed at:
http://src.opensolaris.org/source/xref/pkg/gate/doc/
Glynn Foster said:
I suspect Garrett was referring to the fact that ON was dependent on the desktop consolidation rather than GNOME itself (since Python is built within the desktop consolidation – no doubt something that will change with the userland consolidation).
UX-admin said:
“What’s in the gate now can be viewed at:
http://src.opensolaris.org/source/xref/pkg/gate/doc/”
Thank you kindly for the pointer, I’m most grateful for it.
Please be assured that I will go over each and every one of those files with a fine tooth comb.
John Levon said:
At least one major problem is that of debuggability. Traditionally, the dynamic environments have been a closed shop in terms of extracting the critical information necessary for determining an issue: you could use the Python debugger, *or* you could use your OS debugger, but not the two together. This is often a problem but it’s especially troublesome when you’re talking about the OS core.
The changes in Nevada to support Python (my work on DTrace, and the subsequent changes by Krister to make pstack work with Python) make a *huge* difference here IMO, and are a significant enabler for systems-level Python use. There’s still more work that could be done though.
PS you’re always best off ignoring “UX-admin”.