Profile

Cover photo
Tycho Softworks
106 followers|123,930 views
AboutPostsPhotosYouTube

Stream

Tycho Softworks

Shared publicly  - 
 
There are many specific reasons I use c++ in my projects and for building api's, even back in 97 when so many at the time were so very skeptical of doing so in what would become #bayonne. One of them is that, even if the underlying libraries I am using are pure c, it is far easier for me to add structure and organization to the overall project codebase through c++ and object oriented methodologies. The other use I found for having a core c++ library and sdk in my projects was in mediating platform/compiler differences, and in adding missing features never standardized at the time such as threading, crypto, and sockets.

Hence, even with #APE (which appeared ~97 and was initially a response to #ACE), which became #commoncpp, and later evolved into #ucommon, the real underlying goals and purposes of the core library has remained unchanged. uCommon as a core api for me currently mediates c++98 thru c++11, and does so on so many entirely different platforms and architectures, many of which are no longer even in common use or required. This alone actually makes it rather hard to support and maintain, and what limited time I have had has been absorbed simply doing mediation and maintaining compatibility.

At the same time I also inherited other specific requirements and mandates for building and maintaining ucommon and related packages, including the use of autoconf/automake. In the past decade I added cmake support, but this has meant maintaining two complex and completely different build systems.

Another original goal of ape/commoncpp/ucommon was having very tight control over code for possible embedded uses. Hence, none of the ucommon code base really supported exceptions, and in fact could be built without exception support and can even be optionally built without a c++ runtime library or stack unwinding at all. This focus on deep optimization and architecture is also part of how we got Bayonne to run an entire DS3 circuit with live real-time concurrent IVR active on all 672 channels using a stock pentium 3 at the time in our trials with Telstra very early last decade. I think though moore's law had obsoleted this requirement...

Another inherited goal in ucommon and related projects was maintaining packaging and build structures optimized for use and inclusion in the GNU Project and for some GNU/Linux distros, particularly Debian. This also meant we were required to divide our core sdk into multiple smaller stand-alone packages. This actually is completely different from how I internally develop and maintain the codebase. Long ago I shifted to the idea of a single master cmake bootstrap build tree that automatically checks out each package into a submodule, and then doing a single top-down build of everything together when needed to quickly validate changes.

I really do not think project organization should be optimized for any specific distro's (or os's) packaging model, and anyway even doing so in ways fully consistent with #debian (or similarly #fedora) packaging policies still meant that often it had taken a number years to even get a single package included in a distro, whereas often I needed the entire set for a complete api to build other things on top of, as well as complicated the whole process of maintenance just to keep different distro packages updated. This eliminated any potential benefits that were possible from being particularly well aligned with any specific distro. And I do not even actually use the distro packages in my own preferred development model except to assure a place to later deliver final projects in those distros.

Hence I see focusing on c++11 and later as a means to also drop so many legacy practices going forward. c++11 (and later) requires far less mediation support and has some very useful features for optimizing and improving code, such as move constructors and type inference, which simply cannot be "simulated" in older compilers. boost asio seems an entirely reasonable means to address sockets. Starting with c++11 there is standardized threads, atomics, etc, which also no longer require extensive library mediation. I only wish that <filesystem> had also been standardized, as it touches upon so many things I would consider entirely normal and actually required as well.

I also am looking to entirely abandon #autoconf/#automake. Having a single build system, and using build trees, also makes ci setup and testing so much simpler, especially given that most ci systems offering public hosting (such as #travis, #gitlab, etc) use disposable temporary containers rather than offering persistent slave instances like Jenkins does.

Hence the idea of moving past #ucommon is the idea of re-assembling the existing codebase in a much cleaner way, as well as dumping so many features and practices that also take tremendous time to maintain and do, and which are simply no longer really required going forward.

3
Add a comment...

Tycho Softworks

Shared publicly  - 
 
At one time we had a #friendika node. Now that #letsencrypt has finally made it so very easy to get a working ssl certificate, I have thought about setting up a tribal #hubzilla, as valid ssl certificates are a requirement for that. We already used letsencrypt to setup our tribal #owncloud with valid certs, as we had some tribal council members who had immense difficulty working with self-signed ones in the past.

