

An example of command-line bullshittery in computer science research - yarapavan
http://www.pgbovine.net/cmdline-bs-example.htm

======
todd8
I had Professors David H. Hubel and Torsten N. Wiesel for a really great
undergraduate class. Later, to satisfy some undergraduate EE research
requirement I did some work for Dr. Hubel. Hubel and Wiesel went on to win the
Nobel prize for their research on the origin of visual perception in 1981.

It all sounds like a great story to tell my kids except for one thing: I
didn't end up helping them in their research even one tiny bit. All I ended up
doing was extreme command-line bullshittery for a semester trying to get a
PDP-9 (an 18bit machine!) to talk to a system with some home-brew crt-to-film
based output device. Everything had to be coded in low level assembly language
and even booting up the PDP-9 in a dark lab was intimidating for someone
starting out in CS, not to mention the strange hardware it was hooked up to
("flip this switch but not until the power supply to the film writer
stabilizes", etc.)

In the end, Dr. Hubel couldn't have been more understanding, and it ended up
as a good experience for me. Not because I did anything productive but because
I had a sympathetic professor. Today, I've been programming computers for
almost half a century and it's been great. I'm so grateful for the teachers,
professors, co-workers and colleagues that have helped me over the rough
spots, command-line bullshittery, and my own ignorance over the decades. It's
nice to hear the concern Dr. Guo has for his students in the originally cited
article (despite the frustration it ends up causing for him).

------
z5h
Another name for phenomenon is: "reality". And the typical way non-"computer
science researchers" overcome it is through a system known as "working" or
"doing work". As a software developer, I sometimes do so much work in a day
that I can barely write a line of code.

~~~
audleman
Gotta concur. Setting up an SSL certificate or firewall do not constitute
bullshit. The complexity of these systems lies in their solid engineering, not
any inherit flaw.

SSL is designed to be secure, not easy to learn. I remember how painful it was
to set up root certificates the first time I did it; combining certificate
files, setting permissions correctly, configuring nginx. It's a pain in the
ass. But as a result nobody can snoop on messages between me and my users.
Worth it.

Firewalls are firewalls; having one in place means when you send a request to
your server sometimes nothing will come back. Yes, if you've forgotten you
have a firewall this makes it hard to debug. But if the firewall returned any
kind of response it would be less secure.

I am bemused that the author finds this to be demeaning, merely annoyances
blocking him from doing his pure "research." I suggest he take the time to
study these systems and learn why the annoyances are there. Who knows, out of
that might come a new research project that improves the way the world uses
SSL!

------
lotsofcows
Man, tell me about it! I needed to do some original research the other day and
had to get to an out-of-the-way library.

Do you know how hard it is to learn to drive? Took me 3 months! And don't get
me started on buying cars and insurance... All I wanted to do was read some
papers!

------
aychedee
Professor discovers that actual system creation is painstaking and easily
becomes very painful unless great care is taken to manage the complexity...
and all he's trying to do is hack two servers together. Imagine if his service
had to be reliable!

