From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200210241736.g9OHaEi23621@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Essay: Is network transparency something bad? In-Reply-To: Your message of "Thu, 24 Oct 2002 15:51:59 GMT." From: Dan Cross Date: Thu, 24 Oct 2002 13:36:14 -0400 Topicbox-Message-UUID: 0c3d6a0a-eacb-11e9-9e20-41e7f4b1d025 He was being polemical, and the context was different. That said, I enjoyed the article, but disagree with him on several points. First, he was talking about a programming interface, not a system interface. Plan 9 integrates things like the network into the filesystem, effectively making IPC endpoints look like local files and the like, to enhance generality, and provide system-wide abstractions. Everything looks like a file, and everyone knows how to deal with files, so it makes things convenient. But an important difference is that a programmer still interacts with those abstractions explicitly. You know that you're creating and manipulating a TCP connection when you open the files under /net/tcp, or when you call dial(2). Because of that, you're congicent of the potential problems you might encounter. It's the psychological difference that matters here; the point isn't to abstract things to the point of oblivion, but to generalize the system interface and remove redundancies. Just because you do that doesn't mean you stop thinking about remote files versus local files, it's just no longer the focal point. Second, he was addressing specific issues in the Windows environment that don't exist on other platforms. We don't call ``CopyFile()'' under Plan 9; we invoke cp(1). It doesn't ``halt your application,'' it pauses your shell (unless you background it). There's no activity indicator because there doesn't need to be: you can sweep another window and use ls(1) to tell you if the file is getting bigger. The problems he's refering to go away, so finding a good solution to them is a nonissue. In exchange, we remove a *lot* of complexity (why do I want every application that copies a file to know about FtpOpenFile? Do I really insist that an FTP server be running every place I want to copy a file *from*?), and the system is a lot more general. Also, his complaints about reliability are valid, but what happens if my FTP server crashes? Do I want to go back to having everything on one big machine? What if *that* crashes? What's the point of a network, just to transfer MP3's and images? Anyway. As Russ pointed out, he makes a few good points, but the solution might not fit the crime here. If he were exposed to a system with a different type of interface, he might feel very differently. But evidentally most of his experience is with Windows, which doesn't have a particularly good abstraction for the network. In Plan 9, as is often the case with both Unix and VMS, the network plays a far more central role in an installation. - Dan C.