Date: Sun, 21 Dec 2014 17:56:58 +0100 From: Polytropon <freebsd@edvax.de> To: Mayuresh Kathe <mayuresh@kathe.in> Cc: freebsd-questions@freebsd.org Subject: Re: posix has been rendered useless, isn't it? Message-ID: <20141221175658.3d574a88.freebsd@edvax.de> In-Reply-To: <20141221155635.GA1388@aio> References: <20141221155635.GA1388@aio>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Dec 2014 21:26:37 +0530, Mayuresh Kathe wrote: > i have been studying the unix way of doing things, > i.e. tool-chaining to combine small programs for > accomplishing a solution. A noble goal. > but, almost none of today's servers built for any > of today's unix-like systems adhere to the unix > philosophy. most of them instead, are large > applications. The creation of monolithic applications can be a problem sometimes. It's often being accellerated by GUI paradigms where "one big program" is, often on the basic of object oriented programming (and the typical misunderstandings and misconceptions of that orientation), being "required" - you simply cannot easily apply the UNIX principles here. > does that mean, posix has been rendered useless? > if yes, what's the need to have so much support > for the posix standard? No. Basically, POSIX defines measures and guidelines for programs to be portable on source level in the first place, like: "If a program is compliant to the POSIX standard, it can be compiled on any system that conforms to the POSIX standard without alteration." And "compiled on" often is a requirement for "runs on", even though there might be platform-specific changes. > wouldn't it make more sense to have a components > based layer surrounding the kernel? > components would be specialized programs designed > to accomplish one task, and do it well, and which > in turn would communicate with other components > over clean and well designed interfaces. > yes, this is what exists right now, but somehow, > the idea doesn't reach out deep enough. > i couldn't find a way to write a c-shell script > to create a workable mail server in minimal time. This is because the C shell simply is the wrong tool. UNIX also is about being able to select the suitable tools for your tasks. If a complex task like a mailserver cannot be solved "in one run", split the task into subtasks and chain them to each other. Again, the C shell might not be part of a solution here, because a shell is intended for a different kind of use. Still, the shell can interact with a mail server and the dialog elements it exposes to the user. The "small programs" around a server tend to be the parts that adhere to the UNIX principles, where the server (because of its complexity) doesn't have to. Still server programs _are_ components in the context of the UNIX philosophy. Imagine a "one server" that does everything from one big monolithic program (and worse, from one big, several million lines long source file). That would be terrible. Even complex servers like the Apache web server allow working with modules to add or remove functionality, separating components. > i apologize if i have provoked anyone, it's not > my intention, but, it's just frustrating to note > that there's so much work being done towards > writing more and more server programs, but none > of them adhere to the base philosophy of the > system for which they are supposedly crafted. Servers often are very complex. But today's computers tend to "buffer" the complexity by providing more than sufficient resources. Remember inetd? It was being used to start servers when they needed to be run. Today, the servers are started and left alone, so they deal with their "invocation" on their own. If a server needs to communicate, it provides a communication interface as needed. If we abstract servers to services, those do offer an API for interaction. The more standardized this API is, the better interoperation can be. On the other hand, encapsulation is implemented, so the "inner workings" do not have to be shown in order to allow the interaction. > it's like, people are writing 'vms' style programs > for unix-like systems. > > that's crazy, isn't it? Definitely CRAZY.COM;1. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141221175658.3d574a88.freebsd>