+Will Hill +Jos Poortvliet +Jan Wildeboer +Rafael Rico Ríos +Haakon Meland Eriksen +Eric Côté


3
Tycho Softworks's profile photoHaakon Meland Eriksen's profile photo
9 comments
 
Not yet. Bob Mottram has added it to his http://freedombone.uk.to/ setup and some other people to theirs, but I have not had time to add letsencrypt to the deploy script, but given time and Python I am sure it is relatively easy. Come to think of it, I think I read about OpenShift with Let's Encrypt on Stackoverflow.com or similar.
Add a comment...

Tycho Softworks

Shared publicly  - 
 
When I think of a more focused #sipwitch descendant as a product, I actually had considered two possible paths. The first was a rpi premise hosted VoIP switch, which really goes back to where OST was originally headed. Indeed, if circumstances suddenly became very desperate and made it necessary, I could turn around even the existing older #ucommon/sipwitch codebase over a week or two and try doing a kickstarter along these lines. I think though that would be more a plan-C at this point. But I definitely feel I have strong need for a potential need for a plan B for 2016 at this time. The second possibility is a hosted #PBX as a cloud service.

Each possibility takes advantage of a specific feature of sipwitch, which is that it only mediates #SIP sessions, not #RTP media, and hence can manage a much larger fully inter-operable VoIP infrastructure with rather modest cpu requirements. Also it would be pretty easy to integrate a more #VoIP focused and hence greatly simplified version of ucommon combined with #exosip2 into a single VoIP sdk for common service development, which is kinda where I was already headed with a newer ucommon for after 7.0.

+Eric Côté+Haakon Meland Eriksen+Jos Poortvliet+Georg Greve+Rafael Rico Ríos


3
Add a comment...

Tycho Softworks

Shared publicly  - 
 
When I talk about what is next after #ucommon, I am really speaking of a purely modern C++ sdk, based on C++11 as a starting point and one that embraces STL. Part of this is an effort to get out of the "platform mediation" business that is core to ucommon itself. I was also interested in co-existing with other modern C++ libraries, such as boost, rather than re-inventing core libraries in a different form.

Some practices we have in ucommon I think are superior to the path that modern C++ development had chosen. For example, we used templating only to do light inline type wrapping for strong generic type support around code that had a solid base class implemented thru inheritance and virtual methods. Pure templating and specialization is of course orthogonal to inheritance with virtual methods, but it seems most have decided that the way forward with C++ is to use it as a kind of modern mainframe macro assembler with templating used to regurgitate complex code, rather than as a means to cleanly encapsulating object hierarchies and expressing protocols through virtuals. It is actually this reason I also had been looking at #golang.

Nonetheless we have also internally produced a C++ sdk as a cleaner successor to ucommon, and one that more fully adopts many of these modern idioms. In doing so I also have looked at what we tried doing with usecure and coimath.

usecure of course is our crypto toolkit. Right at the start though it was overloaded with the need to support ssl. This was unfortunate in some ways. ssl may well be fundimentally unredeamable, but it also distracts from the functionality and needs of a more pure crytographic toolkit. At the same time there are black-box "system provided" crypto/ssl toolkit libraries which seem inherently dangerous.

I do think we need to have our own easily re-buildable crypto library, and have it make only used decided optional use of system provided hw acceleration, such as for hashing. While the math is trustworthy, any vendor supplied black box library can never be, especially as made very clear by industry relationships of the #NSA and other similar untrustworthy governmental organizations.

As some might have guessed, the experiment with coimath under ucommon was about having a foundationally trustworthy big number library to support building our own pki library. This too will also be an essential component of a new post-ucommon sdk, though as a separate library from the crypto one, so crypto can also be used cleanly stand-alone in our projects and easily mixed with other libraries on it's own.


+Eric Côté +Haakon Meland Eriksen +Rafael Rico Ríos +Jos Poortvliet +Jan Wildeboer +Georg Greve

1
Add a comment...

Tycho Softworks

Shared publicly  - 
 
This is the release weekend for introducing #ucommon 7.0.0.

We also are facing a major winter storm in the homeland. Our tribal council meeting for this weekend had already been cancelled.
3
Will Hill's profile photoEric Côté (ericlnu)'s profile photo
2 comments
 
