IBM did in SCO v IBM. The court apparently accepted that argument and thus established case law precedent. This is just one example.
Did the court accept an argument that header files, broadly speaking, are not copyrightable, or just that the header files in question weren't copyrightable? If the latter, that might apply to header files upon which public standards such as the System V Interface Definition, various POSIX specifications, etc. are based aren't copyrightable, but might not apply to header files not part of some broad public specification containing bits of code in the form of inline functions and/or macros containing code; some Linux kernel headers are more like the latter than the former.
So, I'm not entirely convinced that your assertion that the header files aren't copyrighted is actually true.
It's not an assertion. It's backed up by case law such as the rulings of SCO v IBM where one of IBM's central claims against SCO with respect to SystemV header files like ERRNO.H is that they aren't copyrightable.
Did the case establish that no header files are copyrightable, or just that some System V header files, such as errno.h, aren't copyrightable (assuming the judge ruled on that particular claim)?
Perhaps you are trying to make a claim that "headers are not copyrightable", but that would be crazy.
So you think IBM was also crazy to argue that back in SCO v IBM where that argument was held up by the court?
Did IBM, in fact, argue that "headers are not copyrightable", stated that broadly, or just that the particular parts of the particular headers they were accused of copying in violation of the System V copyrights were not copyrightable? The parts of an IBM document for that case given in a Groklaw posting seem to me as if they were arguing the latter, not the former.
The code in question are header files, not actual running code (i.e. the binary compiled doesn't really contain any machine instructions produced from those files).
I.e., the header files in question contain neither definitions of inlined functions nor #definitions that include code and/or the source code used to produce the binary in question doesn't use those functions or macros?
Because of an addendum Torvalds added to the GPL v2 as it applies to the Linux kernel. I couldn't find it quickly on Google
You can find it in the COPYING file at the top level of the Linux kernel source tree:
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
That the biggest indicator of slashdot's downfall is that every single article posted is immediately met by a claim that the inclusion of said article indicates the site's downfall.
Unfortunately, the old Slashdot drinking game at http://people.cs.uchicago.edu/~neilk/drinking.txt appears to be gone, but perhaps it needs to be updated anyway. "Somebody posts a comment complaining about how Slashdot is going downhill and this story is an example" is probably a good one for the game; perhaps "I know I'm going to be modded down, but..." also belongs on the list, with an additional one for "Somebody says 'I know I'm going to be modded down, but...' and gets modded up".
when did we forget that javascript is garbage? everyone needs to quit writing absolutely EVERYTHING in javascript.. imagine the dos world if EVERYTHING was written in qbasic. please, for the love of the lord who loves/hates you, write your code in something that produces slim, native binaries!
Native binaries? How's this? It even has first-class functions, just like JavaScript! Not available for iOS, unfortunately. Dunno how slim the binaries are.
When Safari is up front and center, let it have the majority of the CPU time. When a "web app" is on the home screen, let it compete for clock cycles with the rest of the "web apps" on the home screen and the main functions of the home screen (and the phone in general).
When a "web app" is run from the home screen, it is "up front and center".
And what is the "regular app" involved in a WebView? (Note: "app" in this context means something with an executable image; the Web app itself isn't the "regular app", obviously.)
Nitro is a JIT. As a JIT, it builds machine code on the fly and executes it. In the iOS security model, that's considered “uncool”, and regular apps aren't allowed to do it.
And what is the "regular app" involved in a WebView? (Note: "app" in this context means something with an executable image; the Web app itself isn't the "regular app", obviously.)
Be careful to not confuse 'apple' and 'pc' with the entire processor market. There is a huge market for microprocessors and ARM is just the most successful, mainly because of their excellent lineup of developer tools. The power efficiency came second.
Think about it, are there more microwaves in the world, or more PCs? I don't know the answer, but every one of those microwaves have a microprocessor.
Yes, but is it a big fancy high-end super-powered sophisticated !!!!!!32-BIT!!!111ONE!!!!! ARM, or is it some lower-end 16-bit or 8-bit microcontroller? I suspect there's a huge market for microprocessors that make ARMs look like mainframe processors.
There are multiple *nixes, one of which comes from Apple, one of which comes from Oracle, one of which comes from HP, one of which comes from IBM, one of which (if you count all the Linux distributions as "Linux") or a whole bunch of which (if you count different Linux distributions separately) come from a whole bunch of different people and groups, four of which (*BSD) come from their groups, etc., so different *nixes would be different religions.
I still fear that Apple will start to boil the OS X frog. They have code signing and an app store in place. They have a warning dialog if you try to run software downloaded from anywhere else.
That dialog pops up if you've run software downloaded from anywhere (with the possible exception of stuff downloaded from the App Store). Yes, that include Apple.
They're clearly repositioning OS X server versus the regular version in Lion.
Apparently, the US National Institutes of Health (NIH)...for some strange reason...has been hosting the project. (Off the top of my head, I know that NIH also developed Image and ImageJ, presumably for their own needs.)
<republican>Sounds like more government waste to me. Why is NIH in this business exactly</republican>
Because Arthur Olson worked for the National Cancer Institute of NIH when he started the project, and continues to work there, and because they were willing to provide him space on their FTP server to store the releases etc. and let him run the project and mailing list from there.
UNIX "presents" applications to the network ("daemons") that have been started from their own shell and if you manage to crash those daemons, then you can force the system to drop to a shell prompt.
Err, umm, what? At least one UNIX has its daemons started directly by a system daemon, without an intervening shell. Even in UN*Xes that launch daemons from rc files, the shell running the rc file doesn't hang around forever.
If that daemon was running with root permissions, then it will drop to a root shell prompt and you then have unrestricted access to the system to do what you like - this type of attack is known as a "buffer overflow attack" because it's purpose is to crash the daemon by sending either too much data for it to process or badly constructed data.
No, buffer overflow attacks aren't intended to crash the daemon so you get to type at the (either non-existent or, if there are any cases where it exists, non-interactive) shell that started the daemon, buffer overflow attacks are typically intended to get the daemon to run code you stuffed into the buffer in question.
What? You can't understand that OSX has had more TOTAL vulnerabilities than Windows7,
What? You can't understand that "OS X" corresponds not to "Windows 7", but to the entire Windows NT series, and that the equivalent of "Windows 7" would be something like "OS X Snow Leopard"? And that the only reason that, 2003-2008, Windows 7 had zero vulnerabilities was that, 2003-2008, Windows 7 didn't, err, umm, exist as a product, as it was released to manufacturing in the middle of 2009? (BTW, is it just me, or is "windowsteamblog.com" continuing in the grand tradition of "expertsexchange.com"? Why is steam condensed on your window worthy of an entire blog?:-))
Unfortunately, Secunia neither offers a page for the Windows NT family as a whole, nor for individual releases of Mac OS X (although they do offer pages for individual releases of iOS!), so there's no way to compare, for example, Windows 7 and OS X Snow Leopard, but if, for example, we compare Windows 7 and OS X statistics in 2010 (that being the only year in which both Windows 7 and OS X Snow Leopard were available for the entire year), we have 47 advisories for Windows 7, 20 of which are critical, and 6 of which, 4 non-critical, are unpatched, and 12 vulnerabilities for Snow Leopard, 8 of which are critical, and 2 of which, both non-critical, are unpatched. Statistics for 2009, where they were both available for approximately the same amount of time, and for 2011, where they are available for exactly the same amount of time, are left as an exercise for the reader.
Then again, if Windows 7 in its entirety has more lines of code than Snow Leopard in its entirety, that might just be a case of "the same number of vulnerabilities per line of code, or fewer vulnerabilities per line of code, but they have more lines of code", so it's not clear that, even once you compare particular OS versions, rather than comparing a particular version of one OS to all versions of another OS, you necessarily have an easy way for fanboys or foeboys of one particular OS to validly beat up another OS or defend a particular OS.
Baloney, Apple had ACL and Code signing, memory randomization, and disk encryption long before Windows rolled theirs out.
Not true for "ACL", if by that you mean "supporting ACLs on files"; NT had that in NTFS since Day One, OS X picked it up later (it originally just had the UNIX permission-bits model - ACLs showed up in either Tiger or Leopard, I forget which). I can't speak for the others, as I don't know when they showed up in Windows, but I'd still not assume OS X had them first.
With the Unix underpinnings and the x86 hardware, a lot of stuff written for Unix or Linux will work with very little tweaking.
Well, "for Linux", maybe, as there's probably a lot of Linux developers who have never programmed for anything other than an x86-based personal computer and have never learned how to avoid writing non-portable code (which probably means, in this context, "how to avoid writing code that only works on little-endian processors").
"For Unix" is another matter, depending on what you mean by "Unix"; if you mean "commercial Unixes other than Mac OS X", which, these days, largely means "Solaris, AIX, and HP-UX", one of those (AIX) only runs on big-endian processors (Power Architecture and its variants), one of them (Solaris) runs on both x86 and a big-endian processor line that's still around (SPARC), and one of them (HP-UX) used to run on big-endian processors (PA-RISC) and might still run on one if the processor can run big-endian and is run that way (Itanium), so I doubt that the x86 hardware makes much of a difference for "stuff written for Unix".
I'm not disagreeing with anything you say; I'm just pointing out that Apple making single-button mice has had a disciplining effect on UI design.
Is it, in fact, the case that Windows/Motif/Qt/GTK+/whatever apps - or maybe we should limit it to Windows apps, so we're not dealing with stuff written by nerds who are proud of being nerds for nerds who are proud of being nerds:-) - have more context{ual} menu items that aren't also available from the menu bar than Mac OS apps? There's some random company in Cupertino that makes a Web browser for OS X where, if you've downloaded a PDF, the menu item to open the PDF in Preview is, unless I've missed something, only available as a context menu; perhaps Apple should send those people a copy of their Human Interface Guide?
Control-clicking isn't discoverable
Yes, just as Microsoft and the GNOME folks, like the Apple folks, point out, as I noted in the posting to which you replied.
You frequently actually see Windows software that *doesn't* adhere to such obvious basic principles of design; the people who complain about the single-button mouse on the Mac are very frequently exactly the people who would create such seven-headed UI horrors in the first place.
Again, is it, in fact, the case that you don't see that with Mac applications? If so, is that because:
the Mac developers didn't know about Control-click and thus didn't know that context{ual} menus exist in Mac OS, unlike Windows developers who know about the right button;
a lot of the Mac user base doesn't know about Control-click and thus doesn't know that context{ual} menus exist in Mac OS, so developers can't rely on users knowing about it, unlike Windows users who are more likely to know about the right mouse button;
the community of Mac app developers cares more about UI design, for whatever reason, than the community of Windows app developers (either because of the "Mac cult", or because the market for Mac apps is smaller and doesn't attract the, err, umm, less talented UI developers);
some other reason;
some combination of reasons.
I suspect the third of those might contribute, and that has nothing to do with the single mouse button.
Most Apple true believers are simply people who hate MS and Intel
Any Apple true believer who currently hates Intel is only going to be buying iPhones, iPods (touch or non-touch), iPads, or the current flavor of Apple TV. Anything else from Apple (other than keyboards and mice and AirPort base stations and other accessories) has Intel Inside(TM) (and, for all I know, the keyboard has Intel Inside(TM) in the form of an 8052 or whatever the controller chip is).
I seem to remember the "computer as an appliance" concept being something Steve Jobs wanted to push all the way back in the 1980s. What do you think "computer as an appliance" means, if not "computer for hopelessly clueless users who should remain clueless?"
"Computer for somebody who has better things to do with his or her time than tweak stuff to make it work"?
Slashdot Mirror
Who says the headers are not copyrighted?
IBM did in SCO v IBM. The court apparently accepted that argument and thus established case law precedent. This is just one example.
Did the court accept an argument that header files, broadly speaking, are not copyrightable, or just that the header files in question weren't copyrightable? If the latter, that might apply to header files upon which public standards such as the System V Interface Definition, various POSIX specifications, etc. are based aren't copyrightable, but might not apply to header files not part of some broad public specification containing bits of code in the form of inline functions and/or macros containing code; some Linux kernel headers are more like the latter than the former.
So, I'm not entirely convinced that your assertion that the header files aren't copyrighted is actually true.
It's not an assertion. It's backed up by case law such as the rulings of SCO v IBM where one of IBM's central claims against SCO with respect to SystemV header files like ERRNO.H is that they aren't copyrightable.
Did the case establish that no header files are copyrightable, or just that some System V header files, such as errno.h, aren't copyrightable (assuming the judge ruled on that particular claim)?
Perhaps you are trying to make a claim that "headers are not copyrightable", but that would be crazy.
So you think IBM was also crazy to argue that back in SCO v IBM where that argument was held up by the court?
Did IBM, in fact, argue that "headers are not copyrightable", stated that broadly, or just that the particular parts of the particular headers they were accused of copying in violation of the System V copyrights were not copyrightable? The parts of an IBM document for that case given in a Groklaw posting seem to me as if they were arguing the latter, not the former.
The code in question are header files, not actual running code (i.e. the binary compiled doesn't really contain any machine instructions produced from those files).
I.e., the header files in question contain neither definitions of inlined functions nor #definitions that include code and/or the source code used to produce the binary in question doesn't use those functions or macros?
Because of an addendum Torvalds added to the GPL v2 as it applies to the Linux kernel. I couldn't find it quickly on Google
You can find it in the COPYING file at the top level of the Linux kernel source tree:
which is followed by the text of the GPLv2.
That the biggest indicator of slashdot's downfall is that every single article posted is immediately met by a claim that the inclusion of said article indicates the site's downfall.
Unfortunately, the old Slashdot drinking game at http://people.cs.uchicago.edu/~neilk/drinking.txt appears to be gone, but perhaps it needs to be updated anyway. "Somebody posts a comment complaining about how Slashdot is going downhill and this story is an example" is probably a good one for the game; perhaps "I know I'm going to be modded down, but..." also belongs on the list, with an additional one for "Somebody says 'I know I'm going to be modded down, but...' and gets modded up".
I'm almost certain at this point that they're trying to 'force' upgrades to the new iPhone 4 by making their old devices slower
Because God knows new OS releases have never made your machine run slower, and have never required more powerful hardware....
when did we forget that javascript is garbage? everyone needs to quit writing absolutely EVERYTHING in javascript.. imagine the dos world if EVERYTHING was written in qbasic. please, for the love of the lord who loves/hates you, write your code in something that produces slim, native binaries!
Native binaries? How's this? It even has first-class functions, just like JavaScript! Not available for iOS, unfortunately. Dunno how slim the binaries are.
When Safari is up front and center, let it have the majority of the CPU time. When a "web app" is on the home screen, let it compete for clock cycles with the rest of the "web apps" on the home screen and the main functions of the home screen (and the phone in general).
When a "web app" is run from the home screen, it is "up front and center".
Android phones were sending text messages to the wrong recipients.
And here I thought the problem was you typed "RMS" when you meant to type "SMS".
And what is the "regular app" involved in a WebView? (Note: "app" in this context means something with an executable image; the Web app itself isn't the "regular app", obviously.)
According to another posting, it's Web.app.
Nitro is a JIT. As a JIT, it builds machine code on the fly and executes it. In the iOS security model, that's considered “uncool”, and regular apps aren't allowed to do it.
And what is the "regular app" involved in a WebView? (Note: "app" in this context means something with an executable image; the Web app itself isn't the "regular app", obviously.)
There is no FTP server on the Mac.
And, yeah, it came with the OS. In case you hadn't noticed, Macs are UN*X boxes these days (UNIX(R) boxes, starting with 10.5 for Intel).
Be careful to not confuse 'apple' and 'pc' with the entire processor market. There is a huge market for microprocessors and ARM is just the most successful, mainly because of their excellent lineup of developer tools. The power efficiency came second. Think about it, are there more microwaves in the world, or more PCs? I don't know the answer, but every one of those microwaves have a microprocessor.
Yes, but is it a big fancy high-end super-powered sophisticated !!!!!!32-BIT!!!111ONE!!!!! ARM, or is it some lower-end 16-bit or 8-bit microcontroller? I suspect there's a huge market for microprocessors that make ARMs look like mainframe processors.
So does this make *nix the jews?
There are multiple *nixes, one of which comes from Apple, one of which comes from Oracle, one of which comes from HP, one of which comes from IBM, one of which (if you count all the Linux distributions as "Linux") or a whole bunch of which (if you count different Linux distributions separately) come from a whole bunch of different people and groups, four of which (*BSD) come from their groups, etc., so different *nixes would be different religions.
I still fear that Apple will start to boil the OS X frog. They have code signing and an app store in place. They have a warning dialog if you try to run software downloaded from anywhere else.
That dialog pops up if you've run software downloaded from anywhere (with the possible exception of stuff downloaded from the App Store). Yes, that include Apple.
They're clearly repositioning OS X server versus the regular version in Lion.
If "repositioning" means "just making it an installation option for the one-and-only version of Lion, rather than a separate version that costs more money", yes, that's exactly what they're doing.
Apparently, the US National Institutes of Health (NIH)...for some strange reason...has been hosting the project. (Off the top of my head, I know that NIH also developed Image and ImageJ, presumably for their own needs.)
<republican>Sounds like more government waste to me. Why is NIH in this business exactly</republican>
Because Arthur Olson worked for the National Cancer Institute of NIH when he started the project, and continues to work there, and because they were willing to provide him space on their FTP server to store the releases etc. and let him run the project and mailing list from there.
UNIX "presents" applications to the network ("daemons") that have been started from their own shell and if you manage to crash those daemons, then you can force the system to drop to a shell prompt.
Err, umm, what? At least one UNIX has its daemons started directly by a system daemon, without an intervening shell. Even in UN*Xes that launch daemons from rc files, the shell running the rc file doesn't hang around forever.
If that daemon was running with root permissions, then it will drop to a root shell prompt and you then have unrestricted access to the system to do what you like - this type of attack is known as a "buffer overflow attack" because it's purpose is to crash the daemon by sending either too much data for it to process or badly constructed data.
No, buffer overflow attacks aren't intended to crash the daemon so you get to type at the (either non-existent or, if there are any cases where it exists, non-interactive) shell that started the daemon, buffer overflow attacks are typically intended to get the daemon to run code you stuffed into the buffer in question.
The shit isn't magical, it's the same hardware for more money, with an artsy UI, and an instant "in" with the liberals.
Yeah, I'm sure this guy's Mac use will win big points with liberals....
What? You can't understand that OSX has had more TOTAL vulnerabilities than Windows7,
What? You can't understand that "OS X" corresponds not to "Windows 7", but to the entire Windows NT series, and that the equivalent of "Windows 7" would be something like "OS X Snow Leopard"? And that the only reason that, 2003-2008, Windows 7 had zero vulnerabilities was that, 2003-2008, Windows 7 didn't, err, umm, exist as a product, as it was released to manufacturing in the middle of 2009? (BTW, is it just me, or is "windowsteamblog.com" continuing in the grand tradition of "expertsexchange.com"? Why is steam condensed on your window worthy of an entire blog? :-))
Unfortunately, Secunia neither offers a page for the Windows NT family as a whole, nor for individual releases of Mac OS X (although they do offer pages for individual releases of iOS!), so there's no way to compare, for example, Windows 7 and OS X Snow Leopard, but if, for example, we compare Windows 7 and OS X statistics in 2010 (that being the only year in which both Windows 7 and OS X Snow Leopard were available for the entire year), we have 47 advisories for Windows 7, 20 of which are critical, and 6 of which, 4 non-critical, are unpatched, and 12 vulnerabilities for Snow Leopard, 8 of which are critical, and 2 of which, both non-critical, are unpatched. Statistics for 2009, where they were both available for approximately the same amount of time, and for 2011, where they are available for exactly the same amount of time, are left as an exercise for the reader.
Then again, if Windows 7 in its entirety has more lines of code than Snow Leopard in its entirety, that might just be a case of "the same number of vulnerabilities per line of code, or fewer vulnerabilities per line of code, but they have more lines of code", so it's not clear that, even once you compare particular OS versions, rather than comparing a particular version of one OS to all versions of another OS, you necessarily have an easy way for fanboys or foeboys of one particular OS to validly beat up another OS or defend a particular OS.
Baloney, Apple had ACL and Code signing, memory randomization, and disk encryption long before Windows rolled theirs out.
Not true for "ACL", if by that you mean "supporting ACLs on files"; NT had that in NTFS since Day One, OS X picked it up later (it originally just had the UNIX permission-bits model - ACLs showed up in either Tiger or Leopard, I forget which). I can't speak for the others, as I don't know when they showed up in Windows, but I'd still not assume OS X had them first.
With the Unix underpinnings and the x86 hardware, a lot of stuff written for Unix or Linux will work with very little tweaking.
Well, "for Linux", maybe, as there's probably a lot of Linux developers who have never programmed for anything other than an x86-based personal computer and have never learned how to avoid writing non-portable code (which probably means, in this context, "how to avoid writing code that only works on little-endian processors").
"For Unix" is another matter, depending on what you mean by "Unix"; if you mean "commercial Unixes other than Mac OS X", which, these days, largely means "Solaris, AIX, and HP-UX", one of those (AIX) only runs on big-endian processors (Power Architecture and its variants), one of them (Solaris) runs on both x86 and a big-endian processor line that's still around (SPARC), and one of them (HP-UX) used to run on big-endian processors (PA-RISC) and might still run on one if the processor can run big-endian and is run that way (Itanium), so I doubt that the x86 hardware makes much of a difference for "stuff written for Unix".
I'm not disagreeing with anything you say; I'm just pointing out that Apple making single-button mice has had a disciplining effect on UI design.
Is it, in fact, the case that Windows/Motif/Qt/GTK+/whatever apps - or maybe we should limit it to Windows apps, so we're not dealing with stuff written by nerds who are proud of being nerds for nerds who are proud of being nerds :-) - have more context{ual} menu items that aren't also available from the menu bar than Mac OS apps? There's some random company in Cupertino that makes a Web browser for OS X where, if you've downloaded a PDF, the menu item to open the PDF in Preview is, unless I've missed something, only available as a context menu; perhaps Apple should send those people a copy of their Human Interface Guide?
Control-clicking isn't discoverable
Yes, just as Microsoft and the GNOME folks, like the Apple folks, point out, as I noted in the posting to which you replied.
You frequently actually see Windows software that *doesn't* adhere to such obvious basic principles of design; the people who complain about the single-button mouse on the Mac are very frequently exactly the people who would create such seven-headed UI horrors in the first place.
Again, is it, in fact, the case that you don't see that with Mac applications? If so, is that because:
I suspect the third of those might contribute, and that has nothing to do with the single mouse button.
Most Apple true believers are simply people who hate MS and Intel
Any Apple true believer who currently hates Intel is only going to be buying iPhones, iPods (touch or non-touch), iPads, or the current flavor of Apple TV. Anything else from Apple (other than keyboards and mice and AirPort base stations and other accessories) has Intel Inside(TM) (and, for all I know, the keyboard has Intel Inside(TM) in the form of an 8052 or whatever the controller chip is).
I seem to remember the "computer as an appliance" concept being something Steve Jobs wanted to push all the way back in the 1980s. What do you think "computer as an appliance" means, if not "computer for hopelessly clueless users who should remain clueless?"
"Computer for somebody who has better things to do with his or her time than tweak stuff to make it work"?