Profile

Cover photo
Tycho Softworks
107 followers|124,271 views
AboutPostsPhotosYouTube

Stream

Tycho Softworks

Shared publicly  - 
 
Truth finds a way of getting out...
5
1
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  - 
 
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...
In his circles
87 people
Have him in circles
107 people
David Sugar's profile photo
B Ulrich Ilboudo's profile photo
Birns Telecommunications Inc.'s profile photo
Robert A Burrows's profile photo
Mohd Iqbal Khan's profile photo
Leonel Reyes's profile photo
Orpharion Oroborus Bestheneme's profile photo
samuel barinas varela's profile photo
Fernando Monroy's profile photo

Tycho Softworks

Shared publicly  - 
 
Some time ago I did tribal copyright assignment. In fact, our tribe collectively holds copyright in a few GNU packages. I am similarly thinking of re-forming Tycho Softworks as a tribal enterprise.
1
Add a comment...

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  - 
 
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...
People
In his circles
87 people
Have him in circles
107 people
David Sugar's profile photo
B Ulrich Ilboudo's profile photo
Birns Telecommunications Inc.'s profile photo
Robert A Burrows's profile photo
Mohd Iqbal Khan's profile photo
Leonel Reyes's profile photo
Orpharion Oroborus Bestheneme's profile photo
samuel barinas varela's profile photo
Fernando Monroy's profile photo
Basic Information
Gender
Male
Work
Occupation
Vice Chief, Cherokees of Idaho
Links