A Customer's Request For Open Source Software

A Customer's Request For Open Source Software

[Marin David Condic]

Someone pointed me at the foloowing article:

http://news.com.com/2008-1082_3-5065859.html?tag=lh

Its an interesting conversation with the CEO of Ernie Ball - the guitar 
string manufacturer. Apparently they totally dumped Micro$oft in favor 
of open source software after getting sued for license infringements.

The interesting part for Ada is that the CEO is identifying some major 
holes in the "Open Source" world that he thinks need to be filled. It 
would be wise to listen to a successful business customer who might pick 
up on something written in Ada and start using it if it were available...

 From the article:

-------------------------------------------------------------------
  You've pretty much gotten by with off-the-shelf software. Was it tough 
to find everything you needed in the open-source world?
Yeah, there are some things that are tough to find, like payroll 
software. We found something, and it works well. But the developers need 
to start writing the real-world applications people need to run a 
business...engineering, art and design tools, that kind of 
stuff...They're all trying to build servers that already exist and do a 
whole bunch of stuff that's already out there...I think there's a lot of 
room to not just create an alternative to Microsoft but really take the 
next step and do something new.
----------------------------------------------------------------------

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

Food for Though indeed. :-)....he's not wrong...as in orientation
wise....there's plenty of people working on the servers/datbases/programming
languages etc etc....there's OpenOffice which is a good start for the
business world....but as far as payroll, inventory control, acounting,
receivables etc etc...aint much done in those fields as far as open source
goes....

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F44BC65.4020203@noplace.com...
> Someone pointed me at the foloowing article:
>
> http://news.com.com/2008-1082_3-5065859.html?tag=lh
>
> Its an interesting conversation with the CEO of Ernie Ball - the guitar
> string manufacturer. Apparently they totally dumped Micro$oft in favor
> of open source software after getting sued for license infringements.
>
> The interesting part for Ada is that the CEO is identifying some major
> holes in the "Open Source" world that he thinks need to be filled. It
> would be wise to listen to a successful business customer who might pick
> up on something written in Ada and start using it if it were available...
>
>  From the article:
>
> -------------------------------------------------------------------
>   You've pretty much gotten by with off-the-shelf software. Was it tough
> to find everything you needed in the open-source world?
> Yeah, there are some things that are tough to find, like payroll
> software. We found something, and it works well. But the developers need
> to start writing the real-world applications people need to run a
> business...engineering, art and design tools, that kind of
> stuff...They're all trying to build servers that already exist and do a
> whole bunch of stuff that's already out there...I think there's a lot of
> room to not just create an alternative to Microsoft but really take the
> next step and do something new.
> ----------------------------------------------------------------------
>
> MDC
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
>
>          --  Voltaire
> ======================================================================
>

Re: A Customer's Request For Open Source Software

[Marin David Condic]

That's why I suggested it as an opportunity to establish some major 
market sector as belonging to Ada. An open source accounting system - 
with add-ons for things like payroll, inventory, etc., would be a market 
niche that is not adequately addressed in the Linux/Open Source world. 
All you've got to do is figure out how to make it pay so its worth 
someone's time to do the development.

MDC

Stephane Richard wrote:
> Food for Though indeed. :-)....he's not wrong...as in orientation
> wise....there's plenty of people working on the servers/datbases/programming
> languages etc etc....there's OpenOffice which is a good start for the
> business world....but as far as payroll, inventory control, acounting,
> receivables etc etc...aint much done in those fields as far as open source
> goes....
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Place a paypal donation button on the page and strongly advice commercial users to donate as
much as they can afford. If there is commercial interest in such an application, which there
seems to be, I believe some companies would support it. Of course, this would require having a
somewhat usable application first.

//David Holm

On Fri, 22 Aug 2003 12:32:58 GMT
Marin David Condic <nobody@noplace.com> wrote:

> That's why I suggested it as an opportunity to establish some major 
> market sector as belonging to Ada. An open source accounting system - 
> with add-ons for things like payroll, inventory, etc., would be a market 
> niche that is not adequately addressed in the Linux/Open Source world. 
> All you've got to do is figure out how to make it pay so its worth 
> someone's time to do the development.
> 
> MDC
> 
> Stephane Richard wrote:
> > Food for Though indeed. :-)....he's not wrong...as in orientation
> > wise....there's plenty of people working on the servers/datbases/programming
> > languages etc etc....there's OpenOffice which is a good start for the
> > business world....but as far as payroll, inventory control, acounting,
> > receivables etc etc...aint much done in those fields as far as open source
> > goes....
> > 
> 
> 
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
> 
>          --  Voltaire
> ======================================================================
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Indeed it would...the corporate expects OpenSource to do it all first..sell
later?  :-)... Or so I've noticed in my career.  Maybe somekidn of
ransomware is in order as far as comemrcialware goes?


-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"David Holm" <david@realityrift.com> wrote in message
news:20030822153839.5ec5c918.david@realityrift.com...

Re: A Customer's Request For Open Source Software

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

The problem is that when you are forced to pay for something you expect much more out of it than
you normally would. If it's an opensource development that is carried out in peoples free time
then you can not expect the same things to happen in the same timeframe as you would for a
commercial application.

//David Holm

On Fri, 22 Aug 2003 14:33:46 GMT
"Stephane Richard" <stephane.richard@verizon.net> wrote:

> Indeed it would...the corporate expects OpenSource to do it all first..sell
> later?  :-)... Or so I've noticed in my career.  Maybe somekidn of
> ransomware is in order as far as comemrcialware goes?
> 
> 
> -- 
> Stéphane Richard
> Senior Software and Technology Supervisor
> http://www.totalweb-inc.com
> For all your hosting and related needs
> "David Holm" <david@realityrift.com> wrote in message
> news:20030822153839.5ec5c918.david@realityrift.com...
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A Customer's Request For Open Source Software

[Marin David Condic]

Absolutely. Volunteer projects will move very slowly and will likely not 
be nearly as spiffy as something you can buy off the shelf in a 
shrink-wrap box. (Like Quicken or other commercial products) They are 
also far more likely to appear "organically grown" than "designed". All 
of which is an incentive to go use what you can purchase commercially 
rather than wait for some volunteer freeware to show up.

Or, one could imagine that there is a good commercial potential here and 
figure out if its worth doing as a business venture. It would 
potentially produce jobs programming in Ada and profits for the people 
who put in the sweat equity of developing the initial software. It would 
almost certainly get done sooner and with a more "professional" look if 
a team of for-profit minded developers were working on it.

MDC


David Holm wrote:
> The problem is that when you are forced to pay for something you expect much more out of it than
> you normally would. If it's an opensource development that is carried out in peoples free time
> then you can not expect the same things to happen in the same timeframe as you would for a
> commercial application.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Marin David Condic wrote:
> Absolutely. Volunteer projects will move very slowly and will likely not 
> be nearly as spiffy as something you can buy off the shelf in a 
> shrink-wrap box. (Like Quicken or other commercial products) They are 
> also far more likely to appear "organically grown" than "designed". All 
> of which is an incentive to go use what you can purchase commercially 
> rather than wait for some volunteer freeware to show up.

The notion that something that looks nice and shiny on the cover is a
better product is a foolish thought. Alas it is widespread. Remember
once in an expo an experiment was done. A new computer with normal
design was displayed (it was in the 80's so it wasn't so common as
today) and beside it an very elegant new computer cache design that
contained nothing inside was put next to it. The customers were mostly
all interested in the latter even if it didn't contain the computer.

Whether organically grown is a bad thing can be discussed. I have see
too many articles in the newspapers of big software projects that
failed and had to be scrapped because the design didn't fit with the
usage. Sure a good design is a good thing and it saves a lot of work,
but are you quite sure that the requirements won't change? In science
one design ones experiments, but one do redesign them after examining
the results to delve deeper into the problem. I would say one would need
both a good design and organic growth of the software.

But why would one necessarily think that the shrink-wrapped commercial
version is better designed? 

> Or, one could imagine that there is a good commercial potential here
> and figure out if its worth doing as a business venture. It would
> potentially produce jobs programming in Ada and profits for the people
> who put in the sweat equity of developing the initial software. It
> would almost certainly get done sooner and with a more "professional"
> look if a team of for-profit minded developers were working on it.

If you want to write open source software in the free time it must be
for either of two reasons:

   1) You are making the software for yourself, but don't mind sharing
      it with others.
      
   2) You are making the software with an intent to one day perhaps be
      able to make a professional version you can sell with a support
      license.

At any rate the project is your "baby" and you will need to care for it
to grow. If your work is to make a system you don't need to care so much
just get the job done so you earn your pay.


-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Chad R. Meiners]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbkji2n.2kg.randhol+abuse@kiuk0152.chembio.ntnu.no...
> The notion that something that looks nice and shiny on the cover is a
> better product is a foolish thought.

I think Marin was saying that products should be both shiney and useful ;-)
I think that we all can agree that a useful program becomes better with a
nicer interface; therefore, GNU business software could benifit nicely from
a group of people that would put time and effort into making the software
easy to use.

-CRM

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message
news:bidssm$12sr$1@msunews.cl.msu.edu...
>
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnbkji2n.2kg.randhol+abuse@kiuk0152.chembio.ntnu.no...
> > The notion that something that looks nice and shiny on the cover is a
> > better product is a foolish thought.
>
> I think Marin was saying that products should be both shiney and useful
;-)
> I think that we all can agree that a useful program becomes better with a
> nicer interface; therefore, GNU business software could benifit nicely
from
> a group of people that would put time and effort into making the software
> easy to use.
>
> -CRM
>
>
And to that, I have to agree.   A good user interface (in today's business
world) is just as important than good functionality.  Let's face it,
business users today just dont want to have to do Shift-Ctrl-Alt-F4 to get
something to print.  they wanna click the file menu, then print. Or they
want to push that little button with the Printer drawn on it.  It's been my
professional experiences.  Some hard core users like to have that complicate
key combo.

To me it's a question of balancing the two.  You can't give 600 features on
a screen because the screen gets cluttered beyond usability.  If you take
these 600 and split them into Tabs (which looks quite nice) then other users
will complain there's just too many steps to getting at the end.  so do you
cut 600 features down to 400?  Other users will complain that it lacks
features then. :-)...It's hard to balance the functional / usability ratio
but I think it can still be done....First of my example is exagerated, 600
features is a lot for a screen of any design. At that point you can usually
put part of that into somekind of preferences that can be setup during the
installation for example so they still have it, but dont havfe to bother
with it unless then want to change it permanently.

I give whatever I develop a good try, usually if I think a certain part
takes too many steps, or is just to harsh to read, too cluttered, chances
are the users will think so too.





-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Stephane Richard wrote:
> And to that, I have to agree.   A good user interface (in today's business
> world) is just as important than good functionality.  Let's face it,
> business users today just dont want to have to do Shift-Ctrl-Alt-F4 to get
> something to print.  they wanna click the file menu, then print. Or they
> want to push that little button with the Printer drawn on it.  It's been my
> professional experiences.  Some hard core users like to have that complicate
> key combo.

Well. Consider this. You have a nice shiny GUI and you have 200 new
student that should be registered in a database. You have gotten a file
of names and ids etc... So what do you do? Yes you print the file and
sit and click-i-click for a couple of days to get them all in. Wereas if
you had a non GUI interface you could easily script it to take 5 min.
What I'm saying is that a GUI is everything and it is certainly not the
best interface always.

As to the printing; you need both! You need both a shortcut and a
icon/menu. Because using the keyboard is much faster than reaching for
the mouse all the time. I mean consider making a program for editing
text without Ctrl-C, Ctrl-X, Ctrl-V or equivalent shortcuts and you get
my meaning.

> To me it's a question of balancing the two.  You can't give 600 features on
> a screen because the screen gets cluttered beyond usability.  If you take
> these 600 and split them into Tabs (which looks quite nice) then other users
> will complain there's just too many steps to getting at the end.  so do you
> cut 600 features down to 400?  Other users will complain that it lacks
> features then. :-)...It's hard to balance the functional / usability ratio
> but I think it can still be done....First of my example is exagerated, 600
> features is a lot for a screen of any design. At that point you can usually
> put part of that into somekind of preferences that can be setup during the
> installation for example so they still have it, but dont havfe to bother
> with it unless then want to change it permanently.

A really good GUI interface (I have seen some of these lately) should
have these choices:

      I'm a computer illiterate
      I'm a normal user
      I'm an expert user.

If you choose the first you get simple menus and a limit set of options
that are most useful. As you choose a higher level more options are
presented.

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Chad R. Meiners]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbkm9uv.29i.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Well. Consider this. You have a nice shiny GUI and you have 200 new
> student that should be registered in a database. You have gotten a file
> of names and ids etc... So what do you do? Yes you print the file and
> sit and click-i-click for a couple of days to get them all in. Wereas if
> you had a non GUI interface you could easily script it to take 5 min.
> What I'm saying is that a GUI is everything and it is certainly not the
> best interface always.

Agreed, you have an additional CLI tool for scripting purposes.

Re: A Customer's Request For Open Source Software

[Marin David Condic]

Yes, user interface is important. But also a lot of other usability 
factors. Many "Open Source" things out there might have some marvelous 
functionality but you have to download them, then all the pieces they 
rely on and maybe you have to compile them. Perhaps you then discover 
there are subtle differences in your system versus the author's system 
and you're trying to figure out what switch settings or environment 
variables you have to tweak, etc.

Whereas with a typical application bought from a commercial company, one 
expects to insert the disk, click on "Install", answer "Yes" to 
everything and see the app come up and work. It had better have either 
really easy to understand features on its face or it had better have 
really good documentation - or both. If it doesn't look good in these 
and other respects, the company will be out of business soon. Whereas 
your typical freebie download "Open Source" project can easily afford to 
say "If you don't like it, go pile sand! I'm a *volunteer* and you're 
getting it *free*."

That's basically what I meant about an "Open Source" project needing to 
meet up with certain quality expectations people will have in the 
business world. Not all Open Source projects are going to be a pile of 
defication and not all commercial products are going to be amazing 
wonders. But if one wants to make an Open Source product that is going 
to draw users away from shrink-wrapped packages from commercial vendors, 
one had better look at the market's expectations and what the 
competition is doing *right* in meeting with them.

Commercial software users are not "geeks". They don't find great 
pleasure in tinkering with an app or marveling at how wonderfully it was 
constructed internally. They want to take it out of the box and use it 
to get a job done. That's what "Open Source" has to deal with if it 
wants to overcome Microsoft's market dominance.


MDC


Stephane Richard wrote:
> 
> And to that, I have to agree.   A good user interface (in today's business
> world) is just as important than good functionality.  Let's face it,
> business users today just dont want to have to do Shift-Ctrl-Alt-F4 to get
> something to print.  they wanna click the file menu, then print. Or they
> want to push that little button with the Printer drawn on it.  It's been my
> professional experiences.  Some hard core users like to have that complicate
> key combo.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Wes Groleau]

Marin David Condic wrote:
> factors. Many "Open Source" things out there might have some marvelous 
> functionality but you have to download them, then all the pieces they 
> rely on and maybe you have to compile them. Perhaps you then discover 
> there are subtle differences in your system versus the author's system 

Like 'c2ada'

Installation:
1. Get Python.  ______ is the URI it was at when we stopped supporting this.
2. etc.
:-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes

Re: A Customer's Request For Open Source Software

[Dave Head]

This is correct.  Anything that doesn't have a transfer of money or other
consideration has no incentive for the provider to be concerned with the
consumer's satisfaction.

Its like socialized medicine.  Anyone can get a taste of that if they join the
military.  I was about as sick as I'd ever been, fever, etc. and went to the
doctor in Ft. Monmouth, NJ.  Got aspirin, nothing else.  Now, it may have been
a virus and there was no real treatment for it, but they didn't bother to
explain that.  That's the real difference.  Like all other "free" services, or
goods, that was not a concern of theirs.

Dave Head


On Tue, 26 Aug 2003 12:51:44 GMT, Marin David Condic <nobody@noplace.com>
wrote:

>Yes, user interface is important. But also a lot of other usability 
>factors. Many "Open Source" things out there might have some marvelous 
>functionality but you have to download them, then all the pieces they 
>rely on and maybe you have to compile them. Perhaps you then discover 
>there are subtle differences in your system versus the author's system 
>and you're trying to figure out what switch settings or environment 
>variables you have to tweak, etc.
>
>Whereas with a typical application bought from a commercial company, one 
>expects to insert the disk, click on "Install", answer "Yes" to 
>everything and see the app come up and work. It had better have either 
>really easy to understand features on its face or it had better have 
>really good documentation - or both. If it doesn't look good in these 
>and other respects, the company will be out of business soon. Whereas 
>your typical freebie download "Open Source" project can easily afford to 
>say "If you don't like it, go pile sand! I'm a *volunteer* and you're 
>getting it *free*."
>
>That's basically what I meant about an "Open Source" project needing to 
>meet up with certain quality expectations people will have in the 
>business world. Not all Open Source projects are going to be a pile of 
>defication and not all commercial products are going to be amazing 
>wonders. But if one wants to make an Open Source product that is going 
>to draw users away from shrink-wrapped packages from commercial vendors, 
>one had better look at the market's expectations and what the 
>competition is doing *right* in meeting with them.
>
>Commercial software users are not "geeks". They don't find great 
>pleasure in tinkering with an app or marveling at how wonderfully it was 
>constructed internally. They want to take it out of the box and use it 
>to get a job done. That's what "Open Source" has to deal with if it 
>wants to overcome Microsoft's market dominance.
>
>
>MDC
>
>
>Stephane Richard wrote:
>> 
>> And to that, I have to agree.   A good user interface (in today's business
>> world) is just as important than good functionality.  Let's face it,
>> business users today just dont want to have to do Shift-Ctrl-Alt-F4 to get
>> something to print.  they wanna click the file menu, then print. Or they
>> want to push that little button with the Printer drawn on it.  It's been my
>> professional experiences.  Some hard core users like to have that complicate
>> key combo.

Re: A Customer's Request For Open Source Software

[Marin David Condic]

Keep in mind that an "Open Source" project can still involve the 
transfer of money. (Depending on what your definition of "Open Source" 
is). I see no reason one couldn't write a business application and sell 
it to a customer along with the source code and give them the right to 
install it on any machines they own. That's still "Open Source" - they 
got the source code and they can modify it if they like - or hire 
someone to do that.

Its just that if the project is not commercialized in some manner, 
people will have very little incentive to want to make it a better, more 
customer-satisfying tool. Exceptions exist, but usually they're just 
being driven by a different "customer". (e.g. I build some tool for 
internal use within my business and I release it to the world because I 
don't want to commercialize it myself, but I still keep making upgrades 
because of my internal users.)

MDC

Dave Head wrote:
> This is correct.  Anything that doesn't have a transfer of money or other
> consideration has no incentive for the provider to be concerned with the
> consumer's satisfaction.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

[off-topic] military medicine

[Wes Groleau]

> Its like socialized medicine.  Anyone can get a taste of that if they join the
> military.  I was about as sick as I'd ever been, fever, etc. and went to the
> doctor in Ft. Monmouth, NJ.  Got aspirin, nothing else.  Now, it may have been

I was scheduled for a Naval Reserve weekend, but I was very ill.
"You can't call in sick, you have to come to the reserve center
and let the Corpsman say you're sick"

Wait in misery thirty minutes for the corpsman to say "Go to the
V.A. hospital to see a doc"

Drive there, am told "Wait right here for the doc."

At least there was a TV there, and a football game was
just beginning.

At half-time, somebody came in, asked me a few questions,
and left.

When the game ended, someone else came in, gave me a note
saying I should stay in bed, and left.

Five hours out of bed and out of the house,
in order to be told not to get out of bed.

And interesting timing with regard to the game.  :-)

-- 
Wes Groleau
Genealogical Lookups:  http://groleau.freeshell.org/ref/lookups.html

Re: A Customer's Request For Open Source Software

[Jan Kroken]

Preben Randhol <randhol+abuse@pvv.org> writes:

> If you want to write open source software in the free time it must be
> for either of two reasons:
> 
>    1) You are making the software for yourself, but don't mind sharing
>       it with others.
>       
>    2) You are making the software with an intent to one day perhaps be
>       able to make a professional version you can sell with a support
>       license.

Is it ok if I use this as an example of the dangers of strong typing? :)

-- 
Jan Kroken

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Jan Kroken wrote:
> Preben Randhol <randhol+abuse@pvv.org> writes:
> 
>> If you want to write open source software in the free time it must be
>> for either of two reasons:
>> 
>>    1) You are making the software for yourself, but don't mind sharing
>>       it with others.
>>
>>    2) You are making the software with an intent to one day perhaps be
>>       able to make a professional version you can sell with a support
>>       license.
> 
> Is it ok if I use this as an example of the dangers of strong typing? :)

If you explain what you mean first :-)

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Jan Kroken]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Jan Kroken wrote:
> > Preben Randhol <randhol+abuse@pvv.org> writes:
> > 
> >> If you want to write open source software in the free time it must be
> >> for either of two reasons:
> >> 
> >>    1) You are making the software for yourself, but don't mind sharing
> >>       it with others.
> >>
> >>    2) You are making the software with an intent to one day perhaps be
> >>       able to make a professional version you can sell with a support
> >>       license.
> > 
> > Is it ok if I use this as an example of the dangers of strong typing? :)
> 
> If you explain what you mean first :-)

Sorry about the delayed answer.

I just saw the similarity between organizing information in a uniform
group (a type) in strongly typed languages like Ada, and normalizing
reasons for doing open source development in a distinct and discrete
group that would fit well in an Ada type. The danger I'm talking about
is that of viewing normalized information as a lossless or at least
basically correct representation of chaotic information. The phrase I
reacted the most on was "must be for either of two reasons".

When it comes to motivation for developing open source software, there
is a thorough study available at

http://www.infonomics.nl/FLOSS/report/Final4.htm

I'm unsure to what degree it is representable, since it was voluntary
and distributed through the community by the developers themself. It
also of course suffers from the normalization of the answers (and
probably the questions too). In addition, when the people themself
describe their motivation, the answer is probably going to be
distorted by pride, self-glorification and other human weaknesses.

-- 
Jan Kroken

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

In article <eRp1b.4$i%3.2@nwrdny02.gnilink.net>, "Stephane Richard" <stephane.richard@verizon.net> writes:
> Indeed it would...the corporate expects OpenSource to do it all first..sell
> later?  :-)... Or so I've noticed in my career.  Maybe somekidn of
> ransomware is in order as far as comemrcialware goes?
> 
> 
> -- 
> St�phane Richard
> Senior Software and Technology Supervisor
> http://www.totalweb-inc.com
> For all your hosting and related needs
> "David Holm" <david@realityrift.com> wrote in message
> news:20030822153839.5ec5c918.david@realityrift.com...

Indeed what would ?

Please post a small bit of context in responses.

Do not assume that everybody's newsreader is like yours.

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Sorry Larry,

As you've seen I've responded to David Holm's reply, and in his case, all
message I get from him are as attachement to the posting.  so there's no
contents that show when I hit reply.  if you would have responded in the
normal way (hitting "reply group" to the post) you wouldn't get any more
contents that what I have shown here.  :-)

FYI; Here's the quoted contents of that mews post.

"Place a paypal donation button on the page and strongly advice commercial
users to donate as
much as they can afford. If there is commercial interest in such an
application, which there
seems to be, I believe some companies would support it. Of course, this
would require having a
somewhat usable application first."

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:$ytOWWqDGf8M@eisner.encompasserve.org...
> In article <eRp1b.4$i%3.2@nwrdny02.gnilink.net>, "Stephane Richard"
<stephane.richard@verizon.net> writes:
> > Indeed it would...the corporate expects OpenSource to do it all
first..sell
> > later?  :-)... Or so I've noticed in my career.  Maybe somekidn of
> > ransomware is in order as far as comemrcialware goes?
> >
> >
> > -- 
> > St�phane Richard
> > Senior Software and Technology Supervisor
> > http://www.totalweb-inc.com
> > For all your hosting and related needs
> > "David Holm" <david@realityrift.com> wrote in message
> > news:20030822153839.5ec5c918.david@realityrift.com...
>
> Indeed what would ?
>
> Please post a small bit of context in responses.
>
> Do not assume that everybody's newsreader is like yours.

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <H7s1b.83$i%3.14@nwrdny02.gnilink.net>, "Stephane Richard" <stephane.richard@verizon.net> writes:

<top posting corrected>

> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:$ytOWWqDGf8M@eisner.encompasserve.org...
>> In article <eRp1b.4$i%3.2@nwrdny02.gnilink.net>, "Stephane Richard"
> <stephane.richard@verizon.net> writes:
>> > Indeed it would...the corporate expects OpenSource to do it all
> first..sell
>> > later?  :-)... Or so I've noticed in my career.  Maybe somekidn of
>> > ransomware is in order as far as comemrcialware goes?

>> Indeed what would ?
>>
>> Please post a small bit of context in responses.

<top posting corrected>

> Sorry Larry,
> 
> As you've seen I've responded to David Holm's reply, and in his case, all
> message I get from him are as attachement to the posting.  so there's no
> contents that show when I hit reply.  if you would have responded in the
> normal way (hitting "reply group" to the post) you wouldn't get any more
> contents that what I have shown here.  :-)

Certainly my Keyboard has no "reply group" key, and my terminal emulator
has no such function.  I have never heard of such a thing in ANUNEWS, my
browser :-)

>> Do not assume that everybody's newsreader is like yours.

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Stephane Richard wrote:
> Sorry Larry,
> 
> As you've seen I've responded to David Holm's reply, and in his case, all
> message I get from him are as attachement to the posting.  so there's no
> contents that show when I hit reply.  if you would have responded in the
> normal way (hitting "reply group" to the post) you wouldn't get any more
> contents that what I have shown here.  :-)

First just want to say I'm not lashing out at you, but I'm very
frustrated after getting a lot of Sobig.F virus mails from people who
use M$ Outlook. Why cannot people take the problem at the root and
remove this piece of shrink-wrapped shiny commercial cowpat software
from their system.

Please get a propper USERNET client and not this Virus-infested Outlook
shit. On USENET you don't send attachments nor HTML.

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Marin David Condic]

I'd want to see some evidence that putting a paypal button on a website 
would generate sufficient revenue to make a project sustain itself.

Possibly a better way is to publish documentation and sell that as an 
extra. Or provide the "basic" package free of charge but charge a fee to 
get the "extras". Somehow, some way, you've got to find a way to 
generate some revenue or the thing would languish.

MDC



David Holm wrote:
> Place a paypal donation button on the page and strongly advice commercial users to donate as
> much as they can afford. If there is commercial interest in such an application, which there
> seems to be, I believe some companies would support it. Of course, this would require having a
> somewhat usable application first.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Adrian Hoe]

Marin David Condic wrote:
> That's why I suggested it as an opportunity to establish some major 
> market sector as belonging to Ada. An open source accounting system - 
> with add-ons for things like payroll, inventory, etc., would be a market 
> niche that is not adequately addressed in the Linux/Open Source world. 
> All you've got to do is figure out how to make it pay so its worth 
> someone's time to do the development.
> 
> MDC
> 
> Stephane Richard wrote:
> 
>> Food for Though indeed. :-)....he's not wrong...as in orientation
>> wise....there's plenty of people working on the 
>> servers/datbases/programming
>> languages etc etc....there's OpenOffice which is a good start for the
>> business world....but as far as payroll, inventory control, acounting,
>> receivables etc etc...aint much done in those fields as far as open 
>> source
>> goes....
>>
> 
> 


Yes, market niche it is. But take accounting software for instance, it 
will require ten (10) years to be track proven (or at least 5 years). 
Gnucash has not been track proven yet, but my company (and all 
subsidiaries) are using it. Quite a nice software but it still cannot 
handle some of our financial requirement.

If we talk about payroll, situation becomes worst. Why? Every country 
has different employment policy. Even in every states of US. And to make 
things worst, employment policy changes over years if not months.

These I call them "Business Software". Because they need to evolve with 
businesses.

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Agreed, I've worked on a payroll program (for canada) (in visual basic 1.0
professional for DOS no less I can still feel the pain...hehe) and every
year rates changes, salary margins change, everything changes...and then
when income tax arrives everything seems to change again :-)....it's not
impossible to do, but it is an evolving software....however since payroll is
usually targetted at accoutants, they'll know what to do with it, all we
need is to provide a way for them to update these evolutionary
changes....maybe a grid of salary margins to tax rates is all they need
since they are usually displayed as a table on the official forms.  then
anyone can follow the dotted lines so to speak...and enter margins and rates
the same way...Obviously, these rates/margins changes need to be saved for
future reference and calculations...

But that's one margin...I assume GNUCash is a opensource version of a POS
software?  (point of sale) with integrated accounting?   (or should I shut
up rigth now and google on it first so it looks like I know what I'm
saying?) :-)...


-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f503d49$1_2@news.tm.net.my...
> Marin David Condic wrote:
> > That's why I suggested it as an opportunity to establish some major
> > market sector as belonging to Ada. An open source accounting system -
> > with add-ons for things like payroll, inventory, etc., would be a market
> > niche that is not adequately addressed in the Linux/Open Source world.
> > All you've got to do is figure out how to make it pay so its worth
> > someone's time to do the development.
> >
> > MDC
> >
> > Stephane Richard wrote:
> >
> >> Food for Though indeed. :-)....he's not wrong...as in orientation
> >> wise....there's plenty of people working on the
> >> servers/datbases/programming
> >> languages etc etc....there's OpenOffice which is a good start for the
> >> business world....but as far as payroll, inventory control, acounting,
> >> receivables etc etc...aint much done in those fields as far as open
> >> source
> >> goes....
> >>
> >
> >
>
>
> Yes, market niche it is. But take accounting software for instance, it
> will require ten (10) years to be track proven (or at least 5 years).
> Gnucash has not been track proven yet, but my company (and all
> subsidiaries) are using it. Quite a nice software but it still cannot
> handle some of our financial requirement.
>
> If we talk about payroll, situation becomes worst. Why? Every country
> has different employment policy. Even in every states of US. And to make
> things worst, employment policy changes over years if not months.
>
> These I call them "Business Software". Because they need to evolve with
> businesses.
>

Re: A Customer's Request For Open Source Software

[Christopher Browne]

