[HN Gopher] Dotfiles being hidden is a UNIXv2 mistake (2012)
___________________________________________________________________
Dotfiles being hidden is a UNIXv2 mistake (2012)
Author : varbhat
Score : 237 points
Date : 2022-08-11 16:08 UTC (6 hours ago)
(HTM) web link (web.archive.org)
(TXT) w3m dump (web.archive.org)
| swellguy wrote:
| He's probably just ignorant of how bad things can get. Hidden
| files in a home directory is a lot better than what other
| operating systems came up with (random directories and the
| dreaded registry). I'd call it a win - the search over a home
| directory inode is not going to bother anyone either way.
| jdlyga wrote:
| I love how so many behaviors we depend on were mistakes or
| temporary fixes
|
| "In the beginning the Universe was created. This has made a lot
| of people very angry and been widely regarded as a bad move"
| jiggawatts wrote:
| The standard UNIX file system layout exists because hard drives
| were small at the time and files had to be split across
| several.
|
| The VI keyboard shortcuts only make logical sense on a specific
| Tektronix 4014 terminal that was popular at the time: 46 years
| ago.
|
| The reason the delete key is broken in like half of all UNIX /
| Linux systems is because TTY is short for "teletypewriter" --
| literally a remote type writer banging out text on dead trees.
| The carriage can go back one character at a time and overwrite
| an error but it can't shift printed text on paper.
|
| Windows was developed in an era of CRT displays and delete
| works with it consistently.
|
| This is why it cracks me up whenever someone talks a out "Linux
| being the standard"...
| teddyh wrote:
| > _The VI keyboard shortcuts only make logical sense on a
| specific Tektronix 4014 terminal_
|
| The Lear Siegler ADM-3A, actually:
|
| https://en.wikipedia.org/wiki/ADM-3A#Legacy
| uncletaco wrote:
| Why would you do this to me I'm going to be in a rabbit
| hole trying to recreate this machine for the next two
| years. I've been in the hobby long enough that I only get
| excited about weird things like this keyboard that have
| historical significance.
| warmwaffles wrote:
| Nothing more permanent than a temporary solution.
| donarb wrote:
| "The fix is temporary, unless it works" -- Red Green
| game-of-throws wrote:
| The Garden of Eden was transitory.
| inopinatus wrote:
| Every omnipotent creator implicitly grasps that initial
| configuration matters as much as the automaton rules.
| victorclf wrote:
| Like Quake bunnyhopping and the SID 6581 being able to fake a
| 4th voice.
| rodgerd wrote:
| The thing that irritates me is that people then venerate these
| accidents. Yes, some accidents are happy; many are at best
| neutral or least-worst or what have you. And then *ix culture
| dies in a ditch that we must keep all of them, forever, as
| though they were the result of a carefully thought out process
| that produced the best of all possible worlds.
| shrikant wrote:
| HTTP "Referer" is the one that makes me sad.
| vikingerik wrote:
| At least that one saves a byte on every request. The
| cumulative savings are in the terabytes by now.
| hsbauauvhabzb wrote:
| The fact that terminals being an emulation of a teletype
| comes a close second.
|
| And the origins of /usr/bin a definite third.
| doctor_eval wrote:
| A teleprompter? Is that a typo? Did you mean a teletype?
| hsbauauvhabzb wrote:
| Sorry yes teletype.
| mort96 wrote:
| Honestly, the typewriter interface is pretty useful. A
| program can make text appear on the screen by just writing
| ASCII (or these days, UTF-8) bytes. The only sad part is
| the design of escape sequences, but that's more a
| consequence of chaotic evolution rather than the fact that
| it's emulating a typewriter (and most of the evolution
| happened with the early software terminal emulators).
|
| Honest question: How would you design a simple text
| outputting protocol? Would it be radically different to how
| it's done today, or would it be the same basic ideas but
| cleaned up a bit?
| R0b0t1 wrote:
| Hm, I've actually thought about that a lot. I'd probably
| keep the bytestream format. It is insanely useful.
| However I might open up multiple streams. Stream one is
| basic IO. Stream two could be formatting info. Streams
| above that implementation dependent, but you could
| probably start defining them for keyboard/mouse/HID IO or
| audio and video. Then to make it work over the internet
| just shove it over SSH or TLS.
|
| The one downside that has is if you separate the
| formatting from the data you can not recreate the session
| without keeping time info somehow. So, might need a fix
| for that.
|
| The only other real alternative I'm aware of is moving
| the formatting into the API "stream" that communicates
| using the machine ABI. This is a terrible solution. It's
| what Windows uses.
| hsbauauvhabzb wrote:
| I think that text output protocol is the wrong way of
| thinking about it. It should be a rich data stream
| capable of advanced features like objective stuff. Think
| ps, but then you're able to navigate the output and
| perform additional functions. I think a subset of html
| would work for this.
|
| I think the biggest danger would be scope creep, but a
| terminal shouldn't just be thought of as text.
| hsbauauvhabzb wrote:
| I've always been curious though, can VT escape sequences
| be used to perform user actions? E.g. can you coerce
| stdout to execute an additional command?
| quickthrower2 wrote:
| I recently learned about this "mistake". I always assumed the
| dotfile was some design feature by ancient "gurus" of UNIX rather
| than an accident.
|
| There is something nice and immediate about adding a dot to make
| it invisible to certain things (ls by default, the file explorers
| in ubuntu by default, etc.)
|
| A bit like file extensions themselves and the weight they carry
| in Windows.
|
| It sorts of balances in favour of immediacy of the function over
| "right way to do things", where the right way might be some kind
| of meta data for the file, or for it's folder.
|
| Funny thing about hiding, is what does it mean to hide? If you
| can ask your utility to show hidden things. It sort of means
| "things I reckon people don't wanna see, or shouldn't touch,
| unless they are willing to take a step to see it".
|
| A bit like a shibboleth where if you can't figure out how to see
| it, you are too dangerous/dumb to edit it, or even know about it.
|
| You could instead have security settings for that. Maybe you just
| don't give the user access to the files at all until they elevate
| from user to "poweruser". Which would be somewhere between user
| and superuser. Use chmod to set the permissions, instead of a dot
| filename format.
| throw7 wrote:
| Don't worry Rob. Freedesktop.org learned and spammed my home dir
| with Desktop/Document/Downloads/Music/etc/etc/etc...
| MichaelCollins wrote:
| I've never seen _anybody_ use these trashy preset directories
| as intended. Experienced users ignore them or delete them,
| using their own directory structure instead. Inexperienced
| users use one of them (usually Downloads or Desktop) while the
| others are treated as write-sometimes /read-never; e.g.
| sometimes they accidentally have files saved to those other
| directories which may as well be that file disappearing into
| the void never to be seen again.
|
| These presets only serve to confuse or at best annoy. These
| directories were well-intentioned originally but proved to be a
| huge mistake. They need to go away.
|
| (Edit: The above rant applies only to
| Downloads/Music/Video/etc. I think ~/.config and ~/.local are
| fine. I have no problem using those as intended, and I've seen
| plenty of other people using them too.)
| marcosdumay wrote:
| Browsers default into putting files in ~/Downloads, so that
| one gets used. DEs default into showing anything under
| ~/Desktop on your screen, so people disable the desktop file
| browser.
|
| ~/Documents is there because Freedesktop.org somehow thought
| they were dealing with Windows and tried to port the solution
| of problems Linux does not have. The other directories aren't
| used on any OS and only serve to annoy people.
| layer8 wrote:
| I don't know anyone who actually uses the Documents folder
| under Windows either.
| bscphil wrote:
| I don't know anyone, other than a few tech-ignorant people
| who put everything on the desktop, who doesn't use them.
| Where else would you put stuff like music, pictures,
| documents, etc? These different types of files usually call
| for different hierarchies, so you've got to do something.
|
| What do you do instead?
| Beltalowda wrote:
| A lot of people running more "minimalistic" window managers
| like i3 or dwm or whatnot don't really have a "desktop"
| like Windows, macOS, GNOME, KDE, etc. have, and everything
| tends to just go in ~, or some subdirectory of that.
| MichaelCollins wrote:
| >These different types of files usually call for different
| hierarchies
|
| I organize my files by subject, not file type.
|
| My files about space stuff go in a directory called
| 'space'. Files about the space shuttle go in space/shuttle.
| This directory contains _any_ sort of file related to the
| space shuttle, be it picture, video, pdf, epub, or
| otherwise. I don 't see any utility in breaking this
| directory apart into ~/Pictures/shuttle, ~/Videos/shuttle,
| ~/Documents/shuttle... Do you really do something like
| that? How far do you take this "different files, different
| hierarchies" principle? Do pdfs and docx go in two
| different hierarchies too? Are pngs and jpegs separated?
| What's your criteria for deciding when different sorts of
| files get different hierarchies?
| GauntletWizard wrote:
| You don't know a lot of people, then - Most people, the
| vast majority, are tech ignorant that way.
|
| The concept that files are cross-compatible, and usable
| outside the app that created them, is increasingly foreign
| to an online app oriented world.
| llanowarelves wrote:
| As an aside, the desktop is a great place as a TODO-list /
| sticky note. Your stuff sitting there is so present and
| ugly, you will feel anxiety to get it sorted to a proper
| place.
|
| I am more likely to do something with those files than if
| they are hidden away in Downloads (which is like a
| tempdir), or on windows, some User/Documents subfolder
| somewhere.
| bee_rider wrote:
| Downloads is fine, IMO. It is basically a temporary files
| directory. I'd be fine with changing the name to tmp, but I
| don't really see a reason to change the default.
| nmz wrote:
| Downloads is not a temporary files directory, that's what
| /tmp is for, I for one am using $HOME/Tmp instead of /tmp
| because /tmp is for whoever doesn't respect $TMPDIR big
| problem if you don't have much ram and you want to avoid
| writing to an sdcard. (assuming /tmp is tmpfs)
| naniwaduni wrote:
| Okay, it's persistent storage for potentially arbitrarily
| large files that probably came from a browser, that you
| haven't gone out of your way to find another location
| for. You can go pretty far outside the viable scope of
| /tmp, but still have the files' presence there be
| _logically_ temporary.
| MichaelCollins wrote:
| > _(assuming /tmp is tmpfs)_
|
| Not a safe assumption, annoyingly. Debian doesn't use
| tmpfs for /tmp; I guess they expect you to use /dev/shm
| if you want a tmpfs.
| nmz wrote:
| Which is non-portable.
|
| (Well, it exists in freebsd, but not openbsd, no clue if
| it exists in netbsd/minix)
| pfraze wrote:
| I actually use these extensively on my mac, believe it or
| not.
| Beltalowda wrote:
| > Experienced users ignore them or delete them
|
| I wish I could! But ~/Desktop and ~/Downloads keep getting
| re-created by ... something :-/ I tried setting
| XDG_{DESKTOP,DOWNLOAD}_DIR but it seems to get ignored. Been
| annoying me for years.
| epakai wrote:
| Modify ~/$XDG_DIRNAME_DIR/user-dirs.dirs (usually
| ~/.config/user-dirs.dirs). You can just point them all to
| $HOME if you don't want any sub-directories created.
| Beltalowda wrote:
| I'm fairly certain I tried this in the (distant) past but
| that it didn't take, but I've tried again; we'll see if
| it gets re-created.
| nobody9999 wrote:
| >I wish I could! But ~/Desktop and ~/Downloads keep getting
| re-created by ... something :-/ I tried setting
| XDG_{DESKTOP,DOWNLOAD}_DIR but it seems to get ignored.
| Been annoying me for years.
|
| Perhaps something like: ln -s /dev/null
| ~/Desktop ln -s /dev/null ~/Downloads
| etc.
|
| That would solve the problem, no?
| layer8 wrote:
| It wouldn't solve the problem of those directory entries
| being present.
| bogwog wrote:
| Well the Music/Video folders are probably less relevant now
| with the popularity of streaming. If you aren't using
| ~/Downloads, then that means you went through the extra
| effort of re-configuring your web browser for some reason. I
| don't think many people do that.
|
| Overall I think it would be productive to go back and
| redesign these old folders, even if it breaks some stuff if
| only to better reflect the way the new generation of
| consumers understands tech. There are probably a lot of young
| people who have never used a PC before, and will be confused
| coming into them with a background of smartphones and
| tablets.
|
| Maybe we should eliminate the Desktop folder completely, and
| only allow adding widgets/app launchers/shortcuts to the
| desktop rather than files. Using the desktop as a folder has
| always been a questionable practice since you can't even see
| it when you have a window open.
|
| At the very least, we should get rid of the "Templates"
| folder. I still have no idea wtf that's meant to be used for.
| jle17 wrote:
| > Maybe we should eliminate the Desktop folder completely
|
| Seconded. I'm irrationally annoyed that it gets created and
| sometimes filled with .desktop files while my DE doesn't
| even use it.
|
| > At the very least, we should get rid of the "Templates"
| folder. I still have no idea wtf that's meant to be used
| for.
|
| You can place files in the "Templates" dir to serve as
| templates for the "right-click > new document" feature in
| nautilus and some other file explorers.
| pdntspa wrote:
| Windows users use them, Mac users use them, hell even on a
| fresh profile in Gnome I use them...
|
| It is a little weird to see htem on a server OS install
| though
| rgovostes wrote:
| They _exist_ on macOS and Windows but I tend to agree that
| these directories are not particularly useful for users.
|
| Apple software tries to organize files but it's a disaster:
| iTunes used to download movies to ~/Music/iTunes/iTunes
| Media/Movies, now TV.app downloads them to
| ~/Movies/TV/Media/Movies (!), and videos I shoot on my
| iPhone end up in ~/Pictures.
| pdntspa wrote:
| There has always been a tragedy of the commons with these
| folders, nobody can agree on where a lot of stuff goes.
|
| Should my game saves go in Documents? What about
| Documents/My Games/Publisher? What about
| %APPDATA%/Publisher? Hell there's even a few in ~/My
| Games. Every new game, figuring out where the save data
| went is an adventure and it's cluttered up every folder
| it touches. And now for whatever reason everyone is being
| pushed to put user data in %APPDATA%, which I don't
| consistently remember how to get to without that
| shortcut. So who knows!
|
| I just looked up the save data location for Subnautica
| and it is (I shit you not):
| %AppData%\\..\LocalLow\Unknown
| Worlds\Subnautica\Subnautica\SavedGames
| ablob wrote:
| LocalLow is just %LocalAppData% for low privillege
| programs. The Roaming folder (%appdata%) is for platform
| independent data, and the LocalAppdata folder fo platform
| specific data. You can find the appdata folder in your
| userhome "C:Users\YourUserName\AppData", but it's hidden
| by default if you havent changed it.
|
| Edit: clarified what I mean by the Appdata folder
| pdntspa wrote:
| I am aware of that, those folders have existed as such
| since at least Windows XP. But only recently have I
| noticed consumer software placing fungible user data in
| there.
|
| IIRC at one point you couldn't even open one of the
| "AppData" homefolder aliases, Explorer would spit out
| some error message and you'd have to navigate to the
| hidden folder or key it in manually.
| MichaelCollins wrote:
| > _Windows users use them, Mac users use them, hell even on
| a fresh profile in Gnome I use them..._
|
| Really, you use _all_ of them? When you go on vacation and
| take some pictures and video of your family, do you then
| split those files between ~ /Video/Beach2022/ and
| ~/Pictures/Beach2022?
|
| I've never seen _anybody_ do this, not on Windows, MacOS,
| or any linux DE. Instead you get something like ~
| /Desktop/Beach2022 or ~/Downloads/vacations/Beach2022 or
| generally, a single directory anywhere (often on a USB
| harddrive, not their home directory at all), but never do
| those vacation files get split by filetype into ~/Videos
| and ~/Pictures, that seems like utter madness to me.
| klodolph wrote:
| I think pictures + videos from vacation are the
| exception. I definitely use the ~/Movies ~/Pictures
| ~/Music (or ~/Videos) folders to hold those types of
| media. I do this on macOS, Linux, and Windows.
| pdntspa wrote:
| Not exactly, but as I poke around those folders on my
| desktop PC, all of them hold various things. If I didn't
| have a NAS they'd hold a lot more stuff too.
| naniwaduni wrote:
| I find Desktop fine, it serves a distinct purpose; Downloads
| doesn't seem like the greatest idea, but works well enough
| considering browsers. Documents/Music/Video/&c., though, I
| definitely concur doesn't provide any obvious value being
| more than one directory.
| game-of-throws wrote:
| Imagine being the poor soul who had to implement Windows's
| "3D Objects" directory.
| layer8 wrote:
| I'm tempted to rename "Pictures" to "2D Objects" and
| "Music" to "1D Objects".
| kodah wrote:
| What Rob is griping about is more analogous to $HOME/.config
| now, or /var/run for non-user specific stuff.
| t-3 wrote:
| It's even worse with dotfiles nowadays than before. We have
| the cluttered "xdg" dotfile directories, and then a bunch of
| stuff makes random dotfiles/dotdirs in the home directory,
| and then .profiles/shellrcs/xinits that are basically
| required. _Every single program_ seems to think you want a
| scrollback history, a configuration directory, or some random
| garbage to remind of you of that one time used it.
| samatman wrote:
| Complying with the XDG standard seems about as good as a
| stringly typed OS like Unix can get.
|
| Part of which is making sure that the defaults the program
| chooses may be overridden by consistent environment
| variables.
|
| Programs need some way to persist their own state and
| configuration, after all.
|
| The fact that XDG is more honored in the breach is
| tiresome, but this can at least be corrected, and it's well
| enough put together to be a steady-state approach to
| wrangling dotfiles.
| nmz wrote:
| Windows fixed this by just having %APPDATA%, and to me, its
| a great idea. No .config, no .local, no .share, no
| .randomfile, each installed program has its directory in
| hidden directory, and nobody has to know what each
| directory is for, and sure, this is what ~/.config is for
| some, but I also see there's some stuff in ~/.local/share
| and so on.
|
| To expand on this, when a program gets installed, it should
| write its binary location in a file, then if you ever erase
| it, a doesthisexistanymore $Config/dir/*/symlink |
| remove_entire_configuration_directory should be run via
| cron daily.
|
| No manual cleanup, ever.
| kodah wrote:
| Slight correction here, XDG keys are analogous to Windows
| standards:
| https://github.com/adrg/xdg/blob/master/README.md
| [deleted]
| jmclnx wrote:
| I agree, but the OpenBSD did some nice things in regards to
| ~/Downloads
|
| Using unveil() and pledge(), OpenBSD hides many $HOME and
| system directories from Firefox and chrome. Thus an errant
| javascript will only see things in ~/Downloads
|
| So one nice use for these.
| psanford wrote:
| That is annoying but easily fixed with xdg-user-dirs-update eg:
| xdg-user-dirs-update --set MUSIC ~/.xdg-user-dir/music
| UI_at_80x24 wrote:
| My annoyance is that they create any 'helpful' directories.
| It's just as bad on Windows. "Download", "Pictures", "3D
| crap", etc....
|
| Nope, fuck that.
|
| This is my $home, I'll make it look how I want.
| jl6 wrote:
| > This is my $home, I'll make it look how I want.
|
| I have long since accepted that it's not my $home after
| all, but rather a general purpose application config
| dumping ground. My actual "home" is now a top level
| directory used only by me.
| alexvoda wrote:
| You may indeed prefer an empty canvas you have full control
| over.
|
| However, creating these folders by default is actually
| beneficial to most users. Most users (especially the vast
| majority that transitioned from Windows) expect these
| folders to exist.
|
| I believe the choice to not create these existed and still
| exists. Yet either all the distros that made that choice
| are history or they all made the opposite choice.
|
| I can say the same about other choices. I vastly prefer
| having a TRRS headphone jack and expandable storage on a
| phone. These do not appear to be priorities for most
| people.
| adrusi wrote:
| The choice not to create these directories basically
| doesn't exist, because all sorts of software will
| automatically create them if they don't exist, their
| creation isn't centrally orchestrated. A while back I was
| using a minimal i3-based desktop and when I launched
| transmission-gtk it thought I might want a "Downloads"
| folder, and would create it whenever it launched, even
| though it had been configures to download files
| elsewhere.
| psanford wrote:
| That not really true. Most desktop environments will
| create the directories on session startup but depending
| on the DE that behavior can be disabled (in xfce for
| example has a service in the session you can disable).
|
| It is true that applications will create these
| directories if they don't exist. But you can fix this by
| setting the XDG user directories[0] to something that
| isn't in your home directory. I set them all to a
| subdirectory under `~/.xdg-user-dir/`, but you could just
| as easily set them to `/tmp`. Nothing has recreated
| ~/Documents on my system in years.
|
| [0]:
| https://wiki.archlinux.org/title/XDG_user_directories
| alexvoda wrote:
| I was not aware of that behaviour. I agree that should
| not happen. Or the user should be asked if they want
| that. This should very much be under the control of the
| system and the apps the user chooses to manage the
| system. In a capability-based OS, apps would not be able
| to misbehave like this, unless granted the capability.
| jrockway wrote:
| I had no idea. Excellent tip!
| [deleted]
| petepete wrote:
| I like to lowercase mine so bin and projects don't look weirdly
| out of place. Thankfully it's totally customisable.
|
| https://github.com/peteryates/dotfiles/blob/master/xdg/.conf...
| codedokode wrote:
| Adding . and .. was a mistake by itself. I never needed them, but
| always had to write conditions to skip them when traversing the
| file system.
|
| Also, dotfiles don't work well with masks because `*` doesn't
| match dot-files, and `.*` match all dotfiles including . and ..
| which causes many programs to fall into endless recursion (for
| example, `du -sh .*`).
|
| Everything related to dotfiles in Linux is done wrong.
| GekkePrutser wrote:
| Wildcards are entirely shell-dependent so blame the shell
| you're using, not Linux :)
| debugnik wrote:
| glob and fnmatch are C functions defined in POSIX though.
| Night_Thastus wrote:
| _That 's_ why some files like gitignore and clang-format start
| with a dot? Some old way of hiding the file?
|
| How bizarre. I had no idea it was actually related to the . and
| .. files.
| wizofaus wrote:
| The question is why anyone feels files like .gitignore should
| be hidden by default from ls output - there even seems to be
| disagreement between versions of git whether git itself ignores
| such files by default (using git add e.g.), though I don't
| believe it does, can't check currently.
| wizofaus wrote:
| Was finally able to check on one of my repos and git 2.34.1
| most definitely _does_ ignore . files by default (both git
| status and git add), unless you specify --ignore for git
| status or --force for git add. But my .gitignore (either for
| the clone or global core.excludesfile) doesn 't specify that
| . files should be ignored, so why is it doing so?
|
| I can't see how to do a git add to add all new files,
| including dot files, except those in .gitignore.
| deathanatos wrote:
| > _Some old way of hiding the file?_
|
| An old way, but also it's still the way to hide a file, on *nix
| systems.
|
| (Hence the "mistake", and the countless hours mentioned in TFA
| are still adding up, as people forget them when they shouldn't,
| or don't exclude them when they should...)
| trebbble wrote:
| Practically the only remotely common desktop or server OS
| where it's _not_ still a normal way to hide files, is
| Windows.
| em-bee wrote:
| that's because they are all based on unix. or is there any
| remotely common OS besides windows that is not based on
| unix?
|
| a few decades ago macOS, amiga and atari were rather
| common, which all don't follow that convention. i don't
| know about BeOS/haiku. but if that hides dot-files then
| it's because they ported a lot of unix tools for
| commandline use.
|
| i could not find anything about OS/2 but i suspect that it
| worked like windows.
| naniwaduni wrote:
| Windows is _very_ common.
| cafeinux wrote:
| Unfortunately
| trebbble wrote:
| I didn't mean to imply that Windows is uncommon, but that
| you have to get _pretty damn obscure_ to find another
| modern desktop or server OS that doesn 't do the dot-
| equals-hidden thing. Windows is the most common on the
| desktop, obviously, but if you step outside it you're
| _almost certainly_ in dot-is-hidden territory.
| naniwaduni wrote:
| Windows is still so _overwhelmingly_ common that it 's
| _very_ possible to _never_ have occasion to touch
| "another" desktop or server OS. Especially if you don't
| go out of your way to manage servers, and doubly so if
| you don't live in one of the rich economies.
| xdennis wrote:
| GP is saying "out of the many commonly used OSes, Windows
| is the only one which doesn't hide dot files", not that
| "Windows is an uncommon OS".
|
| But it all makes sense, Windows is CP/M based, not Unix
| based.
| shadowofneptune wrote:
| Windows NT was designed by former DEC employees. DEC had a
| rather low opinion of Unix and dotfiles definitely would
| have been one of the lazy hacks they disliked.
| esoterae wrote:
| alias ls='ls -a'
| dorfsmay wrote:
| alias ls='ls -A'
|
| There really is no need to show "." And "..".
|
| I tend to always start with: ls -lArt
| esoterae wrote:
| How interesting (: I find myself typing a lot of `ls -dl
| /a/b/d/*` these days.
|
| What a strange fingerprint I imagine all our collective
| accumulated behaviors project about our past experiences.
| mark-r wrote:
| It's not just ls though, the shell hides them too right? echo *
| won't show them.
| esoterae wrote:
| Well, I was being a little flippant dismissing it as largely
| a complaint about things not showing up in the terminal, but
| it's obviously deeper than that, yes.
|
| I think this overall situation is most acutely a lack of
| standard. Someone up in the nosebleed section rightly pointed
| out that there should be some environment variable for a
| config to be written to, and I agree. I also want to stress
| that there should be the inclusion of a single variable on
| top of that, that _all_ programs should use when constructing
| the path to their configuration. USER_CONFIG_DIR or something
| equally arguable should, if unset, default to $HOME, and if
| set, be used as the root to construct whatever structure
| therein is desired, also able to be changed with an
| environment variable specific to that program. Be it filename
| or further subdirectory, first using a single reference that
| is /not overloaded/, like HOME, but defaults to HOME if
| unset.
| wizofaus wrote:
| Very good point and arguably a bigger problem. Worth putting
| `shopt -s dotglob` in .bashrc to avoid. How about other
| shells?
| BrainVirus wrote:
| Most people seem to interpret this as "don't hide things".
|
| I interpret this as "file systems need to have a flexible
| metadata mechanism instead of ad-hoc hacks". Of course, at this
| point in time no such thing will happen, because it's easier to
| invent 100 new databases than change some assumptions about our
| core architecture.
| [deleted]
| akira2501 wrote:
| > "file systems need to have a flexible metadata mechanism
| instead of ad-hoc hacks"
|
| xattr's require a system call for each path you want to look
| up, and then another system call for each value you actually
| want to retrieve. Plus all the error handling that goes along
| with those calls. Oh, and they're all strings, so even more
| work if you want to have an integer attribute. Also, which
| quota should the space used by the attributes accrue to? Should
| we split that into "user" and "system" attributes? Whoops,
| looks like we need an "ad-hoc" namespace here too... this time
| with actual security implications!
|
| The mechanism exists, but it's more cumbersome than it's worth.
| That's certainly the way I've felt about it every time I have
| to muck around with a system that "mistakenly" decided to use
| them instead of just a database.
|
| In that light, the dot is not a historical mistake. It's an
| obvious optimization of a particularly popular use case.
| klabb3 wrote:
| > I interpret this as "file systems need to have a flexible
| metadata mechanism instead of ad-hoc hacks".
|
| Pike isn't even talking about that, only the typical config
| files in the home dir that clutter and affect performance of
| file name ops in the home dir.
|
| > (For those who object that dot files serve a purpose, I don't
| dispute that but counter that it's the files that serve the
| purpose, not the convention for their names. They could just as
| easily be in $HOME/cfg or $HOME/lib, which is what we did in
| Plan 9, which had no dot files. Lessons can be learned.)
|
| I have to agree. I can't think of any situation where hiding
| really helps. If the reason is clutter, the solution should be
| a dir.
| BrainVirus wrote:
| _> I can't think of any situation where hiding really helps._
|
| The irony of dot-files is that they became used for metadata,
| like .git directories, .htcasses files and so on. So, a
| solution that fakes metadata by abusing names is now used to
| indicate metadata at another level of the system. There is
| clearly something missing in file system design.
| klabb3 wrote:
| I agree, sometimes dot files are used for metadata. But say
| a typical code repo: lots of dirs (vendored deps, compiled
| libs, generated code) are in regular dirs but git uses a
| dot-dir. Is there a strong reason for this I'm not getting?
| You're not supposed to modify either of them, heck even
| listing can be a shit-show.
|
| I can see the use-case of "when zipping or sending a dir to
| a different machine, omit the metadata", but this doesn't
| hold true for code repos, and is sometimes even the
| opposite of what you want. It'd probably be better with dir
| name conventions like "cache", "secrets", "config" or
| similar.
| BrainVirus wrote:
| I think what you're pointing out is an example of a real
| problem. I'm not sure the problem has a name or is
| noticed by most people. But something is off. In some
| cases it might be that common conventions (like dotfiles)
| aren't really well-designed. But I think the more general
| issue is that the current set of abstractions
| (file/directory/symlink) are not sufficient to take good
| care of practical use cases we have for data these days,
| not matter how cleverly we use them.
|
| Should .git directory reside in the same directory as
| your source code? Maybe not. Fossil has an interesting
| compromise in that regard.
|
| Should compiled artefacts reside in the same directory as
| your source code? Almost certainly not. This seems like a
| bad idea from some hacky implementation decades ago.
|
| Should tools be able to distinguish between "real" files
| and metadata files? Almost certainly yes, except there
| are different types of "metadata" files, as you pointed
| out. I think naming conventions are simply not good
| enough to handle this properly. This is where FS metadata
| could come into play.
|
| Generally, I think if someone without prejudice examined
| the common problems we have with data these days and
| designed a "file" system from scratch, they would end up
| with something vastly different from our current
| files/folders paradigm.
| klabb3 wrote:
| > Should .git directory reside in the same directory as
| your source code? Maybe not.
|
| Indeed, many dependency managers (both go mod and cargo
| iirc) don't vendor deps into your working dir.
|
| > I think naming conventions are simply not good enough
| to handle this properly. This is where FS metadata could
| come into play.
|
| Yeah, the ideal solution may be just that, but I'm not
| 100% convinced that dirname conventions and tooling can't
| solve the major hurdles. New file systems would take
| decades even if they were to take on.. And for VCS and
| other tools you need to account for many different file
| systems and can't rely on anything but largest-common-
| denominator features..
| jl6 wrote:
| I guess one could mention xattrs but there isn't a lot of
| consensus on how they should be used.
| marcosdumay wrote:
| Or if they should be used at all. Distros still default into
| disabling them.
|
| What is quite interesting, because it's all a matter of user
| interface. It's a change that doesn't even impact on software
| compatibility. Any distro that decides that a file is hidden
| due to an attr can just push that change, and nothing will
| break.
| GekkePrutser wrote:
| Inventing new databases doesn't stop the old architecture from
| working, and everything that depends on it. Changing that
| architecture will. This is simply why.
| LukeShu wrote:
| The code in question: https://github.com/dspinellis/unix-history-
| repo/commit/389a4...
| pengaru wrote:
| Funny. People here are conjecturing why one open codes the
| comparison instead of calling strcmp() presuming it's C when
| `ls` was written in assembler where calling a C function like
| strcmp() is far more onerous (and slow) vs. comparing to an
| immediate (cmpb, bne).
| ghayes wrote:
| To be fair, it doesn't need to be strcmp since the target is
| known. It could simply check for a null terminator on the
| next byte or another dot followed by a null terminator.
| Surely a few more instructions, but not a complex subroutine
| call.
| draw_down wrote:
| I don't code in C too much but it seems like it would be
| pretty simple to check if the next index is a null byte.
| dsQTbR7Y5mRHnZv wrote:
| And the modern reimplementation:
| https://github.com/coreutils/coreutils/blob/c7920f2/src/ls.c...
| efxhoy wrote:
| No wonder we call it code. I can read most programs and get a
| hunch of what's going on. With assembly like this I'm
| completely blank.
| mikl wrote:
| I agree that it's annoying that so much junk accumulates in the
| root of your home dir.
|
| But any consumer-facing OS will need some sort of mechanism of
| hiding/protecting configuration files/logs/etc. from deletion by
| clueless users, like how macOS has started hiding ~/Library by
| default.
| int_19h wrote:
| The article points out that a better way to do this would be to
| designate one particular folder for configs, and then that
| alone could be hidden if desired. But we have what we have
| instead because a "convenient" hack was misappropriated.
| mikl wrote:
| Yes, but it also claims that hidden files in general were a
| mistake and mentions how Plan9 not having hidden files was
| learning from this mistake.
| bombcar wrote:
| Config files are only one subset of possible dotfiles (a
| common one to be fair).
| coldtea wrote:
| > _How many bugs and wasted CPU cycles and instances of human
| frustration (not to mention bad design) have resulted from that
| one small shortcut about 40 years ago?_
|
| Not many? In the sense that, considering several UNIX and C
| design issues and footguns, the dotfiles are the least of our
| worries (compare e.g. to C buffer overflows or shell escaping
| rules, to name but two)...
|
| I also don't particularly like the repeated ditches at "lazy
| programmers" - isn't the whole "New Jersey" style [1] heavy on
| laziness?
|
| In fact, if those "lazy programmers" were given OS level-APIs and
| libs doing the right thing about dotfiles, they wouldn't have
| recoded them on their own in their programs...
|
| [1]
| https://en.wikipedia.org/wiki/Worse_is_better#New_Jersey_sty...
| ParetoOptimal wrote:
| Not a fan of worse is better.
|
| I have some rough thoughts on expressing why:
|
| > This leads one of the major cognitive biases in software
| development where people speak of tradeoffs without
| establishing they are Pareto Optimal, and wrongly arriving at
| the conclusion "nothing more can be done without a huge
| effort".
|
| https://www.paretooptimal.dev/pareto-optimality-and-software...
| coldtea wrote:
| > _Not a fan of worse is better._
|
| That's ironic given your handle on HN :)
|
| > _This leads one of the major cognitive biases in software
| development where people speak of tradeoffs without
| establishing they are Pareto Optimal, and wrongly arriving at
| the conclusion "nothing more can be done without a huge
| effort"._
|
| Well, part of the idea is to do the "pareto optimal" work not
| just implementation-wise, but also in checking whether the
| tradeoffs are pareto optimal (pareto-ception). Thus, avoid
| "analysis paralysis"
| jstanley wrote:
| > Here Bob has ignored Pareto Optimality for the context of
| phone security and convenience because he could enable
| automatic updates at no (well little) cost to convenience
|
| This is just not true. Software updates break things all the
| time. Having software updated behind your back is incredibly
| inconvenient.
| doctor_eval wrote:
| That link is awesome. Thanks.
| pantulis wrote:
| It's not my intention to second guess Ken, but at least in
| terms of performance I'd say that the current user home
| directory structure would bet a hit in the buffer cache since
| Unix got filesystem buffer caches.
|
| In terms of wasted CPU cycles, it's another story but hey these
| are the days of using npm packages to basically do a string
| comparison.
| croes wrote:
| >I'm pretty sure the concept of a hidden file was an unintended
| consequence. It was certainly a mistake.
|
| So it's just an assumption and so the title is misleading
| noncoml wrote:
| First of all, "A lot of other lazy programmers". That's cringe. I
| don't care who you are, that's not a way to talk.
|
| Secondly, I think we have all been there. We introduce a bug in
| an interface/API but then the users of it start depending on this
| behaviour and before you know it it's a feature and it's
| impossible to fix without breaking the world.
| googlryas wrote:
| Good point. Rob Pike has nothing interesting to add here. Just
| an old white dude making us cringe. It's like come on grandpa,
| its the 2020s, we've all been there.
| cmrdporcupine wrote:
| He's obviously a very smart guy and a pioneer and a much more
| accomplished person than me (or most of us), but Rob Pike seems
| to make a habit of arrogantly talking down about other people's
| intelligence or skill:
|
| Re: Go _"The key point here is our programmers are Googlers,
| they're not researchers. They're typically, fairly young, fresh
| out of school, probably learned Java, maybe learned C or C++,
| probably learned Python. They're not capable of understanding a
| brilliant language but we want to use them to build good
| software. So, the language that we give them has to be easy for
| them to understand and easy to adopt."_ -- Rob Pike
|
| I agree it's really a cringe way of approaching people. In this
| (dotfile) case there _may_ have been some self-deprecation in
| the comment though, so it 's frankly hard to get too miffed
| about it.
| shepherdjerred wrote:
| I think he very accurately described the problem Go is trying
| to solve which is how do you make new grads productive?
|
| In my experience at AWS people that graduated didn't
| understand the languages we used. This leads to a bunch of
| problems, and makes it's easy to write very bad,
| unmaintainable code. Lots of needless class hierarchies in
| Java, or a misunderstanding of `this` in JavaScript. Go
| solves the problem perfectly.
| cmrdporcupine wrote:
| Never had that experience at Google. New grads and interns
| always seemed sharp. Might just be the superior quality of
| education out of U of Waterloo, or the hiring bar at our
| site, or both. I enjoyed working with them.
|
| With new grads, I generally didn't have to teach coding
| knowledge. It was more about transmitting wisdom around
| best practices, estimation, architecture, etc.
|
| If anything, to me Go makes a lot of things harder that
| could be simpler. Lack of generics means boilerplate.
| Eschewing test frameworks means boilerplate. The structural
| typing stuff is exotic (but neat I guess) and not familiar
| to most new programmers. The actor / CSP type concurrency
| stuff is also exotic and not familiar to most new
| programmers. I don't see how it's a language for new
| programmers.
|
| It also seems very much like a rehash of the concepts they
| had in Limbo so I actually don't find it honest for him to
| be claiming it was designed for this purpose (to simplify
| programming). Instead it feels very much like they had a
| hammer in search of a nail, an itch they've been scratching
| since the Plan9 days. And that's fine. I just don't buy
| this pitch about its market niche and the stuff about the
| relative intelligence of programmers is gratuitous. I've
| seen some very smart new grads produce amazing Rust code
| for example.
| pwinnski wrote:
| Calling someone out (Rob Pike or not) for "A lot of other lazy
| programmers" is cringe. It's clear and accurate communication,
| and shouldn't need to be workshopped to avoid offending people
| determined to be offended.
| [deleted]
| jzelinskie wrote:
| Haha, the first comment is of me throwing shade on HN, oh geez.
| Now I'm curious to read the old HN thread that I thought was so
| disappointing: https://news.ycombinator.com/item?id=4331855
| [deleted]
| hbn wrote:
| That's an interesting history lesson! I always assumed hidden
| dotfiles was a conscious design decision.
| clysm wrote:
| It's not a history lesson. It's just baseless conjecture.
| unixbane wrote:
| this post is a good example of how un*x hippies with their fried
| brains from too much drugs* realize one unit of common sense
| after aeons of contemplation. just like with generics in go. in
| fact, go itself is just decades of C users very slowly conceding
| to the idea of basic hygiene. it took them decades to come up
| with something which is essentially just what was already
| available in the 90s (pascal, fortran, ada, basic, later java 1.2
| or so which also had green threads), but with stuff done a
| certain way so the boomers can be like "oh see, we did this minor
| syntactic change THIS way, checkmate, pascal"), in other words
| they want to have their say in everything
|
| * im not joking, this is what un*x culture appears to essentially
| boil down to. boomers were all hippies in the 70s despite
| presenting themselves as "austere" and "mature" "wise"
| individuals now, which had the unfortunate side effect of too
| much drugs. further research is needed to clarify whether brain
| damage is caused by drugs or un*x
|
| any encoding in file names at all is a mistake. this includes
| character encodings too, which may sound like a non-sequitur but
| its not. in fact, files should only have unique identities, not
| names. names should be metadata. folder hierarchy should just be
| a user defined data structure that can reference these said
| "files". anyone who tries developing their own OS without copying
| extremely idiosyncratic un*x ideas and without being bogged down
| by the overhead of assembly language or C quickly learns this. an
| example of youngins discovering this is IPFS (and subsequently
| implementing it on top of broken un*x)
| arboles wrote:
| lmao based
| qbasic_forever wrote:
| This is an AI generated comment, right?
|
| You didn't get a job at freaking AT&T Bell Labs by being a pot
| smoking hippie. They were the squarest of square professionals
| --suit, tie, the whole bit.
| unixbane wrote:
| no, it just doesn't fit into your two categories of posters
| here on HN
| hk1337 wrote:
| A happy little accident
| kgeist wrote:
| I don't understand how skipping an entry by comparing it with
| strcmp(name, ".") == 0 turned into name[0] == '.'
|
| Is it what really happened (lots of programmers, by mistake,
| wrote a comparison function which is just plain wrong), or Rob
| Pike is conjecturing?
| czx4f4bd wrote:
| Read that part again:
|
| > It was in assembler then, but the code in question was
| equivalent to something like this:
|
| > if (name[0] == '.') continue;
|
| > This statement was a little shorter than what it should have
| been, which is
|
| > if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0)
| continue;
|
| There's no strcmp() in the first example.
| vitiral wrote:
| For those who don't know, it should have been equivalent to:
|
| if (name[0] == '.') { if (name[1] == 0)
| continue; if (name[1] == '.' && name[2] == 0)
| continue; }
| [deleted]
| soegaard wrote:
| Pike says the code is in assembler - which means it is written
| by hand.
|
| In assembler `name[0]=='.'` is simple to write. Fetch what name
| points to and compare it to a literal `'.'`.
|
| A function call on the other hand requires pushing registers to
| the stack, pushing the arguments to the stack, call the
| function, and then restoring the registers.
|
| So if you are in a hurry and just want to try something, you
| will write the equivalent to `name[0]=='.'`.
| samatman wrote:
| It could have checked for ".\0" and "..\0", is the thing.
| There was no need to bring the whole of strcmp to bear.
|
| I think hiding files with a path convention is Good,
| Actually, but I'm comfortable being in the minority on that,
| and it's possible that if we instead had a hidden flag a la
| chmod permissions I would prefer that.
| Findecanor wrote:
| I think dotfiles is the best convention I've seen for
| hidden files.
|
| With "hidden" being a file attribute (like on MS-DOS),
| you'd have the risk of a filename collision with a file
| that you don't know is there.
| jerf wrote:
| Also, I mean, if you've grown up in the era of multicore
| gigahertz, where "gigabytes" is where our opening bid on RAM
| starts, you just don't understand what programming on this
| era of machine was like. The difference between a single
| name[0]=='.' and two calls to a string comparison function
| could very well have resulted in noticeable differences in
| performance, in real-world cases.
|
| I like to keep an eye on the costs of what code I'm writing
| to make sure I don't get too 21st century and let my codebase
| bloat until it's slow as molasses, but at the same time I
| happily harvest the benefits of usually not caring whether
| this function call is inlined or not, or caring about the
| exact number of cycles an indirect function call takes, etc.
| It's a delicate balance but worthwhile to cultivate it.
| slowhand09 wrote:
| ditto! Having coded on PDP-1170s and limited to 32K,
| fighting with link maps, planning common segments etc... We
| scratched for bytes.
| laurent123456 wrote:
| He seems to be saying it was a shortcut, so that the line
| excludes both "." and ".."
| Retr0id wrote:
| They weren't replacing `strcmp(name, ".")`, they were replacing
| `strcmp(name, ".") == 0 || strcmp(name, "..") == 0`.
|
| It's somewhat easy to see how someone would make this shortcut
| when programming in C, but they weren't programming in C, they
| were programming in assembly (as the article describes). It's
| so much simpler to only check the first char when programming
| in assembly, so it's easier to see why the shortcut might've
| been taken.
| alexvoda wrote:
| Exactly, the logic is that "...", "....", "..*", etc. do not
| exist and besides users should have the common sense to not
| name stuff like that. Therefore it is much easier to just use
| the easier to write (assembler) and much faster solution.
| wizofaus wrote:
| "Much" easier? It only needs 3 or 4 extra instructions to
| check for the null terminator at position 1 or 2 (0 based),
| which would be an improvement (only 1 or 2 letter filenames
| starting with dot would be hidden), and a couple of extra
| to check for dot at position 1. Given all the other things
| ls has to do, that's negligible.
| alexvoda wrote:
| Indeed, but I believe, that is not the mindset of a
| person programming in an extremely constrained
| environment. Care for correctness is younger than "ls".
|
| For all intents and purposes at the time, it was a hack
| but it worked, and it worked well.
| GekkePrutser wrote:
| Care for correctness was much more of a thing, when
| coding was a rare art and not a copy/paste from stack
| overflow to finish this week's sprint on time.
|
| There was also a lot less code in general so I would
| expect every line to be considered in much more detail.
| Also, 'laziness' tends to be a character flaw that
| manifests itself everywhere in a person's work, not just
| in one place. And Richie/Kernighan don't exactly have a
| bad reputation.
|
| I wonder if the '-a' parameter of ls appeared at the same
| time. If so it definitely wasn't an oversight.
| wizofaus wrote:
| Are we sure there weren't other rules or conventions in
| place at the time that specified filenames had to start
| with an alphanumeric character?
| wizofaus wrote:
| I cut my teeth writing 8086 assembly code where keeping
| machine code size down to as few bytes as possible was
| necessary and that still strikes me as very lazy hack -
| saving a few bytes at the cost of an infinite number of
| possible filenames being hidden vs just two?
| jph wrote:
| One way to make your config files more visible:
| mv "$HOME/.config" "$HOME/config" ln -sfn "$HOME/config"
| "$HOME/.config"
|
| If you want to move and link files that you want to make visible:
| mv "$HOME/.foo" "$HOME/config/foo" ln -sfn
| "$HOME/config/foo" "$HOME/.foo"
|
| If you want, you can set a custom location in your system file
| `/etc/profile` or your user file `~/.profile`, or `~/.bashrc` or
| `~/.zshenv` etc. export
| XDG_CONFIG_HOME="$HOME/config"
|
| Helpful links for XDG:
|
| https://specifications.freedesktop.org/basedir-spec/basedir-...
|
| https://wiki.archlinux.org/title/XDG_user_directories
| andrewla wrote:
| I have a directory under ~/config, ~/config/dotfiles, that just
| has files that are intended to be dot-prefixed and linked in
| the home directory. That avoids any accidental over-linking; I
| can just run a script that links ~/config/dotfiles/$X to ~/.$X
| and I'm done.
| bmurphy1976 wrote:
| Why move the folder? Why not just symlink config to .config?
| There's almost certainly some poorly written tools out there
| that will blow up on the symlink. Why take that risk?
| cafeinux wrote:
| From a purely esthetic point of view, if you're using a
| graphical file manager, the symbolic link might be denoted by
| an ugly icon. Surely there's a solution to that, but that's
| the only reason I could find.
| jph wrote:
| You're correct, moving the folder can expose a poorly written
| tool, meaning a tool that isn't following the symlink and
| isn't using XDG_CONFIG_HOME.
|
| To me, it's an advantage to surface the latent problems, so I
| can message the authors to ask them about updating. So far,
| all authors are good with updating.
|
| It turns out the bulk of the issues are in internal scripts
| that hardcoded ~/.config instead of using XDG_CONFIG_HOME.
| This is an easy fix, and at the same time we shellcheck those
| scripts.
| kazinator wrote:
| This is reminiscent of John MacCarthy pooping on NIL.
|
| "The unexpected appearance of an interpreter tended to freeze the
| form of the language, and some of the decisions made rather
| lightheartedly for the ``Recursive functions ...'' paper later
| proved unfortunate. These included the COND notation for
| conditional expressions which leads to an unnecessary depth of
| parentheses, and the use of the number zero to denote the empty
| list NIL and the truth value false. Besides encouraging
| pornographic programming, giving a special interpretation to the
| address 0 has caused difficulties in all subsequent
| implementations. " (History of Lisp, 1979)
| gryn wrote:
| the explanation for pornographic programming are very
| interesting:
|
| https://stackoverflow.com/questions/8547142/what-did-john-mc...
|
| > 0==() has been the emoticon for pornography since 1958.
|
| > The fact that too many implementation details were leaking at
| a higher level, i.e. showing up too much
|
| > Code that uses intimate knowledge.
| lofatdairy wrote:
| >I was wondering why this post had so many comments. Then I found
| out it was posted on proggit/HN. The discussions there were
| hardly interesting, however.
|
| For the curious (was a bit annoying to find since gplus is down
| now and all links redirect to a different subdomain):
|
| https://news.ycombinator.com/item?id=4331855
| jxy wrote:
| The second comment there has its merit in UNIX. However, it is
| moot with namespace in Plan 9. You can have different versions of
| the same directory structure, per process.
| heikkilevanto wrote:
| Dotfiles are useful, not only in the $HOME directory, but in
| every project that has a .git directory, and many other ways.
| Maybe it was a design accident, but it has got stuck, and many
| old greybeards like me are used to it, and find good use of it.
| kazinator wrote:
| > _I 'm pretty sure the concept of a hidden file was an
| unintended consequence. It was certainly a mistake._
|
| That is highly implausible, except as a case of extremely
| distracted coding.
|
| Someone like Thompson or Ritchie wouldn't consciously write a
| test for just the leading dot without being fully aware that it
| matches more than . and .. .
|
| Even if the thought had been "nobody in their right mind will
| have files starting with dot, so who cares", that would still
| make it a deliberate requirement being consciously implemented
| and not a mistake.
|
| By distracted coding I mean that situations like this happen: you
| intend to write a piece of code which does something specific.
| The code is motivated by certain happy cases. You start coding it
| and get it into a state in which it runs but doesn't quite do
| what was intended. Then you get completely distracted by some
| interruption. You forget that the code hadn't been completed; you
| mistake the remembered intent for the completion. You run the
| code and it carries out the intent on the motivating happy cases,
| and somehow fool yourself into believing it was done.
|
| Maybe Pike meant that it was a mistake to create that
| requirement.
|
| I don't hate the $HOME/cfg directory idea, but please call it
| $HOME/.cfg so I don't have to see it. :)
| transfire wrote:
| 100%
|
| I'm on the verge of abandoning the home directory. I'll put My
| files elsewhere and leave home to the apps.
|
| I thought XDG would surely solve this problem but it's painfully
| clear now that most developers just don't care. `node_modules`
| and `snap` are good cases in point. They didn't even bother
| hiding them! LOL
| im3w1l wrote:
| A long time ago I liked listening to original soundtracks for
| games. Winamp had a plugin that would play .psf (et al) files.
| There were files that contained the extracted code from games for
| playing the music. The plugin had a tiny builtin emulator that
| could run the relevant parts. No graphics or input I suppose.
|
| One soundtrack I really liked was .hack, including the leading
| dot. Given that "hack" part and the overall theme of the games I
| assume the initial dot was quite intended. But what the creators
| could not have foreseen was that their soundtrack was missing
| from the majority of psf mirrors (but some had it obviously). I
| guess some part of some stack ignored dot-prefixed files when
| doing the mirroring.
|
| Anyway, although I'm usually opposed to inband signalling, I am a
| fan of dot-prefix for hiding. Filenames already have so many
| special corner cases that you would have to treat them very
| carefully even without this one. The fact that it is embedded in
| the name means that any system can roundtrip hiddenness -
| something that cannot be said for metadata.
| andrewla wrote:
| I am increasingly exasperated by apps that do not follow the XDG
| specification for config at this point. Having a ton of dotfiles
| sitting in the root of the home directory is just a maintenance
| nightmare on every level.
|
| I've gone so far as to keep my config directory visible --
| ~/.config is a symlink to ~/config, which actually holds all my
| config, conveniently a git repository in itself for easy
| portability and tracking.
| layer8 wrote:
| I always (since long before XDG became a thing) used ~/etc, in
| analogy to /etc. Also ~/bin, ~/var, and ~/tmp.
| user3939382 wrote:
| If I ever find time to play with hacking the kernel my first
| project is to create an extension that automatically redirects
| all file system lookups for ~/.* to ~/.config/*
|
| I'll even forgo having my own hidden files there, I don't care.
| It's so annoying.
| the_gipsy wrote:
| Don't forget to add the `.config` exception!
| layer8 wrote:
| How about glob symlinks as a filesystem feature? :)
| ln -sg '~/config/*' '~/.*'
| Kaze404 wrote:
| I stopped caring about this by having home-manager do all this
| for me. I don't really care where the files are anymore because
| I change them through Nix, not directly, and I can choose where
| that is located.
| amarshall wrote:
| Further, using a tmpfs for root (and by extension ~), means
| that junk doesn't accumulate (while Home Manager ensures what
| should be there, is there).
| colordrops wrote:
| You should consider Nix home-manager. It keeps config all in
| one place and explicit.
| DoneWithAllThat wrote:
| > Unfortunately, it is quite possible to get difficult to
| understand errors when working with Home Manager, such as
| infinite loops with no clear source reference. You should
| therefore be comfortable using the Nix language and the
| various tools in the Nix ecosystem. Reading through the Nix
| Pills document is a good way to familiarize yourself with
| them.
|
| Thanks, but I'll just deal with a bunch of dotfiles. This
| sounds an awful lot like a "and now you have two problems"
| situation.
| willmorrison wrote:
| Home Manager really doesn't lead to many problems, and if
| you encounter any the NixOS community is wonderful. You can
| set up everything without understanding much of the Nix
| language by looking at other people's configs on GitHub.
| colordrops wrote:
| Whatever works for you, but it's not really a fair
| characterization. It adds one problem and solves another
| dozen, at least in my case. And I don't really run into
| these difficult to diagnose issues too often.
|
| It's like driving a car instead of walking is trading one
| problem for two.
|
| I'm to blame actually, it does a lot more than config
| management, so I mischaracterized it myself.
| ben0x539 wrote:
| The new problem is pretty fun though!
| bjourne wrote:
| I've been filing a few bug reports on software that puts its
| config in dotfiles in ~/. Hopefully we can reach critical mass
| sooner or later. Because the more projects that follow XDG the
| more pressure on the projects that have not migrated yet. It
| makes the Linux desktop better for everyone.
| qbasic_forever wrote:
| Stow is a tool designed to support exactly the workflow you
| describe: https://www.gnu.org/software/stow/
| spinningarrow wrote:
| Been using stow for my dotfiles for many years now and I'm
| really happy with the workflow:
| https://github.com/spinningarrow/.files
| m-n wrote:
| > I've gone so far as to keep my config directory visible --
| ~/.config is a symlink to ~/config, which actually holds all my
| config, conveniently a git repository in itself for easy
| portability and tracking.
|
| Sometimes I wonder how much defaulting to a directory with a
| leading dot hurt adoption. It gave me the impression that it
| was designed for or by people who don't manually edit their
| config files.
| bayindirh wrote:
| It's not defaulting to a directory, but to a variable:
| "$XDG_CONFIG_HOME".
|
| Also, if you know how to change config of an application for
| the last 15-16 years, you also know that you're going to edit
| a "dot file".
|
| KDE stored everything under ".kde" for a long long time, and
| stored a great tree under it too. rc files as config files
| and other KDE related files as app specific files.
|
| In fact, the ".config" folder is just an evolution of ".kde"
| folder. Spec is written by KDE guys.
| m-n wrote:
| > It's not defaulting to a directory, but to a variable:
| "$XDG_CONFIG_HOME".
|
| By default I'm referring to the following part of the spec
| and the fact that systems I've used start in this state:
|
| > If $XDG_CONFIG_HOME is either not set or empty, a default
| equal to $HOME/.config should be used.
| bayindirh wrote:
| The XDG specification is fairly young. It's a bit younger than
| a decade. So, I don't expect older packages to update to it.
|
| Also, some applications use their older files if they find it,
| and re-create under XDG spec when they fail to find that file.
| KDE did that to great extent and success, for example.
| swyx wrote:
| info on XDG: [the XDG
| spec](https://standards.freedesktop.org/basedir-spec/basedir-
| spec-...)
|
| tools that respect XDG, for fellow JS CLI developers:
|
| - https://github.com/davidtheclark/cosmiconfig Find and load
| configuration from a package.json property, rc file, or
| CommonJS module. [Check `searchPaths` to implement XDG spec com
| pliance.](https://github.com/davidtheclark/cosmiconfig/issues/1
| 52)
|
| - Sindre's libraries use [`env-
| paths`](https://github.com/sindresorhus/env-paths#pathsconfig)
| to get paths compliant with this.
|
| - https://github.com/sindresorhus/conf simple config storing
| (maybe try [conf-cli](https://github.com/natzcam/conf-cli) to
| manipulate if needed) the successor to
| [configstore](https://github.com/sindresorhus/conf#how-is-this-
| different-f...)
|
| - https://github.com/jonschlinkert/data-store conf like
| datastore but in the shclinkerverse
| qudat wrote:
| I do something similar, managing dotfiles is pretty easy with a
| git repo
| luma wrote:
| It really is a mess and it would be helpful if we had some sort
| of database for configuration that was reasonably standardized.
| Some sort of "registry" if you will :D
| chasil wrote:
| ...but preferably using the SQLite engine, and eschewing
| well-known proprietary formats.
|
| https://news.ycombinator.com/item?id=32275078
| fezfight wrote:
| Better yet, a flat file structure that you can grep with
| standard utilities. We can put it somewhere convenient,
| like in dot files in the users home directory. We can even
| add them to git with something simple like git add *.*
| NavinF wrote:
| Yes! Let's also make every config file is its own special
| snowflake with its own syntax, keywords, and escape
| characters. That way, it's much harder for software to
| interact with these files and humans will have to write
| config templates for each deployment.
|
| Oh and we might as well store these config file in a
| different place on each distro and move them around once
| in a while just to keep things interesting. Users can
| ignore upstream documentation and just strace the process
| if they wanna know where the files are this year.
| fezfight wrote:
| Snowflakes are beautiful.
| codedokode wrote:
| You are suggesting good ideas, but we should go further.
| Let us write configuration files in Turing-complete
| exotic programming languages that almost nobody knows!
| This way malicious programs won't be able to parse them
| or perform automated edits, and many malicious humans
| too.
| hsbauauvhabzb wrote:
| No need to get passive aggressive, parent has a
| legitimate point. Grep is a huge part of my workflow.
| NavinF wrote:
| Ah I left out a few sentences. My passive aggressiveness
| is directed at the state of Linux distros today, not at
| the parent. I agree that his scheme is a lot better than
| the mess we deal with today.
|
| > Grep is a huge part of my workflow.
|
| You can flatten and grep structured binary formats too.
| chasil wrote:
| As tempting as that may be, the ability to enforce ANSI
| SQL constraints (not null, unique, check, foreign key,
| etc.) could prevent many types of configuration errors.
|
| If you want to grep everything in a sqlite database, then
| ".dump" it. $ echo "create table
| myconfig(param text, value text); insert into
| myconfig values('scrollbar', 'wide'); insert into
| myconfig values('verbose', 'no');" | sqlite3 myconfig.db
| $ sqlite3 myconfig.db '.dump myconfig' | grep verbose
| INSERT INTO "myconfig" VALUES('verbose','no');
| fezfight wrote:
| Good tips, thanks! I love sqlite3.
| codedokode wrote:
| Why add just a monstrous database engine that will spend
| time reading and parsing database schema, parsing SQL
| queries, building execution plans to read several settings?
| Let's go further and use Elasticsearch (startup time about
| 1 minute) for this.
| NavinF wrote:
| SQLite has identical performance vs parsing ad hoc text
| files assuming you're reading from flash not RAM. It's
| also a lot faster if you're loading a few settings from a
| larger file.
| dainiusse wrote:
| IBM AIX has "sort of registry". There are some good things in
| AIX, but querying configurations is ugly as hell
| grumple wrote:
| But it's really nice just being able to alter a regular text
| file for settings for whatever application you're dealing
| with.
| overlisted wrote:
| GNOME has dconf[1], but it's only usable through D-Bus, which
| probably annoys the anti-systemd people
|
| [1] https://en.wikipedia.org/wiki/Dconf
| MichaelCollins wrote:
| It probably annoys most people who are accustomed to using
| their preferred text editor to configure their software,
| and it probably also annoys all the other users who are
| accustomed to using typical GUI preference windows accessed
| through the menus to change their configuration.
|
| Things like dconf and about:config exists in no man's land,
| where neither generic GUI skills nor generic unixy skills
| are applicable.
| forgotpwd16 wrote:
| >and it probably also annoys all the other users who are
| accustomed to using typical GUI preference windows
| accessed through the menus to change their configuration
|
| How is this a problem with dconf? GNOME Settings for
| example is typical GUI preferences and works as a front-
| end to the dconf database.
| MichaelCollins wrote:
| Last time I tried to use it, "GNOME Settings" (or
| whatever it was calling then) was woefully incomplete and
| I had to figure out that dconf-editor existed (which
| wasn't in the menus.)
|
| Same problem with Firefox; hamburger->settings will take
| you to a GUI that contains maybe 0.01% of all the
| settings Firefox actually has. You have to be "in the
| know" to know that about:config exists. I think the first
| time most firefox users find out about about:config is
| when they're angrily searching the web for a solution to
| their problems, which is basically how I discovered
| dconf-editor too. You don't find either of these by
| searching through the GUIs like a normal computer user,
| nor will you find them by poking around in your dotfiles
| like a seasoned console jockey.
| sillystuff wrote:
| And, once you have more than a trivial number of changes
| in about:config, you search for something that will allow
| you to have sane configuration management, and discover,
| the 'user.js' file.
|
| Any setting in about:config can be set in user.js and
| your user.js file can be diffed, grepped, version
| controlled, edited with your favorite editor, and copied
| between profiles/machines.
|
| Sadly, Mozilla is moving a lot of config out of
| about:config/user.js and into multiple random sqlite
| files, so sane config management is getting harder with
| each new release.
| enduser wrote:
| It's not exactly a feature to have several layers of
| abstraction, when a text editor could suffice.
| overlisted wrote:
| Unix will never to achieve true user-friendliness and
| wide adoption if we treat settings like this. The reality
| is that most people _need_ a graphical, hard to break way
| of changing their settings to use your software.
|
| Edit: Although I agree that some situations may require a
| readable text format, like a dotfiles repo. I personally
| use the `dconf-editor` program to find the right keys and
| the `dconf load` command to sync them from a regedit-like
| file format
| likeclockwork wrote:
| Plenty of users find editing configs in a text editor
| very friendly. Changing away from that would be LESS
| friendly to those users. Which users are most important
| to be friendly to?
| stormking wrote:
| The problem here are UI designers who adore Apple but
| cannot afford a Macbook. So they target the Linux
| desktop.
| kevin_thibedeau wrote:
| I find text configs very friendly up until the point that
| a package manager blows away my changes. This system
| harks from an era before fully automated software updates
| when a full time employed sysadmin was expected to
| manually oversee every single update. It's far easier to
| automate incremental changes to a binary database than to
| non-destructively modify a free form text file.
| umanwizard wrote:
| > Unix will never to achieve true user-friendliness and
| wide adoption if we treat settings like this.
|
| I don't care. They can use OSes designed for their needs,
| like macOS and Windows.
|
| Not sure why there is such a persistent idea that
| "everyone using Linux, including entirely non-technical
| users who just want an appliance" is actually a desirable
| or realistic goal.
| GekkePrutser wrote:
| Agreed.
|
| And the funny thing is that everyone does use Unix.
| Everyone with a smartphone does as both iOS and Android
| are derivatives of Unix-OSes (Darwin and Linux). Only
| Fuchsia will be truly non Unix. If it ever makes it out
| the door.
|
| However those mobile OSes (or ChromeOS) are of course not
| what we're talking about when we say we love Unix. The
| same will happen if Linux ever makes it mainstream.
| Consumers might love it but we won't. I'm happy for it to
| stay a niche thing. My niche.
| pessimizer wrote:
| > Unix will never to achieve true user-friendliness and
| wide adoption if we treat settings like this.
|
| You're responding to complaints that settings done this
| way are user-hostile, opaque, and require a ton of
| insider knowledge to even find. So if the only goal is
| user-friendliness, we're moving away from it, not towards
| it.
| jrockway wrote:
| It might not actually matter. Reboot Windows. Sound
| starts playing out of your monitor, which you didn't even
| know had speakers. How do you fix it?
|
| (The answer is not to type "sound" into the search bar.
| That takes you to the "new" sound control panel, which
| doesn't have all the old features, including disabling
| sound devices. So you have to open the control panel, go
| to Devices & Sound, and then you can search around to
| disable a device.)
|
| The fundamental difference between Windows and Linux here
| is that if you write an instructional blog post to fix
| this problem for Windows, you can put some drive-by
| malware installer on it and make some money. You could
| obviously malware up similar Linux documentation, but by
| the time you get discovered you will have only infected 1
| person, simply because it's much less widely used.
| Unfortunate!
| Quekid5 wrote:
| That text file and your editor is two layers of
| abstraction (at least, because there's parsing involved,
| e.g. how to i specify timouts? sizes? Can I use "MiB",
| "s", "ms", etc?).
|
| The thing we want to optimize for is "how easy is to
| change a setting". Firefox's "about:" seems like a
| reasonable approach for expert users.
| nequo wrote:
| But the abstraction that is the text editor is shared
| across many programs. You can use your favorite text
| editor to edit any of the plain-text configs that you
| need. Firefox's about: and the way to edit it are
| specific to Firefox.
| pessimizer wrote:
| > how to i specify timouts? sizes? Can I use "MiB", "s",
| "ms", etc?
|
| These issues neither disappear nor improve when you hide
| the settings in a mystery binary.
| Quekid5 wrote:
| I agree, which is why I mentioned the "about:" thing.
|
| It would be nice to have a base level of types that all
| programs could agree on.
| amarshall wrote:
| Almost all of the things that get written to dconf
| settings are in some typical GUI preference window in
| whatever application. Firefox's about:config can be
| somewhat controlled through a user.js file.
| badrabbit wrote:
| Neat idea with the git part.
| kazinator wrote:
| "Having a ton of sheep rounded up in one enclosure is a herding
| nightmare; why can't they be scattered among the numerous
| meadows, ravines and gulleys that grace these mountains?"
| Gordonjcp wrote:
| The latter is exactly how you keep sheep. Keeping them in one
| enclosure is more of a pain in the arse to cope with than
| having to spend half a day tromping around with a couple of
| dogs herding them back into an enclosure, and then sorting
| out which sheep belongs to who.
|
| I'm not quite sure why this is a good analogy, but it feels
| like it is.
| [deleted]
| carlhjerpe wrote:
| What a genius idea, I'm gonna write a shell function to
| "permanently unhide" everything in a directory, I love *nix
| anamexis wrote:
| That "function" for me is just `alias ls='ls -a'`
| carlhjerpe wrote:
| Not the same, though there are more tools than ls that use
| directories.
| jart wrote:
| I'm exasperated by apps that hide their configuration files
| deep within my home directory and I have to use strace to
| figure out where they are. XDG is mostly useful for people who
| use unix desktops. It's sort of like a compromise between
| dotfiles and regedit.exe. Because desktops are huge and
| complex. If you ask your package manager to install one desktop
| thing, it installs a hundred things. Non desktop UNIX
| environments don't have that problem. So I don't think CLI
| programs like htop shouldn't follow XDG. It's non-standard and
| not the right tool.
| chimprich wrote:
| > So I don't think CLI programs like htop shouldn't follow
| XDG.
|
| I'm confused by your double negative. It looks like you're
| saying CLI tools should follow XDG, but the tone of your post
| sounds like the opposite.
|
| If the latter, what are you, some of kind of monster? :) If
| you don't want a specific XDG config dir, set it to ~. Don't
| force us all to follow some antiquated convention from days
| of yore.
| yjftsjthsd-h wrote:
| > I'm exasperated by apps that hide their configuration files
| deep within my home directory and I have to use strace to
| figure out where they are.
|
| That does sound annoying; if only every application would
| just use ~/.config/appname then your problem would be solved.
| [deleted]
| winstonewert wrote:
| > when the file system became hierarchical (it had a very
| different structure early on).
|
| This leaves me to wonder, what was the structure early on?
| aap_ wrote:
| It was a general graph. Any directory entry could link to any
| inode. Standardize ., .. and forbid links to directories other
| than those and from the directory they're in and you get the
| classic UNIX file tree.
| cryptonector wrote:
| IIRC before that Unix had directories, but it wasn't a rooted
| DAG. I don't recall the specifics, but I suspect you had to
| know a directory's inode to get to it if you couldn't reach it
| from where you were.
| xdennis wrote:
| Multics, the predecessor to Unix, was the first OS to use a
| hierarchical file system. Before that, file systems were
| typically flat: a single long list of files.
|
| I don't know how the original Unix was, but presumably flat.
| smm11 wrote:
| However Apple does it is best.
| danieldevries wrote:
| To some degree this is solved when using stow and a dedicated
| ~/dotfiles directory. No need to dig around in ~/.config
|
| But I agree with Pike. ls -a in the home sir, becomes an
| unorganized mess with all those apps that don't use the xdg
| default .config folder.
| PeterWhittaker wrote:
| Pike may be right that it was a coding error (but cf comments
| elsewhere re the unlikelihood that Ritchie, e.g., wouldn't have
| thought of those other cases), but I think he's wrong about it
| being a mistake.
|
| I love dotfiles. When I list a folder, I don't want to see all
| the cruft, I want to see the key stuff. Sometimes when I
| organizing something new, I use .directoryName to hide things
| temporarily.
|
| git is one of my favourite examples: .git hides stuff I do NOT
| need to see every day, leaving behind the things I am actually
| working on, the things I care about.
|
| Besides, it is so easy, once one has CLIed a while, to find (no
| pun intended) and/or account for dot files when you need to.
| llanowarelves wrote:
| If that wasn't already the behavior, people might do things
| like prefix with "_" or "__" to sort all the cruft to the top.
| "__git".
| ablob wrote:
| I still think it is a mistake which you may be repeating by
| conflating two concepts: - The location of a file - Standard
| visibility of the file
|
| If you hide something (like a folder) temporarily and refer to
| it through a script, you have to go to the script and change it
| once you decide that you don't want the folder hidden anymore.
| The script is now coupled to not only the location of the
| resource, but also its visibility.
|
| There is no reason to conflate the two concepts. Git folders
| can still be hidden by default without requiring adaptation to
| path names.
|
| I'd argue, what you're loving about dotfiles is not the
| presence of the dot, but the concept of visibility levels on
| files.
| PeterWhittaker wrote:
| I understand what you mean, and would argue that the . prefix
| is a simple - and widely accepted - way of achieving this, as
| someone noted elsewhere, convention over configuration.
|
| The only way to get truly hidden folders is to agree on an
| approach and have it adopted everywhere. Someone's git-aware
| GUI app might know to hide git, but as a CLI guy, should I
| have ls modified? Or find? Or my shell (if so, which one)?
|
| The . prefix hides things most users don't need to see (. and
| ..) and allows many other things to be usefully hidden in a
| convenient and consistent manner.
|
| To rephrase my original comment and integrate the crux of
| yours, Pike is wrong to call this a mistake, because it
| accidentally gave us a really useful capability that has been
| widely integrated into most/all of our tools, while allowing
| us to work around it simply and effectively when we want or
| need to.
| em-bee wrote:
| for an alternative that would not have been to hard to
| implement they could have used the permission bits for
| hidden files. it would take another bit, but i think there
| were some spare.
| sophacles wrote:
| Abusing permission bits would be the same form of problem
| as abusing names, however permissions are part of a
| larger bitfield `st_mode` that contains other useful info
| like file type (e.g. symlink, fifo, etc), which would
| make sense to extend to include "visible" or whatnot.
|
| Sorry, not trying to knock your idea, just had to let my
| inner pedant out a bit.
| Evidlo wrote:
| Then you have problems with file system portability like
| you get with permissions.
| vrnvu wrote:
| I got me a copy of The Unix Programming Environment (1984) by
| Pike and Kernighan last year. It has plenty of hidden small
| design gems or anecdotes like this one. For example, why files
| don't need a \EOF char, it's implicit when you don't read more
| bytes the you have reached the end of a file...
|
| Unix design was about making things work (1) and simple (2).
| chasil wrote:
| This book is online for free (three cheers for exotic spelling
| at archive.org).
|
| http://files.catwell.info/misc/mirror/the-unix-programming-e...
|
| https://archive.org/details/UnixProgrammingEnviornment
| cma wrote:
| I wonder if \EOF was around due to punch cards? You maybe
| didn't want an implicit EOF in case you lost the last card.
| int_19h wrote:
| EOF was around because many early file systems only recorded
| the number of allocated blocks per file, so some other
| mechanism was needed to record the precise length in bytes in
| cases where padding with spaces was not acceptable.
| bombcar wrote:
| Exactly - think about a tape with multiple files on it -
| you want some way of knowing you reached the end of a file
| without having to seek all the way back to some directory.
| csydas wrote:
| Maybe a dumb question but why do so many apps rely on dotfiles
| when /etc exists? I'm not making a judgement, this is an earnest
| question as even though it's meant for system config files, is
| there any reason that all app configurations shouldn't live
| there?
|
| If not in /etc, then at least /usr/etc? I'm sure there is some
| historical reason but some brief searching and I've not really
| come up with why dotfiles everywhere are preferable to a
| centralized configuration directory.
| dooglius wrote:
| Multi-user systems, where things outside $HOME are not
| editable, and where different users may have different
| configurations.
| ews wrote:
| I assume that because on true multi-user systems, syncing
| permissions between $HOME and /usr/etc/$USER may be a complete
| disaster.
| nmz wrote:
| Back ups would require you to know which paths are actually
| yours and where, chrooting would be problematic.
| CleverLikeAnOx wrote:
| Dotfiles are a per user application config. Other users of the
| same system are unlikely to want my idiosyncratic zsh setup.
| Hence the suggestion for $HOME/cfg in the article.
| PeterWhittaker wrote:
| Apps can rely on both /etc (for system defaults) and on
| ~/.something (for per user defaults).
|
| If we used only /etc, then we would need per user entries
| there, which would be far more difficult, esp. with network-
| mounted home folders, especially when those are automounted.
| nmz wrote:
| It would be simple with union mounts.
| PeterWhittaker wrote:
| It would be simple now. It took quite a while to get them
| right. My first thought was namespaces, but they are even
| more recent.
|
| The ~/.* convention worked a long time ago, far before
| either union mounts or namespaces were reliable.
| nmz wrote:
| Not that recent considering that's how plan9 works and
| plan9 is from the 90's. 1992[0] to be exact (apparently).
|
| [0]: https://plan9.io/sys/doc/names.html
___________________________________________________________________
(page generated 2022-08-11 23:00 UTC)