Layers.library V45 on the aminet

[psxphill]

Such NDAs are quite common, and of course, the they forbid you to take the developed software and re-sell that to a competitor.

That isn't legal even if you didn't sign an NDA. As long as you don't disclose anything that could only be learnt during your contract then you can contribute to AROS just fine.
 
 What you are describing sounds more like a non-compete clause, which isn't going to be in force by now (if they try to say it is then the court would rule that it was an unfair clause).

[psxphill]

Back in 1989/1990 Michael Sinz at Commodore modified the timer.device not to use two different time sources any more (UNIT_VBLANK and UNIT_MICROHZ used different CIA A and CIA B timers, which had different granularities), but to use single CIA timer instead. That timer had much higher resolution and precision, which was a great improvement.

It turned out that when the 'C' port of timer.device was reviewed, all the old obsolete CIA A and CIA B timer code was still in there, and a good part of the 'C' port was effectively useless. Again, observations such as these, which lead to irrelevant code being discovered and removed, require a high level view of the code, which for assembly language (by its very nature) is difficult to find.

Sounds like "Jumpy the Magic Timer Device", are you sure the code was all unused?
 
 
 

but code brings me (and AROS) into a situation which is quite delicate.

You can't contribute any of the code you received or were paid to write (and that doesn't matter whether you signed an NDA or not), but you were implying that under no circumstances could you contribute anything to AROS ever.
 
It would be pretty easy to prove in court where your contributions came from though, so as long as you are honest then you're fine.
 
 I'm pretty sure that quite a bit of AROS was written by people who had disassembled commodore's code & it already isn't a clean room implementation.

[psxphill]

Anyhow, byte counting stopped making sense, already when 512K were the norm, and priorities changed.

It still made sense, if you needed the space. If you could shave a couple of K off and make something fit in ram or on disk then the cost saving was worthwhile.
 
 exec/dos/workbench etc that were in memory a lot of the time would make sense to be as efficient as possible. Not many people would complain if Prefs wasted 100k of ram.
 
 gnu 68k compilers are shockingly bad, it's one of the things that needs the most development.

[psxphill]

That implies that it's not possible to always implement optimal algorithms in an optimal way in assembly language.

Sure it's possible, it's possible that you'll get it finished before you give up, it's possible there won't be any bugs, it's possible that when you realise there is a better algorithm that requires you to start again that you will actually do it.
 
 For most people it's very unlikely they'll bother.
 
 You are arguing over usage and interpretation of English, not of the actual issues at hand.
 
 It's impossible for me to write in assembler these days, not because I can't but because I won't let myself. Life is too short. If you can afford to waste the time then go ahead, but it doesn't prove what you think it does.

[psxphill]

GCC (and glibc) for m68k has gotten quite a bit of attention the last few years and is far from "shockingly bad". Upgrade already.

Can you back that up, I can't find any proof of that online.

As far as I can remember, probably during training in microelectronics in the 80s:
"in 1972 the first version of C is written in assembler by Brian W. Kernighan and Dennis M. Ritchie."

The C compiler was based on the B compiler, which had already been re-written in B by this point. B was originally written in TMG, but TMG was written in assembler by Doug McIlroy.

Never believe anything they teach you in school.

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

[psxphill]

My personal take on the difference between what these terms stand for is that the software engineer has a significantly bigger toolbox to draw upon than the coder.

It's pointless to use terms when you are applying your own definition of what they mean, as words are only useful to communicate your ideas.

http://en.wikipedia.org/wiki/Programmer

"A programmer, computer programmer, developer, coder, or software engineer is a person who writes computer software"

http://en.wikipedia.org/wiki/Software_engineer

"Software engineers apply the principles of engineering to the design, development, maintenance, testing, and evaluation of the software and systems that make computers or anything containing software work."

Most people who call themselves software engineers are doing it through arrogance as they are piss poor programmers who can't design for toffee. If you call yourself a software engineer because you think it sounds good, then be careful where you work.

"Some of the states regulate the use of terms such as "computer engineer" and even "software engineer". These states include at least Texas[30] and Florida.[31] Texas even goes so far as to ban anyone from writing any real-time code without an engineering license"

I've never called myself a software engineer because I'm not that pretentious, I preferred the term software developer. If I was arrogant I'd call myself a software architect, which trumps your made up software engineer status.

[psxphill]

The term "software engineer" can be anything to anybody. Which is why I mentioned the context in which I used it. Because Thomas used this term to make his point, it does seem prudent to me to keep using it.

If you know that everybody has a different meaning to it, then why would you waste time assigning your own meaning and using the term?

All you'll do is have endless arguments over what the term means, which can't be solved as you are only one person and statistically nobody cares about your point of view.

Life is too short, which is why I'm not going to push you to understand my point of view.

[psxphill]

That is quite funny to is Finns. Here in Finland title is (usually) used to describe your job than competence. It has gone ven so far that I can craft my job title if I want to. And sometimes i do. So far I have been Software engineer, embedded engineer, project engineer, research engineer, training engineer, development engineer and it could be anything relating to my work.

Yes, it's why we have sandwich artists and kitchen technicians.
 
 The job title you have is largely irrelevant, I'd rather have more money than a flashier title (some companies stroke your ego with a flashy title just so they can pay you less)

[psxphill]

and it can be very helpful also for solo projects.

Imagine a big project with many files on which you work for several years.

Yeah, I rarely bother for solo projects that I am not going to share. But these usually turn out to be one off throw away programs anyway. While it makes some sense to source control those too, it is one of those jobs you put off. Like deleting old emails you no longer need.
 
 The biggest problem is when you write crappy programs that have hard coded paths etc, then these show up as changes in source control. You should split those out into configuration, but when it takes 30 seconds to write the code in the first place then making it tidy and putting it into source control is hardly worth it.
 
 You also have to maintain a server yourself, but if you're part of a team then you can offload that to someone else.