BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Debian 12 vs. WSL 1
- Subject: [Discuss] Debian 12 vs. WSL 1
- From: richard.pieri at gmail.com (Rich Pieri)
- Date: Sat, 24 Jun 2023 20:16:22 -0400
- In-reply-to: <ZJd+Njr04pPtSzbT@csail.mit.edu>
- References: <20230624113745.0000319a.Richard.Pieri@gmail.com> <ZJd+Njr04pPtSzbT@csail.mit.edu>
On Sat, 24 Jun 2023 19:37:26 -0400 grg <grg-webvisible+blu at ai.mit.edu> wrote: > even if only one is used at a time, the system still has two paths to > the resource (which I'd argue is twice as many as a clean design > ought to have...) An argument that I would agree with in principle, but you have to walk and merge /bin and /usr/bin before you can run and remove one of them, assuming you don't want to break roughly half of all the software out there. > but unfortunately there's only one copy - usrmerge has made sure > you've lost any data redundancy you might have had. so all you're > left with is the bloat. One LUN, many paths to it, that's redundancy, not bloat. One program, many paths to it, that's redundancy, not bloat. > I thought the "merged-usr-via-aliased-dirs" solution which won the > usrmerge battle explicitly calls for the /bin, /lib, etc. symlinks to > exist? Because the purpose of UsrMerge isn't the elimination of /bin and friends but the elimination of differences between split bin and friends. The redundancy provided by these symlinks will eventually be seen as superfluous. Then a call will be made to remove them from future standards. -- \m/ (--) \m/
- References:
- [Discuss] Debian 12 vs. WSL 1
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] Debian 12 vs. WSL 1
- From: grg-webvisible+blu at ai.mit.edu (grg)
- [Discuss] Debian 12 vs. WSL 1
- Prev by Date: [Discuss] Debian 12 vs. WSL 1
- Previous by thread: [Discuss] Debian 12 vs. WSL 1
- Next by thread: [Discuss] Boston Linux VIRTUAL Meeting , Wednesday, June 21, 2023 - Implementing VisiCalc
- Index(es):