9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Announce: standalone libixp
Date: Tue,  3 Jul 2007 17:10:59 +0200	[thread overview]
Message-ID: <20070703151059.GA20385@nibiru.local> (raw)
In-Reply-To: <1183434625.10665.77.camel@linux.site>

* Roman Shaposhnik <rvs@sun.com> wrote:

<snip>

> > A petition ? Addressed to whom ? 
> 
>   Well, obviously to all sane developers of the world 

A petition is useful for addressing some issue to some group of 
deciding people (ie. some council). What you need is probably 
some public appeal.

> [hm... should I start using smilies now or is it too late?]

obviously ;-O


<snip>

> > Starts w/ typical, stupid U$ flaming: $what_I_hate is like communism.
> 
> I think the level of your insight into how the communism argument
> went shows just how much insight you got into the rest of what I 
> have written. Now, for the record: I grew up in the USSR and I moved to
> US in my 20s. I have benefited from both systems tremendously, but I 
> also have seen their major drawbacks. 

You played around with typical "communism is bad, and $foo is communism" 
argumentation which is quite typical for what we (@ .de) experience from 
the US (this doesn't mean every US citizen thinks that way, but it's the 
outside presentation of this country, maybe heavily depending on the
current administration). It's just like if we would (in fact many people 
do) call things we hate "facism" (altough we, unlinke .it, never had
large facist movements, insead two pseudo-socialist experiments). 
If you know both systems, you shold not argument in such stupid ways. 
You should be confident to do better ;-P

I don't see the parallels between communistic society and the concept
of dynamic linking, neither on the absolute power of multi level council
goverment, nor an stricly top-down (or V-model based) economy controlling.
>From that view DNS and IP space allocation practises are more communistic
than dynamic linking. 

The only valid point is the radical equilibrium activities which soon
end in the perverted view that evryone has to be equal. Many people seem
to see communism as an symbol for total equality, but that's really not
the concept of communism, just an effect of an absolute communism went
out of control. Such effects normally happen if a few people who are not 
(enough) bound/related to the great majority of the citizens get too much 
power. Christianity showed such bad effects about 2k years before the 
communism (no, in fact, Stalinism) came up. BTW: most people probably 
don't know that on the American contentinen there already was an working
society model which was quite close to Communism, which had been wiped 
out by European (fundamentalistic Christian) invasors in an several 
years taking genocide.

Maybe you didn't notice: your argumentation goes much in an radical
direction, where concepts you personally don't like should be wiped out 
in similar ways as certain religious groups wiped out "incompatible"
philosopies in big "inquisitions". ;-P

We shouldn't act religiously on technical discussions.

To get back to the topic: dynamic linking. 
You raised some good points, where it doesn't work well. Of course
each concept has it's constraints. For my situations it works well,
maybe for your's not. Evryone should have the freedom to choose
individually. I don't think anybody has the right to evangelize or
even dictate his personal view to others.

> I had to face reality. 

My reality is different from yours. Everyone has its own. 
Face that !

For my libixp branch, we both have the choice. I will use dynamic,
you'll use static linking. I don't see any reason for ranting 
against each other. 

One of the major advantages of OSS is: evryone can adopt the 
software for his personal needs. There's no vendor who dictates
how to use the software.

> The point of the title for my blog article was to relate a 
> frustration when something that is supposed to be very beneficial 
> doesn't work because reality has not been taken into account 

I often felt that way, too. Maybe I also overreacted the same
way you did (hard to say it by myself). It okay to canalize the
bad emotions for the moments, but it's not constructive for 
longer terms. IMHO, the only good way is simply to do better
and show the world what you did and why you did it. Of course
many of your ideas can't be done due limited resources. Well,
that's life ;-o

> (hey! I'm still angry at good old SU for showing me want universal 
> health care and free top notch education can do for a country and 
> then collapsing!). 

In .de we have similar problems (of course far not as bad as it 
had been in SU or GDR). The major problem is the inherent conflict 
between marked-based economoy (which IMHO grants the most personal 
freedom) and the concept of social wellfare. Both concepts cannot 
be merged within one system, since they conflict each other.
But IMHO both concepts are necessary.

So my idea is to do both things separately. The component of social
wellfare is to give everyone enough money so he can afford evthing
that's needed for life, including a home, food, clothes, communication,
education, healtcare, etc. It's not very hard to calculate an value
for some (well-defined) group of people within some region on the
current marked prices. Simply give the people that value as an 
unconditional income, just because they're living Human. The really
most of all "social systems" are immediately unnecessar at that point.
The risk of poverty is immediately eliminated (of course people who
are too sick to care for themselves are an very special and rare case,
they'll need further assistance nevertheless). Additionally we need
a few marked regulations for transparencey and reliability of some
fundamental economic good, ie. insurance contracts w/o pitfalls, etc.

Once we have ensured the constraint that evryone can afford all things
important for living, we can give almost evrything to the marked. 
(leaves only a few implementation details to discuss). Most aspects
of what's currently called basic social care (ie. playschool) can 
be done by private institutions. Non-profit ones could play a big
role here.


Okay, the whole political debate goes far, far offtopic for this list. 
I really like to continue this discussion, so I'll offer opening
a new list for that topic.

> > Next logic step would be declaring dynamic linking "unamerican".
> > Well, those ideas are really irrelevant to me. 
> 
> Apparently, they are. Otherwise you wouldn't have had such a strong
> and emotional reaction. 

Not really. My reaction is on that redical ranting.

> > * Broken compiler: I don't know which compiler you're talkig about.
> 
> Sun Studio, Intel and g++. They all suffered greatly from it at one
> point or another. Did you know that chances are you WILL NOT be able
> to run a C++ program on a Red Hat 4 if you compiled it on Red Hat 3? 

Okay, my primary reference toolchain is GNU, I never had to cope w/ RH
and binary compatibility between different distos never had been an 
issue for me. There're many other points which break binary compat,
ie. different calling conventions, heavy CPU optimizations, etc.

But there are techniques for working around them, static linking is 
just one of them. I personally prefer chroot or VZ's.

> >   Never ever seen such trouble in recent 15 years.
>  
> Apparently you haven't been looking hard enough. But then again, some
> people never seem to have any problems with Microsoft Windows security
> model either.

Yes. Experiences are always personal. Everyone should have the 
freedom to decide on his personal experiences and views.

> > An clean namespace separation would have done the trick.
> 
> Of course it wouldn't. Please educate yourself on library versioning
> and what a mess GNU made out of it. The original Sun's design was
> pretty misguided but at least it worked in the world of a single OS.

I'm not talking about .so versioning. This may be working on ABI
changes, where API keeps 100% intact, but makes package managing 
tricky. Instead I'm talking about separating different library 
evolution completely. For example I call gtk-2.x an completely 
different package than gtk-1.x. (they just share the great philophy
and so are quite similar, but NOT equal, and NOT compatible).
Maybe you'd like to have a look at an recent debate @ Gentoo. 
The Gentoo folks don't follow my philosophy (instead ranted 
against me) and so have to cope with great trickyness.

