7 Sep
2015
7 Sep
'15
10:23 p.m.
Since I have some spare time on my hands, I've decided to create a .HLP file that
describes service / nodes on HECnet.
If you want an entry, basically just email me some text to sampsa at mac.com and I'll
compile a HECNET help library out of the entries.
So if you're offering some cool service, guest accounts, allow registration of user
accounts, are running on unusual hardware (I know there's a couple of TOPS-20 systems
out there, I really want to learn that OS) then let me know.
I'll release a new .HLP file (over both FAL and HTTP) along with instructions on how
to import it into your system's HELP library whenever there's new material or
material is changed / removed..
See the text below for an example, but please start your numbering at heading level 2:
--- SNIP (lines beginning with a number are like <h#> tags in HTML) ------
1 HILANT
# # # # ## # # #####
# # # # # # ## # #
###### # # # # # # # #
# # # # ###### # # # #
# # # # # # # ## #
# # # ###### # # # # #
Welcome to the HILANT VAX Cluster, part of the SAMPSACOM, .FI section.
2 Accounts
No guest accounts at the moment, but if you log in as ACCTREQ
you can apply for a full one.
For the more active accounts you can interact with, look in
Active Accounts here or KAHUNA$:[INFO]ACCOUNTS.TXT
3 Active Accounts
List of quite active accounts on HILANT::
-----------------------------------------
SAMPSA Sampsa Laine, owner, admin
DAVIDSON Steve Davidson, co-conspirator, admin
2 Mail
Mail can be sent to HECnet users directly using the <NODE>::<USER>
syntax I'm sure you are all familiar with.
To send mail to the internet, route it via the CHIMPYMAIL gateway,
using this syntax:
CHIMPY::smtp%"joe.user at example.com"
Please note that some providers (notably Apple and Hotmail/Windows Live)
do not accept this as a valid address. Gmail does however.
Your inbound address is:
KUHAVX::<username>@chimpymail.com
For information on how to forward your mail, see the Forwarding
subsection.
See KAHUNA$:[INFO]ACCOUNTS.TXT for the most active accounts, usually
admins who can help you.
--- SNIP ---
7 Sep
7 Sep
10:27 p.m.
Sampsa, nice of you to offer this. Just pointing out that this is pretty
much VMS-only, as help files, libraries and functions are somewhat
different in different OSes...
Johnny
On 2015-09-07 22:23, Sampsa Laine wrote:
Since I have some spare time on my hands, I've
decided to create a .HLP file that describes service / nodes on HECnet.
If you want an entry, basically just email me some text to sampsa at mac.com and I'll
compile a HECNET help library out of the entries.
So if you're offering some cool service, guest accounts, allow registration of user
accounts, are running on unusual hardware (I know there's a couple of TOPS-20 systems
out there, I really want to learn that OS) then let me know.
I'll release a new .HLP file (over both FAL and HTTP) along with instructions on how
to import it into your system's HELP library whenever there's new material or
material is changed / removed..
See the text below for an example, but please start your numbering at heading level 2:
--- SNIP (lines beginning with a number are like <h#> tags in HTML) ------
1 HILANT
# # # # ## # # #####
# # # # # # ## # #
###### # # # # # # # #
# # # # ###### # # # #
# # # # # # # ## #
# # # ###### # # # # #
Welcome to the HILANT VAX Cluster, part of the SAMPSACOM, .FI section.
2 Accounts
No guest accounts at the moment, but if you log in as ACCTREQ
you can apply for a full one.
For the more active accounts you can interact with, look in
Active Accounts here or KAHUNA$:[INFO]ACCOUNTS.TXT
3 Active Accounts
List of quite active accounts on HILANT::
-----------------------------------------
SAMPSA Sampsa Laine, owner, admin
DAVIDSON Steve Davidson, co-conspirator, admin
2 Mail
Mail can be sent to HECnet users directly using the <NODE>::<USER>
syntax I'm sure you are all familiar with.
To send mail to the internet, route it via the CHIMPYMAIL gateway,
using this syntax:
CHIMPY::smtp%"joe.user at example.com"
Please note that some providers (notably Apple and Hotmail/Windows Live)
do not accept this as a valid address. Gmail does however.
Your inbound address is:
KUHAVX::<username>@chimpymail.com
For information on how to forward your mail, see the Forwarding
subsection.
See KAHUNA$:[INFO]ACCOUNTS.TXT for the most active accounts, usually
admins who can help you.
--- SNIP ---
10:31 p.m.
I'm aware of this, and would be happy to write a script or two to convert the source
material to something that'll work on other systems as well.
I might even try to upload all this into a Wiki if there's interest (closed Wiki for
HECnet members only :), of course)..
But as a start, a nice VMS HELP file is something rather than nothing, right?
PS: If I do set up the Wiki, we could modify the software on madame to allow people to
click on a node name and get the Wiki entry from that route.
I just have this feeling that's there's lots of cool stuff to discover on HECnet
and it'd be great to document it all - of course nobody is forced to participate if
they don't feel like it.
sampsa
On 7 Sep 2015, at 21:27, Johnny Billquist <bqt at softjar.se> wrote:
Sampsa, nice of you to offer this. Just pointing out
that this is pretty much VMS-only, as help files, libraries and functions are somewhat
different in different OSes...
Johnny
On 2015-09-07 22:23, Sampsa Laine wrote:
Since I have some spare time on my hands,
I've decided to create a .HLP file that describes service / nodes on HECnet.
If you want an entry, basically just email me some text to sampsa at mac.com and I'll
compile a HECNET help library out of the entries.
So if you're offering some cool service, guest accounts, allow registration of user
accounts, are running on unusual hardware (I know there's a couple of TOPS-20 systems
out there, I really want to learn that OS) then let me know.
I'll release a new .HLP file (over both FAL and HTTP) along with instructions on how
to import it into your system's HELP library whenever there's new material or
material is changed / removed..
See the text below for an example, but please start your numbering at heading level 2:
--- SNIP (lines beginning with a number are like <h#> tags in HTML) ------
1 HILANT
# # # # ## # # #####
# # # # # # ## # #
###### # # # # # # # #
# # # # ###### # # # #
# # # # # # # ## #
# # # ###### # # # # #
Welcome to the HILANT VAX Cluster, part of the SAMPSACOM, .FI section.
2 Accounts
No guest accounts at the moment, but if you log in as ACCTREQ
you can apply for a full one.
For the more active accounts you can interact with, look in
Active Accounts here or KAHUNA$:[INFO]ACCOUNTS.TXT
3 Active Accounts
List of quite active accounts on HILANT::
-----------------------------------------
SAMPSA Sampsa Laine, owner, admin
DAVIDSON Steve Davidson, co-conspirator, admin
2 Mail
Mail can be sent to HECnet users directly using the <NODE>::<USER>
syntax I'm sure you are all familiar with.
To send mail to the internet, route it via the CHIMPYMAIL gateway,
using this syntax:
CHIMPY::smtp%"joe.user at example.com"
Please note that some providers (notably Apple and Hotmail/Windows Live)
do not accept this as a valid address. Gmail does however.
Your inbound address is:
KUHAVX::<username>@chimpymail.com
For information on how to forward your mail, see the Forwarding
subsection.
See KAHUNA$:[INFO]ACCOUNTS.TXT for the most active accounts, usually
admins who can help you.
--- SNIP ---
11:50 p.m.
On 07/09/2015 21:31, Sampsa Laine wrote:
I'm aware of this, and would be happy to write a
script or two to convert the source material to something that'll work on other
systems as well.
I might even try to upload all this into a Wiki if there's interest (closed Wiki for
HECnet members only :), of course)..
But as a start, a nice VMS HELP file is something rather than nothing, right?
PS: If I do set up the Wiki, we could modify the software on madame to allow people to
click on a node name and get the Wiki entry from that route.
I just have this feeling that's there's lots of cool stuff to discover on HECnet
and it'd be great to document it all - of course nobody is forced to participate if
they don't feel like it.
This probably sounds ludicrous and over-ambitious but would it make
sense to compile the information into a database then run various
scripts to compile files of various formats from it?
Just the way my mind works :)
--
Mark @ DECtec.info
twitter.com/DECtecInfo
8 Sep
8 Sep
1:06 a.m.
On 09/07/2015 05:50 PM, Mark Benson wrote:
This probably sounds ludicrous and over-ambitious but
would it make
sense to compile the information into a database then run various
scripts to compile files of various formats from it?
Just the way my mind works :)
Are you kidding?? This is a phenomenally great idea!
About 12-13 years ago I worked on a project building a commercial
product. I was doing the hardware and firmware, but I was able to steer
the documentation team a bit. We ended up writing all of the
documentation source material in XML, and we had some XSLT scripts to
generate printed manuals, the help files for the application, and the
online documentation on the website. It was all driven from the XML
source documents, so it never got out of sync. It was great.
Sure, I really dislike XML, it's way too friggin' verbose and
overcomplicated for what it is, but it has some pretty significant
advantages: It's well understood, it's standardized, it's documented,
and there are scads of tools out there to manipulate it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
1:57 a.m.
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and files..
Then just convert them to whatever format you want.
Sampsa
On 8 Sep 2015, at 00:06, Dave McGuire <mcguire at neurotica.com> wrote:
On 09/07/2015 05:50 PM, Mark Benson wrote:
This probably sounds ludicrous and over-ambitious
but would it make
sense to compile the information into a database then run various
scripts to compile files of various formats from it?
Just the way my mind works :)
Are you kidding?? This is a phenomenally great idea!
About 12-13 years ago I worked on a project building a commercial
product. I was doing the hardware and firmware, but I was able to steer
the documentation team a bit. We ended up writing all of the
documentation source material in XML, and we had some XSLT scripts to
generate printed manuals, the help files for the application, and the
online documentation on the website. It was all driven from the XML
source documents, so it never got out of sync. It was great.
Sure, I really dislike XML, it's way too friggin' verbose and
overcomplicated for what it is, but it has some pretty significant
advantages: It's well understood, it's standardized, it's documented,
and there are scads of tools out there to manipulate it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA 
8:53 a.m.
Most people who've worked with xml and xsl/xslt think it's the devils spawn
but yoy can get significant work done with it. It just ain't pretty!
A more DEC centric solution such as vax document would be cool however.
Mark
On 8 Sep 2015 00:57, "Sampsa Laine" <sampsa at mac.com> wrote:
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and
files..
Then just convert them to whatever format you want.
Sampsa
On 8 Sep 2015, at 00:06, Dave McGuire <mcguire at neurotica.com> wrote:
On 09/07/2015 05:50 PM, Mark Benson wrote:
This probably sounds ludicrous and over-ambitious
but would it make
sense to compile the information into a database then run various
scripts to compile files of various formats from it?
Just the way my mind works :)
Are you kidding?? This is a phenomenally great idea!
About 12-13 years ago I worked on a project building a commercial
product. I was doing the hardware and firmware, but I was able to steer
the documentation team a bit. We ended up writing all of the
documentation source material in XML, and we had some XSLT scripts to
generate printed manuals, the help files for the application, and the
online documentation on the website. It was all driven from the XML
source documents, so it never got out of sync. It was great.
Sure, I really dislike XML, it's way too friggin' verbose and
overcomplicated for what it is, but it has some pretty significant
advantages: It's well understood, it's standardized, it's documented,
and there are scads of tools out there to manipulate it.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
9:34 a.m.
On 08/09/2015 00:57, Sampsa Laine wrote:
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and
also potentially makes the data structure less flexible for future
applications, but it is easier to host and transport. Kind of. But
please, no XML. It makes my ears bleed.
I'd love to do a Python/Django/PostgreSQL project with a set of output
scripts but I have no Django-friendly hosting that could be reliably
internet-facing available (only LAMP and frankly I'm starting to dislike
PHP more and more). A
I tried goofing with MediaWiki a while back but found it to be... well
not to my taste. It's a useful tool but it's not the right one for this
IMHO, I think outputting Wiki data to files for various OSs might be a
bit of a bear.
--
Mark @ DECtec.info
twitter.com/DECtecInfo
10:44 a.m.
My only other thought is maybe a DEC-based database like DATATRIEVE
might have a TCP/IP connection I might be able to poke with a modern
language to extract data from? I am not sure though. I only work in a
very narrow field myself with modern systems so I'm not an expert, I
just like the idea of attacking this, but I might be overthinking it a
bit ;)
--
Mark Benson
On Tue, Sep 8, 2015 at 8:34 AM, Mark Benson <md.benson at gmail.com> wrote:
On 08/09/2015 00:57, Sampsa Laine wrote:
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and
files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and also
potentially makes the data structure less flexible for future applications,
but it is easier to host and transport. Kind of. But please, no XML. It
makes my ears bleed.
I'd love to do a Python/Django/PostgreSQL project with a set of output
scripts but I have no Django-friendly hosting that could be reliably
internet-facing available (only LAMP and frankly I'm starting to dislike PHP
more and more). A
I tried goofing with MediaWiki a while back but found it to be... well not
to my taste. It's a useful tool but it's not the right one for this IMHO, I
think outputting Wiki data to files for various OSs might be a bit of a
bear.
--
Mark @ DECtec.info
twitter.com/DECtecInfo
11:03 a.m.
On 8 Sep 2015, at 09:44, Mark Benson <md.benson at gmail.com> wrote:
My only other thought is maybe a DEC-based database
like DATATRIEVE
might have a TCP/IP connection I might be able to poke with a modern
language to extract data from? I am not sure though. I only work in a
very narrow field myself with modern systems so I'm not an expert, I
just like the idea of attacking this, but I might be overthinking it a
bit ;)
I think that's a cool idea - I wouldn't want to be the one implementing it though
:)
sampsa
3:08 p.m.
New subject: Forcing a DS10 back to graphics SRM console
Is there any way to force a DS10 back to using the VGA+PS/2 graphics console instead of
serial, without having access to the serial port (the COM1 port appears to be broken)..
Sampsa
3:13 p.m.
New subject: Forcing a DS10 back to graphics SRM console
Try to stop bootstrap process using HALT button, and then try to press `enter' on ps/2
keyboard multiple times.
I think I could access graphics console this way even if serial console is in use...
On 08-Sep-2015 19:08, Sampsa Laine wrote:
Is there any way to force a DS10 back to using the
VGA+PS/2 graphics console instead of serial, without having access to the serial port (the
COM1 port appears to be broken)..
Sampsa
4:52 p.m.
I need a DATATRIEVE expert... any volunteers? :)
Aside from that, MediaWiki might be the best idea for storage (even if
I'm not that keen on it) as it's easy to host and the front-end is
relatively platform agnostic.
On Tue, Sep 8, 2015 at 10:03 AM, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Sep 2015, at 09:44, Mark Benson <md.benson at gmail.com> wrote:
My only other thought is maybe a DEC-based
database like DATATRIEVE
might have a TCP/IP connection I might be able to poke with a modern
language to extract data from? I am not sure though. I only work in a
very narrow field myself with modern systems so I'm not an expert, I
just like the idea of attacking this, but I might be overthinking it a
bit ;)
I think that's a cool idea - I wouldn't want to be the one implementing it though
:)
sampsa
4:56 p.m.
On 8 Sep 2015, at 15:52, Mark Benson <md.benson at gmail.com> wrote:
I need a DATATRIEVE expert... any volunteers? :)
Aside from that, MediaWiki might be the best idea for storage (even if
I'm not that keen on it) as it's easy to host and the front-end is
relatively platform agnostic.
My idea was to keep the "sources" in VMS HLP format and write some scripts to
convert them to whatever we need (including MediaWiki markup that I then automatically
upload).
This way people can access the information through various sources (Plain text files over
FAL, MediaWiki, VMS HELP, JSON for further processing etc).
Basically you describe the output format to me and I write the scripts to produce them -
the source file is copied across HECnet to CHIMPY which produces the various outputs,
updates the Wiki and possibly even notifies interested parties of updates made.
Sound like a plan?
5:04 p.m.
Yes. Lets do that for now.
I will throw a MediaWiki up on DECtec.info (it had one before but it
blew up and caused problems, but it was very neglected) so we can try
hurling parsed files at in MW format.
--
Mark
On Tue, Sep 8, 2015 at 3:56 PM, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Sep 2015, at 15:52, Mark Benson <md.benson at gmail.com> wrote:
I need a DATATRIEVE expert... any volunteers? :)
Aside from that, MediaWiki might be the best idea for storage (even if
I'm not that keen on it) as it's easy to host and the front-end is
relatively platform agnostic.
My idea was to keep the "sources" in VMS HLP format and write some scripts to
convert them to whatever we need (including MediaWiki markup that I then automatically
upload).
This way people can access the information through various sources (Plain text files over
FAL, MediaWiki, VMS HELP, JSON for further processing etc).
Basically you describe the output format to me and I write the scripts to produce them -
the source file is copied across HECnet to CHIMPY which produces the various outputs,
updates the Wiki and possibly even notifies interested parties of updates made.
Sound like a plan?
5:06 p.m.
On 2015-09-08 16:56, Sampsa Laine wrote:
On 8 Sep 2015, at 15:52, Mark Benson <md.benson at gmail.com> wrote:
Not that I want to discourage you guys, but it is not that simple.
For example, the VMS help files actually looks pretty much the same in
format as the RSX help files. However, where VMS have a rather
interactive help program, that will figure out the subtopics, list them,
and prompt you, the RSX help program does nothing like this. So, instead
each help topic itself needs to list what subtopics exist, in the help
text. So, in essence, while the information is there, you need the
resulting output content to be somewhat different.
Datatrieve is probably not what I'd use for this. This is a case of
wanting to have data in a format that identifies different types of
information, and relationship between them. But it's not really a
database as such. Datatrieve fits this usage pretty bad.
You could argument that something like HTML could work, just like XML,
or any other markup language.
But you need tools to generate output for different targets, which maybe
is the more complex part. Anyone going to write those? Else I think this
is not going anywhere.
You could, in essence, have a very simple source file format. Just
key,value pairs. That is the easy part. The generation of files is the
larger work.
Johnny
I need a DATATRIEVE expert... any volunteers? :)
Aside from that, MediaWiki might be the best idea for storage (even if
I'm not that keen on it) as it's easy to host and the front-end is
relatively platform agnostic.
My idea was to keep the "sources" in VMS HLP format and write some scripts to
convert them to whatever we need (including MediaWiki markup that I then automatically
upload).
This way people can access the information through various sources (Plain text files over
FAL, MediaWiki, VMS HELP, JSON for further processing etc).
Basically you describe the output format to me and I write the scripts to produce them -
the source file is copied across HECnet to CHIMPY which produces the various outputs,
updates the Wiki and possibly even notifies interested parties of updates made.
Sound like a plan?
5:53 p.m.
On 8 Sep 2015, at 16:06, Johnny Billquist <bqt at softjar.se> wrote:
Not that I want to discourage you guys, but it is not that simple.
For example, the VMS help files actually looks pretty much the same in format as the RSX
help files. However, where VMS have a rather interactive help program, that will figure
out the subtopics, list them, and prompt you, the RSX help program does nothing like this.
So, instead each help topic itself needs to list what subtopics exist, in the help text.
So, in essence, while the information is there, you need the resulting output content to
be somewhat different.
I'd need to do this for generating the MediaWiki markup as well, my script will keep a
track of basically headings, subheadings, and the text under each of those, and export
them in the desired format.
It really is quite easy to do this in say Python.
Datatrieve is probably not what I'd use for this.
This is a case of wanting to have data in a format that identifies different types of
information, and relationship between them. But it's not really a database as such.
Datatrieve fits this usage pretty bad.
You could argument that something like HTML could work, just like XML, or any other
markup language.
But you need tools to generate output for different targets, which maybe is the more
complex part. Anyone going to write those? Else I think this is not going anywhere.
You could, in essence, have a very simple source file format. Just key,value pairs. That
is the easy part. The generation of files is the larger work.
Johnny
10:53 a.m.
On 08/09/15 08:34, Mark Benson wrote:
On 08/09/2015 00:57, Sampsa Laine wrote:
json is the friendlier standards based alternative to XML.
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure
and files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and
also potentially makes the data structure less flexible for future
applications, but it is easier to host and transport. Kind of. But
please, no XML. It makes my ears bleed.
I'd love to do a Python/Django/PostgreSQL project with a set of output
scripts but I have no Django-friendly hosting that could be reliably
internet-facing available (only LAMP and frankly I'm starting to
dislike PHP more and more). A
I tried goofing with MediaWiki a while back but found it to be... well
not to my taste. It's a useful tool but it's not the right one for
this IMHO, I think outputting Wiki data to files for various OSs might
be a bit of a bear.
My favourite wiki is Confluence by Atlassian. It's a commercial product
but only $10 for a license (which goes to charity) and it just bloody works!
Mark.
10:58 a.m.
On 8 Sep 2015, at 09:53, Mark Wickens <mark at wickensonline.co.uk> wrote:
I'm actually OK with MediaWiki, producing their markup from a VMS .HLP file would be
trivial and then just a quick HTML POST to update each entry.
Let's see how many people can actually be bothered to write up an entry for their
systems before developing anything more complex than a VMS HELP converter...
sampsa
On 08/09/15 08:34, Mark Benson wrote:
But these are largely text files with just simple headings, so not sure we need anything
more complex than what goes into the VMS HELP system.
On 08/09/2015 00:57, Sampsa Laine wrote:
json is the friendlier standards based alternative to XML.
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and also potentially
makes the data structure less flexible for future applications, but it is easier to host
and transport. Kind of. But please, no XML. It makes my ears bleed.
I'd love to do a Python/Django/PostgreSQL project with a set of output scripts but I
have no Django-friendly hosting that could be reliably internet-facing available (only
LAMP and frankly I'm starting to dislike PHP more and more). A
I tried goofing with MediaWiki a while back but found it to be... well not to my taste.
It's a useful tool but it's not the right one for this IMHO, I think outputting
Wiki data to files for various OSs might be a bit of a bear.
My favourite wiki is Confluence by Atlassian. It's a commercial product but
only $10 for a license (which goes to charity) and it just bloody works!
Mark.
11:01 a.m.
On 8 Sep 2015, at 09:58, Sampsa Laine <sampsa at mac.com> wrote:
On 8 Sep 2015, at 09:53, Mark Wickens <mark at wickensonline.co.uk> wrote:
Saying that, I'm happy to convert the .HLP files into JSON for anyone who wants that
:)
On 08/09/15 08:34, Mark Benson wrote:
But these are largely text files with just simple headings, so not sure we need anything
more complex than what goes into the VMS HELP system.
On 08/09/2015 00:57, Sampsa Laine wrote:
json is the friendlier standards based alternative to XML.
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and also potentially
makes the data structure less flexible for future applications, but it is easier to host
and transport. Kind of. But please, no XML. It makes my ears bleed.
10:54 a.m.
I was thinking that one of the outputs of the flat files would be a feed that updates a
Wiki so you can easily search it..
Then .HLP files for VMS and other systems.
sampsa
On 8 Sep 2015, at 08:34, Mark Benson <md.benson at gmail.com> wrote:
On 08/09/2015 00:57, Sampsa Laine wrote:
Yeah, that should be doable.
Doesn't even need to be a database, just an agreed markup structure and files..
Then just convert them to whatever format you want.
Using flat files makes it less easy to search and query the data, and also potentially
makes the data structure less flexible for future applications, but it is easier to host
and transport. Kind of. But please, no XML. It makes my ears bleed.
I'd love to do a Python/Django/PostgreSQL project with a set of output scripts but I
have no Django-friendly hosting that could be reliably internet-facing available (only
LAMP and frankly I'm starting to dislike PHP more and more). A
I tried goofing with MediaWiki a while back but found it to be... well not to my taste.
It's a useful tool but it's not the right one for this IMHO, I think outputting
Wiki data to files for various OSs might be a bit of a bear.
--
Mark @ DECtec.info
twitter.com/DECtecInfo
3363
days inactive
3364
days old
20 comments
6 participants
participants (6)
-
bqt＠softjar.se -
form＠pdp-11.org.ru -
mark＠wickensonline.co.uk -
mcguire＠neurotica.com -
md.benson＠gmail.com -
sampsa＠mac.com