16 Mar
2017
16 Mar
'17
4:53 p.m.
Hello Harald,
Nice to hear from you so quickly and directly.
On Thu, Mar 16, 2017 at 4:01 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
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. In addition, most people visiting your site, probably have no idea
that they can actually contribute to that Wiki. (more about this later...)
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:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/debian
remotes/origin/master
remotes/origin/v1.0_production
remotes/origin/v1.1_discontinued
remotes/origin/v1.1_production
remotes/origin/v1.2_production
remotes/origin/v1.3
remotes/origin/v1.4
remotes/origin/v1.5
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...
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
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. The turn-around-time for all this is way beyond what
most hobby/FOSS developers want to deal with. In addition, I can tell
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.
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?
Yes, my unclarity. cgit is ok, although I never liked navigating there either.
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.
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. 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.
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.
Kind Regards,
E:V:A
However, it
seem that the project is abandoned since it has not been
updated on your Wiki for ages.
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. For example, I
cloned the SIMtrace and opened the schematics in KiCad
only to find that the schematic is several HW versions behind the
currently shown one.
revision 1.4 (1.4p where 'p' is just for production) of the hardware has
been current since 2014. 1. Have you
abandoned the project?
Not really. SIMtrace v1.4 has been produced and sold in hundreds of
...
Look at the mailing list archive and the git repository
commit history to see how limited contributions there were so far.
Basically Kevin, Holger and I did most of the initial development in
2011/2012, and then there was one patch series from Min Xu in 2014 - and
that's it!
I understand that contributing to the hardware is not easily possible
for people without EE skills. But contribution on the firmware and on
the host software is possible for anyone with a C development
background.
So SIMtrace suffers the fate of many, many other projects that I
developed and/or was involved in developing: It does what the original
author[s] wanted it to do, but it stays very far behind its potential as
nobody seems to be interested in making it do more than it did ever
since its creation.
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. 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..)
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?
SIM1 = UART1 <==> "M3" <==> UART2 == SIM2
//
PC <---> USB <====//
Tracing, unlike the SIMtrace 1.x which is basically
tracing only due to
the limited number of USB endpoints. However, the firmware has still
not yet reached a stage where it can do anything useful beyond SIM card
emulation / forwarding, so I've refrained from announcing it anywhere
before it reaches a point where it can do SIM tracing (like v1.x) as
well as card emulation and there is some documentation on how to use it.
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?
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! ;)
3. There is a
related project on GitHub that are using SIMtrace.
However, the firmware there seem different. What is the current status
of the firmware? Are you involved in that development?
https://github.com/kamwar/simlabTrace
I don't recall having seen this before, so I cannot comment on it. From my point of view, I don't think there's a
lack of maintenance,
there's just a lack of patches to integrate. If people on this list
disagree, please let me know, by all means.
Hey People, please speak up now!
This is
actually a great idea, reagrdless as your Redmine/cgit based
git repo is very slow and
This is the first time we have received complaints about the cgit or
actual git servers being slow. All of the Osmocom projects are hosted
there, and most of them are significantly more complex than SIMtrace. hard to
navigate and the bug tracking of GH is superior in simplicity
to anything else freely available.
yes, and once we all use proprietary "cloud" services we will all become
...
I really don't like to have FOSS projects depend in their development on
non-FOSS software. I also don't like central/single points of failure,
whether they're called SourceForge some decade[s] ago, or whether
they're called github now.
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?