Domain: focusresearch.com
Stories and comments across the archive that link to focusresearch.com.
Comments · 9
-
Re:perl
-
SPAM and ABM: Not So New
While the idea is interesting, its not exactly new. I wrote about some similar capabilities in 2000 when describing Chronofile® (advanced communications technology, including permanent archival). And, the Chronofile® 1-pager refers to the 1999 book by Marc Stiegler , EarthWeb.
(From the article on Gregor's World)
-
Re:Good step
Err... I suppose you've never heard of psh?
-
Re:Perl in the Linux kernel?
Wasn't someone working on embedding a Perl interpreter in the Linux kernel a while ago? And/or rewriting all of
/bin as Perl scripts using the kernel-based interpreter?I haven't ever heard about it, until I read your comment. After a quick Google searching I found some info about it.
In the Summer 2000 issue of The Perl Journal, Simon Cozens wrote Perlix, The Perl Operating System article:
It started, as so many of these things do, with one of those interminable debates between programmers. You know what I mean. They usually end up with one party shouting something like "Well, fine, I don't care if it's impossible, I'm going to do it anyway!"
This time around, it was me, and the topic in question was an operating system user-space comprised of non-GNU components. An operating system consists of two components: the kernel, like Windows or Linux, which talks to the hardware and directs the action, and the user-space, which is all the programs that you see and use: a shell, Explorer, programs to list directories, move files, read your mail, play games, and so on.
On "free" operating systems, a sizeable proportion of the essential user-space - not the really high-level things like web browsers, but the basic stuff that gets the system up and running - comes from the GNU project, and it was these programs that I wanted to replace.
Don't get me wrong. This wasn't an anti-GNU jihad. But someone had told me it wasn't possible, which was precisely the incentive I needed to get stuck into an idea I'd had a while ago.
Any sensible person would use BSD code here -- the BSD project derived their utilities from de-commercialized sources of Unix, and evolved independently of GNU. But that would be easy. And it wouldn't be fun. If you're going to prove a point, do it with style. So I was going to do it with Perl. [...]
Very interesting text, he mentions Tom Christiansen's Perl Power Tools: The Unix Reconstruction Project - "Our goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so." I like the simple version of cat:
#!/usr/bin/perl -w
print while <>;Simon Cozens also writes about Gregor Purdy's Perl Shell (psh) - "The Perl Shell is a shell that combines the interactive nature of a Unix shell with the power of Perl. The goal is to eventually have a full featured shell that behaves as expected for normal shell activity. But, the Perl Shell will use Perl syntax and functionality for control-flow statements and other things." - and about Claudio Calvelli's Linux filesystem written in Perl (PerlFS), but the link is dead and I couldn't find the new PerlFS home page (anyone knows it?).
On 2000-09-26 the SF Project: Perlix Kernel was registered by Bill Dahab. The Perlix.sf.net homepage is empty, the Development Status is Planning. The stats show more activity a year ago. Here's the summary:
Perlix is to be an POSIX compliant operating system based on the more graceful language of Perl, in stead of the uglier C. This specific project is to make a kernel written in Perl, and other core components for this operating system
Let me also quote the latest news about Perlix:
Posted By: rydor
Date: 2001-08-05 14:19
Summary: Ok, the deal with perlixFor one thing, work has not yet really begun on the perlix kernel, at most it's been in speculation. The main thing, is that this project really needs Perl6 to go ahead. Also, is needed (i don't really know if Perl6 will allow it) is direct memory writing via perl. If anyone wants to hack it into Perl 5, that would be great. One thing that may be very helpful, is to load Perl into system memory. From there Perl should run fast enough on a more high end computer to support a kernel. Another thing that has been thought about is since a Perl kernel would be relatively dynamic, have on the fly kernel upgrades, via a special script to be written. So if you want to swap in a new network driver that works better, you use this script, and the script would somehow through that driver in quickly. Anyway, If anyone is interested in joining for planning this out, either email me at Rydor@dahab.com or post to the board here, but posting to that board will probably take me a lot longer to figure out that you've done so. Anyway, hopefully we can get this figured out enough to get off the ground, and I hope the project will be lots of fun.
I also found Greg McLearn's Perl Operating System: Initial Planning Stage from 2001-11-23:
The first order of business is to make a bootable Perl kernel. Basically, this will consist of the Perl 4 core components being hacked into a state whereby it can be loaded into memory after booting and executed. In the initial stages, any Perl code to be executed will be stored as a string and handed to the interpreter module. In later stages, the Perl code will be executed from an arbitrary memory buffer.
Making the Perl 4 core components bootable is easier said than done. A memory-management system will have to be created to replace that found in a standard Unix system. As well, any dependency on the I/O subsystem will have to be removed or replaced.
I am basing the initial design on Perl 4 because the source code is far easier to understand and modify. Perl 4 does not contain many oddities currently found in the Perl 5 runtime (such as OOP and macro-hell). [...]
It sounds very interesting and I'm going to find out more about the current stage of Perlix/PerlOS development (if any). If anyone knows something interesting, please let us know.
-
How I did it
Having learned enough C, C++, and perl to at least read most code (and thus be dangerous), I went through the software I was actually using, and whose code looked comprehendable to me. Psh for one, Xfce for another. Signed up for the dev lists, looked at what they were working on. Downloaded the source to xfce, fiddled with it, broke it, downloaded it again & backed it up this time, messed with some of the smaller features until I found one I thought I could improve. Emailed the project guy, who was very nice, and told me how to get code to him. Borrowed my roommate's GTK book, hacked on it until it worked, and sent the modified source in. My name is in the changelog now
:)
So basically, look at the stuff you use, on your system, and see which parts you might want to change. Then do it, and if your changes work out, see if the maintainers are interested in them. My change was probably under 50 lines of code, and there was a bug in it when I submitted it, but it's how you get started.
-- -
Re:As a long-time Mac user, let me say
>i am the most l33t mac user in the universe coz
>my mac dual boots into Linux and uses psh (PrimOS
>shell-like)
Damn. For a second I thought I had found someone else who uses the Perl shell, currently at 0.0.8. -
Try it out for yourself
-
[OT] speaking of shells
If you're interested in a cross-platform Unix-style shell implemented in Perl, take a look at psh (SourceForge). We can always use developers, testers, and technical writers. It's licensed like Perl (GPL and Artistic).
-
Maybe now is the time for CVFS?
Hmmm... I've had this idea occur to me a few times over the last couple of years, but I just put together some notes last night and earlier today. Maybe some of us should get together, spec it out and code it:
http://www.focusresearch.com /gregor/project_ideas/cvfs.html
--------------------