Keep warm study dagger, and think of sending some of that snow this way bro, we need some, lol. Ask the Grandfather Thunders ;).
Add a comment...

Tycho Softworks

Shared publicly  - 
 
While in the process of preparing #ucommon 7.0 turnover, I also did an analysis of #golang for future #sipwitch development.  There are some advantages, and some challenges.  The most interesting advantage and disadvantage is that go really uses static linking.  From the perspective of libraries, everything, while maybe some of it is still a bit immature, already exists in go, including a sip stack, crypto, etc, which we either had to build ourselves or integrate, and on different platforms sometimes with entirely different libraries. 

Since all the ci services we can find to host builds use one-time use disposable containers, static linking within a single project file actually works much better.  I did do a #jenkins   setup that does things like automate build chains of project source trees on triggers from dependent packages, and, since the host was persistent, I could keep and feed builds from one component to another simply by having it run an install target, but it was rather complicated to setup at the time, we no longer have a place to host such a thing, and as noted is not a methodology any of the the existing ci hosters supports, though some may offer a potentially really clunky way to do so by caching and perhaps then scripting pulling build artificats along each dependent build...yuck...

But wait, we also do use runtime loadable plugins in sipwitch.  From the perspective of sipwitch architecture, plugins really were not that necessary, and did overly complicate the whole service.  The ones we have represent things that we really could simply have been built-in.  Except for database backend.  This is the one spot where go is challenging.  I have thought about this, and maybe actually using #gorpc or maybe a json web api is the best solution, with the backend databse in a seperate go service tied to a specific database backend and schema, which could offer access to the db for both sipwitch itself and a matched up sipwitch admin console with a common externally visible interface.  This would not be the most horrible option, as sipwitch architecture always had frictionless db access by pre-caching entire config instances locally onto the node, so db access/latency issues are not that relevant, even if more loosely coupled.
3
Dietrich Schmitz's profile photoAlexander Nolting's profile photoTycho Softworks's profile photo
4 comments
 
+Dietrich Schmitz the choice for C++ for me was primarily about being able to provide a better architecture to structure my application services, as, especially in the case of Bayonne, most of the underlying libraries and telephony car drivers were often supported in pure C.  Ucommon in particular was about adding rich concurrency support to C++, and a more lightweight runtime library suitable for embedded uses to support that architecture.  Hence, it does not make use of C++ exceptions and does not require the ansi c++ library.  Templates are used in very narrow and specific ways often as lightweight wrappers for pure type automation.

Bayonne of course was often tied to different telephony card runtimes which were either in C or C++, so it never made sense to consider something else.  Sipwitch is really only tied to the very nice and mature exosip2 library from +Aymeric Moizard , which incidentally  I do highly recommend.  But there is several sip implementations for both client and server in go, it also already offers a strong model for concurrency, and also offers a better means to structure and architect applications than at least pure C does...
Add a comment...
In his circles
86 people
Have him in circles
106 people
Harvey Michele's profile photo
Sawi Yati's profile photo
Ayman Khalifa's profile photo
Alvin Sugar's profile photo
Robin Miller's profile photo
Mark Rushing's profile photo
Alison Chaiken's profile photo
Seth Johnson's profile photo
Igor Gnatenko's profile photo

Tycho Softworks

Shared publicly  - 
 
Having watched #systemd grow to swallow ntpd and other things recently, naturally the only response I could think of is to write commandd, a single binary application that executes all the common posix shell binary utilities in itself. Oh, but that might be a future feature in systemd :)

+Eric Côté +Will Hill
6
Valdis Klētnieks's profile photoTycho Softworks's profile photoEric Côté (ericlnu)'s profile photo
4 comments
 
Heehee :). I like the idea, use it as a rescue system instead of busybox on a full system. E.g.
Add a comment...

Tycho Softworks

Shared publicly  - 
 
The first published releases of both ucommon and sipwitch date from 2007, while the first published releases of commoncpp and bayonne date from 1999. And even further back, DBS server and VU date from ~1991. If I were to really consider introducing something newer now, it would also mean I do operate on a roughly 8 year cycle in my public projects.

