The UNIX system has been in wide use for over 20 years, and has helped to define many areas of computing.
Post
Replies:
15
Boosts:
14
anyway that shit was wild
seeing "remote execution" in a 1981 paper and knowing UCLA did it better than us in most ways was both exciting and scary
the google remote execution API is such fucking shit lmao
back to the BSD hagiography
Because 4.2BSD included many new facilities, it suffered a loss of performance compared to 4.1BSD, partly because of the introduction of symbolic links.
blaming two separate things for performance degradation lmao
Some pernicious bugs had been introduced, particularly in the TCP protocol implementation.
TCP is a fucking joke. the pernicious bug is TCP
Others, such as TCP/IP subnet and routing support, had not been specified soon enough by outside parties for them to be incorporated in the 4.2BSD release.
"outside parties" ??? this is still darpaslop and cerf does not let others specify his protocols for him
Commercial systems usually maintain backward compatibility for many releases, so as not to make existing applications obsolete.
complete falsehood. that's what we did at pants and what we do for spack because we are government workers and we achieve guarantees for our users
Maintaining compatibility is increasingly difficult, however,
skill issue, should have used spack
so most research systems maintain little or no backward compatibility.
debatable. very funny how rapidly this guy jumps between commerce and research lol
The implementation changes between 4.2BSD and 4.3BSD generally were not visible to users, but they were numerous.
i would think performance and bug fixes are user-visible, but whatever
For example, the developers made changes to improve support for multiple network-protocol families, such as XEROX NS, in addition to TCP/IP.
if i ever find myself wanting to feel bad i absolutely want to read cerf's code because i wanna know if he gives off vibes that would ring a bell
The most critical shortcoming of 4.3BSD was the lack of support for multiple filesystems.
oh bet
As is true of the networking protocols, there is no single filesystem that provides enough speed and functionality for all situations.
yeah cause you don't specialize per situation and provide a monolithic interface
It is frequently necessary to support several different filesystem protocols, just as it is necessary to run several different network protocols.
ridiculous comparison because you literally can't choose the filesystem per-file???? that's literally why i'm doing any of this????
The design of the networking facilities for 4.2BSD took a different approach, based on the socket interface and a flexible multilayer network architecture.
literally microkernels but only for network sockets
This design allows a single system to support multiple sets of networking protocols with stream, datagram, and other types of access.
how do you write file data? oh read()/write() that's it
Protocol modules may deal with multiplexing of data from different connections onto a single transport medium, as
well as with demultiplexing of data for different protocols and connections received from each network device.
literally file i/o when???
This process illustrates an advantage of having only a few principal developers: The developers all knew the whole system thoroughly enough to be able to coordinate their own work with that of other people to produce a coherent final
system. Companies with large development organizations find this result difficult to duplicate.
programming is expert labor????
There was no CSRG marketing division.
you are the marketing division my man
Thus, technical decisions were made largely for technical reasons, and were not driven by marketing promises.
the marketing folks i talked to at twitter were really nice and clearly experts in their field. it sounds like you hate users
The Berkeley developers were fanatical about this position, and were well known for never promising delivery on a specific date.
oh so they acted like pricks
ok finally the hagiography ceases
