Ok, hi! My name is Boxxy...
Very glad I'm not the only one who thought of this :)
Show HN: boxxy – Control where Linux programs put files, without symlinks
191–200 of 250 posts
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#192This is pretty cool! It's surprising to see the project be at version 0.2.5 when the first commit was _yesterday_ though. What's the reason behind cutting this many releases?
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#193Earlier quoted context omitted.
> some have hardcoded those paths in other scripts My sympathy is lacking, as is my respect for those running projects that hardcode paths. Stop hardcoding paths and the world will be a better place.
eg. ~./bashrc has existed there for 30+ years, changing stuff just because someone doesn't like seeing a file in a folder is imho stupid.
Home is where the .bashrc is <3
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#194Earlier quoted context omitted.
HN is predominately older millennials and genx. This site isn't really making waves among the "kids" and I doubt ever will unfortunately. It's us taking this ship to its end. o7 I would like to see the ages and sign up numbers over the years.
I don't know if it's making waves among the zoomers, but there isn't yet an alternative for zoomers who've entered the tech workforce, is there?
All the techy ones are on discord nowadays, it's the modern IRC. My go and rust servers are packed with people half my age (late 30s).
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#195Chromium doesn't respect XDG config, it always creates ~/Downloads directory on startup. It was so annoying, I hope this tool helps me fix it.
AFAICS it does respect https://www.freedesktop.org/wiki/Software/xdg-user-dirs/.
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#196The biggest problem with getting programs to respect the XDG spec isn't getting programs to move their config file from $HOME/.myproj.yaml to $HOME/.config/myproj/config.yaml. It's getting projects not to store configuration and secrets in the same file.
So much for checking all of $HOME/.config into a Git repository.
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#197Earlier quoted context omitted.
> They're the ones maintaining the damn things, the least we can do is respect them. we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users? yes, they're writing and maintaining, but undoubtedly also using tons of respectful opensource that other maintainers take care of. it's like driving a car ("everybody faster than me is a maniac, e…
> why should we respect maintainers who don't respect users? Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think? Like it or not, unix has historically treated dotfiles as "hidden" and nobody expects you to get upset that they created a hidden file in your home directory without your consent. It's not really about respect, it's just convention you app…
Just to clarify, it is not just about "hidden" files looking good. There are many reasons one may want to move config/data/cache files to other locations, E.G. in my case I have a computer with home on a small partition that simply can't fit all the crap those misbehaving programs try to put there. I simply can't install Flatpacks on that machine because they obviously won't fit in a small home and can't be moved because of a maintainer who is very disrespectful to users (the bugs full with messages of users pleading for him to allow them to move apps to other partitions is disheartening).
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#198Earlier quoted context omitted.
Short, memorable passwords like one's birthday or favourite pet's name are "just fine for the vast majority of users". It's a meaningless metric of quality - or more to the point - it isn't a metric of quality.
Weak passwords have securities downside. I struggle to see what the issue is with ~/.programName ?
1. It doesn't separate program's config, data, and cache; so it is impossible to backup excluding cache, impossible to reset your config without data-loss.
2. It assumes home is infinite, if you are running out of space in home you can't move program files to other partitions. E.G. Flatpack hardcodes its apps data in `~/.var` so if you have a small/almost-full home partition you simply can't install certain Flatpacks.
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#199Earlier quoted context omitted.
This is the world of Unix, there's very little obligation to do anything other than convention. That's technically true, just like you can write your software to ignore all signals, or write your software such that it assumes it's always run as root for your convenience. That may be more convenient for you the developer, it's true. But those are all generally poor ways to write software, and a great way to get your u…
To put configs in ~/.program is the convention I learned, not ~/.config/. That came later, and I see 0 reason to pick it up. It's an annoying new hierarchy which I don't even like as a user, so I certainly wouldn't follow it as a developer.
If the programs in question implement the XDG base directory spec properly, then putting `export XDG_CONFIG_HOME=$HOME/.program` in your .profile will make them put config files in .program, not .config.
Re: Show HN: boxxy – Control where Linux programs put files, without symlinks
#200Earlier quoted context omitted.
> surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. There doesn't need to be an "excuse" though. "I don't like it" or "I don't want to do it" is more than enough. They're the ones maintaining the damn things, the least we can do is respect them. They don't really need to justify anything, acting as if they had to is how you ge…
> They're the ones maintaining the damn things, the least we can do is respect them. we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users? yes, they're writing and maintaining, but undoubtedly also using tons of respectful opensource that other maintainers take care of. it's like driving a car ("everybody faster than me is a maniac, e…
> we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users?
Because they're the ones putting in the work. I could patch all the programs to use whatever paths I liked best if I really cared but the truth is I don't want to put in that much effort. So I just work with what I'm given instead.
Besides, dotfiles conventions are not even in the same category of technical decision as literal vulnerabilities. One puts people at actual risk, the other is just opinion on file system taxonomy.
I mean, I have opinions on proper file system organization too and they certainly don't match Unix "tradition" but I don't go to other people's issue trackers and shame other developers when they make "excuses" for not following whatever scheme I thought up. I have reasons and I can certainly try to convince others that I'm right but it's simply offensive to show up out of nowhere with an indignant tone demanding that others make changes of a subjective and frankly trivial nature and then criticizing them in other forums when they refuse.