[log in to unmask] wrote:
>
> X-no-Archive:yes
> Um, I'm pretty sure that Mark was speaking for himself, posting from
> [log in to unmask], and not for HP...
That's correct, stuff posted from [log in to unmask] is speaking for myself only,
unless I explicitly say "HP this" or "CSY that". If I speak in a strictly HP
role, I do it from [log in to unmask]
I think Ken Hirsch, Gavin Scott, and Mark Klein have all made good comments on
this thread.
> This really does open up the proverbial "can of worms", although that's not
> necessarily a bad thing. I don't know enough about PostgreSQL to know to
> what degree it has been proven, or not. The thread on slashdot had some
> things to say about the open-source RDBMSs, versus Oracle. Others are
> probably better suited than I am to address what PostgreSQL does and does
> not allow us to do. If Mark did this, and on his own time, I have to assume
> that he saw the merit in it (perhaps for other open source apps?).
I've never used PostgreSQL before, nor have I compared its features to other
databases. I chose to port it because it seemed to have decent documentation
and did not require the use of threads (which I have never used on MPE).
I have wanted to port an opensource database for a long time, because it fills
an important gap in the bixby.org offerings. I've ported Apache for the front
end. I've ported syslog, bind, and sendmail for the infrastructure. I've
ported languages like Perl and PHP for application development. But what was
lacking was a standard opensource database for storing non-trivial amounts of
data.
Opensource development tools like Perl or PHP come with the hooks already built
in to talk to opensource databases like PostgreSQL, but no support whatsoever
for TurboImage. Rather than spending weeks or months designing a custom
TurboImage interface, spending 2.5 days getting PostgreSQL to say "Hello world"
seems like a good use of my time to make additional database functionality
available via standard interfaces.
The main point of my PostgreSQL port is this -- with very little effort, one
person can bring significant new functionality to the platform in very little
time. It only took 2.5 days to port ~400,000 lines of PostgreSQL code.
There is a spectrum of actions that people can take to bring new functionality
to MPE:
1) Participate in the System Improvement Ballot process. The first round of
voting concluded last week, and the final round of voting will start soon.
<Speaking for CSY>CSY is serious about implementing some of the final Top Ten
items this year</Speaking for CSY>. There will be many interesting database
items to choose from. If you want to influence what gets added to MPE, vote!
Right now, enhancing TurboImage is only something that CSY can do, so your
input via the SIB will make a difference.
2) Create your own new functionality from scratch and release it as opensource
to share it with the world.
3) Port existing Unix-based opensource apps to MPE and leverage the efforts of
hundreds of developers worldwide.
In response to my PostgreSQL post, I did get a reply from a person who has
never previously inquired about porting (IIRC) but who would now like pointers
on how to get started. In case anybody else is wondering the same thing, the
rest of this message is a copy of my reply:
> I hope you can take the time to point out a starting point where a newbee
> could begin learning about opensource, porting, and e-applications.
...snip...
For some general opensource background, please see:
http://www.opensource.org/
Loosely defined, "opensource" is software for which the source code is freely
available and usually developed cooperatively. Apache is one of the more
famous examples of opensource.
By porting opensource apps to MPE, you can leverage the work of hundreds of
developers, spending FAR less time doing the port compared to developing a
similar application from scratch.
Most opensource code is written in C or C++, with an increasing amount also
being written in higher level languages like Perl or Java.
All of the stuff I've ported has been mostly written in C. Apache was my first
port, and when I started I had only written one simple C program in my life.
So you don't need to be a C expert to get started. But it helps to have C
manuals available for reference.
Most opensource stuff originates from the land or Unix or Linux, so having some
Unix knowledge is helpful. It helps to have access to Unix documentation so
you know how stuff is actually supposed to work when you're trying to get it
running on MPE.
It helps if you've actually used the application you're porting. But this
isn't required either; I've never used PostgreSQL, yet I was able to get it
running minimally without too much trouble.
I have some porting tips at http://www.bixby.org/mark/porting.html, which I
really should update one of these days. Lars Appel has some stuff at
http://www.editcorp.com/Personal/Lars_Appel/index.html.
Opensource C apps all expect to be compiled with the gcc compiler. You can
download gcc for MPE from http://jazz.external.hp.com/src/gnu/gnuframe.html.
For getting started with your first port, I'd recommend porting any of the GNU
stuff from http://www.gnu.org/. The apps all use a common autoconfig script
which analyzes your runtime environment and (usually) chooses the correct
build-time features to be used. Network/sockets apps usually have more porting
issues than non-network apps.
If you attempt a port and get stuck, please post your questions to HP3000-L
where either I or one of the other porters will be eager to help.
--
[log in to unmask]
Remainder of .sig suppressed to conserve scarce California electrons...
|
