Just a quick repply, since i have not a lot of time right now, ...
First, i am a user like you, i have absolutely no relation to inria, apart
that i am a ocaml user, so things i say here are only my opinion, and to add
fuel to the discution, ...
> Also, isn't "information hiding" part of the purpose of .cmi files? What I am
> suggesting might be viewed as an stronger type of .cmi file ... with REAL
> "implementation hiding". :-)
Well i think not, the .cmi files are there to not to hide information, but to
give the information needed by other modules.
> > This surely is the philosophy of those who want to make more money using all
> > the free software that other people have developped for free.
>
> I brought it up precisely because I thought "Maybe this is an idea that occurs
> to me merely *because* I work in a commercial engineering environment? If so,
> then it might not occur to people who are more academically oriented."
>
> Your response shows the virtue of my email: you were motivated to respond.
The above lines where a bit provocative, and meant as humor, at elast
partwise, ...
> (I wanted to post on this topic a couple of months ago ... but since I know
> the high skill level of the people on this list I had to "work myself up to
> it".)
>
> > Anyway, i personnaly are not at all in favor for a scheme such as what you
> > propose.
>
> Ivan Galamian, violin instructor and long time head of the Julliard string
> department said, "A particular technique might go out of style, but the
> ability to do it never goes out of style."
Well, but if you hide the techniques, so that nobody can do it, and people who
want ot are not permitted so by some patent and other such stuff, then the
technique may be lost forever, if the company holding the patent says so.
> The ability to manage encrypted byte code, even if provided, might not be
> used. But the ability to do so would not go out of style.
>
> Today, even when companies "work together" and use each other's chips, models,
> and other circuitry, they distribute encrypted SPICE models or blackbox driver
> specifications called "IBIS".
Yes, as long as they can make money for it, and i don't think this approach as
had much success lately in the software industry, but then now that linux is
gaining acceptance, and microsoft is going to be split, maybe we will have
more chance on this.
But then, remember also how difficult it is to get a cheap ppc motherboard to
build a system, and you will see that even with hardware there is a problem in
this in that you limit sharing to those with money.
> We're stuck with encryption. Worse, with multiple incompatible encryption. :-(
>
> > But then i am a Debian GNU/Linux developper and my opinion might be a bit
> > biased on this.
>
> I know MANY people inside IBM who are actively lobbying for much more use of
> Linux ... as well as general support for the Open Source movement (i.e. more
> than in words). While I personally use FreeBSD at home, I would love to see
> Linux and GNU use increase. At work. In homes. Everywhere.
>
> The problem is that many upper level people who control the money often
> believe that the Open Source movement is anti-business. (Hint, hint:-)
This is begining to change, in truth, the seed has been planted long ago, and
the first fruit where the open sourcing of the netscape code 2 yaer ago.
> > Still, please remmeber a few things :
>
> > 1) Reverse engineering is legal in many european countries.
>
> I did not know that.
There was some talk to change that though.
> Is "making it hard to reverse engineer" illegal? :-)
Don't think so, ...
> > 2) Encryption is illegal in many countries, or at least export restricted, i
> > think france changed this some time ago, but if not, it would not be
> > possible for inria to distribute such a product.
>
> I believe the US has just lightened up on some of the restrictions.
lightened some but not enough i think, at least Debian is not sufficiently
convinced by it to move encryption back to the main server in US from free
country where it is now, ...
> ... But the answer would be: Don't distribute the actual encryptiong directly
> with O'Caml, just the hooks. Have the actual files containing the encryption
> available from non-restricted sites just as FreeBSD does. (I'd guess that
> Linux does something similar?:-)
Some argue that licence wise it is almost the same, ...
> > 3) Well this would be a big step back in what the has been achieved in
> > freedom of software and sharing of ressources.
>
> I would interpret the idea as "allowing people do have control over what they
> wish to share and what they wish to keep private."
Even the GPL allow you to keep secrets, the only unethical thing is that you
are not permitted to hold secret from your customer, but then would you buy a
car which you don't would have the right to open the hood ?
> > Caml has a too small community today that you can permit to hamper it by
> > being overly protectionist. And despite what you may think, it would be more
> > important fro ocaml to be adopted by the "free" software community (that is
> > all the linux/*bsd/whatever users), than by the "non-free" one (that is the
> > people you have in mind).
>
> I believe you are correct. However, the options are not mutually exclusive
> for the following reasons:
Surely from what you described is happening at IBM, it is so, ...
>
> a) I am NOT saying "Everything should be encrypted". Absolutely not. I am
> saying "Consider what might need to be done technically to make such a
> thing possible."
More technical response will be given be others than me, some have already, i
just wanted to make you feel what would be reaction of the "free" (in the
large sense, i don't make politics) software community would be to such a
move.
> b) "Aiding the Open Source movement" is not the same thing as "restricting
> business possibilies".
:)))
> c) If O'Caml is good for Open Source, it is certainly good for business. Any
> territory gained by O'Caml in business is not taken from Open Source.
>
> Are there specific ways and reasons how and why adding such possibilities
> would hurt the Open Source movement? I am especially interested in technical
> problems.
Not, but it may hurt the ocaml perception in open source ? i don't know,
really, i think the main problem is that the inria guys want to restrict code
splitting, and maybe have not much time to devote to it, but as said i have no
idea about it, they will surely respond for themself, if they feel it is
needed.
> > Since the former surely will contain all the programmers in formation who
> > will later become programmers and decider of the second group. Also
> > remember that many big companies are going for the "free" movement, like IBM
> > and SGI for example.
>
> I've heard words and slogans ... and some larger plans. But the real interest
> is in the popular movement inside IBM. In fact "the deciders" are most often
> Myer-Briggs "ISTJ" types who think "long term" means "next month". :-/
Sure, ... but in the long term, they will be replaced by younger people whgo
believe in it, and as "open source/free" stuff gains more acceptance they will
look at it also, ...
> In fact I've seen people with ideas desparately avoid becoming managers, even
> skipping meetings to establish a reputation as non-manager material. :-)
> > 4) Is there really a need for this, would the complexity of doing so not
> > outweigh the benefit ?
>
> I don't know. I am admittedly the only one that I know of who has asked the
> question.
>
> But how hard would it be?
> a) If it's easy, then why not do it?
> b) If it's hard, does the difficulty point out any technical flaws in O'Caml?
> c) If a) or b), then might the answer be "do it in either case"?
>
> :-)
>
> > 5) In particluar there is a theory that says that security though peer
> > review permitted by open source developpment model is higher than security
> > trough hiding which you are suggesting. Or else you will find yourself with
> > a microsoftian type of product (buggy, hidden, expensive, ...), which i
> > doubt is something the ocaml community wish to be associated with.
>
> I believe you are likely correct.
>
> > 6) If someone is good enough to reverse engineer your ocaml bytecode, i
> > think he is good enough also to reverse engineer your encrypted stuff, or at
> > least to find holes in the security of it.
>
> I just "reverse engineered" emacs byte code by doing
> <control> x <control> r ~/.emacs.elc ... and easily viewed actual lisp code.
>
> That's how easy it was. That's the kind of thing I was thinking about
> avoiding.
I think it is not as easy in the ocaml case, ...
but more competent people will or have responded already to you on this,
> > 7) If you think the bytecode security is not enough for you, just use native
> > code, it is faster anyway, and i doubt you will have less hideance in this
> > than writting in C or C++, ...
>
> Yes, that is a possibility.
>
> But what if someone wants to develop a special mathematical toolbox and
> provide it via byte code? The byte code is platform independent ... but in
> this case you want it somewhat hidden.
All in all, i don't think that reverse engineering bytecode would be more easy
than reverse engineering assembler, especially since existing reverse
enginneering experience is more widespread in assembleur than in ocaml
bytecode, ...
> After all, isn't that the purpose of .cmi files? Hiding information?
>
> What I am suggesting could be viewed as an stronger type of .cmi file ... with
> REAL "implementation hiding". :-)
>
> If you don't agree with that, could you tell me why one type of hiding is good
> and the other bad? (The question is rhetorical, of course.)
I don't believe that the .cmi is hiding info, in my sense it is more showing
info, but then i am no expert of the content of it. maybe it does both,
depending how you sees it.
> > 8) Finally, if all the above don't convince you, Ocaml is now available
> > under a free license, and thus you are free to implement such a scheme, if
> > you want so. This may not be the best fro the ocaml community, but still you
> > can do it.
>
> Ummmm... This suggestion troubles me more than any of the rest. :-(
> Leaving some things up to users is good, but *not* everything.
Well, another approach is you pay people to work with inria to do it. :)))
> Consider what happened with Scheme. Here is a quote from a news post by
> Olin Shivers:
>
> Programming in Scheme is an extremely unportable task if you do anything
> serious. Scheme is much less portable than, say, tcl or C. So we are
> unable to build on each other's work, but must instead keep re-inventing
> the wheel.
>
> If you *union* up the technology and features in all the Scheme
> implementations out there, you have an amazing tool. But each
> implementation is different, and all lack some important features. You
> don't hear people saying, "I wrote my program in SGI's implementation of C
> -- I can't run it on your Linux box because the struct declarations are
> different, and Linux's C implementation doesn't have do-while loops. Also,
> the interface the Unix write() function is different, so I'd have to
> rewrite all the I/O."
>
> I couldn't solve my problem in Scheme. And I am tolerably well acquainted
> with the language and its implementations. I could solve my problem with
> tcl. The server we were running had a tcl interpreter linked in, and the
> tcl system had hooks to an RDBM interface. Took an evening.
>
> As long as this situation persists, the Scheme community can snipe about
> what a lousy, poorly-designed language tcl is, but they aren't in a
> position to offer a credible alternative. So it is just empty flaming. So
> why post?
>
> Go fix the problem.
> -- Olin Shivers
>
> I personally *am* a strong believer in "reinventing the wheel" ... because it
> makes me good at reinventing. :-) But then I compare against standard
> prefix stuff, re-work the code, and do it also the "right" way.
I think reinventing the wheel (a part fro teaching and self teaching prupose)
is what hurt the software industry most, but then it makes for lot of job
oportunity for all those programmers out there, ... :)))
> > As a personal note, if it is not confidential, what are the personal
> > interrest that make you ask yourself this kind of questions, are you aware
> > of a particular company which ask this kind of question when faced with
> > ocaml ?
>
> It's not confidential. I'm the only one I know who has asked the question.
> In fact, I've not yet implemented *any* actual solutions with it here at IBM
> in O'Caml. I've tried to be sensitive to the concerns of my colleagues and
> hold back on some change for awhile.
>
> (I am the sort of person who always helped everyone else with their homework
> and forgot to do my own.:-)
>
>
> The problems I've run into have included things such as:
>
> a) Public relations about O'Caml, (informing people around me gains me more
> freedom to act in the future.) I've had to hold back and limit myself to
> reading and informing ... I think I've built enough trust to start using it
> soon.
>
> b) Compiling problems. I've had very poor results with local versions of GNU
> GCC on our AIX/RS6000 systems. Can't link to various libraries, problems
> with shared libraries, problems with compiler crashes, problems with
> crashes of programs compiled with GCC, etc, etc. (It works great on
> FreeBSD.)
>
> c) Whenever I recompile *anything* ... I recompile *everything*, including
> almost all supporting libraries. I dread it. :-(
Use a good packaging system, ... :)))
> d) Lately I've even had some problems compiling with using our own compiler on
> my system. I think I need to reinstall or upgrade the OS.
See above, ...
> > And i hope this few remarks can contribute to this discution, please don't
> > take them negatively, if i was unexact or maybe offending somewhere.
>
> I actually have a GENERAL PURPOSE 2-step problem solving process which can be
> used to solve ANY problem. The advantage is that the second step is trivial,
> and the first step applies to ALL problems. The steps are, 1) learn
> everything in the universe, 2) solve problem.
>
> I'm still working on the first step. :-)
Good work then, i hope this has given you something to think about, ...
Friendly,
Svne LUTHER
This archive was generated by hypermail 2b29 : Fri Jun 09 2000 - 19:48:39 MET DST