$HOME pollution

What I want...
Sounds logical. And I had similar thoughts like that many times, including such as "Why not delete config automatically when a software is deinstalled from the system?"
If you think it through you will find you would only reduce "$HOME pollution" a small bit for the price to complicate the usage much more.
To answer my own question first: Besides config doesn't occupy noteworthy space (almost always a few kB each) by automatically removing user's config you would kill each user's config *cough* - what if a user spent lots of effort into her personal config? (Don't forget: We are on a multiuser system.) What if the user wants to keep the config for the case the software will be installed later again? (e.g. saved games may be put into this suggestion, too) Or the user wants to copy the config to another system?
It's better for to give each user the responsibility to delete her individual config if not needed anymore, than complicate things even more, like producing the urge for workarounds for the danger of automatic deletion.

As I sketched in post #17 automatic placed configs are only one cause for what we call here "pollution". And in my eyes this is just a minor case. Since "reduce pollution" can also be named as "keep your /home/ clean and in order" is primarily the user's own personal task: to create structure, move files, remove not needed things - it is organization, and discipline, and as I also pointed out, a learning process.
Otherwise a user will mess up her /home/ sooner or later anyway - with or without configs.
And I think I also gave in my post some ideas that at least help me to keep overview over my /home/, which for example currently comes to 74 lines for a ls -la ~ - and I bet others will have way more entries in their home, neither lost overview, nor have the feeling to have messed up their place, drowning in useless garbage, files forgotten to be deleted.

I guess we're all roots here, on our, and maybe other systems. But since Unix and unixlike are multiuser systems you also need think of only users, while I'm not talking "no root access" here, but "by far not the knowledge as a root." So in my eyes the idea to ask the users to copy config from default sources somewhere under /usr/ when wanted, was maybe not easier than what we have now.

Bottom line:
You can turn it as you like, you always get things could have been better, even flaws in a system having its roots over fifty years ago, of course. And even known and seen as flaws some things simply cannot be changed if you don't want to get a bunch of other, maybe even bigger problems instead, like compatibility issues with older software, or software from other unix[like] world.
And there also are always things you simply would not get an improvement when you change them, but only change the kind of complication, or move it to another place - so nothing won, really. Or, as we say in german: The choice between pest and cholera.
And sometimes there are just some things coming as an characteristic of the system. You simply have to learn and accept it.
Thinking about it will bring you on many cases to the conclusion (at least in unix[like] {that was a joke on MS Windows}):
The people who made a decision gave it a good thought, and had very good reasons to design things the way they are. In case of FreeBSD comparing it to all other systems I experienced so far in the last fourty years, many of those choices weren't the worst ones. :cool:
In many situations when decision are needed only compromises can be made, since sometimes there is not the one and only perfect solution. And, yes, on other systems you may find single things made better as here. But I am convinced with FreeBSD the overall compromise is best - it is at least to me. Others will have other needs and preferences, and I accept that 😜
 
including such as "Why not delete config automatically when a software is deinstalled from the system?"
Have you payed attention to a PKG upgrade? First the old software is deinstalled and the new installed afterwards. Keeping track of files would be hell otherwise. So no, that idea won't fly. Sorry.
 
Sure.
Maybe you answered before you read it all?
And I wasn't talking about system's config, but the user's config in her /home.
 
Sure.
Maybe you answered before you read it all?
And I wasn't talking about system's config, but the user's config in her /home.
Ahh, but a pkg delete works at the system level, no?
If one accepts that premise, system level operations should never even know about specific user config, with the end result of pkg delete only deletes system level stuff.
If a newer version of the pkg is installed, it should use existing user specific config or migrate to a newer version.
Example:
The application darktable for do photo manipulation stuff.
Install the app, wind up with system level configuration.
Run the app, create user specific configuration.

pkg delete the app, system level unmodified config should go away, but user config is not touched.
App deleted, user can't run, user asks admin to please reinstall.
Admin installs app, newer version, user runs, darktable says "need to migrate config across version, yes/no"

