I only recently checked the OpenSSL site and found out that they've changed their license from 4 clause BSD to an Apache style license. Many sites mention a license conflict between BSD 4 clause licenses and GNU GPL licenses. Several programs I use try to avoid the issue by adding a waiver to their license to allow linking with OpenSSL. Some examples are Dillo and D+. The issue can also be avoided in many cases by using software with a license other than the GNU GPL. So, the new switch to an Apache style license solves the license conflict issue in many cases (although it may cause new license conflict issues).

There's a useful reference on license information at the curl site:
https://curl.haxx.se/legal/licmix.html

There was an interesting thread about the GPL/BSD 4 clause license conflict on the lynx development list. Various SSL library options such as OpenSSL, gnutls and nss were discussed. It was mentioned that parts of the gnutls library (the compatibility layer) was licensed under GPLv3 which is incompatible with GPLv2 only ( https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ). The thread concluded with a recommendation to use the nss library to avoid license conflicts. It also mentioned that contacting everyone who worked on the project to re-license lynx would be too difficult. I guess there was some accommodation made after the thread because the latest version of lynx includes a COPYHEADER file that includes permission to use libraries such as OpenSSL and gnutls.

With the license change to OpenSSL, I hoped that the various license issues one might run across when building and distributing software that need SSL support had been solved. I've been using OpenSSL for a long time and it's always been highly portable and worked on a variety of platforms. However, when I downloaded the latest version of OpenSSL, I found that was no longer the case. With the various OpenSSL security issues in the news, work has been done to update the library and make it more secure. It appears, in this particular case, the security enhancements have come at the cost of portability. I used to be able to build OpenSSL using the ActiveState version of Perl. Now, OpenSSL is designed to only allow use of ActiveState or Windows native Perl builds using the Visual C++ compiler. If I continue to use the mingw compiler, I need a msys or cygwin based version of Perl. I'd previously built OpenSSL for DOS with no issues. Looking through some of the code, I'm afraid to even give it a try with the latest version of OpenSSL. OpenSSL is also much more dependent on Perl than it used to be. If I'm building a C library, it would be nice if it was only dependent on C code to build instead of requiring an interpreted language that's rather complicated to build.

I found it was time to either redesign my build of Perl (since a native Perl could no longer be used with MinGW to build OpenSSL) or to look for a new SSL library alternative. I'll share some of the results in my search for SSL library alternatives.

The major SSL options are OpenSSL, gnutls (with GNU GPL license) and nss (from Mozilla with Mozilla Public License). There are OpenSSL compatibility layers for gnutls (GPLv3 license) and nss ( Nss_compat_ossl originally from Fedora and no longer supported ). From some of the articles I read online, OpenSSL and nss were mentioned as more secure than gnutls. I also read that gnutls was a popular option on certain Linux systems such as Debian.

However, these aren't the only SSL libraries. There are several other options for embedded systems and other specialty uses. It's actually hard to track the options since the names of some of them keep changing. Typically, a program needs to offer support specifically for one or more of these library options because there usually isn't a compatibility layer to use that SSL library in place of a more common SSL library. Curl is a great example of a program that supports multiple SSL library options. D+ included support for cyassl. However, cyassl is now known as wolfssl. axtls looked like an interesting possibility because of its BSD license. It supposedly builds on Windows, but I didn't have any luck with it. Of all the various lightweight and/or embedded options, the only one I was able to get to build out of the box on Windows was mbedtls (formerly polarssl). mbedtls is available under a GPL license. Rather than try to track all the options and library name changes, I'll refer to the Wikipedia list:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

After the recent security issues with OpenSSL, there were also forks of OpenSSL. These include LibreSSL (a fork by the OpenBSD developers) and BoringSSL (by Google). I tried building BoringSSL, but it required an interpreter (similar to OpenSSL), so why not stick with OpenSSL instead of switching to BoringSSL. I also tried building some of the various SSL options with cmake and had no luck at all.

I'd tried building LibreSSL in the past with no luck either. The fork was originally just designed for BSD systems and support for other platforms was added later. There are even some posts on the Internet about how early versions of LibreSSL include issues that made it insecure on Linux and other non-BSD systems. Once support was added for other platforms, I ran into an issue with what platforms were supported. The developers only supported the MinGW64 project on Windows. I use a version of MinGW based on an earlier version of the original MinGW which has a more lenient license. I've been adapting the mingwrt and w32api libraries, but they're based on the original public domain licensed versions of the libraries. So, when I previously tried to build LibreSSL, it wasn't compatible with my MinGW compiler. However, after the various changes to OpenSSL, I decided to give LibreSSL another try. Was pleasantly surprised this time when it only required minor patching with my particular version of MinGW in order to get it to build. It also uses the standard GNU autotools style configure/make/make install rather than requiring Perl just to configure and build it. If anyone's interested in the patches, feel free to contact me about getting a copy.