Quoth Dennis Lee Bieber <wlfraed@ix.netcom.com>:
> Stephane Richard fed this fish to the penguins on Saturday 30 August 
> 2003 04:09 am:
>
>>
>> But that's one margin...I assume GNUCash is a opensource version of a
>> POS
>> software?  (point of sale) with integrated accounting?   (or should I
>> shut up rigth now and google on it first so it looks like I know what
>> I'm saying?) :-)...
>>
>         Wrong end of the system... GNUCash is closer to Quicken (I
> presume you are familiar with that)[though I don't know if GNUCash
> fits Quicken Standard, Deluxe, Home Business... I'm sure it is not
> attempting to fill the role of QuickBooks, which is more of a full
> business/payroll application]

The confusion is understandable, as there was, at one point, a company
building software to do POS and integrate that with GnuCash.  Two or
three of the GnuCash "core developers" went into that project.  

Not too surprisingly, in retrospect, not much emerged, and the
business enterprise was discontinued.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://cbbrowne.com/info/spiritual.html
Where do you want to go, toady?

Re: A Customer's Request For Open Source Software

[Adrian Hoe]

Christopher Browne wrote:

> 
> The confusion is understandable, as there was, at one point, a company
> building software to do POS and integrate that with GnuCash.  Two or
> three of the GnuCash "core developers" went into that project.  
> 
> Not too surprisingly, in retrospect, not much emerged, and the
> business enterprise was discontinued.


Business software is the most chanllenging software development if 
compare to system software. By the time you finish off your development, 
the business rules may have already evolved and you have to catch up 
with that. The life cycle goes on and on.

Believe me, your nightmare will not end. I come from business software 
domain.

Although providing a way to allow users to update the evolutionary 
changes (in Stephane's reply) provide a flexible functionality of the 
software, that renders the software to be complex and afterall, it is 
hard to predict what will come next.

Even the gigantic SAP application framework does not fit into all 
manufacturing environment. You will need alot of customization if you 
want it to work according to spec.

The world is full of chaos and no one can accurately predict the next 
happening. We can only design the software to handle evolutions that 
have already occured.

Understand the business software domain, you will no longer surprise 
that the enterprise has been discontinued.

Adrian Hoe

Re: A Customer's Request For Open Source Software

[Marin David Condic]

That's one of the reasons it might work well as a GPL licensed product. 
You constantly have a need for support in terms of new features, add-on 
capabilities, changing requirements, customization, etc. (Although 
Quicken seems to do well without providing custom software, eh?) I don't 
think it would take 10 years to catch on. It may take 10 years to mature 
as a volunteer effort, but if done with an eye towards 
commercialization, I doubt it would be that long. The rest is what you 
do to promote its use in different places.

MDC


Adrian Hoe wrote:
> 
> Yes, market niche it is. But take accounting software for instance, it 
> will require ten (10) years to be track proven (or at least 5 years). 
> Gnucash has not been track proven yet, but my company (and all 
> subsidiaries) are using it. Quite a nice software but it still cannot 
> handle some of our financial requirement.
> 
> If we talk about payroll, situation becomes worst. Why? Every country 
> has different employment policy. Even in every states of US. And to make 
> things worst, employment policy changes over years if not months.
> 
> These I call them "Business Software". Because they need to evolve with 
> businesses.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> Someone pointed me at the foloowing article:
> 
> http://news.com.com/2008-1082_3-5065859.html?tag=lh

Very interesting article.

> Its an interesting conversation with the CEO of Ernie Ball - the guitar 
> string manufacturer. Apparently they totally dumped Micro$oft in favor 
> of open source software after getting sued for license infringements.
> 
> The interesting part for Ada is that the CEO is identifying some major 
> holes in the "Open Source" world that he thinks need to be filled. It 
> would be wise to listen to a successful business customer who might pick 
> up on something written in Ada and start using it if it were available...
> 
>  From the article:
> 
> -------------------------------------------------------------------
>  You've pretty much gotten by with off-the-shelf software. Was it tough 
> to find everything you needed in the open-source world?
> Yeah, there are some things that are tough to find, like payroll 
> software. We found something, and it works well. But the developers need 
> to start writing the real-world applications people need to run a 
> business...engineering, art and design tools, that kind of 
> stuff...They're all trying to build servers that already exist and do a 
> whole bunch of stuff that's already out there...I think there's a lot of 
> room to not just create an alternative to Microsoft but really take the 
> next step and do something new.
> ----------------------------------------------------------------------
> 
> MDC

I would have to agree. It would seem that there is plenty of interest
in making server and kernel enhancements, but much less support in
getting actual applications done.

I am very interested in doing applications myself. The problem is that
I want to do them strictly in Ada95, for all the reasons we know and
love. So right now, my time is spent building up a series of important
language bindings, one of which is APQ.

*APQ PLUG*  ;-)

My first version of APQ only supported PostgreSQL in an object oriented,
ODBC-less API. I am now in the process of generalizing that API, and
adding a MySQL binding (the packages now split between APQ.PostgreSQL
and APQ.MySQL). With the new binding in place, you'll will only
need to tweak a few things in your application, and then be able to switch
from PostgreSQL to MySQL, or vice versa with a recompile. Alternatively,
you could access them both if you have a reason to. Go to the home page
below, and follow the "Current Development: APQ Version 2.0 " link for
other late breaking details, and issues.

I have one other major binding in the works, but it is a larger effort,
and will need more development. But this is another essential piece
for my application development.

The point of all of this is that the pieces for building applications
are slowly falling into place. I figure another year of my own effort
is required, before I can start to work on the "fun stuff". I think
there are signs of other pieces falling into place as well (I need
to check out the new GtkAda for example).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

And where can I look at this APQ ? :-)

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:ica1b.638$9a2.34465@news20.bellglobal.com...
> Marin David Condic wrote:
>
> > Someone pointed me at the foloowing article:
> >
> > http://news.com.com/2008-1082_3-5065859.html?tag=lh
>
> Very interesting article.
>
> > Its an interesting conversation with the CEO of Ernie Ball - the guitar
> > string manufacturer. Apparently they totally dumped Micro$oft in favor
> > of open source software after getting sued for license infringements.
> >
> > The interesting part for Ada is that the CEO is identifying some major
> > holes in the "Open Source" world that he thinks need to be filled. It
> > would be wise to listen to a successful business customer who might pick
> > up on something written in Ada and start using it if it were
available...
> >
> >  From the article:
> >
> > -------------------------------------------------------------------
> >  You've pretty much gotten by with off-the-shelf software. Was it tough
> > to find everything you needed in the open-source world?
> > Yeah, there are some things that are tough to find, like payroll
> > software. We found something, and it works well. But the developers need
> > to start writing the real-world applications people need to run a
> > business...engineering, art and design tools, that kind of
> > stuff...They're all trying to build servers that already exist and do a
> > whole bunch of stuff that's already out there...I think there's a lot of
> > room to not just create an alternative to Microsoft but really take the
> > next step and do something new.
> > ----------------------------------------------------------------------
> >
> > MDC
>
> I would have to agree. It would seem that there is plenty of interest
> in making server and kernel enhancements, but much less support in
> getting actual applications done.
>
> I am very interested in doing applications myself. The problem is that
> I want to do them strictly in Ada95, for all the reasons we know and
> love. So right now, my time is spent building up a series of important
> language bindings, one of which is APQ.
>
> *APQ PLUG*  ;-)
>
> My first version of APQ only supported PostgreSQL in an object oriented,
> ODBC-less API. I am now in the process of generalizing that API, and
> adding a MySQL binding (the packages now split between APQ.PostgreSQL
> and APQ.MySQL). With the new binding in place, you'll will only
> need to tweak a few things in your application, and then be able to switch
> from PostgreSQL to MySQL, or vice versa with a recompile. Alternatively,
> you could access them both if you have a reason to. Go to the home page
> below, and follow the "Current Development: APQ Version 2.0 " link for
> other late breaking details, and issues.
>
> I have one other major binding in the works, but it is a larger effort,
> and will need more development. But this is another essential piece
> for my application development.
>
> The point of all of this is that the pieces for building applications
> are slowly falling into place. I figure another year of my own effort
> is required, before I can start to work on the "fun stuff". I think
> there are signs of other pieces falling into place as well (I need
> to check out the new GtkAda for example).
>
> -- 
> Warren W. Gay VE3WWG
> http://home.cogeco.ca/~ve3wwg
>

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Stephane Richard wrote:

> And where can I look at this APQ ? :-)

   http://home.cogeco.ca/~ve3wwg/apq-1.93.tar.gz

is the 1.93 sources (PostgreSQL only). The PDF manual
has examples for almost every API function, and is
found at:

   http://home.cogeco.ca/~ve3wwg/apq_manual.pdf

The version 2.0 is not quite ready yet, but it is
the one that will support the common functions
between PostgreSQL and MySQL. There are a few
challenges in doing this, and so even version
2.0 will not yet include MySQL blob support for
example (it has full support for PostgreSQL
however). All other normal RDBMs functions will
be available, however.

APQ version 2.0 is pending more testing, and
updates to the "manual". If you have an urgent need to
try an alpha release, contact me privately
(at v e 3 w w g @ c o g e c o . c a)
and we can arrange something.

For news about the current developments in APQ,
use the link:

   http://home.cogeco.ca/~ve3wwg/software.html#APQ_RECENT

Here is the little vers 1.93 sales blurb from the
web page:

   The following are reasons you want to use APQ as
   your Ada95 binding to the PostgreSQL database:

  - It is a thick binding to the PostgreSQL database
    library libpq
  - Very simple to use
  - Uses Ada95 data types only (no C language interfaces)
  - Full BLOB support (PostgreSQL)
     - Open/Create blobs
     - Read/Write blobs using Ada95 stream I/O
     - Buffered BLOB I/O for greater performance
  - Generic functions and procedures allowing strongly
    typed programming
  - Very simple to install under Linux/FreeBSD:
  - Simple compile and install process
  - Only depends upon PostgreSQL libpq
  - No ODBC required!  Direct interface to database.
  - No GNADE infrastructure required (simple install).
  - Full support of NULL indicators (strongly typed)
  - Source code is almost all Ada95 (tested under GNAT-3.13p, FreeBSD)
  - 120+ page programmer's manual (almost all functions
    have an example code fragment)
  - ACL or GPL2 license (dual license - you choose)
  - win32 clients can be supported
  - Under active development

Here is a testamonial :

  "Thanks for 'apq'. The packages are easy to understand and use,
  and the doc's are helpful. With the help of 'apq' and 'PostgreSQL',
  I was able to build a largish, functional database in less
  than a week."

  Charles Darcy  <charlie@mullum.com.au>, November 30, 2002

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
> I am very interested in doing applications myself. The problem is that
> I want to do them strictly in Ada95, for all the reasons we know and
> love. So right now, my time is spent building up a series of important
> language bindings, one of which is APQ.

Thereby demonstrating exactly the problem that Ernie Ball was talking
about - programmers like to do programmer things, and that's what they'll
do unless they're paid to do otherwise.

Also, programmers know how to do programmer things, but not necessarily
other things. And the people who know how to do the other things aren't
necessarily programmers. That's why you don't get much free software in
non-programmer areas.

Re: A Customer's Request For Open Source Software

[Marin David Condic]

True - to a point. There are programmers with knowledge of other fields 
and with interests beyond the technical hacking. (Your humble narrator, 
for example, happens to know something of accounting and has an interest 
in developing such an application) But the critical point being that 
unless someone sees it as an opportunity to somehow get paid for doing 
the development work, a project like this doesn't get very far.

A lot of the server and network and other "geek tools" that are 
available under things like Linux as GPL'ed projects got developed 
because some geek in some company needed it for internal purposes and 
saw no point in not releasing it to the rest of the world. Something 
like an accounting package doesn't fit in the same category. Companies 
don't usually develop these on their own anymore - they only buy 
off-the-shelf packages. To get someone to develop an off-the-shelf 
accounting system in some version of Open Source they either have to do 
it as some sort of "labor of love" or they have to see some potential 
for financial payoff. The "labor of love" variety of projects don't 
always get real far.

MDC



Hyman Rosen wrote:
> 
> Thereby demonstrating exactly the problem that Ernie Ball was talking
> about - programmers like to do programmer things, and that's what they'll
> do unless they're paid to do otherwise.
> 
> Also, programmers know how to do programmer things, but not necessarily
> other things. And the people who know how to do the other things aren't
> necessarily programmers. That's why you don't get much free software in
> non-programmer areas.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> I am very interested in doing applications myself. The problem is that
>> I want to do them strictly in Ada95, for all the reasons we know and
>> love. So right now, my time is spent building up a series of important
>> language bindings, one of which is APQ.
> 
> Thereby demonstrating exactly the problem that Ernie Ball was talking
> about - programmers like to do programmer things, and that's what they'll
> do unless they're paid to do otherwise.

I can tell you with all honesty, that I _didn't want_ to
write this binding. But the closest thing to a PostgreSQL
binding that I could find, were packages/bindings that were
sadly lacking, and made Ada applications program at the
"C level".

GNADE is great for what it is, but IMHO it is a large
amount of infrastructure, which can be problematic to install.
Just try installing it on FreeBSD for example, or worse,
a FreeBSD Dec Alpha. I want users of my application to not have
to go through a help desk to "get there". A simpler solution
needed to exist.

So I was forced to scratch that itch.

So while you might see this as "unnecessary", I don't agree. I have
applications in mind, but I cannot get there until I have the
necessary building blocks that I need.

> Also, programmers know how to do programmer things, but not necessarily
> other things. And the people who know how to do the other things aren't
> necessarily programmers. That's why you don't get much free software in
> non-programmer areas.

There is some truth to this, but I can't agree with this
wholesale. Not many programmers do kernels and servers in
their day job. Most (probably non-Ada) programmers are doing
mundane things like the Accounting systems and such (perhaps
this is the problem ;-). So I don't buy the argument that the
know how is lacking, only that the desire to do this may be
lacking.

Certainly on the Ada front, there is much needed for general
purpose applications. Ada is quite suitable for embedded
applications, but the Annexes are hardly enough for commercial
use (once again, I repeat that you cannot even get the day
of the week from the Ada.Calendar package, for example).

So while it is easy to be critical, some of us are actually
contributing our time freely here, to help make a difference.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Marin David Condic]

Isn't there already a binding to these databases? GNADE? (I've 
downloaded it but have not had time to actually unpack it and look at 
what it does)

I agree that Ada needs a full-up development environment that ought to 
include things like a database and a GUI. The problem is that the pieces 
are there, but not collected in an integrated, coordinated way, nor are 
they considered "Standard" in some respect so that developers can count 
on the interfaces being portable.

MDC


Warren W. Gay VE3WWG wrote:
> 
> *APQ PLUG*  ;-)
> 
> My first version of APQ only supported PostgreSQL in an object oriented,
> ODBC-less API. I am now in the process of generalizing that API, and
> adding a MySQL binding (the packages now split between APQ.PostgreSQL
> and APQ.MySQL). With the new binding in place, you'll will only
> need to tweak a few things in your application, and then be able to switch
> from PostgreSQL to MySQL, or vice versa with a recompile. Alternatively,
> you could access them both if you have a reason to. Go to the home page
> below, and follow the "Current Development: APQ Version 2.0 " link for
> other late breaking details, and issues.
> 
> I have one other major binding in the works, but it is a larger effort,
> and will need more development. But this is another essential piece
> for my application development.
> 
> The point of all of this is that the pieces for building applications
> are slowly falling into place. I figure another year of my own effort
> is required, before I can start to work on the "fun stuff". I think
> there are signs of other pieces falling into place as well (I need
> to check out the new GtkAda for example).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Isn't there already a binding to these databases? GNADE? (I've 
> downloaded it but have not had time to actually unpack it and look at 
> what it does)
...
> MDC

For many people, GNADE is the right tool. For others it is not.
For example, I do not want the overhead/hassle of ODBC. GNADE also
is tailored for Embedded SQL, which is another approach (I don't
recall if it insists on ODBC, but it might). Finally, if you are
targeting software to people that don't have GNADE pre-installed,
GNADE is pretty large and can present many install related challenges.

I prefer to go the route of an object-oriented interface, that
requires a very light database infrastructure. You only need the
C library(ies) + 1 APQ binding to use database(s).

Hope that helps.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Warren W. Gay VE3WWG wrote:

> Marin David Condic wrote:
> 
>> Isn't there already a binding to these databases? GNADE? (I've 
>> downloaded it but have not had time to actually unpack it and look at 
>> what it does)
> 
> ....
> 
>> MDC
> 
> 
> For many people, GNADE is the right tool. For others it is not.
> For example, I do not want the overhead/hassle of ODBC. GNADE also
> is tailored for Embedded SQL, which is another approach (I don't
> recall if it insists on ODBC, but it might). Finally, if you are
> targeting software to people that don't have GNADE pre-installed,
> GNADE is pretty large and can present many install related challenges.

I forgot to mention that what soured me on it, was the difficulty
of getting it to compile and install on other non-Linux platforms
like FreeBSD (Intel & Alpha). This is an important factor to
consider when you want UNIX portable Ada code. I also must
support win32 (I don't know how GNADE does there).

> I prefer to go the route of an object-oriented interface, that
> requires a very light database infrastructure. You only need the
> C library(ies) + 1 APQ binding to use database(s).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Marin David Condic]

I believe it is supposed to - with MySQL. Like I said, I downloaded it 
but have not had the time to look at installing any of it - much less 
reading the documentation to see how it does its thing.

MDC


Warren W. Gay VE3WWG wrote:
> 
> I forgot to mention that what soured me on it, was the difficulty
> of getting it to compile and install on other non-Linux platforms
> like FreeBSD (Intel & Alpha). This is an important factor to
> consider when you want UNIX portable Ada code. I also must
> support win32 (I don't know how GNADE does there).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Brien]

> I also must
> support win32 (I don't know how GNADE does there).

I tried to get GNADE installed on win xp and then again in cygwin, but
I couldn't get it to work.

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> I would have to agree. It would seem that there is plenty of interest
> in making server and kernel enhancements, but much less support in
> getting actual applications done.

Oh yes. There are currently 362 different window manager projects listed
at freshmeat. I would say we could do with 10 max.

> I am very interested in doing applications myself. The problem is that
> I want to do them strictly in Ada95, for all the reasons we know and
> love. So right now, my time is spent building up a series of important
> language bindings, one of which is APQ.

Same here. Well at the moment I have had to halt any software
development as I'm very busy. But I'm also doing this. What I'm
currently designing and making is a library to contain useful Gtkada
composites, like Dialogs: About, Exceptions, Warning, Info, etc..., new
widgets and a simple Help system that can be integrated in the
applications for simple on the spot help and information. And I'm also
making a Program Template for GtkAda. The purpose of the latter is to be
able to make new GtkAda programs faster as you do not need to do all the
common functions/callbacks etc only that which is specific to your program.
Combined with the other library I described a lot of the work done to
make a nice GUI should be reduced and one would be able to reuse the
code. At least this is my hope :-)

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Preben Randhol wrote:

> Warren W. Gay VE3WWG wrote:
> 
>>I would have to agree. It would seem that there is plenty of interest
>>in making server and kernel enhancements, but much less support in
>>getting actual applications done.
> 
> Oh yes. There are currently 362 different window manager projects listed
> at freshmeat. I would say we could do with 10 max.
> 
>>I am very interested in doing applications myself. The problem is that
>>I want to do them strictly in Ada95, for all the reasons we know and
>>love. So right now, my time is spent building up a series of important
>>language bindings, one of which is APQ.
> 
> Same here. Well at the moment I have had to halt any software
> development as I'm very busy. But I'm also doing this. What I'm
> currently designing and making is a library to contain useful Gtkada
> composites, like Dialogs: About, Exceptions, Warning, Info, etc..., new
> widgets and a simple Help system that can be integrated in the
> applications for simple on the spot help and information. And I'm also
> making a Program Template for GtkAda. The purpose of the latter is to be
> able to make new GtkAda programs faster as you do not need to do all the
> common functions/callbacks etc only that which is specific to your program.
> Combined with the other library I described a lot of the work done to
> make a nice GUI should be reduced and one would be able to reuse the
> code. At least this is my hope :-)

