Or elm, for that matter.
Which tears it for me, my next executable should be named 'oak', to ensure it can't be removed from the file system easily.
So, there's this thing.. the 'debian policy' document. You can find it here:
It's supposed to help clarify lots of information related to creating debian packages.
Skip down to 2.2.2., "The contrib archive area", and witness how well they clarify things.
"Every package in /contrib/ must comply with the DFSG."
No link there on the acronym "DFSG".
Imagine someone not skilled in the art of creating debian packages (say... me?) stumbles into a document with this in it. Would they think to look up at 2.2.1. and find that the acronym means "Debian Free Software Guidlines"?
Would they think to click on the , jumping to some random area of the document where there's another link to 'REJECT-FAQ' "which details the project's current working interpretatin of the DFSG"? Would they continue through the labyrinth to follow that link to the 90s-esque web page that kinda makes all of this feel more like a legal document and less like a technical one?
Or would they just toss their hands up in the air, quietly scream inside, and just do whatever the fuck they want anyway?
Developers can't read or write English, particularly the aspies that dominate free software development, so I'm leaning towards "do whatever the fuck."
I'm still waiting for Stallman to start complaining that I modified the version of the GPL that I use, even though it says "changing it is not allowed."
Holy crap ... emacs is older than vi?
2018-03-12 17:48 from IGnatius T Foobar @uncnsrd
Holy crap ... emacs is older than vi?
I had no idea either. Although GNU Emacs started life in 1984.
James Gosling. His implementation of emacs began in 1981, with editor macros written in an embedded subset of LISP.
Stallman eventually turned his nose up at it, as he does with most things, and began GNU Emacs.
He should think twice about that--Emacs is kind of an ungodly mess, UI-wise. But on rare occasions I drop into it because of some function that might not exist (that I know of) elsewhere.
Gotta build everything to work in RedHat now.
So far, not a trivial undertaking, but probably easier than trying to make this work for Solaris.
Using CentOS, since I don't want to pay for build systems... I expect the binaries should still work on RedHat (but will test to make sure). And one of the first things I discovered is that you have to yum-install the static libraries separately from the -devel packages... unlike in Debian. I find that annoying, but I guess I understand. Also, they don't provide a static library for OpenSSL that will actually work (it tries to drag in a bunch of kerberos nonsense that you don't otherwise need). So, you have to compile it yourself... which if I'm going to do that, I may as well get the latest version and work with that, to address all the subtle security concerns.
Also unlike Debian, there's no way to specify [1;the RPM packaging system offers no consistent way to configure the package upon installation.
You are specifically disencouraged from asking the installer for any information ... which I understand, as many administrators would want to install remotely, etc., but they offer no alternative to specify what you might have wanted to state during the installation (which you can do with Debian packages).
So, yeah, no consistency there. Any configuration would have to happen post-install, and the installer would need to know what to do to make that happen. I might work around this by echoing a script the installer can call to configure the installation, so at least it isn't a mystery.
Is that the normal way of doing things with RPM? After install, write to the console something like, "To configure this installation, run /usr/local/bin/configure_my_tool "?
It's not as integrated as Debian's approach, but it at least might make things easier for those who don't want to slog through dependency hell.
I'm already doing Special Things to avoid dependency hell, so I don't expect I need to worry about that muc.
This is a matter of ensuring that the system is configured properly before they go to use it. I come from a Windows background, where I expect the user to have an intellect closer to that of a gnat than a well-paid engineer, so it's possible I am overthinking things.
Except... I am not dealing with well-paid engineers working on Linux. I'm dealing with instructors, who ought to know better, but might not.
The post-configuration required for this tool is an IP address to a machine within the environment to which information will be pushed, given the nature of this tool.
Further configuration is up to the user... but that one tiny bit of information is critical to getting this to work at a base level.
So, no, a meta-package won't quite cut it. Unless, maybe, I build a meta-package for every conceivable IPv4 address out there. Heh.
I just stormed out of a meeting for that exact reason.
Someone said something to the effect of "I prefer emacs."
I snapped my laptop shut, said "We don't say those words. Not in this house." and without missing a beat, walked out of the room.
I tried emacs for a couple of years or so in college.
After growing weary of holding down the ctrl key, I started looking to vi (via vim), and it much easier to use.
Which might seem a bit weird, but I guess I'm comfortable with the whole modal command thing.
time for docker?
Hmmm... not sure docker will allow us to do some of the weird things we need to do.
We need, for example, to see what a student has typed at a command prompt, and also report the tool's output. It gets weirder if that tool happens to be something like meterpreter.