At this point, I'm considering switching to the LibreSSL fork. Several Linux distributions that use musl as their main C library are using LibreSSL as their SSL library of choice. They included patches to get various libraries and programs to build with LibreSSL instead of OpenSSL. There are also some patches at the LibreSSL site.

However, there are still some issues with switching. Many of the programs that included a waiver for OpenSSL, do not provide a similar waiver for LibreSSL. I certainly be interested in hearing how others are handling this particular issue. It would be nice if LibreSSL users could contact some of these projects and ask about a waiver for LibreSSL as well as OpenSSL. Some of the projects that come to mind are D+, Dillo, lynx, opusfile. Curl, libarchive and libssh2 can also use LibreSSL instead of OpenSSL, but there aren't any issues with license conflicts unless one adds a GNU GPL licensed library or a similar incompatible license to the mix.

I'd be interested to hear what others use as their SSL library of choice when building cross-platform applications and why they chose that particular library. You can find further discussion of this topic on the CPPDesign mailing list ( http://www.distasis.com/connect.htm ).
I've covered SDL and FLTK based applications. Now I'd like to discuss pdcurses and ncurses based ones. ncurses is found on many POSIX systems especially Linux. pdcurses was used primarily on DOS and Windows systems. Support for X and SDL was later added. The X support uses some legacy functions, so it doesn't build well on modern Linux systems. However, the SDL support allows pdcurses to be ported to any system that supports the SDL library. That means it can run on systems like Syllable and Haiku not just POSIX systems with X Windows. ncurses worked only on POSIX systems for a long time, but more recently support was added for Windows and MinGW32.

So which is the better library to use? Depends on your needs. ncurses is very stable, provides good Unicode support on many operating systems and offers added functionality like panels, menus and forms. On POSIX systems, it runs in console mode, so you can run applications outside X Windows (or Wayland) or on systems with no X Windows installed. Applications built with ncurses can also be used via ssh and telnet. Unicode support for pdcurses is currently limited to UCS-2 (16 bits). It designed in such a way that expansion to UTF-8 or UTF-32 would mean major changes. It works in console mode, but on DOS/Windows only. You'll typically need X Windows if you run pdcurses on a POSIX systems. There are some work-arounds to this. You can use DirectFB or nano-x to run SDL in framebuffer and use pdcurses with the SDL backend. However, applications run in framebuffer mode aren't usable with ssh and telnet. You'll need something like vnc to remotely access them. There is also a pdcurses fork called win32a which provides native Windows support and better support for colors. pdcurses has some functions that are not typically standard with ncurses/curses such as specific mouse and clipboard functions. However, it lacks a lot of the extras that ncurses adds such as menu and form support. Both pdcurses and ncurses have functions for the standard ASCII character set and for wide characters (wchar). However, keep in mind that wchar is 16 bits on Windows (and DOS djgpp) systems and 32 bits on most POSIX systems (such as Linux and BSD). Personally, I prefer to use UTF-8 whenever possible for Unicode. I also prefer the new char32_t (or uint32_t if not available) in place of wchar_t in all my applications with internationalization support. However, pdcurses/ncurses aren't designed for these options. Of the two libraries, ncurses better supports characters in a Unicode character set beyond the initial 16 bits and is better designed to handle large character sets.

Even though ncurses has many advantages over pdcurses, I still like to work with pdcurses. It's a more compact library, with the backend code separated from the rest of the code to make it easy to port to other platforms. With this design and with its SDL support, it's easy to get pdcurses working on a wide variety of operating systems including some places ncurses has not been ported. As mentioned, libform and libmenu are not a part of pdcurses, but their functionality is available with ncurses. It turns out that other versions of curses did not originally have support for forms and menus and they were separate libraries. BSD still has libform and libmenu that work with its version of curses. I found it very easy to port libform and libmenu to work with pdcurses. There were some bugs in the libraries which I'm surprised no one has fixed yet, but I have patches for them. One other advantage of pdcurses built with SDL is that you can intermix SDL and pdcurses commands. pdcurses/ncurses are primarily console/text libraries. SDL offers graphics support. You can mix graphics from SDL with text from pdcurses and use pdcurses as a text user interface (GUI alternative) for SDL. That's a really nice option when developing SDL applications.

I've added SDL 2.x support to pdcurses, so it will port to systems that support SDL 1.x or SDL 2.x. pdcurses with the SDL backend, used bitmaps to represent characters. That curtailed Unicode support. I've added support to use SDL_TTF for drawing characters. Now the only limitation on characters that can be used with PDCurses is the 16 bit limit to the character size built into the system. It should be possible to expand that to 32 but it would require modifications that would affect the entire design. Also, since curses only supplies ASCII and wchar support for routines, a Windows (or DOS) system would still be limited to 16 bits. One would need a new set of routines with UTF-32 support or UTF-8 support. The current routines could not be used to support 32 bit characters on systems where wchar is limited to 16 bits. The ASCII functions are designed to work with one character at a time not several which UTF-8 might require.

