On 17Mar2015 07:36, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>
wrote:
I must admit that the Linux filesystem layout strikes me as awfully pedantic
and fussy. We're happy to use our home directory as an undifferentiated bag
with no structure, dumping binaries, scripts, documents, data files, config
files and everything else into $HOME, but for applications we have:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/opt
and probably more, to say nothing of
/lib
/usr/lib
/usr/local/lib
Yeah, it is a bit nuts. A lot of that is history:
/bin vs /sbin
/sbin was staticly linked executables, which needed to work early in the
boot process (or in rescue situations) before (arbitrarily placed) dynamic
libraries were available; as a consequence, /sbin these days mostly
contains admin commands (necessary) versus /bin with the other commands
(less critical, just useful)
Less of an issue these days with bigger drives, so /bin vs /sbin is mostly
historic and unnecessary
/ vs /usr (and therefore /bin vs /usr/bin etc)
the root fs (/0 used to be very small, limiting what would fit
/usr was larger and mounted later
There are multiple reasons for this, including the size of the system you
need to repair to rescue (repair a small / vs something bigger) and
limiting damage (less I/O to /, therefore less risk of need of repair)
and so forth.
Less of an issue these days with bigger and faster drives, fo /bin vs
/usr/bin is historic and unnecessary
/ (and /usr) vs /usr/local
This is architectural and important. /usr/local tends to be for extras not
supplied by the OS provider/vendor. So a bare supplies OS will have stuff
in / and /usr, but /usr/local will be an empty skeleton for people to add
stuff to without treading on the supplied and supported OS areas.
Yes, off topic, sorry.
Python 3 vs Python 2: a good thing IMO. The way the transition was done?
Correct IMO. Add nonbreaking stuff to the 2.x series (with, yield from, extra
libraries supporting interfaces coming in the 3.x series, so forth) but keep
legacy code working unchanged. With 3.x, cut to changes that would break legacy
code, but we now have a cleaner and better language.
And re Paul Rubin's "fork the language" remakr: Python 3.x _is_ the fork!
I try to make most of my code work in both py2 and py3; easier to run on
multiple systems. But I definitely have code that works so much better in
python 3 that I will never backport it; the example I have in mind started as
python 2 and spent years in bytes/text indecision and confusion. Bite the
bullet and go py3, an a whole class of pervasive issue just go away.
Cheers,
Cameron Simpson <c...@zip.com.au>
PARANOIDS!!!! They're EVERYWHERE!!!
- bcash@crchh410.NoSubdomain.NoDomain (Brian Cash)
--
https://mail.python.org/mailman/listinfo/python-list
