From spedraja at gmail.com Thu Feb 23 18:18:49 2012 From: spedraja at gmail.com (Sergio Pedraja) Date: Thu, 23 Feb 2012 08:18:49 +0000 (UTC) Subject: [Unix-jun72] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?= Message-ID: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod> LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-p9hg1j-gyzit23b-16/isd/6035310103/YCHqBtRa/?hs=false&tok=2G1F-50oSieR81 -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-p9hg1j-gyzit23b-16/pQvcBySBaffs0LLhMMtx8DQb3x_CTMm/goo/unix-jun72%40tuhs%2Eorg/20061/I2097818457_1/?hs=false&tok=1I03vjIjSieR81 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spedraja at gmail.com Thu Feb 23 18:36:06 2012 From: spedraja at gmail.com (SPC) Date: Thu, 23 Feb 2012 09:36:06 +0100 Subject: [Unix-jun72] =?iso-8859-1?q?Invitaci=F3n_a_conectarnos_en_LinkedI?= =?iso-8859-1?q?n?= In-Reply-To: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod> References: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod> Message-ID: *Very* sorry for the mistake. Sergio. El 23 de febrero de 2012 09:18, Sergio Pedraja escribió: > > [image: LinkedIn] > > > > [image: Sergio Pedraja] > > *De Sergio Pedraja* > > IT Security Administrator / Information Security Manager en Savings Bank > Santander y alrededores, España > > > > > Me gustaría añadirte a mi red profesional en LinkedIn. > > -Sergio > > > > Confirma que conoces a Sergio > > > > Estás recibiendo invitaciones a conectar. Date de baja > © 2012, LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043 > EE.UU. > > > _______________________________________________ > Unix-jun72 mailing list > Unix-jun72 at tuhs.org > https://minnie.tuhs.org/mailman/listinfo/unix-jun72 > > -- Gracias. -- Saludos - Greetings - Freundliche Grüße - Salutations Sergio Pedraja twitter: @sergio_pedraja http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://www.quora.com/Sergio-Pedraja https://www.xing.com/profile/Sergio_Pedraja http://www.viadeo.com http://www.avalonred.com/ ----- No crea todo lo que ve, ni crea que está viéndolo todo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at bitmover.com Wed Feb 1 01:49:50 2012 From: lm at bitmover.com (Larry McVoy) Date: Tue, 31 Jan 2012 07:49:50 -0800 Subject: [TUHS] History of man pages In-Reply-To: <34F8DEFE-9667-4915-9A3F-703EE78C07E1@ronnatalie.com> References: <20120131013631.GB45125@dereel.lemis.com> <20120131015335.GA31880@minnie.tuhs.org> <34F8DEFE-9667-4915-9A3F-703EE78C07E1@ronnatalie.com> Message-ID: <20120131154950.GZ17183@bitmover.com> I still use it, BitMover's MLA (signed by the likes of Intel, Cisco, IBM, HP, etc) is maintained in troff. And one of those companies, not to be named, shoved it into word (in fact they all did that part), turned on track changes, made some typo like fixes, turned off track changes, and changed some major stuff. I took the word doc, extracted to text, ran it through my formatter and diffed 'em and found the unwanted changes. Said company proceeded to be shocked! shocked! shocked, I tell you! Shocked! that this had happened and it must have been a huge mistake! Go roff. Or go diff. Or something :) On Tue, Jan 31, 2012 at 08:04:09AM -0500, Ronald Natalie wrote: > Gosh, I'd forgotten about that. "Roff is the simplest of the text formatting programs but is utterly frozen." > They finally dragged me off troff in the mid-90's. > > > On Jan 30, 2012, at 8:53 PM, Warren Toomey wrote: > > > On Tue, Jan 31, 2012 at 12:36:31PM +1100, Greg 'groggy' Lehey wrote: > >> I've received a link http://manpages.bsd.lv/history.html claiming to > >> be about man pages; in fact, it's a lot more than that, including the > >> prehistory of troff. Interesting stuff. > >> > >> Greg > > > > Thanks Greg, yes a good read. Pity we've lost the PDP-11 asm > > version of roff from 1st/2nd Edition Unix. > > Warren > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com From a.phillip.garcia at gmail.com Wed Feb 1 05:16:17 2012 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Tue, 31 Jan 2012 13:16:17 -0600 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Message-ID: http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Feb 1 05:27:15 2012 From: imp at bsdimp.com (Warner Losh) Date: Tue, 31 Jan 2012 12:27:15 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: Message-ID: <165D3734-0D92-43B9-9D71-62690AB7BB5E@bsdimp.com> Well, except for the part that it stopped making sense before Linux was invented... the split also allows minimal ram disk images to load the rest of the OS and mount the full system remotely... These were still useful after 1990 when Linux was first released. It wasn't until around 1995 or so that disks were big/cheap enough for it to not matter... Warner On Jan 31, 2012, at 12:16 PM, A. P. Garcia wrote: > http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Wed Feb 1 05:39:18 2012 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Tue, 31 Jan 2012 13:39:18 -0600 Subject: [TUHS] xv6 Message-ID: saw this on osnews under 'related articles'; it's a rewrite of sixth edition for x86: http://pdos.csail.mit.edu/6.828/2011/xv6.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Feb 1 19:26:39 2012 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 1 Feb 2012 01:26:39 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Message-ID: <201202010926.q119QdMm007019@freefriends.org> > http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split Cute, but most of the history is wrong. The distinction between /bin and /usr/bin is true - / held the things need to boot the system. Other things were on /usr. The Berkeley guys did NOT invent shared libraries. Shared libraries as we know them came originally from Sun, on SunOS 4.x for sure, possibly on SunOS 3.x. (Larry?) Many commercial vendors adopted the design (Ultrix, I think, and maybe others) and finally around 4.4 they found their way into "pure" BSD. /home and /opt came into the picture circa 1989 with SVR4 when Berkeley, AT&T and Sun (and maybe a few others?) got together to standardize the layout and make diskless booting possbile and reasonable with NFS sharing of home directories. /sbin & /usr/sbin came into the picture at this point also, to hold executables that until then had lived in /etc. The idea was that /etc should only have per-machine configuration files. The general point of the article and of some of the postings, that the proliferation doesn't make a lot of sense today, is well taken. The Bell Labs guys themselves recognized this when they did Plan 9. The problem is even worse on 64 bit Linux systems, which can handle two different architectures. /lib and /lib64 confuse a lot of the older 'configure' programs. Personally, I hate reading articles by "experts" where 85% of the facts are wrong. I lived through all of it, and I know better... :-) Arnold From jrvalverde at cnb.csic.es Wed Feb 1 21:12:14 2012 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Wed, 1 Feb 2012 12:12:14 +0100 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: Message-ID: <20120201121214.55c73577@cnb.csic.es> On Tue, 31 Jan 2012 13:16:17 -0600 "A. P. Garcia" wrote: > http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split I think this is typical misunderstanding of modern-day newcomers. The main problem to me seems to be that they think of UNIX (and Linux) as a Windows PC, which it isn't (and they even do not understand the Windows PC itself). The fact that at some point people was strained by disk space (and it has nothing to do with Ken or Dennis or disk availability) only means they had a pressure to split contents, and unless anyone was a moron, everyone would do it in a similar rational way. A rational way in the times meant adapting for the times' needs, and by then UNIX was a multi-user OS. So, beyond the point of filling up a disk (and that's the point for the partition system) there was a need to ensure you could separate user data from system data: adding user programs or data to a separate space (disk, partition, whatever) ensured the system space was not filled and the system would not become unusable. That was the real reason for /, /usr, /tmp and /var as standard partitions for most of us, not the availability of new disks. And the same is valid for separating system-specific binaries from general users. When disks came it would be handy to move a partition to a separate disk, but the need itself has nothing to do with the availability of extra disks. This is something obvious to anyone maintaining a multi-user server, only presumptuous single-user windows toyers think they know better. Even now when I get a user asking to set up a new computing server, their first query is how to separate system from users and scratch space. Any power user has filled his own system once and knows the risk. They also know they can cope with their own system and files. And they all know they cannot in a shared environment where they cannot control other users' files. Point is, the very first idea that occurs to any sensible being when facing a multiuser system is how to separate contents safely. That Ken and Denis did the obvious thing (as many of us did at the time --I remember having a /usr/local on my machines years before it was commonplace use) only speaks of their common sense (and the ignorance or lack of common sense in complainers). This is still valid in the times of petabyte disk arrays, ACLs, quotas, queuing systems and all what nots. Even more so in these large installations (I have witnessed multi-TB scratch files in jobs, filling a supercomputing installation and requiring operator intervention to avoid stopping the work of all other users). And so on, I could rant all day arguing why this was the obvious approach to many problems then, and often now too. So, to me, this looks more like a case of "reintrepreting and twisting the facts to justify untenable beliefs" instead of trying to understand what actually happened and why. Like saying the wheel was invented only to make carriages and that we keep using carriages (instead of say helicopters) just because of tradition and "bureaucrats" instead of accepting that there were many needs and when the wheel came it was -and still is- the obvious solution to most of those problems (among them carrying loads in carriages). j -- EMBnet/CNB Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es http://www.es.embnet.org From imp at BSDIMP.COM Thu Feb 2 03:35:53 2012 From: imp at BSDIMP.COM (Warner Losh) Date: Wed, 1 Feb 2012 10:35:53 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120201121214.55c73577@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> Message-ID: <9BAA3D8D-6B2C-4EDD-A413-5079E63D6E86@bsdimp.com> On Feb 1, 2012, at 4:12 AM, Jose R. Valverde wrote: > So, beyond the point of filling up a disk (and that's the point for the partition > system) there was a need to ensure you could separate user data from system data: > adding user programs or data to a separate space (disk, partition, whatever) > ensured the system space was not filled and the system would not become unusable. You had different quotas on different partitions as well... Something most folks don't get these days: you used to get 5MB from the CS department and be grateful they gave you that much... There were bugs in the dim, dark past too where if you filled up /, the system would crash. Having a separate / insulated you from that. Also, fsck and file systems were a little more fragile in the early days than now, so you wanted to make sure that you minimized the amount of data needed to change before / could be mounted rw. This boot-strapping process these days (on linux) happens in a ram disk, but historically (and still in many BSDs) happens on the actual drive, so any corruption or filesystem issue would take a while to repair, and once repaired you had to reboot to ensure that the pages that were swapped in read-only that might have been changed behind the scenes by fsck were properly flushed. None of that was mentioned in the article :) Warner From random832 at fastmail.us Thu Feb 2 23:32:45 2012 From: random832 at fastmail.us (Random832) Date: Thu, 02 Feb 2012 08:32:45 -0500 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120201121214.55c73577@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> Message-ID: <4F2A907D.9000000@fastmail.us> On 2/1/2012 6:12 AM, Jose R. Valverde wrote: > So, beyond the point of filling up a disk (and that's the point for the partition > system) there was a need to ensure you could separate user data from system data: > adding user programs or data to a separate space (disk, partition, whatever) > ensured the system space was not filled and the system would not become unusable. The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures From tfb at tfeb.org Thu Feb 2 23:35:58 2012 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 2 Feb 2012 13:35:58 +0000 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <201202010926.q119QdMm007019@freefriends.org> References: <201202010926.q119QdMm007019@freefriends.org> Message-ID: On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote: > The Berkeley guys did NOT invent shared libraries. Shared libraries as > we know them came originally from Sun, on SunOS 4.x for sure, possibly > on SunOS 3.x. (Larry?) Many commercial vendors adopted the design (Ultrix, > I think, and maybe others) and finally around 4.4 they found their way into > "pure" BSD. 4. 3 may have had them but not in any version we had, so I'd guess not in a major release, anyway. From tfb at tfeb.org Thu Feb 2 23:45:25 2012 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 2 Feb 2012 13:45:25 +0000 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120201121214.55c73577@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> Message-ID: <8E4D7C90-58E1-4860-BBEB-040A5C765DBE@tfeb.org> On 1 Feb 2012, at 11:12, Jose R. Valverde wrote: > This is something obvious to anyone maintaining a multi-user server, only > presumptuous single-user windows toyers think they know better. If only this were true. Until reasonably recently (may be a couple of years ago was the last time I cared), a major Unix vendor's recommendation was not to have separate /var, because that was "old fashioned" (I assume). Some of their installation / upgrade programs would fail if you did in fact. For additional amusement, the default install would put no limit on the size of the memory-based /tmp filesystem. So basically anything on the system could fill / with all the undesirable consequences that has, and also eat the system's memory in an unpleasantly persistent way. --tim From lm at bitmover.com Thu Feb 2 23:49:20 2012 From: lm at bitmover.com (Larry McVoy) Date: Thu, 2 Feb 2012 05:49:20 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <201202010926.q119QdMm007019@freefriends.org> Message-ID: <20120202134920.GT6205@bitmover.com> On Thu, Feb 02, 2012 at 01:35:58PM +0000, Tim Bradshaw wrote: > On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote: > > > The Berkeley guys did NOT invent shared libraries. Shared libraries as > > we know them came originally from Sun, on SunOS 4.x for sure, possibly > > on SunOS 3.x. (Larry?) Many commercial vendors adopted the design (Ultrix, > > I think, and maybe others) and finally around 4.4 they found their way into > > "pure" BSD. > > 4. 3 may have had them but not in any version we had, so I'd guess not in a major release, anyway. I got there when SunOS 4.1 was being worked on and they were definitely in 4.0. 4.0 gave you shared libs, vnodes, mmap, there was a lot of good stuff in there. It actually worked by 4.1.1 which was probably my favorite SunOS release. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com From imp at bsdimp.com Fri Feb 3 03:24:26 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 10:24:26 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <4F2A907D.9000000@fastmail.us> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> Message-ID: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> On Feb 2, 2012, at 6:32 AM, Random832 wrote: > On 2/1/2012 6:12 AM, Jose R. Valverde wrote: >> So, beyond the point of filling up a disk (and that's the point for the partition >> system) there was a need to ensure you could separate user data from system data: >> adding user programs or data to a separate space (disk, partition, whatever) >> ensured the system space was not filled and the system would not become unusable. > > The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". /usr was user data, back in the day. /home came about much later. > And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures sbin was created in SYS Vr4 to move all the binaries that were in /etc. /usr/share was created to move all the non-binary, non-text files that were in /etc like termcap and timezone info. Warner From imp at bsdimp.com Fri Feb 3 03:40:01 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 10:40:01 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> Message-ID: <78400D2A-74E6-434D-B168-4D1C1EDB8326@bsdimp.com> On Feb 2, 2012, at 10:24 AM, Warner Losh wrote: > > On Feb 2, 2012, at 6:32 AM, Random832 wrote: > >> On 2/1/2012 6:12 AM, Jose R. Valverde wrote: >>> So, beyond the point of filling up a disk (and that's the point for the partition >>> system) there was a need to ensure you could separate user data from system data: >>> adding user programs or data to a separate space (disk, partition, whatever) >>> ensured the system space was not filled and the system would not become unusable. >> >> The thing is, /usr isn't "user data". That's /home. /usr is just "more system space". > > /usr was user data, back in the day. /home came about much later. > >> And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures > > sbin was created in SYS Vr4 to move all the binaries that were in /etc. /usr/share was created to move all the non-binary, non-text files that were in /etc like termcap and timezone info. That should read 'all non-binary executables and non-config files' Warner From cowan at mercury.ccil.org Fri Feb 3 03:36:24 2012 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 2 Feb 2012 12:36:24 -0500 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> Message-ID: <20120202173623.GQ30634@mercury.ccil.org> Warner Losh scripsit: > sbin was created in SYS Vr4 to move all the binaries that were in /etc. > /usr/share was created to move all the non-binary, non-text files that > were in /etc like termcap and timezone info. Does anyone know what the "s" in sbin stands for? "Superuser"? I would have put these files in /root/bin, but perhaps /root did not yet exist. Not everything in /usr/share comes from /etc; in particular, /usr/share/dict was formerly /usr/dict. -- Go, and never darken my towels again! John Cowan --Rufus T. Firefly http://ccil.org/~cowan From tim.newsham at gmail.com Fri Feb 3 04:02:41 2012 From: tim.newsham at gmail.com (Tim Newsham) Date: Thu, 2 Feb 2012 08:02:41 -1000 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <4F2A907D.9000000@fastmail.us> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> Message-ID: > The thing is, /usr isn't "user data". That's /home. /usr is just "more > system space". Thats exactly what /usr is supposed to be. user data. ie. /usr/ken, /usr/dmr. -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com From imp at bsdimp.com Fri Feb 3 04:10:17 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 11:10:17 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120202173623.GQ30634@mercury.ccil.org> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> Message-ID: On Feb 2, 2012, at 10:36 AM, John Cowan wrote: > Warner Losh scripsit: > >> sbin was created in SYS Vr4 to move all the binaries that were in /etc. >> /usr/share was created to move all the non-binary, non-text files that >> were in /etc like termcap and timezone info. > > Does anyone know what the "s" in sbin stands for? "Superuser"? I would > have put these files in /root/bin, but perhaps /root did not yet exist. I'd been told a long time ago that is stands for 'system' for people that need to administer the system, not necessarily super users. The FreeBSD hier man page seems to bear this out: /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments > Not everything in /usr/share comes from /etc; in particular, /usr/share/dict > was formerly /usr/dict. That's true, but /usr/dict was a bit of an odd-ball at the top /usr level. /usr/share contained all the stuff from /etc and also other things that didn't seem to belong. That's why it is documented as having the architecture independent files in it... Warner From dave at horsfall.org Fri Feb 3 07:14:56 2012 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 3 Feb 2012 08:14:56 +1100 (EST) Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120202173623.GQ30634@mercury.ccil.org> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> Message-ID: On Thu, 2 Feb 2012, John Cowan wrote: > Does anyone know what the "s" in sbin stands for? "Superuser"? I would > have put these files in /root/bin, but perhaps /root did not yet exist. I seem to recall that they were statically linked i.e. not using those new-fangled shared library thingies. And if you've ever tried to admin a system with a trashed shared library, you'll understand; it usually involves looking for the installation media. > Not everything in /usr/share comes from /etc; in particular, > /usr/share/dict was formerly /usr/dict. As I dimly recall, /usr/share was exported, hence the name. -- Dave From imp at bsdimp.com Fri Feb 3 07:49:44 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 14:49:44 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> Message-ID: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> On Feb 2, 2012, at 2:14 PM, Dave Horsfall wrote: > On Thu, 2 Feb 2012, John Cowan wrote: > >> Does anyone know what the "s" in sbin stands for? "Superuser"? I would >> have put these files in /root/bin, but perhaps /root did not yet exist. > > I seem to recall that they were statically linked i.e. not using those > new-fangled shared library thingies. And if you've ever tried to admin a > system with a trashed shared library, you'll understand; it usually > involves looking for the installation media. /bin is also statically linked, at least on those distributions that support split / and /usr. SunOS 4.x and 4.4BSD did this. Except for the ones that have gone to a dynamic root moving the shared libraries from /usr/lib to /lib. Prior to the /etc -> /sbin moves, all binaries were statically linked. Even after the move /bin and /sbin remained static, while /usr/bin and /usr/sbin were dynamic. The needs of reliability vs space savings pushed all the binaries in /sbin and /bin to be static. Even after the split in more modern systems, init and sh tend to be the only binaries that are statically linked anymore. Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). Warner >> Not everything in /usr/share comes from /etc; in particular, >> /usr/share/dict was formerly /usr/dict. > > As I dimly recall, /usr/share was exported, hence the name. > > -- Dave > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > From tim.newsham at gmail.com Fri Feb 3 08:29:04 2012 From: tim.newsham at gmail.com (Tim Newsham) Date: Thu, 2 Feb 2012 12:29:04 -1000 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: >  Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). you're kidding, right? Disk space of binaries? (I still wish "du" had a "-$" flag that pulled info from a recent price database). > Warner -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com From imp at bsdimp.com Fri Feb 3 08:47:24 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 15:47:24 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: On Feb 2, 2012, at 3:29 PM, Tim Newsham wrote: >> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used). > > you're kidding, right? Disk space of binaries? > (I still wish "du" had a "-$" flag that pulled info from a recent price > database). No. I'm not kidding. Remember that these systems exist in more places than on monster-sized hard-disks. Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. While NAND has grown so that 64MB or 256MB parts are more common on boards, the savings is still rather substantial and allow for additional functionality. The space savings rivals 'crunchgened' binaries (think busybox). Savings between 32MB and 64MB is only a few $$$, but if you ship a million of something, the savings can be substantial. In addition, having everything link in shared libraries makes doing security updates much easier. Warner From lyndon at orthanc.ca Fri Feb 3 08:59:25 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 2 Feb 2012 14:59:25 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: <015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca> On 2012-02-02, at 2:47 PM, Warner Losh wrote: > Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. Those systems also tend to ship with a very carefully culled set of binaries. Perhaps someone reading this with access to that type of system could do some measurements of a static vs. shared build of one of those embedded systems. A well designed system without library bloat can pump out some pretty skinny static binaries. --lyndon From lyndon at orthanc.ca Fri Feb 3 08:53:54 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 2 Feb 2012 14:53:54 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: On 2012-02-02, at 1:49 PM, Warner Losh wrote: > Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used In the day of sub-hundred dollar terabyte drives, you're kidding me, right? Also, ever lost libc.so on a Solaris box? From norman at oclsc.org Fri Feb 3 09:16:35 2012 From: norman at oclsc.org (Norman Wilson) Date: Thu, 02 Feb 2012 18:16:35 -0500 (EST) Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Message-ID: <1328224608.3272.for-standards-violators@oclsc.org> Lyndon Nerenberg: A well designed system without library bloat can pump out some pretty skinny static binaries. ======= V6, for example. Or even V7 if carefully pruned. Once upon a time, I made an RK05 disk (5MB) with a stripped-down post-V7 for an 11/45. It had just enough programs to allow basic file manipulation and text-processing. We used this compact system to allow our secretaries (in a small university department in the early 1980s) to continue typing up papers and letters on the day the machine-room air conditioning was being replaced. With the doors standing open and a big fan, we were willing to leave the 11/45 running, but not the VAX-11/780. Due to contractor screwups (when the chilled water was turned on, it rained up and down the hall--many poorly-soldered joints in the copper pipes), we actually needed this for a couple of days, so for safety I shut the system down every evening, removed the RK05 cartridge, and took it downstairs to the 11/34 that had a tape drive, where I booted RT11 and took an image backup with ROLLOUT. Norman Wilson Toronto ON From imp at bsdimp.com Fri Feb 3 09:33:37 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 16:33:37 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> <015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca> Message-ID: <5274AA4A-9A0A-45BE-9387-564970B522D4@bsdimp.com> On Feb 2, 2012, at 3:59 PM, Lyndon Nerenberg wrote: > On 2012-02-02, at 2:47 PM, Warner Losh wrote: > >> Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done. > > Those systems also tend to ship with a very carefully culled set of binaries. Perhaps someone reading this with access to that type of system could do some measurements of a static vs. shared build of one of those embedded systems. A well designed system without library bloat can pump out some pretty skinny static binaries. You know that I wrote those patches for FreeBSD when I was producing embedded systems that needed the savings, right? At the time, the size of / was on the order of 60MB without the patches and 8MB with the patches (excluding the kernel and modules). Compression got the size of the kernel + / + /usr down to about 7MB which left enough room on the flash for our monolithic application. At the time, the crunchgen approach to binaries produced similar values (about 6MB for the same list of binaries we selected). However, our build process and monolithic application were ill suited to crunchgenning so we opted for shared libraries which got us most of the benefits and allowed us better flexibility in deploying new versions of our program. After the patches were done, we discovered other benefits, such as easier deploying of security fixes... Warner From carl.lowenstein at gmail.com Fri Feb 3 09:37:42 2012 From: carl.lowenstein at gmail.com (Carl Lowenstein) Date: Thu, 2 Feb 2012 15:37:42 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <1328224608.3272.for-standards-violators@oclsc.org> References: <1328224608.3272.for-standards-violators@oclsc.org> Message-ID: On Thu, Feb 2, 2012 at 3:16 PM, Norman Wilson wrote: > Lyndon Nerenberg: > >  A well designed system without library bloat can pump out some >  pretty skinny static binaries. > > ======= > > V6, for example.  Or even V7 if carefully pruned. > > Once upon a time, I made an RK05 disk (5MB) with a stripped-down > post-V7 for an 11/45.  It had just enough programs to allow > basic file manipulation and text-processing. > > We used this compact system to allow our secretaries (in a > small university department in the early 1980s) to continue > typing up papers and letters on the day the machine-room > air conditioning was being replaced.  With the doors standing > open and a big fan, we were willing to leave the 11/45 running, > but not the VAX-11/780. > > Due to contractor screwups (when the chilled water was turned > on, it rained up and down the hall--many poorly-soldered > joints in the copper pipes), we actually needed this for a > couple of days, so for safety I shut the system down every > evening, removed the RK05 cartridge, and took it downstairs > to the 11/34 that had a tape drive, where I booted RT11 and > took an image backup with ROLLOUT. You may have been lucky not to need the backup images. My experience with ROLLIN/ROLLOUT early on was that DEC software used only 200 of the 203 tracks available on a RK05. Unix on the other hand also used the 3 spare tracks. 4872 whole blocks. So ROLLIN backups of a Unix RK05 did not always have everything on them. carl --     carl lowenstein         marine physical lab     u.c. san diego                                                  clowenstein at ucsd.edu From imp at bsdimp.com Fri Feb 3 09:35:38 2012 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Feb 2012 16:35:38 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: On Feb 2, 2012, at 3:53 PM, Lyndon Nerenberg wrote: > On 2012-02-02, at 1:49 PM, Warner Losh wrote: >> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used > > In the day of sub-hundred dollar terabyte drives, you're kidding me, right? No. Read what I wrote: as a percentage of the whole. > Also, ever lost libc.so on a Solaris box? Yes. Thankfully, I've never had a similar loss on my FreeBSD boxes. :) Warner From cowan at mercury.ccil.org Fri Feb 3 09:58:38 2012 From: cowan at mercury.ccil.org (John Cowan) Date: Thu, 2 Feb 2012 18:58:38 -0500 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <1328224608.3272.for-standards-violators@oclsc.org> References: <1328224608.3272.for-standards-violators@oclsc.org> Message-ID: <20120202235838.GE21161@mercury.ccil.org> Norman Wilson scripsit: > Once upon a time, I made an RK05 disk (5MB) with a stripped-down > post-V7 for an 11/45. It had just enough programs to allow basic file > manipulation and text-processing. In my first job, around 1976, I hand-carried an RK05 from New Jersey to Kansas City. It was full of my employer's proprietary software, which I was to install. The laternative was to bring a huge pile of floppies, which didn't seem sensible. I was able to convince the airline security of those days that they could neither open the RK nor X-ray it, but when it got there, it was unreadable anyway. My colleague took the next flight, with the huge pile. > Due to contractor screwups (when the chilled water was turned on, it > rained up and down the hall--many poorly-soldered joints in the copper > pipes), [...] During PM, always mount a scratch machine room! -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the cowan at ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. From tfb at tfeb.org Fri Feb 3 21:10:02 2012 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 3 Feb 2012 11:10:02 +0000 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> Message-ID: <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> On 2 Feb 2012, at 22:53, Lyndon Nerenberg wrote: > > In the day of sub-hundred dollar terabyte drives, you're kidding me, right? > > Also, ever lost libc.so on a Solaris box? This is missing the point. A system with shared libraries can deliver a fix to a bug in a library by a new version of that library, instead of a new version of every program which is statically linked against that library. From jrvalverde at cnb.csic.es Sat Feb 4 01:22:16 2012 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Fri, 3 Feb 2012 16:22:16 +0100 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> Message-ID: <20120203162216.504c4bb7@cnb.csic.es> Whoa! I wasn't expecting this flood of comments! :-) Anyway, I think that I was clear: the choices about separating files into directories, partitions, disks, network shares, etc... have always been pretty obvious to anybody with a minimum of common sense. The only way around them is foolishness or ignorance (or both). I can understand a newcomer, using a computer for his/her petty games one task at a time and not doing much, to believe the world would be simpler if it (or the filesystem) were flat and suited to his unvoiced personal expectations. This is nothing new, the machine language opcode RPM (read programmer's mind) is as old a joke as I can remember. There was a reason to separate user data from system data to avoid the system disk from becoming unusable by a misbehaving user. There was one to separate /tmp for the same reason (a buggy program might generate a huge temporary file and render the system unusable for all other users). Same for /var and out of control log files. When vendors started adding their software in /usr (and maintaining it) there ceased to be a standard, well known set of "reserved system program names" and it made sense to separate /usr/local for non-vendor maintained files which might have an unknown naming conflict (and I witnessed many at the time, not the less GNU) with "non-standard-UNIX" vendor additions. When LANs started to be common it made sense to share as many files as possible, and since executables would not be shareable on an heterogeneous network (something most newcomers have never experienced -or fancied) it became sensible to have /home and /usr/share separate and served over the network. When UNIX systems became more complex and started to take over mainframes and get many users, it made sense to separate system programs from user programs, and it didn't make sense to duplicate all of them: hence a /bin for programs common to users and admins, and a /sbin for just admins (for standard system commands) and a /usr/bin and /usr/sbin (for vendor maintained commands and system daemons) and a /usr/local/bin and a /usr/local/sbin (for locally added commands and system tools and daemons). /lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to ensure user programs keep on running after a system upgrade and cleanup. I often try to keep relevant packages in their own directory and run an automated ldd to save in their own .../lib their shared libraries before doing an upgrade. There are binaries that haven't been updated since the '90s and require very old libraries (or even worst, complex sources that require various versions of the GCC toolchain). It doesn't make sense to port them, it's easier to ensure they keep on running keeping their libraries. And so on. And many of these arguments might hold today. One might argue that since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP, or whomever) one no longer needs separate / and /usr spaces. The problem is that would only work for newbies and occasional users, but would fail for most other cases (large computing servers and multiuser shops as well as tiny embedded devices, as pointed out). So, as long as systems are shipped to run on any machine, the layout should be versatile enough to accommodate all uses. Hence the need for maintaining these conventions, not legacy or bureaucracy. What is shortsighted is to expect all use-cases to be like a home user who only runs one game or, at most, his/her word-processor, e-mail and navigator simultaneously. Beyond that, the original articles and comments complained also about directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in what way is it easier for someone new to a computer to learn a "/bin /etc /var /lib" alien terminology and what it means, than to learn "System Config Libraries etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The point is one needs to learn them and if you are familiar with one terminology then to map terms, and if we are to use a standard, at least POSIX is one. That said, I often place everything (but /boot) in a single partition for single-user machines (except for power users who usually demand at least separate /tmp and /home) and there is nothing to prevent one from making symlinks (er, aliases for Windowers) to system directories with whatever names you like. And I still see a need to separate the system from vendor files and from user files (like, e.g. when you later want to switch from say RedHat to Debian). Only a moron would ignore the risk of system files left around by vendor-specific naming conventions. I said originally I could rant on and on. And I can. And add lots of anecdotes, but I'll leave it here. Sorry. Couldn't resist. j -- EMBnet/CNB Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es http://www.es.embnet.org From ron at ronnatalie.com Sat Feb 4 02:06:13 2012 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 3 Feb 2012 11:06:13 -0500 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120203162216.504c4bb7@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> <20120203162216.504c4bb7@cnb.csic.es> Message-ID: On Feb 3, 2012, at 10:22 AM, Jose R. Valverde wrote: > > There was a reason to separate user data from system data to avoid > the system disk from becoming unusable by a misbehaving user. But this wasn't practically done in the early UNIX. Even much that was in /usr was required for normal system operation and there was stuff that got left on the root that was within the user's ability to hose up. I was system administrator of a V6 UNIX that was used in a University setting in the late 70's. People banging on the disks was the least of my issues. There were far more fun ways to crash UNIX (and even PDP-11's in general), break security, etc... that I ran around trying to forestall. In fact our /usr was on the root disk. We had two "user" home directory drives /sys1 and /sys2 on two more RK05's. My first quota as a student was 8 blocks (4K). I supplemented that at first with a dectape (half a megabyte) and then with my own RK05 pack (we reserved two drives for user mounted volumes). We swapped to an RF11 fixed head disk of about a megabyte. The fun one was people trying to ascribe meanings to the "acronyms" on the kernel disk (KEN and DMR). From lyricalnanoha at usotsuki.hoshinet.org Sat Feb 4 02:09:08 2012 From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas) Date: Fri, 3 Feb 2012 17:09:08 +0100 (CET) Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120203162216.504c4bb7@cnb.csic.es> References: <20120201121214.55c73577@cnb.csic.es> <4F2A907D.9000000@fastmail.us> <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com> <20120202173623.GQ30634@mercury.ccil.org> <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com> <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org> <20120203162216.504c4bb7@cnb.csic.es> Message-ID: On Fri, 3 Feb 2012, Jose R. Valverde wrote: (snipping) > There was a reason to separate user data from system data to avoid > the system disk from becoming unusable by a misbehaving user. There was one > to separate /tmp for the same reason (a buggy program might generate a huge > temporary file and render the system unusable for all other users). Same for > /var and out of control log files. When vendors started adding their software > in /usr (and maintaining it) there ceased to be a standard, well known set > of "reserved system program names" and it made sense to separate /usr/local > for non-vendor maintained files which might have an unknown naming conflict > (and I witnessed many at the time, not the less GNU) with "non-standard-UNIX" > vendor additions. When LANs started to be common it made sense to share as > many files as possible, and since executables would not be shareable on an > heterogeneous network (something most newcomers have never experienced -or > fancied) it became sensible to have /home and /usr/share separate and served > over the network. When UNIX systems became more complex and started to take > over mainframes and get many users, it made sense to separate system programs > from user programs, and it didn't make sense to duplicate all of them: hence > a /bin for programs common to users and admins, and a /sbin for just admins > (for standard system commands) and a /usr/bin and /usr/sbin (for vendor > maintained commands and system daemons) and a /usr/local/bin and a > /usr/local/sbin (for locally added commands and system tools and daemons). > /lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to > ensure user programs keep on running after a system upgrade and cleanup. > I often try to keep relevant packages in their own directory and run an > automated ldd to save in their own .../lib their shared libraries before > doing an upgrade. There are binaries that haven't been updated since the > '90s and require very old libraries (or even worst, complex sources that > require various versions of the GCC toolchain). It doesn't make sense to > port them, it's easier to ensure they keep on running keeping their libraries. > And so on. > > And many of these arguments might hold today. One might argue that > since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP, > or whomever) one no longer needs separate / and /usr spaces. The problem > is that would only work for newbies and occasional users, but would fail > for most other cases (large computing servers and multiuser shops as well > as tiny embedded devices, as pointed out). So, as long as systems are shipped > to run on any machine, the layout should be versatile enough to accommodate > all uses. Hence the need for maintaining these conventions, not legacy or > bureaucracy. What is shortsighted is to expect all use-cases to be like a > home user who only runs one game or, at most, his/her word-processor, > e-mail and navigator simultaneously. > > Beyond that, the original articles and comments complained also about > directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in > what way is it easier for someone new to a computer to learn a "/bin /etc /var > /lib" alien terminology and what it means, than to learn "System Config Libraries > etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The > point is one needs to learn them and if you are familiar with one terminology > then to map terms, and if we are to use a standard, at least POSIX is one. > > That said, I often place everything (but /boot) in a single partition > for single-user machines (except for power users who usually demand at least > separate /tmp and /home) and there is nothing to prevent one from making symlinks > (er, aliases for Windowers) to system directories with whatever names you like. > And I still see a need to separate the system from vendor files and from user > files (like, e.g. when you later want to switch from say RedHat to Debian). Only > a moron would ignore the risk of system files left around by vendor-specific > naming conventions. > > I said originally I could rant on and on. And I can. And add lots of > anecdotes, but I'll leave it here. > > Sorry. Couldn't resist. > > j > > Actually, I tend to think the bare minimum to get the system running goes in /bin, /sbin and /lib, the rest of the base in /usr/bin, /usr/lib, /usr/include and /usr/sbin ... and all installed apps really ought to be in trees off /opt (although that would break stuff that expects X in /usr/X11R6/bin if I put it in /opt/X11 instead). But that's just my own opinion. -uso. From pepe at naleco.com Sun Feb 5 05:34:17 2012 From: pepe at naleco.com (Pepe) Date: Sat, 4 Feb 2012 20:34:17 +0100 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Message-ID: <000901cce373$fc2e2ad0$50651bac@naleco.com> "Jose R. Valverde" said: > Beyond that, the original articles and comments complained also about > directory naming (/bin /etc /lib) as "unintuitive". I fail to > understand in > what way is it easier for someone new to a computer to learn a "/bin > /etc /var /lib" alien terminology and what it means, than to learn > "System Config Libraries > etc..." or "Windows Windows32 Windows64 Temp Users and Settings, > etc..." In SCO Xenix/UNIX, the home directory is usually mounted on /u. I was amused the first time I saw it. From lyndon at orthanc.ca Sun Feb 5 07:05:03 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 4 Feb 2012 13:05:03 -0800 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <000901cce373$fc2e2ad0$50651bac@naleco.com> References: <000901cce373$fc2e2ad0$50651bac@naleco.com> Message-ID: <944F79B5-F88C-42EF-A73D-10DDDE0F2987@orthanc.ca> On 2012-02-04, at 11:34 AM, Pepe wrote: > In SCO Xenix/UNIX, the home directory is usually mounted on /u. > > I was amused the first time I saw it. The /u convention was a common site convention in at least the early 1980s. I don't recall a vendor using it as a default in any shipping system, though. Mind you, I have blissfully forgotten most of my follies with Xenix. --lyndon From hjt at ATComputing.nl Sun Feb 5 18:38:00 2012 From: hjt at ATComputing.nl (Hendrik Jan Thomassen) Date: Sun, 5 Feb 2012 09:38:00 +0100 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split Message-ID: <20120205083800.GA12910@vcursdoc.atcomputing.nl> If I recall well the /sbin directory first appeared in HP/UX, and the name stood for 'Static binaries'. Its reason for existence was that with the introduction of shared libraries the file with the C-library had become a single point of failure. Therefore this sbin was introduced to hold Statically linked executables for the most important commands needed to fix a broken system (sh, ls, mv, cp, find, tar, fsck etcetera). With this directory earlier than /bin in his PATH the administrator could at least restore a working libc.so file. And, while we are at it, the name 'executable' was not commonly used: they were called 'binaries' (except in IBM mainframe terminology were they were called 'load modules'). Only much later the habit of /sbin = System binaries emerged. An important reason to split /bin vs. /usr/bin and /lib vs. /usr/lib etc. was that the root file system had to be kept small. The fsck program, while at work, builds tables. If possible, they stay in memory, but if memory runs out fsck writes them to disk. However, you don't want them to be written to an untrusted/unchecked file system, and certainly not to the file system currently under repair. Since the root file system has to be checked before the others, it had to be small enough so ensure that fsck could run memory-based only. Therefore: the /bin, /lib and other root-fs based directories held the minimal stuff needed for booting and for repairs/restores, while all the rest had to go into the "overflow" directories /usr/bin, /usr/lib etc (and, obviously, /usr was a separately mounted partition). Remember: those were the days that every reboot included a full fsck on all your partitions. -- Hendrik-Jan Thomassen AT Computing 6546 BE Nijmegen NL Fax +31 24 352 72 92 info at atcomputing.nl www.atcomputing.nl 'If you think education is expensive, then try ignorance.' From jaapna at xs4all.nl Sun Feb 5 20:13:50 2012 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sun, 5 Feb 2012 11:13:50 +0100 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120205083800.GA12910@vcursdoc.atcomputing.nl> References: <20120205083800.GA12910@vcursdoc.atcomputing.nl> Message-ID: <3FFAC15F-C8C4-4B7E-B4F5-679652F907FF@xs4all.nl> On Feb 5, 2012, at 9:38, Hendrik Jan Thomassen wrote: > Remember: those were the days that every reboot included a full > fsck on all your partitions. And before such a modern tool as fsck came one used icheck/ncheck/clri to fix broken file systems. Ah, those were the days ... jaap From imp at bsdimp.com Mon Feb 6 03:15:15 2012 From: imp at bsdimp.com (Warner Losh) Date: Sun, 5 Feb 2012 10:15:15 -0700 Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split In-Reply-To: <20120205083800.GA12910@vcursdoc.atcomputing.nl> References: <20120205083800.GA12910@vcursdoc.atcomputing.nl> Message-ID: On Feb 5, 2012, at 1:38 AM, Hendrik Jan Thomassen wrote: > If I recall well the /sbin directory first appeared in HP/UX, > and the name stood for 'Static binaries'. Do you recall when this was? 4.3-RENO has the bin/sbin split, and that was 1990, but the split isn't yet in 4.3-Tahoe, which was in 1988. In 4.3-RENO it was already system binaries since 4.3 didn't have shared libraries, at least according to the TUHS 4.3-RENO archive http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/share/man/man7/hier.7 I don't have a copy of the BSD SCCS trees to narrow the split down further... Perhaps this indicates multiple invention? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Feb 21 06:30:35 2012 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 21 Feb 2012 06:30:35 +1000 Subject: [TUHS] Yet Another Kernel Description Document Message-ID: <20120220203034.GA10432@minnie.tuhs.org> All, I've just received from Poul-Henning Kamp a document entitled "UNIX Program Description", dated January 1976 and written by the UNIX Support Group. It contains detailed descriptions of the functions inside a Unix kernel. Given the date and the USG origin, I'm guessing that the system described is PWB/1.0. Can anybody confirm this at all? The URL is http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_description_jan_1976.pdf but I'll move it if it turns out not to be about PWB. I love how new documents and artifacts keep appearing! Thanks phk. Cheers, Warren From arnold at skeeve.com Tue Feb 21 06:52:36 2012 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Feb 2012 12:52:36 -0800 Subject: [TUHS] why the leading under score added to function names? Message-ID: <201202202052.q1KKqagi002055@freefriends.org> Hi All. Recently at work I helped someone figure out that when working with ld, the name of a function "foo" gets turned into "_foo" by the compiler. (It took this old-timer 15 minutes to solve a problem he had been working on for two days!) I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". Why did the C compiler prepend an underscore to function names? Thanks, Arnold From dave at horsfall.org Tue Feb 21 09:21:41 2012 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 21 Feb 2012 10:21:41 +1100 (EST) Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <201202202052.q1KKqagi002055@freefriends.org> References: <201202202052.q1KKqagi002055@freefriends.org> Message-ID: On Mon, 20 Feb 2012, arnold at skeeve.com wrote: [...] > I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". > Why did the C compiler prepend an underscore to function names? Sure was the PDP-11 :-) I vaguely recall that it was to make sure that user functions did not conflict with predefined assembler functions, as that would be a pain to diagnose (much like having swap overlap root). -- Dave From brantley at coraid.com Tue Feb 21 10:34:26 2012 From: brantley at coraid.com (Brantley Coile) Date: Mon, 20 Feb 2012 18:34:26 -0600 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202202052.q1KKqagi002055@freefriends.org> Message-ID: <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> correct. we could link to assembler code with _entry points and not worry about symbol collisions in the rest of the code. iPhone email On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" wrote: > On Mon, 20 Feb 2012, arnold at skeeve.com wrote: > > [...] > >> I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". >> Why did the C compiler prepend an underscore to function names? > > Sure was the PDP-11 :-) I vaguely recall that it was to make sure that > user functions did not conflict with predefined assembler functions, as > that would be a pain to diagnose (much like having swap overlap root). > > -- Dave > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs From a.phillip.garcia at gmail.com Tue Feb 21 11:50:09 2012 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Mon, 20 Feb 2012 19:50:09 -0600 Subject: [TUHS] Yet Another Kernel Description Document In-Reply-To: <20120220203034.GA10432@minnie.tuhs.org> References: <20120220203034.GA10432@minnie.tuhs.org> Message-ID: nice. any details on the provenance, like those you shared regarding the 1st edition kernel documents a couple months ago? On 2/20/12, Warren Toomey wrote: > All, I've just received from Poul-Henning Kamp a document entitled > "UNIX Program Description", dated January 1976 and written by the > UNIX Support Group. It contains detailed descriptions of the functions > inside a Unix kernel. Given the date and the USG origin, I'm guessing > that the system described is PWB/1.0. Can anybody confirm this at all? > > The URL is > http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_description_jan_1976.pdf > but I'll move it if it turns out not to be about PWB. > > I love how new documents and artifacts keep appearing! Thanks phk. > > Cheers, > Warren > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > From wkt at tuhs.org Tue Feb 21 11:53:27 2012 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 21 Feb 2012 11:53:27 +1000 Subject: [TUHS] Yet Another Kernel Description Document In-Reply-To: References: <20120220203034.GA10432@minnie.tuhs.org> Message-ID: <20120221015327.GA8313@minnie.tuhs.org> On Mon, Feb 20, 2012 at 07:50:09PM -0600, A. P. Garcia wrote: > nice. any details on the provenance, like those you shared regarding > the 1st edition kernel documents a couple months ago? Unfortunately, no. phk can't remember exactly where he got the document, but he is trying to jog his memory :) Cheers, Warren From imp at bsdimp.com Tue Feb 21 12:50:00 2012 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Feb 2012 19:50:00 -0700 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> References: <201202202052.q1KKqagi002055@freefriends.org> <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> Message-ID: And this convention went away with ELF binaries. No more _foo for function foo. Also, the fortran compiler would emit entry_ to as to not conflict either. Made calling C from Fortran, and vice versa, a lot of fun... Warner On Feb 20, 2012, at 5:34 PM, Brantley Coile wrote: > correct. we could link to assembler code with _entry points and not worry about symbol collisions in the rest of the code. > > iPhone email > > On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" wrote: > >> On Mon, 20 Feb 2012, arnold at skeeve.com wrote: >> >> [...] >> >>> I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". >>> Why did the C compiler prepend an underscore to function names? >> >> Sure was the PDP-11 :-) I vaguely recall that it was to make sure that >> user functions did not conflict with predefined assembler functions, as >> that would be a pain to diagnose (much like having swap overlap root). >> >> -- Dave >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > > From cowan at mercury.ccil.org Tue Feb 21 13:33:39 2012 From: cowan at mercury.ccil.org (John Cowan) Date: Mon, 20 Feb 2012 22:33:39 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202202052.q1KKqagi002055@freefriends.org> <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> Message-ID: <20120221033339.GA11143@mercury.ccil.org> Warner Losh scripsit: > Also, the fortran compiler would emit entry_ to as to not conflict > either. Made calling C from Fortran, and vice versa, a lot of fun... Unix f77 emitted _foo_, that is, what C saw as foo_. In effect you could call arbitrary Fortran routines from C, but not really vice versa: in order to do so, the C functions had to have names ending in _ and use the f77 type system. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan at ccil.org isn't a man. --Jewish saying From lyricalnanoha at usotsuki.hoshinet.org Tue Feb 21 13:41:38 2012 From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas) Date: Tue, 21 Feb 2012 04:41:38 +0100 (CET) Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202202052.q1KKqagi002055@freefriends.org> <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> Message-ID: On Mon, 20 Feb 2012, Warner Losh wrote: > And this convention went away with ELF binaries. No more _foo for > function foo. > > Also, the fortran compiler would emit entry_ to as to not conflict > either. Made calling C from Fortran, and vice versa, a lot of fun... > > Warner Watcom C did the postfix style, dunno if it still does. -uso. From ron at ronnatalie.com Wed Feb 22 04:18:59 2012 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Tue, 21 Feb 2012 13:18:59 -0500 (EST) Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202202052.q1KKqagi002055@freefriends.org> <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com> Message-ID: <61309.20.132.68.147.1329848339.squirrel@webmail.tuffmail.net> An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Feb 23 05:17:28 2012 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Feb 2012 11:17:28 -0800 Subject: [TUHS] why the leading under score added to function names? Message-ID: <201202221917.q1MJHSGw013561@freefriends.org> Hi All. This is interesting. It shows that (apparently) early on, assembler was viewed as the primary programming language. It also shows the consequences a small, apparently local decision can have: here we are 40+ years later and GCC on Windows is still preprending underscores to function names! In 15 minutes I helped the guy at work solve a problem he'd been working on for two days! Thanks everyone, Arnold > From: Brantley Coile > To: Dave Horsfall > Date: Mon, 20 Feb 2012 18:34:26 -0600 > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] why the leading under score added to function names? > > correct. we could link to assembler code with _entry points and not i> worry about symbol collisions in the rest of the code. > > iPhone email > > On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" wrote: > > > On Mon, 20 Feb 2012, arnold at skeeve.com wrote: > > > > [...] > > > >> I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". > >> Why did the C compiler prepend an underscore to function names? > > > > Sure was the PDP-11 :-) I vaguely recall that it was to make sure that > > user functions did not conflict with predefined assembler functions, as > > that would be a pain to diagnose (much like having swap overlap root). > > > > -- Dave From dave at horsfall.org Thu Feb 23 07:22:17 2012 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 23 Feb 2012 08:22:17 +1100 (EST) Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <201202221917.q1MJHSGw013561@freefriends.org> References: <201202221917.q1MJHSGw013561@freefriends.org> Message-ID: On Wed, 22 Feb 2012, arnold at skeeve.com wrote: > This is interesting. It shows that (apparently) early on, assembler was > viewed as the primary programming language. Well, C didn't exactly spring from Zeus's brow :-) A good chunk of the C library was in assembler, as were quite a number of programs. > It also shows the consequences a small, apparently local decision can have: > here we are 40+ years later and GCC on Windows is still preprending > underscores to function names! When it comes to Windoze, nothing surprises me any more. Unix has evolved over the years, but Windoze was spat out and hatched. -- Dave From a.phillip.garcia at gmail.com Thu Feb 23 08:47:29 2012 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 22 Feb 2012 16:47:29 -0600 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202221917.q1MJHSGw013561@freefriends.org> Message-ID: On Wed, Feb 22, 2012 at 3:22 PM, Dave Horsfall wrote: > On Wed, 22 Feb 2012, arnold at skeeve.com wrote: > > > This is interesting. It shows that (apparently) early on, assembler was > > viewed as the primary programming language. > > Well, C didn't exactly spring from Zeus's brow :-) A good chunk of the > C library was in assembler, as were quite a number of programs. > relevant: http://cm.bell-labs.com/who/dmr/hist.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu Feb 23 14:30:21 2012 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 23 Feb 2012 15:30:21 +1100 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: References: <201202221917.q1MJHSGw013561@freefriends.org> Message-ID: <20120223043021.GA72269@dereel.lemis.com> On Thursday, 23 February 2012 at 8:22:17 +1100, Dave Horsfall wrote: > On Wed, 22 Feb 2012, arnold at skeeve.com wrote: >> It also shows the consequences a small, apparently local decision >> can have: here we are 40+ years later and GCC on Windows is still >> preprending underscores to function names! > > When it comes to Windoze, nothing surprises me any more. Unix has > evolved over the years, but Windoze was spat out and hatched. I'm no friend of Microsoft either, but gcc isn't exactly Microsoft. What Arnold mentions here is Unix history in action. Greg -- Sent from my desktop computer Finger grog at FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From spedraja at gmail.com Thu Feb 23 18:18:43 2012 From: spedraja at gmail.com (Sergio Pedraja) Date: Thu, 23 Feb 2012 08:18:43 +0000 (UTC) Subject: [TUHS] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?= Message-ID: <1148794579.6426880.1329985123763.JavaMail.app@ela4-bed82.prod> LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-9arw1o-gyzisxbk-15/isd/6035309375/9Ym-js9F/?hs=false&tok=1RpwAbuU2ieR81 -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-9arw1o-gyzisxbk-15/_SZkCeK7HqzqROuy9YxIdtKYnud5RcPs/goo/TUHS%40minnie%2Etuhs%2Eorg/20061/I2097818075_1/?hs=false&tok=1vGDnY_cmieR81 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spedraja at gmail.com Thu Feb 23 18:18:49 2012 From: spedraja at gmail.com (Sergio Pedraja) Date: Thu, 23 Feb 2012 08:18:49 +0000 (UTC) Subject: [TUHS] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?= Message-ID: <483977762.21368179.1329985129840.JavaMail.app@ela4-bed81.prod> LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-amg4ei-gyzit20d-4/isd/6035310080/f1t_FAOT/?hs=false&tok=2oSTjszkSieR81 -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-amg4ei-gyzit20d-4/IES2kw2WbAK2tgMLcf1q-MI/goo/tuhs%40tuhs%2Eorg/20061/I2097818448_1/?hs=false&tok=27FHkZoUeieR81 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.us Sun Feb 26 04:45:23 2012 From: random832 at fastmail.us (Random832) Date: Sat, 25 Feb 2012 13:45:23 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <20120223043021.GA72269@dereel.lemis.com> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> Message-ID: <4F492C43.3020602@fastmail.us> On 2/22/2012 11:30 PM, Greg 'groggy' Lehey wrote: > On Thursday, 23 February 2012 at 8:22:17 +1100, Dave Horsfall wrote: >> On Wed, 22 Feb 2012, arnold at skeeve.com wrote: >>> It also shows the consequences a small, apparently local decision >>> can have: here we are 40+ years later and GCC on Windows is still >>> preprending underscores to function names! >> When it comes to Windoze, nothing surprises me any more. Unix has >> evolved over the years, but Windoze was spat out and hatched. > I'm no friend of Microsoft either, but gcc isn't exactly Microsoft. > What Arnold mentions here is Unix history in action. > Yes and no. IIRC, gcc doesn't do that on, for example, Linux ELF. it's done on windows, I assume, in deference to the windows 32-bit ABI for cdecl calling convention functions. Now, as far as where windows gets that from (just because something evolved within one company doesn't mean it didn't evolve), supposedly early versions of Microsoft C (pre-ANSI) were very conservative in terms of adhering to the "standard" set by Unix C and K&R - this could have extended to the prepending of underscores. For instance, this is, according to Raymond Chen, why they added WinMain rather than extending main (they didn't know if extensions to main would be allowed). I would also guess it's why MSVC stdio is implemented on top of an imitation of Unix system calls which is in turn implemented on top of DOS/windows; and why MSVC time_t is defined as seconds since 1970. There are comments in the code referring to XENIX in various places relating to I/O and timestamps, so it's possible that MSVC's C library was indeed, to some small degree, based on Unix. From lyricalnanoha at usotsuki.hoshinet.org Sun Feb 26 05:24:40 2012 From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas) Date: Sat, 25 Feb 2012 20:24:40 +0100 (CET) Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <4F492C43.3020602@fastmail.us> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> <4F492C43.3020602@fastmail.us> Message-ID: On Sat, 25 Feb 2012, Random832 wrote: > On 2/22/2012 11:30 PM, Greg 'groggy' Lehey wrote: >> On Thursday, 23 February 2012 at 8:22:17 +1100, Dave Horsfall wrote: >>> On Wed, 22 Feb 2012, arnold at skeeve.com wrote: >>>> It also shows the consequences a small, apparently local decision >>>> can have: here we are 40+ years later and GCC on Windows is still >>>> preprending underscores to function names! >>> When it comes to Windoze, nothing surprises me any more. Unix has >>> evolved over the years, but Windoze was spat out and hatched. >> I'm no friend of Microsoft either, but gcc isn't exactly Microsoft. >> What Arnold mentions here is Unix history in action. >> > Yes and no. IIRC, gcc doesn't do that on, for example, Linux ELF. it's done > on windows, I assume, in deference to the windows 32-bit ABI for cdecl > calling convention functions. > > Now, as far as where windows gets that from (just because something evolved > within one company doesn't mean it didn't evolve), supposedly early versions > of Microsoft C (pre-ANSI) were very conservative in terms of adhering to the > "standard" set by Unix C and K&R - this could have extended to the prepending > of underscores. For instance, this is, according to Raymond Chen, why they > added WinMain rather than extending main (they didn't know if extensions to > main would be allowed). I would also guess it's why MSVC stdio is implemented > on top of an imitation of Unix system calls which is in turn implemented on > top of DOS/windows; and why MSVC time_t is defined as seconds since 1970. > There are comments in the code referring to XENIX in various places relating > to I/O and timestamps, so it's possible that MSVC's C library was indeed, to > some small degree, based on Unix. Though DOS's file i/o calls, starting in 2.0, were much the same as Unix's already. Its open, close, read, write have the same basic semantics and at one point it was possible to have DOS require a syntax like \dev\con for devices. -uso. From cowan at mercury.ccil.org Sun Feb 26 06:39:59 2012 From: cowan at mercury.ccil.org (John Cowan) Date: Sat, 25 Feb 2012 15:39:59 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <4F492C43.3020602@fastmail.us> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> <4F492C43.3020602@fastmail.us> Message-ID: <20120225203959.GE29866@mercury.ccil.org> Random832 scripsit: > For instance, this is, according to Raymond Chen, why they added > WinMain rather than extending main (they didn't know if extensions to > main would be allowed). That doesn't sound very reasonable to me. When you link a Windows program, it still has a main() procedure provided by Windows which does setup and then invokes WinMain(). > so it's possible that MSVC's C library was indeed, to some small > degree, based on Unix. Without doubt. After all, there was no other source of C libraries before ANSI; compare the Whitesmiths library, which was "meticulously incompatibled". -- Samuel Johnson on playing the violin: John Cowan "Difficult do you call it, Sir? cowan at ccil.org I wish it were impossible." http://www.ccil.org/~cowan From random832 at fastmail.us Sun Feb 26 08:15:32 2012 From: random832 at fastmail.us (Random832) Date: Sat, 25 Feb 2012 17:15:32 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <20120225203959.GE29866@mercury.ccil.org> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> <4F492C43.3020602@fastmail.us> <20120225203959.GE29866@mercury.ccil.org> Message-ID: <4F495D84.8030206@fastmail.us> I'm going to need to train myself to use the "reply to list" button. Though in this case I think part of the problem was duplicate-filtering which lost the copy that had the appropriate header. On 2/25/2012 3:39 PM, John Cowan wrote: > Random832 scripsit: > >> For instance, this is, according to Raymond Chen, why they added >> WinMain rather than extending main (they didn't know if extensions to >> main would be allowed). > That doesn't sound very reasonable to me. When you link a Windows > program, it still has a main() procedure provided by Windows which does > setup and then invokes WinMain(). This is not true in my experience. If it was ever true, it's not true today (with MSVC, anyway. GCC may be different, but if there is a 'system-provided main()' it's GCC, or cygwin or mingw, and not anything from microsoft, that is providing it). The procedure "provided by windows" (provided by MSVC, actually) that does that is in fact called WinMainCRTStartup. When you link a windows _console_ program, a different function (called mainCRTStartup) which does the same setup (plus opening a console if none is open and setting up stdio which the WinMain version doesn't) and then invokes main(). The startup function is an interesting read - it has more work to do on windows than the unix equivalent, because systems like signals (which are in ANSI), file descriptor based I/O (which is not ANSI but nevertheless is implemented in MSVC), and such, that are "naturally occuring" on unix have to be set up. The whole program executes in a __try/__except block to allow them to make signals work, for example. From ron at ronnatalie.com Sun Feb 26 23:28:36 2012 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 26 Feb 2012 08:28:36 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <4F495D84.8030206@fastmail.us> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> <4F492C43.3020602@fastmail.us> <20120225203959.GE29866@mercury.ccil.org> <4F495D84.8030206@fastmail.us> Message-ID: <29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com> On Feb 25, 2012, at 5:15 PM, Random832 wrote: >> > > This is not true in my experience. If it was ever true, it's not true > today (with MSVC, anyway. GCC may be different, but if there is a > 'system-provided main()' it's GCC, or cygwin or mingw, and not anything > from microsoft, that is providing it). The procedure "provided by > windows" (provided by MSVC, actually) that does that is in fact called > WinMainCRTStartup. WinMainCRTStartup isn't the replacement for main. It's the replacement for begin or location zero back in the old days. (Anybody remember seeing p&P6 printed by errant programs?). There are different versions of that CRT startup (actually all compiled from the same module with ifdefs) that start: main - for non-MFC console apps wmain - same thing but with wchar_t arguments (SOMETHING C/C++ standards hasn't ever addressed to my satisfaction). WinMain - MFC main function wWinMain - Ditto, with wchar_t Actually the bulk of the CRT involves converting between the command line argument as a string and argc/argv (something UNIX does by the OS), and some gook necessary to support C++. The fake UNIX environment (POSIX) (read/write/seek, etc...) actually is NOT initialized here, but when it is actually referenced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.us Mon Feb 27 11:30:45 2012 From: random832 at fastmail.us (random832 at fastmail.us) Date: Sun, 26 Feb 2012 20:30:45 -0500 Subject: [TUHS] why the leading under score added to function names? In-Reply-To: <29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com> References: <201202221917.q1MJHSGw013561@freefriends.org> <20120223043021.GA72269@dereel.lemis.com> <4F492C43.3020602@fastmail.us> <20120225203959.GE29866@mercury.ccil.org> <4F495D84.8030206@fastmail.us> <29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com> Message-ID: <1330306245.13843.140661041668049@webmail.messagingengine.com> On Sun, Feb 26, 2012, at 08:28, Ronald Natalie wrote: > > WinMainCRTStartup isn't the replacement for main. I never said it was. My point was that there is no "main" anywhere in a program that starts with WinMain, whereas John Cowan claimed that a "main" exists in such programs which does the things that WinMainCRTStartup in fact does. > main - for non-MFC console apps > wmain - same thing but with wchar_t arguments (SOMETHING C/C++ standards > hasn't ever addressed to my satisfaction). I suspect this is partly because the unix world is a multibyte world, and POSIX has "filenames don't have to be valid in any character set, they're just bytes". But Windows never had a satisfactory solution to multibyte vs wide in pipes, either, anyway. > WinMain - MFC main function This existed long before MFC, I suspect. > wWinMain - Ditto, with wchar_t > > Actually the bulk of the CRT involves converting between the command line > argument as a string and argc/argv (something UNIX does by the OS), and > some gook necessary to support C++. Well, not "by the OS" per se. More like, the OS only supports passing argc/argv at any level, so the shell converts user-typed strings to argv. (A big gripe I have with the CRT is that its _spawn/_exec functions don't quote strings containing spaces/etc so they can be round-tripped by the CRT's argv initialization. And the argv code itself doesn't let you have "wildcards in strings without quotes, literal stars in strings with them", you have to choose between wildcards or not) > The fake UNIX environment (POSIX) (read/write/seek, etc...) actually is > NOT initialized here, but when it is actually referenced. mainCRTstartup does in fact call _ioinit() in the version I looked at. I don't recall if WinMainCRTstartup does or not, it's not in front of me now. -- Random832