But is Mach UNIX? I don't mean 'POSIX compliant' because Windows NT 4.0 is POSIX compliant.
If Mach is "the Mach kernel", I don't think it offers UNIX APIs, but at least two OSes based on Mach have passed the Single UNIX Specification test suite (which NT 4.0 hasn't, and which even Interix^Wthe Subsystem for Unix-based Applications hasn't).
Microsoft haven't. I guess they realized that software actually used alternate data streams, so they had to add them back to ReFS, although only "up to 128K for both Windows 8.1 and Windows Server 2012 R2", so they're more like "big extended attributes" than full alternate data streams.
Are you certain? The ln command, when run without -s, would return an error if you used it under Tiger or earlier?
Or are you referring to hardlinking to directories, which was something UNIX traditionally supported, but which required root permissions (as it was used by the mkdir command to create the. and.. directories), and which was removed at one point (4.2BSD, as that added the mkdir() system call, making the ability of link() to link to a directory unnecessary?), and added back in 10.5 with the introduction of Time Machine, so that it could be used in backup trees as a very hacky form of de-duplication (each backup tree is a complete copy of the file system being backed up, but if there's an older copy of an unchanged file or a directory everything under which is unchanged, the "copy" is done by making a hard link rather than by copying the file to the backup disk).
Instead of tackling "bitrot" head-on, Apple seems to have taken the "make backups easy" approach. This works to some degree, but since the backups use hardlinking, you really only have two copies of the data -- the one on your main drive, and the one on your backup drive. This makes cycling your backup drives even more important than it already was.
That's what happens with any backup scheme that does incremental backups - if a file hasn't changed, a copy isn't made.
A claim of cross-platform is one thing. But in practice I know of no significant apps using Qt that exist in the wild that work on OS X.
Please provide a link to any mainstream working application for Mac OS X that uses Qt.
$ otool -L/Applications/Google\ Earth.app//Contents//MacOS//Google\ Earth /Applications/Google Earth.app//Contents//MacOS//Google Earth: @rpath/libgoogleearth_free.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 155.0.0) @rpath/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.4) @rpath/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.4) @rpath/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.7.0, current version 4.7.4) @rpath/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.4)
...
I don't know of a single one because Qt's support for XCode is incredibly poor.
Do you have to use Xcode, the IDE, to develop OS X apps? Or by "Xcode" do you mean "Xcode the IDE, plus the command-line tools"?
EMT64 was in the labs for several years before it was released to market
But was the project started before, or after, AMD published the first AMD64 spec? My guess is "after", unless Intel either 1) somehow managed to come up with the same extensions as AMD or 2) discarded their extensions and went with AMD's after AMD announced them.
Instruction set, the set of instructions. ISA, the part of the architecture which handles the instruction set.
Who, other than you, uses that definition of ISA? Intel doesn't, as per my previous post. IBM doesn't, either, and neither does ARM, nor does AMD, nor does Sun^WOracle, for example; they're all using "instruction set architecture" as "instruction set", with "architecture" perhaps given to signify that the instruction set is not just a characteristic of a particular processor, it's something that's specified separately from particular implementations of the instruction set.
Just the decode and encode stages of the CPU
So what does the "encode" stage of a CPU do? Take various internal chip signals and write out instructions to memory?
But originally, the ISA was defined by the very architecture of the processor, and it related directly to the architecture of the underlying processor.
If you mean "in the very early days of computers, the connection between the instruction set and the design of the CPU was straightforward", that might be true, but, dating at least back to the IBM System/360, the same instruction set was implemented by extremely different internal processor designs in many families of computers.
Yeah, but ISAs are all but over, and they are over in x86-land.
They're not "over" to compiler writers and assembler-language programmers.
IS != ISA, HTH HAND
It would only help if it were true. What are your definitions of "instruction set" and "instruction set architecture", and what citations can you give that would make those definitions worth taking seriously, as opposed to, for example, Intel's use of "instruction set" and Intel's use of "instruction set architecture"?
Yeah, but ISAs are all but over, and they are over in x86-land.
They're not "over" to compiler writers and assembler-language programmers.
We haven't had an x86 core defined by its instruction set since the 80486. Even the Am586 was internally RISCy.
So? They (and the latest z/Architecture chips) might translate native instructions into microops and schedule and execute those microops, but the only way in which those microops - or other implementation details of the processor - are visible to code and people or software that generate code is that they may affect the performance of particular sequences of instructions, so that, for example, a compiler might optimize differently for different processors.
Way to shoot yourself in the foot, AMD. I don't want or need a new architecture. I want x86 (and x64) for my PC and laptop, the end.
Another reason to avoid the unqualified term "architecture" when speaking either of instruction sets or chip designs; person A may read "architecture" as "instruction set architecture" and person B may read it as "microarchitecture". I suspect they're talking about a new microarchitecture, implementing the x86-64 instruction set architecture, here.
Not the architecture, that belongs to Intel, AMD extended it to support 64 bits.
What are you on about? amd64 is not an architecture, nor is x86. They are instruction sets. The underlying architecture may be informed by the instruction set, but it's also only loosely coupled in modern CPUs.
This is why the term "microarchitecture" is useful. In addition to the term "instruction set", the term "instruction set architecture" is also used, so "architecture" is used for both.
If you look at the original post, the AC was disparaging the article for focusing on coding over the 'rest' of computer science
My intent was to point out that coding involves a set of skills that have a wider general application than just focusing on computer science, which could be likened to training a person for a trade
I thought that I was being clear
One thing you said was "Teaching people to rack servers and install operating systems becomes for focused and resembles learning a trade." "Teaching people to rack servers and install operating systems" is, of course, not part of computer science at all; it's also not part of coding, so its relevance to a discussion of coding and/or computer science is, at best, unclear.
(Presumably you're not saying something completely insane, such as likening teaching computer science to teaching people to rack servers and install operating systems. Anybody who "gets" that is completely delusional or completely ignorant of computer science.)
What he said was "There are elements of coding that require planning, logic and completeness that have impacts far beyond computer science. Teaching people to rack servers and install operating systems becomes for focused and resembles learning a trade."
This says nothing about the latter two items not being elements of coding, so, no, that's not what he said.
He doesn't explicitly say they are elements of coding, but he mentions them in a sentence immediately following a sentence that mentions elements of coding, and does so in a comment to an article discussing coding, so, if he thinks they're not elements of coding, it's not clear why he bothered to mention at all.
There are elements of coding that require planning, logic and completeness that have impacts far beyond computer science. Teaching people to rack servers and install operating systems
Neither racking servers nor installing operating systems are elements of coding. They may be useful skills, but they have nothing to do with coding.
Yes, that was precisely my point - does all the extra code make systemd almost 10x better than launchd, or is it better but not by as much, or is it no better or even worse?
No shit. An operating system that changed the world,
...by being the first widely-available, free-as-in-beer-and-speech (and not under legal threat from AT&T) Unix-compatible OS.
vs. a versioned source control system that makes certain administrative tasks easier.
...and that was most definitely not the first widely-available, free-as-in-beer-and-speech version control system capable of over-the-network access (and not, as far as I know, even the first widely-available, free-as-in-beer-and-speech distributed version control system).
(And it makes some things harder if you're "holding it wrong", but I digress.)
We should not diminish the importance of Linux. But it's clear that Git is much more important today. Linux is wonderful, but its a commodity for most people. It doesn't matter that Android is based on Linux. It's awesome but most people don't care. It's just a technicality.
It's "just a technicality" in the sense that Android might not exist if Linux hadn't existed; saying that it's less relevant because people don't know it's there is like saying that ARM isn't all that important because most people don't know they have ARM processors in their smartphones. Git is even less directly relevant to most people, as they're not developers.
What Linus did by creating GitHub is of tremendously much more importance if you look at how well it brings open source developers together.
Presumably you meant "by creating Git"; as far as I know, he no more created GitHub than he created Android, even if GitHub uses Git and Android uses Linux.
I would say Git is virtually indispensable in development, or at least some form of version control, at this point.
Given that many projects don't use Git, I would not even come close to saying that Git is virtually indispensable in development (unless "virtually" means "not" or otherwise renders the adjective to which it refers meaningless).
I would say that some form of version control is important, but there were plenty of free-software version control systems, supporting over-the-Internet access, available before Git came along, so you can't give credit to Git for that.
I'd love to know the reasons that lead some to believe that "In some ways Git can be seen as his more important contribution".
Slashdot Mirror
Not everyone speaks English or Chinese or Spanish.
Everyone recognizes stop sign, airport, pile of poop and other symbols. So communicating via pictographs is actually good. Even if it was incidental.
And many of them recognize this as well.
But is Mach UNIX? I don't mean 'POSIX compliant' because Windows NT 4.0 is POSIX compliant.
If Mach is "the Mach kernel", I don't think it offers UNIX APIs, but at least two OSes based on Mach have passed the Single UNIX Specification test suite (which NT 4.0 hasn't, and which even Interix^Wthe Subsystem for Unix-based Applications hasn't).
Forget about moving Windows off NTFS.
Microsoft haven't. I guess they realized that software actually used alternate data streams, so they had to add them back to ReFS, although only "up to 128K for both Windows 8.1 and Windows Server 2012 R2", so they're more like "big extended attributes" than full alternate data streams.
10.5 added hardlinking.
Are you certain? The ln command, when run without -s, would return an error if you used it under Tiger or earlier?
Or are you referring to hardlinking to directories, which was something UNIX traditionally supported, but which required root permissions (as it was used by the mkdir command to create the . and .. directories), and which was removed at one point (4.2BSD, as that added the mkdir() system call, making the ability of link() to link to a directory unnecessary?), and added back in 10.5 with the introduction of Time Machine, so that it could be used in backup trees as a very hacky form of de-duplication (each backup tree is a complete copy of the file system being backed up, but if there's an older copy of an unchanged file or a directory everything under which is unchanged, the "copy" is done by making a hard link rather than by copying the file to the backup disk).
Instead of tackling "bitrot" head-on, Apple seems to have taken the "make backups easy" approach. This works to some degree, but since the backups use hardlinking, you really only have two copies of the data -- the one on your main drive, and the one on your backup drive. This makes cycling your backup drives even more important than it already was.
That's what happens with any backup scheme that does incremental backups - if a file hasn't changed, a copy isn't made.
No this is NOT a troll, please read.
A claim of cross-platform is one thing. But in practice I know of no significant apps using Qt that exist in the wild that work on OS X.
Please provide a link to any mainstream working application for Mac OS X that uses Qt.
I don't know of a single one because Qt's support for XCode is incredibly poor.
Do you have to use Xcode, the IDE, to develop OS X apps? Or by "Xcode" do you mean "Xcode the IDE, plus the command-line tools"?
IBM introduced the 64-bit version of the PowerPC architecture in 2002,
Well before that, and, yes, the PPC 620 was used in some systems shipped by Groupe Bull. IBM's first systems using 64-bit PPC processors came out in 1997.
and I think that some of their mainframe processors were 64-bit about 2 years before that.
2 years before 2002, yes.
EMT64 was in the labs for several years before it was released to market
But was the project started before, or after, AMD published the first AMD64 spec? My guess is "after", unless Intel either 1) somehow managed to come up with the same extensions as AMD or 2) discarded their extensions and went with AMD's after AMD announced them.
Instruction set, the set of instructions. ISA, the part of the architecture which handles the instruction set.
Who, other than you, uses that definition of ISA? Intel doesn't, as per my previous post. IBM doesn't, either, and neither does ARM, nor does AMD, nor does Sun^WOracle, for example; they're all using "instruction set architecture" as "instruction set", with "architecture" perhaps given to signify that the instruction set is not just a characteristic of a particular processor, it's something that's specified separately from particular implementations of the instruction set.
Just the decode and encode stages of the CPU
So what does the "encode" stage of a CPU do? Take various internal chip signals and write out instructions to memory?
But originally, the ISA was defined by the very architecture of the processor, and it related directly to the architecture of the underlying processor.
If you mean "in the very early days of computers, the connection between the instruction set and the design of the CPU was straightforward", that might be true, but, dating at least back to the IBM System/360, the same instruction set was implemented by extremely different internal processor designs in many families of computers.
Yeah, but ISAs are all but over, and they are over in x86-land.
They're not "over" to compiler writers and assembler-language programmers.
IS != ISA, HTH HAND
It would only help if it were true. What are your definitions of "instruction set" and "instruction set architecture", and what citations can you give that would make those definitions worth taking seriously, as opposed to, for example, Intel's use of "instruction set" and Intel's use of "instruction set architecture"?
Yeah, but ISAs are all but over, and they are over in x86-land.
They're not "over" to compiler writers and assembler-language programmers.
We haven't had an x86 core defined by its instruction set since the 80486. Even the Am586 was internally RISCy.
So? They (and the latest z/Architecture chips) might translate native instructions into microops and schedule and execute those microops, but the only way in which those microops - or other implementation details of the processor - are visible to code and people or software that generate code is that they may affect the performance of particular sequences of instructions, so that, for example, a compiler might optimize differently for different processors.
Way to shoot yourself in the foot, AMD. I don't want or need a new architecture. I want x86 (and x64) for my PC and laptop, the end.
Another reason to avoid the unqualified term "architecture" when speaking either of instruction sets or chip designs; person A may read "architecture" as "instruction set architecture" and person B may read it as "microarchitecture". I suspect they're talking about a new microarchitecture, implementing the x86-64 instruction set architecture, here.
Not the architecture, that belongs to Intel, AMD extended it to support 64 bits.
What are you on about? amd64 is not an architecture, nor is x86. They are instruction sets. The underlying architecture may be informed by the instruction set, but it's also only loosely coupled in modern CPUs.
This is why the term "microarchitecture" is useful. In addition to the term "instruction set", the term "instruction set architecture" is also used, so "architecture" is used for both.
All in all, I actually expect better from the Bulletin of the Atomic Scientists.
Really? Why? They are an anti-nuclear, anti-science political lobby organization, and always have been.
Yeah, those former Manhattan Project scientists and engineers sure hated science.
uranium 233 has been created, and 96 kilograms of the stuff (enough to fuel 12 nuclear weapons) is now missing from the US national inventory
In addition, they have about 96 kilograms of lead that they don't remember ordering. And the situation gets worse every day!
If they started with 192kg of U-233, there'd be a lot more than 96kg of U-233 and a lot less than 96 kg of Pb around at this point.
If you look at the original post, the AC was disparaging the article for focusing on coding over the 'rest' of computer science
My intent was to point out that coding involves a set of skills that have a wider general application than just focusing on computer science, which could be likened to training a person for a trade
I thought that I was being clear
One thing you said was "Teaching people to rack servers and install operating systems becomes for focused and resembles learning a trade." "Teaching people to rack servers and install operating systems" is, of course, not part of computer science at all; it's also not part of coding, so its relevance to a discussion of coding and/or computer science is, at best, unclear.
(Presumably you're not saying something completely insane, such as likening teaching computer science to teaching people to rack servers and install operating systems. Anybody who "gets" that is completely delusional or completely ignorant of computer science.)
Well, I can't argue with a guy who has trouble with basic reading comprehension. Enjoy pretending that you're right.
Nope, so I won't bother arguing with you any more.
That's what he said.
What he said was "There are elements of coding that require planning, logic and completeness that have impacts far beyond computer science. Teaching people to rack servers and install operating systems becomes for focused and resembles learning a trade."
This says nothing about the latter two items not being elements of coding, so, no, that's not what he said.
He doesn't explicitly say they are elements of coding, but he mentions them in a sentence immediately following a sentence that mentions elements of coding, and does so in a comment to an article discussing coding, so, if he thinks they're not elements of coding, it's not clear why he bothered to mention at all.
There are elements of coding that require planning, logic and completeness that have impacts far beyond computer science. Teaching people to rack servers and install operating systems
Neither racking servers nor installing operating systems are elements of coding. They may be useful skills, but they have nothing to do with coding.
Fine, less code, less bugs... +1 for launchd
Yes, that was precisely my point - does all the extra code make systemd almost 10x better than launchd, or is it better but not by as much, or is it no better or even worse?
And... What is your point?
To ask what benefits the additional almost-9x code brings (especially if the result is deemed inferior)?
I suspect that the people responsible for systemd never even thought to look at already-existing alternatives
Poettering was most definitely aware of launchd.
systemd is just an inferior version of launchd.
Yes, that's almost a factor of 10.
No shit. An operating system that changed the world,
...by being the first widely-available, free-as-in-beer-and-speech (and not under legal threat from AT&T) Unix-compatible OS.
vs. a versioned source control system that makes certain administrative tasks easier.
...and that was most definitely not the first widely-available, free-as-in-beer-and-speech version control system capable of over-the-network access (and not, as far as I know, even the first widely-available, free-as-in-beer-and-speech distributed version control system).
(And it makes some things harder if you're "holding it wrong", but I digress.)
We should not diminish the importance of Linux. But it's clear that Git is much more important today. Linux is wonderful, but its a commodity for most people. It doesn't matter that Android is based on Linux. It's awesome but most people don't care. It's just a technicality.
It's "just a technicality" in the sense that Android might not exist if Linux hadn't existed; saying that it's less relevant because people don't know it's there is like saying that ARM isn't all that important because most people don't know they have ARM processors in their smartphones. Git is even less directly relevant to most people, as they're not developers.
What Linus did by creating GitHub is of tremendously much more importance if you look at how well it brings open source developers together.
Presumably you meant "by creating Git"; as far as I know, he no more created GitHub than he created Android, even if GitHub uses Git and Android uses Linux.
I would say Git is virtually indispensable in development, or at least some form of version control, at this point.
Given that many projects don't use Git, I would not even come close to saying that Git is virtually indispensable in development (unless "virtually" means "not" or otherwise renders the adjective to which it refers meaningless).
I would say that some form of version control is important, but there were plenty of free-software version control systems, supporting over-the-Internet access, available before Git came along, so you can't give credit to Git for that.
I'd love to know the reasons that lead some to believe that "In some ways Git can be seen as his more important contribution".