Comment by q3k | Hacker News Reader

Comment by q3k | Hacker News Reader

Parent Full thread

> This is not what I see in my career. Bulk of the applications we installed and ran used some forms of environment variables for runtime configuration of the tool/application.

I think we might have different backgrounds and considerations as to what counts as 'oldschool'? Maybe I shouldn't have extrapolated this to pre-2000... So, my experience comes from working with the following 'mood' of services:

  Postfix, Exim, qmail, slapd, PostgreSQL, MySQL, FreeRADIUS, Apache, Nginx, ...

All of which have their own config file/files, format, etc. All of these system-wide services, not user applications. And I think that's the main difference? I tend to deal with software that is deployed in isolated environments, be it by root users on production server, or by whoever in a containerized environment. And not deployed on an interactive systems, to then be started/reconfigured by users running on the same system.

> I've never seen it TBH, and if that's not documented well, it would be a big bag of fun for the users of that code.

Check out the list above on Dockerhub. I'm not sure all of them are dockerized in this way, but at least a handful of them are.

I've further clarified my PoV here [0], but it won't hurt to reiterate. I'd be happy in fact.

> I think we might have different backgrounds and considerations as to what counts as 'oldschool'?

Most probably. All of the software you mentioned (maybe except Exim4) is actively used in our environments, quite a few of them are in very vanilla configs, and some of them are customized to the point of abuse. However, it's worth mentioning that all of the software you mentioned are in support roles in our scenario, they're the so-called side dish which we configure once and leave alone for a very long time.

> Maybe I shouldn't have extrapolated this to pre-2000...

I've started with a C64, please. :)

> All of these system-wide services, not user applications. And I think that's the main difference?

Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work, but as I said, they all have configs and env variables are convenience overrides most of the time.

> Check out the list above on Dockerhub.

Will take a look, thanks. Wanted to learn docker in depth for a long time, but had no notable project to force me to use it. Maybe someday.

[0]: https://news.ycombinator.com/item?id=26660409

> I've started with a C64, please. :)

Personal experience in computing is not what I meant. I only realized that I'm not intimately familiar of the dawn of the UNIX daemon and how their configuration methods changed with time, only the echos of this in daily Linux use. Thus, I realized I was possibly extrapolating and assuming things.

> Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work.

Yeah, and I think this lack of distinction is what poisons the discussion surrounding this post - these are separate worlds with different requirements, conflated into a single argument or point of view.

tl;dr I stand by my point with preferring anything over environment variables for services (especially complex ones), but I also fully agree with your usecase for interactive, CLI-driven systems. I mean, one of my favourite programming language features in recent years is that I can cross-compile Go programs just by setting two env vars: GOARCH and GOOS :).

I'd be absolutely horrified if a service that I use need a specific environment variable set in a particular way to work correctly and it's not well documented. That service would get bonus points for inability to configure that particular option in a configuration file.

I personally would never add environment variables to a program I write which may run as a service.

Oh, Java is calling, hold on... :)

Reply on news.ycombinator.com