Slashdot Mirror

At Bell Labs here.

"The calcite microlenses expertly compensate for birefringence and spherical aberration - physical effects common in lenses that distort light - and scientists hope to mimic nature's success and design microlenses based on the brittlestar model. Such biomimetic lenses may prove useful as components of optical networks, and in chip design, where they could potentially improve optical lithography techniques."

Every time I see RMS get all uppity like this, I'm tempted to port the BSD userland to Linux--replace glibc with BSD's libc, dump gawk for the One True Awk, etc... and release a distribution with only a small amount of GNU stuff (separated out so you can easily delete it if you want). But unfortunately, I don't have the time for it... it'd be awesome if someone did this though :)

I opened up the link, read as far as the section on "things to leave out", saw "templates", and closed the link. Now, this might seem a bit hasty, but hear me out. Templates are the single greatest feature of C++, and the reason that I like the language at all. Yes, they are complicated to implement, and compilers initially failed on them, but they've gotten a lot better now. Yes, they can be tricky to use, and you can get trapped with them. But for writing libraries, there's just nothing like templates. As a matter of fact, lack of templates is probably the one thing that annoys me most about Java (excessive verbosity being the other). There are people trying to fix this, with Generic Java. (Didn't want to unfairly malign an area of Java that is obviously being worked on.) Anyway, this comment has gotten rather far afield of D, so I'll just say what you all know to be true: there are hundreds of C or C++ like languages out there. Few of them attain widespread use for a simple reason: lack of backing from large entities, be they commercial or open-source supporting (or both!). D will likely be the same.

Actually, Ken Thompson wrote a 3D game called Space Travel in the late '60s. Space Travel. It might not be the earliest 3D game but it must be close.

Offtopic, but still near-and-dear to the hearts of many readers: How does the licensing for Plan 9 work? I saw a copy of the GPL listed as Exhibit A at the very bottom of their own licensing page.

The licensing looks liberal enough (it's labelled "PLAN 9 OPEN SOURCE LICENSE AGREEMENT" license), but how is it related to the GPL?


-bch

My fault-- according to this article Jeff Oldham is converting most of the old illustrations into MetaPost. Anyway, the technical challenges involved in "compiling from source" (so to speak) TAOCP are probably enormous.

Prior to this, the best sounding speech synthesis I had heard was from the Festival system, which is still pretty good - epecially considering it has an open source license, something the AT&T system doesn't.

Another good speech synthesizer, no doubt an early version of the AT&T one (possibly?), is by Lucent.

Still, I am amazed at the quality of the AT&T system - it sounds almost perfectly natural. To the naysayers that say "No, it isn't natural" - what all of you have to realize is that this simply demo doesn't allow you to tweak all the variables that would really allow the inflections or type of voice (like whispering, etc) to really come through - it is too bad they don't give an advanced interface with a FAQ or some other form of documentation to allow this, but I imagine that if they did, it would probably take quite a while to compose even a simple sentence (I remember the hell you had to go through with an old Radio Shack speech synth for the Color Computer, specifying individual phoenomes (sp?) just to get proper speech to come out - it could pronounce many words, but others it just fell flat on its face).

Finally - something I want everyone to ponder. Take a look at this old article (it was about Square redubbing FFTM) - once it loads, search for "cr0sh" and "I dare say" - you will come across a series of comments about what I think may happen in the future - what is funny is that the comments in reply to my take on things sound like your typical naysayers. How many computers were we supposed to only need back in the 60's? How much memory would people "only" need again Mr. Gates?

What I predict will come about - probably sooner than we can all imagine. It may not be cheap enough to do it now, at a quality that people would watch, fast enough to be done quicker than what can be done with live actors - but it is all software and hardware - this stuff will get faster and cheaper. Anybody who has been in this business long enough knows that it will happen. There might still be a need for actors, and voice artists, and such - but they probably won't have the "god" status society seems to confer on them now (with the exception, perhaps, of stage acting - which will probably enjoy a huge comeback).

Worldcom - Generation Duh!

Kernigan & Pike, The Practice of Programming (Addison-Wesley Professional Computing Series), do a compare. Kernigan's academic paper on it is here

Ah, I would recommend you reconsider. I like Perl, I program in Perl, I program professionally in C, but in my opinion these are not a good "learning language."

What makes a good learning language?
Clean, modern design that encourages good programming technique. I suggest you look at languages like Python, Klyix/Delphi, and Java.

You may not choose them in real-world development, but in my opinion they are nice clean designs which encourage good programming habits rather than Perl and C that can be nice and clean, but do not encourage or require good habits. BTW, you can get started in two out of three of those languages for free, which is a bonus for anyone learning to program.

Visual C++ is a Microsoft product, a C and C++ compiler, and is typically used in referring to meaning to develop within their environment, i.e. Win32, Platform SDK, MFC (Microsoft Foundation Classes), etc.

C itself is just a language, it is platform independant, and highly portable, from embedded processors and smartcards to vector supercomputers. Often people refer to ANSI C, which contain the last major changes to the language (as in The C Programming Language), while minor changes were made in ISO 1989 and 1999 international standards.

GJC is indeed cool, and it had the name before GCJ. Watch those acronyms. :)

BTW, gcj and gjc work together. :)

