If Lucent's offer were free and clear (like a GPL or OS license), it would be rude to complain about it. But it's not.
The license is actually an IP monkey trap. It pretends to be open, tempting us all to invest our time and effort into the release. But it's actually very restrictive, and gives Lucent many ways to pull the rug out from under us once we've "trapped" ourselves by investing our time and effort.
If Lucent is serious about getting people to use the release, they need to offer it under some License which involves a true fair exchange. I'm surprised that this isn't self-evident to the Plan 9 developers.
You other comments suggest that you feel Microsoft is a benign entity in the world of software. Looked at that way, it does seem like they would not have a problem with Open Source (or Free Software, for that matter).
I don't happen to believe that's the correct assessment. You might find it instructive to assume it's not for a moment and look for evidence that supports this opposing point of view.
The GPL is the license I prefer, and I support the FSF. I also accept other licenses, at least in that I don't refuse to use or develop on code with any Open Source license. I suspect that most of us are in this camp.
As for being "rabid", I suspect that RMS is considerably more flexible than, say, Brett Glass and his ilk. RMS has a goal, and generally acts in line with that goal, and sometimes that means supporting Open Source licenses instead of the GPL.
Personally, I believe that a schism between Free Software and Open Source can benefit only those who don't truly wish to see either succeed.
When I took the class as a sophomore we had to implement a reasonable facsimile of GNU make as well as a Lisp to C interpreter
Cool projects. I'm not surprised you found them valuable in the long term.
However, due to a massive amount of cheating that went largely unreported the powers that be decided to convert the class to the format that you suggested.
If it was largely unreported, why did the powers react to it?
What ended up happening is that students left the class with little over basic programming experience (a 2 hour coding quiz does not a l337 h4x0r make) and many people failed the class by simply not doing well on a single test.
This sounds kind of contradictory. You seem to be saying that the tests were bad because they overestimated the students' knowledge, but that they were also bad because they underestimated the students' knowledge (causing them to fail). Unless you think the students just slacked off.
Considering that test taking is in many cases and excercise in rote memorization, I have significant problems with making it worth anything over 50% of a students grade.
I don't see rote exams having much if any place in a CS curriculum. The exams I have in mind test skills and involve problem solving.
Eventually, I believe someone realized that it was better to let many people cheat and turn out a few decent students than curb cheating via proctored exams but turn out primarily half-baked students even among does that didn't cheat.
I simply refuse to believe that these are the only choices.
The problem is that the best way to learn how to program is actually to sit down and do it. A limited "proctored environment" doesn't cut it.
You're exactly missing my point, which is that each class activity should be primarily for the purpose of learning or the purpose of evaluation and not both.
No, writing a program in a proctored environment for one's grade is not particularly educational, and it's not supposed to be. The purpose is to evaluate what one has learned in the process of working through all of the previous ungraded pedagogical exercises, which is where the real learning happened.
So you're basically saying that they should de-emphasize the best programming teaching method to accommodate the cheaters.
No. I'm saying that normal programming projects should be reviewed but not graded. For the good students, this changes nothing at all.
This is an unfortunate gray area, and I think the University would be wise to eliminate it. In this case, 100% of the course grade could be given for
things students can't cheat on, like class participation, or
things for which the distinction between cheating and not is exceedingly clear cut.
So, for example, 45% of the grade could be the final, 10% for participation/attendance, and 45% for a project written by the student alone in a restricted environment (e.g., a proctored computer lab). Problem solved.
This is not to say that there shouldn't be other learning projects. There should be, and they should be non-credit and for the explicit purpose of having the students freely discuss and learn from.
That aside, I think this issue is more complicated than the article allows. I was a TA for an undergrad CS course once, and noticed that several of the brightest students turned in clearly duplicate work on one of the programming assignments. I worried over it for a while and ended up not pursuing it, but I'm not at all sure that was the right thing to do.
Except, if I understand correctly, that this is basically a debugger, and that it isn't a part of the OS Kernel.
No, though it does its magic using the same techniques that a debugger would (ptrace, currently). It is not part of the kernel--correct.
It seems more like a system emulation package that runs in user space, and within which a program can be executed (by the emulator).
It's not really an emulator, it's an interposition tool. It interposes itself right on the user/kernel boundary, though it is itself outside of the kernel.
Sounds like a nice tool, but not an OS kind of system.
It's not a replacement for global capabilities. (Nor are they a replacement for it!)
I wouldn't call Unix flawed in the sense that I think you mean. Its design is sound. It is limited in handling the user-vs-application problem, but it's probably better than anything else available. Windows-plus-Office, on the other hand, is in a completely different league--its design is like a magnet for bad luck.
I don't know enough about capabilities to have much of an opinion. It seems like a useful feature, though it's pretty coarse-grained and requires root assistance.
SUBTERFUGUE does many things--it wasn't intended to address this problem exlusively or in an optimal way.
Root is not required, though it may be run as root. It makes use of nothing not already present in the Linux 2.4 kernel; nothing needs to be enabled. It really doesn't do anything you couldn't do yourself with gdb, if you were really clever and patient.:-)
Basically, yes, though perhaps the sandbox usage could eventually more production.
In any case, it's not any kind of security hole, because it doesn't rely in any way on anything but vanilla kernel behavior. (It is a "security" headache to an application that's planning to do something sneaky, but that's intended.)
Exactly. Excellent! One of the practical uses for
SUBTERFUGUE would be to simulate environments that
are difficult to create in reality. How do you regression test behavior under disk-full conditions? You can actually fill the disk, but what a pain in the ass.
Although it hasn't been done yet, it'd be possible to write a fake-ptrace trick (along the lines of qtrace aka mec) which would allow you to fake a disk full while running the program in question under gdb (or strace or whatever).
SUBTERFUGUE runs on the vanilla 2.4 kernel. (Patches were required for previous versions, but they were wrapped into 2.4)
It would be potentially useful for trying out ideas like this, but as another poster noted, it's not really
intended for permanent implementations of such
things.
It's generally slower, but that doesn't necessarily mean it's slow. I've been using it to do manipulation and search of massive genome files, and it can be quite fast if you think carefully about what you're doing.
Much of the time, speed of implementation counts for more than speed of execution.
Can somebody please explain to me the benefit of doing this in Python?
The other replies have hit on most of the reasons:
Ease of Implementation: SUBTERFUGUE required a
lot of trial and error to get working (such as it does) and was
written mostly during hours of the night when I
really needed to be sleeping instead. Implementing
it in any other language, excepting perhaps
Lisp, would simply have taken more time than I had.
Ease of Use: One of the primary design goals was to enable a user with an idea to try it out in very short order, just the way that we use shell
tools like bash, tr, sort, etc, to do real-time
prototyping.
People seem to be assuming that subterfugue is kernel code. I just looked at the source, and it's not. It depends on some kernel patches for 2.3.x, but subterfugue itself is a user-level syscall interceptor.
Correct, but note that no patches are required for 2.4. It's meant to run on a vanilla kernel, just like 'strace'.
When they refer to sf as the subterfugue driver, they mean "driver" in the mushy sense of "anything that's not an application is a driver", not in the precise sense of something that gets loaded into the kernel.
Actually, by "driver" I just meant that 'sf' is the ringmaster that manages and applies all the
tricks, sort of like dejagnu is a driver for regression tests. As you note, this has nothing to do with kernel drivers.
Also, only programs (and their descendants) run explicitly via subterfugue are affected at all; it doesn't hook in at a level that allows it to operate on arbitrary processes.
Correct and construed as a benefit. SUBTERFUGUE was meant to ride herd on a single program or perhaps a small set, leaving the rest of the system alone. This means, for example, that it doesn't require any special privileges and that the rest of the system is unaffected by it.
Sometimes you do want to do things on a system level, and there are several other tools out there that take this approach. The right tool for the right job.
Subterfugue is basically a Python wrapper for strace, so you can inspect and modify syscalls and their arguments in Python instead of in C. Yes, it's neat, but not nearly as neat as being able to implement real drivers or network protocols or filesystems in Python (like this [lwn.net]).
FUSE (and several other tools like it) is cool. It's solving a different problem. As above, different tools for different tasks.
In its defense, I will point out that SUBTERFUGUE
is meant as a tool for experimenting and prototyping, and to be used primarily by an end user (perhaps during a development process, as with strace). Obviously building software meant for
distribution on top of it would probably be a blunder from
an engineering perspective.
In that case, the problem is not that software patents exist, but that the patent office is not doing its job correctly.
You could look at it that way, but I would argue
that there might be a slight chance we could get
software patents outlawed, whereas there is
absolutely no chance that the patent office will
start handling software patents correctly (i.e., by requiring a high-level of novelty and non-obviousness). As an organization, there
is simply no angle in it for them to do this, and
therefore they will not.
Have you read all software patents currently being granted?
Certainly not. I just have never seen or heard of
a piece of software that I would consider worthy
of a patent. The truly novel things that happen
in computer science are algorithms, which
is to say mathematical procedures, which by
definition should absolutely not be patentable, for the same reasons that equations are not.
When you exclude algorithms, nothing else in
software seems to rise to a level of strict
non-obviousness, IMO.
One does not patent ideas, one patents implementations. He knows this as should you all.
I'm sure that he does understand that this is how the patent system was intended to work. But this is not how the patent system currently does work. The patent office has of late been giving out patents on ideas (e.g., hyperlinking, one-click shopping, etc.), which is part of the reason that software patents have become such a disaster.
If the patent office would restrict themselves to truly novel, non-obvious ideas, the damage would thus be greatly contained. But essentially all software patents currently being granted fall outside this definition. Hence disaster.
Instead of allowing/encouraging corporations to dispose of evidence of their criminal behavior, wouldn't it make more sense to require them to preserve all of their documents for a limited time? (Limited in the Disney sense--175 years.)
Corporations are not people and they do not have a similar sense of moral compunction. Their rights should therefore be heavily restricted compared to us.
But the *huge* libraries of supported API's on CPAN, and the fact that the differences between versions is *well* documented (with source available, even), and the fact that the source can easily detect what version it is running under, and make appropriate adjustments, makes it still preferrable to me. Predictability and API support can outweigh Elegance, in my book.
I believe all of this is true for Python, except of
course that the CPAN-ish collection is smaller.
It's a newer language with (at the moment) fewer
users, so that's not surprising.
I believe every Perl programmer owes it to
themselves to at least try it out.
Slashdot Mirror
Mike
The license is actually an IP monkey trap. It pretends to be open, tempting us all to invest our time and effort into the release. But it's actually very restrictive, and gives Lucent many ways to pull the rug out from under us once we've "trapped" ourselves by investing our time and effort.
If Lucent is serious about getting people to use the release, they need to offer it under some License which involves a true fair exchange. I'm surprised that this isn't self-evident to the Plan 9 developers.
--Mike
I don't happen to believe that's the correct assessment. You might find it instructive to assume it's not for a moment and look for evidence that supports this opposing point of view.
Mike
As for being "rabid", I suspect that RMS is considerably more flexible than, say, Brett Glass and his ilk. RMS has a goal, and generally acts in line with that goal, and sometimes that means supporting Open Source licenses instead of the GPL.
Personally, I believe that a schism between Free Software and Open Source can benefit only those who don't truly wish to see either succeed.
Mike
Mike
Mike
Mike
No, writing a program in a proctored environment for one's grade is not particularly educational, and it's not supposed to be. The purpose is to evaluate what one has learned in the process of working through all of the previous ungraded pedagogical exercises, which is where the real learning happened.
No. I'm saying that normal programming projects should be reviewed but not graded. For the good students, this changes nothing at all.Mike
So, for example, 45% of the grade could be the final, 10% for participation/attendance, and 45% for a project written by the student alone in a restricted environment (e.g., a proctored computer lab). Problem solved.
This is not to say that there shouldn't be other learning projects. There should be, and they should be non-credit and for the explicit purpose of having the students freely discuss and learn from.
That aside, I think this issue is more complicated than the article allows. I was a TA for an undergrad CS course once, and noticed that several of the brightest students turned in clearly duplicate work on one of the programming assignments. I worried over it for a while and ended up not pursuing it, but I'm not at all sure that was the right thing to do.
Mike
Mike
I don't know enough about capabilities to have much of an opinion. It seems like a useful feature, though it's pretty coarse-grained and requires root assistance.
SUBTERFUGUE does many things--it wasn't intended to address this problem exlusively or in an optimal way.
Mike
Root is not required, though it may be run as root. It makes use of nothing not already present in the Linux 2.4 kernel; nothing needs to be enabled. It really doesn't do anything you couldn't do yourself with gdb, if you were really clever and patient. :-)
Mike
In any case, it's not any kind of security hole, because it doesn't rely in any way on anything but vanilla kernel behavior. (It is a "security" headache to an application that's planning to do something sneaky, but that's intended.)
Mike
Although it hasn't been done yet, it'd be possible to write a fake-ptrace trick (along the lines of qtrace aka mec) which would allow you to fake a disk full while running the program in question under gdb (or strace or whatever).
Mike
Mike
It would be potentially useful for trying out ideas like this, but as another poster noted, it's not really intended for permanent implementations of such things.
Mike
Much of the time, speed of implementation counts for more than speed of execution.
Mike
Mike
Sometimes you do want to do things on a system level, and there are several other tools out there that take this approach. The right tool for the right job.
FUSE (and several other tools like it) is cool. It's solving a different problem. As above, different tools for different tasks.Mike
Mike
Mike
When you exclude algorithms, nothing else in software seems to rise to a level of strict non-obviousness, IMO.
--Mike
If the patent office would restrict themselves to truly novel, non-obvious ideas, the damage would thus be greatly contained. But essentially all software patents currently being granted fall outside this definition. Hence disaster.
Mike
Corporations are not people and they do not have a similar sense of moral compunction. Their rights should therefore be heavily restricted compared to us.
Mike
I believe all of this is true for Python, except of course that the CPAN-ish collection is smaller. It's a newer language with (at the moment) fewer users, so that's not surprising.
I believe every Perl programmer owes it to themselves to at least try it out.
Mike