HN user
Yeah, the Mitnick hack of Shimomura (rsh + predictable TCP seq #s) was already out there due to that incident's publicity.
How many BOFHs generated keys for everyone, mailed them out, and disabled telnetd / rlogind?
Nice. like a command-line version of Charlie Cheever's bunny1. https://github.com/ccheever/bunny1
Yeah, Harford overweights the trade-offs and does not cover any benefits.
For parents, one large gain is explaining your work to your kids. They get to see how you work, and this provides a template for them. Of course, whether this is good or not....
Yeah, think cheap and distributed. Like Tsutomu Shimomura's quiet Xterminal connected to a noisy box in another room.
The alternative gamer-mentality of tightly coupled cpu, gpu, and storage with huge IO is quite costly.
Though, if your bias is towards action, how do you avoid stepping on toes?
These discussions seem like MBA brain-teasers, ie. there can't be any hard and fast rules, so each case needs to be individually worked out.
There's probably a sub-reddit for this.
Yeah, it seems odd that a golang solution was used instead of just shell.
paths() {
dir=`dirname $1`
while test "$dir" != '/' && test "$dir" != '.' ; do
echo $dir
dir=`dirname $dir`
done
}
find $dir -type f -not -path '*/.git/*' | while read file; do
cnt=`wc -l < $file`
for d in `paths $file`; do
printf "%s\t%s\n" $cnt "$d"
done
done | awk '{
hierarchy[ $2 ] += $1;
}
END {
for (dir in hierarchy) {
printf("%8d %s\n", hierarchy[dir], dir)
}
}' | sort -rn | head | sort -k 2One of the best classes I ever had was a stats class where the prof assigned a paper a week for us to review and mark up any and all faults. In the beginning, the papers were from journals like The Canadian Journal of Forest Research (which we came back with drenched in red ink), by the end we were punching holes in the Lancet.
Granted, the papers and progression were hand-picked by the prof. However, the final effect was that the students became fairly competent at reviewing papers in general.
Gnu M4 manual works well, while for TeX there's the Gentle Introduction.
For an abstract, design/implementation introduction, though? There isn't. We don't learn about macro languages just as we don't learn about domain specific languages.
Schools don't teach macro languages is probably the biggest problem.
Before YAML or Dockerfiles, it was the way to declare state and reduce complexity for sysadmins. Basically, any time you had data that needed multiple projections (eg. hosts to forward and reverse zonefiles), you reached for m4. The same went for unwieldy configs (apache, sendmail, etc.).
Culturally, macro languages seem to be just learned ad-hoc, ie. how many here have had a class in m4 or TeX?
Yeah, Audit for the win.
And it's not "billing", it's Compliance + Bill Presentment (marketing!) where we are always trying to find the most profitable local maximum of explainability to Sales, Customers, and Management/Enforcement while also having hard checks to prevent or at least mitigate losses.
No one wants a Knight Trading excursion....
Yeah, think like equity analysts during upturns, and in a downturn think like credit, ie. map out the sources and uses of funds.
The big caveat here is rising rates on floating rate debt, and the marginal response of revenue to higher rates.
I guess CCAN died?
Yeah, this is received unix lore: anything needed to recover a system needs to be statically linked and in /bin or /sbin.
The gnu m4 manual is the go-to documentation.
One way to think about m4 is as form-substitution, eg. the ssh-config customization via sed.
Another is as text generator, eg. the classic sendmail config generator, where one writes m4 succinctly which in turn generates complex files.
From a 10,000 meter perspective, all the managed servers' config files are a projection from the central config repository. If that config is already an m4 file, then all that's left is finding the variant configs and handling them.
`make` is another nicety, as it handles the dependencies, eg. scp'ing the config and then HUP'ing the daemon only when that config changes.
Corollary to this is that Conferences are judged not by their overt content, but by their curation of the un-conferences / birds-of-a-feather meetings that they facilitate.
Seems like it should use m4 instead of sed/awk for the templating. And `make` for the dependencies that will arise, eg. HUP sshd after config change.
Typing directly into a shell is a smell for teams that manage unwieldy-without-automation amounts of machines.
Shells are just REPLs; use your editor to drive them. This helps document what exactly was done on a machine, and encourages code re-use (yank-put from last time) and other tidbits you get when editing (git repos, git search, etc.).
Yeah, it seems a lot of this reduces to preferences.
FWIW, my email has just INBOX, Archive, and Todo. When documenting, I will log the message-id of an email, so that I can just query on that later. For me, this feels like a don't-make-me-think kind of setup, where I just swipe left-or-right through my inbox (which is ~100 emails/day) and then process Todo into Archive.
A couple reasons maybe:
Specialization means everyone's chasing their own frontiers in their companies, which leads to less toe-stepping?
"Everyone knows" IT is complex. So as long as things are working, there's no real impetus for other people in the company to sully their shirtsleeves.
Technology robbed workers’ of what had been highly valued physical knowledge about a job: the precise way to jimmy a stuck gear, the sound a machine makes when something’s about to break.
lol. I run IT. Nobody at my workplace knows what I do.
Contrary to TFA, my automation gains accrue to myself and my company. It seems difficult to see this as anything but win-win. I get respite and time to think, and my company gets improved responses and uptime.
It's good to practice the different situations.
I spend most my time `duck-talking` with a TeX doc that alternates between annotated questions and answers from some REPL. When I go AFK and have a problem, I try to punt because otherwise I am much more likely to make a mistake. :/
Definitely. Nobody likes forklift upgrades in PROD. Unless it's a complete wreck and one's much better off moving to a different country or the like.
Even smaller, more incremental experiments can be difficult to imagine. eg. beyond a multitool, smartphone, and computer, what additional things have high value? The multitool has high unexpected utility in that I would have predicted near zero and I now use it all the time. So it's likely that I am blind to other possible improvements.
True. Was angling for that with the "that those will remain stable".
It seems easier to personally define what one thinks winning is, and then evaluate (and modify if possible) the games we come across.
Recognizing the games that others are playing is useful, however refining your own games seems the much better play.
What are your personal win conditions? What are the odds and your confidence in those odds that those will remain stable for the rest of your life? Are any inconsistent with the other conditions?
Are all your win conditions attainable? Can you create a simple-to-follow path that leads to those win conditions and avoids going near loss conditiions? Will that path clash with any other people's win conditions paths?
Makes me respect game worlds designed so people can play however they wish.
Lots of people live out full productive lives in SQL, R, etc.
I like the article's idea that DSLs are 4GLs. ie. crafting the nouns and verbs needed to work a problem.
"strong preferences for navigation over search" is surprising to me.
For email, Inbox Zero means everything is basically in Archive, and is findable by successive application of filters.
For files, the requirements of a "project", ie. related files in one repo, means I need to traverse directories.
Mapping memory parts by attributes is way easier for me (file was written in SCSH, something something Pascal's Triangle) than mapping to hierarchies (is that in pkg/scsh or pkg/cs101 or ...).
Hard to believe other people have super good mapping of memories to file hierarchies. Or maybe just repo-based hierarchies is dumb?
Also, one should subscribe to the mailop mailing list, which serves as a Distant Early Warning line for email deliverability issues (ie. like NANOG for netops issues).
Maybe self-host an IMAP server, and periodically archive from FM to your box/VM?
A couple sysadm red flags:
1) The article author is Testing in PROD
2) selinux debugging relies on auditd, so sanity checks required.
df -P /var/log/audit # has space?
tail -1 /var/log/audit/audit.log # is recent?
semodule -DB # disable dontaudit
setenforce 0
# run the failing test
audit2allow -l
mk_semod() {
module_name=$1; shift
audit2allow -l -m ${module_name} -a > ${module_name}.te
$EDITOR ${module_name}.te || return
checkmodule -M -m -o ${module_name}.mod ${module_name}.te
semodule_package -o ${module_name}.pp -m ${module_name}.mod
semodule -i ${module_name}.pp
}Definitely. Debugging loves `duck-talking`.
Didn't mean to come across as REPLs consisted only items in the set of { programming , shells }.