[hspak]

You can call command line bullshit, but at the end of the day it has the least amount of abstraction meaning more visibility in what's actually happening. Visibility is always nice, especially when something breaks.

Say there was this nice GUI that built and setup lot's of projects for you. Who's responsibility is it to make sure that everything it supports stays supported?

[analog31]

Invariably, unless it's a major software product with a lavish budget, the GUI based setup program is less intelligible than the command line, and is accompanied by instructions consisting of page after page of screen shots, "with circles and arrows, and a paragraph on the back of each one," to quote the balladeer. And when the next version of the OS comes out, or a new version changed the installation slightly, the instructions are invalid, but were too costly to update.

After years of that, "sudo apt-get install" was like a breath of fresh air.

[jqm]

You can get anything you want with Make and Make Install.

[zem]

If you argue that supporting the GUI is an undue burden, you're merely shifting that burden onto everyone who has to perform the same steps manually every single time. Automating or away may be more up front work, but it only needs to be done once.

[ddingus]

Until it needs to be done again.

Things change. It's a balance between the pay off and the ongoing investment to maintain the automation.

[zem]

right, but it needs to be done again by the single person maintaining the automation tools, who presumably is more of the "programmer" than "user" inclination. everyone else in the lab benefits.

[ddingus]

And who is that exactly?

For long established, regularly used tools, there is a case for funding this activity somehow.

For the many specialized tools? I'm not sure how this would actually happen, unless the person who creates it decides to maintain it. When their career focus doesn't value that tool, we can't really expect anything.

Worse, let's say some established systems exist. They have a barrier to entry in that new software needs to be compliant and potentially integrated on some level. People already are focused away from this stuff. Raising that bar means fewer overall contributions.

Now, it's often: I wrote this. It's open. You can use it.

And they move on.

If, suddenly, I wrote this, and it's open gets followed up by, "you need to make sure this works with all this other stuff..." what happens?

[zem]

i meant, if there is an organisation (the OP's example involves a university department, but this holds for other places too) where the majority of people simply want to use computers to get their work done, it is well worth having one person (or a team, as things scale up) whose job is to automate all the incidental details of working with the operating system and environment, so that people don't have to context switch from a "user" to a "programmer" perspective all the time.

[ddingus]

Seems to me those people, or person would also have to be pretty great generalists.

A lot of research type tools get written and then left laying a out. Just testing and packaging, integrating, etc... would be a considerable project.

Could be the basis of some sort of course or career though. I'm thinking of the sysadmin types who manage software and research teams outside academia. The really good ones I know used to hold a position, or have some personal interest sufficient to make these sorts of activities make sense.