> From: Greg Lehey
>> V3 and earlier still *called* them special files, but it seems they
>> were essentially just magic inode numbers (there was no physical file
>> on disk, just any directory entry with the given inode would be the
>> special file).
> Isn't that still the case?
>From reading the manual page (URL sent earlier), in V3 and before it really
was just an inode _number_ (less than 50, IIRC). The first inode, in the
first disk block after the super-block, was inode #51. This is of course
different from later Versions, where there is an _inode_ for devices, but
still no actual _file_.
Noel
Co-inventor of Unix, he was born on this day in 1943. Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> My experience is that the problems involved in making a program faster are
> often quite interesting and fun to work on. But the problems making things
> fit in a small space are, IMHO, really deadly.
First make things "as simple as possible, but no simpler" (Einstein). Ken and
Dennis not only cut out fat, they also found generalizations that combined
traditionally disparate features, so the new whole was smaller (and more
comprehensible) than the sum of the old parts. The going gets tough in the
presence of constraints on space or time. Steve's perception, I think, is
colored by the experience of facing hard limits on space, but not on time.
Describing one complication of hard time constraints, John Kelly used to
say that the Packard Bell 250 was "the only machine I ever used where
you transfer to a time of day rather than a memory location". (The delay-
line memory had two instruction formats: one was operation + address-of-
next-instruction, the other was just the operation--the next instruction
being whatever came out of the delay line when the operation ended. The
latter mode minimized both execution time and code space, but the attention
one had to pay to time was, to borrow Steve's phrase, "really deadly".)
Design tradeoffs for efficiency pose an almost moral conundrum:
whether to make things fast or make them easy. For example, the
classic Unix kernel typically did table lookup by linear search,
whereas Linux (when I last looked) typically used binary search.
The price of Linux's choice is that one must take care to keep
the tables sorted. Heavy discipline has to be imposed on making
entries and deletions.
Doug
What do you mean plan9 is dead? It's even possible make a facebook post
from inside plan9 nowadays!
https://twitter.com/bigatojj/status/949838932841201664
See vmx(1)
Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu:
Hi,
I have to take issue with the “plan9 is dead” statement,
I agree it seems on a downward spiral, but are a few who fight on.
[sent from my plan9]
-Steve
You can use make as much as you like; Go just doesn't need it. You can use
Go to fetch code from internet if you like, or you can do it yourself if
you prefer.
Regarding the "hardwired" directories, you can change it through an
environment variable.
Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon(a)orthanc.ca> escreveu:
That's the second endorsement I've seen for Go; I guess I should learn it.
>
In the scheme of "current" languages, Go is pretty good. With two major
caveats, IMO:
1) The build system. It doesn't work with make(1). That makes it a
non-starter for anything other than trivial projects at $WORK. While I
appreciate the arguments for the apparent simplicity of the "go" command,
that doesn't work for us. Which would have been fine, but for the entirely
antagonistic bent they have taken against being able to build Go programs
with make(1). Our build environment entirely precludes Go's promiscuous
insistence on unfettered internet access, and hardwired directory paths.
2) Hardwired directory paths for the development/build environment (see
above).
It seems they have unlearned all the UNIX lessons. Sad, really. I would
love to toss out Python, Ruby, PHP, Perl, et al. And could make the
argument for it, I think. But the build environment will never work in our
shop, therefore Go won't either.
And that ... sucks.
Hi,
Interested in some perspective here since the list has influential Linux
people like Ted Tso.
Linux has been described as influenced by Minix and System V. The Minix
connection is well discussed. The SysV connection something something
Linus had access to a spec manual. But I’d guess reality would be more
gradual — new contributors that liked CSRG BSD would have mostly gravitated
to the continuations in 386/BSDi/Net/Free that were concurrent to early and
formative Linux development.. so there’d be an implicit vacuum of BSD
people for Linux development.
What I am curious about is the continuing ignorance of BSD ideas. Linux
isn’t exactly insular; a lot of critical people and components came much
later on from other SysV flavors (lvm, jfs, xfs, RCU)
The kinds of BSD things I am talking about are ufs, kqueue, jails, pf,
Capsicum. Linux has grown alternatives, but with sometimes willful
ignorance of other technology. It seems clear epoll was not a good design
from the start. Despite jails not being taken to the logical conclusion of
modern containers like zones, the architecture is fundamentally closer
aligned to how people want to securely use containers versus namespaces and
cgroups. And Google ported Capscicum to Linux but it’s basically been
ignored in lieu of nebulous concepts like seccomp. And then there seems to
be outright hostility toward other platforms from the postmodern generation
with things like systemd.
This seems strange to me as BSD people are generally open to other /ideas/,
we have to be careful with Linux code due to license incompatibility, but
the converse is does not seem true either in interest in other ideas or
license hampering code flow.
The history of UNIX is spectacularly successful because different groups
got together at the table and agreeed on the ideas. Is there room for that
in the modern era where Linux is the monopoly OS? The Austin Group is
still a thing but it’s not clear people in any of the Freenix communities
really care about evolving the standards. I get that, but not so much
completely burrying ones head in the sand to what other OSes are doing. Is
there any future for UNIX as an “open system” in this climate or are people
going to go there separate ways?
Regards,
Kevin
We gained John von Neumann on this day in 1903, and if you haven't heard
of him then you are barely human... As computer science goes, he's right
up there with Alan Turing. There is speculation that he knew of Babbage's
work; see
https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… .
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
