From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-12 03:30:01 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-037-237.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) Date: Mon, 12 Apr 2004 12:29:29 +0200 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-037-237.arcor-ip.net (145.254.37.237) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1081765800 545356 I 145.254.37.237 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:6997 Date: 2004-04-12T12:29:29+02:00 List-Id: Alexander E. Kopilovich wrote: > Dmitry A. Kazakov wrote: > >> ... Unix is that sort of half-baked OS. Tools do not replace >> the OS. But what UNIX and later Microsoft shown, one can well sell tools >> and call them OS. > > Well, half-baked... but weren't half-baked food products popular in > supermarkets? Exactly. Are half-baked products healthy? > Quite similar situation: making a product from raw > components may be expensive in terms of workforce and time, while turning > to a good restaurant may be expensive in terms of money; at the same time > half-baked products may provide optimal compromise in many cases. I would not call having no other choice a compromise. >> > In more technical terms, Unix pay much more attention (and provides >> > much >> > more means) to interoperation between separate processes. >> >> You definitely mean fork and copying file descriptors. Indeed, an >> excellent way of interoperation. > > Actually I meant pipes in first place. No matter. In a classical UNIX you would create a pipe file first and then fork, the descriptor is copied and here you are. A pretty idiotic way, IMO. >> > In classical IBM >> > mainframe OSes all processes were really separated from each other, and >> > when a need emerged to establish some kind of cooperation between >> > parallel processes it always was a pain and required the skills far >> > above the ordinary programmer's level. And that was right and good >> > approach those times and for typical applications. In RSX (DEC PDP-11) >> > situation shifted: it became much easier to establish cooperation >> > between parallel processes (at the cost of slightly weaker separation), >> > but it still required programmer's skills above average (although not >> > "far above" any longer). >> >> And you intentionally do not mention VMS which had uncounted ways of >> inter process communication. > > Well, I have no personal experience with VMS, I have read its general docs > but no more. But: 1) VMS appeared (as far as I know) when Unix was already > known and already gained some popularity; Huh, there was ULTRIX for VAX, guess who wished to use it? > 2) VMS ran on VAXes, which were > near mainframes (well, somewhere between mainframes and minis) in many > aspects, including cost and availability; There was microVAX. As for costs, that was management choice, which ruined DEC. > 3) VMS was not portable in any sense. It is not a property of OS. VMS could be implemented on any platform and if they wrote it in Ada... (:-)) > I think (from the docs I have read and other assorted sources) that VMS > was quite good OS, although some of its features surprised me by their > seemingly unnecesessary complications, for example a mixture of > rollin/rollout with virtual memory. > > But nobody, including DEC, did attempt to give this OS an independent > status, that is, to loosen its dependance upon VAXes. And subsequent > MicroVAXes weren't too successful and widespread. Mismanagement, the key point of the discussion. DEC had the best operating system, the best hardware, the best compilers and tools (remember DEC Ada and LSE). And lo and behold, where it is now. The system worked first for UNIX and then Microsoft, because latter were even worse than UNIX. > What followed was Cutler's migration to Microsoft and then appearance of > Windows NT. It was said once (or more than once) that Windows NT has the > heart of VMS, legs of Unix and the face of Windows. Not discussing here > the "legs" and "face", I believe that metaphor for the heart had some > grounds. Heart pacemaker would be more appropriate. > The bottom line of that VMS story is that DEC did not qualify to true > heavyweight and therefore was unable to maintain strong influence in the > wide market (like IBM did), and at the same time it did not let > competitors to use the potential of VMS another way that letting Cutler to > go to MS. And MS in its early days was heavyweight? >> > In >> > Unix the concept of interprocess cooperation was made one of central >> > system concepts, and it was made routinely accessible for all users. It >> > became possible and easy to use tools/utilities in concert, not in >> > sequential order via external data files. >> >> Come on, in UNIX everything is a file. Even locks are files... > > Regargless of what is was at the system level, for an application > programmer the concept usually was a stream. Who is using streams for communication for interprocess now? We are using APIs, mutexes, shared regions, events instead. Only in Internet, because see previous posts, we are using stream-based protocols. >> > Networking was not a strong side of >> > those OSes - it was quite expensive and required highly skilled system >> > administrators, which often weren't available. SNA, and even DECNET >> > looked like monsters. I think that with those kinds of networking we >> > would still have Internet in science fiction only. >> >> Yes, we would have one global distributed OO networking system with nodes >> in PCs. One would need no ftp to get a file. One would even have no >> files, but persistent objects of different types... > > Besides that this is a hardcore idealistic dream, It is not a dream. It is pretty doable, but not sellable. > this means that regular > users would be deprived from the basic low-level abstraction. No more than Ada depriving programmers from *p++; >> >> What new gave UNIX and Windows to us in recent 20 years, except for >> >> awk and viruses? >> > >> > They gave radical extension of user base, which stimulated investments, >> > which, in turn, stimulates hardware vendors, which results in dramatic >> > decrease of hardware prices. Well, they did not exactly *gave* us all >> > that, but they substantially participated in that. >> >> Which features of UNIX and Windows gave that extension? > > Availability of these OSes and accessability of the features, which > are/were important for general/mass end-users and corresponding > applications. A quality in strictly software engineering sense was not > among those features simply because it was not among the most important > things for that audience. See, technical ussues are irrelevant. >> What makes you think >> that LSI-11 under RSX would be worse than IBM PC under CP/M? > > At the same price and quantities? Is that a technical problem? > Perhaps it would be better. Even RSX was > not necessary - more restricted and simple TSX would be better choice for > many beginners. But it was not there at these conditions. The point is that the idea to start with a crap and then level it to a quality product *never* ever worked for software. What you are starting with is what you get in the end. We started with CP/M and now, decades later, it is still CP/M, though maybe containing no single line of its original code! >> That extension would happen anyway, but on a much higher level. > > This is a pure guess, and I think it is wrong guess. Anyway, we aren't > going to rewrite history. Alas >> The problem is that 0.001% of community can produce 60% of mail traffic. >> So it is not 99.999% who are responsible, but the system, which allows >> that. > > The "system", which allows that is not Windows or Unix but the Internet. The Internet was *shaped* by UNIX and later Windows. It is as good as OSes involved allow it to be, especially by the ideology ignoring quality as irrelevant. >> If the OSes and their services were developed at a minimal level >> of responsibility there were no way to produce spam in its current >> volume. There are elementary ways from prevent that. > > I don't know which elementary ways you mean, but I'm sure that at least at > the current stage, any elementary way of that kind that will not broke the > service to the end, will be immediately circumvented. There are thousands of ways. Just attach an ID to any mail source and limit the amount of mail generated by a source by some limit per day. The IDs can be made unique, provider-local, untrackable. If a provider refuses to conform then instead of being mail "relayer" it becomes a "source". >> > And anyway, software is still much more effectively controlled than >> > light weapons, explosives and car traffic (perhaps you know that the >> > latter kills huge number of people every year... software can't come >> > near that number of victims in near future). >> >> You are joking. > > Strange. How can I be joking about million of car accident victims > (worldwide) every year? Because human fault /= software fault. When you make a car accident you are liable. Who is, when a program crashes? Right, the program, and nobody else. >> To your knowledge, the next generation of cars will have >> dozens of contolling computers conntected by up to 6 field buses. Guess >> which language will be used to program them? > > I have read something about MISRA-C regarding this matter. But I think > that language is irrelevant there. Its choice is relevant. It is an indicator of how seriosly people are going to make their job. > Just as sex, race or average age of > programmers. There are much more important issues in the case. For > example, will be car vendors required to publish full sources of the > software used in their cars? What for? To laugh at? How would it help the society of incompetence? C is a consequence, not the problem. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de