TFirst, TermKit combines two different "re"-envisionings of the shell.
Some potential users might find one of those ideas useful (realizing that having command output intended to be parsed by humans or by other commands can result in output that's not as human-readable as you'd like and not as software-parseable as you'd like, a notion that also showed up on LinuXML/XMLTERM and, as noted elsewhere, in PowerShell) and another not (the moving beyond a text interface). The latter doesn't personally interest me; if I want to tweak something from the GUI, there's already GUI code for that - if I want to do command-line stuff, I don't need each command-line token looking like a GUI widget with icons attached to them, I don't need pipe bars looking like big blobs, etc..
Perhaps there's a market for the second part, but I'm not sure what it is. If it helps people who could usefully use a command line learn it, without getting in the way of people not frightened by the command line, then it might be worth the effort.
There was a GIF out several years back, which I haven't been able to find any time recently (and would love a pointer to) of some guy who had something like *19* hardware emulators running on one monitor simultaneously, in 4 or 5 separate stacks.
TRS-80, C-64, T/S-1000; everything you've ever seen an emulator for, he had running on Linux all at the same time; some hosting others.
Didn't you get the memo? Any new technology involves adding a "chip" to your {cell phone, table, computer, server,...}. After all, it's not as if you can add new capabilities to a machine by updating its software....
"If it's using a framework where the run loop is inside the framework, the Snow Leopard and later version of the framework might use GCD, but if you have your own run loop...."
GCD requires the application developer to explicitly call dispatch_async and pass in the task blocks to be executed.
Despite the obvious satire, the answer is yes, since the system handles GCD for the software running on it:p
Well, no, actually, the system doesn't magically make all software use GCD. If it's using a framework where the run loop is inside the framework, the Snow Leopard and later version of the framework might use GCD, but if you have your own run loop....
I've had complaints about OS X, but problems with case-sensitive HFS+ is not among them -- in spite of the fact that all the years I used OS X installed on case-sensitive HFS+, boot volume and all, with never a lick of trouble.
Perhaps you've been lucky. I've seen very few problems with case-sensitive file systems, but they do exist, as those of us with home directories on case-sensitive NFS servers occasionally find out. (I'm looking at you, Google....)
Unfortunately, OS X's tty driver doesn't implement the delay modes needed for an {ASR,KSR}33, or, for that matter, an {ASR,KSR}35, so you probably won't have much luck attaching one of them to a Mac. It's a damn shame....
Wimp. A keypunch with a fucking Backspace key, so you don't have to get it right the first time or waste a card? Real menu use an 029. (I'd say an 026, but that might not have had the character set you need; if it did, you might as well go The Full Monty and get an 024 - who needs to see what's on the card printed on the top?)
I'd say "using gconf to set a default size in certain versions of GNOME Terminal would be a crock even if it weren't broken"; the moral equivalent in Mac OS X would be requiring that you use the defaults command, or the plist editor if you want a GUI, to set the default terminal size in Terminal.app.
but looking at the gnome-terminal 2.33.90 shows a "Use custom default terminal size" (yeah I know that page talks about Ubuntu but the option was there in a Fedora 15 Alpha live CD too). gnome-terminal 2.30 and peering at gnome-terminal's git suggests the option would have gone in around 2.31.
It looks as if they broke it while fixing another bug, and finally got around to putting it back. I don't remember the ability to set it ever being broken in Terminal.app (the UI for it changed when they did a rewrite). Unfortunately, I haven't yet freed up enough disk space to add an Ubuntu 10 VM on my Mac to my other N VMs.
But hey - Slashdot ain't a bug tracker so here might not have been the best place to ask (even if you did work at NetApp)...:)
I was really just snarking about the CLI-in-the-GUI on a non-OS X desktop environment.
Yeah, I remember that when it was mentioned on Slashdot, and the usual low S/N ratio discussion that followed. And, surprise surprise, Apple made the source to the Intel versions available, so Apple didn't "close down OS X", they just hadn't gotten around to releasing the source yet. Way to jump to a conclusion, dude....
Read the context. We are talking in terms of a hypothetical where Macs are the ones being locked down. You aren't disagreeing with my point you are agreeing that Macs support for iOS is what makes this possible.
Actually, what I'm saying is that I'm not sure why the heck Apple would bother locking down Macs, rather than just saying "we sell iOS machines for people who are happy with machines that can only run software that we bless, and we sell Macs for people who aren't", which is what they are, in effect, saying now.
Who the hell uses OSX anymore? The apple fan base gets a lot of publicity but its mainly gadgets not their computers.... Though the NeXT based kernel concept is cute, nobody really cares anymore, especially about anything to do with BSD - Monolithic kernels won the war when they started to develop good realtime characteristics.
1) xnu is a monolithic kernel in practice. Yeah, some stuff is done by upcalls to userland, but you'll find those in monolithic kernels as well. 2) The "gadgets" use that kernel, too.
You cannot recompile Samba and substitute the Apple-provided system component that's based on Samba with the one you compiled on your own.
Why not? Will launchd refuse to start/usr/sbin/smbd if it hasn't been sprinkled with holy water?
If you use OS X to mount SMB shares, you can only do so with Apple binaries, not with your own binaries (unless you go via MacFuSE, that is)
As noted, if you're talking about Samba, that's "export SMB shares from your machine", not "mount SMB shares", and you've not provided any evidence that you can't just build your own smbd etc. and install them and run them (and, no, "butbutbut the copies that ship with OS X are signed!!!!!!1111ONE!!!!!" isn't evidence; the OS has to care that they're signed - the only evidence I'll believe is if somebody tries it and it fails). If you're talking about mounting SMB shares, that's
I wonder how much of their installed base Samba will lose overnight when 10.7 Lion ships.
Probably a large part of the nominal "installed base". How much of the base of machines actually running Samba is, however, another matter; unless you've turned SMB file sharing on, you might have Samba installed, but you're not actually running it, so switching from a Samba that's not running to another SMB server that's not running makes no meaningful difference.
Oh, and, at least at one point, NetApp were considering whether to implement AFP, and, no, they weren't thinking of "licensing" it. They decided not to do AFP at that point - other projects took priority (such as the "turn a file into a SCSI disk and export it over Fibre Channel/iSCSI" project).
In 10.4 they couldn't even talk to the NetApp with CIFS at all, they could talk to Windows servers but slowly. NFS worked but it was a disaster trying to get permissions to work right.
We figured this was in part because they use Samba
As Jeremy noted, no, they don't. They use an SMB client that started out based on the FreeBSD smbfs and had a lot of work done on it since then.
They want Macs to be faster to Mac servers via AFP, and slower to Windows systems via CIFS.
NetApps CIFS implementation was written well after Samba, with some judicious peeks at the Samba code in order to implement the hard stuff
Maybe they looked at the Samba code after I worked on the NetApp code, but while I was working on the first version, we made a point of not having the Samba code around....
Slashdot Mirror
TFirst, TermKit combines two different "re"-envisionings of the shell.
Some potential users might find one of those ideas useful (realizing that having command output intended to be parsed by humans or by other commands can result in output that's not as human-readable as you'd like and not as software-parseable as you'd like, a notion that also showed up on LinuXML/XMLTERM and, as noted elsewhere, in PowerShell) and another not (the moving beyond a text interface). The latter doesn't personally interest me; if I want to tweak something from the GUI, there's already GUI code for that - if I want to do command-line stuff, I don't need each command-line token looking like a GUI widget with icons attached to them, I don't need pipe bars looking like big blobs, etc..
Perhaps there's a market for the second part, but I'm not sure what it is. If it helps people who could usefully use a command line learn it, without getting in the way of people not frightened by the command line, then it might be worth the effort.
Like Everest, because it was there.
There was a GIF out several years back, which I haven't been able to find any time recently (and would love a pointer to) of some guy who had something like *19* hardware emulators running on one monitor simultaneously, in 4 or 5 separate stacks.
TRS-80, C-64, T/S-1000; everything you've ever seen an emulator for, he had running on Linux all at the same time; some hosting others.
Dunno about that one, but here's Amit "Mac OS X Internals and MacFUSE" Singh running a large pile of x86 OSes on top of Virtual PC on a PowerBook.
a specific government chip would be pointless: your carrier can already probably tell your phone to do whatever they want
Including firing up a fart app?
...Any new technology involves adding a "chip" to your {cell phone, table, computer, server, ...}...
s/table/tablet/
First off, there are no new chips required...
Didn't you get the memo? Any new technology involves adding a "chip" to your {cell phone, table, computer, server, ...}. After all, it's not as if you can add new capabilities to a machine by updating its software....
"If it's using a framework where the run loop is inside the framework, the Snow Leopard and later version of the framework might use GCD, but if you have your own run loop...."
GCD requires the application developer to explicitly call dispatch_async and pass in the task blocks to be executed.
O RLY?
Despite the obvious satire, the answer is yes, since the system handles GCD for the software running on it :p
Well, no, actually, the system doesn't magically make all software use GCD. If it's using a framework where the run loop is inside the framework, the Snow Leopard and later version of the framework might use GCD, but if you have your own run loop....
Now it's true with numbers released by planned parenthood itself that well over 90% of prenatal services at planned parenthood are abortions
[Citation needed]. These numbers released by Planned Parenthood itself say otherwise.
Defense spending mostly goes to pay for science and research, not bombs.
[Citation needed]
Linux has a lot of problems that has kept it (and likely will continue to keep it) a niche product
Define "Linux".
I've had complaints about OS X, but problems with case-sensitive HFS+ is not among them -- in spite of the fact that all the years I used OS X installed on case-sensitive HFS+, boot volume and all, with never a lick of trouble.
Perhaps you've been lucky. I've seen very few problems with case-sensitive file systems, but they do exist, as those of us with home directories on case-sensitive NFS servers occasionally find out. (I'm looking at you, Google....)
A purist will only use ed on a teletype ASR-33.
Unfortunately, OS X's tty driver doesn't implement the delay modes needed for an {ASR,KSR}33, or, for that matter, an {ASR,KSR}35, so you probably won't have much luck attaching one of them to a Mac. It's a damn shame....
Newbie. Man up and learn TECO.
And, yes, it's available for OS X.
Pfft! Man up and use an IBM 129.
Wimp. A keypunch with a fucking Backspace key, so you don't have to get it right the first time or waste a card? Real menu use an 029. (I'd say an 026, but that might not have had the character set you need; if it did, you might as well go The Full Monty and get an 024 - who needs to see what's on the card printed on the top?)
Using gconf to set a default size in certain versions of GNOME Terminal is broken
I'd say "using gconf to set a default size in certain versions of GNOME Terminal would be a crock even if it weren't broken"; the moral equivalent in Mac OS X would be requiring that you use the defaults command, or the plist editor if you want a GUI, to set the default terminal size in Terminal.app.
but looking at the gnome-terminal 2.33.90 shows a "Use custom default terminal size" (yeah I know that page talks about Ubuntu but the option was there in a Fedora 15 Alpha live CD too). gnome-terminal 2.30 and peering at gnome-terminal's git suggests the option would have gone in around 2.31.
It looks as if they broke it while fixing another bug, and finally got around to putting it back. I don't remember the ability to set it ever being broken in Terminal.app (the UI for it changed when they did a rewrite). Unfortunately, I haven't yet freed up enough disk space to add an Ubuntu 10 VM on my Mac to my other N VMs.
But hey - Slashdot ain't a bug tracker so here might not have been the best place to ask (even if you did work at NetApp)... :)
I was really just snarking about the CLI-in-the-GUI on a non-OS X desktop environment.
http://www.macworld.co.uk/news/index.cfm?NewsID=14663&Page=1&pagePos=8
Yeah, I remember that when it was mentioned on Slashdot, and the usual low S/N ratio discussion that followed. And, surprise surprise, Apple made the source to the Intel versions available, so Apple didn't "close down OS X", they just hadn't gotten around to releasing the source yet. Way to jump to a conclusion, dude....
Read the context. We are talking in terms of a hypothetical where Macs are the ones being locked down. You aren't disagreeing with my point you are agreeing that Macs support for iOS is what makes this possible.
Actually, what I'm saying is that I'm not sure why the heck Apple would bother locking down Macs, rather than just saying "we sell iOS machines for people who are happy with machines that can only run software that we bless, and we sell Macs for people who aren't", which is what they are, in effect, saying now.
Who the hell uses OSX anymore? The apple fan base gets a lot of publicity but its mainly gadgets not their computers. ... Though the NeXT based kernel concept is cute, nobody really cares anymore, especially about anything to do with BSD - Monolithic kernels won the war when they started to develop good realtime characteristics.
1) xnu is a monolithic kernel in practice. Yeah, some stuff is done by upcalls to userland, but you'll find those in monolithic kernels as well. 2) The "gadgets" use that kernel, too.
Are you sure that you can replace OS X Samba components with your own? Aren't they digitally signed
Yes.
(and the signatures verified)?
By whom? Not by launchd, or the kernel, as far as I know. FFS, /bin/cat is code-signed, but I rather doubt you can't replace it.
You cannot recompile Samba and substitute the Apple-provided system component that's based on Samba with the one you compiled on your own.
Why not? Will launchd refuse to start /usr/sbin/smbd if it hasn't been sprinkled with holy water?
If you use OS X to mount SMB shares, you can only do so with Apple binaries, not with your own binaries (unless you go via MacFuSE, that is)
As noted, if you're talking about Samba, that's "export SMB shares from your machine", not "mount SMB shares", and you've not provided any evidence that you can't just build your own smbd etc. and install them and run them (and, no, "butbutbut the copies that ship with OS X are signed!!!!!!1111ONE!!!!!" isn't evidence; the OS has to care that they're signed - the only evidence I'll believe is if somebody tries it and it fails). If you're talking about mounting SMB shares, that's
(which is BSD-licensed) but you haven't shown that you can't replace that, either.
I wonder how much of their installed base Samba will lose overnight when 10.7 Lion ships.
Probably a large part of the nominal "installed base". How much of the base of machines actually running Samba is, however, another matter; unless you've turned SMB file sharing on, you might have Samba installed, but you're not actually running it, so switching from a Samba that's not running to another SMB server that's not running makes no meaningful difference.
Apple doesn't license AFP to NetApp
License? (Oh, and before you ask, here's DSI.)
Oh, and, at least at one point, NetApp were considering whether to implement AFP, and, no, they weren't thinking of "licensing" it. They decided not to do AFP at that point - other projects took priority (such as the "turn a file into a SCSI disk and export it over Fibre Channel/iSCSI" project).
Apple doesn't license AFP to NetApp
License? (Oh, and before you ask, here's DSI.)
In 10.4 they couldn't even talk to the NetApp with CIFS at all, they could talk to Windows servers but slowly. NFS worked but it was a disaster trying to get permissions to work right.
We figured this was in part because they use Samba
As Jeremy noted, no, they don't. They use an SMB client that started out based on the FreeBSD smbfs and had a lot of work done on it since then.
They want Macs to be faster to Mac servers via AFP, and slower to Windows systems via CIFS.
So they can sell more Xserves. Oh, wait....
NetApps CIFS implementation was written well after Samba, with some judicious peeks at the Samba code in order to implement the hard stuff
Maybe they looked at the Samba code after I worked on the NetApp code, but while I was working on the first version, we made a point of not having the Samba code around....
Yeah.. i'm sure if they do it, they'll sell a more expensive machine or software to developers that isn't locked down.
They already do. They're called "Macs". The locked-down less expensive machines are called "iPhones", "iPod touches", and "iPads".