gyepi

No, the radial arm saw does not get enough love because it is dangerous when used for anything but cross cuts and straight angled cuts, both of which are easily handled by a miter saw, which is safer and more versatile.

I used one for years and was happy when I finally gave it away. A sliding miter saw and a table saw are a safer combination, for sure.

Wholly agree with the dust collection. You can actually get far with a shop vac if you add a cyclone type pre-filter bin to it.

I disagree with the author. I certainly understand that reading "hard" books takes a lot of effort that may not seem worthwhile, but would not say they are overrated. However, like anything else, they aren't for everyone. Just those who are ready for them.

For example, the shell script named "banana.x.do" is expected to produce the content for the file named "banana.x".

When you say

    # redo banana.x

    sh -x banana.x.do banana.x banana XXX > ZZZ

   $1 denotes the target file
   $2 denotes the target file without its extension
   $3 is a temp file: XXX, in this case.

If banana.x depends on grape.y, you add the line

    redo-ifchange grape.y

The only other commands I haven't mentioned are init and redo-ifcreate, which are obvious and rarely used, respectively.

That's it.

Not quite sure what you mean here. The scripts don't do anything complicated and redo catches errors that could occur.

As for readability, etc, I suppose it's relative. Simple makefiles do read very nicely. Unfortunately, they aren't always simple and hairy makefiles are just horrible to write, read and maintain. I've had no such problems with do scripts.

You're right, of course.

> Also, I think you wanted .o, not o.

I would, yes, but I copied the Makefile ;)

Should have been clearer; I meant that redo is simpler (and more reliable) than make.

For simple projects, redo scripts are a bit longer. However, as the projects grow, the redo scripts reach an asymptote whereas Makefiles don't. The only way to reduce the growth in make is to add functions and implicit rules which get ugly real fast.

