The author mentions to be unsatisfied with the solution to use symlinks for finding DocBook XSL files. The correct way to reference DocBook XSL stylesheets is to use the HTTP URL to the stylesheet, which will be looked up in the XML catalog of your system. This catalog file maps URLs to files on disk and is managed by your package manager.
You should also forbid your tools to access these URLs directly (--nonet), as it would be incredicly slow and you rather want your build to fail in this case instead of downloading on-demand.
If you prefer to work with files instead of passing long URLs on command line, use a small wrapper file to import the real stylesheet and pass that on command line instead of using the URL. The advantage is that you can also put additional <xsl:param> tags to customize the output right into this file.
<?xml version='1.0' ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>
<!-- put additional xsl:param here -->
</xsl:stylesheet>
If your makefiles use gnu-isms (which is a valid choice) then I would lean towards using GNUmakefile and have Makefile call gmake - and don’t forget to use $(MAKE) for any recursion.
This is less fragile and requires less dependence on replacing make in the $PATH.
I'm also working on OpenBSD and NetBSD, other kernels, and non-x86 architectures. If anyone is interested in using this to make their software more portable, please let me know! Email in my profile.
Do you plan on providing Github integration? Providing other OSes and platforms (e.g. ARM64, ppc64el) would be really useful for testing low-level projects like .NET Core runtime, node.js / libuv, etc., and integrating with Github would make it really easy for people to start adding this to their existing projects.
We currently test Rust under qemu-system for FreeBSD and have no real good solution for OpenBSD and DragonflyBSD. It would be very interesting for us to do "native" testing.
pfSense is great for a prosumer router. What gets me about it is cleaning up the mess it creates in business use cases, as pfSense is designed with a mindset that the pro will always be there, ready to attach a screen at a moments notice when interfaces change or packages get updated. Running PHP as root also isn't great, I'm not sure how that passes in the context of HIPPA.
I tried using meson for https://github.com/shlomif/mini-factor , and while it worked fine locally it turned out to require python 3.6 which made it hard to install on Travis-CI. I ended up created a complementary cmake build system.
Another great thing about FreeBSD is it's not too hard going the other way: Embedding FreeBSD is a robust choice, one that can take you quickly to market as it did for me and a GPS on golf cart project I did in the late 90s with it, busybox, and some valuable help from PHK on getting support for the weirdo LCD panel the suits picked (we had to turn the panel upside down in the cart, the viewing angle was atrocious).
I wish more VPS providers offered OpenBSD and FreeBSD. I remember using FreeBSD a lot when I was 12-17 just messing around and setting up servers, etc but eventually moved to Debian because VPS' at the time didn't really offer these that much (reliably.)
Don't most providers let you roll your own images? Outside of some (mundane) virtualization issues, you should be able to get BSD images running fine at places like Linode, et al.
Which ironically I do use in this way but never formulated it in such a compact and witty way.
I found Perl to be available basically by default on every platform I could encounter, from AIX 3 to Windows (it comes along with Git for Windows, which gives you bash too).
FreeBSD is great! Even as a desktop. NVIDIA builds official drivers for FreeBSD. I dont know whats the status for newer AMD graphics card. Nvidia + Intel graphics also works very well.
There is a port system where users can build the packages from sourcecode on their own machines. Its +- like gentoo.
There is also a binary pkg system. It is faster to install since the packages are already built (binary).
To upgrade from minor versions ie. 11.1 to 11.2 it is very simple and well documented. Just see in the manual freebsd-update
There is native support for ZFS also which is great.
Virtualbox works very well, so its possible to install other OSes in virtualbox. VMware i dont think is supported.
Why? They're not compatible and not a drop-in replacement.
They're also likely a little bit slower, especially on large datasets. It's really hard to beat GNU grep. (Which is famously 3 cycles/byte in the trivial case. Great exercise though.) But for the most part performance is secondary to feature partity.
Which still has many of the terrible problems of the shell, because its original design was an imitation of several different shell scripting languages.
If all you know is Perl and you're incapable of learning any other languages, or for some perverse reason you like the way Perl scripts look just as incomprehensible as shell scripts, and you're absolutely sure nobody else will ever need to look at or maintain your code, then by all means use Perl. But if you don't hate the people who will have to clean up after you or decipher and maintain what you're done, then please use Python or JavaScript instead of Perl or shell scripts.
> and you're absolutely sure nobody else will ever need to look at or maintain your code
By "nobody else" you really mean "other people with the same mindset who aren't willing to invest some time in getting used to perl syntax". Thing is that modern javascript is just as incomprehensible to sysops/devops people who're not familiar with the new JS syntax. You come from one world and think that's the "normal", they come from the other and expect that everyone already knows perl as it is half bash, half C. And in the end it's really much more about how much time did you spend working in it, than in one language being so much clearer than the other.
I can understand Python (it has a library in stdlib for running subprocess, and it is specially good after Python 3.4). However AFAIK JavaScript is bad for shell scripting. You need a external library to have sane subprocess call, unless you give up and allow command injection inside your scripts. Last time I looked even the alternatives in npm were not as good as what Python offered in stdlib.
Actually, I don't know many languages that have a good way to call subprocess in stdlib. Ruby's Open3 comes in mind, however the API is kind horrible.
Perl is still one of the best glue/high level systems languages around, partisan missives not withstanding. Debian's apt system is based upon it, as is git (though it uses C for parts that are intensive), and many other tools.
Python is fine as a systems language if you don't mind the insane indentation issues, and the extra boilerplate you need to do for "simple" things.
Honestly, I see Julia as the up and comer here. Julia has IMO the best syntax, is JIT compiled, is a real programming language, and is IMO python done right.
If you are stuck believing python is a good language to develop new projects in, great. Knock yourself out. I personally find myself most productive in Julia, Perl, C, Octave/Matlab, and yes, even Fortran.
I haven't really seen enough Python code in my life to have an opinion about readability of Python code in the wild. But I have seen quite a lot of unreadable (unminimized) Javascript code.
In the end it really depends on how much the developer is suffering from some form of impostor syndrome: if they're not, you have a good chance they will create code that will be unmaintanable even for them in a few months time. Regardless of language.
[+] [-] raimue|7 years ago|reply
You should also forbid your tools to access these URLs directly (--nonet), as it would be incredicly slow and you rather want your build to fail in this case instead of downloading on-demand.
If you prefer to work with files instead of passing long URLs on command line, use a small wrapper file to import the real stylesheet and pass that on command line instead of using the URL. The advantage is that you can also put additional <xsl:param> tags to customize the output right into this file.[+] [-] blattimwind|7 years ago|reply
[+] [-] jwilk|7 years ago|reply
[+] [-] mcbain|7 years ago|reply
This is less fragile and requires less dependence on replacing make in the $PATH.
[+] [-] ComputerGuru|7 years ago|reply
All maintained and ready to go.
[+] [-] Sir_Cmpwn|7 years ago|reply
https://builds.sr.ht/~sircmpwn/job/9348
I'm also working on OpenBSD and NetBSD, other kernels, and non-x86 architectures. If anyone is interested in using this to make their software more portable, please let me know! Email in my profile.
[0] https://github.com/swaywm/wlroots
[+] [-] profquail|7 years ago|reply
* https://github.com/travis-ci/travis-ci/issues/1818 * https://github.com/travis-ci/travis-ci/issues/6671 * https://github.com/travis-ci/travis-ci/issues/5473
Do you plan on providing Github integration? Providing other OSes and platforms (e.g. ARM64, ppc64el) would be really useful for testing low-level projects like .NET Core runtime, node.js / libuv, etc., and integrating with Github would make it really easy for people to start adding this to their existing projects.
If you do end up providing Github integration, consider listing a paid option for your service in the Github marketplace: https://github.com/marketplace/category/continuous-integrati...
[+] [-] flurrything|7 years ago|reply
We currently test Rust under qemu-system for FreeBSD and have no real good solution for OpenBSD and DragonflyBSD. It would be very interesting for us to do "native" testing.
[+] [-] nikisweeting|7 years ago|reply
[+] [-] setquk|7 years ago|reply
[+] [-] metildaa|7 years ago|reply
[+] [-] enriquto|7 years ago|reply
[+] [-] brian_herman|7 years ago|reply
[+] [-] xvilka|7 years ago|reply
[1] https://mesonbuild.com/
[2] https://ninja-build.org/
[+] [-] dig1|7 years ago|reply
Maybe fourth - learn how to use it
[+] [-] ridiculous_fish|7 years ago|reply
One of make's great strengths is that it is so generic.
[+] [-] shlomifish|7 years ago|reply
I tried using meson for https://github.com/shlomif/mini-factor , and while it worked fine locally it turned out to require python 3.6 which made it hard to install on Travis-CI. I ended up created a complementary cmake build system.
[+] [-] enriquto|7 years ago|reply
[+] [-] imron|7 years ago|reply
[+] [-] MaxBarraclough|7 years ago|reply
[+] [-] howard941|7 years ago|reply
[+] [-] dis-sys|7 years ago|reply
This is gold!
[+] [-] rob|7 years ago|reply
[+] [-] tamentis|7 years ago|reply
[+] [-] _eht|7 years ago|reply
[+] [-] otherflavors|7 years ago|reply
[+] [-] na85|7 years ago|reply
[+] [-] jancsika|7 years ago|reply
[+] [-] lloeki|7 years ago|reply
> Perl is portable shell
Which ironically I do use in this way but never formulated it in such a compact and witty way.
I found Perl to be available basically by default on every platform I could encounter, from AIX 3 to Windows (it comes along with Git for Windows, which gives you bash too).
[+] [-] nopacience|7 years ago|reply
There is a port system where users can build the packages from sourcecode on their own machines. Its +- like gentoo.
There is also a binary pkg system. It is faster to install since the packages are already built (binary).
To upgrade from minor versions ie. 11.1 to 11.2 it is very simple and well documented. Just see in the manual freebsd-update
There is native support for ZFS also which is great.
Virtualbox works very well, so its possible to install other OSes in virtualbox. VMware i dont think is supported.
[+] [-] throwaway487548|7 years ago|reply
[deleted]
[+] [-] agambrahma|7 years ago|reply
(I continue to wonder what's stopping everyone from just ditching `grep` altogether and switching to `ag`/`rg`)
[+] [-] ddevault|7 years ago|reply
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/gr...
Using ag et al in a script makes your script non-portable, which is the opposite of the goal here.
[+] [-] andrewprock|7 years ago|reply
[+] [-] xorcist|7 years ago|reply
They're also likely a little bit slower, especially on large datasets. It's really hard to beat GNU grep. (Which is famously 3 cycles/byte in the trivial case. Great exercise though.) But for the most part performance is secondary to feature partity.
[+] [-] rurban|7 years ago|reply
ag and gmake and several GNU or linux-specific extensions not.
[+] [-] pbhjpbhj|7 years ago|reply
By ag, do you mean ack-grep (https://beyondgrep.com/install/)?
[+] [-] kzrdude|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] DonHopkins|7 years ago|reply
Which still has many of the terrible problems of the shell, because its original design was an imitation of several different shell scripting languages.
If all you know is Perl and you're incapable of learning any other languages, or for some perverse reason you like the way Perl scripts look just as incomprehensible as shell scripts, and you're absolutely sure nobody else will ever need to look at or maintain your code, then by all means use Perl. But if you don't hate the people who will have to clean up after you or decipher and maintain what you're done, then please use Python or JavaScript instead of Perl or shell scripts.
[+] [-] ivanhoe|7 years ago|reply
By "nobody else" you really mean "other people with the same mindset who aren't willing to invest some time in getting used to perl syntax". Thing is that modern javascript is just as incomprehensible to sysops/devops people who're not familiar with the new JS syntax. You come from one world and think that's the "normal", they come from the other and expect that everyone already knows perl as it is half bash, half C. And in the end it's really much more about how much time did you spend working in it, than in one language being so much clearer than the other.
[+] [-] m45t3r|7 years ago|reply
Actually, I don't know many languages that have a good way to call subprocess in stdlib. Ruby's Open3 comes in mind, however the API is kind horrible.
[+] [-] TurboHaskal|7 years ago|reply
Sorry but Perl is perfectly fine even by today’s standards.
[+] [-] hpcjoe|7 years ago|reply
Perl is still one of the best glue/high level systems languages around, partisan missives not withstanding. Debian's apt system is based upon it, as is git (though it uses C for parts that are intensive), and many other tools.
Python is fine as a systems language if you don't mind the insane indentation issues, and the extra boilerplate you need to do for "simple" things.
Honestly, I see Julia as the up and comer here. Julia has IMO the best syntax, is JIT compiled, is a real programming language, and is IMO python done right.
If you are stuck believing python is a good language to develop new projects in, great. Knock yourself out. I personally find myself most productive in Julia, Perl, C, Octave/Matlab, and yes, even Fortran.
[+] [-] lizmat|7 years ago|reply
In the end it really depends on how much the developer is suffering from some form of impostor syndrome: if they're not, you have a good chance they will create code that will be unmaintanable even for them in a few months time. Regardless of language.