From: D Yuniskis on
Hi Vladimir,

Vladimir Vassilevsky wrote:
> Actially, it is Meggitt decoder. The idea is to calculate the syndromes
> on the fly rather then store them in a LUT. This kind of decoder could
> be easily applied for *any* cyclic code; it's advantage is simplicity.
>
> For those who are interested in the classic error correction math, the
> good book is R. Blahut "Theory and practice of the error control codes"

I like _Error-Correcting Codes_ by W Wesley Peterson. No doubt
out of date. But, requires a considerable math background to
truly appreciate much of what is covered (field theory, etc.).
And, you won't find any code snippets within. :< But, if
you understand the math behind the theory, you can usually
roll your own implementation fairly easily.

I will try to chase down a copy of Blahut just to see how it feels.
From: D Yuniskis on
steve_schefter(a)hotmail.com wrote:
> David Brown <david.br...(a)hesbynett.removethisbit.no> wrote:
>
>> To use LGPL'ed code with your own code, anyone receiving your code must
>> have access to the LGPL'ed code, be able to change and recompile that
>> code, then link it along with the rest of the binary and run that
>> software instead. For non-embedded systems (or "big" embedded systems),
>> that typically means the LGPL'ed code is part of a dynamic library. To
>> use LGPL code in a (typically statically linked) embedded system means
>> that the end user will need access to your source code, or at least
>> compiled and linkable object files. Since that is impractical or
>> impossible for most embedded systems, the rough conclusion is that pure
>> LGPL code is very seldom suitable for embedded systems.
>
> Okay, thanks. I guess where we differ is in the opinion that
> dynamically linked apps are not suitable for embedded systems. The
> ones I work on (Linux-based) tend to use dynamically linked apps more
> than statically linked ones. In the early days, I've even had to
> force the apps to be dynamically linked to fit everything in flash
> (several apps linked with the same library).

I think the reasons many (most?) embedded systems shy away from
"shared objects" are twofold: resources and tools.

Small (< 1MB TEXT+DATA) systems tend to feel like they don't
have the resources to spare on the dynamic binding (I think
this is usually silly-talk but the folks building those
systems are the ones who have the final say :> ). Personally,
I find the overhead to be small and the discipline associated
with developing with s.o.'s makes it a *big* win "almost always".

The other reason is often poor tools. E.g., you aren't going to
find (?) an 8051 compiler/linkage editor that will support
this sort of thing. So, to do it, you (the developer) have to
build your own tools (this isn't very hard but *is* another
step and something *you* have to support -- not the tool vendor).

I think if more folks were accustomed to this sort of
run-time environment, they might be more willing to
add it to their toolkit (e.g., just like adding PMMU
support)
From: whygee on
Jon Kirwan wrote:
> To achieve software freedom in RMS' sense, they have to use
> force on _developers_ (not users) to fight the proprietary
> developers' forces. Which is why the licenses exist, I gather.

wrong, the FSF provides tools to the coders, it's more like
providing weapons to the poorer side of a war... which is
not popular.

The GPL is not appreciated by a lot of people because...
well, it gives the developers the means to unite in a way,
and defend themselves. Nobody is "forced" but there is
a choice, a bit more freedom.

Then, between the plan and its implementation, there
are probably a lot of... glitches. So don't get impressed
by David : read RMS's "writings" and make your *own* opinion
(and yes, RMS is stubborn, but it does make him malevolent).

> Jon
yg
--
http://ygdes.com / http://yasep.org
From: Jon Kirwan on
On Mon, 08 Mar 2010 04:13:02 +0100, whygee <yg(a)yg.yg> wrote:

>Jon Kirwan wrote:
>> To achieve software freedom in RMS' sense, they have to use
>> force on _developers_ (not users) to fight the proprietary
>> developers' forces. Which is why the licenses exist, I gather.
>
>wrong, the FSF provides tools to the coders, it's more like
>providing weapons to the poorer side of a war... which is
>not popular.

I was thinking about the copy-left, itself, and that it does
have _legal_ force to it. It clearly must. Maybe I didn't
write what I meant so well.

