Oops .. correction: ##slackware-help, not #slackware-help

Not just you, sir! I for one am glad that the BSDs remain a final fallback position, should the remaining Linux distributions fall to the enemy.

For the moment, however, the situation seems fairly static. Roughly 70 Linux distributions (about 25%) do not use systemd and show no signs of starting. http://without-systemd.org/wiki/inde...ithout_systemd

The systemd team tried to make more advances by weaponizing some software dependencies. First they tried deprecating the netlink device interface for a systemd-specific interface, but device driver developers are an unruly crowd of cats and shunned the new interface. Then they tried to introduce a systemd dependency to the kernel itself with kdbus/BUS1, but the Linux devs repeatedly rejected these patches.

Either of these moves, if successful, would have swept most of the resistance into the systemd fold. But they failed, so they declared victory and pretend it's fait accompli.

So the lines of battle have remained static for a while, but who knows when they might start up again on a new front.

If the worst happens, many of us will be glad to find final refuge with the BSDs.

Bah .. 676 views here on LQ, but only 61 of you clicked through to the actual article. Next time I'll paste a copy of the entire article into LQ, not just the link.

Update - CPAN modules have proven an unruly collection of software. It took a lot of stops and starts and more manual intervention than I would like, but I finally managed to test almost all of CPAN on -current.

Conclusion: perl-v5.18.0 looks pretty good!

None of the problems I encountered with any CPAN module seemed to be attributable to faults in perl.

When Slackware next updates perl, I'll be wanting to re-run the tests, but first I'd like to improve my test harness so that it requires less manual intervention.

The test harness will become an integral part of Slackhammer as well.

Thanks :-) I worry that spreading myself too thin puts projects like ##slackware-help in jeapordy, so your words of encouragement are appreciated.

Regrettably, most of my work is still in private cvs repos. I've been meaning to move them to Github, but mostly haven't.

Some of my older work is browsable at http://ciar.org/ttk/codecloset/ and my Github page is https://github.com/ttkciar/ (there's not much there).

Most of the scripts in the ttk-slackware-customizations repo are horrible, horrible. I'll be taking advantage of this project to clean them up, and wean them off of oddball module dependencies (KS and DR, primarily). Oh yeah, a lot of them don't work without modules which haven't been added to that repo yet, too.

It's very much a work in progress.

One of the regulars in ##slackware suggests using glib's hash table implementation (which I've not used) and Inline::C (which I have used, and like). He's seen 3x speedup this way vs native perl hashes: https://developer.gnome.org/glib/sta...sh-Tables.html . The main downside here is introducing a gnome dependency, but their implementation looks nicely complete.

Another regular pointed me at his own C hash table implementation, which also looks nice, though it needs a bit of fixing (which he might be taking care of now): http://tekk.in/dtype.tar.gz . Specifically, some declarations need to be changed so that it either uses Hash and List or TList, THash, and FHash. Also I'd want to replace his hash() with my own http://ciar.org/ttk/codecloset/libth-0.2.tar.gz implementation (which is about as fast as Google's CityHash, and generates more square output).

It occurs to me that if I write the code such that the functions which access/manipulate the intermediate format are encapsulated and isolated, I can use perl hashes first to get things working, and then replace those isolated functions with an Inline::C implementation, using either of these hash libraries.

Somewhat indirectly.

About fifteen years ago, I became interested in the material science of composite armor. One of my mentors in the subject, Paul Lakowski, invited me to the Tank-Net military forums, where I became acquainted with Anthony Williams, who is championing the GPC concept to the UK Defense Ministry and is a Tank-Net regular.

In order to understand armor, and to design armor to defeat a threat, it is necessary to become familiar with the threat it needs to defeat, which meant that my interest necessarily spilled over into the study of things which seek to penetrate armor -- long-rod penetrators, shaped charges, shell case fragments, and bullets.

To this end, I had already built out a few formulae for predicting the ballistic behavior of small-arms projectiles. Tank-Net is a gift culture, where everyone helps everyone else with their interests, and gets helped in turn with their own -- kind of like LQ, but with militaria rather than Linux. In this spirit, I tried to apply my formulae to the GPC discussions, to foment better understanding.

I quickly discovered that my formulae (which mostly dealt with penetration) were woefully insufficient to the subject. The GPC issue touches on matters of internal and external ballistics, and on more terminal ballistics than just penetration. Just as important are munition total weight, barrier defeat, and wounding, which I'd never considered before.

An engineer's got to engineer, and I've been digging in and figuring things out, collecting other people's formulae and a few of my own into Ballistics Perl modules which I can use in my perl calculator. These are still very much under development, and likely will be for some time.

The formula for estimating the weight of empty brass cartridges is somewhat wrong, for instance. It is fairly accurate when a cartridge was designed for a given volume and peak pressure, but many cartridges are actually derived from larger/heavier cartridges (the 6mm PPC from the .220 Russian, for instance, and the .243 WSSM from the .300 WSM), which makes them heavier than they "need" to be, and heavier than Physics::Ballistics::Internal::empty_brass() predicts. Thus some of the weights in my second GPC article are wrong, which is something the third GPC article will address.

I've started writing that article, but it's slow going. I want to touch on a wider variety of topics in it than I did in the first two articles, and it's in competition with other personal projects for my time and attention.