Gentlemen,
please calm down and let us deal with this on the facts. It was definetely
not my intention to start another flamewar when I did that announcement.
Tomi Manninen wrote:
>
> On Wed, 26 Apr 2000, Jan Wasserbauer wrote:
>
> > I have to support Jens since I think nex-Ax25 support is much better (and
> > what is done so far greatly proves that).
> >
> > Have in mind we're talking about Ax25 for 2.5/2.6 kernels .. (or patched
> > 2.2/2.4 of course) so compatibility issues are not that important.
>
> I wasn't talking about compatibility issues (which are important also of
> course) or which implementation is better. I was talking about attitudes.
> [...]
Iīm sorry if my matter-of-fact-attitude has hurt somebody. I am currently in
a local group which sets very high high standards. Matthias successfully
tried to fullfill these standards and contributed a lot of interesting stuff,
not only in the linux/ax25 area as long as his spare time permitted it. I
took over, but people still tell me thereīs a lot of work to do, and I know
they are right.
I am not going to point out again why KISS is suboptimal when CSMA is used
or why the unix philosophy is to have many little tools rather than one large
tool. I assume that people know, and that they know the neccessity to correct
this. If that means rewriting some or most code, you have to eat that sour
apple, thatīs what I was told my whole life long.
Note that I once did the same mistakes when coding AIRS (see
http://www.afthd.tu-darmstadt.de/~dg1kjd/airs/). I realized that it was
crap what I did and merily dropped it. Of cause I also spent a lot of time
on it, but I know that this time is was not lost since I learned a lot. For
example I accepted that this "channel-access thing" affects more than low-level
driver interfaces. It affects the whole LAPB state machine structure. Thatīs
why Matīs (mostly) rewrite was the right thing (tm) to do.
Finally, we are doing this for fun and education, arenīt we?
> > Some developers talk, some actually develop something .. :)
> > (just my opinion about new-ax25 discussion ..
> > don't take personaly (anyone))
>
> Yeah, right. And some people think they know all the answers and never
> need any advice/comments/suggestions/input.
I definetely do not think I know the answers to everything. In fact I love
to say "I know that I know nothing". Iīm studying ee, not cs, so there are
surely a lot people who have more knowledge and better ideas than me. Thatīs
why I did that posting revealing my intentions. If somebody has other ideas
Iīd like him to speak up now, or leave it completely.
Fact is, nobody else but Jan and Joerg came up with any concrete, factual
ideas/founded bug reports/patches. This is _very_ irritating, especially
if you spend most of your spare time on this stuff while the download
counter reaches the "100" mark. I really need more feedback.
> > > The /proc reading stuff was somethign I hacked quickly together to support
> > > node. I don't think anyone else uses it. Would you care to elaborate on
> > > what exactly is so evil about that.
> >
> > Someone was asking here what is so conceptionally wrong about old-ax25
> > .. so just one example ..
>
> And I still don't see an explanation of exactly _what_ is conceptionally
> wrong about that. Explain it and I'm happy. (If the explanation makes
> sense that is.)
I my opinion only configuration should be in /proc. Thatīs settings, port
status, ax25 circuit list (for reading only of cause) etc. Thatīs mostly
what it consists of now, so it should stay there. What I have a bad feeling
about is that terminal programs begin scanning /proc/net/ax25 to find out
about L2 state of "their" sockets just to display them. They IMHO ought to
use the ioctl() interface.
Another thing is trying to find ax25-Interfaces. Some apps scan the proc
entries instead of using ioctl()s. They break when proc format changes.
In my opinion procfs should be reserved for user interaction with standard
tools such as "cat", "grep" etc, applications and tools should use the
ioctl() interfaces.
> > > > I know that this will pose a lot of administrative problems. But I will
> > > > not accept any performance-compatibility tradeoffs here, except perhaps
> > > > the binary compatibility with the old socket interface.
> > > >
> > > > Comments?
> > >
> > > Good luck getting other developers interested in your (apprently personal)
> > > crusade to save us from the evil of the old implementation.
I do not expect may people to come and contribute much these days. Whoever
has a little bit of brain and some spare time will go to the commercial
market and make his/her skills to money with industrial programming.
This is pretty much an academic thing.
However, I have no objections agains people contributing stuff or ideas.
You got that completely wrong. In fact I will set up a public CVS repository
on dl0td as soon as possible.
>[...]
-- Jens