Very good. Ada needs development resources. If enough people like
yourself contribute the necessary components, we can start to
play on a level playing field (application wise). For the moment,
it is still an up hill battle, but I think we're slowly winning.. ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> 
> Very good. Ada needs development resources. If enough people like
> yourself contribute the necessary components, we can start to
> play on a level playing field (application wise). For the moment,
> it is still an up hill battle, but I think we're slowly winning.. ;-)

Yes, we must labour like Sisyphus :-)


-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Preben Randhol wrote:
> Warren W. Gay VE3WWG wrote:
> 
>>Very good. Ada needs development resources. If enough people like
>>yourself contribute the necessary components, we can start to
>>play on a level playing field (application wise). For the moment,
>>it is still an up hill battle, but I think we're slowly winning.. ;-)
> 
> Yes, we must labour like Sisyphus :-)

I'm not so sure I like that comparison :-/  (see graphic below)

    http://stripe.colorado.edu/~morristo/sisyphus.html

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Warren W. Gay VE3WWG wrote:
> 
> I'm not so sure I like that comparison :-/  (see graphic below)

hehe :-)

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

The kind of applications mentioned in this article, payroll system, engineering, art and design
tools, all domain knowledge. For someone like me who rarely come into contact with those kinds
of systems it would be difficult for me to start such a project.
Projects such as mozilla and openoffice both come from companies which can afford to hire
someone with domain knowledge and to do studies on what is needed to produce this kind of
software.
I have never used a payroll system and I have only seen a professional engineering system once.
Where do you find people who know these kinds of software and who are willing to aid in
developing an opensource application? If you look for people on sourceforge.net you will only
find programmers and maybe some artists.

//David Holm

On Thu, 21 Aug 2003 12:35:12 GMT
Marin David Condic <nobody@noplace.com> wrote:

> Someone pointed me at the foloowing article:
> 
> http://news.com.com/2008-1082_3-5065859.html?tag=lh
> 
> Its an interesting conversation with the CEO of Ernie Ball - the guitar 
> string manufacturer. Apparently they totally dumped Micro$oft in favor 
> of open source software after getting sued for license infringements.
> 
> The interesting part for Ada is that the CEO is identifying some major 
> holes in the "Open Source" world that he thinks need to be filled. It 
> would be wise to listen to a successful business customer who might pick 
> up on something written in Ada and start using it if it were available...
> 
>  From the article:
> 
> -------------------------------------------------------------------
>   You've pretty much gotten by with off-the-shelf software. Was it tough 
> to find everything you needed in the open-source world?
> Yeah, there are some things that are tough to find, like payroll 
> software. We found something, and it works well. But the developers need 
> to start writing the real-world applications people need to run a 
> business...engineering, art and design tools, that kind of 
> stuff...They're all trying to build servers that already exist and do a 
> whole bunch of stuff that's already out there...I think there's a lot of 
> room to not just create an alternative to Microsoft but really take the 
> next step and do something new.
> ----------------------------------------------------------------------
> 
> MDC
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
> 
> Send Replies To: m c o n d i c @ a c m . o r g
> 
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
> 
>          --  Voltaire
> ======================================================================
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

Well I did a commercial Payroll system in my career...I know accounting,
inventory management, and just about everything in between, I've dont a lot
of industry specific application development.  and I'm thinking of doign an
OpenSource project :-)....that message on the group made me realize how much
it was lacking, but I agree, we need to replace such things as MYOB
Accounting or atleast have an equivalent of.  We need business management
software, stats and probabilities, trend analysis, financial advisory tools,
and everything else that can be used in a business.  so I'm game.  Also done
a Point of Sale commercial application which integrated accounting behind
the scene.

He is right, as much as we do need the people who are updating the kernel,
coming up with server apps, programming languages sure that's all good.  But
I think we equally need business quality solutions.  and that does
lack....think about it, a lot of databases are available for Linux, but what
applications make very good use of these databases?  if not by us, by
someone else, but that field does need to get covered.  In my book :-)...

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"David Holm" <david@realityrift.com> wrote in message
news:20030822005323.2ff66948.david@realityrift.com...

Re: A Customer's Request For Open Source Software

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

Another issue I see is that even though it would be a great idea to write this in Ada (I'm
thinking of stability here), there will be problems finding programmers who are able to work
on it. One way of making it easier for people to help the project might be to write the backend
in Ada with a module loader (dlopen/dlsym/dlclose would d othe trick). That way people can
contribute to the project without knowing Ada and the backend can still be kept solid. By using
some database system like berkley db for universal datastorage (by all modules) and implementing
a recovery system in the backend you should be able to have a solid system even though it will
be tainted by other languages.

//David Holm

On Thu, 21 Aug 2003 23:11:23 GMT
"Stephane Richard" <stephane.richard@verizon.net> wrote:

> Well I did a commercial Payroll system in my career...I know accounting,
> inventory management, and just about everything in between, I've dont a lot
> of industry specific application development.  and I'm thinking of doign an
> OpenSource project :-)....that message on the group made me realize how much
> it was lacking, but I agree, we need to replace such things as MYOB
> Accounting or atleast have an equivalent of.  We need business management
> software, stats and probabilities, trend analysis, financial advisory tools,
> and everything else that can be used in a business.  so I'm game.  Also done
> a Point of Sale commercial application which integrated accounting behind
> the scene.
> 
> He is right, as much as we do need the people who are updating the kernel,
> coming up with server apps, programming languages sure that's all good.  But
> I think we equally need business quality solutions.  and that does
> lack....think about it, a lot of databases are available for Linux, but what
> applications make very good use of these databases?  if not by us, by
> someone else, but that field does need to get covered.  In my book :-)...
> 
> -- 
> Stéphane Richard
> Senior Software and Technology Supervisor
> http://www.totalweb-inc.com
> For all your hosting and related needs
> "David Holm" <david@realityrift.com> wrote in message
> news:20030822005323.2ff66948.david@realityrift.com...
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

That is a good point David,

I think I'd still keep a preference to Ada since this is an Ada Project.
but if we can't find one then I'd go for the other languages.  It might
limit programmers, but it might also encourage them to learn and get into
ada.  (be flexible but still have a goal if you get what I'm saying
:-)...some parts may not have a choice about beign in another language.  but
others might :-)

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"David Holm" <david@realityrift.com> wrote in message
news:20030822020403.625ffbf5.david@realityrift.com...

Re: A Customer's Request For Open Source Software

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

But like you say, no matter what, the back end should definitaly be done in
Ada...:-)....no two ways about that

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"David Holm" <david@realityrift.com> wrote in message
news:20030822020403.625ffbf5.david@realityrift.com...

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Stephane Richard wrote:
 > But like you say, no matter what, the back end should definitaly be
 > done in Ada...:-)....no two ways about that

I strongly believe in using the right tool for the job.  For a lot of an
accounting system, that seems to be databases or spreadsheets.  But not 
necessarily.

Let's imagine creating a double-entry bookkeeping system in Ada.  You 
would have a generic that you instantiated to create a journal, and all 
the underlying complexity of transactions, journalling, and backup would 
be hidden from view.

Now you could implement the interface as a binding to say ODBC, but 
let's go a bit further.  If the system were to have guarenteed restore 
properties, the actual operation could be all done in memory.  (Say 
journalling and periodic backup to hard-disk, possibly on two physically 
separate disks.)

Now for 90+% of the actual use, the file system is not involved. 
(Completing a transaction forces a journal write.)  But let's go a bit 
further, the journalling can be to NVRAM, for example a Compact Flash 
card.  The effort to memory map such a card would not be too great, and 
now we have an accounting system that is hard-disk (and file-system) 
free in operation.

Why do that?  Because in the next few years, NVRAM is going to replace 
DRAM.  I can't tell you WHICH variety of NVRAM, AMD has a very nice 
polymer memory developed with Coatue, which AMD just bought. Motorola, 
IBM and others are working on MRAM.  Molecular electronic memory is 
unlikely to be the first to market, but may eventually be the winning 
entry in the race.

So an open source accounting system that gets away from dependencies on 
file systems and DBMSs will be very attractive down the road.  How to 
make money on the idea?  My leaning would be fairly simple.  Have a 
loosely organized group of developers and maintainers who retain certain 
rights.  (To sell the software or modified versions thereof, but free 
distribution and use would be permitted.)  This group could sell "shrink 
wrapped versions of the software, but I see that as only an alternative 
to selling books to users (with CD-ROMs in the back)  The group could 
also sell support both by individuals and through the group.

I've probably said enough for now...

--
                                                    Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac,
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Stephane Richard wrote:
>  > But like you say, no matter what, the back end should definitaly be
>  > done in Ada...:-)....no two ways about that
> 
> I strongly believe in using the right tool for the job.  For a lot of an
> accounting system, that seems to be databases or spreadsheets.  But not 
> necessarily.
...
> Now for 90+% of the actual use, the file system is not involved. 
> (Completing a transaction forces a journal write.)  But let's go a bit 
> further, the journalling can be to NVRAM, for example a Compact Flash 
> card.  The effort to memory map such a card would not be too great, and 
> now we have an accounting system that is hard-disk (and file-system) 
> free in operation.
> 
> Why do that?  Because in the next few years, NVRAM is going to replace 
> DRAM.  I can't tell you WHICH variety of NVRAM, AMD has a very nice 
> polymer memory developed with Coatue, which AMD just bought. Motorola, 
> IBM and others are working on MRAM.  Molecular electronic memory is 
> unlikely to be the first to market, but may eventually be the winning 
> entry in the race.
...
> I've probably said enough for now...
>                                                    Robert I. Eachus

The problem is that even when NVRAM (in whatever form) becomes
cheap and plentiful, addressing it still remains a problem. Assume
that molecular memory becomes cheap and you have Petabytes+ of memory
to waste with home movies and wave files.  Do you want to use 1024 bit
addresses to gain access to each byte of it?

For this reason, even if memory becomes plentiful (as one hopes it
will), it will still likely become "packaged" similar to the way
disk I/O occur today.  We just won't call it track and cylinder
any more, but we'll fetch bunches of memory by some block address
on an as needed basis.

So I don't see the role of a RDBMs changing much, as a result. Only
the amount that we have to manage, and the media that it is stored
upon.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

"Warren W. Gay wrote:

> The problem is that even when NVRAM (in whatever form) becomes
> cheap and plentiful, addressing it still remains a problem. Assume
> that molecular memory becomes cheap and you have Petabytes+ of memory
> to waste with home movies and wave files.  Do you want to use 1024 bit
> addresses to gain access to each byte of it?

Quite strange to see such a concern here, in Ada (not C or Assembler) forum.
Why do you need global addresses of these bytes? It is a compiler's job and
not a concern for an application programmer. Well, I hope you aren't imagining
Petabytes+ single data item, string or BLOB -:)

> For this reason, even if memory becomes plentiful (as one hopes it
> will), it will still likely become "packaged" similar to the way
> disk I/O occur today.  We just won't call it track and cylinder
> any more, but we'll fetch bunches of memory by some block address
> on an as needed basis.

No, there is no need to fetch bunches of memory - compiler will tell (perhaps
through OS directives) the memory chip siutable value of "base" and it's enough
- we went through that long ago. Naturally, that will be less efficient than
we currently associate with "real" (that is, non-virtual) memory - the switches
of the "base" will take time, but it will be more efficient than disk I/O.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> No, there is no need to fetch bunches of memory - compiler will tell (perhaps
> through OS directives) the memory chip suitable value of "base" and it's enough
> - we went through that long ago. Naturally, that will be less efficient than
> we currently associate with "real" (that is, non-virtual) memory - the switches
> of the "base" will take time, but it will be more efficient than disk I/O.

I guess this is not an Ada issue yet, but it will be. ;-)  Remember that 
when Ada first came out, there was no agreement that Integer should be 
32-bits, not 16-bits.  Of course, the only real effect on machines that 
support both 16-bit and 32-bit Integer types is on the size of Strings. 
  Within a few years, as expected, almost all implementations had moved 
to 32-bit Integers.  (Almost all, because of 24 and 36-bit 
implementations. ;-)

For a financial package is 4 Gigabytes of addressable memory enough? 
(Two Gigabytes currently under Windows.)  Some people are running up 
against that limit with spreadsheets, and most large database servers 
use machines with 64-bit address space support.  Note that with current 
large databases a 32-bit address space is insufficient to manage the 
indexes and tables that are (virtual) memory resident.

(Advertisement -- The next paragraph is in some sense a shameless plug 
for the new Opteron from AMD, and for the Athlon64 and Athlon64 FX that 
will be released next month.)

AMD is now selling processors where the architecture supports up to 
64-bit addresses.  The virtual memory system supports 40-bits of 
addressable memory per processor, and the virtual memory system supports 
up to a 48-bit address space.  (But unless you are putting together a 
system with over 1000 processors, those later numbers are details.  The 
Red Storm machine which may soon be the worlds fastest supercomputer 
will have over 10,000 Opteron processors, and I am sure they are working 
the global addressing issue.)  So not only can you now buy machines off 
the shelf that can directly address almost a petabyte of data, some 
organizations are buying them...

But what I wanted to point out about the AMD64 architecture here is that 
with a 64-bit aware OS, modules written in (x86) compatibility mode can 
call dynamically linked libraries that are written in long mode.  So a 
"database" module could address hundreds of Gigabytes of memory 
directly, while the application for the most part uses 32-bit 
addressing.  Compared to a file system call which will take thousands to 
millions of clock cycles, an in memory database can probably be accessed 
in under a hundred clock cycles.  That is a noticeable performance 
improvement.

Apple has also recently started shipping 64-bit machines based on the 
new PowerPC chip from IBM.  And if you are into masochism, there is 
Intel's Itanium2.  (Speaking only as a compiler developer, of course. 
;-)  So in a few years, almost all server hardware should allow users to 
avoid the file system and address enough memory for most accounting 
systems and databases.  Of course, someone will then invent a use for 
all that memory...

-- 
                                                    Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Matthew Heaney]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F4828D9.8050700@attbi.com...
> Alexander Kopilovitch wrote:
>
> For a financial package is 4 Gigabytes of addressable memory enough?
> (Two Gigabytes currently under Windows.)

There's a mode that allows you to use a 3GB of address space, but I think
it's only available on Windows Server versions.

Re: A Customer's Request For Open Source Software

[Marin David Condic]

I think that depends on how you go about doing it. If you're talking 
about small to medium sized businesses (Not Citibank or GM) how many 
accounts do you think they'll want to maintain? How many transactions do 
you think they'll need to support? Certainly for "home" accounting and 
most small businesses, this number can't be really huge. Are the 
accounts and transactions going to be simple ascii and numeric stuff (a 
few hundred bytes a piece, at most?) Or are we going to have to store 
graphics or other really memory intense items with each transaction. 
(Like if you want to keep scanned-in receipts for a transaction.)

I'd think a memory based model would be sufficient right now for 
single-user accounting for home or small businesses. I also think it 
wouldn't be an imense job to take the basic in-memory model and then 
later modify it to write-through to a database or otherwise deal with a 
"transaction" that has to have integrity between multiple users. (Think 
multiple-clients, single-server) So the thing is you could start simple 
and get the programming model you want and then upgrade to fancier 
back-ends if you've got a basic product that works.

For that, I'd think a 32-bit address space ought to be sufficient. But 
if you're doing dynamic allocation and you code things properly, 
switching to a bigger address space ought to be near trivial.

MDC


Robert I. Eachus wrote:
> 
> For a financial package is 4 Gigabytes of addressable memory enough? 
> (Two Gigabytes currently under Windows.)  Some people are running up 
> against that limit with spreadsheets, and most large database servers 
> use machines with 64-bit address space support.  Note that with current 
> large databases a 32-bit address space is insufficient to manage the 
> indexes and tables that are (virtual) memory resident.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Marin David Condic wrote:

> For that, I'd think a 32-bit address space ought to be sufficient. But 
> if you're doing dynamic allocation and you code things properly, 
> switching to a bigger address space ought to be near trivial.

To answer both Marin and Matthew together, yes, under Windows Server you 
can get a 3 Gig process space, but it isn't supported well.  However, 
that is why I was gushing about the AMD64 architecture.  Programs that 
are currently limited to two (or three) Gig, can have a 4 Gig process 
space under the beta of Windows 2003.  No recompiles, no nothing.  Even 
handier, as I pointed out, you can have a DLL that uses 64-bit 
addressing, and returns data copied into the 4 Gig process space.

To use the example of scanned receipts, they wouldn't have to take a 
chunk out of the 4 Gig accounting process address space, just run the 
program to display them in its own 32-bit OR 64-bit address space.  If 
you want to phrase that in Ada, you can have a distributed architecture 
where everything is running on the same system, but different parts of 
the application each have their own address space.  If you happen to 
have a dual or quad processor system fine, but even on a single CPU 
system you get the addressing benefits.  (Yes this code would work on 
Intel chips as well, but the PAE overhead is a killer.)

