Do you get off on being offensive, stupid or wrong? Since your post is all three, it's hard to tell.
I won't address "offensive", as that's a matter of the person offended. I'll ask about "wrong"; if shown not wrong, "stupid" would imply "right by accident".
So the three assertions made in the post to which you're responding are:
"This is an argument for why GCC is not modular, not compilers in general. For example, LLVM is highly modular."
"Different optimizations apply at different stages of compilation... you know when you have differing semantic information available to guide those optimizations!?!"
"Oh, and "reification" does not mean "steady refinement". Reification means "to make real"."
If the first is wrong, then there must be no modular compilers. Are you ready to make that assertion? If so, what supports that assertion?
If the second is wrong, what would "the absolute final stage" of compilation take as input - some intermediate representation, or generated code (as e.g. a peephole optimizer does)?
Yes, some CPUs separate the stack model into an Independent instruction or two applied to an arbitrary register. Yet no CPU has a kind of register or instruction that easily implements a closure's upvalues, nor any of the more esoteric concepts commonly found in functional languages.
So what about general-purpose registers makes it difficult for them to implement those concepts (by "[implement] a closure's upvalues" I presume you mean "implement a pointer to a collection of a closure's upvalues")?
All of this is perfectly compatible with the way real-world CPUs work, including their built-in hardware stacks.
...or their hardware that can be used to implement stacks. A lot of CPUs don't have "hardware stacks" (presumably meaning call stacks); the calling sequence used on the machine chooses one of the general-purpose registers to be a stack pointer (and might, or might not, have another register used as a frame pointer). Some CPUs might have instructions that manipulate one particular GPR in a stack-like fashion, so the instruction set is a bit biased towards using that particular register as a stack pointer.
Clearly, if we are having trouble "interpreting" the consitution using modern-day language, the answer is to look at the spirit and intentions of the founders.
...which still means interpreting the constitution based on what the founders said - and they might not always have stated things explicitly, so now you're interpreting that, as well.
For christ's sake, we are talking about the most expensive, most powerful government AND world empire (with military bases in some 150 countries) that has ever existed.
"Most expensive... government" only makes sense if you mean "per capita" or "as a fraction of GNP" or something such as that. It should not come as a complete surprise that the U. S. government spends more, on an absolute basis, than, say, the government of Luxembourg. Is the U.S. government really spending more per capita, or as a fraction of GNP, than any other government that exists or has ever existed?
1. Is it a correct thing to allow interpretation of Constitution?
...
The correct long term answer to items 1-7 is always a 'no', it cannot be a 'yes' under any circumstances
...which means you have a constitution that states things so precisely that it's impossible to draw more than one conclusion about what anything it says means. Do you have an example of such a constitution? (Hint: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries" is not part of such a constitution - what's a "limited Time"? This is not, BTW, an idle question, given, for example, various Acts of Congress that keep extending the lifetime of copyrights.)
It ain't just those 2 things, but also the Posix compliance as well as the API's.
Yes, as I've noted several times when pointing out that, whilst Linux etc. might not be "Unixes" in the trademark sense, they're most definitely Un*xes in the "how you deal with them in real life" sense.
However, the point remains that, unless the "code in common" refers to software running *atop* those OSes rather than code *in* those OSes, there's not a huge amount of code in common between an AT&T-derived Unix and Linux, so it's not the "code in common" that makes Linux a Un*x.
I don't believe SPARC uses microcode (though I’m not sure in all cases, and I have seen the term 'microcode' used for some of the low-level instructions added for supporting hypervisors), but POWER certainly does. See e.g. "IBM POWER6 microarchitecture", IBM J. Res. & Dev. vol. 51 no. 6, November 2007.
Well, having spent USD 30 for the article (I miss the days when IBM JRD and IBM Systems Journal were available for free...) and saved it to disk (no way am I going to spend another USD 30 if I want to read it again!), and having scanned the stuff from "POWER6 chip physical overview" (just in case it mentions microcode storage) through "Error recovery", I didn't see any place where it implies that microcode is used (the only explicit use of the word "microcode", at least as far as Preview can find it, is in an author bio). What did I miss there?
Multics also had hexadecimal access control: read, execute, write, append.
But it didn't have "4 hexadecimal modes", it had ACLs - and, at least according to the 1975 Multics Programmer's Manual Reference Guide, they're read/execute/write/deny-everything for segments and status/modify/append/deny-everything for directories.
Nice piece. A bit incorrect about multiplexing as Burroughs had released the B-5500/5700 in 1966 that allowed multiple terminals and running the CANDE ( Command And Edit interface) allowed batch jobs and terminals to run simulatinously, unlike IBM computers of the day which were batch orietented for almost 10 years later.
...if you don't count the IBM System/360 Model 67 running either TSS or, more likely, CP/CMS (or third-party OSes such as the Michigan Terminal System, but you're presumably talking about OSes from the hardware vendor). (And it's more like "for almost 5 years later", given TSO, which showed up in 1971.)
But, yeah, it's not as if Multics invented time-sharing (that dates back to CTSS back in the early '60's) or even was the first commercially-sold time-sharing OS (the original PDP-6/PDP-10 time-sharing monitor came out in the mid '60's).
And they're not really selling "Android" the operating system - Google does that; they sell/offer it to their customers, who are, in this case, phone (and tablet) manufacturers. AT&T are selling phones that run Android (just as they sell phones that run iOS and Windows Phone).
I don't know whether AT&T or the phone manufacturer would be the ones responsible for providing support and/or bug fixes in this case.
Windows had to do this leap from dumb micro computer OS to a real OS also but it was a longer period of pain because they were too hesitant to break compatibility so the conversion happened piecemeal over time.
Presumably you mean "piecemeal" in the sense that it took Windows XP to kick the old "Windows OT" code base to the curb for mainstream users; it's not as if they replaced bits and pieces of "Windows OT" piecemeal from release to release - Windows NT 3.1 wasn't a "dumb micro computer OS", but it also wasn't the OS that shipped on most Windows PC that shipped at the time.
(Contrast this to Linux which "isn't UNIX" either, but makes a pretty damn good attempt at fooling most reasonable hackers).
And, as is the case on Mac OS X, but as isn't the case with Cygwin, the UN*X API is the native API for Linux; it's not an attempt at implementing a UN*X API atop an OS whose "native" API isn't UN*X.
And z/OS is certified Unix 95 but it's a layer atop an OS whose native API isn't UN*X, so "it's certifioed Unix 03" isn't a sufficient refutation. ("There is no "native API" atop which Mac OS X's UNIX API is implemented" is a sufficient refutation.)
I thought it was a Mach kernel and a BSD userland.
It's a kernel that consists of Mach plus BSD code plus IOKit, with the BSD code modified to let Mach handle platform-specific stuff, the lower levels of process/thread management, and paging and let IOKit handle talking to hardware. Except when doing stuff such as sending Mach messages, userland talks to the BSD code for system calls - process management, address-space management, file system operations, and network operations all involve system calls to the BSD layer even if the system call in question makes a lot of calls to the Mach layer (I'm not sure to what extent pthread operations go to Mach system calls arther than BSD system calls).
How exactly that's quintessentially different from me installed Cygwin on my Windows machine and calling it a Unix machine is beyond me.
It's because Cygwin sits atop the OS's main native API, Win32, and emulates UN*X as best it can, while libc, err, umm, libSystem on Mac OS X implements the lowest userland layer of the UN*X API and, when it needs to talk to the kernel, mostly does it with UN*X system calls (some places end up doing Mach messaging to processes such as DirectoryService/opendirectoryd or mDNSResponder), but there's no "native" API (either in the sense of Win32 on NT or the native NT API on NT) atop which the UN*X APIs are implemented. The only Mach APIs implemented for applications are things such as mach_msg() and stuff atop it such as MIG, but that's not really any "non-UNIXy" than, say, doors in Solaris.
There's so much code in common between Unix and Unix-like operating systems today
"Unix" can either refer to "the trademark and systems that have it" or to "the software released by AT&T". If you're referring to the latter, I'm not sure how much code is in common between, for example, AT&T Unix and a typical Linux distribution. Even if you're referring to the former, I'm not sure how much code is in common between, say, Solaris or AIX or HP-UX and a typical Linux distribution.
System I, I think System II got the "versions", then they "jumped" to System III, although many people allready had sidejumped to Berkeley.
But indeed it started with System, not versions, (but the "versions" made it popular:-))
Well, yeah, it started with "System", as in "The UNIX Time-sharing System". The document cited there is "Unix Programmer's Manual, First Edition", at least according to Dennis Ritchie's home page. I'm not sure Research UNIX had anything as formalized as "releases", as opposed to "what we have right now when we're making a UNIX tape", and I'm not sure that the "version numbers" applied to the operating system rather than to the manual.
There was no "System I" or "System II"; "System III" came from a line of UNIXes that combined Research stuff with the (based on something that looked like V6 with the "Phototypesetter, Version 6" enhancements and some other post-V6 stuff) first edition of PWB/UNIX and a bunch of other UNIXes inside AT&T.
Congratulations, you are the blind man holding the trunk of the elephant. Those other blind men you are responding to are holding a leg or a tail or an ear.
Actually, my eyes work quite well, and can see that there are a pile of different UN*X systems out there, which are similar in a lot of ways (a lot of core APIs, for example) and different in a lot of ways (system administration quirks, for example). If you focus on the parts that are most different, they're all weird in their own ways, with Mac OS X not necessarily being any worse than others (hey, at least ifconfig works the way it's supposed to); if you focus on the parts that are most similar, they're all close enough to call them UN*X.
I don't think there's an OS sold today whose name is just "Unix", so "[using] Unix" presumably means "using an operating system that has been certified as following the Single UNIX Specification"; which particular such OSes do you use every day?
Linux is better, because it has capabilities.
If by "capabilities" you mean stuff such as "POSIX capabilities" that means you don't just have "normal privilege" and "root privilege", Solaris (which is an operating system that has been certified as following the Single UNIX Specification) has them as well.
It still has the horribly limited and antique unix-style file/folder structures, though - three octal modes
As opposed to four hexadecimal modes?
Linux, and several other UN*Xes, also support access control lists, at least on some file systems, if that's what you're contrasting with "three octal modes". (Adding a "delete" privilege and a set of permission bits for what amounts to root, to get the four hexadecimal modes, isn't a huge change.)
I used to write systems and apps code on 64-bit computers with graphical UIs, language and context-sensitive IDEs, no root superuser, and automatic versioning filesystems. But that was back in the 1980s, before the black ships came and the secret of hose gartering that never ravels was forgotten.
So what 64-bit computers were those? (Presumably that means "64-bit address space"; "does 64-bit arithmetic in one instruction" is a lot less interesting.) System/38 and AS/400 had larger address spaces, but I think they had 48-bit address spaces until the PowerPC update. (I'm not talking about the 128-bit pointers, I'm talking about the address space available to the instructions that are executed by the machine rather than to the instructions translated into machine instructions.)
I miss VMS vaxen sometimes.
(Those, of course, weren't the 64-bit computers to which you were referring. OpenVMS Alphas were, but those didn't come out until the 1990's, and OpenVMS Itaniums are, but they didn't come out until even later. In any case, you've been talking about OS features, so VAX is irrelevant.)
Do you really consider Unix and Linux to be two separate things?
"Unix", as in "the registered trademark "Unix"", is separate from "Linux", meaning either the Linux kernel or the set (equivalence class?) of Linux distributions. To be legally eligible to be called a "Unix", an OS has to pass the Single UNIX Specification test suite; as far as I know, nobody's run any Linux distributions through that test suite.
However, Linux is most definitely a "Un*x", in that its API is a UNIX-derived API, even if it might not be able to check every single checkbox for the Single UNIX Specification.
And they also missed a line from SunOS 4 to SVR4; they showed it as a line from 4.3BSD instead. The SVR4 VM system and VFS layer came from SunOS 4.x, and the dynamic-linking mechanism, although changed a bit with the switch from a.out to ELF, also came from SunOS 4.x. Most of the BSDisms added to SVR4 also came from SunOS 4.x rather than directly from 4.3BSD.
Slashdot Mirror
Do you get off on being offensive, stupid or wrong? Since your post is all three, it's hard to tell.
I won't address "offensive", as that's a matter of the person offended. I'll ask about "wrong"; if shown not wrong, "stupid" would imply "right by accident".
So the three assertions made in the post to which you're responding are:
If the first is wrong, then there must be no modular compilers. Are you ready to make that assertion? If so, what supports that assertion?
If the second is wrong, what would "the absolute final stage" of compilation take as input - some intermediate representation, or generated code (as e.g. a peephole optimizer does)?
If the third is wrong, why should we prefer your use of "reify" to the one from the Oxford Dictionaries Web site?
Yes, some CPUs separate the stack model into an Independent instruction or two applied to an arbitrary register. Yet no CPU has a kind of register or instruction that easily implements a closure's upvalues, nor any of the more esoteric concepts commonly found in functional languages.
So what about general-purpose registers makes it difficult for them to implement those concepts (by "[implement] a closure's upvalues" I presume you mean "implement a pointer to a collection of a closure's upvalues")?
And Canada bows to an old lady that lives in the UK.
And you have the nerve to talk about thinking for yourself?
And the number of times Canada has been forced to do what Liz Windsor directly told them to do is?
All of this is perfectly compatible with the way real-world CPUs work, including their built-in hardware stacks.
...or their hardware that can be used to implement stacks. A lot of CPUs don't have "hardware stacks" (presumably meaning call stacks); the calling sequence used on the machine chooses one of the general-purpose registers to be a stack pointer (and might, or might not, have another register used as a frame pointer). Some CPUs might have instructions that manipulate one particular GPR in a stack-like fashion, so the instruction set is a bit biased towards using that particular register as a stack pointer.
GP has got it right. Parent is demonstrably wrong.
Parent was most likely trolling ("always has", for a language that started being developed in 1979 or so?), and you appear to have bitten the hook.
Clearly, if we are having trouble "interpreting" the consitution using modern-day language, the answer is to look at the spirit and intentions of the founders.
...which still means interpreting the constitution based on what the founders said - and they might not always have stated things explicitly, so now you're interpreting that, as well.
For christ's sake, we are talking about the most expensive, most powerful government AND world empire (with military bases in some 150 countries) that has ever existed.
"Most expensive ... government" only makes sense if you mean "per capita" or "as a fraction of GNP" or something such as that. It should not come as a complete surprise that the U. S. government spends more, on an absolute basis, than, say, the government of Luxembourg. Is the U.S. government really spending more per capita, or as a fraction of GNP, than any other government that exists or has ever existed?
1. Is it a correct thing to allow interpretation of Constitution?
...
The correct long term answer to items 1-7 is always a 'no', it cannot be a 'yes' under any circumstances
...which means you have a constitution that states things so precisely that it's impossible to draw more than one conclusion about what anything it says means. Do you have an example of such a constitution? (Hint: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries" is not part of such a constitution - what's a "limited Time"? This is not, BTW, an idle question, given, for example, various Acts of Congress that keep extending the lifetime of copyrights.)
It ain't just those 2 things, but also the Posix compliance as well as the API's.
Yes, as I've noted several times when pointing out that, whilst Linux etc. might not be "Unixes" in the trademark sense, they're most definitely Un*xes in the "how you deal with them in real life" sense.
However, the point remains that, unless the "code in common" refers to software running *atop* those OSes rather than code *in* those OSes, there's not a huge amount of code in common between an AT&T-derived Unix and Linux, so it's not the "code in common" that makes Linux a Un*x.
I don't believe SPARC uses microcode (though I’m not sure in all cases, and I have seen the term 'microcode' used for some of the low-level instructions added for supporting hypervisors), but POWER certainly does. See e.g. "IBM POWER6 microarchitecture", IBM J. Res. & Dev. vol. 51 no. 6, November 2007.
Well, having spent USD 30 for the article (I miss the days when IBM JRD and IBM Systems Journal were available for free...) and saved it to disk (no way am I going to spend another USD 30 if I want to read it again!), and having scanned the stuff from "POWER6 chip physical overview" (just in case it mentions microcode storage) through "Error recovery", I didn't see any place where it implies that microcode is used (the only explicit use of the word "microcode", at least as far as Preview can find it, is in an author bio). What did I miss there?
Multics also had hexadecimal access control: read, execute, write, append.
But it didn't have "4 hexadecimal modes", it had ACLs - and, at least according to the 1975 Multics Programmer's Manual Reference Guide, they're read/execute/write/deny-everything for segments and status/modify/append/deny-everything for directories.
Nice piece. A bit incorrect about multiplexing as Burroughs had released the B-5500/5700 in 1966 that allowed multiple terminals and running the CANDE ( Command And Edit interface) allowed batch jobs and terminals to run simulatinously, unlike IBM computers of the day which were batch orietented for almost 10 years later.
...if you don't count the IBM System/360 Model 67 running either TSS or, more likely, CP/CMS (or third-party OSes such as the Michigan Terminal System, but you're presumably talking about OSes from the hardware vendor). (And it's more like "for almost 5 years later", given TSO, which showed up in 1971.)
But, yeah, it's not as if Multics invented time-sharing (that dates back to CTSS back in the early '60's) or even was the first commercially-sold time-sharing OS (the original PDP-6/PDP-10 time-sharing monitor came out in the mid '60's).
'No advertising, no support, no bug fixes, payment in advance.'
No advertising?
And they're not really selling "Android" the operating system - Google does that; they sell/offer it to their customers, who are, in this case, phone (and tablet) manufacturers. AT&T are selling phones that run Android (just as they sell phones that run iOS and Windows Phone).
I don't know whether AT&T or the phone manufacturer would be the ones responsible for providing support and/or bug fixes in this case.
Windows had to do this leap from dumb micro computer OS to a real OS also but it was a longer period of pain because they were too hesitant to break compatibility so the conversion happened piecemeal over time.
Presumably you mean "piecemeal" in the sense that it took Windows XP to kick the old "Windows OT" code base to the curb for mainstream users; it's not as if they replaced bits and pieces of "Windows OT" piecemeal from release to release - Windows NT 3.1 wasn't a "dumb micro computer OS", but it also wasn't the OS that shipped on most Windows PC that shipped at the time.
(Contrast this to Linux which "isn't UNIX" either, but makes a pretty damn good attempt at fooling most reasonable hackers).
And, as is the case on Mac OS X, but as isn't the case with Cygwin, the UN*X API is the native API for Linux; it's not an attempt at implementing a UN*X API atop an OS whose "native" API isn't UN*X.
Well, OSX (at least 10.5 and 10.6) is certified Unix 03.
And z/OS is certified Unix 95 but it's a layer atop an OS whose native API isn't UN*X, so "it's certifioed Unix 03" isn't a sufficient refutation. ("There is no "native API" atop which Mac OS X's UNIX API is implemented" is a sufficient refutation.)
I thought it was a Mach kernel and a BSD userland.
It's a kernel that consists of Mach plus BSD code plus IOKit, with the BSD code modified to let Mach handle platform-specific stuff, the lower levels of process/thread management, and paging and let IOKit handle talking to hardware. Except when doing stuff such as sending Mach messages, userland talks to the BSD code for system calls - process management, address-space management, file system operations, and network operations all involve system calls to the BSD layer even if the system call in question makes a lot of calls to the Mach layer (I'm not sure to what extent pthread operations go to Mach system calls arther than BSD system calls).
How exactly that's quintessentially different from me installed Cygwin on my Windows machine and calling it a Unix machine is beyond me.
It's because Cygwin sits atop the OS's main native API, Win32, and emulates UN*X as best it can, while libc, err, umm, libSystem on Mac OS X implements the lowest userland layer of the UN*X API and, when it needs to talk to the kernel, mostly does it with UN*X system calls (some places end up doing Mach messaging to processes such as DirectoryService/opendirectoryd or mDNSResponder), but there's no "native" API (either in the sense of Win32 on NT or the native NT API on NT) atop which the UN*X APIs are implemented. The only Mach APIs implemented for applications are things such as mach_msg() and stuff atop it such as MIG, but that's not really any "non-UNIXy" than, say, doors in Solaris.
There's so much code in common between Unix and Unix-like operating systems today
"Unix" can either refer to "the trademark and systems that have it" or to "the software released by AT&T". If you're referring to the latter, I'm not sure how much code is in common between, for example, AT&T Unix and a typical Linux distribution. Even if you're referring to the former, I'm not sure how much code is in common between, say, Solaris or AIX or HP-UX and a typical Linux distribution.
System I, I think System II got the "versions", then they "jumped" to System III, although many people allready had sidejumped to Berkeley. But indeed it started with System, not versions, (but the "versions" made it popular :-))
Well, yeah, it started with "System", as in "The UNIX Time-sharing System". The document cited there is "Unix Programmer's Manual, First Edition", at least according to Dennis Ritchie's home page. I'm not sure Research UNIX had anything as formalized as "releases", as opposed to "what we have right now when we're making a UNIX tape", and I'm not sure that the "version numbers" applied to the operating system rather than to the manual.
There was no "System I" or "System II"; "System III" came from a line of UNIXes that combined Research stuff with the (based on something that looked like V6 with the "Phototypesetter, Version 6" enhancements and some other post-V6 stuff) first edition of PWB/UNIX and a bunch of other UNIXes inside AT&T.
Congratulations, you are the blind man holding the trunk of the elephant. Those other blind men you are responding to are holding a leg or a tail or an ear.
Actually, my eyes work quite well, and can see that there are a pile of different UN*X systems out there, which are similar in a lot of ways (a lot of core APIs, for example) and different in a lot of ways (system administration quirks, for example). If you focus on the parts that are most different, they're all weird in their own ways, with Mac OS X not necessarily being any worse than others (hey, at least ifconfig works the way it's supposed to); if you focus on the parts that are most similar, they're all close enough to call them UN*X.
We loaded a tape we "borrowed" from Pitt in '73 to a PDP-8. Now get off my lawn!
Not onto your PDP-8, you didn't. PDP-11, maybe.
Now get off my lawn. :-)
I use both every day.
I don't think there's an OS sold today whose name is just "Unix", so "[using] Unix" presumably means "using an operating system that has been certified as following the Single UNIX Specification"; which particular such OSes do you use every day?
Linux is better, because it has capabilities.
If by "capabilities" you mean stuff such as "POSIX capabilities" that means you don't just have "normal privilege" and "root privilege", Solaris (which is an operating system that has been certified as following the Single UNIX Specification) has them as well.
It still has the horribly limited and antique unix-style file/folder structures, though - three octal modes
As opposed to four hexadecimal modes?
Linux, and several other UN*Xes, also support access control lists, at least on some file systems, if that's what you're contrasting with "three octal modes". (Adding a "delete" privilege and a set of permission bits for what amounts to root, to get the four hexadecimal modes, isn't a huge change.)
I used to write systems and apps code on 64-bit computers with graphical UIs, language and context-sensitive IDEs, no root superuser, and automatic versioning filesystems. But that was back in the 1980s, before the black ships came and the secret of hose gartering that never ravels was forgotten.
So what 64-bit computers were those? (Presumably that means "64-bit address space"; "does 64-bit arithmetic in one instruction" is a lot less interesting.) System/38 and AS/400 had larger address spaces, but I think they had 48-bit address spaces until the PowerPC update. (I'm not talking about the 128-bit pointers, I'm talking about the address space available to the instructions that are executed by the machine rather than to the instructions translated into machine instructions.)
I miss VMS vaxen sometimes.
(Those, of course, weren't the 64-bit computers to which you were referring. OpenVMS Alphas were, but those didn't come out until the 1990's, and OpenVMS Itaniums are, but they didn't come out until even later. In any case, you've been talking about OS features, so VAX is irrelevant.)
Those of us that actually use multiple Unixen on a daily basis and have done so for decades have a more complete picture of what a Unix is.
And those of us who actually develop for multiple Unixes have to deal with all their quirks, and don't always find Mac OS X the quirkiest.
Come on dude, we're talking about server systems here, not desktop unix which isn't exactly a "consumer" product.
Not even if somewhere around 10% of desktops and laptops are running Un*x? Heck, some of them are even running trademarked UNIX.
Do you really consider Unix and Linux to be two separate things?
"Unix", as in "the registered trademark "Unix"", is separate from "Linux", meaning either the Linux kernel or the set (equivalence class?) of Linux distributions. To be legally eligible to be called a "Unix", an OS has to pass the Single UNIX Specification test suite; as far as I know, nobody's run any Linux distributions through that test suite.
However, Linux is most definitely a "Un*x", in that its API is a UNIX-derived API, even if it might not be able to check every single checkbox for the Single UNIX Specification.
And they also missed a line from SunOS 4 to SVR4; they showed it as a line from 4.3BSD instead. The SVR4 VM system and VFS layer came from SunOS 4.x, and the dynamic-linking mechanism, although changed a bit with the switch from a.out to ELF, also came from SunOS 4.x. Most of the BSDisms added to SVR4 also came from SunOS 4.x rather than directly from 4.3BSD.