hercynium

https://arstechnica.com/science/2026/08/parasitic-zombie-fun...

Still, it looks pretty neat. Thanks for sharing!

I can't speak to how good the actual product is today (or even when it launched, but that's a whole 'nother story), but during development it was capable of processing 100K RPS in a footprint of ~30MB RAM with ~98% accuracy compared to WURFL as a baseline.

[1] https://jeffreykegler.github.io/Marpa-web-site/

Background: I've lived my entire adult life (and most of my teens) with severe chronic depression. In my early 20's I started taking pharmaceutical treatment, and once I found the right drug (after trying many over the course of years) my life became manageable. SSRIs helped but I experienced severe nausea on most of them, or worse. It was only when I tried SNRIs like Effexor that things started to get better. YMMV, IANAPsychiatrist, etc, etc.

A few years ago I switched from Effexor to Cymbalta. Same class of drug - The Effexor simply wasn't helping as much as it used to and the switchover was done with a long taper-down and replace period. I even bought a lab-grade scale to measure out the contents of the capsules so I could cross-over smoothly.

All that said, Cymbalta has the same withdrawal effects, on about the same time scale - a single missed dose. But I wouldn't give it up unless something better comes along. I still struggle with my depression and the SNRI is just one tool in my toolbox for managing it.

Edit: Specifically, Perl 5 + CPAN is what makes it so much better than many people think. The language itself is insanely flexible, which lends itself to extensions that greatly increase its expressiveness. IMO, if you start with Moose (from the CPAN) as part of your "core library" Perl 5 becomes a very powerful tool for writing very nice code, at any scale.

My $employer paid Hortonworks for a support contract and I have no qualms declaring publicly that it was a total and utter scam. (We are a Java shop and know our shit)

If I go into too much detail I'll write countless pages like my internal report on why we needed to switch, but the bottom line is that Cloudera's products are well and honestly documented, while, as of last year, Hortonworks' products are simply one land-mine after another.

Their management platform (Cloudera manager) being closed-source is barely a mark on the comparison analysis when you compare it to Ambari in practice. Ambari is a bad joke and I'd rather do without it after spending significant time using it and trying to extend it.