Combine that with a transaction/journalling system that is very 
lightweight and can use memory-mapped NVRAM, and I think we have a 
winner.  Works something like this.  The database can have per record 
locking.  The transaction system writes the journal entry, then updates 
the database unlocking the entries, and finally the transaction writes a 
completion.  Or, of course, the trasaction fails for some reason and the 
entry is overwritten, or preferably, logged as failed with the reason. 
If you have a small (Compact Flash card maybe?) NVRAM, the transaction 
process can write the log to disk--preferably two disks--when the 
contents of the NVRAM get full.  But my preference is to write the 
entire database out when the session is done, without, of course, 
overwriting the current version on disk.  With proper design, you can 
have a complete journalling and audit trail system with little or no 
user involvement.


-- 
                                               Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Marin David Condic]

If you started with a "Single User" system, then all operations can take 
place in RAM - of whatever sort. This would be no different than editing 
a document with a word processor that is not journaling. If you take a 
power hit, you lose your work to that point in time. You get done 
posting transactions or generating reports - you "Exit - Save" and your 
work is written to a database. (The simplest form would be a stream file 
  where you do a 'Write for your data structure.)

 From there, you can consider if you want to make this a multi-user 
system. An upgrade would be to write a wrapper around the core 
accounting object that acts as a "Server". Multiple clients connect, 
post transactions, disconnect, etc. The server is enforcing a kind of 
transactional integrity and it naturally lends itself to a network. 
(You're still stuck with a potential power-outage problem, but that 
isn't insurmountable. Worst case, you force writes to the database every 
few minutes.)

There would be a couple of advantages to this approach - one technical 
and one financial. Starting with a simple single-user system gives you a 
reasonably simple goal to shoot for and lets you iron out all the bugs 
while building your understanding of what you are doing. The second is 
that you could easily release the single-user version as a freebie that 
would get people using it and then provide the multi-user version as a 
paid-for upgrade.

MDC

Robert I. Eachus wrote:

> contents of the NVRAM get full.  But my preference is to write the 
> entire database out when the session is done, without, of course, 
> overwriting the current version on disk.  With proper design, you can 
> have a complete journalling and audit trail system with little or no 
> user involvement.
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Marin David Condic wrote:

> There would be a couple of advantages to this approach - one technical 
> and one financial. Starting with a simple single-user system gives you a 
> reasonably simple goal to shoot for and lets you iron out all the bugs 
> while building your understanding of what you are doing. The second is 
> that you could easily release the single-user version as a freebie that 
> would get people using it and then provide the multi-user version as a 
> paid-for upgrade.

Ah, the perils of decent design and encapsulation!  If the database 
interface and transaction management protocol are properly encapsulated 
these changes are trivial.  But if they are trivial, you will have a 
hard time charging for them if the base system is free...

--
                                               Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

Robert I. Eachus wrote

> Ah, the perils of decent design and encapsulation!  If the database 
> interface and transaction management protocol are properly encapsulated 
> these changes are trivial.  But if they are trivial, you will have a 
> hard time charging for them if the base system is free...

It is rarely trivial to recognize properly what your customer (of this kind)
really needs -- even for himself -- because his mindset on the matter usually
has neither decent design nor encapsulation. Therefore real job of customization
in this domain is not to make changes, but to determine which changes are
needed.

The problem space for the domain is complex enough, but every single customer
occupies small part of it. And most of that small part is, as a rule, quite 
common and easily identifiable, but almost always there are some bits, which
are rather specific and at the same time important for this particular customer.
Sometimes the crucial moment is simply to determine properly whether specifics
is present or absent.

So, perhaps, more proper way will be to aim not directly to end-user, but to
some sort of consultant, who will install the product for a customer.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Christopher Browne]

In an attempt to throw the authorities off his trail, Marin David Condic <nobody@noplace.com> transmitted:
> If you started with a "Single User" system, then all operations can
> take place in RAM - of whatever sort. This would be no different
> than editing a document with a word processor that is not
> journaling. If you take a power hit, you lose your work to that
> point in time. You get done posting transactions or generating
> reports - you "Exit - Save" and your work is written to a
> database. (The simplest form would be a stream file where you do a
> 'Write for your data structure.)
>
> From there, you can consider if you want to make this a multi-user
> system.

There is a strong tendancy for systems designed in this manner to NOT
play well when they move over to allow concurrency.  I think I can
characterize it all in one word: "Windows."

In spite of there being Windows NT around, which _was_ designed as a
multiuser multitasking system, since so much of the software had its
genesis with companies that assumed ONE user running ONE program on
some variation of Windows 95, which was a thin layering of GUI atop
MS-DOS, what we see now is that "Windows applications" are basically
designed for a single user OS, and most don't play well if you have
multipel instances of things around.

Concurrency is _hard_, and if you don't design it in at the beginning,
it is quite likely that by the time you get around to it, the system
design will probably preclude having it _really_ work...
-- 
output = ("cbbrowne" "@" "acm.org")
http://www.ntlug.org/~cbbrowne/languages.html
"It's not  about 'Where do you  want to go today?'";  "It's more like,
'Where am I allowed to go today?'"

Re: A Customer's Request For Open Source Software

[Marin David Condic]

I agree that concurrency is difficult. What I'm talking about is that if 
you built a core accounting engine that presented itself to the rest of 
the application as an "object" and if that engine initially just 
operated within RAM (load and store to a file), you'd have a useful 
start. If you wanted to later go to a concurrent system you could either 
wrap the core in a server that serialized the access (serve just one 
user at a time in a read/modify/write kind of protocol) *or* if you 
thought that would be unreliable, you could rebuild the core with a 
database beneath it and present the same interface to the rest of the app.

Its mostly a way of saying "Start with a nice simple, achievable goal 
that produces something useful. If it succeeeds in comiing to fruition, 
worry about upgrades later." All too many projects that get discussed 
here end up on the trash heap of obscurity and decay because the owners 
get far too ambitious for their own good. Its a natural human tendancy 
and one that strikes us engineers particularly hard. It has to be 
overcome if you want to actually get something done.

MDC


Christopher Browne wrote:
> 
> 
> There is a strong tendancy for systems designed in this manner to NOT
> play well when they move over to allow concurrency.  I think I can
> characterize it all in one word: "Windows."
> 
> In spite of there being Windows NT around, which _was_ designed as a
> multiuser multitasking system, since so much of the software had its
> genesis with companies that assumed ONE user running ONE program on
> some variation of Windows 95, which was a thin layering of GUI atop
> MS-DOS, what we see now is that "Windows applications" are basically
> designed for a single user OS, and most don't play well if you have
> multipel instances of things around.
> 
> Concurrency is _hard_, and if you don't design it in at the beginning,
> it is quite likely that by the time you get around to it, the system
> design will probably preclude having it _really_ work...


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I agree that concurrency is difficult. What I'm talking about is that if 
> you built a core accounting engine that presented itself to the rest of 
> the application as an "object" and if that engine initially just 
> operated within RAM (load and store to a file), you'd have a useful 
> start. 
...
> MDC

Actually, that is not too far away! I just finished testing some generic
database code, that can swing between PostgreSQL and MySQL with just
a swap of a "with" statement in the main program (using APQ 2.0). This
relies heavily on tagged types and polymorphism, but it works very
well.

You build your code so that it only needs the database connection
Root_Connection_Type'Class (which naturally dispatches when used),
and the procedure that this connection object is passed to
can do everything else in a database neutral way.

This is not to say there aren't some database specific issues,
but there are ways to deal with most of these, and some of
them in a fairly generic way.

Since accounting is such a basic need, I have made plans to include
an accounting engine object in a child package, to do just the sort
of thing you have suggested. I mean, why build the accounting engine
more than once?  Everyone needs accounting. The package may
fit into the hierarchy structure as something like
APQ.Applications.Accounting. If you want to see a rough draft
of a PDF manual for APQ version 2.0, email me and I'll send it
to you (it includes some generic database code examples).

The first thing I had to conquer was generic database
programming, since I don't like being locked into one
brand of database.  Whatever I choose will be the wrong
choice for you, or the wrong choice 2 years from now.
But this annoyance is nearly out of the way now.

I only like to write such things once if possible, and
only support one instance of the same code. So the time is
now ripe for application objects of this type. It is nearly
next on my list of things to do, and I have a big list ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[chris]

Robert I. Eachus wrote:
> 
> Apple has also recently started shipping 64-bit machines based on the 
> new PowerPC chip from IBM.  And if you are into masochism, there is 
> Intel's Itanium2.  (Speaking only as a compiler developer, of course. 
> ;-)  So in a few years, almost all server hardware should allow users to 
> avoid the file system and address enough memory for most accounting 
> systems and databases.  

What do you mean 'avoid the file system'?  I've heard people say if vast 
amounts of persistant ram storage become available file systems will be 
given the boot.  Is that what you meant?  If so I can't see it.  You 
still have to know where things are and more importantly you need a 
conceptual association with data.  That's all a file system is really, a 
way to name blocks of data (people won't be able to remember 100 64bit 
addresses, even in hex).  Everything else is just built on top of that 
simple idea.  The details may (will) change but it'll still be a file 
system.  (Just a really fast, abundant and abused* one).


 > Of course, someone will then invent a use for
> all that memory...
> 

Orthogonal Persistance with versioning and reversability implemented in 
Windows ;)



Chris

*Although I'd love an athlon 64 and love lots of persistant ram more, it 
might be actually be bad thing.  Will people bother with the memory 
footprint of their apps anymore?  Sure some algorithms which have large 
space demands might be feasible and desirable, but I fear many will just 
  factor out memory as a concern and gobble as much of it as they can.

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

chris wrote:

> What do you mean 'avoid the file system'?  I've heard people say if vast 
> amounts of persistant ram storage become available file systems will be 
> given the boot.  Is that what you meant?  If so I can't see it.  You 
> still have to know where things are and more importantly you need a 
> conceptual association with data.  That's all a file system is really, a 
> way to name blocks of data (people won't be able to remember 100 64bit 
> addresses, even in hex).  Everything else is just built on top of that 
> simple idea.  The details may (will) change but it'll still be a file 
> system.  (Just a really fast, abundant and abused* one).

What was so wonderful about Multics?  In part, that it wasn't built 
around a file system, it was built around virtual memory.  I won't go 
into the gory details here--you can find the Organik book if you haven't 
read it.  But the memory concept in Multics was that everything was made 
of segments, and a process had access to segments.  (Of course, some of 
the things in those segments were links to other segments.)

The point though, is that you don't open a file and read it record by 
record or line by line.  You map a segment into your process and can 
address any bit in the segment at random.  The operating system may have 
some of pages of the segments your process has access to resident in 
memory and others still on disk, but you (and your applications) don't 
care.  Access to the data is not mediated by the OS or the file system 
once you link to the segment.  (Of course, on Multics when you linked to 
a segment both mandatory (security) permission levels and discressional 
access permissions are checked, and if those permissions change, the 
link will be snapped and have to be re-established with a new set of 
access checks. But all that is implementation detail.)

This was the paradox of Multics that most people never understood.  The 
system could afford to have good security because compared to 
conventional OSes security checks--and all of the other overhead of 
accessing a file--only needed to be done maybe one-thousandth as often, 
if that.

The rest of what you talk about has to do with naming of datasets. 
Multics had both character string versions of pointers and "packed" 
hardware pointers.  The character strings corresponded to file names 
(and a directory hierarchy) on a conventional system, plus the ability 
to address multiple entry points in a segment, or address an individual 
bit.  The packed pointers were used by hardware to actually find the 
data.  And as I alluded to above, converting a pathname to a segment 
table entry is the one time that access rights have to be checked.  If 
the access control list or security level for a segment changes, then 
all existing page table entries are invalidated, and have to be 
revalidated to access the segment again.  Neat, simple, and secure.

So yes, when I talk about memory-mapping of files and not avoiding any 
file systems that is exactly what I mean.  And until you have worked 
with a system that supports it well, you don't know what you are missing.

Just one other example.  Multics of course had dynamic linking, but the 
form of dynamic linking was much different from what we think of today. 
  During development, you never invoked a linker.  You just had all of 
the the code segments of your program lying around, pointed at the main 
program--or some other entry point, and said run.  If you got to a point 
in your program where you called a procedure you hadn't written yet? 
The operating system would tell you that a call had been made to a 
segment it couldn't find.  You could then run emacs, write the code, 
compile it, then--and only then--tell the OS where to find the code. 
Your program would continue running from the point where it had stopped. 
   Once you had a complete, debugged program, you often invoked the 
binder, and put all your pieces together in one segment.  Of course, 
there were probably lots of pathnames that connected to the OS, or to 
other subsystems, etc., that you left unresolved in the bound version.
--
                                        Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <3F4EA616.30607@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:

> The point though, is that you don't open a file and read it record by 
> record or line by line.  You map a segment into your process and can 
> address any bit in the segment at random.

> This was the paradox of Multics that most people never understood.  The 
> system could afford to have good security because compared to 
> conventional OSes security checks--and all of the other overhead of 
> accessing a file--only needed to be done maybe one-thousandth as often, 
> if that.

That sounds true for unrestricted access, but the number of occasions
for checks should have to be the same as any other operating system for
data protected as "single writer at a time".

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Larry Kilgallen wrote:

> That sounds true for unrestricted access, but the number of occasions
> for checks should have to be the same as any other operating system for
> data protected as "single writer at a time".

I wasn't particularly addressing that, but yeah, in Multics, its "in 
there."  The first and most important feature for supporting multiple 
writers was known as the first reference trap.  When a process accessed 
  a segment for the first time, or wrote to a segment for the first time 
(for that segment) there was a piece of code associated with each action 
that would be run (if non-null).  Sometimes, for example if a program 
had a predefined data segment, it would do copy-on-write so the first 
time the program wrote to its data segment, the process got its own 
copy.  There were a number of "predefined" first reference trap-handlers 
that were used for common purposes.

For example, there was a MRDS (Multics Relational Database System) 
manager.  MRDS ran in ring 2, so if a segment had a write bracket of 2, 
any attempt to write would be passed inward to MRDS.  If you wanted 
transaction protection, you would define a set of MRDS transactions and 
MRDS would guarantee the all or nothing character of each transaction. 
(The first reference trap initialized the database connection.)  Even 
though MRDS supported the whole relational algebra, you could use it for 
concurrency protection with out using the rest of it.

Similarly, the mail system ran in ring 3. Processes sometimes used the 
mail system just to create and manage (in-memory) queues.  No reason not 
to.  Since the mail system didn't have to work through a file system, it 
could be very fast--and low overhead.  Inward ring calls are/were also 
very cheap in Multics, and returns from an inward call wasn't much of a 
problem.  The tricky part of the ring system was the "crawl-out" in the 
login daemon.  The code had to do a lot of checks that were normally 
done by the hardware, then "return" into the newly created outer ring 
environment.

-- 
                                             Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Jon S. Anthony]

"Robert I. Eachus" <rieachus@attbi.com> writes:

Re: Multics memory stuff...

Sounds like a bit like a subset of a Lisp machine/OS.

> Just one other example.  Multics of course had dynamic linking, but
> the form of dynamic linking was much different from what we think of
> today. During development, you never invoked a linker.  You just had
> all of the the code segments of your program lying around, pointed at
> the main program--or some other entry point, and said run.  If you got
> to a point in your program where you called a procedure you hadn't
> written yet? The operating system would tell you that a call had been
> made to a segment it couldn't find.  You could then run emacs, write
> the code, compile it, then--and only then--tell the OS where to find
> the code. Your program would continue running from the point where it
> had stopped.  Once you had a complete, debugged program, you often
> invoked the binder, and put all your pieces together in one segment.
> Of course, there were probably lots of pathnames that connected to the
> OS, or to other subsystems, etc., that you left unresolved in the
> bound version.

This, of course, is definitely a part of a Lisp OS.  Actually this is
still available in CL implementations even on current (primitive)
state of the art HW...

/Jon

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>What was so wonderful about Multics?  In part, that it wasn't built
>around a file system, it was built around virtual memory.  I won't go
>into the gory details here--you can find the Organik book if you haven't
>read it.  But the memory concept in Multics was that everything was made
>of segments, and a process had access to segments.  (Of course, some of
>the things in those segments were links to other segments.)

What is not so wonderful about Multics? That it is almost mythical in part,
somehow like ancient Greece - famous, with obvious conceptual heritage, but
unreachable for observation and study. You mentioned Organik's book - well,
here is a copy of single review for it at Amazon:

------------------------------------------------------------------
Organick describes the design of Multics, a mainframe timesharing system that
was one of the most influential software efforts of the late 1960s. The book
describes the internals of the Multics system with a clarity and thoroughness
that set a standard for other writers on operating systems. The book describes
Multics as it was planned in the late 1960s, before it had been released to
users, and it describes the version of the system that ran on the GE-645
computer. Multics became a commercial product from Honeywell on a substantially
enhanced machine and continued to evolve for 20 years, so readers should
understand that they are reading about the system designers' intentions and
plans, and not necessarily about features of the commercial system.
(disclosure: I worked on Multics in the 60s and helped review drafts of some
chapters of this book before publication.) 
-----------------------------------------------------------------

