I must be a bit thick here, but people have been able to write files over networks for years before WebDAV was even an acronym.
I never said this had anything whatsoever to do with the WebDAV protocol; it's purely a question of the implementation of the WebDAV and FTP file systems.
While there might be some sort of 'under the hood' technical reason for this not being an easy thing to accomplish
There's no fundamental technical reason why this is possible for WebDAV but not for FTP. It's purely a question of, as I said, the current implementations of the WebDAV and FTP file systems (which were done independently). One could implement the FTP file system atop the same underlying infrastructure as the WebDAV file system, which would allow the FTP client file system to know that a file being written to was closed, just as the WebDAV file system does, so that they know that they can push the file system up to the server.
So why should I need to get a 3rd party app or pay Apple for a.mac account to Transfer a File using a Protocol?
Because, for better or worse, nobody's reimplemented the FTP file system atop the same kernel stub file system (for those who are curious about the implementation of WebDAVfs, see the webdavfs project in the Darwin source; I think you'll need a free Apple Developer Connection membership to get access to the Darwin source.)
No, it's not. It's a client, ultimately, of a bunch of subroutines named open(), close(), read(), write(), readdir() (or getdirentriesattr()), etc.. (The access is mediated by a bunch of Carbon routines, but they ultimately turn into standard UN*X calls - or nonstandard extensions such as getdirentriesattr().)
The FTP client it's using when it's accessing an FTP folder is called mount_ftp:
and it's a user-mode NFS server which is mounted on/Volumes/ftp.gtk.org. The Finder just accesses it the same way it accesses other folders, such as folders on your local disk.
The lack of write support is due to the lack of an indication of when the app writing to a file is finished writing to the file, so that it can be written back to the server; as I indicated in another posting, WebDAVfs (which works similarly; that's how an iDisk is implemented, for example) has its own kernel stub file system that talks to the WebDAV client program in userland, and can deliver "file closed" indications.
Never had the Internet copying problem though, maybe it's due to your host?
Or perhaps it's due to the remote file system mechanism he's using (iDisk, if I remember correctly, which means WebDAV) either doesn't support delivering "hey, something changed" notifications to the client or doesn't support kqueue notifications (the "UNIX component" to which you're referring).
I.e., to some degree, this is a case either of the Finder being blamed for something happening at lower layers of the OS or for not working around deficiencies in the lower layers. In this case, the workaround would involve polling the directory if it can't be monitored with a kqueue or if no notifications would be delivered to the kqueue. (Another example of this are complaints about FTP access being read-only; the Finder isn't doing the FTP access, it's ftpfs, which is implemented with a user-mode NFS daemon, which would have to guess when you're done writing to a file to know when to push it back to the server; WebDAVfs has its own kernel stub, which can deliver "file is closed" indications, rather than using the NFS client as its kernel stub, so it knows when to push the file back.)
But most Mac users probably don't know any of that, so they naturally think of these as Finder problems because the problems manifest themselves when the Finder is what's being used (and I can't really blame those Mac users for that).
I have been to many of my clients houses and they mention that their performance is slow. I look down at the dock and they have 15 applications running, but are not using any of them.
The real fix for that is to have those apps not burn up CPU time if they don't have any windows open and don't have anything useful to do if they don't have any windows open. Yes, they still chew up swap space, so they might fragment the swap file and cut paging performance, but I suspect those apps chewing CPU up when idle is a significant part of the problem. Unfortunately, that's almost certainly not something you or your clients can fix directly; the best you can do is yell at the vendors of the apps, and shut those apps down when idle.
Speaking of apps chewing up CPU when you think they're idle, note that if you have a Safari window open to a page with an animated GIF or other form of "attract mode" on that page, it's probably chewing up CPU doing that. I can't speak for Firefox or IE or Konqueror or..., but they might have the same issue. Another reason to hate animated Web pages - especially if they're pop-unders, so you don't even know they're there.
Oh, and in response to the GGP, you've obviously never used an flavor of UNIX other than Linux. Linux is NOT UNIX despite what some might want to tell you. It's inspired by UNIX but doesn't follow many of the forms that became common in true UNIX platforms. OSX is closer to BSD than Linux is, and as such I'm quite comfy in that environment having cut my teeth on NetBSD, FreeBSD and AT&T UNIX (yes, the real deal). Just because nothing is where you expect it coming from a hobbyist UNIX platform, doesn't mean it's automatically wrong. In fact, OSX has more in common with most commercial UNIX's (Unices?) than Linux will ever have.
Yup. For example, OS X doesn't have those weird "run levels" in init that Linux has; it's more like AT&T UNIX in that regard.
Oh, wait, never mind....:-)
(Yes, the original AT&T UNIX didn't have them, either, but most Linux distributions are closer to SV than the BSDs - including, in this case, OS X - are in that regard.)
On the other hand, ifconfig in OS X looks like the original BSD version; Linux is the one that stands out there.
So I suspect you'll find that
OS X is closer to *BSD than Linux in many regards;
it's closer to Linux in some regards (some commands are GNU commands when the *BSDs use BSD equivalents, e.g. OS X offers bash and not the Almquist shell, and the OS X make is GNU Make rather than Berkeley make);
it's sui generis in other places (e.g., launchd in Tiger, although launchd is closer to the BSD init than to the SV init or the Linux clone thereof).
First of all the US government paid most of the initial infrastructure cost for the phone network in the US. Time for an example. Lets say the US government in its grand stupidity had contracted out the creation of the Interstate system. They said, OK private companies here is a load of cash to build the interstate, you build it, and you can charge fees, and 95% of those fees have to go back into maintainance and building new roads. That is exactly how the phone system was build and maintained untill the mid 90s.
Indeed? The US government paid all the money to string those phone lines and build those telephone switchboards and switches, and just hired Ma Bell to run it? AT&T and its subsidiaries didn't spend their own money building the phone nework? Could you please cite a document that supports your assertion?
Aqua is quite customizeable, thanks to Objective-C and the Cocoa framework's highly dynamic runtime. Look up method swizzling and class posing and learn how to tweak every last aspect of your desktop.
Even those aspects of your desktop implemented in, err, umm, Carbon? Such as, say, the Finder?
Guess they forgot that the SMB stack was created by IBM.
The original SMB protocol was created by IBM. Many of the subsequent additions - and the DCE RPC-based protocols added atop it - were created by Microsoft.
If that's what Ballmer meant, perhaps he should have said that instead of blaming it on Linux?
Try convincing Ballmer that the difference between a Linux distribution and the Linux kernel is something he should care about. Good luck (does your insurance policy cover chair-related injuries?). For extra credit, see if you can convince him it's "GNU/Linux", not "Linux".:-)
For better or worse, I suspect most people who aren't computer technical types - and even many who are - use "Linux" to refer to Linux distributions, not just to the Linux kernel. I also suspect many of them would end up even more confused if you tried to explain the difference to them.
(I'm not arguing one way or the other about the importance of making that distinction, I'm just noting that I suspect most people who would purchase a Linux distribution, or support for one, would probably think of Samba as part of the "Linux" they bought.)
IF MS doesn't allow Samba and interoperability then they aren't opening their APIs.
What if they allow it, but only if you pay a licensing fee? The EU decision requires only "reasonable and non-discriminatory terms", and explicitly speaks of "any remuneration that Microsoft might charge for supply"; perhaps I'm missing something, but I don't see anything there that requires Microsoft to allow you to give away SMB server software for free. (See section "6.1.1 Remedy concerning refusal to supply", and its two subsections "6.1.1.1 Order to disclose interoperability information for the development of interoperable products" and "6.1.1.2 Reasonable and non-discriminatory terms, timeliness of the disclosures".)
Perhaps Microsoft's strategy can be summed up here as "Don't forget to pay your $32 to $760 licensing fee you cock-smoking teabaggers.":-)
AFAIK, SMB was not "reverse engineered" -- Microsoft actually submitted the spec to IETF in 1996.
As noted, Samba antedated that spec. However, specs for earlier versions of SMB were available at the time Tridgell first developed Samba. The problem was that he didn't know that the protocol PATHWORKS was using was SMB or that specs were available. (Reminds me of my reverse-engineering work to implement code in Ethereal to read files from Sun's snoop - I later discovered it was documented in RFC 1761.)
SMB was based on (really copied from) an old DEC protocol. This is what jump-started the Samba project; one of the lead developers had access to DEC's specs for this protocol.
No. DEC had an implementation of SMB called PATHWORKS, which included a DOS client and a server for VMS and, I think, Ultrix, but they didn't invent the protocol. (They might have had some add-on protocols with PATHWORKS, but the core protocol was the SMB that IBM, 3Com, Intel, and Microsoft were involved with developing. See this message from Steven French. I think Steve's the main developer of the cifsfs in-kernel SMB client for Linux).
One of the lead developers (some guy named "Andrew Tridgell":-)) reverse-engineered SMB based on traffic between the PATHWORKS client and server; he later discovered that this was SMB, which did have some published specs. See Tridgell's description of the history of Samba.
No, he's suggesting that if Linux had these before Windows, then Linux can't be violating any MS IP (at least W.R.T. the things he mentioned).
That parenthetical note is key here. Linux didn't have an SMB server before Microsoft did; no, Samba isn't part of the Linux kernel, but it is part of a lot of Linux distributions (as well as being used on other UN*X OSes), and Microsoft do have a licensing process for SMB and various protocols that run atop it, so that might be what Ballmer was referring to.
In the US, you can't even drive down the road without your license plate number being picked up or buy breakfast without your debit card indicating that you where Noah's Bagels on University Ave. at 7:07AM and that you bought the Kona Blend.
Noah's won't take cash? I'm not a breakfast person, but I might have to try that, just to see whether your second claim has any validity at all. (I'm not doing 7 AM, though. I don't do mornings.)
That's the whole article, not just the picture; for a Happy Little Family Picture, there's this one, which doesn't make me feel particularly sorry for the proud papa.
As long as we're linking Wikipedia pictures, I'm not particularly sorry for either of the war criminals shaking hands in this picture. All that's happening to the one on the left, though, is that some people are saying he should be fired.
Re:Americans will buy anything "exotic"....
on
Slashdot's Vastu
·
· Score: 1
...if I told someone that they should arrange their house to suit some passages in the Bible, they'd likely tell me to go piss up a rope.
If I wrapped it in Eastern Mysticism, they'd get a guru, moving company, and reed sandals.
That depends on the American you're talking to; there are probably plenty of them who'd lap it up if you gave them some Biblical quote that one could, if one worked really hard at it, interpret in some way that one could, if one really wanted to, think referred to some Web design issue. (Maybe they'll prefer popunders to popups thanks to "get thee behind me, Satan".)
The graphics and sans serif font induce good Water flow.
So will several cups of tea or several glasses of beer.
(As for "...Rob Malda chose an excellent URL, even though it's confusing when read aloud", one wonders why the good doctor thinks the domain name was chosen in the first place.)
What I really want to know is what Web Vastu says about loading up your page with stupid Flash animations so that when you go to a new page, the page slowly drops down or slides in or rolls down, or the letters fly into place one at a time, or something such as that. The people ultimately responsible for the decisions to create pages such as that should be disemboweled and strangled with their own intestines; I'm willing to let the Web designers off if their client demanded it and they really needed the business.)
Except MSFT will have to refuse to sell to people building AMD based systems because they will be based on processors that have virtualisation technology
How _dare_ they reject Western Enlightenment Liberalism! Don't they know that it's the Absolute Truth (tm)?
Actually, if done right, it's not; it's something that realizes that a lot of Absolute Truths(tm) aren't. You have to keep looking deeper and deeper because you might have missed something (velocities don't really appear add the way they appear to at low speed, for example; the differences at high enough speed make a difference).
(Of course, digging deeper is a lot of work, so "look, I've used my high school math and physics and I've PROVEN EINSTEIN WRONG!" doesn't cut it.)
I don't know whether where reading a paper on evolution/molecular genetics can get you expelled from Bob Jones, with "reading" meaning "privately reading" rather than "reading it aloud in a class", but merely reading a paper on creationism in the privacy of your dorm room is unlikely to get you expelled from one of those Western Enlightenment Liberalism-based universities. (Maybe your roommate might have to ask to change rooms if it bothers them.)
Slashdot Mirror
I never said this had anything whatsoever to do with the WebDAV protocol; it's purely a question of the implementation of the WebDAV and FTP file systems.
There's no fundamental technical reason why this is possible for WebDAV but not for FTP. It's purely a question of, as I said, the current implementations of the WebDAV and FTP file systems (which were done independently). One could implement the FTP file system atop the same underlying infrastructure as the WebDAV file system, which would allow the FTP client file system to know that a file being written to was closed, just as the WebDAV file system does, so that they know that they can push the file system up to the server.
Because, for better or worse, nobody's reimplemented the FTP file system atop the same kernel stub file system (for those who are curious about the implementation of WebDAVfs, see the webdavfs project in the Darwin source; I think you'll need a free Apple Developer Connection membership to get access to the Darwin source.)
No, it's not. It's a client, ultimately, of a bunch of subroutines named open(), close(), read(), write(), readdir() (or getdirentriesattr()), etc.. (The access is mediated by a bunch of Carbon routines, but they ultimately turn into standard UN*X calls - or nonstandard extensions such as getdirentriesattr().)
The FTP client it's using when it's accessing an FTP folder is called mount_ftp:
and it's a user-mode NFS server which is mounted on /Volumes/ftp.gtk.org. The Finder just accesses it the same way it accesses other folders, such as folders on your local disk.
The lack of write support is due to the lack of an indication of when the app writing to a file is finished writing to the file, so that it can be written back to the server; as I indicated in another posting, WebDAVfs (which works similarly; that's how an iDisk is implemented, for example) has its own kernel stub file system that talks to the WebDAV client program in userland, and can deliver "file closed" indications.
Or perhaps it's due to the remote file system mechanism he's using (iDisk, if I remember correctly, which means WebDAV) either doesn't support delivering "hey, something changed" notifications to the client or doesn't support kqueue notifications (the "UNIX component" to which you're referring).
I.e., to some degree, this is a case either of the Finder being blamed for something happening at lower layers of the OS or for not working around deficiencies in the lower layers. In this case, the workaround would involve polling the directory if it can't be monitored with a kqueue or if no notifications would be delivered to the kqueue. (Another example of this are complaints about FTP access being read-only; the Finder isn't doing the FTP access, it's ftpfs, which is implemented with a user-mode NFS daemon, which would have to guess when you're done writing to a file to know when to push it back to the server; WebDAVfs has its own kernel stub, which can deliver "file is closed" indications, rather than using the NFS client as its kernel stub, so it knows when to push the file back.)
But most Mac users probably don't know any of that, so they naturally think of these as Finder problems because the problems manifest themselves when the Finder is what's being used (and I can't really blame those Mac users for that).
The real fix for that is to have those apps not burn up CPU time if they don't have any windows open and don't have anything useful to do if they don't have any windows open. Yes, they still chew up swap space, so they might fragment the swap file and cut paging performance, but I suspect those apps chewing CPU up when idle is a significant part of the problem. Unfortunately, that's almost certainly not something you or your clients can fix directly; the best you can do is yell at the vendors of the apps, and shut those apps down when idle.
Speaking of apps chewing up CPU when you think they're idle, note that if you have a Safari window open to a page with an animated GIF or other form of "attract mode" on that page, it's probably chewing up CPU doing that. I can't speak for Firefox or IE or Konqueror or..., but they might have the same issue. Another reason to hate animated Web pages - especially if they're pop-unders, so you don't even know they're there.
Yup. For example, OS X doesn't have those weird "run levels" in init that Linux has; it's more like AT&T UNIX in that regard.
Oh, wait, never mind.... :-)
(Yes, the original AT&T UNIX didn't have them, either, but most Linux distributions are closer to SV than the BSDs - including, in this case, OS X - are in that regard.)
On the other hand, ifconfig in OS X looks like the original BSD version; Linux is the one that stands out there.
So I suspect you'll find that
Indeed? The US government paid all the money to string those phone lines and build those telephone switchboards and switches, and just hired Ma Bell to run it? AT&T and its subsidiaries didn't spend their own money building the phone nework? Could you please cite a document that supports your assertion?
Then try a different station at Caffe Macs.
...these people.
Even those aspects of your desktop implemented in, err, umm, Carbon? Such as, say, the Finder?
...not that there's all that much "micro" about XNU.
The original SMB protocol was created by IBM. Many of the subsequent additions - and the DCE RPC-based protocols added atop it - were created by Microsoft.
The article is discussing what the programmer sees, i.e. the instruction set architecture.
Try convincing Ballmer that the difference between a Linux distribution and the Linux kernel is something he should care about. Good luck (does your insurance policy cover chair-related injuries?). For extra credit, see if you can convince him it's "GNU/Linux", not "Linux". :-)
For better or worse, I suspect most people who aren't computer technical types - and even many who are - use "Linux" to refer to Linux distributions, not just to the Linux kernel. I also suspect many of them would end up even more confused if you tried to explain the difference to them.
(I'm not arguing one way or the other about the importance of making that distinction, I'm just noting that I suspect most people who would purchase a Linux distribution, or support for one, would probably think of Samba as part of the "Linux" they bought.)
What if they allow it, but only if you pay a licensing fee? The EU decision requires only "reasonable and non-discriminatory terms", and explicitly speaks of "any remuneration that Microsoft might charge for supply"; perhaps I'm missing something, but I don't see anything there that requires Microsoft to allow you to give away SMB server software for free. (See section "6.1.1 Remedy concerning refusal to supply", and its two subsections "6.1.1.1 Order to disclose interoperability information for the development of interoperable products" and "6.1.1.2 Reasonable and non-discriminatory terms, timeliness of the disclosures".)
Perhaps Microsoft's strategy can be summed up here as "Don't forget to pay your $32 to $760 licensing fee you cock-smoking teabaggers." :-)
As noted, Samba antedated that spec. However, specs for earlier versions of SMB were available at the time Tridgell first developed Samba. The problem was that he didn't know that the protocol PATHWORKS was using was SMB or that specs were available. (Reminds me of my reverse-engineering work to implement code in Ethereal to read files from Sun's snoop - I later discovered it was documented in RFC 1761.)
No. DEC had an implementation of SMB called PATHWORKS, which included a DOS client and a server for VMS and, I think, Ultrix, but they didn't invent the protocol. (They might have had some add-on protocols with PATHWORKS, but the core protocol was the SMB that IBM, 3Com, Intel, and Microsoft were involved with developing. See this message from Steven French. I think Steve's the main developer of the cifsfs in-kernel SMB client for Linux).
One of the lead developers (some guy named "Andrew Tridgell" :-)) reverse-engineered SMB based on traffic between the PATHWORKS client and server; he later discovered that this was SMB, which did have some published specs. See Tridgell's description of the history of Samba.
That parenthetical note is key here. Linux didn't have an SMB server before Microsoft did; no, Samba isn't part of the Linux kernel, but it is part of a lot of Linux distributions (as well as being used on other UN*X OSes), and Microsoft do have a licensing process for SMB and various protocols that run atop it, so that might be what Ballmer was referring to.
Noah's won't take cash? I'm not a breakfast person, but I might have to try that, just to see whether your second claim has any validity at all. (I'm not doing 7 AM, though. I don't do mornings.)
That's the whole article, not just the picture; for a Happy Little Family Picture, there's this one, which doesn't make me feel particularly sorry for the proud papa.
As long as we're linking Wikipedia pictures, I'm not particularly sorry for either of the war criminals shaking hands in this picture. All that's happening to the one on the left, though, is that some people are saying he should be fired.
That depends on the American you're talking to; there are probably plenty of them who'd lap it up if you gave them some Biblical quote that one could, if one worked really hard at it, interpret in some way that one could, if one really wanted to, think referred to some Web design issue. (Maybe they'll prefer popunders to popups thanks to "get thee behind me, Satan".)
So will several cups of tea or several glasses of beer.
(As for "...Rob Malda chose an excellent URL, even though it's confusing when read aloud", one wonders why the good doctor thinks the domain name was chosen in the first place.)
What I really want to know is what Web Vastu says about loading up your page with stupid Flash animations so that when you go to a new page, the page slowly drops down or slides in or rolls down, or the letters fly into place one at a time, or something such as that. The people ultimately responsible for the decisions to create pages such as that should be disemboweled and strangled with their own intestines; I'm willing to let the Web designers off if their client demanded it and they really needed the business.)
Either:
Why? What the license says is
not
Actually, if done right, it's not; it's something that realizes that a lot of Absolute Truths(tm) aren't. You have to keep looking deeper and deeper because you might have missed something (velocities don't really appear add the way they appear to at low speed, for example; the differences at high enough speed make a difference).
(Of course, digging deeper is a lot of work, so "look, I've used my high school math and physics and I've PROVEN EINSTEIN WRONG!" doesn't cut it.)
I don't know whether where reading a paper on evolution/molecular genetics can get you expelled from Bob Jones, with "reading" meaning "privately reading" rather than "reading it aloud in a class", but merely reading a paper on creationism in the privacy of your dorm room is unlikely to get you expelled from one of those Western Enlightenment Liberalism-based universities. (Maybe your roommate might have to ask to change rooms if it bothers them.)
Perhaps, perhaps not.
Was that purely because the programs used Carbon, or was it because they were developed using CodeWarrior?
...assuming the program doesn't explicitly or implicitly assume a big-endian machine.