These aren't pre-installed back doors - the NSA is hacking their way in.
That seems to be the implication of the article, although that doesn't rule out pre-installed back doors as well.
And it's not just American equipment
Including equipment from Huawei, which I suspect is unlikely to have back doors installed at the NSA's behest, unless the NSA and the The Ministry of State Security of the People's Republic of China are cooperating on that.
(and, interestingly, there's no mention of Apple).
There's also no mention of HP or Acer, so the lack of a mention of Apple might not have any special significance.
Thank heavens no German tech. companies were implicated.
No tech companies were explicitly implicated at all; the article says
A document viewed by SPIEGEL resembling a product catalog reveals that an NSA division called ANT has burrowed its way into nearly all the security architecture made by the major players in the industry -- including American global market leader Cisco and its Chinese competitor Huawei, but also producers of mass-market goods, such as US computer-maker Dell.
Huawei is not at the top of my list of companies that would put in back doors for US access. ANT, from the Der Spiegel article, appear to be breaking into systems not necessarily designed to be broken into by the NSA.
Perhaps some of the tools exploit back doors put in deliberately for the benefit of the NSA. Perhaps some of them exploit back doors put in deliberately for the benefit of other agencies, including agencies that do not view the NSA as friendly. And perhaps some of those other agencies are exploiting back doors put in for the benefit of the NSA....
And perhaps other tools exploit security bugs not put in deliberately.
My son brought his Macbook to me one day and asked if Python was on his machine and how he could use it. I could have easily told him to go to the Applications folder and look
Fortunately, you didn't do so:
$ ls/Applications | egrep -i py $
As python is used in system maintenence, it may not be listed in Applications if the idle application isn't installed, but I'll bet it is there.
As Python isn't a GUI application packaged as an application bundle, it's not in Applications, and thus not listed there. It's in/usr/bin:
Like I said, I think JSON strikes a better balance, as much as there are a couple things I don't like about it and as superficially resistant to it from a buzzword standpoint.:-)
Too buzzword-compliant, or not buzzword-compliant enough? (XML is probably Grade A when it comes to buzzword compliance.)
Beyond that, MacOS is all about it's own thing completely separate and distinct from all of the other Unixen. It has always been it's own thing, even before the bolted all of the visible parts onto something else.
That's fine and dandy except for the fact that MacOS _IS_ (being derived from NextStep, itself derived from IIRC 4.1 BSD) Unix underneath, nothing it adds overtop changes that.
I infer from "even before [they] bolted all of the visible parts onto something else" that the lack of "X" in "MacOS" is intentional; it sounds as if they were referring to "Mac OS" as dating back to the original Mac Toolbox or whatever the heck the term is, long before OS X.
Mac OS X was derived from NeXTStEP, but the original Mac software wasn't.
(But saying Apple "bolted all of the visible parts onto something else" when they went from classic Mac OS to Mac OS X is a bit bogus; there ain't much classic Mac OS code in OS X - there was Classic, but that was an emulation environment, running classic Mac OS on top of OS X rather than on the hardware - and even a lot of the UI conventions changed; Carbon on OS X implemented a similar API to Carbon on classic Mac OS, but, again, the code was different.)
IRIX had a load of GL/multimedia stuff overtop the base system, it was still Unix underneath.
Yup.
Your complaint is much more applicable to Linux, which despite all the pretending otherwise with constant talk of "inherently secure" because of "Unix underpinnings" is not and never was Unix. It's built to mimic Unix to a certain extent, but ultimately does its own thing, separate from Unixen, hence the term Unix-Like.
Every single UN*X does its own thing in some areas, separate from all other UN*Xes - if a supposed UN*X OS doesn't differ in some noticeable way from every other UN*X, it's not a UN*X.:-)
Yeah, Linux code isn't derived from AT&T UN*X, but that's true of a lot of the commercial UN*Xes as well, as well as the BSDs and OS X.
If Unix utilities were set up to pass around structured data instead of the same text meant for human consumption, the entire toolset becomes more Unixy, not yes.
And what stuff is shielded in such a way as to make it inaccessible from the command line (i.e., that can't be manipulated with scutil/scselect, defaults, etc.)?
OS X, despite having some unix anchestry, and using some NetBSD code here and some FreeBSD code there, can nowadays hardly be called 'unix', for it shields nearly everything behind the apple-proprietary GUI
What are some examples of this that differ from, say, Ubuntu or Fedora shielding things behind a GUI? (If the key is "proprietary", note that, prior to the free desktop environments that run atop X11, several UN*Xes offered proprietary GUIs.)
Exactly, fisted's comment about OS X is particularly retarded in an article about Unix. I can only hoping it was some sort of clever troll and they aren't really that fucking stupid.
Perhaps he meant that many developers on OS X do all their development inside Xcode and never see the command line, whereas few developers on other UN*Xes do all their development inside KDevelop or Eclipse or the Oracle Studio IDE or... and never see the command line.
General question about x32 ABI: is the OS still can use more than 4GB RAM w/o penalties?
Yes.
IOW, is kernel still 64bit?
Yes.
Only userspace is x32?
Userland can be IA-32 (or whatever you want to call the old 32-bit-only instruction set, with 8 registers), x32, or x86-64.
Or x32 and pure 64-bit can run alongside?
Yes, just as IA-32 and x86-64 code can run (in separate processes, typically; dunno if anybody's done thunking to let 32-bit code call 64-bit code or vice versa) alongside each other.
Think Atom processors running Android, or High-performance computing applications.
As long as you're not doing high-performance computing on more than 3-4GB of data. mmap() and MapViewOfFile() aren't all that cheap, so if you are working on more data, and can fit it in main memory, you'd probably prefer Full Frontal x86-64 to x32.
but.. I've heard* that it is generally better to compile in 64-bit mode, because the 32-bit part of the CPU is "legacy" and potentially less efficient than the 64-bit operations.
I hate watching videos, but I looked at the slides from the presentation, and slide 16 has, as one of its points, "Prefer 64-bit code, 32-bit data", which doesn't sound very consistent with "oh, the 32-bit stuff is legacy".
On x86, some reasons to prefer 64-bit code are that you have twice as many registers (although instructions that use the 8 new registers are one byte longer, as they need an additional instruction prefix to add additional register specifier bits), and that, as you're allowed to break binary compatibility when going 64-bit, the calling sequence was changed to support passing parameters in registers. Those have nothing to do with the 32-bit stuff being potentially-slower "legacy".
In fact, if you're talking about processors that don't have "Itanium" in the name, it's not clear what "the 32-bit part of the CPU" is:
for most RISC architectures, and for {System/3x0}/{z/Architecture}, the 64-bit version of the instruction set is just a widened flavor of the 32-bit version and the same data paths, registers, and instruction decoder can be used in 32-bit and 64-bit mode;
for x86, "the 32-bit part of the CPU" would be the lower half of 8 of the GPRs, the program counter, and the ALU(s), and the parts of the instruction decoder that handle the prefix used to get at extra registers as INC/DEC instructions with embedded register numbers, so the data paths, half of the registers, and almost all of the instruction decoder are used in both modes;
for ARM, "the 32-bit part of the CPU" would be the lower half of 16 of the GPRs, the program counter, and the ALU(s), and the part of the instruction decoder that handles AArch32 instructions, so a lot of that is used in both modes;
so I'm not sure why "the 32-bit part of the CPU" would be "legacy" and possibly slower.
Just to remind you, His Holiness Saint Jobs forbids reading about heretic technologies.
Then maybe he should've fired the folks responsible for Apple's Internet connection, given that it was, at least as of 2011, quite possible to read, and post to, Slashdot from Apple's corporate network.
You could make a film about a pile of dead body parts assembled into the form of a man being shocked by lightning and being given the will to live. You could even add some wanton violence and philosophical questions of existence to make the story interesting.
I'd happily pay 2x or 3x the money to get 20x the write endurance.
That only makes sense if you are hitting the write limits. If the drive dies because the bearings wear out after 5 years of spinning regardless of the number of writes, you have just paid 3x the money and gotten exactly zero benefit.
The poster to whom you responded said "SSDs have a property called "write endurance" - their data cells are rated to a specific number of writes. Every time you write, you consume some of the remaining write capacity of the drive. It works like a salt shaker: works find until you run out of salt.", which suggests he's talking about SSDs here, not HDDs. SSDs don't have spinning parts (well, other than the electrons, protons, and neutrons of which they're made:-)), and don't have bearings.
Anyway, when I took an assembly course a couple years back, we referred to passing on the stack as "the C calling convention," so I suppose I'm probably overgeneralizing.
Yes - there's no such thing as "the C calling convention", there are just conventions for particular instruction sets and, as indicated, most of the conventions involve passing some parameters in registers.
Obviously you have to be careful when passing by register though, as many ops destroy register values so you can't expect them to retain their starting value when you return, unless you manually restore them inside the subroutine. I suppose that's a general observation of anything you do in assembly, though.
Yes, if programming in assembler, or developing a compiler, you have to make sure you know whether a register gets overwritten, but that's not specific to passing parameters in registers.
It's an x86 calling convention (as the article says), not a generic calling convention for C for all architectures, as "blah blah blah is not a standard C parameter passing method" would speak of. There's no generic convention for passing parameters in C, there are only specific conventions for passing them on particular architectures, and most of those conventions do pass parameters in registers, although not all do (somewhat to my surprise, S/390 also passes parameters in registers), so x86, along with some rather old ISAs such as PDP-11, VAX, 68k, etc., may be the only ones that never pass parameters in registers, so "Passing in registers is not a standard C parameter passing method" is complete bullshit.
Massachusetts has shown how to do it. Now all it takes is realization of what can be done and applying it elsewhere.
That's no mystery: just attract a highly educated workforce, and education, health, income, life expectancy, etc. will all follow. Unfortunately, getting the top 5% of the population to move to your state is not something every state can do.
And not something Massachusetts has done, given that, from the as-of-July 1, 2012 estimates on this Wikipedia page, Massachusetts' population is about 2.1% of the US population.
And, as another poster noted, it's not as if Massachusetts is completely filled with Harvard/MIT/Tufts/Wellesley/Northeastern/UMass/Amherst College/Simmons/Smith/WPI/etc. graduates.
Passing in registers is not a standard C parameter passing method
There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.
If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.
Slashdot Mirror
READ THE ARTICLE.
These aren't pre-installed back doors - the NSA is hacking their way in.
That seems to be the implication of the article, although that doesn't rule out pre-installed back doors as well.
And it's not just American equipment
Including equipment from Huawei, which I suspect is unlikely to have back doors installed at the NSA's behest, unless the NSA and the The Ministry of State Security of the People's Republic of China are cooperating on that.
(and, interestingly, there's no mention of Apple).
There's also no mention of HP or Acer, so the lack of a mention of Apple might not have any special significance.
Thank heavens no German tech. companies were implicated.
No tech companies were explicitly implicated at all; the article says
Huawei is not at the top of my list of companies that would put in back doors for US access. ANT, from the Der Spiegel article, appear to be breaking into systems not necessarily designed to be broken into by the NSA.
Perhaps some of the tools exploit back doors put in deliberately for the benefit of the NSA. Perhaps some of them exploit back doors put in deliberately for the benefit of other agencies, including agencies that do not view the NSA as friendly. And perhaps some of those other agencies are exploiting back doors put in for the benefit of the NSA....
And perhaps other tools exploit security bugs not put in deliberately.
My son brought his Macbook to me one day and asked if Python was on his machine and how he could use it. I could have easily told him to go to the Applications folder and look
Fortunately, you didn't do so:
As python is used in system maintenence, it may not be listed in Applications if the idle application isn't installed, but I'll bet it is there.
As Python isn't a GUI application packaged as an application bundle, it's not in Applications, and thus not listed there. It's in /usr/bin:
It's not Linux's fault that the developers of Final Cut Pro and Lightroom specifically chose *not* to support Linux.
Yes, it is. Get back to us when Linux can deliver an equivalent to the IOKit.
For which devices do Final Cut Pro and Lightroom include drivers?
Like I said, I think JSON strikes a better balance, as much as there are a couple things I don't like about it and as superficially resistant to it from a buzzword standpoint. :-)
Too buzzword-compliant, or not buzzword-compliant enough? (XML is probably Grade A when it comes to buzzword compliance.)
This luser is supposedly an assistant professor in CS at some little university ex polytechnic is my bet
It's the University of Rochester; do you win or lose the bet?
IOW, they predate not only X, but also W.
CDE doesn't predate X, for obvious reasons.
Beyond that, MacOS is all about it's own thing completely separate and distinct from all of the other Unixen. It has always been it's own thing, even before the bolted all of the visible parts onto something else.
That's fine and dandy except for the fact that MacOS _IS_ (being derived from NextStep, itself derived from IIRC 4.1 BSD) Unix underneath, nothing it adds overtop changes that.
I infer from "even before [they] bolted all of the visible parts onto something else" that the lack of "X" in "MacOS" is intentional; it sounds as if they were referring to "Mac OS" as dating back to the original Mac Toolbox or whatever the heck the term is, long before OS X.
Mac OS X was derived from NeXTStEP, but the original Mac software wasn't.
(But saying Apple "bolted all of the visible parts onto something else" when they went from classic Mac OS to Mac OS X is a bit bogus; there ain't much classic Mac OS code in OS X - there was Classic, but that was an emulation environment, running classic Mac OS on top of OS X rather than on the hardware - and even a lot of the UI conventions changed; Carbon on OS X implemented a similar API to Carbon on classic Mac OS, but, again, the code was different.)
IRIX had a load of GL/multimedia stuff overtop the base system, it was still Unix underneath.
Yup.
Your complaint is much more applicable to Linux, which despite all the pretending otherwise with constant talk of "inherently secure" because of "Unix underpinnings" is not and never was Unix. It's built to mimic Unix to a certain extent, but ultimately does its own thing, separate from Unixen, hence the term Unix-Like.
Every single UN*X does its own thing in some areas, separate from all other UN*Xes - if a supposed UN*X OS doesn't differ in some noticeable way from every other UN*X, it's not a UN*X. :-)
Yeah, Linux code isn't derived from AT&T UN*X, but that's true of a lot of the commercial UN*Xes as well, as well as the BSDs and OS X.
If Unix utilities were set up to pass around structured data instead of the same text meant for human consumption, the entire toolset becomes more Unixy, not yes.
Somebody had an idea like that a while ago.
Yes, the keyword is proprietary
So the issue isn't the shielding per se.
And what stuff is shielded in such a way as to make it inaccessible from the command line (i.e., that can't be manipulated with scutil/scselect, defaults, etc.)?
OS X, despite having some unix anchestry, and using some NetBSD code here and some FreeBSD code there, can nowadays hardly be called 'unix', for it shields nearly everything behind the apple-proprietary GUI
What are some examples of this that differ from, say, Ubuntu or Fedora shielding things behind a GUI? (If the key is "proprietary", note that, prior to the free desktop environments that run atop X11, several UN*Xes offered proprietary GUIs.)
Exactly, fisted's comment about OS X is particularly retarded in an article about Unix. I can only hoping it was some sort of clever troll and they aren't really that fucking stupid.
Perhaps he meant that many developers on OS X do all their development inside Xcode and never see the command line, whereas few developers on other UN*Xes do all their development inside KDevelop or Eclipse or the Oracle Studio IDE or... and never see the command line.
General question about x32 ABI: is the OS still can use more than 4GB RAM w/o penalties?
Yes.
IOW, is kernel still 64bit?
Yes.
Only userspace is x32?
Userland can be IA-32 (or whatever you want to call the old 32-bit-only instruction set, with 8 registers), x32, or x86-64.
Or x32 and pure 64-bit can run alongside?
Yes, just as IA-32 and x86-64 code can run (in separate processes, typically; dunno if anybody's done thunking to let 32-bit code call 64-bit code or vice versa) alongside each other.
x86-64 has more registers.
...than IA-32 or whatever you want to call it; it does not have more registers than x32.
Think Atom processors running Android, or High-performance computing applications.
As long as you're not doing high-performance computing on more than 3-4GB of data. mmap() and MapViewOfFile() aren't all that cheap, so if you are working on more data, and can fit it in main memory, you'd probably prefer Full Frontal x86-64 to x32.
but.. I've heard* that it is generally better to compile in 64-bit mode, because the 32-bit part of the CPU is "legacy" and potentially less efficient than the 64-bit operations.
I hate watching videos, but I looked at the slides from the presentation, and slide 16 has, as one of its points, "Prefer 64-bit code, 32-bit data", which doesn't sound very consistent with "oh, the 32-bit stuff is legacy".
On x86, some reasons to prefer 64-bit code are that you have twice as many registers (although instructions that use the 8 new registers are one byte longer, as they need an additional instruction prefix to add additional register specifier bits), and that, as you're allowed to break binary compatibility when going 64-bit, the calling sequence was changed to support passing parameters in registers. Those have nothing to do with the 32-bit stuff being potentially-slower "legacy".
In fact, if you're talking about processors that don't have "Itanium" in the name, it's not clear what "the 32-bit part of the CPU" is:
so I'm not sure why "the 32-bit part of the CPU" would be "legacy" and possibly slower.
I'm betting on a lost anchor or random pieces of cast iron from an old ship.
Or maybe an intact old ship.
Just to remind you, His Holiness Saint Jobs forbids reading about heretic technologies.
Then maybe he should've fired the folks responsible for Apple's Internet connection, given that it was, at least as of 2011, quite possible to read, and post to, Slashdot from Apple's corporate network.
When man stare at goat man have heart attack.
Are you sure they didn't stare at something the name of which begins with "goat"?
You could make a film about a pile of dead body parts assembled into the form of a man being shocked by lightning and being given the will to live. You could even add some wanton violence and philosophical questions of existence to make the story interesting.
And don't forget the enormous schwanzstucker.
I'd happily pay 2x or 3x the money to get 20x the write endurance.
That only makes sense if you are hitting the write limits. If the drive dies because the bearings wear out after 5 years of spinning regardless of the number of writes, you have just paid 3x the money and gotten exactly zero benefit.
The poster to whom you responded said "SSDs have a property called "write endurance" - their data cells are rated to a specific number of writes. Every time you write, you consume some of the remaining write capacity of the drive. It works like a salt shaker: works find until you run out of salt.", which suggests he's talking about SSDs here, not HDDs. SSDs don't have spinning parts (well, other than the electrons, protons, and neutrons of which they're made :-)), and don't have bearings.
Anyway, when I took an assembly course a couple years back, we referred to passing on the stack as "the C calling convention," so I suppose I'm probably overgeneralizing.
Yes - there's no such thing as "the C calling convention", there are just conventions for particular instruction sets and, as indicated, most of the conventions involve passing some parameters in registers.
Obviously you have to be careful when passing by register though, as many ops destroy register values so you can't expect them to retain their starting value when you return, unless you manually restore them inside the subroutine. I suppose that's a general observation of anything you do in assembly, though.
Yes, if programming in assembler, or developing a compiler, you have to make sure you know whether a register gets overwritten, but that's not specific to passing parameters in registers.
http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl
Doesn't this count?
It's an x86 calling convention (as the article says), not a generic calling convention for C for all architectures, as "blah blah blah is not a standard C parameter passing method" would speak of. There's no generic convention for passing parameters in C, there are only specific conventions for passing them on particular architectures, and most of those conventions do pass parameters in registers, although not all do (somewhat to my surprise, S/390 also passes parameters in registers), so x86, along with some rather old ISAs such as PDP-11, VAX, 68k, etc., may be the only ones that never pass parameters in registers, so "Passing in registers is not a standard C parameter passing method" is complete bullshit.
That's no mystery: just attract a highly educated workforce, and education, health, income, life expectancy, etc. will all follow. Unfortunately, getting the top 5% of the population to move to your state is not something every state can do.
And not something Massachusetts has done, given that, from the as-of-July 1, 2012 estimates on this Wikipedia page, Massachusetts' population is about 2.1% of the US population.
And, as another poster noted, it's not as if Massachusetts is completely filled with Harvard/MIT/Tufts/Wellesley/Northeastern/UMass/Amherst College/Simmons/Smith/WPI/etc. graduates.
Passing in registers is not a standard C parameter passing method
There's no such thing as "a standard C parameter passing method". Passing in registers is a perfectly legitimate C parameter passing method, used on several RISC architectures, such as SPARC, MIPS, 32-bit ARM, 64-bit ARM, and 64-bit {PowerPC/Power Architecture} (and probably most other RISC architectures), as well as x86-64 and z/Architecture.
If there are more parameters than fit in the registers available for parameter passing, or if the parameters are in the variable-length portion of the argument list, they might be passed on the stack, and if the called function has no prototype in scope, the compiler might be forced to pass everything on the stack, but, in all other cases, if the ABI supports it, parameters can and will be passed on the stack.