After all, another Organik's book is about ill-fated, although also famous
that time Intel 432 processor (by the way, I remember vague rumors that that
processor somehows implements/supports Ada directly in hardware) - was this
author specializing on the subjects that were impressive in design, but have
no real perspective as products?

Anyway, it seems that Multics world was very closed world, consisting of
competent, creative and ethusiastic people,,, who appreciate each other, but
were disinterested in presenting the results of their work to broader community.
If this impression is wrong then how can one explain apparent absence of
publications describing the developed Multics system? Certainly it is a tradition
in science and even in engineering to describe thoroughly every significant
project, which results may influence future progress.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> What is not so wonderful about Multics? That it is almost mythical in part,
> somehow like ancient Greece - famous, with obvious conceptual heritage, but
> unreachable for observation and study.

I had accounts on various Multics systems, and at one point I had half a 
dozen project accounts distributed among three Multics systems. 
(HI-Multics in Minneapolis, MN System-M in Phoenix, AZ and BCO-Multics 
in Billerica, MA.)   Later I added an account at MIT-Multics (Cambridge, 
MA).

Then I moved to Stratus Computer.  VOS, the "native" operating system 
for Stratus products was closely based on PrimOS, which in turn was 
based on Multics.  So Multics features were widely available, even if 
Multics systems were not.

I would love to have an operating system for today's x86 processors that 
took the Multics approach.  But the problem would be that most 
applications would be ported versions of applications that were designed 
around file systems, so you would have to materialize a file system for 
them. :-(

Could be done, but I think the better approach is to design applications 
that don't require a file system first.

-- 
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > What is not so wonderful about Multics? That it is almost mythical in part,
> > somehow like ancient Greece - famous, with obvious conceptual heritage, but
> > unreachable for observation and study.
>
> I had accounts on various Multics systems, and at one point I had half a
> dozen project accounts distributed among three Multics systems.
> (HI-Multics in Minneapolis, MN System-M in Phoenix, AZ and BCO-Multics
> in Billerica, MA.)   Later I added an account at MIT-Multics (Cambridge,
> MA).
>
> Then I moved to Stratus Computer.  VOS, the "native" operating system
> for Stratus products was closely based on PrimOS, which in turn was
> based on Multics. So Multics features were widely available, even if
> Multics systems were not.

Well, the Multics features were more widely available then Multics itself, but
nevertheless there were (and certainly are) very few people who have real
experience with Multics or at least those Multics features and are more or
less active today. And there is no good book accumulating both description of
the real producttion system and experience with it.

> I would love to have an operating system for today's x86 processors that
> took the Multics approach.  But the problem would be that most
> applications would be ported versions of applications that were designed
> around file systems, so you would have to materialize a file system for
> them. :-(
>
>Could be done, but I think the better approach is to design applications
>that don't require a file system first.

I don't think that this porting is a grave problem, this is something like
transition from 16-bit MS Windows 3.1/3.11 to 32-bit Windows 95 and Windows
NT 3.5 and then to Windows 98 and Windows NT 4.0 and further. First time it
was significant to support previous 16-bit applications, but then they began
steadily disappear, being replaced by new 32-bit ones - more and more often
not simply "ported", but designed (or redesigned) for new 32-bit systems.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> I don't think that this porting is a grave problem, this is something like
> transition from 16-bit MS Windows 3.1/3.11 to 32-bit Windows 95 and Windows
> NT 3.5 and then to Windows 98 and Windows NT 4.0 and further. First time it
> was significant to support previous 16-bit applications, but then they began
> steadily disappear, being replaced by new 32-bit ones - more and more often
> not simply "ported", but designed (or redesigned) for new 32-bit systems.

It is a resource issue.  It would be nice to have a son of Multics 
implementation in Ada, but the cost of doing that for any real platform 
is prohibitive.  I think the last time I seriously looked, Multics ran 
to over 20 million lines of (almost all PL/I) source code.  That does 
include the compilers, mail system, emacs, relational data base, etc., 
but it gives you some idea how large the Multics environment was.

On the other hand most RDBMSs have options for bypassing the file system 
and managing disk storage directly.  With a large amount of NVRAM, their 
is no need for the file system at all.  So my feeling is that the way to 
get something to market at the right time is to concentrate on products 
that can take full advantage of large (and non-volitile) addressable 
memories.
-- 
                                             Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> It is a resource issue.  It would be nice to have a son of Multics
> implementation in Ada, but the cost of doing that for any real platform
> is prohibitive.  I think the last time I seriously looked, Multics ran
> to over 20 million lines of (almost all PL/I) source code.  That does
> include the compilers, mail system, emacs, relational data base, etc.,
> but it gives you some idea how large the Multics environment was.

Well, this is understandable. But I guess that there may be non-conventional
ways to get something like that. One way, which I imagine, largely avoids that
"prohibitive cost" (although it still may be considered as a sort of a plot
for an episode of the serial "Wild Investor" -:) : take existing open source
OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers
from the ground, that is, from the kernel, following the Multics design, and
making necessary bridges (between lower Multics-layers and upper FreeBSD
layers) at each stage, thus maintaining functionality but not too worrying
about effectiveness.

> On the other hand most RDBMSs have options for bypassing the file system
> and managing disk storage directly.  With a large amount of NVRAM, their
> is no need for the file system at all.  So my feeling is that the way to
> get something to market at the right time is to concentrate on products
> that can take full advantage of large (and non-volitile) addressable
> memories.

Well, I have vague only feeling about current state of RDBMSs, and it is not
clear for me whether people in that area will see that as major improvement
(for what I constantly hear, their main practical problem regarding efficiency
is just right index structure). But I have a friend who is an active professional
in this area, both at academic side and at practical side, and I'm going to ask
for his opinion on this matter (but it may take about 2 weeks, because just
now he is busy at a DBMS conference in Germany -;) ... if his opinion will be
positive then, perhaps, some of his Ph.D. students will become interested in
such a project -:) .



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Well, this is understandable. But I guess that there may be non-conventional
> ways to get something like that. One way, which I imagine, largely avoids that
> "prohibitive cost" (although it still may be considered as a sort of a plot
> for an episode of the serial "Wild Investor" -:) : take existing open source
> OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers
> from the ground, that is, from the kernel, following the Multics design, and
> making necessary bridges (between lower Multics-layers and upper FreeBSD
> layers) at each stage, thus maintaining functionality but not too worrying
> about effectiveness.

Non-starter, really.  That would be like translating a novel from 
Russian to English a word at a time.  You would end up with a book all 
in English, but full of Russian idioms and with no English idioms or 
common phrases.  Actually, make that Klingon and English, or something 
even wierder. Klingon to Chinese?

There are hundreds, make that thousands of assumptions in a disk-based 
OS that are absent or different in Multics.  For example on Multics 
there is a tool called the binder that can be used to bundle up 
snapshots of a group of programs.  These snapshots are not the programs, 
but they are the closest Multics has to the concept of a computer 
program.  In the Multics world, a program is often no better defined 
than "this entry point in this segment, called with these parameters." 
Of course, there is on-line documentation FOR THAT SEGMENT, that 
explains all that.  (And yes, one of the things that you pass to the 
binder is a list of the entry points that you want to be visible.)

Similarly, connecting to a Multics site is a meaningful concept. 
Booting is something that hardware does after a power failure.  You can 
have a Multics site with several CPUs--I think System M in Phoenix had 
five--and we can discuss things in terms of symmetric multiprocessing. 
But that sort of misses the point.  The Multics site can add CPUs, drop 
CPUs, upgrade CPUs, etc., and all that is going on from the Multics 
viewpoint is adding and removing resources.  Same for memory, disk 
drives, tape drives, and any other resources.  (Hmmm. Translation, in 
the Multics world critical is not a word you assoicate with resources.)

> Well, I have vague only feeling about current state of RDBMSs, and it is not
> clear for me whether people in that area will see that as major improvement
> (for what I constantly hear, their main practical problem regarding efficiency
> is just right index structure). But I have a friend who is an active professional
> in this area, both at academic side and at practical side, and I'm going to ask
> for his opinion on this matter (but it may take about 2 weeks, because just
> now he is busy at a DBMS conference in Germany -;) ... if his opinion will be
> positive then, perhaps, some of his Ph.D. students will become interested in
> such a project -:) .

As I said, most RDBMSs already have the ability to bypass the OS and 
access disk drives directly.  This is going one step further, and 
"mapping" the disk drive into memory.  With a memory-mapped drive on a 
virtual memory system, you can address the disk just like the memory was 
physically present in RAM.  On Multics, a user process had 4096 segment 
descriptors available, each of which could map to about one Megabyte of 
RAM (actually 256k words of 36-bit memory).  Some of these segments were
common OS gate segments, some were applications in use by the user, some 
were what you would think of as open files, and some were user defined 
segments with entry points.  (Remember, one segment could have several 
hundred different entry points--or more.  About a dozen entry points was 
common.)
-- 
                                          Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Christopher Browne]

The world rejoiced as "Robert I. Eachus" <rieachus@attbi.com> wrote:
> Alexander Kopilovitch wrote:
>
>> Well, this is understandable. But I guess that there may be non-conventional
>> ways to get something like that. One way, which I imagine, largely avoids that
>> "prohibitive cost" (although it still may be considered as a sort of a plot
>> for an episode of the serial "Wild Investor" -:) : take existing open source
>> OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers
>> from the ground, that is, from the kernel, following the Multics design, and
>> making necessary bridges (between lower Multics-layers and upper FreeBSD
>> layers) at each stage, thus maintaining functionality but not too worrying
>> about effectiveness.
>
> Non-starter, really.  That would be like translating a novel from
> Russian to English a word at a time.  You would end up with a book all
> in English, but full of Russian idioms and with no English idioms or
> common phrases.  Actually, make that Klingon and English, or something
> even wierder. Klingon to Chinese?
>
> There are hundreds, make that thousands of assumptions in a
> disk-based OS that are absent or different in Multics.  For example
> on Multics there is a tool called the binder that can be used to
> bundle up snapshots of a group of programs.  These snapshots are not
> the programs, but they are the closest Multics has to the concept of
> a computer program.  In the Multics world, a program is often no
> better defined than "this entry point in this segment, called with
> these parameters." Of course, there is on-line documentation FOR
> THAT SEGMENT, that explains all that.  (And yes, one of the things
> that you pass to the binder is a list of the entry points that you
> want to be visible.)

Right, that sure was one of the bigger differences with Multics.

That means that a recreations would need to have a fair bit of code to
support this.

A start might be to look into RVM, the "recoverable virtual memory"
system created for the Coda distributed filesystem.  That is a system
that implements something strongly resembling Multics segments, which
runs on all sorts of systems.

Instead of giving up because it's necessary to implement _everything_,
from hardware on up, in order to have a viable system, it might be an
idea to start by hosting "PseudoMultics" atop one of the Unixes,
running it inside user space, with a view to modifying the kernel
eventually to support things that vitally need to be in the kernel.

> Similarly, connecting to a Multics site is a meaningful
> concept. Booting is something that hardware does after a power
> failure.  You can have a Multics site with several CPUs--I think
> System M in Phoenix had five--and we can discuss things in terms of
> symmetric multiprocessing. But that sort of misses the point.  The
> Multics site can add CPUs, drop CPUs, upgrade CPUs, etc., and all
> that is going on from the Multics viewpoint is adding and removing
> resources.  Same for memory, disk drives, tape drives, and any other
> resources.  (Hmmm. Translation, in the Multics world critical is not
> a word you assoicate with resources.)

That can only conceivably be supported on hardware that conciously
supports adding and dropping CPUs while the system is "hot."  You're
lucky, these days, to have a RAID controller that lets you hot-swap
disk drives; hot-swapping processors tends to indicate that you have
multiplied the cost of the system up to a new level.

Vis-a-vis disk, it's quite common for the support for that to mostly
sit at the hardware level, where a lot of change can take place with
the OS being oblivious to it.  (That's one of the _nice_ things about
FibreChannel arrays...)

But mandating an OS design that mandates this
"many-times-more-expensive" sort of hardware in days when
over-the-counter hardware is so cheap and available seems almost as
limiting as the lack of an "adding CPUs" feature.

I think it would be a mistake, today, to assume hot-swappable CPUs as
a basic function of the hardware.  It has proven a lot more economical
to put additional rackmounted computers onto a rack, and separate the
functions across multiple buses.

Futurists keep imagining that we are right around the corner from the
situation where it will make sense to buy computers that have huge
arrays of CPUs; while Apple may be very proud of their dual-PPC "G5"
systems, prices of multi-CPU "backplanes" remain stunningly higher
than those for single-CPU hardware, and there doesn't seem to be good
reason for that to change soon.

> As I said, most RDBMSs already have the ability to bypass the OS and
> access disk drives directly.

That's news; I wasn't aware that there were any left since Digital
sold RDB to Oracle.

There are some that support "raw partitions," but this doesn't involve
"bypassing the OS;" they merely bypass filesystem support.
-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"The only constructive theory connecting neuroscience and psychology
will arise from the study of software." 
-- Alan Perlis
[To the endless aggravation of both disciplines.  Ed.]

Re: A Customer's Request For Open Source Software

[Ludovic Brenta]

Christopher Browne <cbbrowne@acm.org> writes:

> I think it would be a mistake, today, to assume hot-swappable CPUs
> as a basic function of the hardware.  It has proven a lot more
> economical to put additional rackmounted computers onto a rack, and
> separate the functions across multiple buses.
> 
> Futurists keep imagining that we are right around the corner from
> the situation where it will make sense to buy computers that have
> huge arrays of CPUs; while Apple may be very proud of their dual-PPC
> "G5" systems, prices of multi-CPU "backplanes" remain stunningly
> higher than those for single-CPU hardware, and there doesn't seem to
> be good reason for that to change soon.

In fact, mainframes have had this kind of capability for quite some
time now.  And the people who use them take hot-swapped CPUs for
granted.  The only reason why they don't convey an image of futurism
is that they still program in COBOL :) Yes, mainframe-class hardware
costs more than commodity PCs, but there are situations where this is
economically sensible because racks upon racks of small independent
computers mean huge sysadmin costs.  I have been personally involved
in managing several racks of 32 Linux blade servers and I can tell you
that this kind of approach simply does not scale from a human
perspective.

More info here:

http://www-1.ibm.com/servers/eserver/zseries/library/techpapers/gm130260.html

(I am not affiliated with IBM).

-- 
Ludovic Brenta.

Re: A Customer's Request For Open Source Software

[Christopher Browne]

Ludovic Brenta <ludovic.brenta@skynet.be> wrote:
> In fact, mainframes have had this kind of capability for quite some
> time now.

I know that.  That is why I used words like
"many-times-more-expensive" and "over-the-counter".

When building a new operating system, in the post-Mach, post-Windows
NT age, where the ground has been scorched, and there are no DARPA
projects pushing hundreds of millions of dollars at OS research, there
is little point in building something that requires custom hardware.
-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://cbbrowne.com/info/oses.html
HEADLINE: Suicidal twin kills sister by mistake! 

Re: A Customer's Request For Open Source Software

[Charlie Spitzer]

"Christopher Browne" <cbbrowne@acm.org> wrote in message
news:bj2asn$egqfv$1@ID-125932.news.uni-berlin.de...
> Ludovic Brenta <ludovic.brenta@skynet.be> wrote:
> > In fact, mainframes have had this kind of capability for quite some
> > time now.
>
> I know that.  That is why I used words like
> "many-times-more-expensive" and "over-the-counter".

not so expensive. far more reliable than clusters. see the ftserver product
at http://www.stratus.com for hot swappable cpus for windows on pcs that's
available now.

> When building a new operating system, in the post-Mach, post-Windows
> NT age, where the ground has been scorched, and there are no DARPA
> projects pushing hundreds of millions of dollars at OS research, there
> is little point in building something that requires custom hardware.
> --
> (reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
> http://cbbrowne.com/info/oses.html
> HEADLINE: Suicidal twin kills sister by mistake!

caveat: i work for stratus, but don't speak for them.

regards,
charlie
stratus cac

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Ludovic Brenta wrote:

> In fact, mainframes have had this kind of capability for quite some
> time now.  And the people who use them take hot-swapped CPUs for
> granted.  The only reason why they don't convey an image of futurism
> is that they still program in COBOL :) Yes, mainframe-class hardware
> costs more than commodity PCs, but there are situations where this is
> economically sensible because racks upon racks of small independent
> computers mean huge sysadmin costs.  I have been personally involved
> in managing several racks of 32 Linux blade servers and I can tell you
> that this kind of approach simply does not scale from a human
> perspective.