For instance, redux [https://github.com/gyepisam/redux] is written in Go (not compiled for binary distribution, but I could add that), is cross platform, supports any mix of languages and tasks, is very easy to learn.

It uses shell scripts to create targets so everything is scriptable. Stuff like recognizing standard folder hierarchies and auto-discovery can be added with small scripts or tools. It can be as simple as you want or as complex as you need.

    CXX=g++

    hello: main.o factorial.o hello.o

    clean:
        rm -rf *o hello

    cat <<EOF > @all.do
    redo hello
    EOF

    cat <<EOF > hello.do
    o='main.o factorial.o hello.o'
    redo-ifchange $o
    g++ $o -o $3
    EOF

    cat <<EOF > default.o.do
    redo-ifchange $2.cpp
    g++ -c $1 -o $3
    EOF

    cat <<EOF > @clean.do
    rm -rf *o hello
    EOF

These are just shell scripts and can be extended as much as necesary. For instance, one can create a dependency on the compiler flags with these changes:

    cat <<EOF | install -m 0755 /dev/stdin cc
    #!/bin/sh
    g++ -c "\$@"
    EOF

    # sed -i 's/^\(redo-ifchange.\+\)/\1 cc/' *.do
    # sed -i 's}g++ -c}./cc}' *.do

[1] https://github.com/gyepisam/redux

There are many differences between the two implementations, some quite fundamental. redux uses sha1 checksums instead of timestamps. Timestamps cause all sorts of problems as we know from make. apenwarr redo has all sorts of extra utilities to ameliorate the problems. redux has the minimum functionality needed for the task (init, redo, redo-ifchange, redo-ifcreate) and I don't think it needs any others.

Redux passes most apenwarr tests. The few it does not pass are apenwarr specific. I've not tried the converse. Might be interesting.

I actually have a task list to add an apenwarr compatibility mode to redux so users can switch easily. At that point, it should pass all the apenwarr tests.

Of course, redux is quite a bit faster too.

Makefiles work great most of the time, but become difficult when you need to do things that don't fit well with the make model. I do a lot of multi level code generation, for instance, and make requires a lot of incantations to get right. Whereas redo works exactly the same way regardless of the complexity. I used make for many, many years and got very good at using it before I decided to implement something new.

> Also, I don't think it is a good idea to implement this in Go...

I choose Go because I would not have enjoyed it as much in C. I did not use Perl or Python because redo is used recursively. Perl and Python startup were too slow. I actually wrote a shell implementation that served me well for a while, but it was too slow.

Likely, there are those who won't use it because it's Go and that's fine. I've solved my problem and made the solution available to anyone else to whom it might be useful.

>But honestly, redo don't address any issue that "make clean; make" wouldn't solve.

Fixing make's reliability issue with "make clean; make" is like rebooting Windows when it hangs. Yeah, you can do that, but it doesn't actually solve the underlying problem. With redo, you don't need need to do that.

See https://github.com/gyepisam/redux

It's an implementation of DJB's redo concept.

I wrote it because I needed a build tool with exactly the features you describe and none of the alternatives had them.

I encourage you to try it out and provide feedback if necessary.

   There was a child went forth every day;
   And the first object he look’d upon, that object he became;
   And that object became part of him for the day, or a certain part of the day, or for many years, or stretching cycles of years.

What yardstick are you using to determine your level of suckage? Is it true? How do you know? If it is true, do you care? If you care, in what way do you care? Does it matter? If it matters, is it important? How so? Hopefully, the books you have read will help with the answers. You may not be able to answer all of these questions (and honestly, the answers don't matter too much), but they might serve to orient you.

I have read a fair number of the books on the list (and many more not on the list) and can truly say that I am a better human being for doing so, according to my criteria.

I am glad to see Csikszenmihalyi on the list as well. Flow is a very powerful concept; we all know it, but understanding it and using it effectively is a different matter entirely.

After reading The Miracle of Mindfulness by Thich Nhat Hanh, I realized that all three books are actually talking about the same subject from different perspectives.

To this list, I would add:

anything by Robert Grudin, but especially:

Time and the Art of Living and The Grace of Great Things

How to solve it by G. Polya

Conceptual Blockbusting by James Adams

Nice to see the Mortimer Adler recommendation as well, but I think his How to Read a Book should be a prerequisite for serious reading.

As I've gotten older, I've come to the conclusion that true understanding requires the kind of depth that comes from knowing one's self intimately. It's a lot harder than it sounds, especially for a technologist.

[1] https://github.com/gyepisam/redux

https://github.com/gyepisam/redux

I took the office, finished the software, and quit.

Depending on the environment, the change will bring its own set of difficulties and those will need to be addressed. Sometimes, it's a matter of the people involved. For instance, you are the only one passionate about a new language and others are not or is willing to learn and others are not, etc, then you suddenly have a new problem that may not have existed before, including having to support your colleagues through the transition.

As for arguments, etc, those should arise from your situation. If the current system is not working, make that clear. You may have to repeat yourself to get the point across. But do your homework first. Know what's broken and how your suggestion will fix it. Know the advantages of the current system and the distadvantages of the new one. "Trying something new" does not seem like a good reason; surely there's a reason why you use language X?

I live in mostly white neighborhoods because that's where I and my family wanted to live.

It was not to show that we had "made" it or to give the neighbors the opportunity to demonstrate their lack of racism. I think, far too often, people focus on race and don't realize that class distinctions are frequently better indicators.

On that basis, it seems quite reasonable to choose to live amongst people who are similar to me and not amongst those who aren't.

As it turns out, I'm now in South Africa and it's easier to see my point. Most of my neighbors are black or "colored" but I live near them because it's a nice neighborhood and not becuase of their race.

This is generally true. However, the United States is a multi ethnic country. So the question is, does this statement apply to all ethnicities, everywhere? The fact is, for a large number of Americans, they are "the foreigner" exactly in that position most of the time.

If the standard syslogd is inadequate, how about using a different logger? Gerritt Pape's svlogd, an implementation of DJB's daemontools loggers, solves this problem very nicely, is very reliable, can log over UDP and write to disk if desired. Heck, it can even replace syslog and run more reliably.

Not to say that this software is not useful. It is a great solution if the client software insists on using syslog and cannot be modified or reconfigured and syslogd cannot be modified or replaced. However, these are quite specific and generally unusual cases. For more prosaic circumstances, there are simpler and better solutions.