Hi, > >>> If ed is wanted, perhaps LSB should only include it by reference > >>> to POSIX, and not explicitly include it in LSB. > >> vi is often (or always?) placed in /usr/bin, and /usr is on a separate > >> partition. > > > > So.. I don't quite see the connection of ed to vi being in /usr. > > > >> There are many scenarios, and they all exclude vi from being in /. > > > > Counter-example: openSUSE which ships vim in /bin. This is no counter-example for that scenario. These scenarios do exist. What I was talking about: The system should have a minimal set of tools to be usable when everything else fails.
> Many of the legacy decisions have been made when disk drives were > expensive and small. I remember being excited when I bought my first > hard drive: 80MB for the new low price of $600. That was somewhere > around 1985. > > Today, I don't think you can get a new rotational disk drive that is > less than 250GB (for about $40 to $60). Even thumb drives are 16GB for > less than $20. The economics of HW today does have an impact on the > disk layout. What was appropriate in 1990 is not appropriate today. I > think the FHS should reflect that. this is not about disk space, this is about usage scenarios. Having an external (via nfs) /usr does not need to be for disk space reasons, but for management purposes. Having an extra filesystem for /usr could be for many reasons, having many source files there is one of them. The source-building systems like portage, ports and pkgsrc (though ports is a BSD thing) have many small files, thus it is better having another inode/block ratio than usual. Or encrypting /usr, or whatever you want to do with it. There are many reasons to make /usr an extra partition. > I have seen discussion about removing /usr/bin completely and putting > everything on /usr. There are multiple distributions that today say > that they don't support a separate (or at least a remote) /usr partition. > > What the FHS/LSB should be about is to not only set a standard about > what facilities are available for a product today, but to provide a > roadmap to what will be available in the future. This means that > programs that are of marginal use should be deprecated. > > In the days when memory is measured in GB and disk in TB, things like vi > in /bin and vim in /usr/bin is nonsensical. The same can be said for > the differences between dash and bash. That's a separate discussion going on, removing /usr completely or requiring it to be in /bin would change this situation. > I don't know of any *programs* that rely on ed/at/batch. Sure users can > and do use them, but do they need to be part of a standard? With vi and possibly all other editors being on separate partition, / would be completely without an interactive editor. And there are situations in which you only have that choice, even on the most modern hardware. Regards, Julian
signature.asc
Description: PGP signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/fhs-discuss