pkg upgrade, I would imagine that new versions of config would simply replace old versions at the system level, when user runs new version they would likely see the "migrate config..." message.

Part of reason for not deleting user specific config, is I can rebuild and install an application in my user home directory so even if it's deleted at system level, I can still run it.
 
Sounds logical. And I had similar thoughts like that many times, including such as "Why not delete config automatically when a software is deinstalled from the system?"
If you think it through you will find you would only reduce "$HOME pollution" a small bit for the price to complicate the usage much more.
To answer my own question first: Besides config doesn't occupy noteworthy space (almost always a few kB each) by automatically removing user's config you would kill each user's config *cough* - what if a user spent lots of effort into her personal config? (Don't forget: We are on a multiuser system.) What if the user wants to keep the config for the case the software will be installed later again? (e.g. saved games may be put into this suggestion, too) Or the user wants to copy the config to another system?
It's better for to give each user the responsibility to delete her individual config if not needed anymore, than complicate things even more, like producing the urge for workarounds for the danger of automatic deletion.

As I sketched in post #17 automatic placed configs are only one cause for what we call here "pollution". And in my eyes this is just a minor case. Since "reduce pollution" can also be named as "keep your /home/ clean and in order" is primarily the user's own personal task: to create structure, move files, remove not needed things - it is organization, and discipline, and as I also pointed out, a learning process.
Otherwise a user will mess up her /home/ sooner or later anyway - with or without configs.
And I think I also gave in my post some ideas that at least help me to keep overview over my /home/, which for example currently comes to 74 lines for a ls -la ~ - and I bet others will have way more entries in their home, neither lost overview, nor have the feeling to have messed up their place, drowning in useless garbage, files forgotten to be deleted.

I guess we're all roots here, on our, and maybe other systems. But since Unix and unixlike are multiuser systems you also need think of only users, while I'm not talking "no root access" here, but "by far not the knowledge as a root." So in my eyes the idea to ask the users to copy config from default sources somewhere under /usr/ when wanted, was maybe not easier than what we have now.

Bottom line:
You can turn it as you like, you always get things could have been better, even flaws in a system having its roots over fifty years ago, of course. And even known and seen as flaws some things simply cannot be changed if you don't want to get a bunch of other, maybe even bigger problems instead, like compatibility issues with older software, or software from other unix[like] world.
And there also are always things you simply would not get an improvement when you change them, but only change the kind of complication, or move it to another place - so nothing won, really. Or, as we say in german: The choice between pest and cholera.
And sometimes there are just some things coming as an characteristic of the system. You simply have to learn and accept it.
Thinking about it will bring you on many cases to the conclusion (at least in unix[like] {that was a joke on MS Windows}):
The people who made a decision gave it a good thought, and had very good reasons to design things the way they are. In case of FreeBSD comparing it to all other systems I experienced so far in the last fourty years, many of those choices weren't the worst ones. :cool:
In many situations when decision are needed only compromises can be made, since sometimes there is not the one and only perfect solution. And, yes, on other systems you may find single things made better as here. But I am convinced with FreeBSD the overall compromise is best - it is at least to me. Others will have other needs and preferences, and I accept that 😜
I don't want anyone to automatically clean up existing configs in my home directory. What I meant is "minimize pollutions to start using anything".

If default is OK, no configs should be generated in the user's home.
In this case, announcing the deletion of the software to all users is sufficient and no harm.

If any of users want custom configs and the admin allows it, what admin should do on deletion would be announcement of deletion prior to actual deletion and provide script to remove custom configs from each user's home directory (run it or not is on each users).

Most annoying cases would be like below.
  • Format of configs are changed and each user need to convert manually (and creating script to convert supporting ALL possible cases is not easy).
  • Data format (except config, something like M$ Office's data formats) is changed but no automatic conversion by the software itself is supported (external tool is needed to be used, like PostgreSQL upgrades).
 
Back
Top