Some of my patches for better internationalization support for pdcurses have been added back in to the official version of pdcurses. All of my pdcurses patches plus documentation on them and my build scripts can be found by following the archive link at http://www.distasis.com/cpp/lmbld.htm I'm interested in adding some of the win32a patches and continuing to improve support for internationalization in the future. If anyone wants to discuss design ideas for continuing to add better Unicode support for pdcurses, please contact me.

The good news with ncurses/pdcurses based applications is that it's relatively easy to port them from one version of curses to another in many cases. It may require changes in the names of header files. Non-portable functions such as those supporting a mouse may not be available on some systems. However, one can typically use any application designed for a particular version of curses with another version of curses. That does not mean ncurses/pdcurses applications can easily be ported to other operating systems. For instance, if an application uses functions that aren't very portable across platforms (such as fork which isn't easy to emulate on Windows and doesn't work on DOS), it will be very difficult to port that application. Unfortunately, many ncurses applications do just that and use POSIX functions that aren't widely ported to non-POSIX systems.

So, let's talk about some of the applications that I've found that do port across a variety of operating systems and can be built with pdcurses.

There are several ncurses based hex editors available. I personally like the interface for ncurses hexedit. It reminds me of the kzap program I used to use with DOS, so I find it user-friendly. shed is another interesting option. It handles large file sizes extremely well.
You can find the programs here:
http://www.rogoyski.com/adam/programs/hexedit/onlinedoc/hexedit.html
https://sourceforge.net/projects/shed/

I have patches/build scripts for ncurses hexedit to work with pdcurses and port to other platforms. I've built shed on Windows before, but haven't created my own build scripts/patch set for it yet.

There aren't a lot of music applications that work well in console mode and provide a text user interface, but there are some. The ones that come to mind are TiMidity++ and GramoFile. Make sure if you intend to work with TiMidity++ that you start with the source from version control not the very old, outdated tarball at Sourceforge. Many features, including better Karaoke midi support, have been added since the tarball was created. I find it discouraging that distributions such as Debian refuse to update to the latest supported version of this project. I always build TiMidity++ from source myself to make sure I have the updates I need. I'm currently working on a build script for TiMidity++ that will allow me to build it as a library so it can be used with other applications. I currently have build scripts for TiMidity++ and freepats (Open Source sound fonts used with TiMidity++) and gramofile.
https://sourceforge.net/projects/timidity/
http://www.opensourcepartners.nl/~costar/gramofile/

I originally looked for library versions of libform and libmenu because I thought a lot of curses applications would make use of these features. Turns out, not as many use it as I originally estimated. One program that makes use of the functionality for these libraries is ckpass. It's a console based password keeper that is compatible with KeePass 1.x format. That means, if you want a lightweight alternative to the earlier versions of KeePass or KeePassX, you can still have console access to your passwords. The program looks great and it's easy to use. Unfortunately, it offers just read-only support for viewing password information. There's no easy way to modify password information using the program. However, it isn't that hard to add code to allow editing as well as viewing of passwords using libform. I'm working on some modifications to ckpass to give it more functionality, so it will become a useful, more lightweight replacement to other password storage alternatives. There are other command line based password storage options available and some even use portable formats so that you can find cross-platform solutions. However, I like the idea that ckpass supports the KeePass 1.x format which many other GUI password programs also use. This is the link to the original ckpass project:
https://sourceforge.net/projects/ckpass/

The final category I'll cover is the text editor category. There are a great many text editors that work in console mode or build with ncurses as can be seen from the listings at TextEditors.org ( http://texteditors.org/cgi-bin/wiki.pl ). However, the large majority of them are not highly portable.

When the competition between vi and emacs comes up and people start debating what should be the default editor on a Unix or Linux system, I typically skip both and go with nano. nano was based on the pico text editor. It wasn't a fork. It was coded from scratch, so there would be no issues with code licenses. pico was the main editor for the alpine mail system. Compared to other editors with unusual key sequences that you need to memorize to get anything to work, I find it very user-friendly. It has a menu and easy access to help if you forget what command keys you need to perform a specific function. My personal preference is to use a programming editor that will allow you to map key commands however you see fit. That avoids large learning curves if you didn't originally use vi or emacs as your first text editor and memorize their commands. However, if a text editor with keymapping support is not available, a user-friendly text editor with easy to access command menus and help descriptions is a good second choice. Most POSIX systems I work with have either pico or nano available or they can be installed fairly easily. So, if I need to do a quick edit from the console on a POSIX system, my default editor is typically nano or pico. One major drawback to pico is that it only handles one file at a time. You cannot have multiple files open and flip between editing them or cut and paste between them. nano adds support for multiple files, but the commands to switch aren't particular easy to remember.

