To be honest, it was not my Mac, and I have little knowledge of what its owner had done before I touched it (but he seemed equally annoyed).
Perhaps he accidentally did set -C, then.
The point was more about features that stop you from overwriting files than about Mac OS X.
Then it would more accurately have been stated as "Ironically, the fact that bash on a coworker's machine did not let you overwrite files...", or something such as that, so as to clearly indicate that it had absolutely nothing to do with Mac OS X. I.e., you can't blame that one on Apple.
Yes, features that prevent you from doing things can be annoying (and, yes, that sometimes goes for dialog boxes, e.g. if I just want to dump something to/tmp/patch - or, given e.g. Safari's insistence on calling all text files something.txt,/tmp/patch.txt - as the latest patch to look at and apply to whatever, it can be a nuisance). However, features that don't prevent you from doing things can be annoying, too, if you end up destroying a valuable file because of a typo. Fortunately, at least at the command line, -C isn't the default, even on Mac OS X, and you can override it with >| if you want it set to protect yourself.
Basically Apple is just implementing Mandatory Access Control (MAC).
Yup, the Mac OS X sandbox stuff is built atop the MAC hooks.
We Linux fans love to boast about SELinux, but SELinux is just a way of sandboxing everything via MAC.
"Everything" can be a bit annoying. My Fedora virtual machine can't mount hgfs due to the SELinux sandboxing, which makes it a bit of a pain to move stuff between my Mac and the Fedora VM; given that I can scp stuff to it when I need to, and that my Ubuntu machine doesn't get in hgfs's way and is less of a pain to work on in other ways when I need a Linux development platform, I haven't bothered trying to fix it.
The Apple sandboxing doesn't sandbox everything, so if, for example, the VMware guest software needed to add kernel extensions or mount file systems, it wouldn't have to fight its way out of the sandbox.
Now, the problem with Apple is that when they do this they make themselves into the system administrator, which is inappropriate. The computer owner should always be the one in charge, but they should be free to delegate this authority to Apple if they can later revoke that decision and take back control of their device.
As noted, sandboxing is a per-app policy, not a system-wide policy, in Mac OS X, so it's a bit different.
The problem right now is that Linux software developers are not unlike Windows developers in assuming that the app runs with broad permissions, and bolting on MAC after the fact is like trying to lock down a copy of Windows XP when running apps written for Windows 98.
And this is different from Mac OS X how? There are apps out there that had to be modified to work in a sandbox, including some apps named "TextEdit" and "Preview". (Heck, there are some system daemons that needed some work to fit in a sandbox....)
That's what Lion is, the start of a dumbing down of Apple's software basically making it iOS on a desktop/laptop platform, because everyone knows serious computer users don't use Mac's, it's moving to consumer (read cattle) only./me braces for the inevitable Pro Apple backlash.
You presumably meant "braces for the inevitable mistaken backlash from people who don't realize you're making fun of some anti-Apple types". ("Because everyone knows serious computer users don't use Mac's" was a dead giveaway; only that particular anti-Apple type would believe a claim as idiotic as that.)
My understanding is that applications won't be able to see other users's files.
Sounds like UNIX to me. And, gee, that's been around for only 40 years.
No, applications won't be able to see other applications' files that belong to you. The Multics/UNIX/VMS/Windows NT permissions model may have been sufficient in a world of time-sharing machines where you were more likely to trust apps than to trust other users, so a permissions model that protected you from other users on the machine or on your network did the trick. A world where you can't trust apps that you yourself run is different.
Like, say, if you want to write a backup application? How about a photo management application that allows bulk-importing of images from a camera or SD card? (The second one is something that iPad users would like, but which is impossible on iPad due to the restrictions on SD card access; it appears the Mac App Store is heading in the same direction.)
The Mac App Store is heading in a direction that means that backup applications and photo management apps of the sort will have to be sold through other means. This may simply mean that the Mac is heading in a direction wherein, due to the restrictions on apps sold in the Mac App Store, it will never be the case that all useful applications for it are sold through the Mac App Store.
Perhaps cartoons are not the best source of information regarding things you clearly have no experience with.
There was a time when I did modify an X server configuration file whilst setting up my old PC. I'm glad I don't have to do that any more, because having to do so did not improve my life in any fashion whatsoever; it wasted time that could be better spent, say, working on libpcap or tcpdump or Wireshark or file or the time zone code or....
You may be missing the real joke there.
The real, sad joke is that there are probably people out there proud of having configured their system by editing xorg.conf. If they had, for example, written or enhanced a useful piece of free software in the time they spent editing xorg.conf, that would be something to be proud of.
If that's an app I've installed specifically for its screenshot abilities, cool! If not, I don't want it running on my desktop. I don't want a text editor connecting to Facebook or an instant messenger to open a disk device node. Systems like SELinux implement these permissions as access controls. Apple seems to have decided to implement them at the code review level.
Is there some reason to think that they would not do such a thing? I have said it before, but my prediction is that the Mac line is going to be split into two separate lines, one which targets professionals and one which targets consumers. The consumer line will be locked down and marketed as "appliances," while the professional line will be high-priced but permit the installation of unapproved software. We are watching a steady buildup toward that situation.
Apple already has a line of locked-down machines marketed as "appliances"; is there any reason to believe, with a high degree of certainty, that they want to have a second separate line? ("They need ones that support a keyboard and mouse" isn't it; the line of machines in question already supports physical keyboards, and could conceivably at least support trackpads, that being the direction in which Apple's moving for their other line of machines.)
On the other hand, this is the latest in a long series of steps towards Mac OS X becoming both more iOS-like and more tightly locked down, and at each step people have insisted that the obvious next step is completely absurd and that you shouldn't extrapolate like that.
And the previous steps towards making it more locked down were? (No, "Don't Steal Mac OS X" isn't obviously such a step; it's just moving the "Mac OS X only runs on computers from Apple" policy enforcement from hardware, as in "the only major source of PowerPC-based personal computers is Apple, and Mac OS X only runs on PowerPC-based personal computers", to software. "More iOS-like" in the sense of, say, some of the new features in Lion is separate from "more tightly locked down".)
Ironically, the fact that bash on Mac OS X does not let you overwrite files when you redirect a program's output was an annoyance yesterday. Before anyone asks, yes, we did read the manual and found out how to disable that feature.
WTF?
$ echo $SHELL /bin/bash $ echo "this is a test" >/tmp/testme $ echo "this is a testicle" >/tmp/testme $ cat/tmp/testme this is a testicle
You didn't accidentally do set -C, did you?/etc/bashrc in Snow Leopard, at least, does
# System-wide.bashrc file for interactive bash(1) shells. if [ -z "$PS1" ]; then return fi
PS1='\h:\W \u\$ ' # Make bash check its window size after a process completes shopt -s checkwinsize
My toaster has two inputs. One is a knob that determines how long the bread is toasted, and the other starts the process of toasting. Now, would you prefer that, which requires you to understand how far to turn the knob in order to get the sort of toast you want, or would you prefer if someone removed the knob, created a toaster that "just works" and told you that if you want a different sort of toast you need to pick the lock on the back of your toaster?
I guess my Mac's like your toaster, then, given that it has a brightness control for the screen and a volume control for the sound; it doesn't claim to "just work" by adjusting the brightness and volume for me and require me to pick a lock to adjust either the screen brightness or the sound myself.
Now, if you had to adjust the brightness or volume by setting numbers in memory by using a debugger with the kernel or a daemon, poking variables....
Most people do not really lack intelligence. What most people lack is a motivation to make use of their intelligence; they would rather have other people do their thinking for them. Why spend time reading a manual and learning how to use your computer, when all you really wanted to do was go to Youtube and watch cool videos that other people created?
Many people lack a motivation to use their intelligence in the ways that some people might think they should. For example, I have no motivation at all to, for example, devote any of my intelligence whatsoever to looking at or editing an xorg.conf file - I'd rather devote it to something useful, such as developing software - so, were Mac OS X to get to the point where I can't fire up a Terminal window, run builds, run the resulting software and do so as root if necessary, I'd probably end up switching to something such as Ubuntu or PC-BSD for development purposes.
While I agree that we need xattr style metadata that describes the file in some circumstances, I think most use-cases are simply misunderstanding the concept of a proper file structure.
That said, it would be great to be able to do interesting things from the *nix command-line like:
That's not just a file-vs-directory issue, it's a rename() vs. MoveFile() issue. If the target exists, rename() attempts to remove it, but MoveFile() fails. That's even true for files. For files, but not directories, MoveFileTransacted() can be told to overwrite the target if it exists (I say "overwrite" because the description of MoveFileTransacted() says "If a file named lpNewFileName exists, the function replaces its contents with the contents of the lpExistingFileName file").
Oh, and if a required attempt by rename() to remove the destination fails, the rename() fails, so the target directory had better be empty if you're moving something in its place. If you're renaming or moving a directory, and the destination doesn't exist, and the source and destination are on the same file system, both rename() and MoveFile() are atomic, even if the directory being moved is non-empty.
In any case, it's not as if this is Not A Problem on UN*X and A Problem on Windows, much less being solely due to MoveFile() not supporting atomic moves of directories within a file system if the target name already exists.
The thing is, those particular file systems also use a different notion of what a file is than what Unix folks are used to. One major example of this is that on these systems, a file can contain multiple streams of data, which both NTFS and HFS+ call forks.
(...and UFS and ZFS on newer versions of Solaris call "extended attributes", even though they are arbitrary-sized named streams.)
Files-11 and HFS+ also support a notion of files as being containers of discrete data records, rather than streams of bytes.
Files-11, or, at least, RMS (no, not that RMS:-)), was probably inspired by OS/360 and successors in that regard. However, at the lowest layer of Files-11 (QIO), a file could be accessed as an array of fixed-length blocks; the record-oriented stuff ran atop that (in userland in RSX-11; in, as I remember, executive mode in VMS). It sounds as if you're talking about the Resource Manager in Mac OS; I don't know whether that was implemented atop "resource fork as seekable byte stream" in classic Mac OS, but it's definitely implemented that way in Mac OS X.
In case anybody's wondering "WTF?", that was a response not to the previous poster's comment, but to the previous posters signature "You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!" - i.e., it's arguably offtopic, but still amusing.
3) I'm looking at Darwin on ARM right now, on my iPhone. And my iPad. And the iPod Touch located nearby. ARM is an architecture, not some exclusive hardware platform.
Apple is so open they made their own OS out of BSD.
And that makes them less open because?
(Besides, it's more like "Apple is so open they bought NeXT, who had made their own OS out of the Mach kernel and BSD kernel and userland code, back in the days before BSD was open source, when they needed a new OS, and built an OS based on a lot of the NeXT code".)
iPhone:~ root# uname -a
Darwin iPhone 9.4.1 Darwin Kernel Version 9.4.1: Mon Dec 8 20:59:30 PST 2008; root:xnu-1228.7.37~4/RELEASE_ARM_S5L8900X iPhone1,2 arm N82AP Darwin
There's "see" in the sense of "see uname printing "Darwin" on an ARM-based machine" and there's "see" in the sense of "see the source to the ARM support code in Darwin up on opensource.apple.com". I suspect, given that the person to whom you're responding and the person to whom they were responding both talked about open source, that the person to whom you're responding meant "see" in the latter sense.
Slashdot Mirror
To be honest, it was not my Mac, and I have little knowledge of what its owner had done before I touched it (but he seemed equally annoyed).
Perhaps he accidentally did set -C, then.
The point was more about features that stop you from overwriting files than about Mac OS X.
Then it would more accurately have been stated as "Ironically, the fact that bash on a coworker's machine did not let you overwrite files...", or something such as that, so as to clearly indicate that it had absolutely nothing to do with Mac OS X. I.e., you can't blame that one on Apple.
Yes, features that prevent you from doing things can be annoying (and, yes, that sometimes goes for dialog boxes, e.g. if I just want to dump something to /tmp/patch - or, given e.g. Safari's insistence on calling all text files something .txt, /tmp/patch.txt - as the latest patch to look at and apply to whatever, it can be a nuisance). However, features that don't prevent you from doing things can be annoying, too, if you end up destroying a valuable file because of a typo. Fortunately, at least at the command line, -C isn't the default, even on Mac OS X, and you can override it with >| if you want it set to protect yourself.
If Apple's own apps run in the sandbox, that's fine.
iTunes, not currently, as far as I know. TextEdit and Preview, yes, in Lion.
Basically Apple is just implementing Mandatory Access Control (MAC).
Yup, the Mac OS X sandbox stuff is built atop the MAC hooks.
We Linux fans love to boast about SELinux, but SELinux is just a way of sandboxing everything via MAC.
"Everything" can be a bit annoying. My Fedora virtual machine can't mount hgfs due to the SELinux sandboxing, which makes it a bit of a pain to move stuff between my Mac and the Fedora VM; given that I can scp stuff to it when I need to, and that my Ubuntu machine doesn't get in hgfs's way and is less of a pain to work on in other ways when I need a Linux development platform, I haven't bothered trying to fix it.
The Apple sandboxing doesn't sandbox everything, so if, for example, the VMware guest software needed to add kernel extensions or mount file systems, it wouldn't have to fight its way out of the sandbox.
Now, the problem with Apple is that when they do this they make themselves into the system administrator, which is inappropriate. The computer owner should always be the one in charge, but they should be free to delegate this authority to Apple if they can later revoke that decision and take back control of their device.
As noted, sandboxing is a per-app policy, not a system-wide policy, in Mac OS X, so it's a bit different.
The problem right now is that Linux software developers are not unlike Windows developers in assuming that the app runs with broad permissions, and bolting on MAC after the fact is like trying to lock down a copy of Windows XP when running apps written for Windows 98.
And this is different from Mac OS X how? There are apps out there that had to be modified to work in a sandbox, including some apps named "TextEdit" and "Preview". (Heck, there are some system daemons that needed some work to fit in a sandbox....)
That's what Lion is, the start of a dumbing down of Apple's software basically making it iOS on a desktop/laptop platform, because everyone knows serious computer users don't use Mac's, it's moving to consumer (read cattle) only. /me braces for the inevitable Pro Apple backlash.
You presumably meant "braces for the inevitable mistaken backlash from people who don't realize you're making fun of some anti-Apple types". ("Because everyone knows serious computer users don't use Mac's" was a dead giveaway; only that particular anti-Apple type would believe a claim as idiotic as that.)
My understanding is that applications won't be able to see other users's files.
Sounds like UNIX to me. And, gee, that's been around for only 40 years.
No, applications won't be able to see other applications' files that belong to you. The Multics/UNIX/VMS/Windows NT permissions model may have been sufficient in a world of time-sharing machines where you were more likely to trust apps than to trust other users, so a permissions model that protected you from other users on the machine or on your network did the trick. A world where you can't trust apps that you yourself run is different.
This is likely based on work from MIT and Google:
http://people.csail.mit.edu/jansel/papers/2011pldi-nacljit.pdf
No, it's for C/C++/Objective-C code, not code JITted into machine code.
Like, say, if you want to write a backup application? How about a photo management application that allows bulk-importing of images from a camera or SD card? (The second one is something that iPad users would like, but which is impossible on iPad due to the restrictions on SD card access; it appears the Mac App Store is heading in the same direction.)
The Mac App Store is heading in a direction that means that backup applications and photo management apps of the sort will have to be sold through other means. This may simply mean that the Mac is heading in a direction wherein, due to the restrictions on apps sold in the Mac App Store, it will never be the case that all useful applications for it are sold through the Mac App Store.
Perhaps cartoons are not the best source of information regarding things you clearly have no experience with.
There was a time when I did modify an X server configuration file whilst setting up my old PC. I'm glad I don't have to do that any more, because having to do so did not improve my life in any fashion whatsoever; it wasted time that could be better spent, say, working on libpcap or tcpdump or Wireshark or file or the time zone code or....
You may be missing the real joke there.
The real, sad joke is that there are probably people out there proud of having configured their system by editing xorg.conf. If they had, for example, written or enhanced a useful piece of free software in the time they spent editing xorg.conf, that would be something to be proud of.
If that's an app I've installed specifically for its screenshot abilities, cool! If not, I don't want it running on my desktop. I don't want a text editor connecting to Facebook or an instant messenger to open a disk device node. Systems like SELinux implement these permissions as access controls. Apple seems to have decided to implement them at the code review level.
...and at the access controls level, at least for some of those.
Is there some reason to think that they would not do such a thing? I have said it before, but my prediction is that the Mac line is going to be split into two separate lines, one which targets professionals and one which targets consumers. The consumer line will be locked down and marketed as "appliances," while the professional line will be high-priced but permit the installation of unapproved software. We are watching a steady buildup toward that situation.
Apple already has a line of locked-down machines marketed as "appliances"; is there any reason to believe, with a high degree of certainty, that they want to have a second separate line? ("They need ones that support a keyboard and mouse" isn't it; the line of machines in question already supports physical keyboards, and could conceivably at least support trackpads, that being the direction in which Apple's moving for their other line of machines.)
On the other hand, this is the latest in a long series of steps towards Mac OS X becoming both more iOS-like and more tightly locked down, and at each step people have insisted that the obvious next step is completely absurd and that you shouldn't extrapolate like that.
And the previous steps towards making it more locked down were? (No, "Don't Steal Mac OS X" isn't obviously such a step; it's just moving the "Mac OS X only runs on computers from Apple" policy enforcement from hardware, as in "the only major source of PowerPC-based personal computers is Apple, and Mac OS X only runs on PowerPC-based personal computers", to software. "More iOS-like" in the sense of, say, some of the new features in Lion is separate from "more tightly locked down".)
Ironically, the fact that bash on Mac OS X does not let you overwrite files when you redirect a program's output was an annoyance yesterday. Before anyone asks, yes, we did read the manual and found out how to disable that feature.
WTF?
You didn't accidentally do set -C, did you? /etc/bashrc in Snow Leopard, at least, does
and that's it.
My toaster has two inputs. One is a knob that determines how long the bread is toasted, and the other starts the process of toasting. Now, would you prefer that, which requires you to understand how far to turn the knob in order to get the sort of toast you want, or would you prefer if someone removed the knob, created a toaster that "just works" and told you that if you want a different sort of toast you need to pick the lock on the back of your toaster?
I guess my Mac's like your toaster, then, given that it has a brightness control for the screen and a volume control for the sound; it doesn't claim to "just work" by adjusting the brightness and volume for me and require me to pick a lock to adjust either the screen brightness or the sound myself.
Now, if you had to adjust the brightness or volume by setting numbers in memory by using a debugger with the kernel or a daemon, poking variables....
Most people do not really lack intelligence. What most people lack is a motivation to make use of their intelligence; they would rather have other people do their thinking for them. Why spend time reading a manual and learning how to use your computer, when all you really wanted to do was go to Youtube and watch cool videos that other people created?
Many people lack a motivation to use their intelligence in the ways that some people might think they should. For example, I have no motivation at all to, for example, devote any of my intelligence whatsoever to looking at or editing an xorg.conf file - I'd rather devote it to something useful, such as developing software - so, were Mac OS X to get to the point where I can't fire up a Terminal window, run builds, run the resulting software and do so as root if necessary, I'd probably end up switching to something such as Ubuntu or PC-BSD for development purposes.
While I agree that we need xattr style metadata that describes the file in some circumstances, I think most use-cases are simply misunderstanding the concept of a proper file structure.
That said, it would be great to be able to do interesting things from the *nix command-line like:
cat somecomplexfile.dat}meta=text | grep somethinginteresting
Where "}" is a delimiter I invented that allows selection of subsections of a file.
Or just
.
I'm not talking about GUI at all. http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows
That's not just a file-vs-directory issue, it's a rename() vs. MoveFile() issue. If the target exists, rename() attempts to remove it, but MoveFile() fails. That's even true for files. For files, but not directories, MoveFileTransacted() can be told to overwrite the target if it exists (I say "overwrite" because the description of MoveFileTransacted() says "If a file named lpNewFileName exists, the function replaces its contents with the contents of the lpExistingFileName file").
Oh, and if a required attempt by rename() to remove the destination fails, the rename() fails, so the target directory had better be empty if you're moving something in its place. If you're renaming or moving a directory, and the destination doesn't exist, and the source and destination are on the same file system, both rename() and MoveFile() are atomic, even if the directory being moved is non-empty.
In any case, it's not as if this is Not A Problem on UN*X and A Problem on Windows, much less being solely due to MoveFile() not supporting atomic moves of directories within a file system if the target name already exists.
The thing is, those particular file systems also use a different notion of what a file is than what Unix folks are used to. One major example of this is that on these systems, a file can contain multiple streams of data, which both NTFS and HFS+ call forks.
(...and UFS and ZFS on newer versions of Solaris call "extended attributes", even though they are arbitrary-sized named streams.)
Files-11 and HFS+ also support a notion of files as being containers of discrete data records, rather than streams of bytes.
Files-11, or, at least, RMS (no, not that RMS :-)), was probably inspired by OS/360 and successors in that regard. However, at the lowest layer of Files-11 (QIO), a file could be accessed as an array of fixed-length blocks; the record-oriented stuff ran atop that (in userland in RSX-11; in, as I remember, executive mode in VMS). It sounds as if you're talking about the Resource Manager in Mac OS; I don't know whether that was implemented atop "resource fork as seekable byte stream" in classic Mac OS, but it's definitely implemented that way in Mac OS X.
jobs: you will pry my source code out of my cold dead hand.
god: ok.
satan: both of you forgot about darwin and the stuff other than alac at mac os forge and stuff such as clang and lldb at llvm.org....
The vast majority of portable, dedicated digital music devices are made by Apple
Among marketers, "devices" has become a euphemism for locked-down appliances, so I got a bit confused.
And when I hear "devices", I think of something else.
Here you go:
http://www.thingiverse.com/thing:249
In case anybody's wondering "WTF?", that was a response not to the previous poster's comment, but to the previous posters signature "You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!" - i.e., it's arguably offtopic, but still amusing.
3) I'm looking at Darwin on ARM right now, on my iPhone. And my iPad. And the iPod Touch located nearby. ARM is an architecture, not some exclusive hardware platform.
I suspect he meant "see Darwin source to support ARM".
Apple is so open they made their own OS out of BSD.
And that makes them less open because?
(Besides, it's more like "Apple is so open they bought NeXT, who had made their own OS out of the Mach kernel and BSD kernel and userland code, back in the days before BSD was open source, when they needed a new OS, and built an OS based on a lot of the NeXT code".)
Yeh, clearly apple only open sources things they have to. Because clang, alac, cups, ... don't exist.
"Darwin" would be a better choice than "cups" here; CUPS wasn't originally written by somebody at Apple (Apple hired Michael Sweet several years after CUPS came out), and was licensed under the GPL (and is now licensed under "the GNU General Public License ("GPL") and GNU Library General Public License ("LGPL"), Version 2, with exceptions for Apple operating systems and the OpenSSL toolkit").
Or AFLAC. Would you rather a penis shape or a duck that sounds like Gilbert Gottfried?
I want a penis-shaped duck that sounds like Gilbert Gottfried. Or maybe a penis, shaped like a duck, that sounds like Gilbert Gottfried.
I doubt you'll ever even see Darwin for ARM.
What ?
iPhone:~ root# uname -a Darwin iPhone 9.4.1 Darwin Kernel Version 9.4.1: Mon Dec 8 20:59:30 PST 2008; root:xnu-1228.7.37~4/RELEASE_ARM_S5L8900X iPhone1,2 arm N82AP Darwin
There's "see" in the sense of "see uname printing "Darwin" on an ARM-based machine" and there's "see" in the sense of "see the source to the ARM support code in Darwin up on opensource.apple.com". I suspect, given that the person to whom you're responding and the person to whom they were responding both talked about open source, that the person to whom you're responding meant "see" in the latter sense.