And I could go into excruciating detail as to how Hortonworks abuses the Apache License to try and force lock-in. It's disgusting and pathetic.

  * For a graphical IDE: Komodo or Padre or Eclipse with EPIC (great debugger support in those, since Perl 5's built-in debugger is pretty old-skool, requiring significant skill and experience to use effectively)
  * For code quality/standards static analysis: Perl::Critic
  * For performance profiling: Devel::NYTProf (seriously one of the best profilers I've used in any language)
  * For test coverage analysis: Devel::Cover
  * For benchmarking: Benchmark (core module) and friends
  * A REPL: Devel::REPL or Reply
  * On-demand debugging: Enbugger and Devel::Trepan
  * Unit testing: Test::More (and there are many, many other Test::* modules for anything you can think of that use the same general testing framework as the basic Test module that comes with Perl 5)

Now, my current employer... Email your manager: "I wrote this entirely in-house and would like to open-source it." Manager: "OK, let's talk to Legal" Legal: "OK, get at least one other person to verify that it doesn't contain any trade secrets and sign this." Upload to github. Done.

And submitting patches upstream - just a matter of code-review and sending it out. Now that's OSS-friendly.

Wayland has been a long time coming, and I do hope that's because those working on it are really shooting to get things right. Mir is interesting, and it looks like it will be able to do some things that Wayland/Weston can't, or would require some difficult hacks or even spec changes to make work. I don't know if Mir would be better than Wayland for me, but if you ignore all the FUD from both sides, I think the bottom line is that Mir is better for Canonical's plans unless or until Wayland/Weston can be changed to accommodate their needs.

I personally have no positive or negative opinion on Mir vs. Wayland, but I hope that at least one truly delivers on their potential and shows a clear improvement over our old trusty ;) X11/Xorg.

In addition, GNOME is busily porting everything to work on Wayland. I think when that is finally done, we will begin to actually get Wayland-by-default on a few dists, and from there, well... that depends on how well it works!

Links to additional info:

  https://fedoraproject.org/wiki/Changes/Wayland
  http://blogs.gnome.org/uraeus/2013/09/09/fedora-wayland-update/
  http://fedoramagazine.org/?p=538
  https://wiki.gnome.org/Initiatives/Wayland
  https://wiki.gnome.org/ThreePointEleven/Features/WaylandSupport

This isn't a SSL cert screw-up, but certainly a silly misconfiguration. They should certainly have known better than to let that happen.

To be fair... when I worked there, I thought about different ways to transparently enable SSL across all domains using a CDN that would work with all existing SSL-enabled browsers and it's a freakin' hard problem. There are potential solutions, but they're not particularly cheap or simple given the IPv4 address crunch and for Akamai even more so since the edge servers are so widely distributed.

Bottom line - I never pitched the idea anyway because while I was interested in making the internet a better place, I knew that it was DOA at Akamai because they're much more interested in making it a more profitable place, and I couldn't think of a strong-enough business case...

Oh, and people in other industries have told me it's par for the course everywhere.

This is why networking is so important. That's my main advice to give. Meetups, user-groups, etc... get involved in them and do your best to learn, interact, and "level up" (to steal a brilliant recruitment/marketing slogan from the big A)

I speak ill of them all the time. Not about their impressive infrastructure and engineering, or the scores of brilliant people I had the privilege to work with. No, it was more my experience with the corporate culture and the pervasive games of "power politics" that anybody who wasn't a manager was constantly subject to. Unfortunately I ended up in a position to be the patsy for a director's bad decisions, to make a long story short.

Indeed, I was asked to sign an agreement in exchange for money, and because of the timing of things (newborn baby 2.5 weeks prior) I needed the money more than I needed the freedom to speak my mind about the situation. And it really wasn't very much money, just like in the linked article.

However, despite sending the signed agreement certified mail, the money never showed up, their HR department claims it was never received, and the money didn't end up mattering so much as I was fielding offers within a month and began my current position in short order.

Since then I've received several letters from them, asking for my signature on various things and I refuse - There's simply nothing they can do to me. But I know quite well that I'm lucky. I've got a skill set and experience that puts me in demand, and anybody who asks why I was fired can get a simple answer: "Here's my LinkedIn profile, take note of the slew of recommendations I got within a week of my termination."

(I will add, my subsequent contact with their HR and legal department did have me worried about things for a while - not to mention various thinly-veiled verbal threats made by my former director before and during my termination, in case you're wondering just what kind of politics and culture made me dislike the place)

Though I don't know Haskell, ML, or Rust, I do know Java, Clojure, C++, and a few other languages quite well.

In a nutshell, I like type-checking and smart-pointers, and module systems and such. They often save me lots of trouble! But not all the time. Sometimes, these features get in the way - either to making the code more flexible, or to making the code more readable. (casts dirty look at Java)

But at the end of the day, no matter how precisely one can communicate to the compiler, and no matter how good one's compiler is at detecting (or even correcting) inconsistency, flawed logic, corner-cases, over-specificity and under-specificity (or the reverse of genericity, take your pick)... We puny-brained humans still manage to screw things up. The compiler can't read the spec, never mind actually cognitively understand the problem trying to be solved... so it's up to us to attempt to translate.

And fill in the inevitable gaps.

And attempt to anticipate future needs.

And finish on-time.

With our pitiful, buggy, meat-based processing organs.

Sure, "readability", "maintainability", and "understandability" are all pretty subjective, but that's part of the point. With the languages I've used, I find that sometimes the "safety mechanisms" get in the way. Working around them with "design patterns" tends to add code that might not otherwise be necessary. And might contain more bugs. I'm sure I'm missing something life-changing by not knowing Haskell or ML, but more important to me is that the code I write be, well... "readable", "maintainable", and "understandable" by whomever might be working on it (fixing, extending, whatever) next!

'Cause experience has shown me that bugs happen. And I want finding and fixing them to hurt as little as possible - whether it be me or some other poor fool.

Oh... also, I couldn't help but have a snarky response to your last remark: (no offense intended :)

> I see writing buggy code as negative productivity. So a language that gives you the illusion that you are writing correct code, when you in fact are not, actually makes you less productive.

FTFY: I see writing buggy code as inevitable. So a language that gives you the illusion that you are writing correct code, (by sucessfully compiling) when you in fact are not, actually makes you less productive.

https://en.wikipedia.org/wiki/Larry_Wall#Education

He talks about it in more depth in this interview: http://youtu.be/aNAtbYSxzuA

This is an interesting statement to me, and one that I think may be telling towards the author's experience as a programmer. This is not my way of saying he is a poor or inexperienced programmer! I skimmed through a few other articles on the site and what stood out to me is that he is heavily "academic." Some of the best programmers I have worked with had deep academic experience and were quite adept at writing fast, concise, correct code in many different languages.

What stands out to me is the absence of something that (as is my personal observation) most experienced programmers in non-academic settings begin to realize at some point... While avoiding bugs (by, for example, choosing a language with strict type-checking, or immutable data/vars) is quite important, writing code that can be easily corrected is arguably just as important!

In regards to just the use of a programming language, this comes down to choosing a careful balance of constructs - syntax, features, naming, etc. Coding standards for a project or organization are not just there to stoke somebody's ego or cater to the "lowest common denominator". Well-chosen standards and conventions are there to simultaneously avoid bugs and make code easier to debug and maintain - which is what one must do to make corrections!

It is therefore crucial to insist on it when choosing (or designing) one.

This sentence is what really drove me to comment: No programming language can prevent all bugs. Not even most bugs.

In practice, I have even found that constructs and limitations that are intended to prevent bugs of one type can lead to bugs of some other type. In the worst cases, these limitations can lead to programmers making code that is much more verbose and complicated, which, of course... leads to more bugs that are harder to correct.

IMO, one should choose a language based on many, many more criteria than "avoidance of bugs." Personally, one of my top criteria is to choose a language with which those who will write and maintain the software (now and in the future) are going to be most productive.

/obligatory