- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Coordinating the Vms porting efforts
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-26-2007 08:49 PM
тАО09-26-2007 08:49 PM
Coordinating the Vms porting efforts
I see regularly various freeware ported to Vms a second time by another person.
I think this is a pity, as there is a real need to have some software ported urgently.
Some years ago, Mysql was the important piece missing on Vms.
It is now available.
In your opinion, what is the most urgent freeware to port ?
I think some SAP-light may be useful (Baan, Bpcs...), when I see more and more companies leaving Vms because they go for SAP or any other ERP.
While there are many interesting languages to port, having a good language is not enough: you need to be able to read a Vms indexed file, to access an Oracle or Rdb database, use all the Vms system services...
We need more than printing Hello World :-)
So Haskell, Erlang, Ocaml, LUA, Lisaac may wait a little.
Several Wiki and CMS (content management system) are available, so this is not at the top at the list IMHO.
What do you put at the top of the list ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 05:10 AM
тАО09-27-2007 05:10 AM
Re: Coordinating the Vms porting efforts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 05:20 AM
тАО09-27-2007 05:20 AM
Re: Coordinating the Vms porting efforts
I think there are few people porting free software to Vms, so such thing should be avoided.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 08:03 AM
тАО09-27-2007 08:03 AM
Re: Coordinating the Vms porting efforts
No future Freeware distro is known to me.
Contact me off-line and I'll send along the information on who was thinking about this project. I'd rather not post the names here.
I know of only a few folks actively porting open source wares over to OpenVMS.
There are certainly larger porting efforts available for consideration, whether you look at a business practices environment (SAP, et al) or at PostgreSQL or the Ingres community release databases.
That written, it is often easier to use the existing tool ports -- or existing and supported packages -- on the particular platforms that have ports or packages. Or for folks with specific requirements and/or particularly for larger-scale packages, to simply pay for a port.
What package(s) are appropriate or are needed can and does vary widely, and whether or not incorporating support for native OpenVMS features and APIs such as indexed files is considered appropriate also varies. Widely.
And empirical evidence shows duplication of effort is an inherent feature of open source and open source porting -- the definition of "best" is always highly localized.
Contact me offline and I'll get you in touch with the folks that were here ruminating most recently.
Stephen Hoffman
HoffmanLabs.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 04:26 PM
тАО09-27-2007 04:26 PM
Re: Coordinating the Vms porting efforts
> like bzip2 ported, when it was already
> available.
> the definition of "best" is always highly
> localized.
Exactly. I like my bzip2 better, naturally.
On the bright side, the more people who do a
job, the better the chance that one of them
will get it right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 07:08 PM
тАО09-27-2007 07:08 PM
Re: Coordinating the Vms porting efforts
Probably I was the first to port the stuff. But when I got aware of Steven's port, I recognized his work was better and changed the links on my web-page.
Recently I cam across Alexey Chupahin's port He added some good idea's but was nor aware of Steven's port. So I urged him to look at it and merge the two versions to get a better one. (I'm not sure what the status is).
IMHO : the more people work on VMS-porting the better. But avoid inventing the wheel many times. So merge good ports into one version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-27-2007 07:13 PM
тАО09-27-2007 07:13 PM
Re: Coordinating the Vms porting efforts
However, in the case of bzip2 the author of bzip2 was not very cooperative (some 10 years ago).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2007 02:34 AM
тАО09-28-2007 02:34 AM
Re: Coordinating the Vms porting efforts
> bzip2 was not very cooperative (some 10
> years ago).
That was my experience in 2006-2006, too, but
he did fix a problem I reported in the UNIX
installation procedure.
The new wget maintainer has expressed at
least a weak interest in adding some
VMS-related changes. I've been trying for
years to figure out which release is that
"next" release, where all the good stuff will
happen.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2007 07:55 AM
тАО09-28-2007 07:55 AM
Re: Coordinating the Vms porting efforts
Some of the typical dos and don'ts when participating in open source projects would be:
Don't view porting as a one-way, one-time effort: get your changes into the authoritative repository and use whatever tact, diplomacy, and technical prowess you have at your disposal to make that happen and keep them up-to-date.
Do submit changes against the latest development snapshot, not the last stable release.
Don't make changes that will work only on VMS unless it's really necessary (such as providing VMS-only functionality).
Do make your VMS-specific changes in a way that minimizes the cost of maintaining a separate port. For example, take advantage of existing build infrastructure if possible.
Don't make the mainline code a jungle of "#ifdef __VMS" statements. Use OO-type overrides, macros, LIB$INITIALIZ sections, and/or separate modules and procedures to abstract out platform differences where possible.
Do make changes that upgrade the code to comply with some published standard, such as ANSI C, the Open Group Single Unix Spec, or some relevant RFC. There are times when standards compliance makes the portability problem go away.
Don't make changes that break functionality on other platforms -- test everywhere (or at least on one non-VMS platform) before submitting.
Do submit changes as GNU uniified diffs, not as VMS DIFFERENCES output (though this varies by project).
Don't override missing CRTL functions in a way that will break if a new CRTL begins to provide them. Either do your own prefixing or do a configure-time test for the presence of the functions and define macros accordingly.
Do port, support, and run any test suite available with the package when at all possible.
Well, this could go on for pages, but it's a start.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-28-2007 10:57 PM
тАО09-28-2007 10:57 PM
Re: Coordinating the Vms porting efforts
Purely Personal Opinion