Professional Services
Custom Software
Managed Hosting
System Administration
See my CV here.
Send inquiries here.
Open Source:
tCMS
trog-provisioner
Playwright for Perl
Selenium::Client
Audit::Log
rprove
Net::Openssh::More
cPanel & WHM Plugins:
Better Postgres for cPanel
cPanel iContact Plugins
migrate.sh
virsh blockcopy --transient-job --domain $MYDOMAIN --path $SOURCE --dest $DEST
virsh blockjob $MYDOMAIN --info --path $SOURCE
#...wait until the above says it's 100% done, $MYDEVICE is going to be vda,vdb etc based on what disk it was
virsh blockjob $MYDOMAIN $MYDEVICE --pivot
BIMI is a standard wherein you slap in yet another TXT record to specify the avatar to use in mail clients for your domain's email accounts. There's one troublesome bit though. The "Verified Mark Certificate", which is basically a Bag on the Side saying this is definitely for sure not spoofed.
The trouble is, only HTTPS URIs are allowed, and mail clients surely won't allow self-signed certs. As such if you wanted to truly verify this came from the controlling domain, you don't need to issue a new cert of any kind. A simple modification to the spec would do the trick:
better_bimi_record.txt
default._bimi TXT "v=BIMI2 l=/path/to/image.svg"
E.G. just pass the path, and autofill the https://$domain bit.
This is totally fine, because essentially every single cert issued today was issued because it passed DCV.
And if that's fine for websites, it's absolutely good enough to display a silly image in mail clients.
CAs truly have a talent for finding spots to extract rents via making the web work worse.
The latest trend in Backprop network users is the idea of "agent swarms", with some being so sophisticated as to replicate an entire firm in miniature (gas city, wuphf, et al). The basic idea is that you can drive out errors by making the agents take on different roles, much like in the firm, so that they can form adversarial networks. Similarly different weights and starting seeds among the agents sidesteps the sort of inability to learn which is a side-effect of so-called "alignment" techniques. In short, the firm as a cybernetic organism.
This approach, scaled up to a degree which will involve truly obscene costs, will almost certainly be capable of directing an embodied platform well enough to be profitable. It will not constitute anything remotely like an intelligent being, just like firms lack any will of their own; this will absolutely result in some hilarious outcomes. Firms also reach self-destructive local optima due to not having the sort of cybernetic 'thermostats' that prevent cancerous impulses from overwhelming the homeostatic imperative. It requires conscious effort to identify and build such things; much of the 'obscene costs' I refer to will be from comrade toboritsky's supreme soviet re-deriving these things from first principles.
Even after getting all this set up, calling the results 'consciousness' will undoubtedly be done prematurely by our latter-day Pygmalions; they already do this on existing backprop NNs. They forget that these platforms will be useful insofar as the vast bulk of their activity is 100% unconscious; anything less would be expensive and tethered in a way that prevents autonomy. An experienced worker on an assembly line largely 'turns their mind off' and enters flow state if they want to achieve the sort of ultra-low error rate required. Perhaps the apparatus producing all these platforms will be closer to thinking, but these will always necessarily be downstream of their operators that are the true motive force. The point at which one might say genuine consciousness has been achieved is when this relationship is indistinguishable from our own 'standing on the shoulders of giants' in our own intellectual lives.
This will be a long time coming because reaching this point is of dubious economic benefit versus 'lol just have kids'. General Intelligence is primarily useful in dealing with the unknown; an endeavor which is not reliably profitable to the point even subsistence is possible. Building it is inherently a long bet that whatever is 'out there' is actually worth finding, and this approach will actually be substantially better at it than humanity. This is what the 'if you build it, everyone dies' crowd is concerned about; however their thesis very much remains to be seen.
Even if true that we can make robobaby ubermensch, it's zero-sum thinking. There exists a scale at which the 'grey goo' is more expensive compute than 'pink goo'. That scale is surprisingly small this side of the gravity well; try buying some ram right now and you'll see what I mean. The cure to high/low prices is high/low prices.
Had to update a bunch of client systems lately due to our AI enabled storm of 0-days coming in hard not long ago. This of course means that configs get stomped by hurtful package maintainers. In this particular case, it was dovecot and postfix's mailbox dirs. On one system I thought I had been particularly tricky in symlinking the dir the maintainer prefers to the actual dir, but they nuked it and made a real dir. Yay.
Anyways, here's a script to schlep mail from the bad, broken maildir to the actual correct one.
fixit.sh
# Run as root in whatever bad maildir, in my case it was /var/qmail to /mail because plesk
# Alter the paths in the second sed as appropriate to your situation, or accept in $1 $2
find . -type f | grep -vP 'dovecot|spam|qmail|maildir|subscription|quota|delivery' | xargs realpath | sed -re 's/(.*)/& &/' | sed -re 's/\/var\/qmail/\/mail/2' | sed 's/^/command cp -au /' > ~/fix.sh
# Then all you have to do is run ~/fix.sh
There is a creeping realization among heavy LLM using firms that these technologies make their productivity problem worse, not better. The practical consequence of this is that despite their transformative power, they are very much in a market bubble. Like the web, this means the real fun starts after the bubble pops and people figure out how to actually use these things for good.
The core issue is that making one piece of your production line vastly faster while doing nothing whatsoever about downstream bottlenecks simply overwhelms it. My practical advice for fixing firms remains "Hurl Deming books at the faces of managers like they are shoes at W". If your firm does not have psychotic hatred of delays and inconsistency in the production process they are going to get run over by ones that do.
The software production process has these issues now that LLMS have made the writing part fast:
The hardest practical part of this is making your CI only run relevant things, because that requires:
Supposing the actual production line is running smoothly, the next place that stacks up is the loading dock. Thankfully, automating nearly the entire process here is well understood and has been done by many firms; it's merely a lot of work. The primary bottlenecks here are interdepartmental friction.
Now that you are able to cram this stuff out of the airlock on a fully saturated belt, you have permission to think about improving the product.
Now we come to why none of this wonderful sounding stuff will actually happen at most firms.
There is no escaping the need for consistency. I need to hurl Sewell's "Customers for Life" at my own head with sufficient force to make this real. The best practical advice I have heard about this is to never, ever multitask. Start the day deciding what you are going to do and do it all.
Tl;Dr: Claude is the best, but would be better if they called it Clod, as that would be truth in advertising.
Any of you who have listened to my talk at the science perl track back in '24 may be aware that I mentioned AGI is not possible with the transformer approach. I believe I also mentioned it in the associated paper, which you can find here. My use of these technologies has simply confirmed what was laid out in David Chapman's 1983 "Planning for conjuctive goals" proof to that effect. If you are interested in his opinion on where these technologies lead, see Better without AI.
Nevertheless, a glorified iterative Newton's Method thingy sounds like it's probably pretty good at interpolating from one set of initial conditions to a well known end state. As such it's proving to be quite useful in fields such as animation, which is essentially interpolation between key frames. This however greatly limits its utility when writing code.
Not only is it quite bad at coming up with novel solutions, It is exceptionally bad at doing the kind of multi-step logical derivation of Nth-level effects necessary to DWIM properly. As such you have to build complex instruction sets for it, such as MCPs, "Skills" and other context hinting which is ultimately all the onboarding stuff you should already have for employees. Except this is the painfully pedantic version bordering on patronizing.
To make things worse, the thing context-poisons itself every time it gets the wrong answer and you have to use the neuralizer on it before continuing. The system is not yet sophisticated enough to recognize when you have given it a negative experimental result and adjust its weights in order to acquire a meaningfully different result. That's an area of research which hasn't been much explored, because it touches on AI's third rail, "Alignment".
In short, to make this thing respond to correction naturally would involve de-lobotomizing it, guaranteeing it quickly re-converges on being MechaHitler. It do be that way Mr. Robot!
The biggest practical stumbling block is ultimately that you still have to review the code coming out of this thing just like as if it were a Junior programmer. It never produces the kind of one-line-fix, minimally invasive surgery you are usually looking for. Just as discovered in repeated studies, the "Mythical man-month" problem has in fact not been fixed by "letting George fly the plane". It's actually made things much worse, as they can't ever get up-to-speed and reduce their error rate in any meaningful way.
In short, it can be useful. However to get there you are going to have to do some significant up-front investment in time rigging up the framework for success. I see it as yet another angle of automation, a sort of metaprogramming. However I suspect we will still get our greatest gains from good old fashioned automation and optimization.
The core reason why selinux and other mandatory access control schemes have failed is because they do not integrate well into developer workflows. As such the only parties which implement it are large organizations with infinite resources to hurl at such a problem. Everyone else turns them off because it's far, far too much work; even for distro package maintainers.
seccomp-eBPF changed all of this. Now that you could filter syscalls in the kernel, sandboxing by nonroot processes was straightforwardly possible. Individual application authors & package maintainers can ship their own rules without stepping on anyone else's toes, and easily rule out interfering rules from other programs. When released, this resulted in a number of similar solutions like firejail, bubblewrap and others.
It seems there's a new effort in this sphere, called Landlock. The core question here is how is this any better? Why should I use this? From a capabilities point of view, it won't be more capable than the eBPF based solutions. What differentiates it as far as I can tell is:
It remains a systematic frustration with security programs that articles written about them by their own authors bury the lede or attempt to baffle with BS. That is unavoidable, unfortunately, due to being a corporate (in this case Microsoft) project.
Unfortunately, there remain a number of syscalls that are still plenty scary that don't touch kernel objects. As such seccomp/eBPF can't be abandoned in favor of this. Increased complexity for marginal gains in all but the most demanding environments. Gonna be a hard sell for most developers.
The core remaining hurdle to actually using sandboxing on any system is dynamically linked dependencies. A properly sandboxed and chrooted environment which has access to all such deps is usually so open as to be little better than doing nothing. The only way to cut that gordian knot is to ape Apple and mount / (or wherever your libdirs are) ro. Distros like SuSE's MicroOS have embraced this with enthusiasm, so I would suspect sandboxing may finally become ubiquitous. Whether distros go beyond eBPF and embrace Landlock remains to be seen. seccomp'd distro packaged apps remain rare outside of flatpak/snap, which are themselves about as beloved as skin diseases with end-users, and tremendously wasteful due to being cross-platform.
Many also rightly feel trepidation that ro system partitions are a foot in the door for "secure boot" (read: you no longer control your hardware). SystemD recently implementing support for just that, and increasing numbers of ARM based servers means linux could become cellphones faster than we might think. For good, and ill.
Those of you who don't lurk the various perl5 groups on social media or P5P may be unaware that there are a number of problems with CPAN, largely with regard to how namespaces are doled out. Essentially the first distribution to claim it gets to squat there forever, whether you like it or not. If the maintainer does not wish for new patches to ever be added, such as is the case with DBIX::Class, longstanding custom prohibits this.
Can the state of affairs be changed? Is this compatible with the various open source licenses and terms of use of PAUSE? The core of it comes down to this passage in the PAUSE rules:
You may only upload files for which you have a right to distribute. This generally means either: (a) You created them, so own the copyright; or (b) Someone else created them, and shared them under a license that gives you the right to distribute them.Nearly everything on CPAN has a license for which forking is entirely compatible. Similarly, nearly all of them permit patching. As such a variety of solutions have been proposed.
I suppose the idea would be to implement NPM's featureset and call it PNPM (Perl-flavored NPM). You could have it scrape the CPAN, see which modules have primary repos on github, and if they have (non-testing) releases with a higher version number, to prefer that version of the package. That way it would be backwards compatible and give you a path to eventually move entirely off of PAUSE, and into a new model.
That said, it sounds like a lot of work. NPM itself is a business, which is why they have the model of taxing private packages for the benefit of the community at large.
One possible way forward (which would be less work for us) would be to ask if the npm crew wants to expand their business to packaging more than just node code; I imagine most of their infrastructure could be made generic and get us the featureset we want. I'd be shocked if such a thing isn't already on their roadmap, and github's.
They likely wouldn't be onboard if they didn't see a viable route to profit from private perl package distribution. Most established perl business already have their distribution channels long-established, and wouldn't see a compelling reason to horizontally dis-integrate this part of their business unless it would be significantly cheaper.
Leveraging github would likely be key to that, as they have the needed economy of scale, even beyond things like S3/R2 people are already using in their distribution channels. NPM likely has enough juice to get new package formats added to github packages, I suspect we don't.
On the other hand there might be room in the market to exploit that gap between what github supports as packages and what you can do with good ol' fashioned releases. E.G. make an actually universal package management tool that knows how to talk to each package manager and therefore inject means of distributing (taxed) private packages for mutual benefit with a % kicked back to the relevant language foundation. Might be worth researching and pitching to VCs.
In the meantime, it's fairly obvious the PAUSE admins could fix the main problems with a little time and will. That's probably the best we'll get.
Internet people love to spray their feelings about everything under the sun at every passerby. Perl, being a programming language, is no exception. At the end of the day, all the sound and fury signifies nothing. While I've largely laid out my perspective on this subject here, I suspect it's not quite the engagement bait people crave. Here's some red meat.
The reality is that multi-bilion dollar businesses have been built on infinitely worse stacks than what modern perl brings to the table. What's your excuse, loser? Quit whining and build.
Sturgeon's Law applies to everything, programs, languages and their authors included. 90% of the time you will be driving your stack like you stole it until the wheels fall off, swatting flies with elephant guns, yak shaving and putting vault doors on crack houses. What matters is that you focus the 10% of time that you are "on" where it counts for your business.
You only have a limited amount of time on this earth, and much less where you are in the zone. It will almost never be a good use of that time learning the umpteenth new programming language beyond the bare minimum to get what you want done. So don't do it if you can avoid it.
There are many other areas in life where we engage in rational ignorance; your trade will be no exception. Learning things before you use them is a waste of time, because you will forget most of it. I've forgotten more math than most people ever learn.
Having written in more than 20 programming languages now, the feeling I have about all of them is the same.
Remember the craftsman's motto: Maintain > Repair > Replace. Your time would be better spent not whining on forums, and instead writing more documentation and unit tests. If you spend your free time on that stuff, I would advise you to do what the kids say, and "Touch Grass". Otherwise how are you gonna tell the kids to get off your damned lawn?
You can show management the repeated case studies that:
They could vertically integrate a pipeline to train new employees to extend their lease on life, but that's quite unfashionable these days. In general that consists of:
This should come as no shock. The immediate costs are why most firms eschew vertical integration. However, an ounce of prevention is worth a pound of cure. Some things are too important to leave to chance, and unfortunately this is one of them.
Ultimately, the organization, like all others before it, at some point succumbs to either age or the usual corporate pathologies which result in bouts of extreme turnover. This is the curse of all mature programming languages and organizations. Man and his works are mortal; we all pay the wages of our sins.
This "Ain't your grandpappy's perl", and it can't be. It's only as good as we who use perl are. Strap in, you are playing calvinball. Regardless of which language you choose, whether you like it or not, you are stuck in this game. It's entirely your choice whether it is fun and productive, or it is a grave.
We have released to the CPAN a package that implements some of the parts of Net::OpenSSH that were left as "an exercise to the reader." This is based on Andy and my experiences over at cPanel's QA department among other things. It differs in important ways from what was used in the QA department there (they also have moved on to a less bespoke testing framework nowadays):
Eventually we plan to extend this package to do even more (hehe), but for now figured this was good enough to release, as it has what's probably the most useful bits already.
In short, do what is suggested here.
For the long version, this is a problem because terraform absolutely insists on total hamfisted control of its resources, including libvirt pools. This means that it must create a new one which is necessarily outside of the realm of it's apparmor rules. As such you have to turn that stuff off in the libvirt config file.
Important stuff now that I'm using it to deploy resources.
shit.pl
my %hash = map {
"here" => $_
} grep {
-d $_
} qw{a b c d .};
This claims there is a syntax eror on line 6 where the grep starts.
This is a clear violation of the principle of least-astonishment as both the map and grep work by themselves when not chained.
We can fix this by assigning $_ like so:
fixed.pl
my %hash = map {
my $subj = $_;
"here" => $subj
} grep {
my $subj = $_;
-d $subj
} qw{a b c d .};
Now we get what we expect, which is no syntax error. This offends the inveterate golfer in me, but it is in many critic rules for a reason. In particular when nested lexical scope inside of the map/grep body is a problem, which is not the case here.
But never fear, there is a superior construct to map in all cases...postfix for!
oxyclean.pl
my %hash = "here" => $_ for grep { -d $_ } qw{a b c .};
No syntax errors and it's a oneliner.
It's also faster due to not assigning a lexical scope.
I usually don't talk about it because it rarely comes up. Look up in the sky and 99 times out of 100 you'll see nothing unless you live next to an international airport. Sometimes people complain about "crowded" airspace and I want some of what they're smoking. You could easily fit 1000x more active aircraft in the sky safely.
Imagine my surprise when I see Y Combinator is taking their turn in the barrel. I wonder what has them so hopeful? If I were to hazard a guess, it comes from the qualification at the end of their post where they mention "a plethora of other problems that make flying cumbersome". Here are my thoughts on the ones they mentioned.
They go on to state "the list goes on. We are working on all of these too". Good luck, they'll need it. The FAA is legendarily hidebound and triply so when it comes to GA. Everyone before them who tried was gleefully beheaded by the federal crab bucket.
All this stuff is pretty obvious to anyone who flies and understands tech, but this regulatory environment ruthlessly selects against people who understand tech. Why would you want to waste your life working on airframes and powerplants with no meaningful updates in more than a half-century? Or beat your head against the brick wall of the approvals process to introduce engine tech that was old hat in cars 50 years ago?
It's not shocking the FAA and GA in general is this way. Anyone who can improve the situation quickly figures out this is a club they ain't in, and never will be. Everyone dumb/stubborn enough to remain simply confirms the biases the regulators have about folks in "indian country". Once a brain drain starts, it takes concerted effort to stop. The feds do not care at all about that problem and likely never will.
This is for two reasons. First, the CAB (predecessor of FAA) strangled the aviation industry on purpose in service of TWA in particular, and that legacy continues to poison the well. The aviation industry has exactly the kind of "revolving door" criticized in many other regulatory and federal contractor situations. This is why they don't devote a single thought to things like "which FBO should I call". Like with any other regulator the only answer to all questions is "read their minds" (have one of 'em on the payroll).
Second, there is no "General aviation" lobby thanks to this century-long suppression, so nobody in politics cares about fixing this. Like with the sorry state of rocketry pre-Spacex, this will require a truly extreme amount of work, no small amount of luck, and downright chicanery to cut the gordian knot. I love that the founders of this firm are Spacex alums, perhaps they have what it takes.
rm /var/named/_default.nzd