What do I, as a lowly network application programmer do if I want to write portable code that migrates smoothly to ipv6?
Last I checked, getaddrinfo was not widely available under most Linux distros. Apparently, there is no api standard for sockets, ipv6 or no (the ipv4 api is more or less a de facto standard, although there are still gaps, such as a threadsafe version of gethostbyname).
Stevens talks about XTI, but as far as I can tell it's yet another example of Open Group navel gazing. Is it even available under Linux?
Unless I'm wrong, they haven't made it easy to do the Right Thing. Ah well, I guess the right thing to do is complain to a local representative of ITC (the International They Consortium).
"boys and girls" appears 17 times
on
One for the Kids
·
· Score: 2
17 times by my count. A bit excessive. But then, CWD has never been known for its august writing style.
Over the years, CWD, in spite of its kick-your-ass, heavy-boozing style, has scooped the more mainstream media on some important issues. Remember when Brock found a student to reverse-engineer the block list of some crummy censorware, and (surprise surprise!) found sites blocked for pretty obviously political reasons?
I look forward to CWD being on slashdot. It deserves the wider readership it's going to get.
What many people don't realize is that domain name registrar competition is largely illusory. NSI still holds a monopoly for the database holding the com, org, and net top level domains. All the other registrars still pay NSI $9/year per domain for access to this database.
Thus, the only real competition is in billing and customer service. Given NSI's track record on these matters, the "alternative" registrars have a wide-open opportunity to do better, and I think this is a good thing. But the fact that NSI retains the monopoly on the database itself suggests that we're not going to see fundamental improvements any time soon.
The expected benefit of this new license is almost exactly the same as my licensing plan for libart. I'm just doing it using existing licenses.
Specifically, I'm releasing the code under GPL, but I'm also holding onto the copyright so I can license it to proprietary customers. I ask people to assign copyright over to me if they want their work to go in my relase. This creates a nice balance of powers, and gives me incentive to be a "nice guy." If I stop doing my job of maintaining libart well, then anyone who wants to is perfectly free to continue development under the GPL. Similarly, people are also free to fork if they feel that what I'm doing is unfair. It's in my interest to avoid a fork, so I better play nice.
Actually, while libart as a whole is released under GPL, large chunks (basically, everything used by gnome-libs, including gnome-print and the Gnome Canvas) are released under LGPL, to make it even more friendly towards people with alternate licensing arrangements. This may increase the fraction of proprietary users who can just use it for free and not pay me any license, but that's ok. It still gets libart out there and used, which is no doubt good for business.
This model is pretty simliar to what Sleepycat is doing for their Berkeley DB code. The main difference is that they have YAOSL, which imho is not quite as friendly as using the existing LGPL and GPL licenses. In particular, they had to grant Gnome a special one-off license to use DB safely in the Gnome libraries, which is obviously not needed for LGPL stuff.
I'm not advocating this model for everybody, but I'm expecting it to work well for libart. I think everyone benefits: I get funded, which means that I can eat and afford to put a lot of work into making libart great, and the free software community gets a well-polished graphics library without encumberance.
Isn't this supposed to be an important aspect of the programming art, to make best use of existing tools rather than trying to create a new set of tools for every possible use? In any case, I cringe every time I see yet another goddamn open source license.
I agree. While Microsoft currently has the most to lose from Linux world domination, they neither invented it nor will it go to the grave with them.
The Jargon file is clear enough on the predating. The term was coined by Gene Amdahl in reference to IBM. Now IBM is a major Linux citizen. Ironic, huh?
And regarting point two, why not just say "the combined market share of free software OS's going over 50%"? Linux rocks, and I agree there are no signs on the near horizon for its dominance to be threatened.
However, over a longer term, I don't see why three or four free operating systems occupying distinct ecological niches. Linus has already suggested that it may be technically wise to have separate codebases (with much sharing, presumably) for tiny embedded linux and for the massive 64+ multiprocessor systems.
Yeah, it was an interesting read, but I don't think it contains any deep revelations.
Structurally, the piece is a mess. This would seem to be a bad sign when the subject is one as exacting as programming! I realize that it was written mostly as the outline of a course, but still.
The main thesis appears to be that the most important attribute of people's cognitive styles is the one-bit mapper/packer distinction. As far as I could tell, "mapper" is pretty much the same old "think outside the box" philosophy, while packers are a strawman for inside the box thinking. Ok good, now I understand the world a whole lot better.
The piece did have some interesting moments. I liked the section on the quality plateau. There is a clear moral I get from the story:
An ounce of simplicity is better than a pound of abstraction.
A lot of the piece seems to be railing against traditional "software engineering" practices. Probably a lot of/. readers do work in corporate coding environments where these practices hold sway, but I'd guess we don't need much convincing. Linux and other successful free software projects prove convincingly that traditional "software engineering" principles are not necessary to make high quality code.
The concepts of programming, especially those specific to larger projects with many people, are very difficult to master. A lot of writers on the subject delight with with oversimplified metaphors that are actually fairly easy to understand. In the best case, these metaphors actually capture an interesting aspect of programming. I'm not sure that this piece really achieves that goal.
"A FURTHER POTENTIAL RISK FACTOR THAT MAY IMPAIR THE PROGRESS OF THE COMPANY IS ITS DEPENDENCE ON THE LINUX COMMUNITY TO WRITE THE CODE THAT WE WILL SHIP. WHILE THE LINUX COMMUNITY HAS AN UNPARALLELED TRACK RECORD IN DEVELOPING HIGH QUALITY CODE, THEIR SMUG KNOW-IT-ALL ATTITUDE MAY DETRACT FROM THEIR SUPPORT OF THE COMPANY'S GOALS. IN ADDITION, THE FACT THAT THEY ARE A BUNCH OF PIMPLY FACED TEENAGERS MAY POSE A FURTHER RISK TO THE COMPANY."
Hopefully, it's not too late to amend the filing.
Agreed - the W3C is not the IETF
on
Weaving The Web
·
· Score: 2
While I tend to agree regarding the privacy issues, I've also have some unpleasant experiences with the W3C over strictly technical issues. If you search the W3C mailing list archives for the DOM and SVG working groups, you'll see some of this discussion.
The fundamental problem is that, unlike the IETF, the W3C process is closed. Really closed. Members of a working group are obligated to keep the discussions of the working group confidential. There are open mailing lists for public comment, but trying to actually raise technical issues and see them addressed is like pulling teeth.
I know the W3C tries pretty hard, and it seems kind of unfair to pick on them, because they're far less avaricious than the typical make-10^9-buck-quickly Internet scheme, but their process is just not good. You see this reflected in their specs, which are often more complex than necessary, contain technical flaws, and have too much concession to industry demands.
I really liked the reviews on your page. I will be picking up a few recommended books.
If you ask me, Children of the Mind is easily the worst (or least good) book out of the Ender canon. It's well crafted, of course, but contained little of the magic of the first two.
Basically, CSS takes away the guarantee of consistent rendering (one of TeX's more amazing features). Thus, if you fiddle with the style sheets to get the document looking exactly the way you want it, your columns all aligned, figures moved to really nice logical places, etc., then as soon as you bring the document to another machine, it totally reformats your document. You're back to a rendering which is ok (it does correspond to the style markup), but certainly not excellent.
TeX, on the other hand, implements consistent rendering. It accomplishes this basically through mind-bogglingly careful craftsmanship. As anyone who's been through the TeX sources knows, it makes no use of floating point. Rather, all computation (including trigonometry and other complex formulae) is done with hand-coded fixed point math. That way, Knuth guarantees that the document will be pixel-for-pixel on any TeX implementation.
Ironically, TeX is in this way much more WYSIWYG than, say, an HTML editor. What you see (in the xdvi preview or whatever) is exactly what you get when you transport the document to other machines. In an HTML editor, yes you get to see that your font kinda resembles Times, and you get to see the colors, but every browser is going to render the page slightly differently. In my opinion, calling this "WYSIWYG" is stretching the original meaning of the acronym somewhat.
I think the holy grail is a good interactive editor, with the typographic sophistication of TeX, a nice stylesheet mechanism, and the consistent rendering property. Having the editing interactive means that you have much shorter cycles towards getting the document to look like what you wanted.
I personally am working toward this goal with the Gnome-Text subsystem in Gnome. I have a good head start because I am using ideas, algorithms, and file formats from TeX. Consequently, there's code in Gnome CVS (under the libhnj module) that can read TeX hyphenation data, then typeset using TeX-like whole paragraph optimization. My current implementation is about 12 milliseconds per page on a 400MHz Celeron. This is fast enough for interactive display.
So if you really care, you can help me with the coding. Of course, this is/., so I'm not expecting too much:)
I'm glad to see this interview posted on Slashdot. Knuth is certainly one of the great pioneers of the free software movement, among many other accomplishments. In the "Digital Typography" book, his description of why he didn't want Xerox PARC to own the copyright on the fonts he was creating ranks up there with any modern-day philosophizing on the benefits of free software.
Unlike the people who get a lot of publicity for being free software or Open Source gurus, Knuth hasn't sought a lot of publicity for his contributions. But they are there for all of us to benefit from.
Much of my work on the printing subsystem of Gnome consists of adapting the beautiful work that Knuth and his students did with TeX and Metafont. The more I study the original sources for this work, the more impressed I am by their depth overall "rightness." I do believe that it is time to adapt the best parts of the work to a more modern environment with interactive editing and so on, but this in no way detracts from the magnitude of the original work. And, because it's free software, I can!
So, thank you, Don Knuth, for being a pioneer both in computer science and in free software.
I'll see if I can fill in some info on the color matching issue.
There are basically two types of color matching that are relevant. The first is Pantone spot colors, and the second is ICC. The latter is generally what you'd use when preparing photos and related images for CMYK offset printing. ICC is gaining ground, and is used as the color matching standard in such emerging technologies as SVG.
Pantone is basically a named collection of colors. The cool thing about Pantone is that you can communicate Pantone colors to professional printers, and they know how to match it. Let's say for example that you're doing a business card, and you want your logo to be in black and a nice deep blue. By specifying Pantone 280, you can be assured that the printers will produce the same nice deep blue that you intended. Incidentally, it's not hard to find a Pantone palette for Gimp if you're skilled at Web searching.
Pantone colors are far less useful when dealing with natural images. The Pantone palette is only a few thousand colors, while the standard for scanned images is sixteen million. These are all the colors between "nice deep blue" and "slightly deeper blue than that". That's where ICC comes in.
ICC basically specifies a transformation from a source color space (say, a calibrated RGB such as sRGB) to a destination color space (say, CMYK values for your particular printing press). In theory, this allows exact color matches between scanned, displayed, and printed images, but in practice things are a lot more complicated because (a) people don't perceive color the same way from an emissive display such as a CRT and reflected color from paper, and (b) not all devices can reproduce the same range of colors. Category (b) is especially tricky because the only way to ensure an exact color match is to use a lowest-common-denominator set of colors. As you can imagine, that's not a good idea. It doesn't look very good. In any case, ICC goes at least partway to solving these things.
Now we get to the patent problem. It appears that Electronics for Imaging has some patents that cover the generic idea of colorimetric matching between scan, display, and print. These patents have recently been upheld in court, so they'd appear to be pretty strong. I don't see a way around them.
As far as I know, these patents only apply in the United States. There is some very interesting development of color management code going on outside the US. Perhaps in 2003, when the most important of the EFI patents expires, this means that color management will be free for all to use.
However, it looks like the letter refers only to the BSD software. It's a little known fact that the UC system's default license for software released by researchers, etc., has changed significantly since the BSD days, and (last time I checked), isn't a free software license at all.
My question, if anyone knows the answer, is whether UC has seen the light and decided to allow new software to be released under the new BSD (=~ X) licesnse, or whether the same bad non-free license applies.
The PDF version of the paper, with lots of detailed images, is here.
I'd like to commend the PNAS for putting the PDF file online for free and with no registration hassle. In addition, the server seems to be holding up quite well. It looks like a successful defense against the/. effect does exist!
In case anyone was wondering whether the guy is a crank, Reference [1] contains Mathematical Proof:
1. E. Terrell ( not published notarized, 1979 ) " The Proof of Fermat's Last Theorem: The Revolution in Mathematical Thought " Outlines the significance of the need for a thorough understanding of the Concept of Quantification and the Concept of the Common Coefficient. These principles, as well many others, were found to maintain an unyielding importance in the Logical Analysis of Exponential Equations in Number Theory.
To complete the Proof, simply use the corollary of the Taniyama-Shinomura Conjecture, which is that if you have proved FLT and your name is not Andrew Wiles, you are a crank.
Thanks, plambert, for making such a convincing demonstration.
The take-home message here is that it is generally safe to use the same key a number of different times with a conventional secret-key system, but not safe at all with a one time pad.
Yes, OTP's are completely invulnerable when used correctly. This is similar to saying Micros~1 software doesn't crash when it doesn't come across any bugs.
The essence of OTP is almost trivially simple: generate a large random file, distribute it securely to the receiver of the file, then XOR it with the message. The receiver XOR's it back, and voila, the message!
Of course, the trick here is securely conveying the random file to your communications partner. This is almost as hard as getting a secret message across. You can't email it, or even send it encrypted, because that reduces the security to the weakest link. Thus, all OTP gives you is a form of time-arbitrage. If you can do a secure transmission at time A, that gives you a free secure transmission at later time B.
Then you have to worry about only using the pad once. If you use it twice, your message is totally toast. During WWII, a lot of traffic was gathered this way.
Finally, you need to worry about the keying material. If it's recovered (on either side), your messages are also toast. Since you need to store the key between the time of key exchange and the time of message exchange, it's a pretty ripe target for somebody to snatch off your hard drive. And forget about storing it encrypted - the same weakest link problem.
So this is why people don't use OTP's. You get perfect theoretical security, but in practice keeping track of the keying material is a bitch.
Finally, if you really want to do OTP, I recommend grabbing some/dev/random output and using a simple script to XOR./dev/random is carefully designed (largely by our own Ted Ts'o). Given what the HardEncrypt people say about sound header files, I find it difficult to believe that anywhere near the same care went into the design.
This statement seems to be inconsistent with the History of TrueType. According to that doc, Kaasila completed work on TrueType in August 1989. In fact, Kaasila started work on TrueType in August 1987, so there would have been exactly three months to get this into the LaserWriter II. Operating system support would not be announced until over three years later (this data from the Interview with Sampo Kaasila.
So I'll be skeptical of this claim unless I see some hard evidence.
What kind of evidence do you have for this? Can you point to published documents and/or software dated before May 8, 1988?
If so, it would be an excellent argument to overturn the patents.
Alternatively, I think some of the Metafont work may anticipate the TrueType patents. People don't give it very many props now, but it contains some pretty amazing technology, and is truly one of the pioneering Open Source projects.
Incidentally, I agree with the posters who have pointed out that this is not a good "ask slashdot" question in the sense of "which 3d graphics card works best for linux right now."
That said, this question touches some deep issues that I'd like to try to comment on.
The main thing is that different projects have different needs in the design process. In most of the projects that I've worked on, learning how to do "X" is more of the thing than actually writing the code to do "X." This is probably because I tend to choose "fun" projects. If I were banging out yet another goddamn middleware transaction thingy, I'm sure that more formalized "processes" would make more sense.
As it is, the usual processes that get applied assume that it's already understood what is needed and how to accomplish that. One common thread to many of the horror stories I've read is the churn-mill of changing requirements and specifications. To me, this is a natural consequence of not knowing what you're doing to start with.
And not knowing what you're doing when you start is necessarily a problem, especially if learning is a part of the process. This is perhaps one of the greatest things about free software - it's a learning-centric process.
I think good design is just as important in the free software world as elsewhere, but it manifests itself in different ways. Usually, there is more than one competing project in a given space. Ideally, the one with the better design will win more developer hearts and minds. This is of course not always the case - often, a program will succeed in spite of its bad design, or perhaps because of it (a certain popular mail transfer agent certainly comes to mind:).
And the other thing about free software design is that it's often a whole lot simpler than comparable designs from the commercial world. Free software rarely comes with chrome-plated tail fins. In my opinion, the mark of a truly outstanding design is that you don't even notice it's there. Take the sockets API for example; compare it with any other networking API out there.
I guess my point is "different strokes for different folks." The fact that free software turns out such good work even though there's no formal design process certainly proves that the formal techniques are not necessary, and suggests that the formal people are missing a big piece of the puzzle. But for successfully executing needlessly complex projects by an army of more-or-less competent programmers, I'm sure they are an indispensable communications tool.
Maybe some day the software engineering crowd will work out tools and processes that work so well everyone will use them, even in free software. But I'm not holding my breath.
I've been following the RTLinux project for a few months. It uses a very innovative approach to combining RT features with a standard Linux kernel. Basically, there is a minimally small RT kernel, and the Linux kernel running on top of it as an idle task.
This approach has a number of advantages. The main thing is that you can factor your programs into the parts that really need RT (like your video and audio codecs and mixing) and the parts that don't (like the initialization and configuration). Life gets easier on several counts. First, the RT part can get much simpler because it doesn't have to support a full, rich operating environment. Second, your apps get simpler because the bulk of them don't have to be specially made to fit in the RT box.
The other cool thing is that you're not burdening the mainstream Linux kernel with the requirements of being realtime. The Linux kernel doesn't have to worry about scheduling RT tasks while it's in the middle of a complex internal operation - the RT scheduler will just "make it so". Thus, we get to take advantage of all the cool development in the Linux kernel, including drivers and so on, without having to have an incompatible RT branch.
So my feeling is that this approach has great promise for building kick-ass consumer multimedia systems. I mean, you'd really be able to play skip-free MP3's and videos while doing multiple compiles or intensively surfing the web. Audio effects box? Sure!
The main thing standing in the way of this RT mecca is compatibility with existing stuff, almost all of which was designed without RT in mind. Some of the RT stuff can be kludged on top of the existing stuff, but a clean design is appealing for a number of reasons.
So to me, this announcement is good news. If Amiga has a codebase of RT multimedia stuff that can be readily ported to the RTLinux platform, then they really have a chance of delivering something interesting and useful. The smartest thing they could do is ship a computer that's just as good a Linux box as a Linux box, and just as good a multimedia platform as, say Be. It looks to me that both technically and marketing-wise, they now have a chance at it.
Slashdot Mirror
What do I, as a lowly network application programmer do if I want to write portable code that migrates smoothly to ipv6?
Last I checked, getaddrinfo was not widely available under most Linux distros. Apparently, there is no api standard for sockets, ipv6 or no (the ipv4 api is more or less a de facto standard, although there are still gaps, such as a threadsafe version of gethostbyname).
Stevens talks about XTI, but as far as I can tell it's yet another example of Open Group navel gazing. Is it even available under Linux?
Unless I'm wrong, they haven't made it easy to do the Right Thing. Ah well, I guess the right thing to do is complain to a local representative of ITC (the International They Consortium).
17 times by my count. A bit excessive. But then, CWD has never been known for its august writing style.
Over the years, CWD, in spite of its kick-your-ass, heavy-boozing style, has scooped the more mainstream media on some important issues. Remember when Brock found a student to reverse-engineer the block list of some crummy censorware, and (surprise surprise!) found sites blocked for pretty obviously political reasons?
I look forward to CWD being on slashdot. It deserves the wider readership it's going to get.
This doc should answer your questions and more:
Wonderful World of Linux 2.4
What many people don't realize is that domain name registrar competition is largely illusory. NSI still holds a monopoly for the database holding the com, org, and net top level domains. All the other registrars still pay NSI $9/year per domain for access to this database.
Thus, the only real competition is in billing and customer service. Given NSI's track record on these matters, the "alternative" registrars have a wide-open opportunity to do better, and I think this is a good thing. But the fact that NSI retains the monopoly on the database itself suggests that we're not going to see fundamental improvements any time soon.
The expected benefit of this new license is almost exactly the same as my licensing plan for libart. I'm just doing it using existing licenses.
Specifically, I'm releasing the code under GPL, but I'm also holding onto the copyright so I can license it to proprietary customers. I ask people to assign copyright over to me if they want their work to go in my relase. This creates a nice balance of powers, and gives me incentive to be a "nice guy." If I stop doing my job of maintaining libart well, then anyone who wants to is perfectly free to continue development under the GPL. Similarly, people are also free to fork if they feel that what I'm doing is unfair. It's in my interest to avoid a fork, so I better play nice.
Actually, while libart as a whole is released under GPL, large chunks (basically, everything used by gnome-libs, including gnome-print and the Gnome Canvas) are released under LGPL, to make it even more friendly towards people with alternate licensing arrangements. This may increase the fraction of proprietary users who can just use it for free and not pay me any license, but that's ok. It still gets libart out there and used, which is no doubt good for business.
This model is pretty simliar to what Sleepycat is doing for their Berkeley DB code. The main difference is that they have YAOSL, which imho is not quite as friendly as using the existing LGPL and GPL licenses. In particular, they had to grant Gnome a special one-off license to use DB safely in the Gnome libraries, which is obviously not needed for LGPL stuff.
I'm not advocating this model for everybody, but I'm expecting it to work well for libart. I think everyone benefits: I get funded, which means that I can eat and afford to put a lot of work into making libart great, and the free software community gets a well-polished graphics library without encumberance.
Isn't this supposed to be an important aspect of the programming art, to make best use of existing tools rather than trying to create a new set of tools for every possible use? In any case, I cringe every time I see yet another goddamn open source license.
I agree. While Microsoft currently has the most to lose from Linux world domination, they neither invented it nor will it go to the grave with them.
The Jargon file is clear enough on the predating. The term was coined by Gene Amdahl in reference to IBM. Now IBM is a major Linux citizen. Ironic, huh?
And regarting point two, why not just say "the combined market share of free software OS's going over 50%"? Linux rocks, and I agree there are no signs on the near horizon for its dominance to be threatened.
However, over a longer term, I don't see why three or four free operating systems occupying distinct ecological niches. Linus has already suggested that it may be technically wise to have separate codebases (with much sharing, presumably) for tiny embedded linux and for the massive 64+ multiprocessor systems.
Is there a web archive of the fsb mailing list?
Yeah, it was an interesting read, but I don't think it contains any deep revelations.
/. readers do work in corporate coding environments where these practices hold sway, but I'd guess we don't need much convincing. Linux and other successful free software projects prove convincingly that traditional "software engineering" principles are not necessary to make high quality code.
Structurally, the piece is a mess. This would seem to be a bad sign when the subject is one as exacting as programming! I realize that it was written mostly as the outline of a course, but still.
The main thesis appears to be that the most important attribute of people's cognitive styles is the one-bit mapper/packer distinction. As far as I could tell, "mapper" is pretty much the same old "think outside the box" philosophy, while packers are a strawman for inside the box thinking. Ok good, now I understand the world a whole lot better.
The piece did have some interesting moments. I liked the section on the quality plateau. There is a clear moral I get from the story:
An ounce of simplicity is better than a pound of abstraction.
A lot of the piece seems to be railing against traditional "software engineering" practices. Probably a lot of
The concepts of programming, especially those specific to larger projects with many people, are very difficult to master. A lot of writers on the subject delight with with oversimplified metaphors that are actually fairly easy to understand. In the best case, these metaphors actually capture an interesting aspect of programming. I'm not sure that this piece really achieves that goal.
I think they left out a risk from the S1...
"A FURTHER POTENTIAL RISK FACTOR THAT MAY IMPAIR THE PROGRESS OF THE COMPANY IS ITS DEPENDENCE ON THE LINUX COMMUNITY TO WRITE THE CODE THAT WE WILL SHIP. WHILE THE LINUX COMMUNITY HAS AN UNPARALLELED TRACK RECORD IN DEVELOPING HIGH QUALITY CODE, THEIR SMUG KNOW-IT-ALL ATTITUDE MAY DETRACT FROM THEIR SUPPORT OF THE COMPANY'S GOALS. IN ADDITION, THE FACT THAT THEY ARE A BUNCH OF PIMPLY FACED TEENAGERS MAY POSE A FURTHER RISK TO THE COMPANY."
Hopefully, it's not too late to amend the filing.
While I tend to agree regarding the privacy issues, I've also have some unpleasant experiences with the W3C over strictly technical issues. If you search the W3C mailing list archives for the DOM and SVG working groups, you'll see some of this discussion.
The fundamental problem is that, unlike the IETF, the W3C process is closed. Really closed. Members of a working group are obligated to keep the discussions of the working group confidential. There are open mailing lists for public comment, but trying to actually raise technical issues and see them addressed is like pulling teeth.
I know the W3C tries pretty hard, and it seems kind of unfair to pick on them, because they're far less avaricious than the typical make-10^9-buck-quickly Internet scheme, but their process is just not good. You see this reflected in their specs, which are often more complex than necessary, contain technical flaws, and have too much concession to industry demands.
"Rough consensus and working code" forever!
Hi Aaron,
I really liked the reviews on your page. I will be picking up a few recommended books.
If you ask me, Children of the Mind is easily the worst (or least good) book out of the Ender canon. It's well crafted, of course, but contained little of the magic of the first two.
TeX, on the other hand, implements consistent rendering. It accomplishes this basically through mind-bogglingly careful craftsmanship. As anyone who's been through the TeX sources knows, it makes no use of floating point. Rather, all computation (including trigonometry and other complex formulae) is done with hand-coded fixed point math. That way, Knuth guarantees that the document will be pixel-for-pixel on any TeX implementation.
Ironically, TeX is in this way much more WYSIWYG than, say, an HTML editor. What you see (in the xdvi preview or whatever) is exactly what you get when you transport the document to other machines. In an HTML editor, yes you get to see that your font kinda resembles Times, and you get to see the colors, but every browser is going to render the page slightly differently. In my opinion, calling this "WYSIWYG" is stretching the original meaning of the acronym somewhat.
I think the holy grail is a good interactive editor, with the typographic sophistication of TeX, a nice stylesheet mechanism, and the consistent rendering property. Having the editing interactive means that you have much shorter cycles towards getting the document to look like what you wanted.
I personally am working toward this goal with the Gnome-Text subsystem in Gnome. I have a good head start because I am using ideas, algorithms, and file formats from TeX. Consequently, there's code in Gnome CVS (under the libhnj module) that can read TeX hyphenation data, then typeset using TeX-like whole paragraph optimization. My current implementation is about 12 milliseconds per page on a 400MHz Celeron. This is fast enough for interactive display.
So if you really care, you can help me with the coding. Of course, this is /., so I'm not expecting too much :)
Unlike the people who get a lot of publicity for being free software or Open Source gurus, Knuth hasn't sought a lot of publicity for his contributions. But they are there for all of us to benefit from.
Much of my work on the printing subsystem of Gnome consists of adapting the beautiful work that Knuth and his students did with TeX and Metafont. The more I study the original sources for this work, the more impressed I am by their depth overall "rightness." I do believe that it is time to adapt the best parts of the work to a more modern environment with interactive editing and so on, but this in no way detracts from the magnitude of the original work. And, because it's free software, I can!
So, thank you, Don Knuth, for being a pioneer both in computer science and in free software.
There are basically two types of color matching that are relevant. The first is Pantone spot colors, and the second is ICC. The latter is generally what you'd use when preparing photos and related images for CMYK offset printing. ICC is gaining ground, and is used as the color matching standard in such emerging technologies as SVG.
Pantone is basically a named collection of colors. The cool thing about Pantone is that you can communicate Pantone colors to professional printers, and they know how to match it. Let's say for example that you're doing a business card, and you want your logo to be in black and a nice deep blue. By specifying Pantone 280, you can be assured that the printers will produce the same nice deep blue that you intended. Incidentally, it's not hard to find a Pantone palette for Gimp if you're skilled at Web searching.
Pantone colors are far less useful when dealing with natural images. The Pantone palette is only a few thousand colors, while the standard for scanned images is sixteen million. These are all the colors between "nice deep blue" and "slightly deeper blue than that". That's where ICC comes in.
ICC basically specifies a transformation from a source color space (say, a calibrated RGB such as sRGB) to a destination color space (say, CMYK values for your particular printing press). In theory, this allows exact color matches between scanned, displayed, and printed images, but in practice things are a lot more complicated because (a) people don't perceive color the same way from an emissive display such as a CRT and reflected color from paper, and (b) not all devices can reproduce the same range of colors. Category (b) is especially tricky because the only way to ensure an exact color match is to use a lowest-common-denominator set of colors. As you can imagine, that's not a good idea. It doesn't look very good. In any case, ICC goes at least partway to solving these things.
Now we get to the patent problem. It appears that Electronics for Imaging has some patents that cover the generic idea of colorimetric matching between scan, display, and print. These patents have recently been upheld in court, so they'd appear to be pretty strong. I don't see a way around them.
As far as I know, these patents only apply in the United States. There is some very interesting development of color management code going on outside the US. Perhaps in 2003, when the most important of the EFI patents expires, this means that color management will be free for all to use.
Hope this clears things up.
You're not taking into account that said nameless spy agency is too incompetent to track this kind of thing down :)
It's very easy to imagine that enough of the detailed facts have changed to protect the, uhm, err, ok.
But the post itself has the "ring of truth" to me.
This looks like a very nice move, kudos.
However, it looks like the letter refers only to the BSD software. It's a little known fact that the UC system's default license for software released by researchers, etc., has changed significantly since the BSD days, and (last time I checked), isn't a free software license at all.
My question, if anyone knows the answer, is whether UC has seen the light and decided to allow new software to be released under the new BSD (=~ X) licesnse, or whether the same bad non-free license applies.
I'll research this myself if nobody else knows.
Hmm, that's entirely possible. I accessed it from my machine at UC Berkeley. I know that we have a number of "digital library" agreements.
I definitely wasn't trying to be sarcastic. If indeed they are restricting access, then I withdraw my commendation.
I'd like to commend the PNAS for putting the PDF file online for free and with no registration hassle. In addition, the server seems to be holding up quite well. It looks like a successful defense against the /. effect does exist!
In case anyone was wondering whether the guy is a crank, Reference [1] contains Mathematical Proof:
1. E. Terrell ( not published notarized, 1979 ) " The Proof of
Fermat's Last Theorem: The Revolution in Mathematical Thought "
Outlines the significance of the need for a thorough understanding
of the Concept of Quantification and the Concept of the Common
Coefficient. These principles, as well many others, were found to
maintain an unyielding importance in the Logical Analysis of
Exponential Equations in Number Theory.
To complete the Proof, simply use the corollary of the Taniyama-Shinomura Conjecture, which is that if you have proved FLT and your name is not Andrew Wiles, you are a crank.
Thanks, plambert, for making such a convincing demonstration.
The take-home message here is that it is generally safe to use the same key a number of different times with a conventional secret-key system, but not safe at all with a one time pad.
Looks like the one time pad strikes again!
/dev/random output and using a simple script to XOR. /dev/random is carefully designed (largely by our own Ted Ts'o). Given what the HardEncrypt people say about sound header files, I find it difficult to believe that anywhere near the same care went into the design.
Yes, OTP's are completely invulnerable when used correctly. This is similar to saying Micros~1 software doesn't crash when it doesn't come across any bugs.
The essence of OTP is almost trivially simple: generate a large random file, distribute it securely to the receiver of the file, then XOR it with the message. The receiver XOR's it back, and voila, the message!
Of course, the trick here is securely conveying the random file to your communications partner. This is almost as hard as getting a secret message across. You can't email it, or even send it encrypted, because that reduces the security to the weakest link. Thus, all OTP gives you is a form of time-arbitrage. If you can do a secure transmission at time A, that gives you a free secure transmission at later time B.
Then you have to worry about only using the pad once. If you use it twice, your message is totally toast. During WWII, a lot of traffic was gathered this way.
Finally, you need to worry about the keying material. If it's recovered (on either side), your messages are also toast. Since you need to store the key between the time of key exchange and the time of message exchange, it's a pretty ripe target for somebody to snatch off your hard drive. And forget about storing it encrypted - the same weakest link problem.
So this is why people don't use OTP's. You get perfect theoretical security, but in practice keeping track of the keying material is a bitch.
Finally, if you really want to do OTP, I recommend grabbing some
Happy ciphering!
So I'll be skeptical of this claim unless I see some hard evidence.
What kind of evidence do you have for this? Can you point to published documents and/or software dated before May 8, 1988?
If so, it would be an excellent argument to overturn the patents.
Alternatively, I think some of the Metafont work may anticipate the TrueType patents. People don't give it very many props now, but it contains some pretty amazing technology, and is truly one of the pioneering Open Source projects.
But these kind of claims require documentation.
That said, this question touches some deep issues that I'd like to try to comment on.
The main thing is that different projects have different needs in the design process. In most of the projects that I've worked on, learning how to do "X" is more of the thing than actually writing the code to do "X." This is probably because I tend to choose "fun" projects. If I were banging out yet another goddamn middleware transaction thingy, I'm sure that more formalized "processes" would make more sense.
As it is, the usual processes that get applied assume that it's already understood what is needed and how to accomplish that. One common thread to many of the horror stories I've read is the churn-mill of changing requirements and specifications. To me, this is a natural consequence of not knowing what you're doing to start with.
And not knowing what you're doing when you start is necessarily a problem, especially if learning is a part of the process. This is perhaps one of the greatest things about free software - it's a learning-centric process.
I think good design is just as important in the free software world as elsewhere, but it manifests itself in different ways. Usually, there is more than one competing project in a given space. Ideally, the one with the better design will win more developer hearts and minds. This is of course not always the case - often, a program will succeed in spite of its bad design, or perhaps because of it (a certain popular mail transfer agent certainly comes to mind :).
And the other thing about free software design is that it's often a whole lot simpler than comparable designs from the commercial world. Free software rarely comes with chrome-plated tail fins. In my opinion, the mark of a truly outstanding design is that you don't even notice it's there. Take the sockets API for example; compare it with any other networking API out there.
I guess my point is "different strokes for different folks." The fact that free software turns out such good work even though there's no formal design process certainly proves that the formal techniques are not necessary, and suggests that the formal people are missing a big piece of the puzzle. But for successfully executing needlessly complex projects by an army of more-or-less competent programmers, I'm sure they are an indispensable communications tool.
Maybe some day the software engineering crowd will work out tools and processes that work so well everyone will use them, even in free software. But I'm not holding my breath.
I've been following the RTLinux project for a few months. It uses a very innovative approach to combining RT features with a standard Linux kernel. Basically, there is a minimally small RT kernel, and the Linux kernel running on top of it as an idle task.
This approach has a number of advantages. The main thing is that you can factor your programs into the parts that really need RT (like your video and audio codecs and mixing) and the parts that don't (like the initialization and configuration). Life gets easier on several counts. First, the RT part can get much simpler because it doesn't have to support a full, rich operating environment. Second, your apps get simpler because the bulk of them don't have to be specially made to fit in the RT box.
The other cool thing is that you're not burdening the mainstream Linux kernel with the requirements of being realtime. The Linux kernel doesn't have to worry about scheduling RT tasks while it's in the middle of a complex internal operation - the RT scheduler will just "make it so". Thus, we get to take advantage of all the cool development in the Linux kernel, including drivers and so on, without having to have an incompatible RT branch.
So my feeling is that this approach has great promise for building kick-ass consumer multimedia systems. I mean, you'd really be able to play skip-free MP3's and videos while doing multiple compiles or intensively surfing the web. Audio effects box? Sure!
The main thing standing in the way of this RT mecca is compatibility with existing stuff, almost all of which was designed without RT in mind. Some of the RT stuff can be kludged on top of the existing stuff, but a clean design is appealing for a number of reasons.
So to me, this announcement is good news. If Amiga has a codebase of RT multimedia stuff that can be readily ported to the RTLinux platform, then they really have a chance of delivering something interesting and useful. The smartest thing they could do is ship a computer that's just as good a Linux box as a Linux box, and just as good a multimedia platform as, say Be. It looks to me that both technically and marketing-wise, they now have a chance at it.
The Amiga is dead, long live the Amiga!