To get back to libixp: 
I indent to give my branch an different name, ie. libixp2 or
libmixp ("m" for metux ;)). So we won't conflict each other :)

> > * Bug vs. feature: with clean development methods, it's really 
> >   clear what some module should do. First design, then implement
> >   and test. If you just hack up something w/o any clear spec,
> >   you can easily run into trouble. In that case: your fault.
> 
> Wow! I have seen maybe 3 engineers in my life who could pull this
> off (has Ken ever needed unit testing). The rest of us are hopeless.
> If you are trying to tell me you are the 4th one -- I would have
> to wait till you prove it with something real. Before that happens
> the statement above is beyond naive. Its dangerously naive.

No, I don't think it's naive. It's very strict, maybe some bit
radical or fundamentalistic. Of course such concepts are teached
for decades, but in practise almost nobody cares about them. 
That's not the fault of the concept, but the people who ignore it.
In other industries, such constraints are fundamental standard,
ie. building constructions or automotive couldn't live w/o that
(or many many people would be killed by buggy systems).

> > * Commercial or half-Commercial stuff like OO: I'm neither resposible 
> >   for their unability to produce clean code, nor do I care. 
> 
> An important question is -- are you capable of it?

Assuming I had enough manpower: yes.
But I can't afford investing several man-month (and maybe also
hire some more devs) in such an project. And I don't have any
reasonable personal interest in it. If there was an investor 
with an adequate budget, we could talk about it ;-)

> > If I, for some reason get interested in such an package, ie. Mozilla, 
> > I just break off my own branch and cleanup things as I feel its right.
> > This includes kicking off all these bundled 3rd-party libs.
> 
> Well, I try not to be cynical. May be you are the 4th one. I wish you
> luck. You had all the right intentions when this thread got started. 

Of course this project runs with an quite low prority. I've got several
commerical projects (have to live from something ;-)) and other interests
(outside IT) on higher priority. So it will take some time to for 
useful results ;-O

> I also wish that you spend a bit of time looking around and learning
> from the mistakes others made. 

Well, I'm now coding for about 15yrs, which give me some experiences. 
And I read several books on development methods (Wirth + Moessenboeck
are always worth a look). So I think I'm confident enough for my
projects :)

> But then again, reinventing the wheel
> is always much more fun compared to listening to the old geezers.

Reinventing the wheel ? Where exactly ?


> This is pretty much the only place where whenever people tell you 
> that you're making a mistake -- chances are: you ARE making a mistake. 
> It is your choice to either listen and learn something or disregard 
> it all and move on.

"mistakes" are often subjetive. 
For dynamic linking, I don't think is generally an mistake. It just
one concept with its pros and cons. Same for static linking. 
Good libraries should support both sides, so evryone is free to 
choose for himself.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------


  parent reply	other threads:[~2007-07-03 15:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-30 15:38 Enrico Weigelt
2007-06-30 16:47 ` Kris Maglione
2007-06-30 16:50   ` Kris Maglione
2007-06-30 17:30   ` Enrico Weigelt
2007-06-30 17:41     ` Kris Maglione
2007-07-01 12:50       ` Enrico Weigelt
2007-07-01 16:15         ` Iruata Souza
2007-07-01 10:11     ` Charles Forsyth
     [not found]     ` <dba1bd02516b1cfbf4119d7c567ec8e9@terzarima.net>
2007-07-01 12:42       ` Enrico Weigelt
2007-06-30 16:47 ` Uriel
2007-07-01 23:22   ` Roman Shaposhnik
2007-07-02  0:45     ` Enrico Weigelt
2007-07-03  3:50       ` Roman Shaposhnik
2007-07-03  4:09         ` Kris Maglione
2007-07-03 15:10         ` Enrico Weigelt [this message]
2007-07-03 19:45           ` Federico Benavento
2007-07-03 20:31           ` Jonathan Cast
2007-07-03 21:14             ` Wes Kussmaul
2007-07-03 21:51           ` Martin Neubauer
2007-07-03 23:16             ` Enrico Weigelt
2007-07-04  3:36               ` Iruata Souza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070703151059.GA20385@nibiru.local \
    --to=weigelt@metux.de \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).