The relevant difference among these statements is that Reiser might, in fact, have murdered his wife in cold blood. I was going to say that the jury is still out, but of course that's not just a figure of speech in this case; according to Wikipedia, they will be convened in May.
The rest of the post was sort of funny, but that part was unjustifiable. Let the law do its work.
He didn't invent the idea, but he wrote a well-known "Open Letter to Hobbyists" that attempted to justify the idea to a population of hackers who thought it was stupid.
It varies a lot from university to university. Generally grad students in the sciences, and also in computer science, work as employees of the university, which is where the university gets the leverage to possibly expropriate their intellectual work and turn it into intellectual property. Some years ago I bought a book entitled, "Who owns intellectual work?" about this issue, but I never got around to reading it.
I have been thinking about this for a long time, but I really like the way Jamie has focused the question here. I will write an essay in answer to the question --- "What's the equivalent of free software for web services?" --- and post it to kragen-tol as soon as I can.
Some examples of fiction from the chapter on the Web. Done in a hurry, I have to get back to work.
p.3 (135): when I'm coding something I don't understand, I stop and spike it out or read about it, alone, not with a pair, rather than trying to code it with a pair. My pair does not hold my hand, ever, nor hug me. Our high-level requirements are written, in English, on note cards, not in C++ or any other programming language; but it's true that our low-level requirements are in our unit tests. And when I'm writing unit tests, it's not in order to find bugs; it's in order to formalize the specification of a small part of the system and check it against its specification. Occasionally they do find bugs when I'm writing them, but that's because I've decided that some piece of code I need to refactor is insufficiently tested. On those occasions, I feel great, because I have just found (and am about to fix) a bug before it hit anybody in production.
The entanglement of fact and fiction is dangerous here. Obviously it's fictitious that your pair will hold your hand or hug you, at least in most workplaces, but the subtler fictions about the role of unit tests and requirements specs in the XP development process would be easy to mistake for assertions of fact; and they're mixed in with truths and half-truths, like the fact that some of our requirements are in unit tests, and we enjoy our work a great deal.
And spiking and story cards are not peripheral, minor aspects of XP; they've been part of the process since C3, they're extensively discussed on the Wiki and in Kent's very first XP book, and there's really no excuse for this level of ignorance about them --- except carelessness about the truth.
p.4 (136): our room sometimes got stinky or noisy, so we solved the problem. We have little orange signs we hold up when the room starts to get noisy, and we ask our pair to brush their teeth or take a shower when they start to smell bad. (This rarely happens, though.) Clearly we were doing XP when we had those problems, and we still are, so I can't claim they're never problems with XP. But XP gives you the tools to solve them: courage, experimentation, and a practice of rearranging your workplace for maximal productivity.
p.5 (137): XP doesn't mandate a switching interval, and many XP teams use intervals greater than a couple of hours. We switch once or twice a day. Pairing doesn't require two programmers to do the work one programmer was previously doing; typically, they do more and better work, and simultaneously talk about the code and the environment. (So what the book claims is "obvious" about pairing is not only not obvious, it isn't even true.) In non-pair environments, teams typically spend a fair bit of time discussing the code in order to get a relatively poor collective understanding of it; in XP, that's built into the pairing process. The book mentions how pairing compensates for the lack of up-front design and design documentation, but not how it improves your communication about other issues --- issues that never get written down in most development teams of any kind.
p. 6 (138) is clearly marked as fiction in its entirety --- it consists of one person's speculation about the potential difficulties of pairing with one other person or working in an open workspace, followed by a satirical song about pairing. The satirical song asserts that XP programmers would rather go home than switch pairs at the beginning of a new day (clearly absurd, the flip side of the apparently-serious "switch every two hours" strawman a couple of pages ago), and that they are unable to write code or watch unit tests run alone. In reality --- at least, on my XP team, in common XP practice, and in the XP literature --- we switch pairs at least once a day anyway, and we write spike code and run unit tests singleton (alone), except when we think we need to discuss something with someone. I guess you could still be "doing XP" if you always spiked and ran unit tests in pairs, but you wou
Ron Jeffries wrote a good review of this book last month; his review avoids most of the flaws the comments here find in this review.
I've only read one chapter, the one up on the web, but it's quite silly. The author repeatedly describes how one team or another did some dumb stuff and it didn't work; many of these anecdotes are parodic fiction, and obviously so, but some of them are presumably real. Then he explains that that dumb stuff didn't work. The trouble is that a reader with no XP experience might be fooled into thinking that XP advocates doing that dumb stuff.
The trouble with liberals listening to Rush Limbaugh, as one poster suggested, is that Rush makes up a lot of lies and passes them off as truth. (See Al Franken's earlier book for details.) If you don't spend ten minutes investigating facts for every minute you spend listening to Rush, you're likely to come away believing a lot of nonsense. The same problem applies to this book: it's largely fiction, and the line between fiction and reality is unclear.
I've been working on an XP team for a year, and I really like it, but it certainly has its disadvantages. I'm very impressed with the people I'm working with, and I'm really happy with our product. The process we use has almost nothing in common with the processes the book criticizes. Still, sometimes it has its drawbacks, and I think you should definitely be aware of them before you jump into XP. But this book is a good source for information on the drawbacks of doing things XP prohibits, not on the drawbacks of XP. See Questioning Extreme Programming for that. (Briefly, XP requires a small team, significant buy-in and resource commitments from the customer, easy deployment, testing support, and flexible underlying technology.) And, you know, myself, I'd be a lot happier with an ATC system developed with Cleanroom than with XP.
I think it's unfortunate that XP has become so fashionable, because now we have programming fashionistas embracing and pushing it, and any technique or technology they embrace gets badly abused. Just look at Java, XML, and C++!
See "deshredding", posted on kragen-tol on 1999-06-01. It describes the primary heuristic
mentioned in the article --- edge intersections and
textual redundancy, for example --- and some others
not presently in use, such as scanning both sides
of each scrap. It also anticipated the
likely achievable results --- blocks of text
rather than full documents.
However, it did not suggest using
the shapes of pieces of paper to piece them
together, because I was writing about shredded
documents, not torn ones. Also, the
countermeasures I suggested --- feeding paper to
the shredder accurately, using uniform fonts,
single-sided printing, whitespace between
paragraphs, and adding printed random text --- differ from the countermeasures
suggested in the article --- using large fonts
and feeding your paper into strip shredders
sideways.
Of course, what I published was a
direction for research, not a usable system of
algorithms. Still, it's nice to know I had good
foresight.
It puzzles me that so many people have posted comments describing
one or another common usability-related security problem that the
paper discusses, but without even mentioning the solutions the paper
offers.
Twitter says:
Best practices, such as unprivalidged [sic] user accounts, are just
as easy to implement as an email account that automaticaly [sic] executes
code sent by strangers.
On Microsoft Windows or Linux, any code you run executes with your
privileges by default. Running any code without, say, the privilege
to send further email requires great effort with, say, Subterfugue.
Twitter continues:
The problem of security in M$ [sic] apps is the distribution method -
closed source. This can not be fixed and so Windoze [sic] can not be made
secure.
Licensing Microsoft Windows freely would not solve its security
problems; many of them exist in Linux, too, just as the quote you
inserted explains in detail.
Beryllium Sphere says:
The article depends heavily on distinguishing data
("objects") from code ("actors").
The paper doesn't really depend on that distinction, at least not
in the way you think. One could call a process an actor, but an
executable file an object, for example.
The distinction between an "actor" and an "object" can only be clear
in a primitive system....
The blurring of the code/data distinction shows up in a lot of
recent exploits. ILoveYou.VBS is an actor that looks like an
object. That one was avoidable, but what about a GET or POST?
They're data which causes code to run on the web server. From
another point of view their content is a short web server program.
Sure, you can dream about analyzing and controlling the capabilities
of data-which-causes-actions. But if you ever let it achieve Turing
equivalence you can't even guarantee whether it halts.
Well, if you run it with a ulimit on cputime, you can guarantee
that it will halt in at most 10 CPU seconds.:) And if you
run it in a context where it has no filesystem access, you can
guarantee it won't delete any files; and if you run it in a context
where it has no network access, you can guarantee it won't send email.
Etc.
A non moose cow wrote:
look [sic] at how similar these are:
Visibility. The interface should allow the user to easily
review any active actors and authority relationships that would affect
security-relevant decisions.
Identifiability. The interface should enforce that
distinct objects and distinct actions have unspoofably identifiable
and distinguishable representations.
It would be very difficult to follow one of these without following
the other by default.
Visibility means you can see the things that matter;
identifiability means the things you can see don't look the same.
They seem quite orthogonal to me.
Someone asked, "What, you mean rm file.c should be the most secure
way to delete a file?" And Anonymous Coward responded:
If you are Bob Worker Bee, trying to discard that spreadsheet with
the CEO's salary in it, then yes, the default policy on your machine
should be secure (three-swipe, whatever) deletion. If you're Bob,
you don't know that rm has an option for 'secure' delete, and/or
that if you just rm, it's still recoverable, and so forth.
Superb example.
I urge everyone to read this paper, at least. Thinking about
security in the terms it suggests will change the landscape of
computer security, and it could lead to solutions to the most
persistent problems of both computer security and usability.
alternative digital logic technologies
on
Future Computers
·
· Score: 1
This PopSci article covers quantum computation, DNA computation, and
molecular electronic digital logic devices built of nanotubes, thiol,
and DNA.
I wrote an article on this same topic last month. It's almost exactly the same length as the PopSci article, but it covers a broader range of topics: all of the above (except for thiol), but also
inkjet-printed semiconductors, rod logic, buckling-spring
logic, optical computing, spherical integrated circuits, fluidics, and
Josephson junctions. It's also a little less confused than the PopSci article.
However, its style is not nearly as engaging, and I didn't interview any researchers for it, so it's limited by my own limited knowledge.
As can be seen from this story these tests involve several thousand transactions per second and not several hundred as reached by this Great Bridge sponsored benchmark.
Throughput claimed in the article was 440,880 transactions per minute, or 7348 transactions per second. This was on a cluster of 32 IBM Netfinities, so that's 230 transactions per second per Netfinity. Furthermore, according to another post in this thread, those were all four-processor machines --- presumably because otherwise processor speed would have been a bottleneck --- so we have 57 transactions per second per processor.
I'm not saying, of course, that database benchmark numbers scale linearly as you add CPUs. I'm only saying that the fact that IBM can get 7000 transactions per second out of DB2 on 32 servers costing $14 million does not demonstrate that you are a bonehead if you can only get 300 transactions per second out of Oracle on a single PIII-600 costing $20,000 or so.
I still suspect that the benchmarks were unfair, but they do show PostgreSQL is getting faster.
I taught the 'intermediate' level stuff - basicaly, one step up from LOGO, and one step down from Pascal (which was the advanced course.)
BASIC --- if you're talking about the standard BASIC with line numbers, no local variables, no subroutine parameters or return values, and, in fact, no official subroutines (as opposed to QBasic or something similar) --- is not one step up from LOGO. It's ten steps down from it.
Because calling subroutines is so ungodly awful, BASIC implementations invent new syntax for everything; beginners are fooled into believing that memorizing syntax is what programming is about. The kids who hate memorizing syntax get turned off by this; the kids who don't hate it miss the point that programming is about describing a task in detail, not learning how to use features of the libraries provided by your language vendor.
Scheme, Logo, Python, Tcl, and Smalltalk are at the other end of the spectrum. I think any of these is suitable for an introductory class in programming --- although admittedly I've never taught one.
As has been documented in recent books (notably When Wizards Stay Up Late), the original ARPANET was not designed to survive nuclear war.
However, packet-switching, as used in the original ARPANET and today's Internet, was invented by Paul Baran at the RAND corporation, and one of the rationales in his original paper was indeed survivability of nuclear wars.
(Unfortunately, I posted this previously as Anonymous Coward, due to a longstanding Slashdot bug I'd forgotten to work around.)
The Internet's routing protocols don't seem particularly hive-like to me, but I haven't been able to read the paper yet to see what the researchers mean --- it's apparently been slashdotted.
One of the points Philip makes in his page about how Bill got rich is that it had a great deal to do with who his parents were --- not that there aren't people with richer parents who are poorer today.
First: this is not the first time Sun has released open-source software. NFS, NIS, parts of XEmacs, parts of X, XView, olwm, and of course RPC and XDR are all open-source software released by Sun. All of these, except for the XEmacs parts, were released under a BSDish license.
Not that this isn't important --- all of the things mentioned above were at least ten years ago.
About Lothar's post about defense systems and banking systems being open-source: of course they should be open source. Would you really want to be defended by "defense" systems the would-be defenders didn't have the source to? Would you really want to run your bank with software you didn't have the source to?
RMS has never said that all software should be freely available --- just that people who have a piece of software have the right to use, copy, modify, and redistribute the software as they see fit.
Other minor points: the Mozilla license is OK according to OSI and Debian; the MPL doesn't let the original author use your code in proprietary software (but the NPL does); releasing public domain software doesn't automatically make you liable for damages; US-government-made software is in the public domain because government works are not eligible for copyright, not because the government can get away with it.
I'm really depressed with the quality of comments that get moderated up on Slashdot these days.
First, it's quite possible to embed your own malicious code into proprietary software without having access to the source code. happy99.exe inserted malicious code into WINSOCK.DLL to propagate itself, for example. You just have to be handy with a hex editor and understand the calling conventions of your platform.
Worse, it's extremely unlikely that anyone will detect the modification, except possibly through its effects. Detecting such a modification (without observing its effects) in a proprietary application is much, much more difficult than inserting it. (After all, you only have to insert it in one place; you have to look for it everywhere. Looking everywhere means you have to understand what the whole application should be doing. Without source code. Inserting it only requires that you understand what the application actually does do.)
Analogous attacks on free software are typically detected within hours or days.
Second, you can run Purify on applications you don't have the source code to, as long as Purify can find and redirect malloc() and free(). Purify doesn't find all buffer overflows, though; in particular, it doesn't find the most interesting kind, where you overflow a buffer into something you're not supposed to be able to overwrite.
Third, these attacks are not related to inserting "malicious/foreign" code into an operating system. They're related to breaking into a system, running some user code on it, and sending out packets from it.
EOSAT doesn't actually fly the satellite, IIRC; NASA does. EOSAT/Space Imaging just processes the data.
I don't know much about whether EOSAT's costs for L5 are lower than NASA/USGS's costs for L7. I do know that the benefits of L5 to society are much smaller; it's difficult to get hold of the data, and you can't modify and redistribute it. This is such an obstacle that Congress enacted a law to establish L7.
Those involved in the privatization seem to think of it as a mistake.
Well, the resolution of IKONOS is new, but space photographs of many places --- yes, including Area 51 --- have been available from many years.
Space Imaging --- previously EOSAT --- has handled Landsat imagery since the mid-1980s, when Landsat was "privatized" (read: "paid for with taxpayer money and then given away to wealthy aerospace firms.") They raised the Landsat prices to the point where Congress enacted a law (in 1992, I think) to pay for flying a new Landsat not under Space Imaging's control, and distribute the results in the public domain.
The Space Imaging Landsat CDs on my desk are marked "Trade Secret", with a notation that their use is governed by a license agreement.
Landsat has borne four sensors: the RBV or Return Beam Vidicon, with 80m resolution and which never got much use; the MSS or Multispectral Scanner, with four bands of 80m resolution; the TM or Thematic Mapper sensor, with 7 bands with 30m resolution; and the latest satellite, Landsat 7, whose data is available from the USGS's EROS Data Center for cost (presumably a few hundred dollars for a roughly 7000x7000 "scene", although I haven't been able to find it on their Web site yet) bears the ETM+ or Enhanced Thematic Mapper Plus sensor, which is roughly equivalent to the TM sensor, but with an extra "panchromatic" band with 18.9 meter resolution.
About the Landsat-7 data: it's public-domain once you get it, so you can do whatever you like. If someone sets up a web site with all L7 data available free to the public, the cost to the USGS per image provided will probably go up --- they'll be providing only one copy of each image. They might be unhappy about this.
About geosynchronous orbits: the Landsat 7 satellite flies at 705 km altitude. Geosynchronous, or geostationary, satellites are flown at 35,000 km, 50 times higher. (That's the way the math works out --- if you want to go around the Earth once every 24 hours, you need to fly that high.) If the Landsat 7 ETM+ sensor were flown in a geostationary orbit, its multispectral bands would provide 1500-meter resolution instead of 30-meter resolution. The GOES satellites that provide weather maps fly in geosynchronous orbits; they have 4-km resolution on most bands and 1-km resolution on one of them.
An additional difficulty is that half of the work --- one direction of scanning --- is taken care of by the Landsat's motion over the earth, giving us a simpler and more reliable satellite. (Landsat 5, still flying, is 15 years old.) So a geostationary surveillance satellite would need either a much bigger sensor array, or more mechanical parts to do a second direction of scanning.
In response to some of the more paranoid posts: given the difficulty of surveillance from a geostationary orbit and the coverage times from the unclassified satellites (Landsat-7 covers the whole earth every 16 days --- so it covers any given spot almost twice a month), it is highly unlikely that the NRO or any other agency is able to track you minute by minute, or probably even day by day, by satellite.
(I do not have access to any classified information on this topic.)
Space Imaging also handles one of the Indian Remote Sensing satellites, if I recall correctly.
Landsat data is good enough that you can distinguish different kinds of crops --- so those guys you know who grow their weed under fluorescents in their basements aren't just being paranoid.
Other satellites that provide similar information are the French SPOT satellites and the EOS satellites.
The hot new tech in this department is something called "imaging spectroscopy", or "hyperspectral imaging", which potentially provides much more detailed information by collecting hundreds of bands of information. (What brand of paint are you using on your car? What is this soil made of? Where in this minefield is the earth disturbed? etc.) I believe there is now one experimental hyperspectral sensor in orbit.
"Remote sensing" is the name for this whole field of study. I believe rst.gsfc.nasa.gov has a superb tutorial on the subject.
Just some responses to some things people have said in other comments:
SGI has more than one line of supercomputers. ASCI Blue Mountain is an SGI Origin2000 machine. I don't think we can expect to see Linux on Crays in the near future. (And didn't SGI just divest Cray again?)
It's true that Linux hasn't currently "mastered" 16-CPU SMPs. If Larry McVoy is to be believed, that's probably a good thing for the correctness and stability of the kernel.
CPlant is number 129 on the TOP500 list; it's the fastest Linux machine currently listed that runs Linux. It used to be below 100, but more new machines were added.
The 1000-node genetic-programming cluster mentioned recently on Slashdot, and distributed.net, are not on the list at all; to get on the TOP500 list, you need to run LINPACK fast. This (a) does not interest some people, and (b) is not well-suited to the structure of some clusters. A parallel machine that is very fast for some tasks may be very poor at others.
With regard to DES cracking: the EFF's DES cracker, which cost less than a quarter of a million dollars to build, cracks DES keys in a matter of days. Such a machine can scale linearly. The fact that distributed.net takes a month to crack a single DES key does not demonstrate that the NSA requires months to do the same.
Generally, "secure" DoD sites are not connected to the Internet, auditing or no.
"supercomputer" and "enterprise server" are very different categories. "enterprise server" means "mainframe killer" -- that is, reasonable CPU speed, fast I/O, but above all, reliability. Linux is definitely fit for supercomputing, and is being used for supercomputing all over the world. Linux is probably not quite yet fit for being an "enterprise server".
However, many supercomputers do indeed need lots of disk storage.
With regard to http://www.gapcon.org/listg.html: someone said, "You will notice there are no Linux installations in that list." Actually, they list a bunch of machines from Atipa Linux Solutions at LANL, the Avalon Beowulf at LANL, the Parnass2 Beowulf at the University of Bonn, the LoBoS Beowulf at the National Institutes of Health, the Centurion Beowulf at the University of Virginia, and possibly some others. They're a minority, but they're way cheap, and they're growing fast.
With regard to the GPL: if I hack something proprietary into Linux, I need to give source, licensed under the GPL, only to people whom I give binaries to. I am under no obligation to give source to anyone else. However, the person to whom I give it can put it up on their FTP site if they want.
The Linux reboot() system call takes some special magic parameters. The second one needs to be one of LINUX_REBOOT_MAGIC2, LINUX_REBOOT_MAGIC2A, or LINUX_REBOOT_MAGIC2B. These values are respectively 672274793, 85072278, and 369367448. So I think Linux's 30th birthday is in December. Consider it a little easter egg in the kernel source:)
The Navajo code talkers actually spoke in code as well as Navajo; a native Navajo speaker would have been able to understand the structure of their sentences, but not knowing the code, would not have easily been able to understand their meaning.
On tripwires
Tripwires have their disadvantages. You can't actually drop the cracker into a pit in a computer system. What you can do is try to make it harder for them to get in: drop packets from them, or answer them more slowly, etc. The trouble is, if the attacker can trick the tripwire, they can turn this into a denial-of-service attack.
On NP and P
You refer to the notorious difficulty of NP problems. But essentially all problems solved by computers are in NP; problems are in NP if a nondeterministic computer can solve them in polynomial time. Most of them are in the subclass of NP called 'P', which means they take polynomial time on a deterministic computer.
There's a class of problems called NP-complete problems. Any problem in NP can be reduced to any NP-complete problem in polynomial time (deterministically). Presently NP includes some problems that take exponential time as far as we know. If we found a polynomial-time deterministic algorithm to solve an NP-complete problem, then we could use it to solve all problems in NP in polynomial time.
Factoring numbers is not known to be NP-complete. It is known to be in NP, but it is possible that it is in P, even if NP != P. The Traveling Salesman Problem, on the other hand, is known to be NP-complete.
However, nobody has found a quicker-than-exponential-time method to factor numbers yet. RSA is "provably secure" in the sense that any method to break RSA in a reasonable time can also be used to factor numbers in a reasonable time. (Other public-key cryptosystems use discrete logarithms in finite groups, not factoring numbers.)
Your DNA computer point is ill-made. You still need O(k^N) pieces of DNA to solve TSP in linear time. This means that it is still trivial to construct instances of TSP that cannot be solved in reasonable time in reasonable amounts of space. (If k is 1.1, then N must be 48 to take 100 DNA units, 145 to take a million DNA units, 574 to take 6x10^23 DNA units, and so forth. It is trivial to construct an instance of TSP that requires more DNA than the Earth's mass to solve in linear time, using presently-known methods.
You say, "the repercussions when this piece of obscurity is cracked", referring to the secret of factoring numbers in polynomial time. But, as you point out earlier in the same paragraph, nobody knows whether this secret exists at all.
On human factors
Your point that no computer technology is proof against people giving away the farm is well-taken. Of course, if I accept CA certificates from whoever sends them to me, I will have security problems, regardless of the technological security measures I try to use. The same is true if I type arbitrary commands for anyone who calls me on the phone. "echo + + >.rhosts, OK, I did that; what next?"
On brute-force cryptanalysis
Your point about brute-force cryptanalysis is also missing the point. If I have a hundred-gigabyte hard disk, there are 10^11 or so places on the disk that the secret information can be hidden. That's equivalent to a 36.5-bit key. If I go all out and buy a DVD jukebox with 10 terabytes, that's still only 10^13 places to hide the secret bank-account number, equivalent to a 43.2-bit key.
On the other hand, if I encrypt my data with Twofish with a 256-bit key, there are 2^256 "places" my data could be "hidden". That's about 10^77 "places". 10^77 hydrogen atoms weigh about 10^54 grams. The mass of the sun is about 10^33 grams. So if you built a hard disk that stored one byte per hydrogen atom, you could obtain an equivalent degree of security by taking 1,000,000,000,000,000,000,000 stars the size of the sun for raw materials for your hard drive. (It turns out you'd need to use a significant part of the matter in the universe to build such a hard drive.)
So yes, your real error lies in having a hard drive of insufficient space. But 'insufficient space' simply doesn't begin to convey the magnitude of the difference. It's sort of like describing downtown Hiroshima in 1945 as unseasonably warm, although that simile falls short of conveying the degree of the understatement by several tens of orders of magnitude. It's like saying that the universe is a little bit bigger than a hydrogen atom.
There's another difference: the effort required to assemble several galaxies into a data storage device is roughly proportional to the size of the resulting data storage device. So is the effort of searching it. With encryption, on the other hand, using a key that is twice as long generally causes the encryption to take about twice as long, while squaring the difficulty of brute-force search. So I can use my Apple//e to encrypt something with a 128-bit key, and all the computers in the world working for billions of years won't be able to recover it.
Re:How does the GPL infect a code tree?
on
BSD vs GPL
·
· Score: 1
You write:
As an example, consider GPL'd libraries. Linking your proprietary program with one is certainly considered fair usage, and legally the GPL would fail in this instance.
I don't know that a claim that linking to a library was "fair use" of that library has ever been tested in court. However, the use of entire works for copyright purposes -- particularly when such works are not fictional -- is almost never considered to be "fair use".
If it were fair use, I could ship the majority of almost any Microsoft product as part of my software (by using it as a library -- most of them are libraries already) and pay no licensing fees.
Of course, perhaps you simply mean running a program linked against a library -- not distributing binaries linked against that library. In this case, the GPL places no restrictions on what you may do; you can use GPLed software however you want. (And in this case you might have a defense under copyright law, too.)
The biggest problem with the GPL is that it places restrictions that it doesn't have the legal grounds under copyright law to do. . . .
The lawyers who have reviewed the GPL don't think so.:)
Slashdot Mirror
Thanks, I'm glad you liked it!
The relevant difference among these statements is that Reiser might, in fact, have murdered his wife in cold blood. I was going to say that the jury is still out, but of course that's not just a figure of speech in this case; according to Wikipedia, they will be convened in May.
The rest of the post was sort of funny, but that part was unjustifiable. Let the law do its work.
He didn't invent the idea, but he wrote a well-known "Open Letter to Hobbyists" that attempted to justify the idea to a population of hackers who thought it was stupid.
It varies a lot from university to university. Generally grad students in the sciences, and also in computer science, work as employees of the university, which is where the university gets the leverage to possibly expropriate their intellectual work and turn it into intellectual property. Some years ago I bought a book entitled, "Who owns intellectual work?" about this issue, but I never got around to reading it.
Yeah, and I've had you on my IM buddy list forever --- not sure since when. So my messges don't count :)
I have posted my answer to kragen-tol; the message is The equivalent of free software for online services.
I have been thinking about this for a long time, but I really like the way Jamie has focused the question here. I will write an essay in answer to the question --- "What's the equivalent of free software for web services?" --- and post it to kragen-tol as soon as I can.
Some examples of fiction from the chapter on the Web. Done in a hurry, I have to get back to work.
p.3 (135): when I'm coding something I don't understand, I stop and spike it out or read about it, alone, not with a pair, rather than trying to code it with a pair. My pair does not hold my hand, ever, nor hug me. Our high-level requirements are written, in English, on note cards, not in C++ or any other programming language; but it's true that our low-level requirements are in our unit tests. And when I'm writing unit tests, it's not in order to find bugs; it's in order to formalize the specification of a small part of the system and check it against its specification. Occasionally they do find bugs when I'm writing them, but that's because I've decided that some piece of code I need to refactor is insufficiently tested. On those occasions, I feel great, because I have just found (and am about to fix) a bug before it hit anybody in production.
The entanglement of fact and fiction is dangerous here. Obviously it's fictitious that your pair will hold your hand or hug you, at least in most workplaces, but the subtler fictions about the role of unit tests and requirements specs in the XP development process would be easy to mistake for assertions of fact; and they're mixed in with truths and half-truths, like the fact that some of our requirements are in unit tests, and we enjoy our work a great deal.
And spiking and story cards are not peripheral, minor aspects of XP; they've been part of the process since C3, they're extensively discussed on the Wiki and in Kent's very first XP book, and there's really no excuse for this level of ignorance about them --- except carelessness about the truth.
p.4 (136): our room sometimes got stinky or noisy, so we solved the problem. We have little orange signs we hold up when the room starts to get noisy, and we ask our pair to brush their teeth or take a shower when they start to smell bad. (This rarely happens, though.) Clearly we were doing XP when we had those problems, and we still are, so I can't claim they're never problems with XP. But XP gives you the tools to solve them: courage, experimentation, and a practice of rearranging your workplace for maximal productivity.
p.5 (137): XP doesn't mandate a switching interval, and many XP teams use intervals greater than a couple of hours. We switch once or twice a day. Pairing doesn't require two programmers to do the work one programmer was previously doing; typically, they do more and better work, and simultaneously talk about the code and the environment. (So what the book claims is "obvious" about pairing is not only not obvious, it isn't even true.) In non-pair environments, teams typically spend a fair bit of time discussing the code in order to get a relatively poor collective understanding of it; in XP, that's built into the pairing process. The book mentions how pairing compensates for the lack of up-front design and design documentation, but not how it improves your communication about other issues --- issues that never get written down in most development teams of any kind.
p. 6 (138) is clearly marked as fiction in its entirety --- it consists of one person's speculation about the potential difficulties of pairing with one other person or working in an open workspace, followed by a satirical song about pairing. The satirical song asserts that XP programmers would rather go home than switch pairs at the beginning of a new day (clearly absurd, the flip side of the apparently-serious "switch every two hours" strawman a couple of pages ago), and that they are unable to write code or watch unit tests run alone. In reality --- at least, on my XP team, in common XP practice, and in the XP literature --- we switch pairs at least once a day anyway, and we write spike code and run unit tests singleton (alone), except when we think we need to discuss something with someone. I guess you could still be "doing XP" if you always spiked and ran unit tests in pairs, but you wou
Ron Jeffries wrote a good review of this book last month; his review avoids most of the flaws the comments here find in this review.
I've only read one chapter, the one up on the web, but it's quite silly. The author repeatedly describes how one team or another did some dumb stuff and it didn't work; many of these anecdotes are parodic fiction, and obviously so, but some of them are presumably real. Then he explains that that dumb stuff didn't work. The trouble is that a reader with no XP experience might be fooled into thinking that XP advocates doing that dumb stuff.
The trouble with liberals listening to Rush Limbaugh, as one poster suggested, is that Rush makes up a lot of lies and passes them off as truth. (See Al Franken's earlier book for details.) If you don't spend ten minutes investigating facts for every minute you spend listening to Rush, you're likely to come away believing a lot of nonsense. The same problem applies to this book: it's largely fiction, and the line between fiction and reality is unclear.
I've been working on an XP team for a year, and I really like it, but it certainly has its disadvantages. I'm very impressed with the people I'm working with, and I'm really happy with our product. The process we use has almost nothing in common with the processes the book criticizes. Still, sometimes it has its drawbacks, and I think you should definitely be aware of them before you jump into XP. But this book is a good source for information on the drawbacks of doing things XP prohibits, not on the drawbacks of XP. See Questioning Extreme Programming for that. (Briefly, XP requires a small team, significant buy-in and resource commitments from the customer, easy deployment, testing support, and flexible underlying technology.) And, you know, myself, I'd be a lot happier with an ATC system developed with Cleanroom than with XP.
I think it's unfortunate that XP has become so fashionable, because now we have programming fashionistas embracing and pushing it, and any technique or technology they embrace gets badly abused. Just look at Java, XML, and C++!
See "deshredding", posted on kragen-tol on 1999-06-01. It describes the primary heuristic mentioned in the article --- edge intersections and textual redundancy, for example --- and some others not presently in use, such as scanning both sides of each scrap. It also anticipated the likely achievable results --- blocks of text rather than full documents.
However, it did not suggest using the shapes of pieces of paper to piece them together, because I was writing about shredded documents, not torn ones. Also, the countermeasures I suggested --- feeding paper to the shredder accurately, using uniform fonts, single-sided printing, whitespace between paragraphs, and adding printed random text --- differ from the countermeasures suggested in the article --- using large fonts and feeding your paper into strip shredders sideways.
Of course, what I published was a direction for research, not a usable system of algorithms. Still, it's nice to know I had good foresight.
It puzzles me that so many people have posted comments describing one or another common usability-related security problem that the paper discusses, but without even mentioning the solutions the paper offers.
Twitter says:
On Microsoft Windows or Linux, any code you run executes with your privileges by default. Running any code without, say, the privilege to send further email requires great effort with, say, Subterfugue.
Twitter continues:
Licensing Microsoft Windows freely would not solve its security problems; many of them exist in Linux, too, just as the quote you inserted explains in detail.
Beryllium Sphere says:
The paper doesn't really depend on that distinction, at least not in the way you think. One could call a process an actor, but an executable file an object, for example.
Well, if you run it with a ulimit on cputime, you can guarantee that it will halt in at most 10 CPU seconds. :) And if you
run it in a context where it has no filesystem access, you can
guarantee it won't delete any files; and if you run it in a context
where it has no network access, you can guarantee it won't send email.
Etc.
A non moose cow wrote:
Visibility means you can see the things that matter; identifiability means the things you can see don't look the same. They seem quite orthogonal to me.
Someone asked, "What, you mean rm file.c should be the most secure way to delete a file?" And Anonymous Coward responded:
Superb example.
I urge everyone to read this paper, at least. Thinking about security in the terms it suggests will change the landscape of computer security, and it could lead to solutions to the most persistent problems of both computer security and usability.
This PopSci article covers quantum computation, DNA computation, and molecular electronic digital logic devices built of nanotubes, thiol, and DNA.
I wrote an article on this same topic last month. It's almost exactly the same length as the PopSci article, but it covers a broader range of topics: all of the above (except for thiol), but also inkjet-printed semiconductors, rod logic, buckling-spring logic, optical computing, spherical integrated circuits, fluidics, and Josephson junctions. It's also a little less confused than the PopSci article.
However, its style is not nearly as engaging, and I didn't interview any researchers for it, so it's limited by my own limited knowledge.
I hope you find it interesting.
Throughput claimed in the article was 440,880 transactions per minute, or 7348 transactions per second. This was on a cluster of 32 IBM Netfinities, so that's 230 transactions per second per Netfinity. Furthermore, according to another post in this thread, those were all four-processor machines --- presumably because otherwise processor speed would have been a bottleneck --- so we have 57 transactions per second per processor.
I'm not saying, of course, that database benchmark numbers scale linearly as you add CPUs. I'm only saying that the fact that IBM can get 7000 transactions per second out of DB2 on 32 servers costing $14 million does not demonstrate that you are a bonehead if you can only get 300 transactions per second out of Oracle on a single PIII-600 costing $20,000 or so.
I still suspect that the benchmarks were unfair, but they do show PostgreSQL is getting faster.
Because calling subroutines is so ungodly awful, BASIC implementations invent new syntax for everything; beginners are fooled into believing that memorizing syntax is what programming is about. The kids who hate memorizing syntax get turned off by this; the kids who don't hate it miss the point that programming is about describing a task in detail, not learning how to use features of the libraries provided by your language vendor.
Scheme, Logo, Python, Tcl, and Smalltalk are at the other end of the spectrum. I think any of these is suitable for an introductory class in programming --- although admittedly I've never taught one.
However, packet-switching, as used in the original ARPANET and today's Internet, was invented by Paul Baran at the RAND corporation, and one of the rationales in his original paper was indeed survivability of nuclear wars.
(Unfortunately, I posted this previously as Anonymous Coward, due to a longstanding Slashdot bug I'd forgotten to work around.)
The Internet's routing protocols don't seem particularly hive-like to me, but I haven't been able to read the paper yet to see what the researchers mean --- it's apparently been slashdotted.
One of the points Philip makes in his page about how Bill got rich is that it had a great deal to do with who his parents were --- not that there aren't people with richer parents who are poorer today.
First: this is not the first time Sun has released open-source software. NFS, NIS, parts of XEmacs, parts of X, XView, olwm, and of course RPC and XDR are all open-source software released by Sun. All of these, except for the XEmacs parts, were released under a BSDish license.
Not that this isn't important --- all of the things mentioned above were at least ten years ago.
About Lothar's post about defense systems and banking systems being open-source: of course they should be open source. Would you really want to be defended by "defense" systems the would-be defenders didn't have the source to? Would you really want to run your bank with software you didn't have the source to?
RMS has never said that all software should be freely available --- just that people who have a piece of software have the right to use, copy, modify, and redistribute the software as they see fit.
Other minor points: the Mozilla license is OK according to OSI and Debian; the MPL doesn't let the original author use your code in proprietary software (but the NPL does); releasing public domain software doesn't automatically make you liable for damages; US-government-made software is in the public domain because government works are not eligible for copyright, not because the government can get away with it.
I'm really depressed with the quality of comments that get moderated up on Slashdot these days.
First, it's quite possible to embed your own malicious code into proprietary software without having access to the source code. happy99.exe inserted malicious code into WINSOCK.DLL to propagate itself, for example. You just have to be handy with a hex editor and understand the calling conventions of your platform.
Worse, it's extremely unlikely that anyone will detect the modification, except possibly through its effects. Detecting such a modification (without observing its effects) in a proprietary application is much, much more difficult than inserting it. (After all, you only have to insert it in one place; you have to look for it everywhere. Looking everywhere means you have to understand what the whole application should be doing. Without source code. Inserting it only requires that you understand what the application actually does do.)
Analogous attacks on free software are typically detected within hours or days.
Second, you can run Purify on applications you don't have the source code to, as long as Purify can find and redirect malloc() and free(). Purify doesn't find all buffer overflows, though; in particular, it doesn't find the most interesting kind, where you overflow a buffer into something you're not supposed to be able to overwrite.
Third, these attacks are not related to inserting "malicious/foreign" code into an operating system. They're related to breaking into a system, running some user code on it, and sending out packets from it.
EOSAT doesn't actually fly the satellite, IIRC; NASA does. EOSAT/Space Imaging just processes the data.
I don't know much about whether EOSAT's costs for L5 are lower than NASA/USGS's costs for L7. I do know that the benefits of L5 to society are much smaller; it's difficult to get hold of the data, and you can't modify and redistribute it. This is such an obstacle that Congress enacted a law to establish L7.
Those involved in the privatization seem to think of it as a mistake.
Well, the resolution of IKONOS is new, but space photographs of many places --- yes, including Area 51 --- have been available from many years.
Space Imaging --- previously EOSAT --- has handled Landsat imagery since the mid-1980s, when Landsat was "privatized" (read: "paid for with taxpayer money and then given away to wealthy aerospace firms.") They raised the Landsat prices to the point where Congress enacted a law (in 1992, I think) to pay for flying a new Landsat not under Space Imaging's control, and distribute the results in the public domain.
The Space Imaging Landsat CDs on my desk are marked "Trade Secret", with a notation that their use is governed by a license agreement.
Landsat has borne four sensors: the RBV or Return Beam Vidicon, with 80m resolution and which never got much use; the MSS or Multispectral Scanner, with four bands of 80m resolution; the TM or Thematic Mapper sensor, with 7 bands with 30m resolution; and the latest satellite, Landsat 7, whose data is available from the USGS's EROS Data Center for cost (presumably a few hundred dollars for a roughly 7000x7000 "scene", although I haven't been able to find it on their Web site yet) bears the ETM+ or Enhanced Thematic Mapper Plus sensor, which is roughly equivalent to the TM sensor, but with an extra "panchromatic" band with 18.9 meter resolution.
About the Landsat-7 data: it's public-domain once you get it, so you can do whatever you like. If someone sets up a web site with all L7 data available free to the public, the cost to the USGS per image provided will probably go up --- they'll be providing only one copy of each image. They might be unhappy about this.
About geosynchronous orbits: the Landsat 7 satellite flies at 705 km altitude. Geosynchronous, or geostationary, satellites are flown at 35,000 km, 50 times higher. (That's the way the math works out --- if you want to go around the Earth once every 24 hours, you need to fly that high.) If the Landsat 7 ETM+ sensor were flown in a geostationary orbit, its multispectral bands would provide 1500-meter resolution instead of 30-meter resolution. The GOES satellites that provide weather maps fly in geosynchronous orbits; they have 4-km resolution on most bands and 1-km resolution on one of them.
An additional difficulty is that half of the work --- one direction of scanning --- is taken care of by the Landsat's motion over the earth, giving us a simpler and more reliable satellite. (Landsat 5, still flying, is 15 years old.) So a geostationary surveillance satellite would need either a much bigger sensor array, or more mechanical parts to do a second direction of scanning.
In response to some of the more paranoid posts: given the difficulty of surveillance from a geostationary orbit and the coverage times from the unclassified satellites (Landsat-7 covers the whole earth every 16 days --- so it covers any given spot almost twice a month), it is highly unlikely that the NRO or any other agency is able to track you minute by minute, or probably even day by day, by satellite.
(I do not have access to any classified information on this topic.)
Space Imaging also handles one of the Indian Remote Sensing satellites, if I recall correctly.
Landsat data is good enough that you can distinguish different kinds of crops --- so those guys you know who grow their weed under fluorescents in their basements aren't just being paranoid.
Other satellites that provide similar information are the French SPOT satellites and the EOS satellites.
The hot new tech in this department is something called "imaging spectroscopy", or "hyperspectral imaging", which potentially provides much more detailed information by collecting hundreds of bands of information. (What brand of paint are you using on your car? What is this soil made of? Where in this minefield is the earth disturbed? etc.) I believe there is now one experimental hyperspectral sensor in orbit.
"Remote sensing" is the name for this whole field of study. I believe rst.gsfc.nasa.gov has a superb tutorial on the subject.
SGI has more than one line of supercomputers. ASCI Blue Mountain is an SGI Origin2000 machine. I don't think we can expect to see Linux on Crays in the near future. (And didn't SGI just divest Cray again?)
It's true that Linux hasn't currently "mastered" 16-CPU SMPs. If Larry McVoy is to be believed, that's probably a good thing for the correctness and stability of the kernel.
CPlant is number 129 on the TOP500 list; it's the fastest Linux machine currently listed that runs Linux. It used to be below 100, but more new machines were added.
The 1000-node genetic-programming cluster mentioned recently on Slashdot, and distributed.net, are not on the list at all; to get on the TOP500 list, you need to run LINPACK fast. This (a) does not interest some people, and (b) is not well-suited to the structure of some clusters. A parallel machine that is very fast for some tasks may be very poor at others.
With regard to DES cracking: the EFF's DES cracker, which cost less than a quarter of a million dollars to build, cracks DES keys in a matter of days. Such a machine can scale linearly. The fact that distributed.net takes a month to crack a single DES key does not demonstrate that the NSA requires months to do the same.
Generally, "secure" DoD sites are not connected to the Internet, auditing or no.
"supercomputer" and "enterprise server" are very different categories. "enterprise server" means "mainframe killer" -- that is, reasonable CPU speed, fast I/O, but above all, reliability. Linux is definitely fit for supercomputing, and is being used for supercomputing all over the world. Linux is probably not quite yet fit for being an "enterprise server".
However, many supercomputers do indeed need lots of disk storage.
With regard to http://www.gapcon.org/listg.html: someone said, "You will notice there are no Linux installations in that list." Actually, they list a bunch of machines from Atipa Linux Solutions at LANL, the Avalon Beowulf at LANL, the Parnass2 Beowulf at the University of Bonn, the LoBoS Beowulf at the National Institutes of Health, the Centurion Beowulf at the University of Virginia, and possibly some others. They're a minority, but they're way cheap, and they're growing fast.
With regard to the GPL: if I hack something proprietary into Linux, I need to give source, licensed under the GPL, only to people whom I give binaries to. I am under no obligation to give source to anyone else. However, the person to whom I give it can put it up on their FTP site if they want.
Kragen Sitaker, current Beowulf FAQ maintainer
The Linux reboot() system call takes some special magic parameters. The second one needs to be one of LINUX_REBOOT_MAGIC2, LINUX_REBOOT_MAGIC2A, or LINUX_REBOOT_MAGIC2B. These values are respectively 672274793, 85072278, and 369367448. So I think Linux's 30th birthday is in December. Consider it a little easter egg in the kernel source :)
On code talkers
The Navajo code talkers actually spoke in code as well as Navajo; a native Navajo speaker would have been able to understand the structure of their sentences, but not knowing the code, would not have easily been able to understand their meaning.
On tripwires
Tripwires have their disadvantages. You can't actually drop the cracker into a pit in a computer system. What you can do is try to make it harder for them to get in: drop packets from them, or answer them more slowly, etc. The trouble is, if the attacker can trick the tripwire, they can turn this into a denial-of-service attack.
On NP and P
You refer to the notorious difficulty of NP problems. But essentially all problems solved by computers are in NP; problems are in NP if a nondeterministic computer can solve them in polynomial time. Most of them are in the subclass of NP called 'P', which means they take polynomial time on a deterministic computer.
There's a class of problems called NP-complete problems. Any problem in NP can be reduced to any NP-complete problem in polynomial time (deterministically). Presently NP includes some problems that take exponential time as far as we know. If we found a polynomial-time deterministic algorithm to solve an NP-complete problem, then we could use it to solve all problems in NP in polynomial time.
Factoring numbers is not known to be NP-complete. It is known to be in NP, but it is possible that it is in P, even if NP != P. The Traveling Salesman Problem, on the other hand, is known to be NP-complete.
However, nobody has found a quicker-than-exponential-time method to factor numbers yet. RSA is "provably secure" in the sense that any method to break RSA in a reasonable time can also be used to factor numbers in a reasonable time. (Other public-key cryptosystems use discrete logarithms in finite groups, not factoring numbers.)
Your DNA computer point is ill-made. You still need O(k^N) pieces of DNA to solve TSP in linear time. This means that it is still trivial to construct instances of TSP that cannot be solved in reasonable time in reasonable amounts of space. (If k is 1.1, then N must be 48 to take 100 DNA units, 145 to take a million DNA units, 574 to take 6x10^23 DNA units, and so forth. It is trivial to construct an instance of TSP that requires more DNA than the Earth's mass to solve in linear time, using presently-known methods.
You say, "the repercussions when this piece of obscurity is cracked", referring to the secret of factoring numbers in polynomial time. But, as you point out earlier in the same paragraph, nobody knows whether this secret exists at all.
On human factors
Your point that no computer technology is proof against people giving away the farm is well-taken. Of course, if I accept CA certificates from whoever sends them to me, I will have security problems, regardless of the technological security measures I try to use. The same is true if I type arbitrary commands for anyone who calls me on the phone. "echo + + > .rhosts, OK, I did that; what next?"
On brute-force cryptanalysis
Your point about brute-force cryptanalysis is also missing the point. If I have a hundred-gigabyte hard disk, there are 10^11 or so places on the disk that the secret information can be hidden. That's equivalent to a 36.5-bit key. If I go all out and buy a DVD jukebox with 10 terabytes, that's still only 10^13 places to hide the secret bank-account number, equivalent to a 43.2-bit key.
On the other hand, if I encrypt my data with Twofish with a 256-bit key, there are 2^256 "places" my data could be "hidden". That's about 10^77 "places". 10^77 hydrogen atoms weigh about 10^54 grams. The mass of the sun is about 10^33 grams. So if you built a hard disk that stored one byte per hydrogen atom, you could obtain an equivalent degree of security by taking 1,000,000,000,000,000,000,000 stars the size of the sun for raw materials for your hard drive. (It turns out you'd need to use a significant part of the matter in the universe to build such a hard drive.)
So yes, your real error lies in having a hard drive of insufficient space. But 'insufficient space' simply doesn't begin to convey the magnitude of the difference. It's sort of like describing downtown Hiroshima in 1945 as unseasonably warm, although that simile falls short of conveying the degree of the understatement by several tens of orders of magnitude. It's like saying that the universe is a little bit bigger than a hydrogen atom.
There's another difference: the effort required to assemble several galaxies into a data storage device is roughly proportional to the size of the resulting data storage device. So is the effort of searching it. With encryption, on the other hand, using a key that is twice as long generally causes the encryption to take about twice as long, while squaring the difficulty of brute-force search. So I can use my Apple //e to encrypt something with a 128-bit key, and all the computers in the world working for billions of years won't be able to recover it.
kragen@pobox.com (mailing lists)
Kragen
As an example, consider GPL'd libraries. Linking your proprietary program with one is certainly considered fair usage, and legally the GPL would fail in this instance.
I don't know that a claim that linking to a library was "fair use" of that library has ever been tested in court. However, the use of entire works for copyright purposes -- particularly when such works are not fictional -- is almost never considered to be "fair use".
If it were fair use, I could ship the majority of almost any Microsoft product as part of my software (by using it as a library -- most of them are libraries already) and pay no licensing fees.
Of course, perhaps you simply mean running a program linked against a library -- not distributing binaries linked against that library. In this case, the GPL places no restrictions on what you may do; you can use GPLed software however you want. (And in this case you might have a defense under copyright law, too.)
The biggest problem with the GPL is that it places restrictions that it doesn't have the legal grounds under copyright law to do. . . .
The lawyers who have reviewed the GPL don't think so. :)