this feels like a silly thing to say but even though i’ve been using linux since 2004 I feel like i’m learning recently that the impact of the GNU project’s software (and its design decisions) on me is even bigger than I thought
like even just the fact that (afaik) many of them used Emacs has an impact on me today
(please no “it’s GNU/Linux”)
for example I thought the “vim vs emacs” flamewars were silly (who cares? use what you want!)
but actually I feel like some of the GNU software design decisions are really influenced by emacs (readline, info pages) and that does actually have an effect
(please don’t tell me that readline has a vi mode)
(2/?)
also this guidance on command line arguments is great, I didn’t realize these things came from the GNU project and I really appreciate them https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces
(via @zwol)
(3/?)
also I didn’t realize that standardizing “—help” came from the GNU project, it makes me wonder if folks have proposed adding —help to programs that predated GNU (or are from a BSD project etc) and if so what that conversation looked like
I imagine it’s not always possible to do without breaking backwards compatibility
(4/?)
anyway i’ve been thinking about how to understand the way “the terminal” works it feels really important to understand the cultural impact of specific programs or projects (like xterm, the GNU project, etc)
i think it’s something a lot of people are intuitively aware of just from using the terminal and noticing patterns
(5/?)
@b0rk I couldn't agree more.
The more history I've learned about these things the more the way they work makes sense.
@b0rk in '94 I used (sun's) db (dbg?, does anyone remember?) and a friend asked me why I didn't use gdb. It was such an amazingly different experience, the gdb ui seemed to be designed with care---dare I say love?---for an actual human (me!) using it.
I went to read all of gnu.org, the philosophy (empowering the user instead of keeping them ignorant), the coding standards (info instead of elitist manual pages, no arbitrary limits, etc ...) and decided I wanted to be part of this.
The reason some of us prefer to say GNU/Linux is rooted in the idea that even people that have been using "Linux" for decades, may not have heard about GNU.
https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals
"GNU Manuals
The preferred document format for the GNU system is the Texinfo formatting language. Every GNU package should (ideally) have documentation in Texinfo both for reference and for learners."
Info manuals usually have a philosophy section, an introduction, a tutorial and describe the relationship of the software with other softwares. Some manual pages nowadays also give examples, but in the 90s the main feature of a man page, as I experienced it as a newbie, was terseness with no regard for (dare I say a elitist disregard?) for learners like myself.
@b0rk yeah, the info experience outside of emacs is pretty terrible. I believe there was a short period where GNOME/Yelp would seamlessly present info pages.
Info manuals tell a story, for power users and learners alike. Link between different concepts. Usually have a tutorial. All of that is missing, for example--not wanting to single out one non-gnu project-- in an avalanche of manual pages.
If you want to learn about Linux (the kernel), wouldn't it be amazing if there was a manual for that? There is one for the Hurd.
@b0rk we have been living in mostly different bubbles.
When I read "We will use Emacs as our editor" and I realized that was the single one statement that I had a problem with (being a happy VI user for some years), it occurred to me that this was probably caused by a problem with my perspective.
I then spent three summers to try to learn Emacs. That's some 25y ago. I can't say whether it was having context aware info pages with just a keystroke away next to your program text, being able to copy stuff without even having to glance at your mouse. Or whether it was the automagical (re-)indentation of code. Or something like the debian-changelog-mode when creating a Debian package.
Together with a friend I went to create GNU LilyPond which was often praised because of its documentation. I now hear similar praise about our Guix manual.
@b0rk that seems useful (unless maybe when you're running a shell inside de Emacs, you prolly don't want a GUI browser to spawn, bt that's details).
Which reminds me, I believe there was a proposal to add up, previous, next semantics to html and it got rejected.
One of the amazing things about info (esp in emacs) is that you can read the whole document just by hitting the space bar. For, next screen and next section alike. No such thing exists in web browsers today. Similarly you isearch or regexp-search, go to node, jump to index entries. Once you're used to it, using HTML documentation becomes terribly cumbersome in comparison.
@b0rk @janneke I failed to read Info manual although I consider myself comfortable with Emacs and tried several times over the years. Well, local manuals in HTML format missed me… a lot! Then one day, reading yet another message by some Guix wizard advocating for Info, I decided tp try again, so to force myself to only rely on Info for two weeks… Today, I don’t look back. 😀
Even, today, I “regret” that Info isn’t the standard for locally browsing any documentation. 😁
@b0rk somewhat aside, a lot of old unix tools would balk at "cmd file -opt" but gnu tools had no issue handling options coming after arguments
i had a friend who used to complain of "gnu bloatware" until he was forced to use (fairly old) solaris at work and he installed the gnu userland tools within minutes of trying to get the older tools to behave in ways he was used to
Yea; back in "the bad old days" it was common to roll our own command line parameter parsing.
Didn't have the memory for reusable libraries in a 64K byte address machine.
"getopt", with the "--" long option names was a significant improvement. And "--" by itself to *STOP* option processing at that point, forcing all other "words" to be file names.
Julia Evans
Flesh & bone by the telephone
filipa mv
Janneke
Luis Villa
Simon Tournier
tef
Joe ❌👑
Jeff Grigg
Steve Wart
Nelson Minargcc and glibc. Or if there were, it'd be very very different. I think the community has outgrown the FSF now but I have great respect for what they started.@b0rk @nelson The GNU project was also an early champion of portability. They *wanted* their software to work everywhere to show that their stuff was *good*. So they built it that way. That had an outsized impact on how people thought about software portability.
(Fun fact, glibc is the only C standard library implementation that worked on multiple operating systems. Nobody else ever did that before and I haven't seen such a thing since.)
@Conan_Kudo It was more of necessity, no free operating system existed back in the early 90s.
The GNU C library has only worked with the GNU system and variants (GNU/Linux, and GNU/kFreeBSD). I'm not aware of any other system where glibc was supported.
@puppygirlhornypost2 GNUTLS is part of the GNU project, and maintained by Simon Josefsson.
@b0rk yeah, i get irritated and some of their software is now crusty, but they got a snowball rolling that turned out to be bigger than i could have imagined.
i also remember seeing something about Wikipedia early (possibly Nupedia?) and thinking it was a foolish project--wouldn't get the mass or the accuracy.
for both projects i was extremely wrong, and the details of how the 'impossible' happened are fascinating!
@rf @b0rk I remember Nupedia well. I tried to help edit a few entries. 1999-2000 Eric would not have believed how things turned out.
In a way though, the evidence was already there with Linux and GNU that it was possible. Even though I had dabbled with both I didn't make the connection in the slightest that it could be applied to knowledge, too.
@b0rk it is absurd that this man just one day said "fuck it, we ball" and slaughtered AT&T's bazillion dollar OS business
that's like deciding to fight god
@b0rk people mock the "GNU Coding Standard" because its specification of how to indent C is legitimately weird. But that's actually the least important part of the document. There is stuff in there about how programs should *behave* that's been much more influential.
https://www.gnu.org/prep/standards/html_node/Program-Behavior.html
@zwol “Please define long-named options that are equivalent to the single-letter Unix-style options. We hope to make GNU more user friendly this way.”
i had no idea this was the goal and it’s so good
@Conan_Kudo @b0rk @zwol Eh? There's definitely still a bunch of getopt(3) usage, even though getopt_long(3) is in most Unixes libc.
And when it comes to long options implementation (which if you see the dd command, inspired from IBM JCL, isn't just a GNU thing), there's often different behavior, for example accepting = as separator or not, as well as accepting abbreviated names or not.
Which can get a bit funky in codebases like git for example where long options are rather prevalent but it's subcommands are implemented in different languages.
@Conan_Kudo I recently started making a makepkg clone-ish and at the start I thought "Imma try to stick to pure POSIX 2024 (+ cURL and bsdtar)" and not only was the shell syntax very limiting (specifically arrays, but I can work around that with HEREDOCs and newlines) but what made me decide "nope, Imma stick to "bash and GNU coreutils" is that all the tools only define the short options. It makes the scripts so unreadable :(
on a different note: I recently learned that GNU getopt allows abbreviating all long options as long as they don't clash (e.g. specifying --dir instead of --directory)
@gugurumbe @b0rk It says something about programmer brain that no one has ever seriously explored that possibility as far as I know, even though GNU and many others did do a lot of work on translating the *output* of programs.
Specifically, I think people become accustomed to thinking of programming languages as independent from natural language, even though almost all of them draw heavily on prior understanding of English. To the experienced, command line options are tokens of the scripting language "shell" and thus it maybe doesn't occur to them that they are also words in English that could usefully be translated.
It *would* be good to change that but it may well require a rethink of how the whole "shell" environment works ... which would be a good idea *anyway* of course...
Neal Gompa (ニール・ゴンパ) 
Alfred M. Szmidt
Amber 
rf
Eric Gerlach
owls
Zack Weinberg
Tony “Abolish ICE” Arcieri🌹🦀
Haelwenn /элвэн/ 
Nekko
Vivien (dentelle & numérique)
Jim Luther
Steven Woolgar
voidampersand
mirabilos