gchpaco

Linux kernel? Uses its own automation. See also *BSD make, which is the basis for ports among other things (unless that's changed since last I looked); entirely in-make. Plan 9 and the userspace port uses mk, which is a slightly cleaned up variant of the BSD make.

Fact is, a makefile for building C code is typically smaller than the autoconf files required to get autotools to work on the same code. Most horrible makefiles are written by terrible build automation software (autotools being among the worst offenders here) or by people who don't understand the dependency graph model. A ten line Makefile that automated something repetitive is fantastically important, even if it is just writing down something in an executable fashion such that you don't have to remember it later. Almost every build automation tool out there either doesn't scale up (too simple) or is too hard for small work, or occasionally both, like Ant.

If I need to do something simple, a Makefile is only a very little bit more complex than a command line—I frequently crib the command I just ran to start off the Makefile. If I needed to do nontrivial logic in a Makefile and couldn't avoid it, I wouldn't use jam or tup or redo or SCons—I couldn't, because they're less useful than make! I would probably end up using Rake, which is the only build automation tool I've seen so far that isn't a make clone and can do implicit dependency generation.

Typically this shows up in recursive make projects with lots of sub projects—it doesn't take that much time to stat every file in question but reinvoking make sixteen times can be quite slow.

I don't deal with this by not using make, I deal with this by not writing recursive makefiles.

Well, one of the biggest differences is that in NetHack you have a goal, which you can complete. That is, it is a game you can win, or lose at. DF is an open world simulation; you can "lose" by having your fort wiped out, or you can lose interest (#1 killer of my forts) but you can't actually "win". Even in adventurer mode there isn't a victory condition.

I'm not sure that DF's learning curve is really comparable to vi. Maybe TECO. Almost everybody's first fort dies because they didn't set plant orders or ran out of booze or something similar. Next, forts die because you got enough wealth to spawn an ambush and you are totally unprepared. There's a litany of failure conditions that can shut you down hard and once they've begun it is very difficult to impossible to reverse; tantrum spirals are the most obvious but for example you might find out that you needed to plant food some time ago, or that aquifers are full of Fun and Exciting and cause interesting problems for your nascent fort. I mean as a veteran I'm pretty good at avoiding these and getting into the late game but I can't even remember what they all are.

It reminds me in some ways of the old HGTTG text game, where if you didn't take exactly the right steps at the start of the game you would be irreversibly fucked two hours later with no warning. Except I think that was due to malicious intent, and DF's complexity is some combination of developer indifference / incompetence (Toady is quite good but obviously UI design is not something he's really enthralled by) and Stockholm syndrome on the part of the player base. Some folks won't play without Dwarf Therapist, I absolutely require dfhack's workflow plugin to not go insane, etc. This is not really a good situation, but there's just one of Toady and the community is startlingly loyal, probably helped by the sheer addictive quality of the game once you get going; he can be excused, to some degree, a focus on new, novel things before the total UI revamp needed.

Depressingly their competitors are no better. I've been monitoring a bug in puppet that's been open for the better part of three years for adding options like "--enablerepo" to yum invocations. This is not technically difficult to do but they keep dithering on design issues "because it's not cross platform". (Really? Because Ubuntu and RedHat totally agree on how to name packages, where system files live, which init.d to use, and those are both Linuxes; it gets even stupider with Solaris, BSD and Windows)

It would have to get substantially less vapor-y to even qualify as "messed up".

Regular here does not mean regular in the technical sense, it means there aren't any weird special case constructs that break the rest of the parsing (for a particularly egregious example, consider the Perl report sublanguage, which is nothing like the rest of the language).

When I was TAing I remember the office staff glancing at my "classes I would like to TA" list and thanking me for putting all upper division courses; apparently most of the TAs competed for lower division course slots where the problems were easier and so presumably the workload was lessened. I always went for upper division because I hated dealing with entitlement complexes and don't like trying to teach shallow material. We never really had enough resources, but it wasn't quite that bad.

Another way of looking at this is how much code you have to read. This is one of the reasons I hate wizard generated code in a way that I don't hate InterfaceBuilder or similar serialized object trees. If I'm gonna have to read the code eventually, the fact that your IDE makes it easy to draw a button is cold comfort to me when it takes 100 lines of cryptic C to do it (actually pretty common in early Windows programs or Xaw hacks, but mercifully diminished in frequency in these more enlightened days).

Code generation can cause people to neglect library design; the reason why the MFC wizards spat out volumes of code instead of calling a library method is because you might need to rewrite some or all of that. You are not expected to modify InterfaceBuilder output, nor should you have to any more than you would have to regularly rewrite bits of Xlib to customize them appropriately.

Building java libraries isn't really all that difficult. Not is packaging them. Damned if it doesn't take 30 lines of XML to do it in maven, but these kinds of see-spot-run situations are pretty easy.

Extremely difficult in maven and five minutes work in make or ant is things like "running LaTeX to generate a PDF of some of your documentation, because it is math laden and HTML isn't suitable". This is not theoretical; I had to do this at the place that was using maven and we depended on some semi-obscure mathematical formalisms like the stable distribution.

Intermediate between these two is driving things with maven plugins, which is either easy (because you're doing something trivial) or fiendishly difficult because the debugging output is terrible, the docs are worse and the only thing left to you is to Use The Source, Luke. Every nontrivial maven plugin I've ever used has tripped this at some point, be it loading config files, including the dependencies, or something else.

A correction I should note; the broken json gem was 1.4.3.

Ant and a lot of the build tools that grew up around Ant don't support what make calls pattern rules very well. It's a lot like the difference between using Prolog and C to do the same task. A good example of how this is painful is to try to imagine how difficult it would be to handle the dependencies between various Java source files automatically if <javac> didn't do it for you.

To pick an SNMP related example, since I've done a bunch of that, suppose you have a MIB for your organization (using a hacked private OID that you haven't told anybody about for development, because it's easy) and then a lot of other MIBs that depend on that. And then one bright day you get your IETF approved SNMP OID for your organization, and you need to retarget your MIBs to be under that. It could be as simple as changing the base MIB to the new, official, OID and then letting your build tool rebuild the generated files in the correct dependency order--but that's hard to do with Ant. Usually you'll just rebuild all the generated files and then rebuild all the downstream code and then ... It's not trivial in make but it's not especially difficult--make for example has no real knowledge of C code, but with cc -M it doesn't need any.

Maven isn't even good at making hard things easy. Trivial things are easy and anything else will take a day of head scratching, minimum.

If what you need to do can be done in Maven you don't need to do anything very difficult. Ant scales poorly; dependencies are a particular headache. Maven scales astoundingly poorly.

Here's a very short list of things that are massively obnoxious to do with Maven, but are perfectly reasonable:

- submitting code to a code review site like Gerrit.

- generating code (for example, a parsed SNMP MIB that you want as a Java class so you can refer to it easily).

- integration with a tool like Sonar (yes, there's a Maven plugin. You ever used it?).

- code coverage analysis (yes, there's a Maven plugin. You ever used it?).

- FindBugs style analysis (yes, there's a Maven plugin. You ever used it?).

- interesting dependencies on external libraries (to pick an example from Ruby, the json gem was horribly broken at 1.4.2 and generations of projects have varying requirements for json < 1.4.2, json > 1.4.2, and many other worse things.

- C code (through JNI or anything else, a perfectly reasonable thing to want to do).

- deployment.

From bitter personal experience it is possible to get so wrapped up in this that you think you have achieved something amazing when you finally finish, when it could have been done in a few hours in make or rake.

"Oh, but you can integrate it with your IDE!" The only thing your IDE actually needs to get from the Maven POM is to understand where your source code is, what you depend on and where it is, and how to run your tests. Everything else they do with command line calls, just like it was Ant.

Have they been permitting anyone who isn't oracle affiliated to work on the sandbox? I was under the impression that the core development and compiler work was all in house.

A friend of mine does that with her boyfriend as a sort of solidarity thing with same sex couples. Dunno if that's Aaron's reason, but that was what I thought of.

Unless the data is random (which is to say the additional layer of crypto is probably not buying you much) you can do e.g. frequency analysis on the output of the cipher. If you have a reasonable sized corpus (given how biased the PRNG is, probably a few thousand characters is overkill) you can probably break it effortlessly.

A biased RNG for a stream cipher is very difficult to recover from.

Also depending on the discipline you're working in you can make very confident assumptions about what a random mathematical object is depending on which language it is typeset in. In the context of programming language type systems, for example, a Greek letter is almost always an ML style type variable (think Haskell type a -> b -> a stuff) whereas Roman type is almost always a ground object (int, bool, whatever). Vectors are boldface, groups are capitals, fields are blackboard bold, lowercase letters in a group context are almost certainly group elements... In some contexts you're actually reaching for new alphabets (e.g. the Hebrew letters that are used for infinite cardinals) to be even more distinctive.

I think you might have misread; what I saw was "exec responsible for Maps goes away. His underlings, who were feeding him bad data but which he was apparently unable or unwilling to replace, also go away." Whether this is the right thing or not can be debated, but arguably it's why people on that level of the enterprise get paid the big bucks.

I'm being elliptic about why here because I don't think I can talk about the internal architecture of that system in public, but warning people off one particularly stupid third party bug that we fixed in our internal fork is not, I believe, a problem. Anyway, we certainly did use it to manage daemon processes, although not deliberately; we had a daemon that communicated with external software about system events, and running shell scripts was part of that. We didn't necessarily anticipate folks running 'service httpd start' in those shell scripts, but it was not an inherently unreasonable thing to do.

And this isn't "arbitrary use cases"; this is an explicitly supported function that is completely contrary to good practice and sane behavior and, to boot, has the ability to arbitrarily kill programs for impenetrable reasons and block for significant periods of time (the central sin of event driver programming). You can't tell me that if you saw something like this in a random crypto library you wouldn't immediately tell everybody to stop using it; why should EM's developers get a pass for their, yes, incompetently written popen? I would actually be considerably happier if it wasn't in the library at all; at least then it wouldn't be wrong.

From hard learned professional experience: EventMachine isn't written very well, when I say that I mean specific things like "whoever wrote the sub process handling in EventMachine wrote code that is uniquely wrong on every platform I've ever heard of." If you are not familiar with this (and are curious, in some sort of macabre way), I urge you do grep for SIGCHLD or wait in the source and see what you find.

What EventMachine does (or at least what it did a year or so ago when I was debugging this) is this: sub processes are equated to popen. When the input side of that pipe closes (that is, when the sub process closes STDOUT) the process will be finally be waited upon—and if it doesn't terminate in a hard coded timeout which by the way blocks the rest of your program, then it will be forcibly gunned down, with SIGKILL if necessary.

Among the problems that arise here, note that unless your daemon script is written to unconditionally drop STDOUT upon forking (uncommon) and you attempt to launch a daemon from within a sub process you are managing using EventMachine, the subprocess itself will terminate quickly, the daemon will go on its merry way, and your driver program will never, ever tell you it has finished running until that daemon is dead and anything it has spawned that might possibly use STDOUT is also dead. And god forbid it close that stream and then dare to continue running, for EventMachine will shoot it dead within IIRC 20 seconds, and lock up your driver program for the duration to boot.

Programmers who understand how the Unix process model works will write a very small signal handler for SIGCHLD that writes a byte on a pipe or some similar method of notifying the main event loop and call wait on the child immediately and then close its end of those pipes. I am reliably informed by those who understand the Windows process model that what EventMachine does is even more wrong there. This is a subsystem that was not written by anyone who knew what popen does, could not be bothered (or was perhaps incompetent to read) what any of a dozen standard implementations of it do, and appears to have debugged the code into some form of submission and then released it upon an unsuspecting public.

This is the only colossally wrong decision they made that I can list off the top of my head, but that's because it was so stupid I stopped looking for trouble after that. EventMachine does not handle anything but a very straightforward select loop very well, and I am sufficiently terrified of what lives under the covers in that system that I would rather write the select by hand (massive pain though it may be) than let this system anywhere near it. The thing that really alarms me is that people build walls of cardboard like NeverBlock (which reaches deeply into the guts of the Ruby software I/O and replaces it with EventMachine driven coroutines) atop this foundation of sand and then wonder when it falls over sideways in an impenetrable and impossible to debug fashion.

Coroutine programming (for that is, essentially, what we are talking about) can be a very elegant way to solve certain problems, but it works best when it is simple, or it least localized (e.g. samefringe). In an event driven server, every little piece must be audited carefully to ensure that it does not block. You get all the same problems any preemptive concurrency model does, with some added nastiness; in exchange you get some slightly better scalability numbers. It is at its best in a fairly simple program such as, say, nginx in its proxy configuration, where it speaks streams and SSL and talks to some application server on the other end of a different stream for anything sophisticated.

That's not actually sufficient when you consider version requirements; for example requiring a specific range of libc or the like.

12.10 is the official name for the actually released OS. The animal name is the code word for the thing that will become 12.10 when it's done. Things get a little confused sometimes in e.g. apt repositories but the official stuff is all quite clear on the distinction.

It is creepy how much that looks like 8 1/2 and rio. Pike clearly thought he had a good thing.

It is surprisingly demanding of mice; you need to have a three button mouse and ideally with a separate button, as chording on the mouse wheel can be error prone. I try to switch now and again but I never really stay; particularly with acme I find I like the way wily (a nominal clone) did the current working directory better; easier to create utility files.

But it is a really good editor, just not to my taste.

Sam and acme are both very good; they're weird, certainly, and very different from editors before and since but they are quite nice to work in. At least the equal of vi.

The law is non-copyrightable. However a lot of state laws say "You will build your building according to Document X by Corporation Y" and that is copyrighted and not given out without a lot of money. The reason why these exist is that lawmakers aren't experts in, say, concrete; and those who are tend to be employed privately, and make industrial standards. As an example consider specifying that a program will be written in C (a bad idea here, but saying "structural members for buildings shall be steel as defined by this standard" isn't a terrible idea). C is defined by the relevant ANSI or ISO standard; now if you want to know what the law actually says, you have to pony up the money for an official standard.

I don't know what settled law is about this, but it is at the least morally questionable activity.

So what motivated this? What do you see as differentiating you from ikiwiki?

I worked for a startup that was like this but with a grand total of five employees. It did not sit well with me.