hi E:V:A,
On Thu, Mar 16, 2017 at 05:53:30PM +0200, E:V:A wrote:
Nice to hear from you so quickly and directly.
likewise. I guess we've been working on different ends of cellular
communications during the last decade but never really crossed roads.
Well, it is a
collaborative effort. With several hundred SIMtrace
device owners out there, one would hope that the wiki gets updated by
users if they find something is out of date.
Aha, I understand. Well, that is exactly the problem. Today developers are
very sensitive and lazy to signing up to anything, unless its a one-click
operation.
I find that hard to believe. Today, contrary to 20 or even 10 years ago,
almost every website requires you to register, so I somehow doubt that.
We even support OpenID based authentication on our redmine, so you
should be able to log in with many other accounts. That won't give you
write permission (see below), but maybe we can do something about that.
Also, if you cannot even bother to send a patch series by e-mail, or
send an e-mail to request commit / write access, then I don't think you
have time or energy to contribute to a project. After all, what is the
one minute to send that mail compared to the many hours, days or weeks
of your life you're working on the actual contribution?
In addition, most people visiting your site, probably
have no idea
that they can actually contribute to that Wiki. (more about this later...)
We can either
* update the wiki to explicitly explain that, even add it to every page
* re-enable public registration with write permissions with some
automatic spam filtering (wiki spam was the reason to disable it some
years ago)
revision 1.4
(1.4p where 'p' is just for production) of the hardware has
been current since 2014.
Sorry, my bad. I was looking only in the master branch, hoping that
would reflect latest production releases. And they are not named "1.4p",
AFAICT, but:
The 'p' is for 'production', kevin introduced that some time ago, I
don't recall the exact rationale.
So I found the 1.5 schematics and it simply look funny
as there are
a number of "??" parts covering others while others are unconnected...
1.5 was an abandoned work-in-progress and is not what has shipped to
anyone, AFAICT.
v1.4p is what all circuit boards of recent years are labelled, so the
v1.4 tag is applicable. The schematics should render nicely.
I've updated the wiki with a png and pdf schematics as well as gerber
for that revision.
Osmocom has
always been open to anyone. Anyone can post patches to the
mailing list, anyone can get write permissions to the wiki. Simply
register an account and let us know.
Again, I sincerely believe this is because the contribution threshold is
way too high for most small and highly technical projects like this. As I
mentioned above, people simply don't use mailing lists anymore and
Well, I can equally state I won't use anything else for communication.
E-mail is perfect due to its offline/asynchronous nature. I don't have
to be connected to read/write them. I don't need a sluggish web
browser. I don't need a mouse, even.
they certainly hate to have to email their patches,
just to find out that
they conflict or have some other minor errors that prevents them from
getting implemented.
Well, then everyone would have to hate developing on the Linux kernel?
My experience in that field is quite different, even though I haven't
been doing much kernel work in many years ;)
The turn-around-time for all this is way beyond what
most hobby/FOSS
developers want to deal with.
Actually, if I am not working on something full time (e.g. just in the
evenings), then the turn-around time to wait for some feedback until the
one of the next evenings I spend on the project is actually fitting very
well the rhythm of my work. Only poeple who work on something
full-time, with a tight deadline need quick turn-around times.
what I learned from my own experience of failed
projects. That unless
the original developer or other highly skilled (in that project) is watching
and maintaining it (from a feedback point of view) like a Hawk, it will
quickly disintegrate and people will start doing weird shit all over, if not
breaking it all together. Then for sure its dead.
sure, that can very well be the case. But then, it's always up to
people to decide what they do or what they don't do. If somebody cares
sufficiently, then it will be revived. If not, then it might be dead
for good. Which is maybe sad from an emotional point of view, but why
does it matter? If nobody is interested in (and capable of) moving a
project forward, then what's the point o the project. People with an
actual need / itch to scratch will work on it. And if there are no such
people, then nobody needs the project :)
The more
popular/active projects
have moved patch submission to gerrit at
https://gerrit.osmocom.org/ -
for SIMtrace there simply was not enough activity to bother.
Cool, probably move it there. (more below..)
I would argue to do that with the new simtrace2.git firmware. With the
old code it probably makes no sense unless somebody actually has
something to submit.
Behind the
scenes we've been working on-and-off during several year on a
hardware + software refresh called 'simtrace 2'. The controller has
been changed from SAM7S to SAM3S, which supports more USB endpoints and
thus allows for more versatile USB configurations CCID / Card-Emulation /
I don't see why you need more USB endpoints for this? Isn't it enough
with 1-2 since the 2 IF are using the UARTs. Shouldn't all the Tracing, MiTM
and Emulation be done in the FW?
You can, but not if you want to have the "Card reader" part use a
generic driver and middleware architecture, i.e. a USB-CCID compatible
device on which you can run OpenCT or pcsc-lite and the likes. I
strongly believe in interoperable standards. And unfortuantely the SAM7
has insufficient USB endpoints to offer a two-interface configuratio
with one USB-CCID compatible one simultaneous to another one for the
'card emulation' part.
The current
work in progress for the firmware is in
git://git.osmocom.org/simtrace2 but as stated I think it's not ready for
wider consumption. The firmware is a complete rewrite without the
legacy of the openpcd project that lives in the SIMtrace v1.x firmware.
Great! How well is the FW code compartmentalized in the sense that
it can be used with or easily ported to different HW?
All the peripherals of SAM7 and SAM3 are [almost] identical. They
basically switched the CPU core and left most other parts identical. It
shouldn't be *that* hard with the excaption of the smaller number of USB
endpoints, as indicated above.
My roadmap
would be to:
* complete SIM tracing, card emulation and CCID in simtrace2.git
* write related documentation
* start to transition to v2.x in the webshop
* maybe, if there is sufficient interest, try to port the v2.x firmware
to v1.x, although it's rather comprehensive task due to the ARM7TDMI
<-> Coretx-M3 transition. At least the tracing and card-reader
functions should work in theory, MITM will be v2.x only. Advantage
would be identical USB protocol to the host and identical host
utilities for both v1.x and v2.x.
Sound like the perfect opportunity to try GitHub! ;)
I'm not sure why? So far, nobody has even stated in any way that they'd
want to do some work on it [not even you *g*].
Also, as indicated before, I don't like to depend with my development on
third party web services.
I don't
recall having seen this before, so I cannot comment on it.
Please have a good look. It is quite nicely documented with beautiful
pictures. I'd like to know how their FW and SW compares to your
developments, and if something new have been already implemented?
No offence, but if you have an interest in such a comparison, I suggest
you create it?
Hey People, please speak up now!
Indeed. I guess nobody is used to receiving mails on this list anymore ;)
Yes, my unclarity. cgit is ok, although I never liked
navigating there either.
good (first part)
It's your Redmine GIT/repo integration that is
horrible. E.g. It doesn't show
time stamps and when you hit browser back button it puts you back in the
beginning rather than on the page you saw before the current one.
it isn't "our" redmine git integration, but it is the git integration of
redmine. If you don't like it, I suggest you provide feedback and/or
patches to the redmine project.
All we can do is disable it (and redirect to cgit), if more people thing
it hurts more than it helps.
There are many
FOSS projects that are not hosted on github, many of them
way before github existed. If somebody claims they cannot or will not
contribute because it is too difficult to register an account on our
redmine, or to enroll their ssh key for commit access, then I am
somewhat doubtful as to how large their interest really is to
contribute. Wouldn't you agree?
I agree with most of what you say above, but this is the world we live
in and try to be productive in. The same arguments can be used against
your company, suddenly someone offers you a billion EUR and then
the party is over.
Which party is over? When we started sysmocom, we made very sure that
it does not control the Osmocom projects in any way. It doesn't hold
the trade marks, and all time Holger or I spent on development of
Osmocom code is our personal copyright, and not that of a company.
Also, there are no copyright assignments with contributors, making it a
safe guard against anyone who might want to come later to try to change
the license or whatever else.
We have started sysmocom to be able to generate business that funds more
developers and developments for Osmocom.
SIMtrace was btw. developed mostly outside sysmocom. WE just used the
opportunity of having a company that has processes and workflows for
electronics development to provid ready-built units to interested people
who don't want to go through the effort of building it themselves.
If you want to be productive, we need to use the best
tools currently
available and not worry so much what will happen to those 2 years down
the line.
You are free to do what you want. I will not compromise on this. I am
not using non-free software to develop FOSS. In fact, we even go beyond
this to a large extent even in sysmocom: We do everything down to
accounting in FOSS, even non-tech staff works on Linux and the only
Windows machines are our Oscilloscope/Spectrum Analyzer/VNA.
Under some circumstances, I might even consider investing in a
source-code license of a proprietary project management software that I
could host myself, and fix/improve myself. But I will certainly not
depend on third-party *services*, where I have no clear idea how to ever
migrate away from it, once they change their terms of service or go out
of business.
Seeing in general how things are developing with
privately maintained FOSS,
I really think we should consider making some compromise. A good idea
would be to do the opposite of what you proposed, by making your GitHub
the offical repo and use instead your private as a mirror. As a FOSS you can
also have free private repos.
I don't care where the primary git repository is hosted. But I do care
about not using all the non-free issue tracking and merge request
features of a proprietary service.
This discussion has been taking a significant amount of time over the
past days, and I think we have made both of our views sufficiently
clear.
I would love to see contribution from anyone, including you, in
whichever way. I'm happy to gerrit-enable the related repositoires,
and also happy to provide SAM3-versions of the SIMtrace v1.4p boards for
free. But I certainly won't make my development depend on tools I
cannot control.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)