However, these languages are very difficult to learn and this can get in the way of learning other facets of programming and computer science. This learning curve impacts the learning of the general problem solving skills needed to work outside the limited world of discrete finite machines, such as in networking or inter-personal spaces. Java solves some of the problem in the OU cirricula by providing a "lite" language. It is a language that does impressive things very easily and that gaurds the programmer against some nasty complexities like platform/compile/library incompatabilities. These are also the reasons it is popular in industry. Languages such as Fortran and Cobol hold on in our Science and Business colleges because of legacy code and the personal perceptions of the faculty. Unfortunately you can improperly teach the problem solving ciritcal to progammin in any language, just as you can properly teach without a language. Classes that focus on getting design and thought about a problem started at least during if not before a project would be much more helpful. Systems such as OO pattern and tools like UML provide much help to the Software Engineer and Computer Scientist alike.

I've worked in the *real world* Perl, C, C++, Z80 assembler (in embedded and non-embedded environments) and Java. Each has a different goal and a different way of getting their. However, irregardless of the path taken, they achieve those golas to a limited degree. Oak, the language that became Java, was designed to be a simple extension of real OOP with a C syntax. Like other embedded languages, most of which are either assemblers or functional strangely enough, it has grown to include methods of getting at the machine and conecpts such as closures. If it adopted lamda calculus syntax extensions, you could use it to teach mathematical therom proving.

However you choose to view the language, as toy, irritant, the next wave, the last wave, et cetera, it is in our CompSci cirricula and it can be taught and taught well. When I went on to my second year of classes I was exposed to C++ for Data Structures and Java for a Programming Abstractions course. Data Structures became a waste of a class trying while to work with a professor who was new to the lanugage. The Programming Abstractions professor knew what was up with Java and so taught us a lot about OO design before delving into the language. I didn't get a lot of help from my time learning Haskel, wich in turn had severly limited my time working with C before moving onto C++.

For what it's worth, learning RCS, and later CVS and UML, helped with my programming more than any of the languages I in which I learned or worked. In the end, these languages proved that they are just tools. Like all tools - Craftsman, DeWALT, GNU liscenses, Sun.Java.*, there will be proponents and detractors and teachers and charlitans. You mileage may vary.

Here's to 5 years of CompSci and counting (with 1 year to go.)

As you can read here, they were just designing Unix in the Summer of 1969. The first programs were written using an Assembler on a GECOS system in 1970. C didn't exist, even as a concept, until 1972. Pipes came along in 1972, also. Unix was fairly unrecognizable until 1972-1974 or so.

Dating Unix "back to the 1960s" is like dating heavier-than-air flight to Michaelangelo.

But, you're right, the issue is should Stallman have anticipated this problem in the early 80's. And the answer is a resounding yes.

Multics had Shared libraries in the mid 60s. The DEC operating system that Stallman first developed Emacs on (TOPS-10) had them in the mid 70s. They were already old-hat by the 80's, regardless of when you first learned of them.

With the help of Bell Labs' Text-to-Speech project, this can be done is a jiffy!

e.g.

enforcer/death1.wav -> "arrrrrrrrrg"

enforcer/idle1.wav -> "dum de dum dum"

enforcer/pain1.wav -> "ow"

enforcer/pain2.wav -> "ow ow ow!"

Is it just me, or is this one hideously ugly GUI

http://plan9.bell-labs.com/plan9dist/screenshot.ht ml

I wish the GUI was "beatiful" instead of the source. :P (It can run any other WM, right?)


--

It's open source, written by some of the best people in the business, (the source code is beautiful) and its whole raison d'etre is to investigate how things should be done, instead of how they are usually done.

