Subject: Overgeneralization [was Re: [hackers-il] usage of patented and closed source products in courses.]

From: "Tzahi Fadida" <[email-masked]>
Date: Thu, 25 Dec 2003 02:11:16 +0200

> -----Original Message-----
> From: Shlomi Fish [mailto:[email-masked]]
> Sent: Thursday, December 25, 2003 12:50 AM
> To: Hackers-IL
> Subject: Overgeneralization [was Re: [hackers-il] usage of patented 
> and closed source products in courses.]
> 
> 
> 
> Hi Tzahi and all!
> 
> Tzahi, judging from your answers you seem to be very frustrated about this
> course. And, from my impression based on your description, you have every
> right to. However, you seem to have started this argument with some
> overgeneralizations:
> 
> 1. Use of proprietary software in Academic courses is bad.
> 
> 2. Teaching of patented technologies is bad.

well, i think that in most places i added "my opinion" because as you
said, i will have a hard time to make it work for every case.
and i did not mean that we should stop using matlab today, but in an
academic world we should aspire to do so.
I say this because in my opinion a university is an idealistic creature
that looks for ways to increase scientific knowledge for the benefit
of the community in 99% of the time.
however since we live in israel + in the real world, i would accept
that the institution will allow himself to patent some of the work so
they could fund further research, but i think its important not
to loose track of the main theme of the university.

> 
> Both of them may or may not be valid depending on the case, but
> over-generalizing them is bad. In general my belief is that:
> 
> 1. A course should teach using mature, well-proven tools, whether open
> source or (with a lesser preference) otherwise. Open source programs are
> not a panacea. A sub-standard open source program can waste a lot of times
> for the students, and for the other staff, while a high-quality
> proprietary solution will just work and give them what they need.

agreed. just to remind that in my case the course application is 
experimental.

> 
> I can testify from my experience, that in EE Lab 1, my partner and I had
> to work against a pre-configured circuit of electrical components
> (hardware not software) that we had to analyze. In the middle of the
> experiment, the case broke down and no one was able to fix it. To get the
> score for this experiment we had to come another time and spend some good
> 3 or 4 hours doing the experiment again.
> 
> So, bugs, whether in software or real-world, always cost time. No one has
> time to debug bugs in open source software in the context of Academic
> studies. So, I think a course should prefer the solution that is known to
> work best.

right again. and to remind, they are testing the application on us and
debugging it on our expense.

> 
> 2. Regarding the course's staff and its treatment, I think it is very bad
> that they treat you this way. By all means, answering "we are under NDA so
> we can't tell you", etc. defies the purpose of Academic studies, in which
> the staff aims to educate the students as much as possible, rather than
> hide information from them.
> 
> If this technology is problematic in this regard, then they should have
> avoided and teach you something less proprietary.
> 
> 3. Teaching Patented technologies sometimes cannot be avoided if the
> university wishes to stay on the cutting edge.

agreed, but aspire to lower this as much as it can and not take it for
granted.

> 
> 4. Regarding your point that because I don't have access to Excel's
> source, I can't tell what its algorithms are. As far as Excel is
> concerned, I can, because programming spreadsheets is well known with many
> partial open source implementations. Even, if I don't know how a feature
> works, I still know the formulas behind it (they are in the help file),
> and can still do it by hand.
> 
> Most able programmers can tell how to write most programs based on their
> behaviour. The source code itself is useful for modifying the program when
> the need arises, but is otherwise not necessarily a pre-requisite for
> duplicating its functionality. (nor is it always very helpful if you need
> to know how it works).
> 
> Like I said, in a course that involves using a tool, you usually don't
> expect the students to fix bugs, much less add features to the tool. (you
> can't do it with physical tools, so why should you with software). Unless
> of course, the entire purpose of the course is to extend this tool.

maybe in bsc, but when in advanced courses you are expected to think
of ways to generate experiments and create new models you need
to know of functional side affects if there are any and perfomance,
and how a certain algorithm will behave if you use a built in command.
I agree that in simple courses there is no need for that because they
spoon feed us.

> 
> 
> Regards,
> 
> 	Shlomi Fish
> 
> 
> 
> 
> ----------------------------------------------------------------------
> Shlomi Fish        [email-masked]
> Home Page:         http://t2.technion.ac.il/~shlomif/
> 
> An apple a day will keep a doctor away. Two apples a day will keep two
> doctors away.
> 
> 	Falk Fish
> 
> To unsubscribe from this group, send an email to:
> [email-masked]
> 
>  
> 
> Yahoo! Groups Links
> 
> To visit your group on the web, go to:
>  http://groups.yahoo.com/group/hackers-il/
> 
> To unsubscribe from this group, send an email to:
>  [email-masked]
> 
> Your use of Yahoo! Groups is subject to:
>  http://docs.yahoo.com/info/terms/ 
> 
> 
>

---

From: Shlomi Fish <[email-masked]>
Date: Thu, 25 Dec 2003 02:36:16 +0200 (IST)

Hi Tzahi!

It's great that we agree to agree. How do you say "heganu le'emeq
hashaveh" in English? "Reached a mutual agreement"?

> academic world we should aspire to do so.

Hell, I think everyone should aspire to stop using any proprietary
software. But not everyone has time to work on solving all the problems
that are solved by proprietary solutions. Some open source solutions are
up to par with their proprietary equivalents, or many times even better.
Others still have a long way to go.

If we take the database field for example: the most feature-full database
is Oracle, which is proprietary and costs quite a bit. Furthermore, Oracle
Corp. has much more man-power at its disposal than the equivalent open
source projects have individually. (and naturally, these people work full
time there and are getting paid to improve the product). Oracle costs
quite a bit, (don't recall the price, but it can be easily verified), but
a version can download a version for development for free, and would just
need to pay for a license to deploy it.

Now, generally we can assume that the cost of licensing a database product
would be relatively small to the development cost and general TCO, so many
customers will be willing to pay for it. So, Oracle still gets many new
licensees, and can continue the development so far, keeping ahead of the
competition.

That does not mean the functionality provided by the open source database
products is useless, just that there is a place for a high-quality
proprietary solution.

This is also the case for Matlab, (at least for now) and for Excel.

> of the community in 99% of the time.

You are right about that. In a way. I support fully privatized education,
where even K12 schools are private. (either individual schools or school
networks). What will be the behaviour of universities in such a scheme
remains to be seen, but they should still not be companies proper, or else
they won't be called universities.

This comment has the possibility of being a little flame-bait. Let's not
start a "privatized education - good or bad?" discussion here. It's
off-topic.

> to loose track of the main theme of the university.

Right.

> agreed. just to remind that in my case the course application is

Right, which means it has no place in it.

> debugging it on our expense.

Right.

> agreed, but aspire to lower this as much as it can and not take it for

Right.

> I agree that in simple courses there is no need for that because they

You are right here. That's where open source can really shine.

	Falk Fish