I think it's just stupid that POSIX programs don't always work the way you expect or are missing (e.g. umount -> diskutil unmount )
umount's still there, and it works the same way it does on other UN*Xes - i.e., if some program has a handle (file descriptor, mapped file, etc.) on the volume to be unmounted, it fails (unless you use the -f flag, to forcibly invalidate those handles and unmount the file system). "diskutil unmount" sends a "hey, could you please let go of any handles you have for this?" request before the actual unmount() call is done, and waits a while for "OK, I've released it" replies before it attempts to unmount.
Unfortunately, a lot of stuff in macOS holds onto those handles - and some stuff just grabs them for the lulz as soon as something's recognized as having been mounted - so, as the umount(8) manual says, "Due to the complex and interwoven nature of Mac OS X, umount may fail often. It is recommended that diskutil(1) (as in, ``diskutil unmount/mnt'') be used instead."
(And it's not in POSIX; it's considered an administrative tool and UNIX(R) systems are allowed not to have it or to implement it as they choose.)
The other side of this is that Linux developers can use it to gain insight to making your favorite Linux distribution run – or run better – on Mac hardware.
...assuming that the code to support the Mac hardware in question is in the kernel, or an open-source kernel extension ("loadable kernel module" in Linux-speak), rather than in a non-open-source kernel extension.
Some of userland is GNU (and some of it may be GNU in various of the *BSDs). Other parts of userland are also from BSD, or written by Apple, or code from various other places. The toolchain, if by that you mean "the compilers, the assembler, and the linker", aren't GNU any more or were never GNU. The assembler and links are from Apple (some possibly ultimately from NeXT); the compilers used to be from GNU, but they're now from the LLVM project.
Like they've done with every version? Of course it's only the code they have to release.
Not true. They don't have to release a lot of it; for example, the XNU kernel is licensed under BSD licenses, the BSDish license under which Mach was released, or the APSL, none of which oblige Apple to release any of it.
You cannot back up files on a HFS disk without losing unix permissions. HFS, NTFS, EXT4 or almost any other file system would work.
Sentence 1 says HFS won't work. Sentence 2 says it will work. In which of those sentences should "HFS" have been something else, and what should it have been in that sentence?
Could but usually doesn't. As the hardware was more costly and slower, and labor relatively cheaper, mainframes ran in some sense "better" code with far less bloat and frillage. An A was just an A (ascii or baudot or ebcdic) - not a picture of a letter in some font taking many times the bits to store and draw for just one example. Audio or video which were (And still are) largely irreducible to small bits/second were right out for real time use.
Mainframes had "acceleration" hardware to compensate. Line printers took a few bits and did the drawing parts (as did plotters for other uses).
The old line printers didn't do any drawing of pixels, they just had a hammer slam a piece of metal, with a character formed on it, against a ribbon, hitting a piece of paper. The laser printers like the IBM 3800 just let the processor in the printer draw all those bits, rather than doing it in the main CPU.
(And, in a file, an A is still just an A, these days - although if it's UTF-16, it's two bytes rather than one. Those pictures aren't stored in most documents.)
Our computers are not descendants of the mainframes that came before them. By now, they have acquired many of the advanced features of mainframes. Implemented badly, several decades later. It is fascinating to learn about the history of mainframes. It is also somewhat depressing.
And sometimes it goes the other way; the IBM z13 microprocessor cracks z/Architecture instructions into micro-ops and schedules and executes the micro-ops, just as the Pentium Pro and later x86 microprocessors do.
But you're probably referring to system architecture characteristics, in addition to CPU characteristics.
(Speaking of system architecture characteristics, the z13 has I/O instructions to bang on PCI space, so you could plug PCI devices in and have minicomputer/microcomputer-style drivers, rather than doing I/O over a traditional data channel. They're not documented in the Principles of Operation, but they're used in some of the Linux code for z/Architecture.)
As the NASA document you cite (HTML FTW!) says, it's "an advanced propulsion physics laboratory, informally known as "Eagleworks"" being implemented by NASA Johnson Space Center (NASA/JSC), so it is part of NASA.
You have guessed incorrectly (I was looking at the screen when I typed this). Go back and examine your premises and discard those that led to this conclusion.
Is this where the fabled escape key has been banished to?
Yes - there were several scenes in the video of the Apple event showing a virtual key labeled "esc" on the left-hand edge of the touch bar (although, as I've noted elsewhere, it's not directly above the {~ `} key, which may get in the way of muscle memory).
I guess you didn't watch the video of the Apple event, where the touch bar had, in many scenes, a button on the left hand edge marked "esc". (As I said in comments for the rumor article, it's not directly above the {~ `} key, so your muscle memory may have some issues with it.)
The Apple event shows a touch bar that, by default, has a button labeled "esc" on the left-hand edge, although, as I commented elsewhere, it's a little bit to the right of where the "esc" key is now - i.e., not directly above the {~ `} key - which, as I said, could interfere with muscle memory.
Apple still sells one laptop with a hard drive - the 13" non-Retina version of the MacBook Pro.
OK, that one was a bit hidden, but if you go to the bottom of the MBP page, and click on "Compare Mac notebooks", it's currently on the left-hand side of the second row.
D00d, you might want to check those links - goat.cx is now a parked domain. You'll need to find the new home for pictures of Mr. Johnson'sworld-famous anus.
No headphone jack. Fewer keys than a VT-100 terminal. Lame.
Hey, even my current MacBook Pro, which does have a headphone jack, has fewer keys than a VT100, so it's not as if the rumored touch-bar-instead-of-a-function-key-row and might-not-have-a-headphone-jack new MacBook Pro is what put them below the VT100.
Depends on the size of your hands to some degree. I find that Ctrl-C Ctrl-V for example requires twisting the left wrist outward so the hand is angled to the left, and also requires stretching the fingers apart. The natural resting positions of hands which are together in front of you on a keyboard is for the hands to be pointed inward (left hand angled slightly to the right) with fingers not stretched in tendon tension apart.
For what it's worth, when I do Ctrl+{something} on my MacBook Pro's keyboard, I move my left hand off the home row and, if {something} is on the left-hand side of the keyboard, use my index finger for {something}; that might even predate using an MBP. The same applies to Cmd+{something}, although I use my thumb for Cmd.
So one possibility is that Terminal labels that part of the touch bar "Esc" (or, in Apple hipster lower-case style, "esc"), and touching it sends \033 down the pseudo-tty to the currently-running program. That's the one I'm putting my money on, although I'm biased by being a microEmacs user who would want that to be the case.
Although the "Cancel" isn't directly above the (~ `) key, so it's not quite where the esc key is currently, which could interfere with muscle memory, grumble grumble. We'll have to see what Terminal does with the touch bar.
Slashdot Mirror
I think it's just stupid that POSIX programs don't always work the way you expect or are missing (e.g. umount -> diskutil unmount )
umount's still there, and it works the same way it does on other UN*Xes - i.e., if some program has a handle (file descriptor, mapped file, etc.) on the volume to be unmounted, it fails (unless you use the -f flag, to forcibly invalidate those handles and unmount the file system). "diskutil unmount" sends a "hey, could you please let go of any handles you have for this?" request before the actual unmount() call is done, and waits a while for "OK, I've released it" replies before it attempts to unmount.
Unfortunately, a lot of stuff in macOS holds onto those handles - and some stuff just grabs them for the lulz as soon as something's recognized as having been mounted - so, as the umount(8) manual says, "Due to the complex and interwoven nature of Mac OS X, umount may fail often. It is recommended that diskutil(1) (as in, ``diskutil unmount /mnt'') be used instead."
(And it's not in POSIX; it's considered an administrative tool and UNIX(R) systems are allowed not to have it or to implement it as they choose.)
I mean, fair enough, the OS code they release is only the code they "have" to release
Actually, as I said in another post, they don't even "have" to release all of the OS code.
There's tons of source code they've released that they didn't have to: clang ...
...XNU, the C library, a bunch of kernel extensions, and so on.
The other side of this is that Linux developers can use it to gain insight to making your favorite Linux distribution run – or run better – on Mac hardware.
...assuming that the code to support the Mac hardware in question is in the kernel, or an open-source kernel extension ("loadable kernel module" in Linux-speak), rather than in a non-open-source kernel extension.
Understand that the MacBook OS is a BSD kernel
Well, Mach+BSD, but both are open source.
the GNU OS (tool chain)
Some of userland is GNU (and some of it may be GNU in various of the *BSDs). Other parts of userland are also from BSD, or written by Apple, or code from various other places. The toolchain, if by that you mean "the compilers, the assembler, and the linker", aren't GNU any more or were never GNU. The assembler and links are from Apple (some possibly ultimately from NeXT); the compilers used to be from GNU, but they're now from the LLVM project.
Like they've done with every version? Of course it's only the code they have to release.
Not true. They don't have to release a lot of it; for example, the XNU kernel is licensed under BSD licenses, the BSDish license under which Mach was released, or the APSL, none of which oblige Apple to release any of it.
Apple already makes the Macbook Pros in the US.
MacBook Pro, or Mac Pro?
You cannot back up files on a HFS disk without losing unix permissions. HFS, NTFS, EXT4 or almost any other file system would work.
Sentence 1 says HFS won't work. Sentence 2 says it will work. In which of those sentences should "HFS" have been something else, and what should it have been in that sentence?
Could but usually doesn't. As the hardware was more costly and slower, and labor relatively cheaper, mainframes ran in some sense "better" code with far less bloat and frillage. An A was just an A (ascii or baudot or ebcdic) - not a picture of a letter in some font taking many times the bits to store and draw for just one example. Audio or video which were (And still are) largely irreducible to small bits/second were right out for real time use. Mainframes had "acceleration" hardware to compensate. Line printers took a few bits and did the drawing parts (as did plotters for other uses).
The old line printers didn't do any drawing of pixels, they just had a hammer slam a piece of metal, with a character formed on it, against a ribbon, hitting a piece of paper. The laser printers like the IBM 3800 just let the processor in the printer draw all those bits, rather than doing it in the main CPU.
(And, in a file, an A is still just an A, these days - although if it's UTF-16, it's two bytes rather than one. Those pictures aren't stored in most documents.)
Our computers are not descendants of the mainframes that came before them. By now, they have acquired many of the advanced features of mainframes. Implemented badly, several decades later. It is fascinating to learn about the history of mainframes. It is also somewhat depressing.
And sometimes it goes the other way; the IBM z13 microprocessor cracks z/Architecture instructions into micro-ops and schedules and executes the micro-ops, just as the Pentium Pro and later x86 microprocessors do.
But you're probably referring to system architecture characteristics, in addition to CPU characteristics.
(Speaking of system architecture characteristics, the z13 has I/O instructions to bang on PCI space, so you could plug PCI devices in and have minicomputer/microcomputer-style drivers, rather than doing I/O over a traditional data channel. They're not documented in the Principles of Operation, but they're used in some of the Linux code for z/Architecture.)
I suspect he may be channeling Peter Thiel.
They are directly related. https://ntrs.nasa.gov/search.j...
As the NASA document you cite (HTML FTW!) says, it's "an advanced propulsion physics laboratory, informally known as "Eagleworks"" being implemented by NASA Johnson Space Center (NASA/JSC), so it is part of NASA.
I guess you look at the keyboard when you type.
You have guessed incorrectly (I was looking at the screen when I typed this). Go back and examine your premises and discard those that led to this conclusion.
I'm not buying it
Given that it does have a headphone jack (look under "Charging and Expansion"), will you be buying it?
Is this where the fabled escape key has been banished to?
Yes - there were several scenes in the video of the Apple event showing a virtual key labeled "esc" on the left-hand edge of the touch bar (although, as I've noted elsewhere, it's not directly above the {~ `} key, which may get in the way of muscle memory).
And I don't see an escape key. :(
I guess you didn't watch the video of the Apple event, where the touch bar had, in many scenes, a button on the left hand edge marked "esc". (As I said in comments for the rumor article, it's not directly above the {~ `} key, so your muscle memory may have some issues with it.)
The Apple event shows a touch bar that, by default, has a button labeled "esc" on the left-hand edge, although, as I commented elsewhere, it's a little bit to the right of where the "esc" key is now - i.e., not directly above the {~ `} key - which, as I said, could interfere with muscle memory.
Apple still sells one laptop with a hard drive - the 13" non-Retina version of the MacBook Pro.
OK, that one was a bit hidden, but if you go to the bottom of the MBP page, and click on "Compare Mac notebooks", it's currently on the left-hand side of the second row.
laptops with easy to get to disks.
Apple still sells laptops with disks? News to me....
don't want to feel troubles of Walnut [mi7.edu] found 4erspective, the for the project. So on, FreeBSD went
D00d, you might want to check those links - goat.cx is now a parked domain. You'll need to find the new home for pictures of Mr. Johnson's world-famous anus.
No headphone jack. Fewer keys than a VT-100 terminal. Lame.
Hey, even my current MacBook Pro, which does have a headphone jack, has fewer keys than a VT100, so it's not as if the rumored touch-bar-instead-of-a-function-key-row and might-not-have-a-headphone-jack new MacBook Pro is what put them below the VT100.
released a more performant iPad
"Performant"?
to bad the new mac pro missed the mark and they sat on it.
Sitting on a 6.6" Mac Pro probably won't be very comfortable. (Yes, I refrained from posting a link to a picture of Kirk Johnson here. :-))
Depends on the size of your hands to some degree. I find that Ctrl-C Ctrl-V for example requires twisting the left wrist outward so the hand is angled to the left, and also requires stretching the fingers apart. The natural resting positions of hands which are together in front of you on a keyboard is for the hands to be pointed inward (left hand angled slightly to the right) with fingers not stretched in tendon tension apart.
For what it's worth, when I do Ctrl+{something} on my MacBook Pro's keyboard, I move my left hand off the home row and, if {something} is on the left-hand side of the keyboard, use my index finger for {something}; that might even predate using an MBP. The same applies to Cmd+{something}, although I use my thumb for Cmd.
So one possibility is that Terminal labels that part of the touch bar "Esc" (or, in Apple hipster lower-case style, "esc"), and touching it sends \033 down the pseudo-tty to the currently-running program. That's the one I'm putting my money on, although I'm biased by being a microEmacs user who would want that to be the case.
Although the "Cancel" isn't directly above the (~ `) key, so it's not quite where the esc key is currently, which could interfere with muscle memory, grumble grumble. We'll have to see what Terminal does with the touch bar.
Mac users probably don't use the Escape key too much, let alone the function keys.
THIS Mac user uses the Esc key all the time to dismiss OS X/macOS Dialogs.
Which may be why there's something labeled "Cancel" at the left edge of the touch bar in one of the images from TFA.
(And THIS Mac user uses the Esc key all the time to start commands in microEmacs in Terminal, but I digress....)