+Eric Côté +Rafael Rico Ríos +Jos Poortvliet +Jan Wildeboer +Georg Greve
3
Add a comment...

Tycho Softworks

Shared publicly  - 
 
I had been thinking about what it would mean if we did finally organize and commercially deliver software products and services tribally. We currently do have a non-profit as well as holding most of my past copyrights now, and I do not see many other kinds of opportunities for us at the moment. In particular, if we went this route, we would begin to look for funding to develop and provide things like a highly focused #sipwitch descendant, and actually some of the basic architectural groundwork had already been done for this in parallel with #ucommon 7.0 development while I was offline. Other than that, I am open to other ideas while trying to keep warm this winter.

+Haakon Meland Eriksen +Eric Côté +Rafael Rico Ríos +Jan Wildeboer +Jos Poortvliet +Georg Greve
2
Eric Côté (ericlnu)'s profile photo
 
Something off the top of my head, while not software, but still relevant in some ways is trademark and copyright of symbols. Anyone using them who is like using them for say regalia or artwork, can use it, but if it's to be used by say the gap of forever 21 then no no no not allowed. To prevent or slow down cultural appropriation. 
Add a comment...

Tycho Softworks

Shared publicly  - 
 
One reason I never choose to depend on cloud services is also practical, rather than only or exlusively out of ethical concerns. Often times, like now, I may simply find myself in some place in the US where I have no internet connecivity whatsoever. Sometimes I will find electricity is unavailable either. It can also at times and places be a very long walk to find any wireless or mobile.

I did complete ucommon 7.0. External git even has what would have been the release. It may however be several weeks or months before I have an opportunity to distribute a release.
2
Add a comment...

Tycho Softworks

Shared publicly  - 
 
There are several aspects that do seem to make #golang particularly well suited to writing services, which, rather than user facing applications, is actually and historically mostly what I do anyway.  To me, it is to writing services somewhat analogous to what #qml is to writing desktop client applications; it greatly simplifies the process of doing so by proving a language framework and environment that better matches actual needs.

Several common practices I commonly do for concurrency and to achieve very high scalability in my own development actually are already either inherent to or otherwise seem rather well supported by go.  In addition to rich concurrency, this include the ability to compose objects, for which I often would abuse multiple inheritence in C++ to try to accomplish. Because go does have pointers, I can also parcel out large heap or gc managed allocation chunks by providing smaller non-heap/non-managed fast allocations, which is what the #ucommon   mempager and related classes were used for.  This makes it theoretically possible to at least conceive of a "gobayonne" that may be able to achieve similar scalability.

Cross-platform and platform specific code seems easy enough to isolate and manage by simply adding build tags to sources to indicate when they should or should not be built and included, which is what I typically do now in C/C++ with much cruder #ifdef's around an entire C source, since when I use cmake in particular, it is much easier to glob the whole source directory rather than also define in the cmake which files to use conditionally, but yet which produces empty compilation units that a few compilers actually object to.

Of course this gets to another interesting aspect I like about go; it is also it's own build system, and one that may even actually match the way I would want to build things, too.
2
Add a comment...

Tycho Softworks

Shared publicly  - 
 
+Kirk Pearson+Alexander Nolting​ I was never too keen on rolling distros, but from what I can see there is an OpenSUSE gnome stable repo with gnome 3.16 for 13.2, which I do particularly like because of the notification support. It also looks like I should be able to use susestudio to spit out a 13.2 iso already merged with the 3.16 repo! Current gnome and with far less pain than fedora...Now that would be very cool! And far more empowering than any other distro I had ever worked with, too....
2
Jos Poortvliet's profile photoTycho Softworks's profile photo
5 comments
 
+Jos Poortvliet​ indeed I gave some long consideration in choosing that word...
Add a comment...
People
In his circles
86 people
Have him in circles
106 people
Harvey Michele's profile photo
Sawi Yati's profile photo
Ayman Khalifa's profile photo
Alvin Sugar's profile photo
Robin Miller's profile photo
Mark Rushing's profile photo
Alison Chaiken's profile photo
Seth Johnson's profile photo
Igor Gnatenko's profile photo
Basic Information
Gender
Male
Work
Occupation
Vice Chief, Cherokees of Idaho
Links