you might find some of your fundamental assumptions challenged and your paradigms shifted, but isn't that the point?! it keeps fundamentals of UNIX while discarding all the crud that's built up since the 7th Edition...

Human speech (at least in English) is very complicated - it's not just a matter of translating symbols one-to-one into sounds. English, according to my copy of the Big Book of Linguistic Facts (tm), has ~40 vowel sounds (including regional variants, but not including diphthongs). And 5, maybe 6, vowel letters. So the computer has to perform some fairly elaborate calculations that most humans can do "automatically" in order to decide which sound snippet to use, how to tweak it and blend it with surrounding sounds, etc, etc - personally, I thought that the output from the Bell program was quite impressive.

Look at http://www.bell-labs.com/project/tts/tts-overview. html for more information on how they built this system:

The unit selection and concatenation modules select and connect the acoustic inventory elements. These modules retrieve the necessary units, assign new durations, pitch contours and amplitude profiles and pass parameter vectors on to the synthesis module. Our TTS system uses vector-quantized LPC and a parametrized glottal waveform for synthesis.

etc, etc, etc

Messerschmidts! Messerschmidts?
Buddy, I got your Messerschmidts right here, and here.

I especially enjoyed using this site to make very humourous new mail alerts. My personal favorote was to use the german one to say thing in english with a german accent. Hours of fun!

spoonz

---

Here you go.

The folks at Bell Labs have a sense of humor, anyway.

On their pre-generated samples page, the English sample is a computer-sung rendition of "Bicycle Built for Two." This is the song which the murderous HAL 9000 in Clark/Kubrick's 2001: A Space Odyssey sang as he was being put to sleep.

Whoa...

Dancin Santa

But ML turned out to be great! It functions like Lisp, but has some additional interesting features:

• Strong type checking: Most of my Lisp errors were type errors. ML is the most strongly typed language I have heard of (its often used by language theoriticians). When you run the program it is first fully type checked, very few runtime errors are even possible. What makes it different from C is that type checking is implicit (although you can specify types if you want). The compiler/interpreter will figure out which types a function can accept, so you can have a function that accepts many different types for some argument, yet you get the safety of full type checking.
• Its simpler than Lisp. Lisp has too much crap thrown in. ML is more understandable (like Scheme).
• Few parenthesis. Although your programs are structured similar to Lisp, most parenthesis are not needed, which IMO really helps readability and makes it easier to change (no more counting parenthesis when you add something).
• More powerful functions. When you call a function the arguements are actually matched against a pattern in the function declaration. The function with that name which has a pattern that matches the closest is used. You can write interesting recursive functions where one version of the function gets called normally, and another gets called when the argument is a 1, for example. This only scratches the surface of how powerful this feature is.
• There is even an object oriented version: Caml

Have you actually used a Lisp environment in the past twenty years or so? Every major Common Lisp implementation has a compiler, and at least one doesn't even have an interpreter. What specifically about the condition system do you find inadequate compared to other languages? It definitely offers support at a level at least as high as something like C++ or Java.

As far as doing real work in functional languages, perhaps you ought to ask the Erlang people about that. Or check out this link.

Of course, you could just use OCaml to generate the C code. :-)

Sorry, these links should work better:

Vita Nuova

Plan 9

I've done extensive nanofabrication, and these guys have chosen their words so carefully as to be misleading. When they talk about making structures on the "subcellular" scale for biological research, it sounds impressive but really isn't. A typical red blood cell is 5 microns across. The smallest features produced photolithographically for your Athlon are 0.13 microns across. Even more annoying is their claim of molecular and submolecular scale device size without actually naming a number. Molecules can be big - DNA can be many microns long when uncoiled.

A meaningful figure of merit for resolution is: how small a feature can you pattern in resist and then transfer to an underlying substrate, either by etching or through metallization. Fundamentally, e-beam lithography's resolution is limited by the choice of resist, the physics of the development process, and the subsequent pattern transfer step. Making features smaller in width than 10 nm (roughly 40 atoms) is exceedingly hard, even in isolation. Doing that regularly, at production speeds with sub-10 nm registration across a 30 cm wafer, is industrially unachievable right now.

As far as I can tell, this is not a breakthrough in any way, shape, or form. This kind of overhype worries me. It's almost worse than the utopian claptrap from people like Drexler - everyone with a clue know Drexler is a loon, but people may actually believe spokespeople from JPL....

