Go Down

Topic: Linux V0022 Mega 2560 crash (SOLVED?) (Read 5678 times) previous topic - next topic


Jul 29, 2011, 08:47 pm Last Edit: Jul 29, 2011, 08:54 pm by gerg Reason: 1
Many thanks for your input. I had not considered the location of the code. I had gone only by what the repository had done. That may be a good thing to consider. My repository put the files in

That means it was installed into /usr. That's a no-no for a third party in general and a major no-no for software which is extremely likely to be in direct conflict with software provided by the system. They should be installing into /opt (historical) or /usr/local (more semi-recent Linux-esk convention).

The types of files that it put in those locations fit. That is the same file location/type that came from Atmel also. ??

Its has nothing to do with the "types of files", and everything to do with the fact that Atmel is not the maintainer of your distribution, which furthermore makes assumptions about the layout, disposition, and architecture of your distribution.

Any time you download executable files, or even source code to build them, you are taking a bit of a chance. It is best if you stick to reputable suppliers. That link above is to the Atmel website, where I downloaded this from.

That's true only from a security perspective, not a system maintenance and correctness perspective.

Here is but one example that bites people from time to time. Let say you installed the compilers provided by your distribution. Rightly so, they likely installed into /usr. For the sake of example, let's go with that. You now download Atmel's compiler and install it. Its now installed directly over the top of the system provided compiler +- an odd file here and there. Things are good. Now, at some point down the road your distribution notifies you of updates and you accept the updates. Some time later you notice that your "Atmel compiler" is now producing buggy code and only for some not so common code constructs. You hunt and hunt and you can only seem to determine its a compiler bug. You report the bug to Atmel which says no such problem exists.

Turns out the problem was, your distribution found some bugs and re-released their compiler suite which was a valid candidate for update since you had your distro's version installed. The update fixed the original problems which required the install of the Atmel compiler but there was still some odd bug which still lurked. This odd bug is now exposed as the distribution update installed right over the top of your Atmel compiler install which in turn was installed right over the top of the distribution's provided compiler.

The above is just the tip of the iceberg and is but one example of why its a very, very bad idea. There are very good reasons why there are places for vendors to install their software, and failing doing so when its in direct conflict with software provided by the distribution is always an extremely bad idea. This is also one of the classic reasons why Windows is traditionally a royal cluster-f for system correctness and maintenance.

Now then, that doesn't mean it can't be managed but that also doesn't make violation of standards and best practices a good idea. In fact, bluntly, its a very bad idea and shame on Atmel for doing so.



Jul 30, 2011, 12:28 am Last Edit: Aug 01, 2011, 08:02 pm by SurferTim Reason: 1
@gerg: I see your point. You would prefer the install in "/usr/local/". Hope we don't overwrite something there.

For the rest, the functions supplied by Atmel seem to be working.

The ethernet library functions (maintained by Arduino?) are not. The Client::read() apparently does not remove the characters from the ethernet buffer. Even if I quit sending characters from the server, "client.read()" keeps returning the same several characters over and over.

EDIT: I sent the two corrections to Atmel with a mention of the ethernet client.read() problem. Maybe they will feel obliged to do that for me?

Go Up