I did a port of nano to Windows several years ago. There's a lite way to build nano (tiny) and a way to build it with more functionality. Building it the lite way and adding some modifications for porting, I was able to compile it successfully on Windows. So, while it didn't provide all the functionality I used on POSIX systems, it did work on Windows. A few years ago, I found a Windows port of nano on github. It didn't provide extra functionality, but it was interesting to see how the author went about porting the application and the differences between my port and that one. According to the nano editor FAQ, it now looks like there's some official support for Win32. However, when I tried to build the latest version, I still ran across a lot of the same issues as when I built previous versions. Only the lite version is supported for Windows. There were some assumptions about MinGW types that aren't true for all versions of MinGW. Rather than using configure for what it was designed for and testing if there needs to be a work-around for a particular system, the code has ifdefs that assume MinGW always handles things wrong and tries to fix the situation. In the process, it causes errors in the build for MinGW systems that do handle the situation properly. Guess I'll need to stick with my port or a Windows specific port like the one at github if I want nano to build properly on Windows.

nano is a great lightweight alternative for a text editor that works on a large variety of operating systems. When I need to modify a file and want an editor to quickly call from the command line, it is often my editor of choice. You'll find the source code and more information on nano at:
https://www.nano-editor.org/

As I mentioned, I prefer programming editors that have good support for key-mapping. The scintilla text editing component offers just that. A large variety of Open Source editors, including SciTE (my favorite GUI editor) and fxite (lightweight FOX Toolkit based GUI editor), use the scintilla text editing component. While fxite is lightweight and works well on older systems, it requires X Windows on POSIX systems and the FOX Toolkit to build it from source. I wanted something even more lightweight. I did a search of the various editors that make use of the scintilla text editing component and I ran across textadept. It is a GUI text editor, but there's a ncurses based version that works from the console. I found it relatively easily to build the editor on Windows using pdcurses. So, it's rather portable. If I had to pick a console based editor besides nano and pico, textadept would be it.
https://foicica.com/textadept/

There are ncurses front ends to some applications I work with such as hunspell and prozilla, but I typically don't use the front ends. I prefer using hunspell via command line or integrated with a programming editor. There's a nice FLTK front end for prozilla that is highly portable. One other ncurses based application I'll mention is WordGrinder. I typically see it mentioned on sites and blogs that specialize in discussing console based applications. It has many of the features of a word processor. The current web site for it is:
http://cowlark.com/wordgrinder/

If you have other recommendations for useful, cross-platform portable ncurses/pdcurses/curses based applications, I'd love to hear ( http://www.distasis.com/connect.htm ) about them. It would be great to add more helpful applications to this list. I'm also very interested in the possibilities of using pdcurses/libmenu/libform as a text user interface (GUI alternative) for SDL applications.
The last post mentioned other groups' projects with dictionaries and language resources. I thought I'd mention some of the projects I've been working on in this area.

I've been creating build scripts with the LM BLD project ( http://www.distasis.com/cpp/lmbld.htm ) so that I'll have automated, repeatable steps to build programs, libraries and other types of packages. Here are some of things I've been working on.

The Moby project is a very nice dictionary resource. Using their thesaurus, I was able to create a word list and a simple dictionary in stardict format. I use it with Open Source programs like scramble.

The Strongs concordance is in the public domain. I've created a translation dictionary in stardict format with it.

I happen to like the stardict dictionary format. There are several nice programs that can work with that format. I wanted something lightweight that would work well on older systems or let me create my own GUI interfaces. The closest thing I could find to what I wanted was sdcv. However, there were a few issues I had with it. The biggest is that it requires glib as a dependency and I didn't want to install GTK+ related dependencies on my systems. The second issue I ran into was that it couldn't handle some of the newer versions of the stardict format. Since the code is GNU GPL licensed, I started with it and made several modifications and customizations. The result is sdcv2 which can be linked to my own Unicode shared libraries in place of glib if desired and can work with dictionaries in more recent stardict formats. It may not make use of all the latest features in the newer formats, but it can at least access information from them.

I've seen other projects that use the sdcv library as a back-end and create their own GUI for a dictionary program. It makes sense if the program uses GTK+, but it seems awkward for Qt or other GUI programs to require GTK+ related dependencies. With sdcv2, there are no GTK+ related dependencies.

