zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. schmuc+3q[view] [source] 2026-01-04 16:33:55
>>csmant+(OP)
This post gets some of the details wrong. /usr/local is for site-local software - e.g. things you compile yourself, i.e in the case of the BSDs the ports collection - things outside the base system. (They may be compiled for you).

Since Linux has no concept of a base system, it's a stand-alone kernel with a hodgepodge of crap around it - this distinction makes no sense on Linux.

/opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software. You're putting your $500k EDA software under /opt.

◧◩
2. theand+Lt[view] [source] 2026-01-04 16:55:34
>>schmuc+3q
> /opt is generally for software distros for which you don't have source; only binaries. Like commercial software packages. More common on Real UNIX(R) because most Linux users outside enterprise aren't running commercial software

Steam says hi.

On Windows, a common Steam library exists in Program Files directory, therefore not user specific. On Linux, each user has a separate Steam installation and library. I'm not sure why there isn't a common Steam library on Linux, but /opt would be a good place for it.

◧◩◪
3. schmuc+0y[view] [source] 2026-01-04 17:21:41
>>theand+Lt
By default, Program Files is not writable by non-Administrators. This is likely done by some background service. Or they loosened the default file permissions (which would be dumb).

No reason this can't be done on Linux but since NT's security model is more flexible it's a lot easier to do so on Windows. You'd need to add dedicated users. (Running a Steam daemon as root would probably cause an uproar.)

◧◩◪◨
4. Dylan1+HA[view] [source] 2026-01-04 17:37:53
>>schmuc+0y
They loosen the permissions on the steam folder on windows. I would have expected just the library folder but apparently it's the whole thing.
◧◩◪◨⬒
5. schmuc+7C[view] [source] 2026-01-04 17:46:17
>>Dylan1+HA
Oof. The correct location for this is C:\ProgramData

Developers who knowingly reduce or disable default Windows security settings should be censured. Because in 99% of cases it is due to ignorance or plain laziness.

◧◩◪◨⬒⬓
6. Dylan1+DC[view] [source] 2026-01-04 17:49:29
>>schmuc+7C
Well ProgramData didn't exist when they designed it, and the crime of putting their folder in the wrong place is a pretty minor one. They don't change the permissions of anything outside Steam.

It doesn't "reduce or disable default Windows security settings" in a meaningful way if you say to yourself "that folder effectively is in ProgramData, but spelled wrong".

◧◩◪◨⬒⬓⬔
7. schmuc+sE[view] [source] 2026-01-04 18:00:49
>>Dylan1+DC
CSIDL_COMMON_APPDATA is the API call to get this special folder which has been around since <checks notes> Windows 2000, 26 years ago.

You should never hardcode the path since it can and has moved around, though MS has implemented hard links to legacy paths because most developers are stupid and against persistent better advice do it anyway. I've seen multi-million dollar software packages whose vendor requires it to be writable by "Everyone".

Steam was first released in 2003, three years later.

For 80% of grievances about Windows, there is likely a solution in place that no one knows about because they didn't read the documentation.

◧◩◪◨⬒⬓⬔⧯
8. Sleake+RN[view] [source] 2026-01-04 18:58:23
>>schmuc+sE
And steam was originally released to be compatible with Windows 98. windows 2000 wasn't widely used as a consumer installed OS.
◧◩◪◨⬒⬓⬔⧯▣
9. schmuc+iQ[view] [source] 2026-01-04 19:14:30
>>Sleake+RN
> windows 2000 wasn't widely used as a consumer installed OS

But Windows XP, which came out in 2001, inherited everything from Windows 2000 and more, and was used extensively for gaming.

◧◩◪◨⬒⬓⬔⧯▣▦
10. Sleake+Gd2[view] [source] 2026-01-05 08:22:37
>>schmuc+iQ
Absolutely and first iterations of steam hardware survey showed mostly XP users, but still 5-7% win 98 install base, which they maintained compatibility with for quite a while, that's just to say that I can see why they might not have used those specific windows APIs at the start.
[go to top]