That's why I, and apparently IBM are so enamored of the new (AMD) 
Opteron-based servers from Newisys (just acquired by SCI-Sanmina).  The 
(dual or quad) processor servers have an additional smaller processor 
with its own Ethernet port.  You can connect all these server processors 
to a PC (or to several) on sysadmins desks, and they can do all the 
typical system adminstration type stuff from their desks in addition to 
the normal remote functions like checking loads--shutdown, restart, kill 
a particular memory DIMM, boot in an alternate mode for file backup and 
all that, even run some hardware diagnostics.  It doesn't make running 
an array of servers painless, but it does take away a lot of the pain. 
And, yes, you can kill one CPU if necessary.  You do lose the memory 
connected to that CPU though.  (The RAM in an Opteron system connects 
directly to the CPU without going through a Northbridge.)

-- 
                                          Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Jacob Sparre Andersen]

Christopher Browne wrote:
> The world rejoiced as "Robert I. Eachus" <rieachus@attbi.com> wrote:
>>Alexander Kopilovitch wrote:

[ viewing CPU's as just another resource ]

> That can only conceivably be supported on hardware that conciously
> supports adding and dropping CPUs while the system is "hot."

I am not sure I agree with you on this point.  I beleive that MOSIX
actually allows you to do something like that, although the units you
add or drop are whole physical machines and not just single CPU's or
memory blocks.

> But mandating an OS design that mandates this
> "many-times-more-expensive" sort of hardware in days when
> over-the-counter hardware is so cheap and available seems almost as
> limiting as the lack of an "adding CPUs" feature.

If it is sufficient to be able to add or drop physical machines from a
networked cluster of machines that make up the Multics site, then I
don't see it as a problem.

Jacob
-- 
"We will be restoring normality as soon as we are sure what is normal
  anyway."

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Jacob Sparre Andersen wrote:

> If it is sufficient to be able to add or drop physical machines from a
> networked cluster of machines that make up the Multics site, then I
> don't see it as a problem.

Agreed.  There is no particular need for any element to be "hot 
swapable."  With Multics, the units that could be added or dropped were 
large cabinets, call it six feet by three by three or so.  The point was 
that the Multics site had an electronic existance that was not tied to 
any particular hardware.  You could, and many sites did, upgrade the 
hardware, replacing all of it without ever shutting the site down.
-- 
                                            Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Edward Rice]

In article <3F620703.9080804@attbi.com>,
"Robert I. Eachus" <rieachus@attbi.com> wrote:

 > any particular hardware.  You could, and many sites did, upgrade the 
 > hardware, replacing all of it without ever shutting the site down.

Can you actually point to any site that re-cabled a processor or IOM or SCU
without powering down the system, Robert?  At AFDSC, we did about as much
dynamic reconfiguration (and upgrading) as any place, but when it came time
to disconnect power and data cables, HFED wanted the system all to
themselves.

We certainly split our system without bringing down service -- that was a
daily operation.  But I don't consider adding back a processor at 5:00 AM
that was removed at 8:00 PM the previous evening to be an upgrade.

    Edward Rice

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Edward Rice wrote:
> 
> Can you actually point to any site that re-cabled a processor or IOM or SCU
> without powering down the system, Robert?  At AFDSC, we did about as much
> dynamic reconfiguration (and upgrading) as any place, but when it came time
> to disconnect power and data cables, HFED wanted the system all to
> themselves.
> 
> We certainly split our system without bringing down service -- that was a
> daily operation.  But I don't consider adding back a processor at 5:00 AM
> that was removed at 8:00 PM the previous evening to be an upgrade.

At BCO in Billerica, MA it was actually done at least once or twice that 
I was aware of.  As you point out, it is a power and cabling issue.  We 
did have every box on its own circut breaker, so doing it was a lot less 
dangerous.  But remember, that in this situation it helped a lot that 
BCO was part of Honeywell, and there was some trading back and forth of 
staff with CISL in Cambridge, MA, where they hacked their own Multics 
system a lot.  (CISL was the development site for Multics.)

As for disk and tape drives, that was done all the time.

The only two times I can remember BCO being down, a squirrel jumped from 
one power wire coming into the building to another in the rain.  I also 
can't remember any occasion where Honeywell support people came to our 
site.  Doesn't mean it didn't happen.  However there were at least a 
dozen times where someone from CISL showed up to do a hardware mod, or 
to oversee an OS upgrade.

Even though we were a different part of Honeywell from CISL, the 
geographic convenience meant that we were often the first non-CISL site 
to install a software upgrade or hardware fix.  Those hardware fixes 
were the occasions where one processor at a time was shut down, modified 
and added back in.

But again, the reason it was so nice was that it was much nicer to live 
with fewer processors for most of a day, compared to shutting the site 
down for a day or two to do the same thing.

--
                                          Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Christopher Browne]

In an attempt to throw the authorities off his trail, Jacob Sparre Andersen <sparre@crs4.it> transmitted:
> Christopher Browne wrote:
>> The world rejoiced as "Robert I. Eachus" <rieachus@attbi.com> wrote:
>>>Alexander Kopilovitch wrote:
>
> [ viewing CPU's as just another resource ]
>
>> That can only conceivably be supported on hardware that conciously
>> supports adding and dropping CPUs while the system is "hot."
>
> I am not sure I agree with you on this point.  I beleive that MOSIX
> actually allows you to do something like that, although the units
> you add or drop are whole physical machines and not just single
> CPU's or memory blocks.

That agrees with what I have heard about MOSIX.

There's a BIG efficiency difference between the approaches, to the
point of massively changing the approaches you would take to using the
'cluster.'

If the CPUs are on the same bus, then you can assume quick inter-CPU
communications, and that changes task scheduling rather a lot as
compared to off-host scheduling of work.

>> But mandating an OS design that mandates this
>> "many-times-more-expensive" sort of hardware in days when
>> over-the-counter hardware is so cheap and available seems almost as
>> limiting as the lack of an "adding CPUs" feature.
>
> If it is sufficient to be able to add or drop physical machines from
> a networked cluster of machines that make up the Multics site, then
> I don't see it as a problem.

If that were the proper interpretation, I wouldn't see it as a big
problem.  Which interpretation is right seems to me to be a pretty big
/design/ question...
-- 
output = reverse("moc.enworbbc" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/
Coming  Soon  to a  Mainframe  Near  You!   MICROS~1 Windows  NT  6.0,
complete with VISUAL JCL...

Re: A Customer's Request For Open Source Software

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > take existing open source
> > OS - FreeBSD is, perhaps, the best candidate - and start to replace its layers
> > from the ground, that is, from the kernel, following the Multics design, and
> > making necessary bridges (between lower Multics-layers and upper FreeBSD
> > layers) at each stage, thus maintaining functionality but not too worrying
> > about effectiveness.
>
>Non-starter, really.

Perhaps. Although I don't see serious reasons for that other than insufficient
information about real Multics (including its usage).

> That would be like translating a novel from 
>Russian to English a word at a time.  You would end up with a book all 
>in English, but full of Russian idioms and with no English idioms or 
>common phrases.

Well, let's compare it with translation, but why such a ridiculous way - word
by word? You said Russian novel to English - good, let it be (for example)
L.Tolstoy (I think that Tolstoy and Dostoevsky are most known Russian writers
in USA, and programming still didn't reach the Dostoevsky's level of tense
and struggling -:). So, as we know that Tolstoy's writings consist of 3 major
components - static descriptions of natural environment, long moral speeches,
static and dynamic description of characters - and occasional (rare) short
sayings of exceptional strength or contents, so we can deal with all that by
corresponding stages. First, we'll translate into English all descriptions
of natural environment. At the second stage we'll translate moral speeches.
Then, at the third stage we'll translate the rest - real contents, character
by character. And during that third stage we'll care about those singled
sayings.

> Actually, make that Klingon and English, or something 
> even wierder. Klingon to Chinese?

I was very surprised about that Klingon - I never saw this name. So I was
forced to search via Google for it, and yes, I found that this is the language
from Star Trek product. Well, I understand that perhaps it is impossible to 
avoid Star Trek in USA - just as it was impossible to avoid Communist's favorite
movies, songs and slogans in USSR. By the way, here in Russia we have our own
alien language - from the movie "Kin-za-dza" (produced about 1990). It is very
simple language - less that 10 words for all occasions. Two main words are
like "qoo" (positive word, double and triple "qoo" along with touching your
cheeks with your fingers are used for expression of admiration, subordination,
etc.) and like "que" (negative word). Well, I recommend you that good movie,
if you want to understand the mood in the late Soviet Union -:) .

> There are hundreds, make that thousands of assumptions in a disk-based 
> OS that are absent or different in Multics.

Yes, surely. But I do not think that one must be too serious about all those
assumptions. Some of them are significant and should be satisfied or simulated
one way or another; but most of them really need not be satisfied - they may
be substituted by other assumptions without much harm. (I'm not saying that this
is simple or smooth job -;). Note, that in the intermediate stages (being partially
Multics and partially FreeBSD) the system need not have production strength.

>  For example on Multics 
> there is a tool called the binder that can be used to bundle up 
> snapshots of a group of programs.  These snapshots are not the programs, 
> but they are the closest Multics has to the concept of a computer 
> program.  In the Multics world, a program is often no better defined 
> than "this entry point in this segment, called with these parameters." 
> Of course, there is on-line documentation FOR THAT SEGMENT, that 
> explains all that.  (And yes, one of the things that you pass to the 
> binder is a list of the entry points that you want to be visible.)

I don't see why this may appear serious obstacle. I can't imagine that it may
be too hard to emulate conventional process environment in any reasonable OS.
Just because that conventional process corresponds to important and natural
needs of significant share of users - so, if OS can't provide that opportunity
then it is fatally flawed as general-purpose OS, and given the fame of Multics
it seems improbable.

> Similarly, connecting to a Multics site is a meaningful concept. 
> Booting is something that hardware does after a power failure.  You can 
> have a Multics site with several CPUs--I think System M in Phoenix had 
> five--and we can discuss things in terms of symmetric multiprocessing. 
> But that sort of misses the point.  The Multics site can add CPUs, drop 
> CPUs, upgrade CPUs, etc., and all that is going on from the Multics 
> viewpoint is adding and removing resources.  Same for memory, disk 
> drives, tape drives, and any other resources.  (Hmmm. Translation, in 
> the Multics world critical is not a word you assoicate with resources.)

I don't see how these features of Multics may create any obstacle for suggested
scenario - they all are additional features (relative to conventional OS), and
in the scenario Multics grows from the lower layers.

> As I said, most RDBMSs already have the ability to bypass the OS and 
> access disk drives directly.  This is going one step further, and 
> "mapping" the disk drive into memory.  With a memory-mapped drive on a 
> virtual memory system, you can address the disk just like the memory was 
> physically present in RAM.

What I still can't get clear is why this approach did not (apparently) already
succeeded? Not all applications need very large databases - 1Gb is enough for
many, and memory is cheap - so, why we don't see such products? By the way,
I'm pretty sure that I saw something somehow similar to that - OODBMS in Ada95,
which was based on storage pools - in public domain, in 1995 or 1996 or 1997.
I remember that I downloaded that thing, it seemed interesting and I read and
even printed it. Now I tried to find it again, but so far failed - both on my
disks and in the Net (unfortunately I remember neither the author's name nor
exact title). There is still a chance that I'll find it in my archives on CDs.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Alexander Kopilovitch wrote:
> I'm pretty sure that I saw something somehow similar to that - OODBMS in Ada95,
> which was based on storage pools - in public domain, in 1995 or 1996 or 1997.
> I remember that I downloaded that thing, it seemed interesting and I read and
> even printed it. Now I tried to find it again, but so far failed - both on my
> disks and in the Net (unfortunately I remember neither the author's name nor
> exact title). There is still a chance that I'll find it in my archives on CDs.

The names have sort of changed, but not the reality.  There are several 
companies that provide object-oriented databases.  But the names to look 
for are CORBA (Common Object Request Broker Architecture and ORB (Object 
Request Broker).  If you create a CORBA object usually in IDL, then any 
ORB can be used to share access to that object.  Of course what you 
really want to do is to have an object database that you can link to 
through the ORB, and an Ada binding to CORBA to translate your IDL 
objects into Ada code.  (Even better would be a tool that abstracted 
objects from your Ada code and created IDL descriptions of them.)

I used to follow the CORBA work pretty closely, then I got involved 
heavily in projects that used Oracle and staying current in both Oracle 
and the CORBA world was too much.  (Along, of course, with Ada, and the 
computer hardware, and a couple of OSes, and...)

-- 
                                             Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <3F53B88E.7040405@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:

> As I said, most RDBMSs already have the ability to bypass the OS and 
> access disk drives directly.

They do ?  On what operating systems ?

On the one with which I am most familiar, device registers can only be
accessed from the innermost mode, and the code that does that is in a
device driver.  If the DBMS vendor should happen to provide their own
driver, installing it would make it part of the operating system.

Even ADABAS, the most contrary DBMS I have encountered for system manager
relations, was this way.  It insisted on calculating sectors and cylinders
on its own (back when there were such things), but it ended up calling the
operating system's device driver to read those bits into memory.  I think
there are many hardware architectures that would have a hard time delivering
the interrupts without going through the operating system interrupt dispatch.

> This is going one step further, and 
> "mapping" the disk drive into memory.  With a memory-mapped drive on a 
> virtual memory system, you can address the disk just like the memory was 
> physically present in RAM.

I know compilers that read source that way, relying upon the OS paging
in the data as appropriate.  But it is an individual performance/coding
tradeoff, not applied so universally as in Multics.

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Larry Kilgallen wrote:
> In article <3F53B88E.7040405@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
> 
> 
>>As I said, most RDBMSs already have the ability to bypass the OS and 
>>access disk drives directly.
 >
> They do ?  On what operating systems ?

I guess we have a different idea of what bypassing the OS means. I was 
thinking of for example, Oracle on Solaris.  You can go through the file 
system, bypass the file system and have Oracle manage a partition (raw 
mode), or give Oracle full control of the DISK device or devices.  But 
even then you are right, the DBMS uses the standard device drivers.  The 
difference is that if Oracle controls the entire disk, it can take 
control of the head positioning and other driver level functions.

> I know compilers that read source that way, relying upon the OS paging
> in the data as appropriate.  But it is an individual performance/coding
> tradeoff, not applied so universally as in Multics.

Well, in Multics it is universal because there is no user level 
distinction between main memory and disk storage.  It is all memory, and 
once you have linked to a segment, there are no further OS level 
commands to read and write it.  Well, technically not. You could break 
the link to the segment if you wanted, or were running out of segment 
descriptors in your process.  But breaking links was more likely to be a 
side effect of deleting the segment.

A bit of magic here.  If you were compiling a file that was part of an 
application the compiler would normally rename the old version of the 
code segment, not delete it.  That way if someone else--or you in a 
different process--were executing the old code, the segment was still 
there.  But you could then delete the old version to force users to use 
the new copy.  What if the segment you were compiling was part of the 
operating system?  Why should that be any different?  So you could 
modify Multics on the fly.

Occasionally with early versions of Multics, there were "flag days". 
There was an incompatable change to the OS, so at a particular point all 
the affected old segments were replaced with new versions.  But they 
soon stopped.  The reason that flag days happened was usually that 
someone had concluded that some data structure did not need an internal 
version number.  Pretty soon it became accepted wisdom on Multics that 
every OS data structure needed a version number, including structures 
that contained structures with version numbers.

-- 
                                          Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Larry Kilgallen wrote:
> 
>> In article <3F53B88E.7040405@attbi.com>, "Robert I. Eachus" 
>> <rieachus@attbi.com> writes:
>>> As I said, most RDBMSs already have the ability to bypass the OS and 
>>> access disk drives directly.
> 
>> They do ?  On what operating systems ?
> 
> I guess we have a different idea of what bypassing the OS means. I was 
> thinking of for example, Oracle on Solaris.  You can go through the file 
> system, bypass the file system and have Oracle manage a partition (raw 
> mode), or give Oracle full control of the DISK device or devices.  But 
> even then you are right, the DBMS uses the standard device drivers.  The 
> difference is that if Oracle controls the entire disk, it can take 
> control of the head positioning and other driver level functions.

INFORMIX and Sybase can work with the raw devices as well. This
was in fact, a problem in early Linux kernels, as they did not
support raw devices (only "block" devices where the disk blocks
are cached -- database engines prefer to do their own caching
techniques). Linus didn't understand the need for these raw
(unbuffered) devices in the beginning. I think Oracle was
probably the source of enlightening on that front. ;-)

So on the early Linux kernels, only file system based versions of
INFORMIX and Sybase databases were possible. Now I would expect
that has all changed.

You might wonder why buffered "block" devices are not good
enough for the purpose. I can't answer to the specifics, but
only that database engines are in a position to better manage
the cache based upon what they "know" needs to be done. Another
important reason to control caching details is that when a
transaction is committed, you need to guarantee that the
data is written to the disk media (or can be recovered if
the database is to be restarted at that point).

The database
must be recoverable at any given point anyhow, and this
usually requires fine grained control over physical writes
to the media. This aspect and performance means that the
engine must balance performance with reliability (persistance),
which are conflicting goals when using disk.

It is this last area where oodles of persistent fast memory
(instead of disk), can make a world of difference. In this
case persistence = memory performance, which of course is
where the win is. If disks became obsolete (one can hope),
then I could see that new database engine design (internals)
will become much different than what it is today.  Certainly,
many of the present compromises would be eliminated.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[olehjalmar kristensen - Sun Microsystems - Trondheim Norway]

>>>>> "WWGV" == Warren W Gay VE3WWG <ve3wwg@cogeco.ca> writes:

<snip>

    WWGV> You might wonder why buffered "block" devices are not good
    WWGV> enough for the purpose. I can't answer to the specifics, but
    WWGV> only that database engines are in a position to better manage
    WWGV> the cache based upon what they "know" needs to be done. Another
    WWGV> important reason to control caching details is that when a
    WWGV> transaction is committed, you need to guarantee that the
    WWGV> data is written to the disk media (or can be recovered if
    WWGV> the database is to be restarted at that point).

The cache management will typically be the same with both OS files and
raw devices. The main difference is as you say, that you have better
control over the raw device with respect to the layout of your tables,
so you may be able to optimize disk writes better.
Usually, you will be able to get higher bandwidth when running on a
raw device.
Most operating systems will allow you to wait until the data are
even if you are using the file system, so there is no difference with
respect to the durability of data.
All portable DBMS need to do their own cache management, so if you are
running on files, both the OS and the DBMS cache the same blocks,
thereby wasiting RAM. Also, the replacement strategies may be
conflicting, resulting in suboptimal performance.

    WWGV> The database
    WWGV> must be recoverable at any given point anyhow, and this
    WWGV> usually requires fine grained control over physical writes
    WWGV> to the media. This aspect and performance means that the
    WWGV> engine must balance performance with reliability (persistance),
    WWGV> which are conflicting goals when using disk.

    WWGV> It is this last area where oodles of persistent fast memory
    WWGV> (instead of disk), can make a world of difference. In this
    WWGV> case persistence = memory performance, which of course is
    WWGV> where the win is. If disks became obsolete (one can hope),
    WWGV> then I could see that new database engine design (internals)
    WWGV> will become much different than what it is today.  Certainly,
    WWGV> many of the present compromises would be eliminated.

    WWGV> -- 
    WWGV> Warren W. Gay VE3WWG
    WWGV> http://home.cogeco.ca/~ve3wwg

Possibly, but keep in mind that most current DBMS's are already CPU
bound when it comes to throughput. Fast disks and techniques like
group commit ensures that the log is rarely a bottleneck, and all you
need to recover is in the log. 
What you can get with large non-volatile memory is much lower latency
per transaction, that is, the response time for a single transaction
can be dramatically lower, even if the throughput in terms of TPS
stays the same.

And in case you were wondering if you could do away with the log, the
answer is yes, if you create some kind of multi-version system. But
you always need some way of keeping track of the history, so you can
roll back your changes in case a transaction decides to abort for some
reason. Actually, one may say that the log IS the database, all the
rest is there only to give faster access to the latest version.

----------------------------------------------------------------------

There can be only One.

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

I had written a detailed reply to this by my crappy
Netscape 7 had an error posting via NNTP, and threw
the whole reply away (major grumbling here about that!)
So this will be a very brief repeat of the essential
items ;-)

olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
>>>>>>"WWGV" == Warren W Gay VE3WWG <ve3wwg@cogeco.ca> writes:
>     WWGV> You might wonder why buffered "block" devices are not good
>     WWGV> enough for the purpose. I can't answer to the specifics, but
>     WWGV> only that database engines are in a position to better manage
>     WWGV> the cache based upon what they "know" needs to be done. Another
>     WWGV> important reason to control caching details is that when a
>     WWGV> transaction is committed, you need to guarantee that the
>     WWGV> data is written to the disk media (or can be recovered if
>     WWGV> the database is to be restarted at that point).
> 
> The cache management will typically be the same with both OS files and
> raw devices. The main difference is as you say, that you have better
> control over the raw device with respect to the layout of your tables,
> so you may be able to optimize disk writes better.

Control is where it is at. With block devices you can only:

1) leave it up to the O/S when to flush out writes
2) call sync(2) and have all dirty blocks written out
3) call fsync(3) and have all of your own blocks related
    to the file descriptor written out.

With a block device, a return from write(2) does not guarantee
that your data has been recorded on the magnetic media.

With a raw device, it should be a guarantee, with the following
exceptions:

1) Smart caching IDE like disk drives
2) EMC like subsystems with electronic cache


> Most operating systems will allow you to wait until the data are
> even if you are using the file system, so there is no difference with
> respect to the durability of data.

With UNIX, a return from write(2) is only a promise that
it will someday be written. No specific timeline is
guaranteed (see above). I don't expect it is much different
with win32 systems.

> All portable DBMS need to do their own cache management, so if you are
> running on files, both the OS and the DBMS cache the same blocks,
> thereby wasiting RAM. Also, the replacement strategies may be
> conflicting, resulting in suboptimal performance.

Yes, if the DBMS is expecting a raw device, and doing its own
caching, then using a block device (or file system file) is
asking for double-buffering. Very bad indeed for performance.

>     WWGV> The database
>     WWGV> must be recoverable at any given point anyhow, and this
>     WWGV> usually requires fine grained control over physical writes
>     WWGV> to the media. This aspect and performance means that the
>     WWGV> engine must balance performance with reliability (persistance),
>     WWGV> which are conflicting goals when using disk.
> 
>     WWGV> It is this last area where oodles of persistent fast memory
>     WWGV> (instead of disk), can make a world of difference. In this
>     WWGV> case persistence = memory performance, which of course is
>     WWGV> where the win is. If disks became obsolete (one can hope),
>     WWGV> then I could see that new database engine design (internals)
>     WWGV> will become much different than what it is today.  Certainly,
>     WWGV> many of the present compromises would be eliminated.
> 
>     WWGV> -- 
>     WWGV> Warren W. Gay VE3WWG
>     WWGV> http://home.cogeco.ca/~ve3wwg
> 
> Possibly, but keep in mind that most current DBMS's are already CPU
> bound when it comes to throughput. Fast disks and techniques like
> group commit ensures that the log is rarely a bottleneck, and all you
> need to recover is in the log. 

This is primarily where I disagree: I don't disagree that there
are fast disks and subsystems today. But keep in mind two things:

1) There are oodles of traditional slow disk based databases around
    still
2) The database engines were designed to handle the difficult case
    of #1.

Designing a new RDBMS would be much simpler, if you could ignore
the performance cost of putting data to the magnetic media. But
I would venture that all of the popular database vendor offerings
available today, were designed to get performance out of slow
disk I/O technologies.

Otherwise, they could just insist on
this new technology, and make life easier forthemselves from
a design and enhancement point of view.

> What you can get with large non-volatile memory is much lower latency
> per transaction, that is, the response time for a single transaction
> can be dramatically lower, even if the throughput in terms of TPS
> stays the same.

It also buys an opportunity to re-design the database engine,
because now you can eliminate:

  1) the cost of slow disk I/O
  2) the worries about data persistance (no disk
     write operations need to be issued)

This opens the doors to a whole new set of database engine
design dynamics.

> And in case you were wondering if you could do away with the log, the
> answer is yes, if you create some kind of multi-version system. But
> you always need some way of keeping track of the history, so you can
> roll back your changes in case a transaction decides to abort for some
> reason. Actually, one may say that the log IS the database, all the
> rest is there only to give faster access to the latest version.

Going to fast, persistent memory, opens a lot of doors indeed.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

olehjalmar kristensen - Sun Microsystems - Trondheim Norway wrote:
 > Actually, one may say that the log IS the database, all the
> rest is there only to give faster access to the latest version.

Very good.  I am used to calling it the transaction journal, but I am 
very leery of any DBMS whose state cannot be uniquely recovered from the 
journal, or and earlier save, and the journal entries since.  And yes, 
it has been true for at least 15 years that some databases will allow 
you to commit transactions by journalling them in persistant memory.

> There can be only One.

For databases, make that there can only be one version of the database 
at any point in time. ;-)

--
                                             Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <3F5559A4.8030507@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
> Larry Kilgallen wrote:
>> In article <3F53B88E.7040405@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
>> 
>> 
>>>As I said, most RDBMSs already have the ability to bypass the OS and 
>>>access disk drives directly.
>  >
>> They do ?  On what operating systems ?
> 
> I guess we have a different idea of what bypassing the OS means. I was 
> thinking of for example, Oracle on Solaris.  You can go through the file 
> system, bypass the file system and have Oracle manage a partition (raw 
> mode), or give Oracle full control of the DISK device or devices.  But 
> even then you are right, the DBMS uses the standard device drivers.  The 
> difference is that if Oracle controls the entire disk, it can take 
> control of the head positioning and other driver level functions.

You are correct about different terminology.  Eschewing a file system
from my frame of reference is something less drastic than bypassing
the whole operating system.  If I "own" a particular disk I can do
whatever I want with it, but using the disk read/write mechanisms
provided by the operating system (possibly including paging I/O).

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <Ln36b.22618$su.611773@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Control is where it is at. With block devices you can only:
> 
> 1) leave it up to the O/S when to flush out writes
> 2) call sync(2) and have all dirty blocks written out
> 3) call fsync(3) and have all of your own blocks related
>     to the file descriptor written out.

You seem to be presuming some Unix system.  Not all operating systems
have those limitations.

>> Most operating systems will allow you to wait until the data are
>> even if you are using the file system, so there is no difference with
>> respect to the durability of data.
> 
> With UNIX, a return from write(2) is only a promise that
> it will someday be written. No specific timeline is
> guaranteed (see above). I don't expect it is much different
> with win32 systems.

It is certainly quite different with OpenVMS.

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

http://home.cogeco.ca/~ve3wwg
"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:D1upWhxUuOLF@eisner.encompasserve.org...
> In article <Ln36b.22618$su.611773@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>
> > Control is where it is at. With block devices you can only:
> >
> > 1) leave it up to the O/S when to flush out writes
> > 2) call sync(2) and have all dirty blocks written out
> > 3) call fsync(3) and have all of your own blocks related
> >     to the file descriptor written out.
>
> You seem to be presuming some Unix system.  Not all operating systems
> have those limitations.

Duh, yes of course!  Is there any other operating system? ;-)

> >> Most operating systems will allow you to wait until the data are
> >> even if you are using the file system, so there is no difference with
> >> respect to the durability of data.
> >
> > With UNIX, a return from write(2) is only a promise that
> > it will someday be written. No specific timeline is
> > guaranteed (see above). I don't expect it is much different
> > with win32 systems.
>
> It is certainly quite different with OpenVMS.

Never heard of it ;-)

-- 
Warren W. Gay VE3WWG

Re: A Customer's Request For Open Source Software

[Larry Kilgallen]

In article <zCr6b.10761$Pa1.517650@read1.cgocable.net>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
> http://home.cogeco.ca/~ve3wwg
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message news:D1upWhxUuOLF@eisner.encompasserve.org...

>> It is certainly quite different with OpenVMS.
> 
> Never heard of it ;-)

Ok, we have discovered the root cause of your computing problem :-)

Re: A Customer's Request For Open Source Software

[Robert I. Eachus]

Dennis Lee Bieber wrote:

>         And yes, there is an Ada (Ada 80 level, I believe) linkage in the way 
> the processor handled varying sized memory blocks with protected access 
> and tasking. I believe the native developement environment was supposed 
> to be Ada.

I actually interviewed at Intel to work in the compiler group for the 
iapx432.  I guess I was fortunate in one sense in that the day I was 
interviewing Intel management made a killing decision about the chip.

The iapx432 implemented a capability architecture.  The software group 
noticed that standard way of modifying a capability node didn't work 
with the root node.  The only way to alter it was to create a new root 
table, then do a hardware reset.  The hardware people argued that since 
there was a workaround for this errata it didn't need to be fixed for 
the first shipping revision.  When I was at lunch with the compiler 
group, they were planning what to do next, because there was no future 
for the iapx432.  (Of course, what I should have done was to hand out 
some extra resumes.  People at lunch that day were involved in founding 
Rational and Verdix.)

How bad was that decision?  Pretty bad.  It meant that in practice any 
memory reference went through an extra level of indirection.  That did a 
pretty good job of killing performance.

There was also a joint venture by Siemens and Intel called Biin to 
create and sell (Ada) systems based on the iapx432 architecture.  When 
the 432 was bombing based on initial performance tests, Intel pulled the 
rug out from under Biin.  AFAIK, a company in the UK, High Integrity 
Systems was the only company to ever actually sell iapx432 based products.

-- 
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: A Customer's Request For Open Source Software

[Warren W. Gay VE3WWG]

David Holm wrote:

> Another issue I see is that even though it would be a great idea to write this in Ada (I'm
> thinking of stability here), there will be problems finding programmers who are able to work
> on it. One way of making it easier for people to help the project might be to write the backend
> in Ada with a module loader (dlopen/dlsym/dlclose would d othe trick). That way people can
> contribute to the project without knowing Ada and the backend can still be kept solid. By using
> some database system like berkley db for universal datastorage (by all modules) and implementing
> a recovery system in the backend you should be able to have a solid system even though it will
> be tainted by other languages.
> 
> //David Holm

OTOH, when the stuff you really care about is written in this strange
language called "Ada", you might have some interest in learning more
about it. Especially if you want to customize it and/or contribute. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A Customer's Request For Open Source Software

[jim hopper]

Have you all seen this:

http://www.redrocketconsortium.com/zbc/index.html


its in ada here is the intro:

In June of 2001 I started a project to build an application that would
allow small and midsize businesses the same level of inventory, order
entry, sales tracking and accounting functionality as would be expected
from commercial applications. I wanted it Open Source (GPL,
specifically), cross-platform, and international. I wanted to make it
possible for the little guy who can't afford the $60,000 for a
commercial application and the yearly annual license fees to bring his
business into the modern age

Re: A Customer's Request For Open Source Software

[Ludovic Brenta]

jim hopper <hopperj@macconnect.com> writes:

> Have you all seen this:
> 
> http://www.redrocketconsortium.com/zbc/index.html

Yes, I even joined the project, but unfortunately thate hasn't been
any activity on it for a more than a year now.

-- 
Ludovic Brenta.

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Ludovic Brenta wrote:
> jim hopper <hopperj@macconnect.com> writes:
> 
>> Have you all seen this:
>> 
>> http://www.redrocketconsortium.com/zbc/index.html
> 
> Yes, I even joined the project, but unfortunately thate hasn't been
> any activity on it for a more than a year now.

Well it is GPL so ask the author if you may continue on it.
-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Stephane Richard wrote:
> Well I did a commercial Payroll system in my career...I know accounting,
> inventory management, and just about everything in between, I've dont a lot
> of industry specific application development.  and I'm thinking of doign an
> OpenSource project :-)....that message on the group made me realize how much
> it was lacking, but I agree, we need to replace such things as MYOB
> Accounting or atleast have an equivalent of.  We need business management
> software, stats and probabilities, trend analysis, financial advisory tools,
> and everything else that can be used in a business.  so I'm game.  Also done
> a Point of Sale commercial application which integrated accounting behind
> the scene.

Might want to have a look at this site:

   http://www.redrocketconsortium.com/zbc/


-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Marin David Condic wrote:
>   You've pretty much gotten by with off-the-shelf software. Was it tough 
> to find everything you needed in the open-source world?
> Yeah, there are some things that are tough to find, like payroll 
> software. We found something, and it works well. But the developers need 
> to start writing the real-world applications people need to run a 
> business...engineering, art and design tools, that kind of 
> stuff...They're all trying to build servers that already exist and do a 
> whole bunch of stuff that's already out there...I think there's a lot of 
> room to not just create an alternative to Microsoft but really take the 
> next step and do something new.

Amen!


-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: A Customer's Request For Open Source Software

[Chad R. Meiners]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbkjgjn.2kg.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Marin David Condic wrote:
> >   You've pretty much gotten by with off-the-shelf software. Was it tough
> > to find everything you needed in the open-source world?
> > Yeah, there are some things that are tough to find, like payroll
> > software. We found something, and it works well. But the developers need
> > to start writing the real-world applications people need to run a
> > business...engineering, art and design tools, that kind of
> > stuff...They're all trying to build servers that already exist and do a
> > whole bunch of stuff that's already out there...I think there's a lot of
> > room to not just create an alternative to Microsoft but really take the
> > next step and do something new.
>
> Amen!
>
Hazah!

Re: A Customer's Request For Open Source Software

[Preben Randhol]

Chad R. Meiners wrote:
> 
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
>> Amen!
>>
> Hazah!

Just to make it clear nothing religious was meant by my comment. :-)

-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)