Bad example - linux DID copy the BSD constants and typedefs. This is no secret.
To which "BSD constants and typedefs" are you referring? They certainly had their own #defines for various UN*X constants, because they wanted to be UN*X-compatible. The numerical values for some of them differ from instruction set architecture to instruction set architecture (meaning that they can't have duplicated the BSD values for those on all platforms), presumably because they wanted to provide binary compatibility with at least some programs from a "native" operating system on the platforms in question, e.g. SunOS 5.x on SPARC, Digital/Tru64 UNIX on Alpha, etc..
As for typedefs, they do have typedefs in, for example, the 1.3.10 linux/types.h for both the BSD and System V unsigned integral values, but, again, defining some constants and typedefs that are used in a given API in order to implement that API doesn't mean you have to use the code that implements that API in your own implementation (if that were true, the Regents of the University of California would have lost the AT&T lawsuit...).
I guess you missed the whole "linux kernel headers" issue,
To which "linux kernel headers" issue are you referring? The one about the Android C library headers being derived from the Linux kernel headers and the question about whether copying them into a BSD-licensed library violated the GPL?
as well as the "there's SCO code in linux" (that turned out to be code from BSD).
Erm, no. There were several bits of SCO code that SCO asserted were in Linux. In one slide they showed the BPF interpreter and claimed it was copied from SCO; in fact, Linux has a clean-room implementation of the BPF interpreter (and originally had no BPF interpreter), not copied from the BSD interpreter, so Linux didn't have a copy of the BPF interpreter from BSD (unlike SCO Unix), it had its own independent implementation. However, that was not the only bit of SCO code they claimed was in Linux; they also claimed, for example, that some allocation routines that date back to old AT&T Unix - older versions of BSD happened to have it because they were derived from AT&T Unix, and code that implemented read-copy-update (which originally came from Sequent's Dynix, not from BSD). Go read Bruce Perens' analysis of SCO's slide show for details.
For one, it would have saved on the file system patents - zfs (as just one example) is not covered by microsoft patents.
Neither are extN (or,, for that matter, UFS). VFAT*, however, is, regardless of whether it's implemented by BSD code or Linux code or..... I'm not sure whether "FAT classic"; if not, and if the SD cards just use Boring Old FAT Classic (8.3 names and all), you might be able to avoid those patents.
You won't be able to, because they all signed NDAs as part of the deal, but we know that the file system is one area - memory is another,
"Memory" in what sense? Are you asserting that there are some memory management algorithms that Microsoft have patented, and that Linux is violating those patents but...
It's not about the license itself, but the underlying code. BSD == A T & T == lots of patents.
[Citation needed]. The AT&T lawsuit was about copyrights, not patents; see the settlement of the lawsuite. The only patent I know of is the set-UID patent, which AT&T donated to the public.
Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.
"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)
So you're going to need to copy ALL the BSD constants,
No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.
and ALL the BSD typedefs,
Again, you'll only have to copy the ones used in socket calls.
So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?
In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.
As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)
If it works, and it conforms to the IETF norms (which it HAS to to work, then it has to include a lot of the same code. Otherwise, it wouldn't conform to the norm, and would be broken, right?:-)
So, you have the source for the Vista and Win7 stack to back up your claims? Didn't think so.
Err, umm, you're the one making claims about the NT 6 networking stack, not me. I just questioned your "You can't make a compatible stack w/o using [the BSD networking code]" claim, wondering what you meant by "compatible" there.
Do you have the source to it to back up your claim that "It's still based off of BSD code."?
It's still based off of BSD code. "Derivative works" and all that. You can't make a compatible stack w/o using it.
"Compatible" with what? It might be more work to develop an Internet protocol stack from scratch without using the BSD code, but I rather doubt it's impossible to develop such a stack without using the BSD code.
Also, why the fuck should FOSS users care about what Apple does for their own closed-source OS? Before you say Darwin, consider the fact that not a single soul uses Darwin as his main OS. Why? Because it's shit.
Um...millions of OS X and iOS users are using Darwin as their main OS, as it is the foundation for those operating systems.
That depends on what he meant by "[use] Darwin as his main OS". If he meant "use raw Darwin, as built from the source at opensource.apple.com", rather than "use an OS whose core is Darwin", I suspect he's right - you could try building Darwin from source, and get the drivers you need for your hardware, and, if you want a GUI, get X11 running on the bare hardware etc., but that would, I think, be a lot of work.
What these companies have done is grant the same access the CALEA law gives the US Government to other countries. Other countries have taken this authority and used it for espionage. Thus these companies statements that "We didn't build a back door for India" then is correct. They built it for the U.S. Government.
and also apple never gave backdoor access to the government to its systems. even though under CALEA it is required to for all US products.
I guess that depends on what "backdoor" access means. CALEA is not exactly some Deep Dark Secret - it is, after all, U.S. Public Law 103-414. At least in theory, mechanisms required by CALEA are supposed to be used only with a court order or other lawful authorization, although I wouldn't treat that as an indication that it can't be, or isn't ever, used illegally. I suspect many other countries impose similar requirements, and, again, there's no guarantee that those countries' spooks never ever use those capabilities for their own purposes.
(Seriously, why does everyone think Android is/was the only competitor to Apple?)
They're probably looking at U.S. smartphone market share; Symbian is way down at the bottom and Maemo/Meego/whatever isn't listed. In world smartphone market share, Symbian is slightly ahead of iOS but is well behind err, umm, Android.
" The ARMv6 architecture introduced the first hardware support for unaligned accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in hardware, removing the need for software routines."
Thanks; I guess my information was out of date. I'd have looked it up in the instruction set architecture documentation, but as I'm not a "registered ARM customer", I can't see the instruction set architecture documentation....
As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?
Rosetta didn't suck too badly - it ran Quicken 2007 adequately on my MacBook Pro. ("Ran" because I dumped it in favor of Quicken Lite^WEssentials when Q2007 couldn't manage to avoid corrupting one of my credit card accounts.) Unlike the PC emulators, it didn't have to implement the raw hardware - it just had to run usermode code, and it translated system call arguments and results. Dunno how hard it'd be to translate x86 machine code to ARM machine code; if I remember correctly, ARM processors aren't guaranteed to support unaligned accesses, so sufficiently-safe translations of x86 memory-reference instructions might be complicated code sequences. (I'd look it up, but the fine folks at ARM have decided to make their instruction set architecture manuals only "available in [PDF versions] to registered ARM customers". Intel are a bit nicer, as are AMD.)
Did you even read the quote you posted? Alexander Hamilton was advocating the use of the "public purse" to support the "efforts of industry", claiming it's necessary in the US where it's not in other countries with great private wealth. Since the US now has that wealth, his argument is no longer relevant.
I guess I should have made my point clearer. The point was that treating "the Founding Fathers" as a unified entity usable as a club to beat statists over the head only works if you ignore some of the founding fathers. The point wasn't whether his argument was valid then or is valid now, the point is that it was made in the first place.
Besides, Hamilton stood virtually alone among the founding fathers as a statist. He didn't trust the people to rule themselves, and advocated a strong "nanny state" government as powerful as King George's.
Which explains why John Adams vetoed the Sedition Act and Alexander Hamilton supported it. Oh, wait....
And as for trusting the people to rule themselves, why did not the Constitution require universal suffrage for both Federal and State elections? Perhaps some people weren't even trusted to vote for their representatives....
For that matter, the OS could even intercept and handle unaligned references - very slow, but potentially useful for compat purposes.
...which I think SunOS did on SPARC (and may still do, but I'm too lazy to go look at the OpenSolaris source to see what SunOS 5.x does).
Or, alternatively, if the compiler can determine that an access is potentially unaligned, it can generate "safe" code. I seem to remember at least some SPARC C compiler or compilers having an option to make them generate unaligned-safe code for all pointer dereferences.
Hey - guess what? Alexander Hamilton lived in the US at a time when OTHER COUNTRIES had great private wealth. Today, the US is a country with great private wealth.
And how exactly is that relevant to a response to a posting questioning whether all the Founding Fathers, who, err, umm, "lived in the US at a time when OTHER COUNTRIES had great private wealth", were fans of minimal government?
OK, so recompile it if it's in Pascal or Ada or Fortran or....
The only software that you can't recompile (after checking for stuff that doesn't port) would be software in x86 assembler language; is there a significant amount of Windows application software out there written in assembler?
But as it keeps trying, it may find competition on its home turf: Qualcomm, which makes many of the ARM-based chips in those smartphones and tablets, wants to make PCs, too.
The article linked to says
The company is talking with PC makers about building thin and light computers based on its Snapdragon chips, Jacobs said during a keynote address at the Consumer Electronics Show.
which isn't quite the same as "Qualcomm... wants to make PCs".
It will be a very difficult task to port x86 software to ARM...
Why? Because people who write x86 software in higher-level languages tend to assume they can get away with unaligned references? Or because your definition of "x86 software" means "software written in x86 assembler language"?
The Republican who introduced the bill was also one of the recipients of contributions from Elsevier. Much less money ($2K to Issa, $11K to Maloney), but still money. There are other Democrats and other Republicans on the list as well. Dunno whether Issa's just a cheaper date or what.
Unlike myself or the Founding Fathers, he does not view government as a necessary evil that's only a little better than having no government,
And, of course, unlike that most-definitely-not-a-Founding-Father-no-way Alexander Hamilton, who made that most-definitely-not-Founding-Fatherish statement that
That's not more info, it's just the "Indian blogger from ZDNet" referred to, and linked to, by the posting. The original documents are under the "posted on the Net" link in the posting.
Actually, both UNIX and Windows have two time formats:
the one that is more-or-less a count of second-or-sub-second intervals since a fixed time in the past;
the one that's year/month/day/hour/minute/second/maybe fractions of a second.
They do but my understanding was that the former was the internal format while the latter was mostly for display.
In most if not all UN*Xes, that's true. In modern Windows systems, it might be true, but I'm not sure; the fact that the "mostly for display" format is called SYSTEMTIME and the other format is called FILETIME, and that the call to get the former is GetSystemTime() and the call to get the latter is GetSystemTimeAsFileTime(), may or may not be significant, but they do at least seem to suggest that the "mostly for display" format is thought of as the Real System Time.
Slashdot Mirror
Bad example - linux DID copy the BSD constants and typedefs. This is no secret.
To which "BSD constants and typedefs" are you referring? They certainly had their own #defines for various UN*X constants, because they wanted to be UN*X-compatible. The numerical values for some of them differ from instruction set architecture to instruction set architecture (meaning that they can't have duplicated the BSD values for those on all platforms), presumably because they wanted to provide binary compatibility with at least some programs from a "native" operating system on the platforms in question, e.g. SunOS 5.x on SPARC, Digital/Tru64 UNIX on Alpha, etc..
As for typedefs, they do have typedefs in, for example, the 1.3.10 linux/types.h for both the BSD and System V unsigned integral values, but, again, defining some constants and typedefs that are used in a given API in order to implement that API doesn't mean you have to use the code that implements that API in your own implementation (if that were true, the Regents of the University of California would have lost the AT&T lawsuit...).
I guess you missed the whole "linux kernel headers" issue,
To which "linux kernel headers" issue are you referring? The one about the Android C library headers being derived from the Linux kernel headers and the question about whether copying them into a BSD-licensed library violated the GPL?
as well as the "there's SCO code in linux" (that turned out to be code from BSD).
Erm, no. There were several bits of SCO code that SCO asserted were in Linux. In one slide they showed the BPF interpreter and claimed it was copied from SCO; in fact, Linux has a clean-room implementation of the BPF interpreter (and originally had no BPF interpreter), not copied from the BSD interpreter, so Linux didn't have a copy of the BPF interpreter from BSD (unlike SCO Unix), it had its own independent implementation. However, that was not the only bit of SCO code they claimed was in Linux; they also claimed, for example, that some allocation routines that date back to old AT&T Unix - older versions of BSD happened to have it because they were derived from AT&T Unix, and code that implemented read-copy-update (which originally came from Sequent's Dynix, not from BSD). Go read Bruce Perens' analysis of SCO's slide show for details.
For one, it would have saved on the file system patents - zfs (as just one example) is not covered by microsoft patents.
Neither are extN (or,, for that matter, UFS). VFAT*, however, is, regardless of whether it's implemented by BSD code or Linux code or..... I'm not sure whether "FAT classic"; if not, and if the SD cards just use Boring Old FAT Classic (8.3 names and all), you might be able to avoid those patents.
You won't be able to, because they all signed NDAs as part of the deal, but we know that the file system is one area - memory is another,
"Memory" in what sense? Are you asserting that there are some memory management algorithms that Microsoft have patented, and that Linux is violating those patents but...
and BSD doesn't use the same algorithms.
...BSD isn't? If so, well, [citation needed].
It's not about the license itself, but the underlying code. BSD == A T & T == lots of patents.
[Citation needed]. The AT&T lawsuit was about copyrights, not patents; see the settlement of the lawsuite. The only patent I know of is the set-UID patent, which AT&T donated to the public.
Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.
"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)
So you're going to need to copy ALL the BSD constants,
No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.
and ALL the BSD typedefs,
Again, you'll only have to copy the ones used in socket calls.
So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?
So, tell us, how are you going to write something that complies with various UN*X standards without using the code of an existing implementation?
As indicated, you don't have to copy the exact definitions of the constants; even the existing *BSDs don't all have the same numerical value for AF_INET6 (28 in FreeBSD and DragonFly BSD and 24 in NetBSD and OpenBSD; it's 30 in Mac OS X and presumably iOS).
In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.
As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)
If it works, and it conforms to the IETF norms (which it HAS to to work, then it has to include a lot of the same code. Otherwise, it wouldn't conform to the norm, and would be broken, right? :-)
Wrong. Next question?
So, you have the source for the Vista and Win7 stack to back up your claims? Didn't think so.
Err, umm, you're the one making claims about the NT 6 networking stack, not me. I just questioned your "You can't make a compatible stack w/o using [the BSD networking code]" claim, wondering what you meant by "compatible" there.
Do you have the source to it to back up your claim that "It's still based off of BSD code."?
It's still based off of BSD code. "Derivative works" and all that. You can't make a compatible stack w/o using it.
"Compatible" with what? It might be more work to develop an Internet protocol stack from scratch without using the BSD code, but I rather doubt it's impossible to develop such a stack without using the BSD code.
Um...millions of OS X and iOS users are using Darwin as their main OS, as it is the foundation for those operating systems.
That depends on what he meant by "[use] Darwin as his main OS". If he meant "use raw Darwin, as built from the source at opensource.apple.com", rather than "use an OS whose core is Darwin", I suspect he's right - you could try building Darwin from source, and get the drivers you need for your hardware, and, if you want a GUI, get X11 running on the bare hardware etc., but that would, I think, be a lot of work.
What these companies have done is grant the same access the CALEA law gives the US Government to other countries. Other countries have taken this authority and used it for espionage. Thus these companies statements that "We didn't build a back door for India" then is correct. They built it for the U.S. Government.
...which is probably not correct; the EU, for example, has a council resolution concerning requiring capabilities for "lawful interception of communications" and I suspect the Member States have implemented laws for that. I.e., they built it for all countries that require lawful interception capabilities, which probably covers most countries in which they sell mobile phones.
and also apple never gave backdoor access to the government to its systems. even though under CALEA it is required to for all US products.
I guess that depends on what "backdoor" access means. CALEA is not exactly some Deep Dark Secret - it is, after all, U.S. Public Law 103-414. At least in theory, mechanisms required by CALEA are supposed to be used only with a court order or other lawful authorization, although I wouldn't treat that as an indication that it can't be, or isn't ever, used illegally. I suspect many other countries impose similar requirements, and, again, there's no guarantee that those countries' spooks never ever use those capabilities for their own purposes.
N800, bitchez!
(Seriously, why does everyone think Android is/was the only competitor to Apple?)
They're probably looking at U.S. smartphone market share; Symbian is way down at the bottom and Maemo/Meego/whatever isn't listed. In world smartphone market share, Symbian is slightly ahead of iOS but is well behind err, umm, Android.
unaligned references?
" The ARMv6 architecture introduced the first hardware support for unaligned accesses. ARM11 and Cortex-A/R processors can deal with unaligned accesses in hardware, removing the need for software routines."
Thanks; I guess my information was out of date. I'd have looked it up in the instruction set architecture documentation, but as I'm not a "registered ARM customer", I can't see the instruction set architecture documentation....
As far as emulators, everyone recalls the PC emulators available for the PPC Macs. They did work, but the system they were emulating was slow by standards of the time. You could in principle emulate any processor on any other processor - but would it be worthwhile?
Rosetta didn't suck too badly - it ran Quicken 2007 adequately on my MacBook Pro. ("Ran" because I dumped it in favor of Quicken Lite^WEssentials when Q2007 couldn't manage to avoid corrupting one of my credit card accounts.) Unlike the PC emulators, it didn't have to implement the raw hardware - it just had to run usermode code, and it translated system call arguments and results. Dunno how hard it'd be to translate x86 machine code to ARM machine code; if I remember correctly, ARM processors aren't guaranteed to support unaligned accesses, so sufficiently-safe translations of x86 memory-reference instructions might be complicated code sequences. (I'd look it up, but the fine folks at ARM have decided to make their instruction set architecture manuals only "available in [PDF versions] to registered ARM customers". Intel are a bit nicer, as are AMD.)
I think MS finally clued into the power of a cross platform platform (a la iPad/iPhone/OS X)
The UI toolkits are different in Mac OS X and iOS; it's not as if you can just move an app between the platforms with little change.
Did you even read the quote you posted? Alexander Hamilton was advocating the use of the "public purse" to support the "efforts of industry", claiming it's necessary in the US where it's not in other countries with great private wealth. Since the US now has that wealth, his argument is no longer relevant.
I guess I should have made my point clearer. The point was that treating "the Founding Fathers" as a unified entity usable as a club to beat statists over the head only works if you ignore some of the founding fathers. The point wasn't whether his argument was valid then or is valid now, the point is that it was made in the first place.
Besides, Hamilton stood virtually alone among the founding fathers as a statist. He didn't trust the people to rule themselves, and advocated a strong "nanny state" government as powerful as King George's.
Which explains why John Adams vetoed the Sedition Act and Alexander Hamilton supported it. Oh, wait....
And as for trusting the people to rule themselves, why did not the Constitution require universal suffrage for both Federal and State elections? Perhaps some people weren't even trusted to vote for their representatives....
For that matter, the OS could even intercept and handle unaligned references - very slow, but potentially useful for compat purposes.
...which I think SunOS did on SPARC (and may still do, but I'm too lazy to go look at the OpenSolaris source to see what SunOS 5.x does).
Or, alternatively, if the compiler can determine that an access is potentially unaligned, it can generate "safe" code. I seem to remember at least some SPARC C compiler or compilers having an option to make them generate unaligned-safe code for all pointer dereferences.
Hey - guess what? Alexander Hamilton lived in the US at a time when OTHER COUNTRIES had great private wealth. Today, the US is a country with great private wealth.
And how exactly is that relevant to a response to a posting questioning whether all the Founding Fathers, who, err, umm, "lived in the US at a time when OTHER COUNTRIES had great private wealth", were fans of minimal government?
But not all software is in C or C++...
OK, so recompile it if it's in Pascal or Ada or Fortran or....
The only software that you can't recompile (after checking for stuff that doesn't port) would be software in x86 assembler language; is there a significant amount of Windows application software out there written in assembler?
But as it keeps trying, it may find competition on its home turf: Qualcomm, which makes many of the ARM-based chips in those smartphones and tablets, wants to make PCs, too.
The article linked to says
The company is talking with PC makers about building thin and light computers based on its Snapdragon chips, Jacobs said during a keynote address at the Consumer Electronics Show.
which isn't quite the same as "Qualcomm ... wants to make PCs".
It will be a very difficult task to port x86 software to ARM...
Why? Because people who write x86 software in higher-level languages tend to assume they can get away with unaligned references? Or because your definition of "x86 software" means "software written in x86 assembler language"?
we now know now much it costs to buy a congressman: $5,500.
Replace "Democrat" with "Republican" in that URL and you'll see that Issa cost less than Maloney.
The Dem was the recipient of the kick back lefty.
(What's a "kick back lefty"?)
The Republican who introduced the bill was also one of the recipients of contributions from Elsevier. Much less money ($2K to Issa, $11K to Maloney), but still money. There are other Democrats and other Republicans on the list as well. Dunno whether Issa's just a cheaper date or what.
Unlike myself or the Founding Fathers, he does not view government as a necessary evil that's only a little better than having no government,
And, of course, unlike that most-definitely-not-a-Founding-Father-no-way Alexander Hamilton, who made that most-definitely-not-Founding-Fatherish statement that
Try this, not a dump but some more info http://www.zdnet.com/blog/india/have-rim-nokia-apple-provided-indian-military-with-backdoor-access-to-cellular-comm/838
That's not more info, it's just the "Indian blogger from ZDNet" referred to, and linked to, by the posting. The original documents are under the "posted on the Net" link in the posting.
Actually, both UNIX and Windows have two time formats:
the one that is more-or-less a count of second-or-sub-second intervals since a fixed time in the past; the one that's year/month/day/hour/minute/second/maybe fractions of a second.
They do but my understanding was that the former was the internal format while the latter was mostly for display.
In most if not all UN*Xes, that's true. In modern Windows systems, it might be true, but I'm not sure; the fact that the "mostly for display" format is called SYSTEMTIME and the other format is called FILETIME, and that the call to get the former is GetSystemTime() and the call to get the latter is GetSystemTimeAsFileTime(), may or may not be significant, but they do at least seem to suggest that the "mostly for display" format is thought of as the Real System Time.