
How GitLab Abandoned the Unix Philosophy - MilnerRoute
http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned-the-unix-philosophy/
======
wyqydsyq
Interesting that they supposedly "abandoned" the Unix philosophy, when as far
as I'm aware, they never followed it. Seems this article's title is simply
clickbait.

GitLab is not just a program, it is both a collection of programs, and a cloud
SaaS, neither of which the Unix philosophy is applicable to. The _entire_
purpose of GitLab is to do multiple things, extending git's functionality with
issue tracking, wiki etc.

If you want to do one thing and do it well then you should be just using the
git CLI.

------
dredmorbius
There's a fairly logical (and consistent) place to abandon the Unix
philosophy: a complexity hub.

That is, some nexus at which a large number of elements come together and are
either controlled under direct user input, or a large number of frequently
divergent-protocol systems come together. Shells, databases, email, remote
filesystems, IDEs, udev, and firewall rules would be among the examples I've
previously compiled. Test environments certainly fit that bill.

GUIs are another case.

ESR, in his babbling dotage, still occasionally makes a cogent point, and has
noted that elements which don't simply _pipeline_ elements, but have to create
a complex structure or connection (which is to say: they don't fit the Unix
pipeline model) are another general exception class.

[https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...](https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyranny_of_the_minimum_viable_user/)

------
peterwwillis
At a previous company, manager X wanted to adopt a new monolithic proprietary
software suite, and have us write feature drivers for it.

I said, "OK. So we should write these drivers in way that makes them
independent from the software suite, so that when this software suite is
obsolete and we start using something new, we can still retain and reuse our
developed features. Right?"

His answer: "Well, we're going to invest a million dollars in this software
suite, so clearly it's not going to be replaced! Just write the drivers as
quickly as you can."

Two years later, the project was obsolete. The driver features were rewritten
for a new software suite.

A UNIX-style design is less simple than a monolithic one, but it gives you
real-world benefits: saving time and money on not re-developing features, the
ability to adapt quickly to change, flexibility/compatibility. I think the
reasons for abandoning it are often short-sighted.

~~~
praneshp
Can I know what happened to manager X?

------
aphextron
If you've tried setting up a self hosted GitLab install, you quickly
understand the wisdom of that abandoned philosophy.

~~~
Aeolun
You mean, `apt-get install gitlab`? Yeah, I think I can live with that :)

~~~
gabrielcsapo
or even faster [https://www.digitalocean.com/community/tutorials/how-to-
use-...](https://www.digitalocean.com/community/tutorials/how-to-use-the-
gitlab-one-click-install-image-to-manage-git-repositories)

------
ivanbakel
>The best packager in any tech wave wins though, and wins big.

Since this feels the like main point of the article: what makes the "best
packager"? The only complete stacks I've ever enjoyed using broke their own
philosophy and let you integrate external tools, because that's what you're
already using. Does the "best packager" somehow produce a package which is the
best in all aspects, or do they make the most widely-used package - in which
case, they'll shatter the monolith more often than not.

The example that comes to mind is Microsoft's VCS built into their TFS stack.
It is a pain to use from personal experience, but the most grating thing was
the centralisation - if you need a decentralised solution, you'll probably end
up using Git, and MS support it for that reason. Does this make TFS good for
being useful, or bad for failing to meet needs?

~~~
flukus
With TFS, integration seemed to be about the only selling point, every single
component was mediocre at best. But the sales model of TFS was a bit
different, they weren't selling to devs, they were selling to management, who
only look at the big picture.

Rather than being a better SVN, MS seems to have tried to build a better clear
case. They weren't trying to be the best packager, they were trying to create
the best monolith from scratch.

------
AdmiralAsshat
Adherence to Unix Philosophy isn't a prediction of success. Look at the
popularity of Slack. The kitchen sink approach can be very profitable as long
as _most_ of said features work.

------
eikenberry
TLDR; Gitlab are using internally/community developed, better integrated tools
vs. creating a marketplace for integrating external tools. Nothing really
about the Unix philosophy other than the title.

~~~
zeckalpha
Do one thing and do it well, vs do many things and do them just okay.

~~~
xfer
the reason people use git hosting tools is because they do many things(version
control, issue management etc.). Just because gitlab does CI/CD also, doesn't
mean they will automatically do it "just okay". This article has nothing to do
with unix philosophy. Using a sophisticated code hosting tool is like using
unix itself where all parts work with each other well.

~~~
zeckalpha
By "just okay" I meant that GitLab is a good example of the "worse is better"
Unix philosophy.

