Don't bother optimizing for upstart; it's going away in favor of systemd, even in Ubuntu.

systemd can be told to run stuff in the foreground, as if it were called directly from /etc/inittab under old init. I don't know how kosher that is (probably not very) but it does work.

called directly from /etc/inittab under old init. I don't know how
kosher that is (probably not very) but it does work.

Not very kosher under old init, because you had to change runlevels just to enable/disable a specific service.

Might not be considered such a bad thing under a fancier init.

I'm intending to write configurations for the three styles of startup.

I have a couple of sysv scripts made, and (now) the upstart. Next, I'll want to create one for systemd.

At the very least, supporting these more recent inits allow me to take advantage of parrallelization, which strikes me as a good thing.

Hmm, I just thought of something:

Some programs use -d (debug) to force them to stay in the foreground (and spew debug info)

Some programs use -d (daemon) to force them to go into the background

This is an atrocity. I blame the previous owner of my old house, whose last name begins with the letter D, for this atrocity.

I am not sure, but -v seems to be more popular for debugging info (e.g. 'verbose').
But, again, I kinda feel like I'm dipping my toe into all of this.

that's rather neat, actually.

I'd love to play that sometime when I'm not at work.

Playing with Fedora today.


Maybe I don't quite understand the issue that lead someone to say something like this, but supposedly we can't build binary RPMs because we haven't paid for a Red Hat Developer's license or somesuch.

That doesn't strike me as true, though, so I'm looking into things myself.
Hence, installing Fedora. Well, that, and I wanted to look at systemd and see how well I can set up our services to auto-start in that environment's configuration scheme.

Lots of toe-dipping this year.

I'll say this for Fedora, though... it looks pretty out of the box.

But I'm not sure I like the whole 'grab the screen and pull up' screen-locking mechanism they use. I'm sure I can configure something else, but... this isn't a touch-screen.

Oh, nice to know!

I've at least managed to learn how to work with systemd with Fedora. But it's a little weird that one form of logging to syslog works, while the other one I use doesn't (yeah, this is difficult to explain well).

I would call Linus.

Linus will just change the kernel ABI so your program doesn't work at all anymore.

Free network equipment shape gallery designed to allow #LibreOffice and

#OpenOffice users to create network

diagrams.

Ooh, nice!

Holy hell, but I managed to compile Gnu GCC 4.7.3 on Valhalla. I'm feeling plucky, though... building GCC 4.8.3 on it now.

Honestly, compiling these damned compilers feels like I'm beating code into submission. Seriously.

'nm' complains that it doens't understand the -p option? No problem. the
'nm' that it's calling is actually 'exec' (for some insane reason), so I just replaced it with the binutil/nm-new that it should have used in the first place. Shit like this.

Valhalla's version of zlib doesn't have compressBound, which is required by the latest version of binutils, which is required by GCC now? No problem, I'll write it myself. Oh, that function needs 'ceil', which is in -lm, but I can't link it? I'll create my own 'ceil'. How hard can it be?

I'm beating this fucking code into submission.

Valhalla's kernel lacks an __NR_exit_group interrupt, which libsanitizer wants? No problem, configure --disable-libsanitizer and try again.