I would love to find a dictionary with a FLTK GUI, especially if it can handle stardict format. Since, I haven't been able to find one, I may try to write one at some point. I've also been thinking about creating a pdcurses front end. When I use sdcv (or sdcv2) from the command line, certain systems like Windows can't handle input or output of certain Unicode characters correctly. I've added support for SDL 2.x, SDL2_ttf and the ability to work with a range of Unicode characters within the UCS-2 character set to pdcurses. I think pdcurses would make an interesting front end for a program using the sdcv2 library. It would work on any system that supports SDL 1.x or 2.x, including more unusual operating systems like Syllable and Haiku. Would like to hear from others who may be interested in or are working on similar projects.

The dictzip program compresses dictionary files. It uses an extension to the gzip format with extra fields to include information about the compressed dictionary. Files compressed with this format often use the .dz extension. You can use dictzip with stardict files to save space. dictzip is primarily a POSIX compliant program, so it doesn't convert well to certain systems. I was able to find a Windows port that limited the program's functionality, but did enough to get the job of compression done. I've made some modifications to it and am using it as a cross-platform method of compressing stardict dictionary files.

Several utilities and conversion programs were created for stardict in the stardict-tools project. Similar to stardict and sdcv, glib is a dependency for stardict-tools. There are a few tools that use a GTK+ front-end as well. I personally only use the stardict-tools to convert tab delimited files and files in babylon format to stardict. So, I modified the command line tools that do those conversions to build without glib. I also created my own makefile just to build the tools I use.

I've searched and I've yet to find a rhyming dictionary in stardict format. So, I'm working on creating one. It's a slow process. I've taken a public domain rhyming dictionary as a starting point and I'm in the process of editing it and converting it to the format I need.

I've also been searching for an Open Source C/C++ grammer checker, but I've yet to find one that I like.