I disagree. ANSI C isn't broken, but look at early 80s C code. Look at an early version of C and tell it couldn't be improved upon. I dare you :)

Between ISPs, everyone runs BGP4, and most ISPs impose policies that restrict the transit traffic they're willing to carry. Also because inter-domain traffic spans multiple companies, it's much harder to plan what happens in the event of a failure. So there's less redundancy than you might think from just looking at Internet maps.

Also BGP itself has some convergence problems, so whilst it should only take a minute or two to find a backup path, it can take a lot longer than that in practice.

In addition, it's not really hard to misconfigure BGP and screw up someone elses routing by advertising something you shouldn't. This isn't a lack of redundancy but a lack of robustness.

Finally, many internet problems that users might think are routing problems turn out to be issues with DNS, and whilst the network itself is fine, the hostname just can't be resolved to the IP address of the end system.

So, it depends where you look. There's definitely a lot of room for improvement, but most of the internet has a reasonable amount of redundancy. The trouble is that you often only find out that your redundant backup isn't working when the primary solution fails (this is especially true of DNS, less so of routing).

-Fzz

If you're so far gone you use VB, then why choose CORBA over DCOM?

But seriously, 15 exhausting seconds of Googling failed to turn up a serious CORBA works for Standard ML. (But it's good to see there's one for Lisp).

After seeing that benchmark, I got very curious cause I thought it was VERY odd. I read up on the web and noticed that several had commented that the test is VERY favorable for Perl and Awk due to it's "heavy use of associative arrays and strings". I can't comment that because I don't have the source code for any of those but I do know that the results are very weird.

You can get it from the author's web page. The Markov chain one was written in C by him a very very long time ago as a prank new.news poster before the re-org (before ANSI C, or Perl existed). I do think this is an updated version though.

A small app that has two nested loops and calls a method, passing two integers as parameters and returning an integer as the result.

Well that's a fine benchmark, if that is really the kind of code you expect to write. The markov chain one at least does some I/O and uses real data structures. Neither are all that close to code I tend to write, but the markov one is quite a bit closer (I normally have data structures, and I/O for example).

Also note that this book was published in Feb 1999, so the book was prob. done six months before, with software possibly months older. The Java for the x86 may well have had Hot Spot stuff, but the Irix version may not have. Also as I recall I/O sucked big time for C++ (surprising to me, I expected it to win), and I/O for Java (also surprising, I didn't expect I/O to rock, but I expected it not to be so bad).

P.S. if you program go get the book. It really is good. It is one of the few that has a chapter on debugging (even if it is pretty elementary).

As cameras get smaller, smarter, and eventually mobile, privacy is simply going to evaperate. Wireless swarms of cameras the size of flies will be everywere (this technology is already being tested) recording your every movement.
Small surveillance Plane
Camera size of a quarter
6 inch flying camera

Even without trying, most people get on surveillance video a few times a day: the bank, the local 'quicky mart', the gas station.

The only way to preserve privacy is to make preserving privacy a top concern of your government. Many people seem eager to trade their privay for security, but this only works when the security is in the hands of someone you trust, who would never abuse that power. Of course, no western government would ever abuse its power, right? Just ask Steve Jackson.

People who are willing to trade their privacy and freedom to the government for security are abdicating their adulthood, and letting the government be their babysitter.

Silberschatz (bell labs) has posted and excellent older chapeter (pdf) on Mach at

http://www.bell-labs.com/topic/books/os-book/mach- dir/mach.pdf ---->or here if your trusting

Salieri writes, "Ever notice how it's sometimes very difficult to tell which is the real or relevant link in the article write-up? Perhaps the editors can distinguish where the main attraction is." He then clicks preview to make sure the links work.

--------------------------------

http://plan9.bell-labs.com/who/ches/map/yu/index.h tml

Now, I don't know what'd happen to ./, but if there's connectivity, someone will step in. I've got my old ham rig boxed in the basement, just in case; that, and a packet radio TNC, and I could be a post-armegeddon ISP!

http://plan9.bell-labs.com/plan9dist/

PLAN 9 From Outer Space

I'm doing my dissertation on SCM software, so I've done research ;)

I don't like CVS; this is my own opinion and I'm saying so now, so don't flame me :) . The unreservered checkout model is a pain with any project larger than the average GPL hobby-kit. The more programmers you get the more merges need to be done. A merge requires knowledge of all changes under consideration, so the person merging needs knowledge of the entire project. As the goal of an SCM is to distribute the work, it is a failure in this situation.