>The GPL is not appreciated by a lot of people because...
>well, it gives the developers the means to unite in a way,
>and defend themselves. Nobody is "forced" but there is
>a choice, a bit more freedom.

More options is always better.

>Then, between the plan and its implementation, there
>are probably a lot of... glitches. So don't get impressed
>by David : read RMS's "writings" and make your *own* opinion
>(and yes, RMS is stubborn, but it does make him malevolent).

I've read some of his writings and enjoyed them. I think his
mission is "big," but I generally support and like what it
has managed to carve out for itself. I would have no problem
contributing, as well.

Jon
From: Jon Kirwan on
On Sun, 07 Mar 2010 20:58:59 -0700, D Yuniskis
<not.going.to.be(a)seen.com> wrote:

>steve_schefter(a)hotmail.com wrote:
>> David Brown <david.br...(a)hesbynett.removethisbit.no> wrote:
>>
>>> To use LGPL'ed code with your own code, anyone receiving your code must
>>> have access to the LGPL'ed code, be able to change and recompile that
>>> code, then link it along with the rest of the binary and run that
>>> software instead. For non-embedded systems (or "big" embedded systems),
>>> that typically means the LGPL'ed code is part of a dynamic library. To
>>> use LGPL code in a (typically statically linked) embedded system means
>>> that the end user will need access to your source code, or at least
>>> compiled and linkable object files. Since that is impractical or
>>> impossible for most embedded systems, the rough conclusion is that pure
>>> LGPL code is very seldom suitable for embedded systems.
>>
>> Okay, thanks. I guess where we differ is in the opinion that
>> dynamically linked apps are not suitable for embedded systems. The
>> ones I work on (Linux-based) tend to use dynamically linked apps more
>> than statically linked ones. In the early days, I've even had to
>> force the apps to be dynamically linked to fit everything in flash
>> (several apps linked with the same library).
>
>I think the reasons many (most?) embedded systems shy away from
>"shared objects" are twofold: resources and tools.
>
>Small (< 1MB TEXT+DATA) systems

"Modest," for me, is 512 flash and 16 RAM. "Small" would be
half that. "Decent" and kind of roomy is anything like 4k
flash and 512 RAM. "Unbelievably big" is 40k flash and 4k
RAM.

Anywhere _near_ 1Mb of anything is called "monstrously huge,"
or is just a "workstation" and has way way too many pins or
is way too expensive or is way too power hungry or has way
too many extras to worry about. Probably all of those.

My operating system, which supports pre-emption or
cooperative tasking (either), and messages and sleep and
semaphore queues and so on can live with singly-linked lists
(everything is compile-time selectable, so you can remove
what you don't want or add what you do) for the queues. It
adds a little extra code and certainly some small execution
time, but sometimes you want that because RAM is scarse. I
can shovel it into very small devices. But the nice thing is
that when I have the RAM for doubly-linked lists, it's just a
change to a #define and then a recompile. Or if I want to
support a lot of processes, etc. It's all compile-time
stuff.

>tend to feel like they don't
>have the resources to spare on the dynamic binding (I think
>this is usually silly-talk but the folks building those
>systems are the ones who have the final say :> ). Personally,
>I find the overhead to be small and the discipline associated
>with developing with s.o.'s makes it a *big* win "almost always".

Well, if you consider <1Mb to be 'small,' then most
certainly.

Despite your earlier agreement with me on some points, we do
not appear to live in similar programming worlds.

>The other reason is often poor tools. E.g., you aren't going to
>find (?) an 8051 compiler/linkage editor that will support
>this sort of thing. So, to do it, you (the developer) have to
>build your own tools (this isn't very hard but *is* another
>step and something *you* have to support -- not the tool vendor).

I've had to develop my own linkers before. Twice, at least.
It happens. You just don't want to make it happen if you can
avoid it.

>I think if more folks were accustomed to this sort of
>run-time environment, they might be more willing to
>add it to their toolkit (e.g., just like adding PMMU
>support)

Not sure what to say to that. I understand some of the
context, but not all of it, I suspect.

Jon