These are just some of the projects I'm working on. If you're interested in comparing notes on these topics or if you have recommendations of other dictionary and word related projects you like, feel free to contact me ( http://www.distasis.com/contact.htm ).
It's hard to find public domain, Open Source and Creative Commons licensed language resources in formats that are easy for programs to work with. There are growing resources of scanned public domain books. Among them, you can find all kinds of dictionaries and references. Some sites even use an OCR to translate scanned documents to text formats. However, the translated versions are usually full of typographical errors.

There are a few projects out there that use Free, Open Source or Creative Commons licensing and have a goal of creating dictionaries or other references in accessible and searchable digital format, but not a lot. It would be nice to see more projects of this sort. The results could be useful with word processors and editors (such as LibreOffice, Abiword, SciTE), electronic dictionaries (such as stardict) and games (such as anagramarama and scramble).

Here are some of the projects I've located:

XDXF, the XML dictionary interchange format, project had a collection of dictionaries and language translation word lists they were working with and converting to various formats.
https://sourceforge.net/projects/xdxf/files/
They also have tools for converting between XDXF and other formats:
https://github.com/soshial/xdxf_makedict

The Moby project is a wonderful public domain resource. It includes word lists, thesaurus and more.
http://icon.shef.ac.uk/Moby/

The Free Dictionaries Project also provides downloads. If you want to translate one language to another, this is a useful, free resource:
http://www.dicts.info/uddl.php

SCOWL (Spell Checker Oriented Word Lists) and Friends has useful word lists and resources for spell checker utilities:
http://wordlist.aspell.net/

YAWL (Yet Another Word List) is based on the updated Public Domain ENABLE (Enhanced North American Benchmark Lexicon).
You can also find Libre licensed word lists in FLOSS games such as anagramarama.
http://www.sourcefiles.org/Games/Puzzle/Other_Word_Games/

Here's a rhyming dictionary (source code and online example) that uses Moby project resources to find rhymes:
http://stevehanov.ca/blog/index.php?id=8


If you know of other projects or developments in this area, I'd love to hear about them ( http://www.distasis.com/connect.htm ).",public,0,,
16253,2017-03-28 07:59:00,2017-03-28 11:59:20,"My projects with rhyming and language translation and other dictionaries, word lists and thesauri","The last post mentioned other groups' projects with dictionaries and language resources. I thought I'd mention some of the projects I've been working on in this area.

I've been creating build scripts with the LM BLD project ( http://www.distasis.com/cpp/lmbld.htm ) so that I'll have automated, repeatable steps to build programs, libraries and other types of packages. Here are some of things I've been working on.

The Moby project is a very nice dictionary resource. Using their thesaurus, I was able to create a word list and a simple dictionary in stardict format. I use it with Open Source programs like scramble.

The Strongs concordance is in the public domain. I've created a translation dictionary in stardict format with it.

I happen to like the stardict dictionary format. There are several nice programs that can work with that format. I wanted something lightweight that would work well on older systems or let me create my own GUI interfaces. The closest thing I could find to what I wanted was sdcv. However, there were a few issues I had with it. The biggest is that it requires glib as a dependency and I didn't want to install GTK+ related dependencies on my systems. The second issue I ran into was that it couldn't handle some of the newer versions of the stardict format. Since the code is GNU GPL licensed, I started with it and made several modifications and customizations. The result is sdcv2 which can be linked to my own Unicode shared libraries in place of glib if desired and can work with dictionaries in more recent stardict formats. It may not make use of all the latest features in the newer formats, but it can at least access information from them.

I've seen other projects that use the sdcv library as a back-end and create their own GUI for a dictionary program. It makes sense if the program uses GTK+, but it seems awkward for Qt or other GUI programs to require GTK+ related dependencies. With sdcv2, there are no GTK+ related dependencies.

I would love to find a dictionary with a FLTK GUI, especially if it can handle stardict format. Since, I haven't been able to find one, I may try to write one at some point. I've also been thinking about creating a pdcurses front end. When I use sdcv (or sdcv2) from the command line, certain systems like Windows can't handle input or output of certain Unicode characters correctly. I've added support for SDL 2.x, SDL2_ttf and the ability to work with a range of Unicode characters within the UCS-2 character set to pdcurses. I think pdcurses would make an interesting front end for a program using the sdcv2 library. It would work on any system that supports SDL 1.x or 2.x, including more unusual operating systems like Syllable and Haiku. Would like to hear from others who may be interested in or are working on similar projects.

The dictzip program compresses dictionary files. It uses an extension to the gzip format with extra fields to include information about the compressed dictionary. Files compressed with this format often use the .dz extension. You can use dictzip with stardict files to save space. dictzip is primarily a POSIX compliant program, so it doesn't convert well to certain systems. I was able to find a Windows port that limited the program's functionality, but did enough to get the job of compression done. I've made some modifications to it and am using it as a cross-platform method of compressing stardict dictionary files.

Several utilities and conversion programs were created for stardict in the stardict-tools project. Similar to stardict and sdcv, glib is a dependency for stardict-tools. There are a few tools that use a GTK+ front-end as well. I personally only use the stardict-tools to convert tab delimited files and files in babylon format to stardict. So, I modified the command line tools that do those conversions to build without glib. I also created my own makefile just to build the tools I use.

I've searched and I've yet to find a rhyming dictionary in stardict format. So, I'm working on creating one. It's a slow process. I've taken a public domain rhyming dictionary as a starting point and I'm in the process of editing it and converting it to the format I need.

I've also been searching for an Open Source C/C++ grammer checker, but I've yet to find one that I like.

These are just some of the projects I'm working on. If you're interested in comparing notes on these topics or if you have recommendations of other dictionary and word related projects you like, feel free to contact me ( http://www.distasis.com/contact.htm ).
There are some great Open Source applications out there for desktops and laptop machines, but it's much harder to find Open Source for mobile devices. Most mobile devices require their users to go through a proprietary app store just to get software onto their devices. This is a setup back for the Open Source movement since more and more people are turning to mobile devices as their primary computing source.

If you have suggestions and/or recommendations for FLOSS alternatives in the mobile space, please share them with me and other Free, Libre and Open Source advocates on the Schoolforge mailing list ( https://schoolforge.net/ ).


I'll share some Open Source options I've found to date for developing mobile and cloud based applications.


Cross-platform Mobile App Development

Here are a couple of very interesting projects that let developers create cross-platform mobile applications:

https://github.com/MoSync
Developers can use C/C++ which can be compiled to run natively on certain platforms or converted to Java bytecode output that can run on phones that only support Java applications. One can also develop HTML/CSS/JavaScript applications for phones that support those formats (similar to Cordova).

https://cordova.apache.org/
This project supports HTML/CSS/JavaScript development of applications that will work on a wide variety of mobile platforms.


C/C++ Mobile Development

If you want to port your own C/C++ programs or interesting Open Source C/C++ applications to mobile devices such as Android, these projects may be useful.

https://wiki.libsdl.org/Android
Information on using libSDL 2.x with Android.

https://github.com/georgp24/microwindows-android-bin
Port of Nano-X/MicroWindows to Android. Nano-X/MicroWindows supports a subset of simple X11 and Windows applications. Many FLTK applications port easily when run with Nano-X.

https://wiki.allegro.cc/index.php?title=Running_Allegro_applications_on_Android
Article on building and running Allegro based applications on Android.


C/C++ CGI Development

As a C/C++ programmer, I was surprised by how few CGI applications were built with these languages. Originally, I read that the reasoning behind this was that one would have to spawn a new process every time one wanted to run a C/C++ CGI program. Interpreted languages could be built into the web server and avoid spawning new processes. However, with the introduction of libraries such as FastCGI, the inefficiencies of running compiled programs as CGI applications is no longer an issue. From everything I've read, C/C++ CGI programs are much faster than other CGI programs if they avoid the process spawning issue. If you want a highly efficient CGI program, it's a good time to revisit using C/C++ with the proper libraries.

Here's some more information on FastCGI.
https://en.wikipedia.org/wiki/FastCGI

If anyone's interested, I have builds of FastCGI and Apache with fcgid support for Windows/MinGW (including patches to get them working on later versions of Windows).

https://sourceforge.net/projects/witty/
Wt is one of the few projects I've seen that tries to provide useful CGI functionality and routines for C/C++ programmers.


C/C++ on the Web

http://kripken.github.io/emscripten-site/
One can also use projects like emscripten to compile C/C++ code into JavaScript that will run on the web. It's an easy way to port your own C/C++ applications or run popular Open Source applications to the web.


JavaScript

Another area of web development that surprises me is when I see so many language alternatives to JavaScript. JavaScript is supported (in some fashion) by most browsers. However, other programming languages are not. In order to get other languages to work in a browser, they typically need to be converted back to JavaScript. In a case like emscripten, it can be useful to convert C/C++ to JavaScript for porting purposes. However, many new web projects are choosing other languages besides JavaScript (because developers prefer the language) and then using tools to convert those languages back to JavaScript so they'll work via the Internet. Often the conversions introduce a lot of unnecessary code or provide slower implementations than the original. If I'm porting a project that's already written, it's great to be able to move it over with projects like emscripten. However, if I'm writing something new for the web that requires a programming language, I always use JavaScript. It's more efficient to write something specifically for that language than rely on generated code converted from another language.

It's also nice to be able to write CGI in JavaScript and share the same functions, objects and code between the client (browser) and the server. This is one of the major benefits provided by projects like CommonJS. The CommonJS site used to maintain a very nice list of server side JavaScript implementations. Unfortunately, the CommonJS project appears to no longer be active. It's been replaced by more implementation specific solutions like node.js.

There are alternatives for running server side JavaScript other than node.js if you don't want to be locked into a particular web server.

One option is TeaJS which uses FastCGI and works with a variety of web servers including Apache and Nginx.
https://github.com/ondras/TeaJS

Another option is jsc which is a JavaScript implementation that is a part of Webkit (one of the most commonly used browser libraries).

There are also some interesting TinyJS implementations and forks at various code archives such as github. You'll find more details under my Scripting Languages post ( http://lmemsm.dreamwidth.org/2239.html ).
--- Free Software and Patent Policy ---

Patents can inhibit and encumber legal distribution of Free and Open Source software.

One might think that the best way to avoid patent issues would be to stick with Free software and Free operating systems. However, these distributions typically deal mainly with software free of copyright issues not patent issues. Patents may only be issues in some parts of the world and many Free operating systems feel justified in distributing patented code (source code only) as part of their freedom of speech.

Note that Free software and operating systems in this article correspond to the Free Software Foundation's definition of ""Free"" and is not necessarily equivalent to Open Source. The Free Software Foundation provides a list of what they consider Free operating systems at https://www.gnu.org/distros/free-distros.en.html

Debian is a good example of a mostly Free operating system ( https://www.gnu.org/distros/common-distros.en.html ). Unlike many completely Free operating system alternatives, its package repository is so extensive, one can find a variety of useful patent unencumbered options. They've also documented information on their polices regarding patented software. Perhaps surprisingly, the best places to find patent unencumbered and royalty-free operating systems are from commercial sources.

The following links give some information on Debian's policies toward patents and patent issues:


--- Patent Encumbered Software---

It's hard to pin down a definitive list of what software may be patent encumbered. Sometimes, even the developers of the software themselves are vague as to whether the software might infringe on patents or not. So, checking a program's web site for patent information may not always help. Typically, one will find software that uses certain compression/decompression algorithms or supports certain multimedia encoding/decoding on lists of patent encumbered software. Here are some lists of software that may have distribution issues.


--- Patent Unencumbered Multimedia Formats ---

One can help to avoid patent encumbered software by using royalty-free or patent unencumbered alternatives such as some of the following:


--- GIF format and LZW ---

A good example of patent related issues with software is the GIF format. Patents on LZW compression used by the GIF format were a main reason for creation of the PNG format. Even though the related LZW patents have expired, one still sees Free software that uses alternatives like libungif (library that encodes only uncompressed GIFs).


--- MPEG-1 issues ---

According to Wikipedia's article on smpeg ( http://en.wikipedia.org/wiki/SMPEG ), it sounds as if the MPEG-1 format is patent unencumbered. However, upon further reading they contradict the information in their MPEG-1 article ( http://en.wikipedia.org/wiki/MPEG-1 ) and state that a full MPEG-1 encoder/decoder cannot be implemented royalty-free because the MP3 audio format which is part of that standard still has several active patents on it.

One possible solution might be to remove the MP3 support in MPEG-1 software. It would be enough to allow viewing of educational information such as the MPEG 1 videos at:
HubbleSOURCE - http://hubblesource.stsci.edu/sources/video/clips/

--- Multimedia Patents ---

Information on when some multimedia patents expire:


--- Patent Unencumbered Software Options ---

This list covers software and builds of software that attempt to avoid patented code or code that is not royalty free.
  • xine-lib pruned - http://pkgs.fedoraproject.org/lookaside/pkgs/xine-lib/
    Pruned older version of xine-lib that has patent encumbered code stripped from it. Some lightweight xine front ends that can be used with it include xine-ui, flxine, toxine or vplayer. (Note: When I contacted the Fedora Project offering to help update this to a later version, they were very much against updating the pruned library and very impolite about the situation. I do have a later version of this library with patented code stripped.)

  • sox - http://sox.sourceforge.net/ - Sound eXchange, the Swiss Army knife of sound processing programs, can be built with only royalty free and patent unencumbered libraries and codecs.


Graphics programs that can built with patent unencumbered libraries and codecs include:


---===== FLIC Format =====---



---===== Animated PNG =====---



---===== Animated GIF =====---



---===== Ogg Theora =====---



---===== Ogg Vorbis =====---



The OpusFAQ - https://wiki.xiph.org/OpusFAQ - says that Ogg Vorbis and speex are being replaced by Opus. I haven't seen any Open Source projects specifically switch from Ogg Vorbis to Opus. However, Xiph.Org Foundation developers created Opus to replace Ogg Vorbis and recommend that projects switch to using the newer format.

---===== WebM and VPX =====---



--- Other Possibilities ---

As mentioned, one can remove the MP3 code from smpeg. There's a pruned older version of smpeg that does this. It might then be usable with other libraries and applications such as xine-lib, dumpmpeg.

Twolame - http://www.twolame.org/ - is optimized for MP2 (MPEG Audio Layer 2) and might provide an alternative to MP3.

--- What can you do? ---

The best way to encourage royalty-free and patent unencumbered software is to support Open formats that are patent unencumbered. As consumers, pick devices that can handle these Open formats. Share multimedia in patent unencumbered formats and encourage multimedia providers to offer these formats.

Here's a list of efforts to encourage patent unencumbered options.
Recently needed to find Open Source load testing software. A couple of things surprised me. Most were written in interpreted languages or Java. Most were platform specific and only worked on Linux or sometimes POSIX systems. Since my preferences are cross-platform C/C++ programs, it was difficult to find load testing software to my liking. Here's a list of some load testing programs that looked useful.

openwebload (aka openload) - http://openwebload.sourceforge.net/
This was the only cross-platform C++ program in the group. The major limitation was that it didn't seem to handle load testing of secure web sites (URLs with https). It also hasn't been updated or maintained in a while, but that never deters me.

wrk - https://github.com/wg/wrk
This was the most interesting of the options I found. It's configurable using lua scripts. However, I was only able to get it to hit one page at a site. So, if you want to emulate things like logging in and navigating a site, that could be difficult. wrk uses code from nginx and other Open Source projects. There are some sample lua scripts, but documentation on how to write your own was rather sparse.

httperf - http://www.labs.hpe.com/research/linux/httperf/
This looked like a very useful tool, but I received web responses mainly in the 300s (3xx) range for the URLs I was testing.

autobench - http://www.xenoclast.org/autobench/
This is a Perl script that works with httperf. It can run httperf multiple times and increase the number of connections each time. It can also output a graph of the results. Since httperf was returning 3xx web responses for my tests, autobench did so as well.

curl-loader - http://curl-loader.sourceforge.net/doc/faq.html
This looked like a highly configurable program that could perform some interesting tests including navigating sites. However, it was very hard to set up even after reading through whatever documentation I could find. I actually froze the test machine where curl-loader was installed at one point and had to restart the machine.

Apache bench - https://httpd.apache.org/docs/2.4/programs/ab.html
This is typically a part of an Apache installation but it can be used to load test other servers including nginx which was my target. Some articles said the technology used by this program was dated and that results might not provide a true picture. However, the program seemed to work fine for my test cases and didn't have an issue with secure URLs. The nice thing about it was that it was fairly simple to use compared to some of the other options.

It's also useful to have curl around when load testing. Once can check URLs with curl and see exactly what's being returned before using the URLs with the load test software.

July 2017

S M T W T F S
      1
234 5678
9101112131415
16171819202122
23242526272829
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 23rd, 2017 10:41 pm
Powered by Dreamwidth Studios