This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
E:V:A xdae3v3a at gmail.comHi Harald, Thank you so much for taking the time to respond to all my inquiries and challenging comments/requests. Your response has indeed convinced me that this project is very much alive, but that it need a whole lot more of community TLC. On Fri, Mar 17, 2017 at 5:39 PM, Harald Welte <laforge at gnumonks.org> wrote: > hi E:V:A, > ... >> 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? You're probably right, but another aspect of contribution is what effect even the smallest ones has. What I mean is, that when a drive-by developer finds a minor error somewhere, he/she just doesn't bother to open email and register and so on, just to send a patch for some misspellings, minor buffer allocation error and the like, in the hope someone else will fix it. So given the low external developer participation in this project, it may seem dead from the outside perspective as there are barely any new pushes or changes. Now, perhaps I could be very wrong here, but my own thinking goes like that. I regularly find github projects that have been forked in dozens, and although the original or older forks are better, I still usually choose to use one of the later ones, just to be sure that if I do make some changes or have some comments or bugs to report, that someone is on the receiving end.. > 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) Good idea. > 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. Yeah, I noticed almost immediately. Very good. Also have you tried to run the files in the latest KiCAD 4.0.6? There are some new changes there, that require some files to be updated. (automatic) >> 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 ;) I knew you would mention this. ;) But that has quite a different project scope doesn't it... > >> 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. I agree, you have me convinced. >> > 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 see. I would suggest trying a new approach of working on this "on top of the scene" so that people see that something is happening and that they can jump right in to contribute if they want. >> > 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*]. True and fair enough. I would be happy to deal with the documentation in case I ever get my hands on the new HW. >> 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? No offense taken. They (bodziow and kamwar) just recently responded to my question here: https://github.com/kamwar/simLAB/issues/1 and indeed thay have made several improvements. -------------------------------------------------------- "We have refactored that source code (i.a. removed unneeded modules), separated reader and forwarder functionality and added some improvements and bugfixes. The most important work has been done on the Python (Host) side." and: "simLabTrace is APDU forwarder - it receives APDU data from UE, forward it to simLAB and send back the data from simLAB to UE. As Szymon already mentioned, we removed unused files and do basic refactor to split functionality between forwarder code and CCID reader. Most changes in the firmware code are for CCID reader but there are also several fixes and improvements for APDU forwarder. Although original simTrace firmware should work in passive mode it turned out that sometimes the SIM inserted into the SIM slot is not recognized at all, e.g. simTrace doesn't allow to sniff card reader connection (CCID reader -> simTrace -> SIM in simTrace slot). I can't recall the exact solution for this problem but it was related with PTS procedure." -------------------------------------------------------- This seem very promising, so I guess a closer collaboration with them would benefit everyone. >> 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. Awesome and very encouraging! >> 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. Very good and you have me convinced. Thanks again for your time and I think it has been well spent. Many Cheers, E:V:A