Shameless plug: my earlier project StaticPerl, statically linked Perl 5.10 for i386 Linux and FreeBSD: https://github.com/pts/staticperl
Differences:
* Actually Portable Perl runs on more operating systems, StaticPerl runs on Linux i386 (requiring i686 or newer processor), Linux amd64 and FreeBSD with Linux emulation.
* Actually Portable Perl has more of the standard Perl modules and C extensions bundled. StaticPerl contains only a few modules, simplified, with documentation and non-Linux support removed. StaticPerl is unlikely to work with existing Perl scripts with many use calls, but it is useful to write new Perl scripts from scratch, and these scripts will work with both StaticPerl and regular Perl.
* Actually Portable Perl executable programs are larger (5 MB minimum, StaticPerl is ~1 MB) because they are compiled for amd64 rather than i386, and they contain more Perl and C code.
* The first time an Actually Portable Perl executable program is run, it modifies a few bytes at the beginning of the program file (except on Windows). Thus these programs don't work on read-only filesystems unless they have been run on a read-write filesystem first. StaticPerl doesn't have this limitation.
Author here. Nice comparison. By default (and the released) APPerl binaries do not self-modify (they use the non-self modifying ape loader) however on unix-like they install the APE loader to`$HOME/.ape`and use that ELF executable to run the APE. To skip the fork+exec to the ape loader, they can be assimilated with `--assimilate`, that does turn the APE executable into ELF.
There is a kernel patch to add APE (Actually Portable Executable) support to Linux removing the need for the the apeloader or assimilating. I'm not sure what the status is on that.
I forgot to mention APPerl and StaticPerl have many overlapping use cases, but APPerl is more tailored to application packaging. APPerl is built with a patch to Perl adding argv[0] script execution, allowing the APPerl binary to turn into a binary for any of the embedded scripts, with a rename or symlink rather then needing to pass flags the Perl executable to load modules.
Update on the APE Linux kernel support (for fork/ --assimilate)less APE execution. jart informed me: "It's in the process of being emailed out to the kernel developers. I anticipate it'll be merged within the next three months."
Could you suggest a way to do electron-like apps in APPerl?
I'm thinking of serving content on 127.0.0.2. There is no need for a high performance server like nginx, but serving files and having some CGI capability would be a plus.
I'd be interested in suggestions for the HTTP server part and maybe an example for how do serve an index.pl file that reads payload files packaged in the APPerl binary (ex: .js, .jpg)
Perl is really one of the best languages and in modern times is underrated. I've been using it in production for most of my critical services since about 2012. I've used many other languages since then but always keep coming back to perl. It's a true gem of a language.
It's grand child, Raku, also seems to be an impressive language actually. Hated by Perlers and non-Perlers alike, it actually would be a great environment to build powerful programs in:
I messed around with Raku and it is seriously underrated. If anyone hasn't yet I would recommend giving it a try. It still does all the cool stuff Perl 5 can do but with the features you would expect from a modern language baked in. Raku and the core modules are solid and can be used in production but unfortunately the overall ecosystem is still struggling. 3rd party modules can be hit or miss. I found several of them weren't well maintained or seemed abandoned.
Yeah I wish Raku would pick up some steam. It’s the only newish language I’ve looked at that’s made me say wow and it cleans up some of the thorny Perl5 sigil issues.
I don't think anyone hates it, but there were many people who were looking for a solid release that ran fast-enough. There was also... drama, which I feel no one cares for.
I admit the only time I reach for Perl is when I need a really strong and dependable regex service. Still one of the best ways to parse text to this day. Perl text parsing capabilities are nearly unrivaled still.
What do you typically use perl for? I thought it was most commonly used for scripting and running cgi scripts. I find bash to be much more readable and tend to use it or python for most of my scripts
Lol, you find bash readable? With all its weird ad-hoc constructs? I don’t pretend Perl looks pretty but at least its constructs seem to be consciously designed and do not look bolted on.
At my work place we still maintain a huge web application written in Perl 5. Most of the time if we are in trouble it‘s due to bad architectural designs that are not specific to Perl as a language or ecosystem. Only rarely I stumble over issues like implicit returns, or context sensitive sub routines. Also I hate Perl 5 allowing circular includes. The worst offenders among in-house modules are Perl modules written in a Java-esque style which mostly would have benefitted well from using native Perl features instead of trying to mimick Java programs.
The sad thing is that once, a while ago, there was an attempt to compete with the new market of scripting languages (Perl, Tcl) from a shell perspective. The result being Korn Shell, especially ksh93, and tools like dtksh (which allowed Motif UI apps to be written in shell).
Compared to that, bash is really anemic.
Python took Perl's money a bit when it came to scripting, Ruby – clearly influenced a lot by Perl – made big grounds in web apps, once they outgrew CGIs, and of course then we collectively got Javascript Stockholm syndrome.
But seriously, they're all good dogs. We all revel in the Narcicissm of Small Differences, but in the end it wouldn't really matter if we used Perl instead of Python or any other algol-ish imperative OO language with some functional bits.
I learned Perl in the mid-1990's. I'm in semiconductor design and most of our CAD tools use Tcl so I write a lot of that but for any text report processing or sysadmin type tasks I write in Perl. I've got nothing against Python. I learned enough of it and it is fine. If I was writing larger systems I would probably use Python.
Depending on the task to be solved, a Bash script (using AWK, Coreutils etc.) executes much slower than the correspinding Perl or Python script, and having to run slow scripts often interactively can have a strong negative impact on developer productivity, especially on flow state (of mind).
God I must have written 200k lines of Perl5, and I hate it as only an experienced user can.
But the fact is: it gets shit done. It’s pretty good at dealing with strings and byte sequences, and even more importantly, it’s always fucking installed,
The “best” software helps you nothing if you’re machine isn’t running it.
> It’s pretty good at dealing with strings and byte sequences,
Ugh. Close to half the bugs I’ve chased in Perl in the last 10 years are encode/decode string bugs (or more specifically, the lack of doing encode/decode where necessary). After just one ‘downgrade_utf8()’ use, you get sick of Perl pretty fast.
Basically try using it outside of the anglosphere in the world of Unicode and support falls apart. Sure is excellent if you need to do something like extract a bunch of 1980s database files encoded in LATIN-1 though!
If you don’t (need to) care about Unicode, maybe. If you think pythons package management is not disastrous enough, maybe. If you do not (need to) consider Windows, maybe.
> If you think pythons package management is not disastrous enough, maybe.
Huh? I've used PAR::Packer with great success since 2005.
> If you do not (need to) consider Windows, maybe.
Microsoft used to ship Perl scripts to work with COM and WMI with their NT4 and Windows 2000 resource kits. Perl works *extremely* well with Windows.
I mean, there are lots of reasons to choose Python over Perl, but IMHO, these are not those reasons.
I use Perl as a better-bash. If I was writing a modern website, a large application, or any ML related work...I'd choose Python. But for complex system administration, I'm picking Perl. YMMV
Maybe a little off topic, but I'm curious -- why are all of the Actually Portable programs always named with ".com" at the end? Does this have any special purpose?
A .com file is an old form of DOS executables with only code and data. No fancy headers or anything. Only thing specified is that execution will start at a specific address (0100h) and if you put a JMP you got enough space to put other headers around it.
A com file is different from a typical dos/Windows exe, which requires a specific file header. Each exe begins with the two bytes MZ followed by specific information on page sizes etc. and there is no way around.
The challenge a program like APP has is that it should be recognized by all operating systems, so to Linux it should look like an ELF executable, on Windows like a windows executable, etc.
Now if you take this APP perl.com file and load it with Linux, Linux will read the ELF header and be happy. If you load it into Windows, it will see the .com ending and thus just put the code into memory, jump to address 0100h and start executing. The program then can ignore the elf header. And if you open it with some (unzip) Programm such a Programm will look at the end of the file, where it will find a zip file header info and will think it's an zip archive. (Zip files have the header at the end mostly for historic reasons, as all information was only available once compression was done, but as you span multiple disks you can't reach the front anymore)
In the end it is a trick to make it look like different kind of file, depending on who looks at it.
I wonder why microperl or miniperl didn't really take off. Would be a nice thing to have -- just a single-executable-perl with the basics and file i/o, alongside awk, Lua or any other tiny language.
$ bash ./perl.com --version
This is perl 5, version 36, subversion 0 (v5.36.0) built for x86_64-cosmo
(with 3 registered patches, see perl -V for more detail)
This is really interesting. I had to give up on Perl on Windows because Windows Defender was forever flagging anything compiled with Par::Packer as a virus and deleting it.
Shame there isn't a portable windowing toolkit you could use with this. I'm pretty sure it's not possible to get the Qt or GTK bindings to work across all platforms from a single install, even if you are using the toolkit's widgets instead of trying to use the platform native widgets.
Adding on to jart's answer -- I ported PHP 7.3 back in July 2021 (building on alganet's work), and got up to a simple "hello-world". Have never used PHP, so I didn't know what else could be done with it at the time.
However, the libc has grown a lot over the last year (Cosmo has a pthreads API now!) -- the updated libc enabled a quick experimental port of Python 3.11.0rc1 back in August (https://github.com/ahgamut/cpython/tree/cosmo_py311), so I would expect that a newer version of PHP can be ported similarly. Let's see....
One file is nice, but I like being able to run on Alpine Linux. A lot of stuff like Deno depends on glibc. That's one thing I think about when I think "Actually Portable".
Cosmopolitan Libc uses a musl-cross-make toolchain. https://github.com/jart/cosmopolitan/tree/master/third_party... Its primary developer also runs Alpine. Cosmopolitan is closely related to Musl as far as C libraries go. You could think of Cosmo as a Musl that's twice as fast on x86 and runs on more than just Linux.
Shameless plug: my earlier project StaticPerl, statically linked Perl 5.10 for i386 Linux and FreeBSD: https://github.com/pts/staticperl
Differences:
* Actually Portable Perl runs on more operating systems, StaticPerl runs on Linux i386 (requiring i686 or newer processor), Linux amd64 and FreeBSD with Linux emulation.
* Actually Portable Perl has more of the standard Perl modules and C extensions bundled. StaticPerl contains only a few modules, simplified, with documentation and non-Linux support removed. StaticPerl is unlikely to work with existing Perl scripts with many use calls, but it is useful to write new Perl scripts from scratch, and these scripts will work with both StaticPerl and regular Perl.
* Actually Portable Perl executable programs are larger (5 MB minimum, StaticPerl is ~1 MB) because they are compiled for amd64 rather than i386, and they contain more Perl and C code.
* The first time an Actually Portable Perl executable program is run, it modifies a few bytes at the beginning of the program file (except on Windows). Thus these programs don't work on read-only filesystems unless they have been run on a read-write filesystem first. StaticPerl doesn't have this limitation.
Author here. Nice comparison. By default (and the released) APPerl binaries do not self-modify (they use the non-self modifying ape loader) however on unix-like they install the APE loader to`$HOME/.ape`and use that ELF executable to run the APE. To skip the fork+exec to the ape loader, they can be assimilated with `--assimilate`, that does turn the APE executable into ELF.
There is a kernel patch to add APE (Actually Portable Executable) support to Linux removing the need for the the apeloader or assimilating. I'm not sure what the status is on that.
I forgot to mention APPerl and StaticPerl have many overlapping use cases, but APPerl is more tailored to application packaging. APPerl is built with a patch to Perl adding argv[0] script execution, allowing the APPerl binary to turn into a binary for any of the embedded scripts, with a rename or symlink rather then needing to pass flags the Perl executable to load modules.
Update on the APE Linux kernel support (for fork/ --assimilate)less APE execution. jart informed me: "It's in the process of being emailed out to the kernel developers. I anticipate it'll be merged within the next three months."
Could you suggest a way to do electron-like apps in APPerl?
I'm thinking of serving content on 127.0.0.2. There is no need for a high performance server like nginx, but serving files and having some CGI capability would be a plus.
I'd be interested in suggestions for the HTTP server part and maybe an example for how do serve an index.pl file that reads payload files packaged in the APPerl binary (ex: .js, .jpg)
6 replies →
Perl is really one of the best languages and in modern times is underrated. I've been using it in production for most of my critical services since about 2012. I've used many other languages since then but always keep coming back to perl. It's a true gem of a language.
It's grand child, Raku, also seems to be an impressive language actually. Hated by Perlers and non-Perlers alike, it actually would be a great environment to build powerful programs in:
https://www.oreilly.com/library/view/learning-perl-6/9781491...
>>Hated by Perlers and non-Perlers alike
Wrong. Perlers still cheer for it.
But for some reasons it hasn't wide spread adoption yet. We hope to use it some day in production.
https://raku.org
I messed around with Raku and it is seriously underrated. If anyone hasn't yet I would recommend giving it a try. It still does all the cool stuff Perl 5 can do but with the features you would expect from a modern language baked in. Raku and the core modules are solid and can be used in production but unfortunately the overall ecosystem is still struggling. 3rd party modules can be hit or miss. I found several of them weren't well maintained or seemed abandoned.
Yeah I wish Raku would pick up some steam. It’s the only newish language I’ve looked at that’s made me say wow and it cleans up some of the thorny Perl5 sigil issues.
2 replies →
I don't think anyone hates it, but there were many people who were looking for a solid release that ran fast-enough. There was also... drama, which I feel no one cares for.
3 replies →
I admit the only time I reach for Perl is when I need a really strong and dependable regex service. Still one of the best ways to parse text to this day. Perl text parsing capabilities are nearly unrivaled still.
What do you typically use perl for? I thought it was most commonly used for scripting and running cgi scripts. I find bash to be much more readable and tend to use it or python for most of my scripts
> I find bash to be much more readable
Lol, you find bash readable? With all its weird ad-hoc constructs? I don’t pretend Perl looks pretty but at least its constructs seem to be consciously designed and do not look bolted on.
At my work place we still maintain a huge web application written in Perl 5. Most of the time if we are in trouble it‘s due to bad architectural designs that are not specific to Perl as a language or ecosystem. Only rarely I stumble over issues like implicit returns, or context sensitive sub routines. Also I hate Perl 5 allowing circular includes. The worst offenders among in-house modules are Perl modules written in a Java-esque style which mostly would have benefitted well from using native Perl features instead of trying to mimick Java programs.
9 replies →
The sad thing is that once, a while ago, there was an attempt to compete with the new market of scripting languages (Perl, Tcl) from a shell perspective. The result being Korn Shell, especially ksh93, and tools like dtksh (which allowed Motif UI apps to be written in shell).
Compared to that, bash is really anemic.
Python took Perl's money a bit when it came to scripting, Ruby – clearly influenced a lot by Perl – made big grounds in web apps, once they outgrew CGIs, and of course then we collectively got Javascript Stockholm syndrome.
But seriously, they're all good dogs. We all revel in the Narcicissm of Small Differences, but in the end it wouldn't really matter if we used Perl instead of Python or any other algol-ish imperative OO language with some functional bits.
I learned Perl in the mid-1990's. I'm in semiconductor design and most of our CAD tools use Tcl so I write a lot of that but for any text report processing or sysadmin type tasks I write in Perl. I've got nothing against Python. I learned enough of it and it is fine. If I was writing larger systems I would probably use Python.
Depending on the task to be solved, a Bash script (using AWK, Coreutils etc.) executes much slower than the correspinding Perl or Python script, and having to run slow scripts often interactively can have a strong negative impact on developer productivity, especially on flow state (of mind).
1 reply →
APPerl creator here. I appreciate all the feedback and hope it comes in handy.
It's linked from the page, but thought I'd point out if you're curious what went into making APPerl, check out the blogpost (self-plug): https://computoid.com/posts/Perl-is-Actually-Portable.html
If it does what I think it does, then you've found the holy grail.
> a distribution of Perl the runs on several x86_64 operating systems (most Unix-like and Windows) via the same binary
Unix and Windows in the same binary?? Sacrilege! Haven't we still laws against witchcraft?
God I must have written 200k lines of Perl5, and I hate it as only an experienced user can.
But the fact is: it gets shit done. It’s pretty good at dealing with strings and byte sequences, and even more importantly, it’s always fucking installed,
The “best” software helps you nothing if you’re machine isn’t running it.
> It’s pretty good at dealing with strings and byte sequences,
Ugh. Close to half the bugs I’ve chased in Perl in the last 10 years are encode/decode string bugs (or more specifically, the lack of doing encode/decode where necessary). After just one ‘downgrade_utf8()’ use, you get sick of Perl pretty fast.
This to me is where Perl ends up super short.
Basically try using it outside of the anglosphere in the world of Unicode and support falls apart. Sure is excellent if you need to do something like extract a bunch of 1980s database files encoded in LATIN-1 though!
1 reply →
If you don’t (need to) care about Unicode, maybe. If you think pythons package management is not disastrous enough, maybe. If you do not (need to) consider Windows, maybe.
Even then, I’d rather choose Python.
> If you don’t (need to) care about Unicode, maybe
Perl has had strong unicode support since Perl v5.12 (~2010).
references: 1. http://xahlee.info/perl/perl_unicode.html 2. https://stackoverflow.com/a/6163129/12458
> If you think pythons package management is not disastrous enough, maybe.
Huh? I've used PAR::Packer with great success since 2005.
> If you do not (need to) consider Windows, maybe.
Microsoft used to ship Perl scripts to work with COM and WMI with their NT4 and Windows 2000 resource kits. Perl works *extremely* well with Windows.
I mean, there are lots of reasons to choose Python over Perl, but IMHO, these are not those reasons.
I use Perl as a better-bash. If I was writing a modern website, a large application, or any ML related work...I'd choose Python. But for complex system administration, I'm picking Perl. YMMV
Nice to see Cosmopolitan libc starting to be used more widely!
Indeed! Cheers to jart!
<3
1 reply →
Maybe a little off topic, but I'm curious -- why are all of the Actually Portable programs always named with ".com" at the end? Does this have any special purpose?
A .com file is an old form of DOS executables with only code and data. No fancy headers or anything. Only thing specified is that execution will start at a specific address (0100h) and if you put a JMP you got enough space to put other headers around it.
A com file is different from a typical dos/Windows exe, which requires a specific file header. Each exe begins with the two bytes MZ followed by specific information on page sizes etc. and there is no way around.
The challenge a program like APP has is that it should be recognized by all operating systems, so to Linux it should look like an ELF executable, on Windows like a windows executable, etc.
Now if you take this APP perl.com file and load it with Linux, Linux will read the ELF header and be happy. If you load it into Windows, it will see the .com ending and thus just put the code into memory, jump to address 0100h and start executing. The program then can ignore the elf header. And if you open it with some (unzip) Programm such a Programm will look at the end of the file, where it will find a zip file header info and will think it's an zip archive. (Zip files have the header at the end mostly for historic reasons, as all information was only available once compression was done, but as you span multiple disks you can't reach the front anymore)
In the end it is a trick to make it look like different kind of file, depending on who looks at it.
It's a legacy type of windows executable that it uses as part of its multi-OS trick, and other OSes don't care about that extension.
I wonder why microperl or miniperl didn't really take off. Would be a nice thing to have -- just a single-executable-perl with the basics and file i/o, alongside awk, Lua or any other tiny language.
An interesting effort and article from around 2001: https://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html
And an old Perlmonks discussion on a 850kb Perl: https://www.perlmonks.org/?node_id=222465
There is a newer github project as well -- it did work for a simple project with core modules for me: https://github.com/bentxt/microperl-standalone
I was waiting for this, but it doesn't mention which version of Perl 5 this is.
Cool, thanks!
This is really interesting. I had to give up on Perl on Windows because Windows Defender was forever flagging anything compiled with Par::Packer as a virus and deleting it.
Shame there isn't a portable windowing toolkit you could use with this. I'm pretty sure it's not possible to get the Qt or GTK bindings to work across all platforms from a single install, even if you are using the toolkit's widgets instead of trying to use the platform native widgets.
Has anyone done one of these (or wants to) for PHP?
Adding on to jart's answer -- I ported PHP 7.3 back in July 2021 (building on alganet's work), and got up to a simple "hello-world". Have never used PHP, so I didn't know what else could be done with it at the time.
However, the libc has grown a lot over the last year (Cosmo has a pthreads API now!) -- the updated libc enabled a quick experimental port of Python 3.11.0rc1 back in August (https://github.com/ahgamut/cpython/tree/cosmo_py311), so I would expect that a newer version of PHP can be ported similarly. Let's see....
ah, here we are: https://github.com/ahgamut/php-src/tree/cosmo_php81
(note it's an experimental port, I just put it together).
We managed to get it to build I think last year. https://github.com/ahgamut/php-src/tree/cosmo_php73 See also https://github.com/shmup/awesome-cosmopolitan
Yeah, I’ve wanted this for a long time. I’m going to try but can’t promise anything.
Same but for Python. I'll probably look into it when I'm sufficiently bored with my current projects.
5 months ago on HN, "Python is Actually Portable", https://news.ycombinator.com/item?id=32245430 (120 comments)
To quote the blogpost:
really cool, thanks!!
One file is nice, but I like being able to run on Alpine Linux. A lot of stuff like Deno depends on glibc. That's one thing I think about when I think "Actually Portable".
Does this support musl?
It doesn't depend on anything, completely static. Here you can read more about Actually Portable Executables: https://justine.lol/ape.html
Cosmopolitan Libc uses a musl-cross-make toolchain. https://github.com/jart/cosmopolitan/tree/master/third_party... Its primary developer also runs Alpine. Cosmopolitan is closely related to Musl as far as C libraries go. You could think of Cosmo as a Musl that's twice as fast on x86 and runs on more than just Linux.