I might consider calling Linux a GNU/Linux system the day when the Atlas project ceases to exist because the Gnu compilers do a decent enough optimization job and when I can take my two million lines of legacy VAX code and compile them with the command "g77 -fvxt" without errors.
g77 wasn't designed to replace VAX Fortran any more than GNU was designed to
replace VMS.
And it's rather silly to complain about what g77 doesn't do for you now,
when its main developer stopped working on it years ago, and it was removed from the
GCC distribution (in favor of gfortran, a Fortran 95 compiler) as of GCC 4.0.
(By the way, does your old Visual C version 4.1 run on Solaris workstations?
Can it be built as a cross-compiler? How about VAX Fortran — has it been ported
to other OSes? I mean, yes, you're right, "writing a good, well optimized, complete
compiler is very hard"; try writing a good, well optimized, highly portable,
complete cross compiler, and then giving it (and its source code)
away for free.)
I honestly don't see how you can argue that read-only and hard-coded paths are analogous. Whether your code says "/usr/lib/something" vs. "././something" or "$library_path/something" doesn't determine this. Plus proper permissions seem to be what you're really talking about, which can be set per file, not just by directory;)...by modern application, I mean something that's not low-level, like a library or compiler, and written within the last few years
A read-only path that isn't absolute (such as "./queue/" or "$QUEUE/") isn't much of a read-only path once an executable has been convinced
to execute malicious code, since that code could easily do a chdir() or setenv() to a different directory, whether that executable is
the qmail component in question (say, qmail-queue, the only setuid-root program in qmail) or another component (such as qmail-inject,/usr/lib/sendmail, or qmail-smtpd) that invokes it. (E.g. qmail-smtpd is untrusted within qmail's security-obsessed architecture, and
could be exploited by the Guninski bug, but since it can't convince qmail-queue to inject mail into a different directory via chdir() or
setenv() before calling it, the exploitability is severely constrained.)
So you're right that just having the path encoding be read-only isn't enough; the effective path (after applying
transformations such as "./" -> "/foo/bar/", "~" -> "/home/luser", and "$QUEUE" -> "/var/qmail") must be hard-coded — which is
another way of saying it must be absolute, as well as constant, for maximum protection against an exploit (but that doesn't necessarily
assure that pointers to it, and the like, from within the executable are, themselves, read-only!).
As someone else pointed out in this thread, chroot() can still change that effective path, but that normally would just further limit the
damage that could be caused by a misdirected (via exploited calling program) or exploited qmail-queue — at that point, the change
definitely occurs only at the top level of the path (than by, say, an encoded path of "/var/qmail$QMAILID/", which opens a hole if
"$QMAILID" -> "/../..[...]"), is more tightly controlled by the OS (chroot jails are presumably more carefully audited for security flaws
than the other substitutions described above), etc.
Proper permissions are not sufficient protection; as you can imagine, file and dir protections are often incorrectly set, improperly
changed, or maliciously changed, by sysadmins or others. And permissions apply to passive objects (files), not active ones like executables,
which is (partly) why qmail also exploits multiple user IDs (UIDs) as well as group ID (GIDs) in Unix to achieve protection between
components.
For example, qmail's log output is not just logged to directories and files with the appropriate permissions; they also are
owned by a distinct user, qmaill, which is just for logging, and the logging daemons run under that UID, accepting input from whatever
other daemon is doing the work. So if that other daemon, say, qmail-smtpd, gets exploited somehow, the fact that it's running as user
qmaild, not qmaill, means that whatever log output was generated before, during, or (if you're lucky) after the exploit succeeded will
still get logged, and cannot be deleted, unless the OS itself allowed one (non-root) user to delete another user's files.
Note that I'm hardly "up to speed" on all the different ways Unix apps (like sendmail) have been exploited over the past 20
years, so I'm doing some guesswork here as to what DJB and others learned from such exploits. But I've had plenty of experience
with exploits (as well as bugs of varying degrees of nastiness) on various other OSes over the decades, and, as a compiler expert of
sorts, I really don't "see" source code so much as I see the machine code that might get generated from it (at an abstract level,
anyway; been awhile since I ac
There's no excuse for ever using hard coded paths in a modern application these days.
How do you define "a modern application"? Or do you mean "an application compiled into a modern executable-file format"?
In my experience, it's a lot harder to exploit (hack into) read-only portions of executables, which can include
constant strings (like "/var/qmail") as well as code.
Any mutable object, whether data or especially code (such as thunks), offers an opportunity for exploitation
that might not otherwise be present. E.g. mutable data and code can't typically reside in read-only VM that's backed up
by a DVD or CD-R instead of a large writable store (like a hard drive).
Now, maybe modern executable-file formats (ELF, or what-not) no longer usefully make these distinctions — in which
case the OSes on which they're built have perhaps sacrificed a historically useful additional barrier against intrusion,
especially of the undetected or undetectable variety. But I doubt all modern OSes have eliminated that capability,
and qmail was designed to run on, and leverage certain security features of, a variety of Unix-like OSes.
All it really accomplishes is making your software harder to administrate.
Yup. In my experience, qmail definitely makes for harder "interesting" configurations than it might have otherwise — though
not as hard as it might have been, had DJB not provided for files like conf-qmail (while at the same time somewhat
obscuring the actual path it sets within the *.h and *.c files generated from it, definitely an example of security by
obscurity), which make generation of multiple qmail configurations a SMOS (Small Matter Of Scripting).
Whether that's worth the time saved by learning, at 2am on a weekend, that your system has been rooted via an exploited
mailserver (such as insert-your-favorite-MTA-other-than-qmail), and spending hours, days, or even weeks trying to recover from that,
is worth considering.
You know, you could just code the thing in Java and eliminate this issue outright, as well as all possibility of buffer overruns... C is the worst possible language for Internet-facing servers.
I made a similar point (about C) in my writeup on the Guninski bugs (and DJB's response).
However, I'm not sure Java, or C++, Perl, Python, Ruby, Lisp, Scheme, Haskell, etc., are the right
response to the problem, because they (the interpreters, or the code the compilers generate) make
generous use of malloc() and free(), the resulting executables thereby being much more difficult to
predict and thus validate in terms of security, and probably more resource-intensive than
DJB's hand-coded C, therefore easier to DOS, which is still a problem for qmail components such
as qmail-smtpd.
Writing secure, reliable, efficient code is not just about selecting a language in which it's
hard to code bugs — it's about selecting an environment in which there
are likely to exist bugs (including taking substantially more resources to do something
than the coder reasonably expected).
I don't know how well various programming environments (such as Java) meet those requirements
today, never mind how well they did, if they existed as sufficiently-widely-ported
environments, back in the late 1990s when DJB started offering qmail.
(Lots of qmail enthusiasts use qpsmtpd, a Perl-encoded replacement for qmail-smtpd, to
get spam-fighting and other features. I'm under the impression they are comfortable doing
that because the component still fits within qmail's security-obsessed architecture, thus
severely limiting the negative effects of any exploit, and they've made a conscious decision
to accept the substantial increase, often unpredictable, in resource utilization for each
incoming SMTP connection. I gather Perl handles all the memory-allocation issues for them,
making code modification much easier, and avoiding the kinds of bugs that Guninski found in
qmail entirely, unless they're in the Perl interpreter itself.
I wonder who out there uses mail-server components
written in other languages, and how well they do with that?)
These exploits can be performed by any user who owns such hardware, and can read.
Not if qmail-popup, qmail-pop3d, and qmail-smtpd are run with VM limits set low enough (say, 1GB or less), and
the OS enforces those limits, which is how qmail is normally installed (that is, installed as directed by various sources
other than just the qmail-1.03 sources themselves).
But the installation instructions that qmail-1.03 itself provides don't really inform the sysadmin of that necessity and,
as I suggest on my web page about the problem, no developer should rely on the OS and sysadmin to enforce VM limits
in order to prevent coding bugs being turned into actual exploits.
(Hmm, at this point I think it's safe to say that I've spent more time publicly commenting on the as-yet-unfixed
Guninski qmail bugs than it would have taken me to fix them and publish the patches! I'm not sure what
conclusions to draw from that, if any....)
Does anyone know of a similarly-capable, widely-deployed MTA with as good a security track record as
qmail? Or, for that matter, of any actual qmail exploits in the wild, or in the lab?
Only because DJB won't honor it. People have found bugs in his code, but he refuses to acknowlege them.
As my page (to which you link) notes, these bugs are likely exploitable only in theory.
And I've been hired (and paid well) to modify qmail code, including patching it to fix bugs
as well as extending it, for years now, but nobody has even inquired as to what it'd
take to fix the "Guninski" bugs that might theoretically be exploitable — at least,
not so far.
I think that's a pretty sure indication that the qmail user base does not consider
those bugs to be sufficiently worrisome to fix. (I did publish a simple fix to one of the
first bugs Guninski found; that fix was incorporated into netqmail. But I did that gratis.)
I don't know offhand whether DJB has ever acknowledged any bugs in qmail.
But, just as code doesn't lie while comments can, code that is reasonably well-specified,
as qmail's components' interfaces are, cannot pretend bugs don't exist in it, even
if authors or fanboys do, just as it can't pretend it has bugs even when claimed otherwise[*].
So I don't particularly miss djb's opinions and pronouncements on such issues, since I can
read the code and decide for myself.
[*] There's a web page out there that claims "qmail-smtpd does not detect CR LF properly on packet boundaries",
which strikes me as complete and utter — as well as easily demonstrable, by simply looking at the code — nonsense.
Not that it can't happen, but it'd almost certainly be due to an OS, networking, or (non-qmail) library bug.
Tellingly, despite the high likelihood such a bug would result in huge numbers of legitimate emails being
rejected by many qmail servers worldwide, there's no information on this alleged bug beyond
somebody supposedly reporting it. That's only marginally more persuasive than saying "qmail-smtpd
dropped every third email on every server running it on March 17, 2001, between 11:45 and 12:15 UTC,
according to a guy I overheard in a bar the other day." Color me unimpressed.
I'll comment (inline) as someone who has come to appreciate certain of qmail's
strengths even while tolerating (to varying degrees) its weaknesses:
I thought it was hideous. From memory (it has been awhile):
Hard coded file and folder names (it must be in exactly one location, too bad if you have a need for two outgoing SMTP servers running on the same box with different configurations)
That's annoying, but basically a security feature — you can be
reasonably assured that a given qmail executable, especially qmail-queue (which is the only
setuid-root program in qmail), is hard-coded to operate on only certain directories
(aka folders) and files. And it's not "too bad" if you need to run a second SMTP server;
just configure, build, and install as many distinct qmails as you need, with the
configuration files (such as conf-qmail, normally/var/qmail) set
as you want them. But I think it could be more flexible without sacrificing security assurances.
Strange homegrown replacement for the standard C library
I gather djb's perception of the situation (at the time he wrote qmail
and related software) was such that he'd substitute "Secure" for "Strange" above,
but I don't personally know of exploitable bugs in contemporary C libraries, so I
can't vouch for that. However, exploitable bugs in C code that uses standard C libraries
are well-known, which is another reason I believe he grew his own C library.
Memory deallocation done by exiting the program
Definite win for security and speed, if you don't have memory-leak problems
as a result (and I don't think any qmail component does, modulo known issues with
requiring per-process VM limits on Internet-facing components such as qmail-smtpd).
As soon as your program starts down the path of calling free(), or, hey, even
malloc(), if it can reasonably avoid them, it gets much more complicated and
bug-prone, something you don't want in a system as crucial to have working correctly
with no exploitable bugs as an email server.
Odd preprocessor "template" functions
Haven't studied this enough to quite "get" what he was trying
to accomplish vs. other approaches that could have been used, but they are doggone
annoying to deal with at times.
A seeming hatred of descriptive variable or function names
Agreed.
I don't have fond memories of the experience.
qmail code is pretty ugly when looked at closely enough, and can seem
unnecessarily "different" from a more-distant perspective.
However, pull back far enough and look at it, and you might be able
to appreciate that it is, in its own way, a work of art: a reliable,
secure, powerful email system — just as pretty much any sufficiently
large and beautiful work of art can look pretty flawed when scrutinized
closely, especially without an awareness of the "big picture".
So if I wanted to play around with an email server and make it do all
sorts of slick stuff, I wouldn't pick qmail.
But if I wanted to improve a mail server in some fashion while still
being reasonably assured the resulting (modified) system wouldn't have
remotely exploitable bugs in it, based on what I know right now, I wouldn't
pick anything but qmail.
The younger workers will be no more distracted by cell phones ringing than they are by someone walking down the hallway past their door, cars driving past the building, the copy machine running down the hall, or birds chirping outside the window.
Most of that wouldn't distract me, but the copy machine running down the hall? That, I'd notice!
Re:Here's how it works from another perspective
on
How Image Spam Works
·
· Score: 1
Intelligent people can have poor self-esteem and lack assertiveness too, you know.
I don't think you're right about that. Well, maybe you are...what do I know? I guess I should just keep quiet....
I had no objection; I thought your ironic blanket statements were funny (although I wasn't sure that they were intentionally so); I was trying to play along! Sorry for the confusion.
Try this article on human brain cooling issues
(the domain name should be www.kortexplores.com, but it redirects to that IP address; from the home page,
it's under "Topic Index" / "Thinking About Thinking" / "Cranial Cooling and Intelligence" by Kort E Patterson).
I don't think I've seen that page before. I have no idea how trustworthy it is, but it talks about the reverse-blood-flow thingy in the
last several paragraphs, and the rest of it is mostly about what we were talking about here, so it seems like it
might be trustworthy.
Oh, I'm sure you're right (or in the ballpark) about that, and that few, if any, other
animals have as high a blood-flow percentage going to the brain.
I believe it's also the case that an important
evolutionary trait in humans is the ability for the blood flow through the brain to reverse itself
in high-heat situations, something other primates can't do. (It's something we're not aware of
when it happens, but I vaguely recall it has something to do with cooling the brain more rapidly
by changing the direction of blood flow. But I can't recall what the precise circumstances are,
or which direction is "normal" and which is "turbo".)
Turns out that through its evolution the colony had "determined" [...] that intelligence is not a survival trait.
Cool story, thanks for the summary!
I'm not sure intelligence isn't a survival trait, but active intelligence does probably hinder reproduction.
By "active intelligence" I mean not just a set of rules or encodings (which is what DNA amounts to), but their being actively
consulted in response to external stimula (via various senses) and potentially triggering various events (such as muscle twitches).
At the very least, active intelligence appears to require state changes (a wire goes from carrying 0 volts to 5 volts, or a neuron fires
a chemical change, whatever). The more intelligence that is involved, the more state changes are required, all else being equal.
And state changes both consume and give off energy.
So, just as a 1GHz CPU is, all else being equal, going to cost more to operate (and give off more heat) than a 1MHz CPU,
a more-intelligent brain is going to be more costly to operate. Long-term, resource-consumption issues like these affect reproductive rates;
if the 1MHz CPU (or equivalent brain) is just about as good at doing what is required as the 1GHz CPU/brain, and they're both considered
worth "reproducing", taking into account the costs of reproduction, the 1MHz CPU/brain will have the edge over the long haul.
There are other factors affecting reproductive rates and survivability, favorable to one side or the other.
For other examples of how intelligence can be a negative reproductive or survival trait, which surprised me when I first learn about them: more intelligence requires more size, and the size of a human baby's head, due to its large brain, is apparently a major factor
contributing to birth deformities and fatalities (for both child and mother); more intelligence usually requires more static structure,
thus exposing the intelligence to a greater likelihood of impeded operation due to defects in that structure; and more intelligence
implies that defects in the intelligence are more likely to result in negative consequences to large portions of the population (as in, one chimpanzee is unlikely to be able to trigger an extinction event, but one human being could conceivably do so).
While these examples are easily seen to be applicable to computers (especially CPUs) and even individuals (humans, primates, mammals, and
so on), I'm particularly fascinated by their apparent applicability to, and implications for, corporate entities, including governmental
organizations.
The time frame for this is 6 million years (since the human-chimp divergence.) How long have we been meaningfully been manipulating our enviornment in a way that blunts the forces of natural selection? Let's be generous and say...10,000 years? That's 1/600th of the time, and your hypothesis is that all of the 'extra' chimp evolution has occurred in that period of time?
It just doesn't make any sense.
[...]
And yes, IAAPG (population geneticist)
Here's a (wildly speculative) theory that accommodates both viewpoints: "manipulating our environment" has included widespread migration(s)
into areas where our adaptability exceeds that of chimpanzees, who had less ability to migrate as a means to relieve competitive pressures
and so were more prone to adapt to those pressures by "evolving" in the genetic sense.
So, while I agree with you that the usual (perhaps the intended) meaning of "manipulating our environment" probably isn't sufficient,
the fact that we can adapt to new environments might have reduced the pressure for our collective genome to evolve, as sharing of experiences, observations, inventions, and so on, came to supplement genetic evolution sufficiently to accommodate a population explosion. Our
artistic (individually creative) tendencies and highly adapted linguistic facilities seem to be among the most distinctive traits of our species.
Meanwhile, the fact that we were nevertheless willing and able to "reconnect" with disparate populations, as well as that we
used tools and other means (such as intelligence to forecast events like migrations and possibly to crowd out, replace, even extinguish
earlier hominids), meant we remained
one species worldwide, rather than radiationally evolving into a variety of species adapted to specific regions (although we have some
such adaptions, they are, I gather, not sufficient to make for distinct species, just races).
As a PG, does that theory make any sense to you? (IANAPG.)
...and very astute ones at that. I've been "wondering" along the same lines for years now.
It makes more sense to me by viewing intelligence as the servant of reproduction, rather than the other way 'round.
In "intelligent society" (with which I'm quite familiar and which much Western secular media essentially defines itself as representing, if
not defining), people generally assume reproduction is all about making sure future generations are at least as intelligence as the
current one. "Civilization" is, itself, another (very important) means to transmit intelligence to future generations.
From that point of view, the most important reproductive organ in the human body, especially the female's, is the brain.
While other reproductive organs are necessary to make a baby, the parents' (especially the mother's) intelligence and other mental qualities
will exert much more influence on how the child "turns out" than the physical aspects of reproduction.
However, the "Universe" (or Nature) itself really doesn't care about intelligence per se. Entropy guarantees an overall increase in
disorder, so, for information (such as DNA) to survive the corrupting effects of being in this universe, it must reproduce, either
directly or indirectly.
From that point of view, "intelligence" evolved merely to improve the odds of DNA surviving. That it currently happens to
be primarily human DNA isn't (according to modern science) the "point" of the Universe, neither does the Universe care that the
human species has suddenly exploded in population to several Billion and might actually be causing another extinction event,
just as the Universe doesn't care that the human species is probably the first to appear on this planet, if not in the entire
Universe, that is actually capable of preventing a much more severe extinction event (such as an asteroid hitting the planet,
or a supervolcano erupting).
Meanwhile, until a potential extinction event, threatening the human species itself, is on the horizon and requires extraordinary intelligence and coordination to detect and prevent it, the sheer success of the human species prevents the usual evolutionary pressures
compelling continued "progress" towards increased intelligence.
That means people who reproduce even somewhat more "vigorously" than the rest of the population will ultimately
become a majority of the population, even if they're "not as smart" as those who reproduce less vigorously.
And, socially and culturally, it certainly seems that "intelligence" is now widely viewed as corresponding to "global awareness", including
of such concerns as overpopulation; women's reproductive rights (which almost always means less reproduction, as men are
almost always willing, especially in a time and place of plenty, to reproduce more, given their substantially lower
personal investment in the process); and "quality of life" (including its length as well as the overall "expense" a life is deemed
to be worth society's provisioning), which typically includes enjoying the fruits of sexual desire without necessarily having
to bear any of the responsibilities for fulfilling those desires (such as bearing and raising actual children).
These views themselves can be viewed as somewhat akin to DNA that has an anti-reproductive component, and that therefore
tends to not flourish or even survive in the long run.
And these views are not necessarily correlated with religion so much as with whether they view sexual reproduction as low or high cost (corresponding roughly with the masculine versus the feminine outlooks on sexual reproduction). For an extreme example, the Shakers were
successful in many ways by "modern" intellectual assessments, but they viewed sexual reproduction as extremely high-cost, the result
being that they are no longer "reproducing" except via prop
Actually, the quote should have been "Computer Science is no more about computers than astronomy is about telescopes.", by the late Edsger Dijkstra
Ah, thanks for (presumably) correcting the quote as provided in other comments, since that formulation strikes me as correct.
However, I believe computers are more about Computer Science than telescopes are about Astronomy.
That is, one need not know or care about Astronomy to be able to conceive of the need for, design, and build telescopes. One does not study
Astronomy to learn such things. One might learn Optics, Physics, and various other skills, but not necessarily Astronomy.
However, it is difficult to conceive how anyone can really conceive of, design, and build a computer without knowing something of Computer Science
or building upon a knowledge base that includes it.
That's why people like myself are interested in Computer Science, even if we're not "Computer Scientists"; we're interested in computers,
in what makes them tick, and what might make them tick better (or faster).
That's also why so many of us can't understand why anyone would seriously want to "deemphasize programming" in a CompSci curriculum — we don't necessarily grasp how purely mathematical CompSci can be. To us, CompSci is useful only insofar as it makes programs run faster, smaller, more reliably, etc.
If I was similarly interested in telescopes, I'd learn about all sorts of things...but not Astronomy, unless I felt it was important
to be able to talk with Astronomers about their telescopes.
And if I was interested in Astronomy, I might have a very difficult time understanding why anybody would want to "deemphasize" looking at stars and galaxies, and thus "telescope use", in favor of "pure Astronomy", done with little or no regard to what is actually out there, what it actually looks like, how it actually behaves, etc.
But "purists" do exist, and some fields of study require such incredible focus to comprehend their abstract complexity that those who pursue them might decide it's best to avoid the friction of interaction with physical manifestations of the phenomena they're studying.
Interesting analogy you chose there: global warming is like having someone point a gun at you?
Okay, let's run with that. I'll agree the consequences (being shot and perhaps killed) are unacceptable, regardless of whether the risks at 10%/2% or 75%/25%.
Now, you have two schools of thought regarding how to respond.
The first group of experts (the 10%/2% group) says that even if the gunman fires, the bullet will take decades to reach you, giving you plenty of time to assess its trajectory, move out of the way, obtain suitable body armor, knock it down, even develop new technologies that will render the bullet, if not the gunman, impotent. They say "okay, maybe the gunman is there and will shoot, but guns, bullets, and shots fired happen, so it's best for each person to be individually free and able to respond how he or she chooses, rather than expecting everyone to just stand around and wait for some government program to solve the problem."
The second group (the more-worried 75%/25% group) agrees that bullet will take decades to reach you, but repeatedly and hysterically yells "We've got to ACT NOW!!!", and recommends widespread gun-control legislation, UN symposiums on seeking consensus, restrictions on developed countries (which make or fund most gun and bullet production) smelting metals, and that public schools teach children to be extremely fearful of guns and bullets but to somehow reduce their own use of and dependence on them, perhaps even saying people and corporations should buy "gun/bullet offsets" in order to keep things in "balance" — most or all of these tactics being admitted to require substantial increases in governmental revenues (taxes and fees) and reductions in individual liberties — while expecting you to just stand there and wait for them to solve the problem for you. Indeed, they gravely warn that any actions you take as an individual to protect yourself could lead, perversely, to the gunman (or someone else in the future) being that much more likely to take a shot at you. They also run commercials depicting someone like you seemingly ignoring the approaching bullet, then stepping out of the way just as it arrives, only to reveal a young girl now in its path with, presumably, no more time to dodge it, no armor, etc. (Yes, the Global Warming advocates have exploited children in ads like that. "Tick...tick...tick....")
Which course of action would you take, or recommend be taken?
If you choose the latter, please tell us how successful similar government initiatives have been in the past — I'm thinking of the Wars on Alcohol, Poverty, Drugs, Genocide, Sharing (copying, aka "pirating"), Spam, Child Predators, Obscenity/Pornography, Terrorism, and so on, all of which share, with the Wars on Guns and Climate Change, the axiomatic belief that government can substantially and effectively change the behaviors of over 6 Billion human beings via legislative fiat and zealous enforcement.
More to the point, which response is the more scientifically responsible? Not just the one that makes you feel like you're "doing something"?
Wow indeed! That's definitely different than how TOPS-10 BASIC worked. From your description, it sounds like Dartmouth BASIC was the OS! But I wonder why they bothered compiling and executing only a line at a time — was it a matter of keeping memory utilization low?
It does seem to me that one of BASIC's main innovations was allowing multiple interactive users to enter, edit, debug, test, and run programs on a single computer via TTY. In TOPS-10 BASIC, the program was kept in core (along with BASIC itself) and then compiled when you entered the RUN command (in fact I think there was a command that meant "compile but don't start running yet", but I forget its name). But TOPS-10 systems had plenty of memory for that sort of thing, supported swapping (in all models I think, starting with the KA-10, IIRC), and later VM (starting with the KI-10, IIRC). The timesharing aspects, switching between multiple users, were handled entirely by TOPS-10 itself; BASIC was just another program running within it, and much of that was "shared", memory-wise, between users (again, the OS mostly handled that, with lots of help from the PDP-10 architecture itself).
I did play around with a timesharing system that was built entirely around BASIC — the HP 2000C Prime, I think it was called. The one I used was hosted at Babson College. I can imagine that an entire computer system could be built, from nearly the ground up, to allow many users interactive use of the BASIC environment while making highly efficient use of core (if not CPU time), and maybe that's what Dartmouth BASIC originally was.
BTW, all the teletypes with which I was familiar (starting in the late 1960s, which postdates Dartmouth BASIC's introduction) were 110 baud, or 10cps. I don't recall ever hearing of 100-baud TTYs, but vaguely recall some components (acoustic couplers? serial interfaces?) supporting 75 baud.
Man this is a blast from the past. Wish I hadn't lost my old BASIC and other TOPS-10 manuals...though I still have some PDP-8 and related books, thank goodness!
You are correct. Indeed, the first source I checked to make sure I wasn't spouting nonsense (about IMPLICIT NONE being MIL-STD, not ANSI) was the g77 docs, which I found online fairly easily. I didn't find a section specifying the MIL-STD extensions, but it might be there and I just didn't look hard enough. (The g77 docs were intended to be reasonably thorough about describing the g77 "language", but focused on what's different about it vis-a-vis well-known standards like ANSI and MIL-STD, which readers could and would presumably obtain for themselves. They do list the MIL-STD intrinsics as such — like BTEST and MVBITS.)
I did see the language in the docs that said IMPLICIT NONE was an extension, however, and am quite sure it was also MIL-STD, as well as being popular with many vendors as an extension to offer (though some offered IMPLICIT UNDEFINED(A-Z) instead, IIRC). And, FWIW, g77 also offers some F90 features as extensions, though not the hairy math/array ones or the module/interface stuff so much as the more-elegant control constructs. (Some people still use g77, apparently not quite ready to trust its successor on their old codes, so I refer to it, but not the g77 docs themselves, in the present tense.)
I then confirmed there's no IMPLICIT NONE in ANSI FORTRAN 77 by looking at an online version of the standard. (I figure, better safe than sorry when posting to a public forum that offers no edit-or-delete-after-submit capabilities! And it'd be especially embarrassing if I got any of this wrong.)
Historically, I wonder if anyone paranoid enough about implicit typing and standards conformance might have used IMPLICIT CHARACTER (A-Z) or similar? That'd catch many sorts of bugs, but not a typo like WRITE (...) INDXE. ISTR hearing about that sort of thing, but probably decades ago.
You're both wrong, though trivially so. IMPLICIT NONE isn't ANSI FORTRAN 77; it's MIL-STD 1753, which is rarely not implemented by ANSI FORTRAN 77 compilers. (And it's Fortran 90 as well.) But it does basically what you say (that is, override the default used by Fortran 77 and most of its predecessors and successors).
Also, the only thing I saw with the GGP's program, as an ANSI FORTRAN 77 (or earlier?) program, was that the program name was more than six characters long, and contained an underscore. I think it's fine as a Fortran 90 program. It doesn't need to use IMPLICIT NONE in any case, since it uses no variables or functions.
As I said, I didn't personally use Dartmouth's original BASIC, but what you're describing isn't necessarily inconsistent with an environment in which the (stored) BASIC program is, when RUN, first compiled and then run, although the specific error message and other behaviors you claim to recall do suggest an interpreting environment (or a rather lax compiler).
Here the expression "X - Y" is evaluated, and if the result is less than zero, go to label 200, go to label 300 if equal, and to 400 if greater than zero.
No, that's arithmetic IF you're describing:
IF (200,300,400) X-Y
Computed GOTO example:
GOTO (200,300,400) X-Y
This means evaluate X-Y, convert to INTEGER, and if.EQ. 1, GOTO 200, else if.EQ. 2, GOTO 300, else if.EQ. 3, GOTO 400, else fall through to next statement. List not limited to only three statements labels. Kinda like C's switch construct.
No. The original language was not interpreted; it was compiled. It was originally supported within an environment that might be better described as "interactive", because the user (programmer) could enter code, modify code, delete code (this is partly why original BASIC required each statement to be given a unique "line number" by the programmer, and they specified the ordering of statement execution), and then run code — at which point a built-in compiler generated the machine code internally and invoked it.
I didn't ever use the original Dartmouth BASIC or systems, but I did both use and hack (somewhat significantly) the TOPS-10 version of BASIC that ran on PDP-10 systems. It was definitely a compiler as well; that was my first significant exposure to code generation (I was a youngish teenager at the time) as well as language design (since I modified the language accepted by my hacked-up version of BASIC).
It's been so long, I can't recall whether original or TOPS-10 BASIC could be interpreted rather than compiled, but FORTRAN generally couldn't, since DATA statements setting initial values of variables could be (and often were) specified after most or all of the imperative code, such as just before the final END statement.
So FORTRAN definitely wasn't designed to be interpreted, and the BASIC implementations that were interpretors might well have not supported all of the linguistic features of the original or early compiled BASICs in order to make interpreting work properly.
Anyway, I'm sorry to hear Backus has STOPped and gone on to that great COMMON block in the sky! May he CONTINUE in peace, and find even more interesting things to DO!
You raise good points, but, to me, it all boils down to this:
The "web" (the HTTP protocol) was designed, as a protocol built on top of TCP/IP, to inherently include and allow caching, mirroring, and other forms of content sharing, from the outset.
The web was not designed, from the outset, as a means to restrict access to content such that distinguishable advertising (including separately-served graphics and text) would always be presented whenever that content was presented. Indeed, it was explicitly designed as a means to give end-users control (via their browsers) to what will be shown them, as well as how it will be shown to them.
Therefore, anyone publishing their content via the web (permitting it to be served via the HTTP protocol) has already bought into the idea that end users, as well as their "agents" (intermediaries such as proxies, caches, mirrors, and other technologies that necessarily, possibly as well as intentionally, "shift time"), can pick and choose what they do and do not want to view.
In short, Shell herself entered into a contract by publishing via the web — a contract in which she agreed to permit just the sorts of things that go on in HTTP-land, as the protocol envisioned. (This is even without the robots.txt standard, which applies to only polite guests of a website.)
Similarly, nobody ("A") should complain that sending an email (via the SMTP protocol) to Z resulted in some kind of privacy violations by B, C, D,..., and Y, because they exchanged that email with each other, when it's inherent in the protocol that such exchanges will likely occur as the email propagates from A to Z. (Or, more obviously nuttily, though still akin to what Shell is claiming, that their copyright has been infringed because they emailed text including some anti-copying disclaimer to an email address they knew was "manned" by an automaton that published whatever was sent to it, such as a list manager or archive. If you want your English prose to be legally enforced, don't make it available to an entity that cannot read English but that you know will act contrary to it! Yet Shell did that when she gave her content to an HTTP server for publishing, and let that server provide it to HTTP clients, not all of which were necessarily humans that could read English.)
There are two ways to be sure that advertising published with your content remains connected to it as it (legally) propagates in HTTP-land:
Intertwine the content and advertising so closely they cannot be easily pulled apart (put 'em both in the same JPEG and accept the likely lack of automated indexing by others)
Don't publish your content on the web in the first place
My guess: archive.org did not seek to dismiss the copyright-infringement case because it's happier potentially setting a precedent against a poorly-represented individual who didn't engage in trivial "self-help" to avoid her plight and who might, for personal financial reasons, decide to make serious efforts to resolve the matter before it proceeds to trial (and costs her significant legal expenses as well as public humiliation).
Sometimes, when you believe you have a winning hand and especially when you know you are in the Right, had the best of intentions, and didn't go looking for a fight in the first place, as well as that you reasonably crossed all your t's and dotted your i's in the first place, you have to stand up and fight; at the very least, it shows you will likely do so, which might give future senders of cartoonies pause before filing their complaints.
Slashdot Mirror
g77 wasn't designed to replace VAX Fortran any more than GNU was designed to replace VMS.
And it's rather silly to complain about what g77 doesn't do for you now, when its main developer stopped working on it years ago, and it was removed from the GCC distribution (in favor of gfortran, a Fortran 95 compiler) as of GCC 4.0.
(By the way, does your old Visual C version 4.1 run on Solaris workstations? Can it be built as a cross-compiler? How about VAX Fortran — has it been ported to other OSes? I mean, yes, you're right, "writing a good, well optimized, complete compiler is very hard"; try writing a good, well optimized, highly portable, complete cross compiler, and then giving it (and its source code) away for free.)
A read-only path that isn't absolute (such as "./queue/" or "$QUEUE/") isn't much of a read-only path once an executable has been convinced to execute malicious code, since that code could easily do a chdir() or setenv() to a different directory, whether that executable is the qmail component in question (say, qmail-queue, the only setuid-root program in qmail) or another component (such as qmail-inject, /usr/lib/sendmail, or qmail-smtpd) that invokes it. (E.g. qmail-smtpd is untrusted within qmail's security-obsessed architecture, and
could be exploited by the Guninski bug, but since it can't convince qmail-queue to inject mail into a different directory via chdir() or
setenv() before calling it, the exploitability is severely constrained.)
So you're right that just having the path encoding be read-only isn't enough; the effective path (after applying transformations such as "./" -> "/foo/bar/", "~" -> "/home/luser", and "$QUEUE" -> "/var/qmail") must be hard-coded — which is another way of saying it must be absolute, as well as constant, for maximum protection against an exploit (but that doesn't necessarily assure that pointers to it, and the like, from within the executable are, themselves, read-only!).
As someone else pointed out in this thread, chroot() can still change that effective path, but that normally would just further limit the damage that could be caused by a misdirected (via exploited calling program) or exploited qmail-queue — at that point, the change definitely occurs only at the top level of the path (than by, say, an encoded path of "/var/qmail$QMAILID/", which opens a hole if "$QMAILID" -> "/../..[...]"), is more tightly controlled by the OS (chroot jails are presumably more carefully audited for security flaws than the other substitutions described above), etc.
Proper permissions are not sufficient protection; as you can imagine, file and dir protections are often incorrectly set, improperly changed, or maliciously changed, by sysadmins or others. And permissions apply to passive objects (files), not active ones like executables, which is (partly) why qmail also exploits multiple user IDs (UIDs) as well as group ID (GIDs) in Unix to achieve protection between components.
For example, qmail's log output is not just logged to directories and files with the appropriate permissions; they also are owned by a distinct user, qmaill, which is just for logging, and the logging daemons run under that UID, accepting input from whatever other daemon is doing the work. So if that other daemon, say, qmail-smtpd, gets exploited somehow, the fact that it's running as user qmaild, not qmaill, means that whatever log output was generated before, during, or (if you're lucky) after the exploit succeeded will still get logged, and cannot be deleted, unless the OS itself allowed one (non-root) user to delete another user's files.
Note that I'm hardly "up to speed" on all the different ways Unix apps (like sendmail) have been exploited over the past 20 years, so I'm doing some guesswork here as to what DJB and others learned from such exploits. But I've had plenty of experience with exploits (as well as bugs of varying degrees of nastiness) on various other OSes over the decades, and, as a compiler expert of sorts, I really don't "see" source code so much as I see the machine code that might get generated from it (at an abstract level, anyway; been awhile since I ac
How do you define "a modern application"? Or do you mean "an application compiled into a modern executable-file format"?
In my experience, it's a lot harder to exploit (hack into) read-only portions of executables, which can include constant strings (like "/var/qmail") as well as code.
Any mutable object, whether data or especially code (such as thunks), offers an opportunity for exploitation that might not otherwise be present. E.g. mutable data and code can't typically reside in read-only VM that's backed up by a DVD or CD-R instead of a large writable store (like a hard drive).
Now, maybe modern executable-file formats (ELF, or what-not) no longer usefully make these distinctions — in which case the OSes on which they're built have perhaps sacrificed a historically useful additional barrier against intrusion, especially of the undetected or undetectable variety. But I doubt all modern OSes have eliminated that capability, and qmail was designed to run on, and leverage certain security features of, a variety of Unix-like OSes.
Yup. In my experience, qmail definitely makes for harder "interesting" configurations than it might have otherwise — though not as hard as it might have been, had DJB not provided for files like conf-qmail (while at the same time somewhat obscuring the actual path it sets within the *.h and *.c files generated from it, definitely an example of security by obscurity), which make generation of multiple qmail configurations a SMOS (Small Matter Of Scripting).
Whether that's worth the time saved by learning, at 2am on a weekend, that your system has been rooted via an exploited mailserver (such as insert-your-favorite-MTA-other-than-qmail), and spending hours, days, or even weeks trying to recover from that, is worth considering.
I made a similar point (about C) in my writeup on the Guninski bugs (and DJB's response).
However, I'm not sure Java, or C++, Perl, Python, Ruby, Lisp, Scheme, Haskell, etc., are the right response to the problem, because they (the interpreters, or the code the compilers generate) make generous use of malloc() and free(), the resulting executables thereby being much more difficult to predict and thus validate in terms of security, and probably more resource-intensive than DJB's hand-coded C, therefore easier to DOS, which is still a problem for qmail components such as qmail-smtpd.
Writing secure, reliable, efficient code is not just about selecting a language in which it's hard to code bugs — it's about selecting an environment in which there are likely to exist bugs (including taking substantially more resources to do something than the coder reasonably expected).
I don't know how well various programming environments (such as Java) meet those requirements today, never mind how well they did, if they existed as sufficiently-widely-ported environments, back in the late 1990s when DJB started offering qmail.
(Lots of qmail enthusiasts use qpsmtpd, a Perl-encoded replacement for qmail-smtpd, to get spam-fighting and other features. I'm under the impression they are comfortable doing that because the component still fits within qmail's security-obsessed architecture, thus severely limiting the negative effects of any exploit, and they've made a conscious decision to accept the substantial increase, often unpredictable, in resource utilization for each incoming SMTP connection. I gather Perl handles all the memory-allocation issues for them, making code modification much easier, and avoiding the kinds of bugs that Guninski found in qmail entirely, unless they're in the Perl interpreter itself. I wonder who out there uses mail-server components written in other languages, and how well they do with that?)
Not if qmail-popup, qmail-pop3d, and qmail-smtpd are run with VM limits set low enough (say, 1GB or less), and the OS enforces those limits, which is how qmail is normally installed (that is, installed as directed by various sources other than just the qmail-1.03 sources themselves).
But the installation instructions that qmail-1.03 itself provides don't really inform the sysadmin of that necessity and, as I suggest on my web page about the problem, no developer should rely on the OS and sysadmin to enforce VM limits in order to prevent coding bugs being turned into actual exploits.
(Hmm, at this point I think it's safe to say that I've spent more time publicly commenting on the as-yet-unfixed Guninski qmail bugs than it would have taken me to fix them and publish the patches! I'm not sure what conclusions to draw from that, if any....)
Does anyone know of a similarly-capable, widely-deployed MTA with as good a security track record as qmail? Or, for that matter, of any actual qmail exploits in the wild, or in the lab?
As my page (to which you link) notes, these bugs are likely exploitable only in theory.
And I've been hired (and paid well) to modify qmail code, including patching it to fix bugs as well as extending it, for years now, but nobody has even inquired as to what it'd take to fix the "Guninski" bugs that might theoretically be exploitable — at least, not so far.
I think that's a pretty sure indication that the qmail user base does not consider those bugs to be sufficiently worrisome to fix. (I did publish a simple fix to one of the first bugs Guninski found; that fix was incorporated into netqmail. But I did that gratis.)
I don't know offhand whether DJB has ever acknowledged any bugs in qmail. But, just as code doesn't lie while comments can, code that is reasonably well-specified, as qmail's components' interfaces are, cannot pretend bugs don't exist in it, even if authors or fanboys do, just as it can't pretend it has bugs even when claimed otherwise[*]. So I don't particularly miss djb's opinions and pronouncements on such issues, since I can read the code and decide for myself.
[*] There's a web page out there that claims "qmail-smtpd does not detect CR LF properly on packet boundaries", which strikes me as complete and utter — as well as easily demonstrable, by simply looking at the code — nonsense. Not that it can't happen, but it'd almost certainly be due to an OS, networking, or (non-qmail) library bug. Tellingly, despite the high likelihood such a bug would result in huge numbers of legitimate emails being rejected by many qmail servers worldwide, there's no information on this alleged bug beyond somebody supposedly reporting it. That's only marginally more persuasive than saying "qmail-smtpd dropped every third email on every server running it on March 17, 2001, between 11:45 and 12:15 UTC, according to a guy I overheard in a bar the other day." Color me unimpressed.
I'll comment (inline) as someone who has come to appreciate certain of qmail's strengths even while tolerating (to varying degrees) its weaknesses:
qmail code is pretty ugly when looked at closely enough, and can seem unnecessarily "different" from a more-distant perspective.
However, pull back far enough and look at it, and you might be able to appreciate that it is, in its own way, a work of art: a reliable, secure, powerful email system — just as pretty much any sufficiently large and beautiful work of art can look pretty flawed when scrutinized closely, especially without an awareness of the "big picture".
So if I wanted to play around with an email server and make it do all sorts of slick stuff, I wouldn't pick qmail.
But if I wanted to improve a mail server in some fashion while still being reasonably assured the resulting (modified) system wouldn't have remotely exploitable bugs in it, based on what I know right now, I wouldn't pick anything but qmail.
Most of that wouldn't distract me, but the copy machine running down the hall? That, I'd notice!
I don't think you're right about that. Well, maybe you are...what do I know? I guess I should just keep quiet....
Ummm...what?!
Try this article on human brain cooling issues (the domain name should be www.kortexplores.com, but it redirects to that IP address; from the home page, it's under "Topic Index" / "Thinking About Thinking" / "Cranial Cooling and Intelligence" by Kort E Patterson).
I don't think I've seen that page before. I have no idea how trustworthy it is, but it talks about the reverse-blood-flow thingy in the last several paragraphs, and the rest of it is mostly about what we were talking about here, so it seems like it might be trustworthy.
Oh, I'm sure you're right (or in the ballpark) about that, and that few, if any, other animals have as high a blood-flow percentage going to the brain.
I believe it's also the case that an important evolutionary trait in humans is the ability for the blood flow through the brain to reverse itself in high-heat situations, something other primates can't do. (It's something we're not aware of when it happens, but I vaguely recall it has something to do with cooling the brain more rapidly by changing the direction of blood flow. But I can't recall what the precise circumstances are, or which direction is "normal" and which is "turbo".)
Cool story, thanks for the summary!
I'm not sure intelligence isn't a survival trait, but active intelligence does probably hinder reproduction.
By "active intelligence" I mean not just a set of rules or encodings (which is what DNA amounts to), but their being actively consulted in response to external stimula (via various senses) and potentially triggering various events (such as muscle twitches).
At the very least, active intelligence appears to require state changes (a wire goes from carrying 0 volts to 5 volts, or a neuron fires a chemical change, whatever). The more intelligence that is involved, the more state changes are required, all else being equal.
And state changes both consume and give off energy.
So, just as a 1GHz CPU is, all else being equal, going to cost more to operate (and give off more heat) than a 1MHz CPU, a more-intelligent brain is going to be more costly to operate. Long-term, resource-consumption issues like these affect reproductive rates; if the 1MHz CPU (or equivalent brain) is just about as good at doing what is required as the 1GHz CPU/brain, and they're both considered worth "reproducing", taking into account the costs of reproduction, the 1MHz CPU/brain will have the edge over the long haul.
There are other factors affecting reproductive rates and survivability, favorable to one side or the other.
For other examples of how intelligence can be a negative reproductive or survival trait, which surprised me when I first learn about them: more intelligence requires more size, and the size of a human baby's head, due to its large brain, is apparently a major factor contributing to birth deformities and fatalities (for both child and mother); more intelligence usually requires more static structure, thus exposing the intelligence to a greater likelihood of impeded operation due to defects in that structure; and more intelligence implies that defects in the intelligence are more likely to result in negative consequences to large portions of the population (as in, one chimpanzee is unlikely to be able to trigger an extinction event, but one human being could conceivably do so).
While these examples are easily seen to be applicable to computers (especially CPUs) and even individuals (humans, primates, mammals, and so on), I'm particularly fascinated by their apparent applicability to, and implications for, corporate entities, including governmental organizations.
Here's a (wildly speculative) theory that accommodates both viewpoints: "manipulating our environment" has included widespread migration(s) into areas where our adaptability exceeds that of chimpanzees, who had less ability to migrate as a means to relieve competitive pressures and so were more prone to adapt to those pressures by "evolving" in the genetic sense.
So, while I agree with you that the usual (perhaps the intended) meaning of "manipulating our environment" probably isn't sufficient, the fact that we can adapt to new environments might have reduced the pressure for our collective genome to evolve, as sharing of experiences, observations, inventions, and so on, came to supplement genetic evolution sufficiently to accommodate a population explosion. Our artistic (individually creative) tendencies and highly adapted linguistic facilities seem to be among the most distinctive traits of our species.
Meanwhile, the fact that we were nevertheless willing and able to "reconnect" with disparate populations, as well as that we used tools and other means (such as intelligence to forecast events like migrations and possibly to crowd out, replace, even extinguish earlier hominids), meant we remained one species worldwide, rather than radiationally evolving into a variety of species adapted to specific regions (although we have some such adaptions, they are, I gather, not sufficient to make for distinct species, just races).
As a PG, does that theory make any sense to you? (IANAPG.)
...and very astute ones at that. I've been "wondering" along the same lines for years now.
It makes more sense to me by viewing intelligence as the servant of reproduction, rather than the other way 'round.
In "intelligent society" (with which I'm quite familiar and which much Western secular media essentially defines itself as representing, if not defining), people generally assume reproduction is all about making sure future generations are at least as intelligence as the current one. "Civilization" is, itself, another (very important) means to transmit intelligence to future generations.
From that point of view, the most important reproductive organ in the human body, especially the female's, is the brain. While other reproductive organs are necessary to make a baby, the parents' (especially the mother's) intelligence and other mental qualities will exert much more influence on how the child "turns out" than the physical aspects of reproduction.
However, the "Universe" (or Nature) itself really doesn't care about intelligence per se. Entropy guarantees an overall increase in disorder, so, for information (such as DNA) to survive the corrupting effects of being in this universe, it must reproduce, either directly or indirectly.
From that point of view, "intelligence" evolved merely to improve the odds of DNA surviving. That it currently happens to be primarily human DNA isn't (according to modern science) the "point" of the Universe, neither does the Universe care that the human species has suddenly exploded in population to several Billion and might actually be causing another extinction event, just as the Universe doesn't care that the human species is probably the first to appear on this planet, if not in the entire Universe, that is actually capable of preventing a much more severe extinction event (such as an asteroid hitting the planet, or a supervolcano erupting).
Meanwhile, until a potential extinction event, threatening the human species itself, is on the horizon and requires extraordinary intelligence and coordination to detect and prevent it, the sheer success of the human species prevents the usual evolutionary pressures compelling continued "progress" towards increased intelligence.
That means people who reproduce even somewhat more "vigorously" than the rest of the population will ultimately become a majority of the population, even if they're "not as smart" as those who reproduce less vigorously.
And, socially and culturally, it certainly seems that "intelligence" is now widely viewed as corresponding to "global awareness", including of such concerns as overpopulation; women's reproductive rights (which almost always means less reproduction, as men are almost always willing, especially in a time and place of plenty, to reproduce more, given their substantially lower personal investment in the process); and "quality of life" (including its length as well as the overall "expense" a life is deemed to be worth society's provisioning), which typically includes enjoying the fruits of sexual desire without necessarily having to bear any of the responsibilities for fulfilling those desires (such as bearing and raising actual children).
These views themselves can be viewed as somewhat akin to DNA that has an anti-reproductive component, and that therefore tends to not flourish or even survive in the long run.
And these views are not necessarily correlated with religion so much as with whether they view sexual reproduction as low or high cost (corresponding roughly with the masculine versus the feminine outlooks on sexual reproduction). For an extreme example, the Shakers were successful in many ways by "modern" intellectual assessments, but they viewed sexual reproduction as extremely high-cost, the result being that they are no longer "reproducing" except via prop
Ah, thanks for (presumably) correcting the quote as provided in other comments, since that formulation strikes me as correct.
However, I believe computers are more about Computer Science than telescopes are about Astronomy.
That is, one need not know or care about Astronomy to be able to conceive of the need for, design, and build telescopes. One does not study Astronomy to learn such things. One might learn Optics, Physics, and various other skills, but not necessarily Astronomy.
However, it is difficult to conceive how anyone can really conceive of, design, and build a computer without knowing something of Computer Science or building upon a knowledge base that includes it.
That's why people like myself are interested in Computer Science, even if we're not "Computer Scientists"; we're interested in computers, in what makes them tick, and what might make them tick better (or faster).
That's also why so many of us can't understand why anyone would seriously want to "deemphasize programming" in a CompSci curriculum — we don't necessarily grasp how purely mathematical CompSci can be. To us, CompSci is useful only insofar as it makes programs run faster, smaller, more reliably, etc.
If I was similarly interested in telescopes, I'd learn about all sorts of things...but not Astronomy, unless I felt it was important to be able to talk with Astronomers about their telescopes.
And if I was interested in Astronomy, I might have a very difficult time understanding why anybody would want to "deemphasize" looking at stars and galaxies, and thus "telescope use", in favor of "pure Astronomy", done with little or no regard to what is actually out there, what it actually looks like, how it actually behaves, etc.
But "purists" do exist, and some fields of study require such incredible focus to comprehend their abstract complexity that those who pursue them might decide it's best to avoid the friction of interaction with physical manifestations of the phenomena they're studying.
Interesting analogy you chose there: global warming is like having someone point a gun at you?
Okay, let's run with that. I'll agree the consequences (being shot and perhaps killed) are unacceptable, regardless of whether the risks at 10%/2% or 75%/25%.
Now, you have two schools of thought regarding how to respond.
The first group of experts (the 10%/2% group) says that even if the gunman fires, the bullet will take decades to reach you, giving you plenty of time to assess its trajectory, move out of the way, obtain suitable body armor, knock it down, even develop new technologies that will render the bullet, if not the gunman, impotent. They say "okay, maybe the gunman is there and will shoot, but guns, bullets, and shots fired happen, so it's best for each person to be individually free and able to respond how he or she chooses, rather than expecting everyone to just stand around and wait for some government program to solve the problem."
The second group (the more-worried 75%/25% group) agrees that bullet will take decades to reach you, but repeatedly and hysterically yells "We've got to ACT NOW!!!", and recommends widespread gun-control legislation, UN symposiums on seeking consensus, restrictions on developed countries (which make or fund most gun and bullet production) smelting metals, and that public schools teach children to be extremely fearful of guns and bullets but to somehow reduce their own use of and dependence on them, perhaps even saying people and corporations should buy "gun/bullet offsets" in order to keep things in "balance" — most or all of these tactics being admitted to require substantial increases in governmental revenues (taxes and fees) and reductions in individual liberties — while expecting you to just stand there and wait for them to solve the problem for you. Indeed, they gravely warn that any actions you take as an individual to protect yourself could lead, perversely, to the gunman (or someone else in the future) being that much more likely to take a shot at you. They also run commercials depicting someone like you seemingly ignoring the approaching bullet, then stepping out of the way just as it arrives, only to reveal a young girl now in its path with, presumably, no more time to dodge it, no armor, etc. (Yes, the Global Warming advocates have exploited children in ads like that. "Tick...tick...tick....")
Which course of action would you take, or recommend be taken?
If you choose the latter, please tell us how successful similar government initiatives have been in the past — I'm thinking of the Wars on Alcohol, Poverty, Drugs, Genocide, Sharing (copying, aka "pirating"), Spam, Child Predators, Obscenity/Pornography, Terrorism, and so on, all of which share, with the Wars on Guns and Climate Change, the axiomatic belief that government can substantially and effectively change the behaviors of over 6 Billion human beings via legislative fiat and zealous enforcement.
More to the point, which response is the more scientifically responsible? Not just the one that makes you feel like you're "doing something"?
Wow indeed! That's definitely different than how TOPS-10 BASIC worked. From your description, it sounds like Dartmouth BASIC was the OS! But I wonder why they bothered compiling and executing only a line at a time — was it a matter of keeping memory utilization low?
It does seem to me that one of BASIC's main innovations was allowing multiple interactive users to enter, edit, debug, test, and run programs on a single computer via TTY. In TOPS-10 BASIC, the program was kept in core (along with BASIC itself) and then compiled when you entered the RUN command (in fact I think there was a command that meant "compile but don't start running yet", but I forget its name). But TOPS-10 systems had plenty of memory for that sort of thing, supported swapping (in all models I think, starting with the KA-10, IIRC), and later VM (starting with the KI-10, IIRC). The timesharing aspects, switching between multiple users, were handled entirely by TOPS-10 itself; BASIC was just another program running within it, and much of that was "shared", memory-wise, between users (again, the OS mostly handled that, with lots of help from the PDP-10 architecture itself).
I did play around with a timesharing system that was built entirely around BASIC — the HP 2000C Prime, I think it was called. The one I used was hosted at Babson College. I can imagine that an entire computer system could be built, from nearly the ground up, to allow many users interactive use of the BASIC environment while making highly efficient use of core (if not CPU time), and maybe that's what Dartmouth BASIC originally was.
BTW, all the teletypes with which I was familiar (starting in the late 1960s, which postdates Dartmouth BASIC's introduction) were 110 baud, or 10cps. I don't recall ever hearing of 100-baud TTYs, but vaguely recall some components (acoustic couplers? serial interfaces?) supporting 75 baud.
Man this is a blast from the past. Wish I hadn't lost my old BASIC and other TOPS-10 manuals...though I still have some PDP-8 and related books, thank goodness!
You are correct. Indeed, the first source I checked to make sure I wasn't spouting nonsense (about IMPLICIT NONE being MIL-STD, not ANSI) was the g77 docs, which I found online fairly easily. I didn't find a section specifying the MIL-STD extensions, but it might be there and I just didn't look hard enough. (The g77 docs were intended to be reasonably thorough about describing the g77 "language", but focused on what's different about it vis-a-vis well-known standards like ANSI and MIL-STD, which readers could and would presumably obtain for themselves. They do list the MIL-STD intrinsics as such — like BTEST and MVBITS.)
I did see the language in the docs that said IMPLICIT NONE was an extension, however, and am quite sure it was also MIL-STD, as well as being popular with many vendors as an extension to offer (though some offered IMPLICIT UNDEFINED(A-Z) instead, IIRC). And, FWIW, g77 also offers some F90 features as extensions, though not the hairy math/array ones or the module/interface stuff so much as the more-elegant control constructs. (Some people still use g77, apparently not quite ready to trust its successor on their old codes, so I refer to it, but not the g77 docs themselves, in the present tense.)
I then confirmed there's no IMPLICIT NONE in ANSI FORTRAN 77 by looking at an online version of the standard. (I figure, better safe than sorry when posting to a public forum that offers no edit-or-delete-after-submit capabilities! And it'd be especially embarrassing if I got any of this wrong.)
Historically, I wonder if anyone paranoid enough about implicit typing and standards conformance might have used IMPLICIT CHARACTER (A-Z) or similar? That'd catch many sorts of bugs, but not a typo like WRITE (...) INDXE. ISTR hearing about that sort of thing, but probably decades ago.
You're both wrong, though trivially so. IMPLICIT NONE isn't ANSI FORTRAN 77; it's MIL-STD 1753, which is rarely not implemented by ANSI FORTRAN 77 compilers. (And it's Fortran 90 as well.) But it does basically what you say (that is, override the default used by Fortran 77 and most of its predecessors and successors).
The GP wrote "IMPLICIT DOUBLE F". Actually, it's written "IMPLICIT DOUBLE PRECISION (F)".
Also, the only thing I saw with the GGP's program, as an ANSI FORTRAN 77 (or earlier?) program, was that the program name was more than six characters long, and contained an underscore. I think it's fine as a Fortran 90 program. It doesn't need to use IMPLICIT NONE in any case, since it uses no variables or functions.
As I said, I didn't personally use Dartmouth's original BASIC, but what you're describing isn't necessarily inconsistent with an environment in which the (stored) BASIC program is, when RUN, first compiled and then run, although the specific error message and other behaviors you claim to recall do suggest an interpreting environment (or a rather lax compiler).
And, FWIW, Wikipedia's writeup on BASIC states that:(Wish I knew of another source I could trust more, though.)
No, that's arithmetic IF you're describing:
Computed GOTO example:
This means evaluate X-Y, convert to INTEGER, and if .EQ. 1, GOTO 200, else if .EQ. 2, GOTO 300, else if .EQ. 3, GOTO 400, else fall through to next statement. List not limited to only three statements labels. Kinda like C's switch construct.
No. The original language was not interpreted; it was compiled. It was originally supported within an environment that might be better described as "interactive", because the user (programmer) could enter code, modify code, delete code (this is partly why original BASIC required each statement to be given a unique "line number" by the programmer, and they specified the ordering of statement execution), and then run code — at which point a built-in compiler generated the machine code internally and invoked it.
I didn't ever use the original Dartmouth BASIC or systems, but I did both use and hack (somewhat significantly) the TOPS-10 version of BASIC that ran on PDP-10 systems. It was definitely a compiler as well; that was my first significant exposure to code generation (I was a youngish teenager at the time) as well as language design (since I modified the language accepted by my hacked-up version of BASIC).
It's been so long, I can't recall whether original or TOPS-10 BASIC could be interpreted rather than compiled, but FORTRAN generally couldn't, since DATA statements setting initial values of variables could be (and often were) specified after most or all of the imperative code, such as just before the final END statement.
So FORTRAN definitely wasn't designed to be interpreted, and the BASIC implementations that were interpretors might well have not supported all of the linguistic features of the original or early compiled BASICs in order to make interpreting work properly.
Anyway, I'm sorry to hear Backus has STOPped and gone on to that great COMMON block in the sky! May he CONTINUE in peace, and find even more interesting things to DO!
Therefore, anyone publishing their content via the web (permitting it to be served via the HTTP protocol) has already bought into the idea that end users, as well as their "agents" (intermediaries such as proxies, caches, mirrors, and other technologies that necessarily, possibly as well as intentionally, "shift time"), can pick and choose what they do and do not want to view.
In short, Shell herself entered into a contract by publishing via the web — a contract in which she agreed to permit just the sorts of things that go on in HTTP-land, as the protocol envisioned. (This is even without the robots.txt standard, which applies to only polite guests of a website.)
Similarly, nobody ("A") should complain that sending an email (via the SMTP protocol) to Z resulted in some kind of privacy violations by B, C, D, ..., and Y, because they exchanged that email with each other, when it's inherent in the protocol that such exchanges will likely occur as the email propagates from A to Z. (Or, more obviously nuttily, though still akin to what Shell is claiming, that their copyright has been infringed because they emailed text including some anti-copying disclaimer to an email address they knew was "manned" by an automaton that published whatever was sent to it, such as a list manager or archive. If you want your English prose to be legally enforced, don't make it available to an entity that cannot read English but that you know will act contrary to it! Yet Shell did that when she gave her content to an HTTP server for publishing, and let that server provide it to HTTP clients, not all of which were necessarily humans that could read English.)
There are two ways to be sure that advertising published with your content remains connected to it as it (legally) propagates in HTTP-land:
My guess: archive.org did not seek to dismiss the copyright-infringement case because it's happier potentially setting a precedent against a poorly-represented individual who didn't engage in trivial "self-help" to avoid her plight and who might, for personal financial reasons, decide to make serious efforts to resolve the matter before it proceeds to trial (and costs her significant legal expenses as well as public humiliation).
Sometimes, when you believe you have a winning hand and especially when you know you are in the Right, had the best of intentions, and didn't go looking for a fight in the first place, as well as that you reasonably crossed all your t's and dotted your i's in the first place, you have to stand up and fight; at the very least, it shows you will likely do so, which might give future senders of cartoonies pause before filing their complaints.