I think locking is a better model. In my SCM, I'm allowing locking of individual functions/classes by clients. In addition, CORBA networking and XML-based storage are features.

Thanks for the bullet points, Node renaming was on my early lists, but I had forgotten it. :)

Personally, my favorite so far has been sablime( Link; rigid locking, SQL queries and can handle HUGE teams and documentation.

Not that I believe it's particularly relevant in this case (given that anything that they contribute to the Linux kernel at large would be in source form), but I believe you're referring to Ken Thompson's classic article Reflections on Trusting Trust. This is a must-read for anyone interested in computer security.

What makes you so sure that they received the complete source? Is the source even buildable? What makes you sure the Windows binaries don't include backdoors in source files Microsoft doesn't distribute?

I would bet that it is buildable. But see Reflections on Trusting Trust.

That paper applies to GCC too, of course.

Bell Labs is owned by Lucent, not AT&T. You can by the coffee stain in the upper-right corner of their webpage.

http://channel.nytimes.com/2001/03/08/science/08SU PE.html

now of course, Lucent has a website, with the press release here. The page with photos of the team can be found here on the bell labs site.

As Usual, the story was first reported in NATURE (NOTE - free registration gives some access, paid registration gives more)

...check out Shannon's classic 1948 paper "A mathemtical theory of communication". It is available in postscript (460 Kb), gzipped postscript (146 Kb), and PDF (358 Kb) formats, here on the Bell-Labs site. Warning, though: it's 55 pages, including 7 appendices.

...check out Shannon's classic 1948 paper "A mathemtical theory of communication". It is available in postscript (460 Kb), gzipped postscript (146 Kb), and PDF (358 Kb) formats, here on the Bell-Labs site. Warning, though: it's 55 pages, including 7 appendices.

...check out Shannon's classic 1948 paper "A mathemtical theory of communication". It is available in postscript (460 Kb), gzipped postscript (146 Kb), and PDF (358 Kb) formats, here on the Bell-Labs site. Warning, though: it's 55 pages, including 7 appendices.

...check out Shannon's classic 1948 paper "A mathemtical theory of communication". It is available in postscript (460 Kb), gzipped postscript (146 Kb), and PDF (358 Kb) formats, here on the Bell-Labs site. Warning, though: it's 55 pages, including 7 appendices.

...check out Shannon's classic 1948 paper "A mathemtical theory of communication". It is available in postscript (460 Kb), gzipped postscript (146 Kb), and PDF (358 Kb) formats, here on the Bell-Labs site. Warning, though: it's 55 pages, including 7 appendices.

Plumbing is a new mechanism for inter-process communication in Plan 9, specifically the passing of messages between interactive programs as part of the user interface. Although plumbing shares some properties with familiar notions such as cut and paste, it offers a more general data exchange mechanism without imposing a particular user interface. The core of the plumbing system is a program called the plumber, which handles all messages and dispatches and reformats them according to configuration rules written in a special-purpose language. This approach allows the contents and context of a piece of data to define how it is handled. Unlike with drag and drop or cut and paste, the user doesn't need to deliver the data; the contents of a plumbing message, as interpreted by the plumbing rules, determine its destination. The plumber has an unusual architecture: it is a language-driven file server. This design has distinct advantages. It makes plumbing easy to add to an existing, Unix-like command environment; it guarantees uniform handling of inter-application messages; it off-loads from those applications most of the work of extracting and dispatching messages; and it works transparently across a network.

Actually, if the poster was serious, I doubt he was supporting VB, but rather something like SML/NJ. The proponents of this language insist that their programs can be made unhackable because they can be mathematically proven to be secure.

Of course, I don't think this is the way to go - mostly because current SML implementations are damn slow, and I'm a C bigot. ;->
--------------------------

If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!

Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.

I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.

Have Fun!

If UNIX/LINUX treats everything like a file, why not TCP/IP ports, too? That way, you could assign a port to a group/user who could access that port without being root!!!

Ahh, yes. Somebody finally noticed. Unfortunately TCP/IP was not added to UNIX until BSD in the 80's. So we have BSD Sockets and the "Everything is a File" mantra no longer holds.

I believe that Plan9, now known as Inferno, works this way. It was developed in the late 80's/early 90's by the original UNIX people at Bell Labs. Lucent (Bell Labs) has released Plan9 source under their own license, source and binaries can be downloaded here.

Have Fun!