Slashdot Mirror

Mirror whitout the images:

http://razor.hemmet.chalmers.se/klez/klez.html

Xine (with decss plugin), Mplayer, Ogle, Videolan

There are of course many Linux news sources, and if you run a php-based web server they are easily added (simple drop-in code) to your web server - my private web site at www.mvw.net, for instance, has news from slashdot, the register, and newsforge. The scripts are at:

http://swamp.chl.chalmers.se/backends/

He currently has about 40 sources, primarily linux orienteded.

One of the main reasons we chose the +RW drives over the -RW drives, is the fact that the data can be written to the drives on loaded, slow systems, or across a network. A disk image does not need to be created, the data is written directly to the device from a modified mkisofs. The -R/RW drives require the system to burn the DVD in real-time, typically from an ISO image stored on disk. Buffer under-runs are a disticnt possibility if the system isn't up to the task of feeding the higher data rate of DVD drives. Another big plus over -R/RW media was the +R/RW's ability to incrementally add data to the media. I've not tested this. Reports indicate that Linux works transparently with the resultant multi-session file system, but other OS's are not, and only see data in the first session.

We are satisfied users of the HP 200i DVD+RW drives and dvd+rw-format and growisofs utilities found at http://fy.chalmers.se/~appro/linux/DVD+RW/

I have found that few of our older DVD-ROM drives can read either -RW or +R/RW media, although DVD-ROM drives purchased with our most recent Dell PC's can read both. Of course, YMMV.

---"I have to give Ransom credit for his good answers. Especially in the area of whether Caldera will make billions off Linux without giving back to the community."

The community gives to anybody who accepts their license (usually the GPL). The GPL has no clause saying that they must tithe if they make money on GPL software. I could care less if a company makes money on Linux, however if they provide a good product, I'll support them.

---"Ransom makes it pretty clear that Caldera's development of Linux, even though done for profit,"

Why even mention that? Go on to thier "Contact Us"... Caldera International, Inc. Hmm, wonder what that Inc. stands for .... It's not like they're an INCorporated company, right?

---"is in itself something big that's being given to the community--it's the effect that takes place when a product has a lot of support from reputable companies more than which lines of code Caldera writes and puts wherever. Even in Caldera didn't write a single apostrophe of code but only packaged other people's hard and free work and sold it for profit, they'd still be opening a market window for the Linux community that wouldn't have existed otherwise."

Since they're a company, let thier business stragedies hold them up.

---"I believe that for Linux to really be successful, both in terms of code quality and widespread acceptance, a team of companies needs to get together with a specific purpose to fulfill: To develop a desktop version of Linux similar in functionality to Windows XP or Mac OS X."

Funny thing is Linux is sort of the P2P os. All the parts are everywhere, there are multiple 'fixes' to the same problem, and developers are around the world. Asking some standards body to make a "UnifiedLinux" is asking for trouble. Other than thier words, what are these people going to do to sway developers to do addon X to code Y? The "UnifiedLinux" players are probably going to be PR and programmers, but still how's that going to guarantee that thier patch is going to be included?

---"In other words, other than a few options here and there, it wouldn't really have the possibility of configuring every detail. The bare-bones system, which basically means a desktop with a few icons on it for basic functionality (and no applications) would basically be integrated into the kernel."

In a way, isn't that true to a certain extent already? Linux/Unix ideas is you reuse components like crazy. Because of that, I just cant see "bare bones" along with desktop with a few icons. You need a bit of stuff to build your way up to X and your windowmanager.

---"When the computer boots up, it boots directly into a nice graphical desktop, kind of like the way BeOS did, except Linux will actually stick around. Most of the configuration would be built in, heavily reducing the number of "system" files."

So you're saying that "advanced OS'es like Windows" dont have as much systems files? Ever look at /windows , /windows/system or the registery with regedit? Yeah. Windows has tons of configuration options, with most of those being hidden it clsid's and other crap. It's either configuration TEXT files or a kludge of a registery.

---"No desktop system needs to drown in its own configuration. I would say that a really good bare-bones desktop Linux OS shouldn't take more than 15 to 20 megs of space, and that includes all the beautiful graphics it would have."

15-20 megs wouldn't even be enough for the graphics libs for your "beautiful graphics". Considering that WinXP is 1 GB install, I think people would be OK with a graphic install around 300 MB. I actually mean having it work correctly (including all the pretties, decent fonts, AA, all the "new OS stuff").

---"To make this system useful, a number of applications made specifically for this version of Linux would be included, increasing the size to about 60 or 80 megs. This might include the standard "fun" stuff that consumers look for, like video editing, audio editing, image editing, and the more mundane crap, like word processing and whatnot. Obviously, major formats would need to be recognized."

Most of the closed formats have been dealt with. Office argment has been beaten (like that already dead horse). Even DiVX, MPEG 4, DVD's, and newer MS and Apple/Sorenson codecs are being released by 3'rd party develpers.

---"Only when something that's actually easy to use becomes available, Linux will skyrocket in popularity and Windows will go into the dumpster. Yeah, most of the code for this exists. Someone just needs to recognize why Linux tends to be so damn complicated, and rearrange these pieces into something that's really well designed and coherent."

People will take "Easiness" over stability if that means complication. That alone shows why that is true. And of curse, you're dealing with the mysticism of a computer...

---"As a disclaimer, just so someone doesn't say, "You stupid fsck! If you think Linux is too hard, go back to Windows and enjoy crashing all the time."

That's what a slashdotters and other moronic haxor types do. They hurt linux. Usually though, RTFM or STFU is the best answer to a linux question (in their minds). Beginners have no idea a manual exists for Linux (man).

---"Otherwise, learn how to use the damn thing!" I've been using Linux for years now, since an old Yggdrasil distro I picked up at some computer trade show, and a 8 CD set of crap they downloaded from a bunch of mirrors and stuck on some CDs. (Back in those days, those CDs were really handy, especially considering that most folks had a 14.4 connection. And that was considered fast ! Even 56k was far off! So that was a loooooooooooooooooooooooong time ago.)"

Neat little rant :-) I'm a user since '97. I just dabbeled in it. Now I run it as my main desktop of choice. Windows is my games desktop, as that seems to be its forte.

---"Anyway, I've since realized that Linux is too fragmented. There's way too much duplication of effort. The Linux file system "standard" is totally wrong, IMO, because everything's in the wrong place. (/home should be under /usr, for example.) And the configuration is a nightmare! There are literally hundreds of configuration files strewn all over the system!"

I dont agree with that... You live in a home, so /home it is. If you have problems with .conf's everywhere (like I did), just cp the files to /etc and sym-link to the original location. Now ALL your configs are in 1 place. Now you can back up your /etc dir (and sym links across your whole FS).

---"So I since moved on to FreeBSD. All ya'll Linux folks out there can learn a shitload of great stuff from the BSD folks. Just look at how much of the system configuration for a FreeBSD system is in a single file (rc.conf). In Linux, this would be scattered across 10,000 different files in a monster directory structure under /etc/rc or something like that, as far as I remember."

I absolutely love the run-level structure. You have 1 script for each runlevel, along with some scripts for large program init's. YOu have a rc.modules, which you can update for newer hardware. My opinion, I love the RC setups.

---"As you can easily tell, I haven't touched a Linux system in ages, and there's a reason. That's why I say this desktop thing needs to be made. Linux can kick Windows' ass in server stuff. Now it needs to start kicking Windows' ass in the desktop, because only when Microsoft loses that battle, they'll no longer be able to embrace and extend, a practice that fscks up all our code because we have to be compatible with their bugs,"

Who says so? I would fully support a addon in Samba that would allow extra features (embrace and extend) than what Windows normally has. Then make a client for WIndows that can take advantage of these extra features. However, the whole idea is to make Linux seamless with windows clients/servers.

---"flawed design decisions, and programming features probably designed by lawyers and marketeers rather than programmers. Ooooooooooh well. Oh yeah, I had all kinds of Negra Modelo last night. It was fun. (If Cerveceria Modelo made software, their operating system would kick everyone's ass!)"

Oh well. Fun rant :-)

If you are using Ogle, you can skip anything. It ignores the idiotic DVD button restrictions, and it supports DVD menus.

Blimey that certainly does sound like it was a whole lot of hastle. However, I would argue that if you are willing to compile from source you should expect to be in for a rough time. Because there are so many parts to it (this library that library this compiler etc), it's just more likely to go wrong...

If you want the easy life then wait until your distro brings out a packaged version of the DVD players. I myself fought with hand compilation until I found that Mandrake packaged Xine themselves and I just installed the RPMs. I can't stand the interface but things did work. The Debian guy downstairs also seemed to have things go quite smoothly with Ogle...

I guess the moral is that if your distro is old then getting new things to work with it is going to be difficult. That's the time to sit back and wait for the next update to be released with what you need packaged in it, unless you want to upgrade half your installation by hand. If that's what you want to do - good luck. You might need it.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. [...] So what is the solution?

Of course, there is no magic bullet to make software suck less, but I would strongly encourage all developers to at least look at what FP offers.

This article does a terrible job of representing Ben Shneiderman's objections to Hal-like interfaces. The article focuses only the verbal memory issue.

But, Ben has been objecting to Hal-like interfaces for 20 years. He is a well-known computer science critic of artifical intelligence and intelligent agents. He specifically objects to making voice more practical by making the computer more intelligent. Just think of normal human conversation and the number of errors and corrections and hmms and ahs and redundancy elements. Verbal communication is rife with the potential for error, and add that to powerful, independent, software agents and you could have chaos. Ben doesn't want computers to be "clever secretaries" that take "initiative" on our behalf.

All the posts I've seen on this thread focus on the content of this one Washington Post article and are not written with knowledge of his extensive writings on the possibility and ethics of intelligent computer agents.

Here is one way of putting his fundamental objection. Would you rather have:

a) A surgeon working on your heart with his/her own hands?
or
b) A surgeon using a microphone to direct a robotic knife with only auditory feedback?

Even if the latter were programmed to "know" certain surgical tasks, isn't there a sense of a weak, indirection interaction with the device through voice? Wouldn't you feel better if the surgeon were more directly, visually connected to the system?

Ben's point has always been that direct, visual interfaction with objects (what he calls direct manipulation) will be safer and more efficient than a voice system, and that making the voice system smarter is not a solution to the problem.

Ben has debated this point in many forums. This spring he debated this at the AAAS (American Association for the Advancement of Science) conference with Jim Hendler, an AI prof at the University of Maryland. When I was a graduate student there years ago you could count on Ben to tweak the pure AI types as to the ethics and reliability of their work. A 1997 debate with Pattie Maes of MIT is easy to find online and is in PDF format. Try
CHI97 debate home
debate in PDF

Don't take this Washington Post article as anything but what it is, an extremely superficial summary of a complex position. There's lots more to read on this. In the long run, Ben's objections may be left in the dust, but for the moment he serves an important role by critically evaluating AI claims and predictions.

Elvis, which is the predecessor of Priscilla and the first and most famous robot from the lab was built by two friends of mine.

Marcus and Manne

Somehow, seeing Priscilla rip off her jersey at the end of a match just won't be the same as seeing Brandi Chastain do it.

On the other hand, Priscilla could play the part of "Ally McBeal" if they ever revive that series...

Here are some pictures of Priscilla. That robot is scary looking. I wouldn't want to meet it (her?) on a soccer field or anywhere else.

Robots should be cute. Otherwise they remind us of the whole taking-over-the-world scenario.

For DVDs on linux, the only real solution is ogle. It simply kicks ass, and offers a combination of perfect menu support, good speed, and a decent GTK interface.

Check it out

I don't understand why, if they get tax-exempt status as a religion, do their "trade secrets" qualify for protection under the DCMA. The DCMA should not apply to them if they're a religion, and not a business.

I own both a DVD-RAM and a DVD+RW (a Philips DVDRW208, the exact model as the second drive in the review), and use them primarily for data storage. This rant starts with some DVD-RAM history and moves on to the DVD+RW, so if you're only interested in the latter, skip down a ways.

I got the DVD-RAM some years back, with the intent of using it as a shared data medium between a Windows machine and a Linux machine (running kernel 2.2.5 or so, IIRC). At that time, I had been using a PD (Phase Dual, the DVD-RAM precursor), and since the DVD-RAM dirve I was interested in (a SCSI Panasonic LF-D101) also had support for PD cartridges, it was a natural step up. It worked pretty much exactly as advertised, except that at one point, I reformatted one of the discs (with FAT32) in such a way that for some reason Linux was never able to mount it again, though Windows had no problem with it. Reformatting it from one OS or the other resulted in the opposing OS being unable to read it, so I eventually formatted it ext2fs and used it to make direct backups that didn't require tar to keep permissions and such. It was slow, and it was a little clunky, but it got the job done pretty well.

A short while ago, I upgraded the kernel on that particular Linux machine to 2.4.18, and got a bit of a surprise -- it was no longer possible to reformat the discs, although they did mount rw and I was able to manipulate the data. Well, I had been looking at DVD+RW for some time, had eventually decided on the Philips model as the best of the bunch, and when I saw it for sale online, I ordered it.

Okay, the people interested in DVD+RW stuff can start reading again

The DVD+RW dropped into the new (dual boot Windows 98/Linux 2.4.19-pre2) system quite nicely, although I do recall from reading other people's experiences that it much preferred being the slave drive on an IDE chain. This suited me fine, as I already had an IDE DVD-ROM (AOpen 1640 Pro-A, with 3rd-party RPC-1 firmware) in the system. Installing the drivers on the Windows side was a multiple pass process, as the packet writer initially refused to work with the DVD+RW media supplied with the drive (more on this below). Also a test burn I was making with Nero crashed the machine about halfway through, so I'm not overy enchanted with the quality of the Windows drivers. Nothing new there. On the Linux side, I passed hdc=ide-scsi and hdd=ide-scsi to the kernel to make both drives accessable from the SCSI subsystems, and started compiling the software at the DVD+RW for Linux page. I also tested a CD-RW burn with XCDRoast, which worked just fine, although the speed got locked at 4x, and I'm not entirely sure why (the drive itself should support 10x CD-RW burning).

Writing to the DVD+RW media under Linux has to pretty much be done exclusively with growisofs. There's a kernel patch available that is supposed to enable packet writing for the device, but I was unable to get it to work. The result is data that can be written to the disc and read pretty much on any DVD-ROM that can handle standard ISO9660 data and read the DVD+RW media at all (fortunately, most of them can). Unfortunately, writing this way reduces much of the functionality of the DVD+RW to that of a very fast DVD-RW -- you have to erase all the data to erase one file, though fortunately growisofs can trivially add data. Ideally, someone will write a working packet writing driver for Linux, fix the UDF driver (more on this below) and get those patches included in the 2.5 series. Until then, however, I'll just have to make do. Fortunately, the drive is so damn fast , that I don't mind writing things in large chunks.

Bolstered by my success writing under Linux, I went back to Windows to check on the readability. Windows was able to read the disc just fine, though due to the limitations of the Joliet CD extension, filenames were restricted to 64 characters if I wanted them to show up correctly in Windows (RockRidge fortunately has no such restriction, but Windows doesn't support it). To my delight, the InCD Packet Writing driver suddenly started working as well (I suspect it simply needed something to have been written to the disc once). I activated it, reformatted the DVD+RW disc as UDF, and tried dragging and dropping a few files onto it. Worked like a charm, and no speed drop as far as I could tell. So I booted back to Linux to see how well Linux could deal with it.

Well, the disc mounted. Files were retrievable. Unfortunately, the uid and gid of all the files was set to 4294967295. Remounting it with -o gid=1000,uid=1000 got relatively sane values, though it would have been nice to have the driver automatically set the ownership to either root or nobody by default. Unfortunately, the disc was still detected as write-protected by the kernel, so it was impossible to test writing to the disc. Still, I'm not entirely disappointed. I can write to it in chunks from Linux and have it read by either Linux or Windows, and drag-and-drop to it from Windows and have it read in either Windows or Linux, and that's good enough for my purposes.

I own both a DVD-RAM and a DVD+RW (a Philips DVDRW208, the exact model as the second drive in the review), and use them primarily for data storage. This rant starts with some DVD-RAM history and moves on to the DVD+RW, so if you're only interested in the latter, skip down a ways.

I got the DVD-RAM some years back, with the intent of using it as a shared data medium between a Windows machine and a Linux machine (running kernel 2.2.5 or so, IIRC). At that time, I had been using a PD (Phase Dual, the DVD-RAM precursor), and since the DVD-RAM dirve I was interested in (a SCSI Panasonic LF-D101) also had support for PD cartridges, it was a natural step up. It worked pretty much exactly as advertised, except that at one point, I reformatted one of the discs (with FAT32) in such a way that for some reason Linux was never able to mount it again, though Windows had no problem with it. Reformatting it from one OS or the other resulted in the opposing OS being unable to read it, so I eventually formatted it ext2fs and used it to make direct backups that didn't require tar to keep permissions and such. It was slow, and it was a little clunky, but it got the job done pretty well.

A short while ago, I upgraded the kernel on that particular Linux machine to 2.4.18, and got a bit of a surprise -- it was no longer possible to reformat the discs, although they did mount rw and I was able to manipulate the data. Well, I had been looking at DVD+RW for some time, had eventually decided on the Philips model as the best of the bunch, and when I saw it for sale online, I ordered it.

Okay, the people interested in DVD+RW stuff can start reading again

The DVD+RW dropped into the new (dual boot Windows 98/Linux 2.4.19-pre2) system quite nicely, although I do recall from reading other people's experiences that it much preferred being the slave drive on an IDE chain. This suited me fine, as I already had an IDE DVD-ROM (AOpen 1640 Pro-A, with 3rd-party RPC-1 firmware) in the system. Installing the drivers on the Windows side was a multiple pass process, as the packet writer initially refused to work with the DVD+RW media supplied with the drive (more on this below). Also a test burn I was making with Nero crashed the machine about halfway through, so I'm not overy enchanted with the quality of the Windows drivers. Nothing new there. On the Linux side, I passed hdc=ide-scsi and hdd=ide-scsi to the kernel to make both drives accessable from the SCSI subsystems, and started compiling the software at the DVD+RW for Linux page. I also tested a CD-RW burn with XCDRoast, which worked just fine, although the speed got locked at 4x, and I'm not entirely sure why (the drive itself should support 10x CD-RW burning).

Writing to the DVD+RW media under Linux has to pretty much be done exclusively with growisofs. There's a kernel patch available that is supposed to enable packet writing for the device, but I was unable to get it to work. The result is data that can be written to the disc and read pretty much on any DVD-ROM that can handle standard ISO9660 data and read the DVD+RW media at all (fortunately, most of them can). Unfortunately, writing this way reduces much of the functionality of the DVD+RW to that of a very fast DVD-RW -- you have to erase all the data to erase one file, though fortunately growisofs can trivially add data. Ideally, someone will write a working packet writing driver for Linux, fix the UDF driver (more on this below) and get those patches included in the 2.5 series. Until then, however, I'll just have to make do. Fortunately, the drive is so damn fast , that I don't mind writing things in large chunks.

Bolstered by my success writing under Linux, I went back to Windows to check on the readability. Windows was able to read the disc just fine, though due to the limitations of the Joliet CD extension, filenames were restricted to 64 characters if I wanted them to show up correctly in Windows (RockRidge fortunately has no such restriction, but Windows doesn't support it). To my delight, the InCD Packet Writing driver suddenly started working as well (I suspect it simply needed something to have been written to the disc once). I activated it, reformatted the DVD+RW disc as UDF, and tried dragging and dropping a few files onto it. Worked like a charm, and no speed drop as far as I could tell. So I booted back to Linux to see how well Linux could deal with it.

Well, the disc mounted. Files were retrievable. Unfortunately, the uid and gid of all the files was set to 4294967295. Remounting it with -o gid=1000,uid=1000 got relatively sane values, though it would have been nice to have the driver automatically set the ownership to either root or nobody by default. Unfortunately, the disc was still detected as write-protected by the kernel, so it was impossible to test writing to the disc. Still, I'm not entirely disappointed. I can write to it in chunks from Linux and have it read by either Linux or Windows, and drag-and-drop to it from Windows and have it read in either Windows or Linux, and that's good enough for my purposes.

Hmm, kinda. The parts are there, but no-one has put them together in a neat package yet. That's probably since Linux video software has really taken off in just the last 6 months.

There's mplayer which is a great player for any video-format out there. It can even play DVD's, although it doesn't have menu support like Ogle. It can also rip DVD:s to MPEG-4 (a.k.a DivX) using a couple of different encoders. Xvid is my favorite open-source MPEG-4 encoder, it's also got good reviews on Doom9 (good place for DivX info!).

For the TV-in recording part you can use a $50 WinTV card and the Video4Linux drivers. On top of that you need an audio-video capture application that can use encoders such as Xvid and Lame to encode to MPEG-4 (video) and MP3 (audio). I use NVrec. If you try the NVrec suite, use the DIVX4rec app (with the Xvid library instead of divx4linux which isn't maintained anymore). On my P-III 500MHz I can compress 29.97 Hz (NTSC) 320x240 in real-time to 800 kbit/s (video) + 80 kbit/s (audio). It takes about 5 hours to make a one-pass encoding of a DVD, so with a faster CPU it's probably possible to do real-time de-interlacing and encoding of 640x480 video.

A drawback is that NVrec is a command-line app for recording, I'm working on a patch for real-time preview on Matrox G400 TV-out. Or if you have a fast enough computer you might be able to run mplayer on the file as it is being recorded. This would allow for Tivo-like pause and resume. It might be a problem with AVI files from NVrec though since I don't think they're streamable.

Now, to put all of this together you need some kind of control application. That's not really that hard to write compared to all the other pieces (mplayer, xvid, nvrec). I've been working on one for the last couple of months, and have an alpha version that is usuable. It only supports the Matrox G400 for TV-out, and is a little crude, but it works good enough that I have it hooked up to my TV for everyday use. It's controllable by a remote control (see Lirc), using a very simple text-menu system to view tv, play avi/mpeg/mp3/dvd, record tv-in and rip DVD's. I'm getting ready to put it up on Sourceforge as Freevo within the next couple of weeks.

The application is written in Python which is great for stuff like this. Once the basic stuff is done, it might be cool to make a plugin architecture where you could interface to other stuff. For instance, with OSD (on screen display), it is easy to add things like new mail notification while you're watching TV. Or new Slashdot headlines, ICQ chat notif, phone caller ID interface, www control, etc. And, of course, an interface to some kind of tv-guide.

I haven't really found any other complete applications like this. Not that I've looked that hard, I'm always looking for an excuse to write software. mplayer might end up with all these feaures eventually, it is improving at an incredible rate at the moment.

It depends a lot on the stage of development. For a mature product it's probably true that source availability is less valuable. There are fewer bugs to be caught, and they're probably deeper in the code and thus more difficult to catch anyway. In the Free Software world there are also likely to be just one or only a few projects around, making code sharing more difficult.

But in the early stages of a project, though, source availability can be tremendously useful. A good example of this that I'm personally familiar with is with Linux DVD players. Different projects have focused on different parts of the overall picture, and the availability of code from other projects has allowed a lot of borrowing between projects to shore up their strengths. The player I use, for instance, had a very good MPEG player but lacked good menu support or the ability to read encrypted disks. But they were able to build a menu system by taking the code for menus from one place and a decryption library from another. Source availability makes that kind of thing possible.

Okay, I apoligize for an extra long post here, but I still see people mischaracterizing functional programming. So I'm going to take a few excerpts from "Why Functional Programming Matters" by John Hughes. It's a short paper, worth your time if you're new to the functional paradigm.

No Side Effects:
Functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant - since no side-effect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa - that is, programs are "referentially transparent". This freedom helps make functional programs more tractable mathematically than their conventional counterparts.

Higher Order Functions:
Functional languages allow functions which are indivisible in conventional programming languages to be expressed as a combi-nation of parts - a general higher order function and some particular specialising functions. Once defined, such higher order functions allow many operations to be programmed very easily. Whenever a new datatype is defined higher order functions should be written for processing it. This makes manipulating the datatype easy, and also localises knowledge about the details of its represen-tation. The best analogy with conventional programming is with extensible languages - it is as though the programming language can be extended with new control structures whenever desired.

Lazy Evaluation:
A complete functional program is just a function from its input to its output. If f and g are such programs, then (g . f ) is a program which, when applied to its input, computes g (f input). The program f computes its output which is used as the input to program g. This might be implemented conventionally by storing the output from f in a temporary file. The problem with this is that the temporary file might occupy so much memory that it is impractical to glue the programs together in this way. Functional languages provide a solution to this problem. The two programs f and g are run together in strict synchronisation. F is only started once g tries to read some input, and only runs for long enough to deliver the output g is trying to read. Then f is suspended and g is run until it tries to read another input. As an added bonus, if g terminates without reading all of f 's output then f is aborted. F can even be a non-terminating program, producing an infinite amount of output, since it will be terminated forcibly as soon as g is finished. This allows termination conditions to be separated from loop bodies - a powerful modularisation. Since this method of evaluation runs f as little as possible, it is called "lazy evaluation". It makes it practical to modularise a program as a generator which constructs a large number of possible answers, and a selector which chooses the appropriate one. While some other systems allow programs to be run together in this manner, only functional languages use lazy evaluation uniformly for every function call, allowing any part of a program to be modularised in this way. Lazy evaluation is perhaps the most powerful tool for modularisation in the functional programmer's repertoire.

Why you might care:
Modularity is the key to successful programming. Languages which aim to improve productivity must support modular programming well. But new scope rules and mechanisms for separate compilation are not enough - modularity means more than modules. Our ability to decompose a problem into parts depends directly on our ability to glue solutions together. To assist modular programming, a language must provide good glue. Functional programming languages provide two new kinds of glue - higher-order functions and lazy evaluation. Using these glues one can modularise programs in new and exciting ways... Smaller and more general modules can be re-used more widely, easing subsequent programming. This explains why functional programs are so much smaller and easier to write than conventional ones. It also provides a target for functional programmers to aim at. If any part of a program is messy or complicated, the programmer should attempt to modularise it and to generalise the parts. He should expect to use higher-order functions and lazy evaluation as his tools for doing this.

See Why Functional Programming Matters by John Hughes.

Yes in AI they have been useful - LISP was made for this purpose actually. Although I do like Prolog a lot more.

Which, incidentally, is not a functional language at all, but one of the Declarative programming paradigm. However, it is possible to use it for functional programming.

And if you want menus with that, try Ogle. Works great for me.

how did you determine (and what are) the "commands" the section B lists ? .. did you disassemble the code ?

The DVD FAQ has details about the nature of the commands on DVDs. The commands that were on the Warner DVDs that I looked at did not do anything very exciting - it was stuff like setting the audio language to match the setting on the player.

Have you tried Xine or Ogle? Both of them work perfectly. Infact I am running older versions of both of them because I have seen no reason to update, they both do everything a DVD player needs to do (and in the case of Xine, a bit more).

I watch DVDs all the time and find it annoying that Linux doesn't have decent DVD playback. Hmmm maybe I should help write one...

I watch dvds on Linux with no problems. Make sure you have udma enabled on your HD(it improves the speed *a lot*):
#hdparm -d1 /dev/xxx

Do some fine tunning with -X option of hdparm too and use a good player (I use ogle ).

Currently, there are two versions of Lava in use. One, Chalmers-Lava, developed at Chalmers University of Technology in Sweden, is mainly aimed at interfacing to automatic formal hardware verification tools. The other, Xilinx-Lava, developed at Xilinx Inc., is aimed at generating configurations for Xilinx' FPGAs. We hope to merge these two version soon.

DVD+RW on Linux

Pioneer A03 (DVD-R) is supported using this patch for cdrecord
HP DVD+RW drive is supported using this patch .

For DVD+RW check this site For DVD-R(W), check this one: http://www.abcpages.com/~mache/cdrecord-dvd.html mache

Just because most people on a P2P network use it for piracy, it doesn't become a pirate-app. I can, and have, used programs that are under attack by the RIAA do download speeches, text documents, etc. At the early point of the 2000 Nader campaign, when he couldn't get 30 seconds of time on M$NBC (much less a place in the debates later on), I used Napster and Scour to find speeches he's given. And when the Department of Commerce kicked of it's 'Safe Harbor' privacy program by failing to put the confidential information provided by the companies involved on a secure site, I downloaded the pages in a zip file despite the site being closed for a fix. Using programs like Scour, I found reading material on scientology, COINTELPRO, and more, all the way up until the day that lawsuits shut them down.

Here you are :-)

A lot of people seems to be overlooking that this is not "just" GP. It is GP with a feedback loop unto itself. Now, the difficult thing with this is: How do you make a fitness-function that measures how good your program is at improving itself? This is a damn hard problem, which the page does not even try to explain. But since the notion of "Seed-AI", as Eliezer would call it, is so tantalizing, there are more and more people trying to accomplish it.

I have done some work on how to solve it, on the swedish University of Chalmers. An overview of how we think it can be solved, using some concepts from information theory (together with a small introduction to strong AI in general), can be found here.

Please mail me if you have any thoughts/comments regarding the text in the previous link.

Check out xtraceroute. It gives you a view of the globe (using OpenGL) and will attempt to locate a given IP and the route to that IP and plot it. It uses a list of know routers around the globe and simple rules similar to: If domain name contains .md. then its probably in Maryland...

Good cooling does not only allow overclocking. It also (and mainly) improves the life expectancy for the processor.

The probability of failure increases a lot with temperature, and the effect becomes notable at relatively low temperature values (50-60 C).

See for example http://www.dtek.chalmers.se/~kw/papers/thermal.pdf but there are certainly many other references.

I happen to think it's the cleanest programming language I've ever worked with. Functions are small, readable and when they work, they work. No strange cases where things don't work.

I've yet to encounter a bug in the program which I couldn't fix or understand what was wrong with after a few minutes of thinking. When functions are 1-5 lines long, bugs are not a problem any more...

However, for real-world development, being able to "cheat" when it's convenient, and mutate a value here and there, can be a real development timesaver. I find languages which don't let you do that to be less practical. Also, for those new to functional programming, starting out with a language that's a little less pure may make things a little easier, and avoid frustration.

So, do you have any thoughts on O'Haskell? When I first saw this, I thought it would take over the world. But, being an academic project, it's development has progressed at a leisurely, academic pace. Which is very unfortunate. oCaml may yet rule the space, as you suggest.

The "surprising angle" of the book you referenced is not all that surprising, except possibly to a total newbie.

Yes, but it was the newbies I was addressing, albeit obliquely. :-)

OK, so the joke wasn't that funny. In any case:

Graphical programs are a perfect application space for pure functional programming.

Absolutely, but the usual imperative style for this is for-loops galore and more assignment statements than you can shake a stick at.

Check out this link for more info. This one is from MIT (quite a bit old, but it's still interesting read). And then of course there is the Humanoid Project.

Ogle is not hassle free enough?
Check out their site.

MPLS totally sucks. It's the X.25 of the new millenia, just as ATM was the X.25 of the 90's. Why? It's a CIRCUIT SWITCH methodology on top of a PACKET SWITCHING network. Dumb! It's another thing to manage and break from a network engineering point of view. That, and most vendors implementations don't work worth a damn today.
[snip]

This would be enough for a person with an average education in MPLS to judge how much you (don't) know about MPLS. I am doing MPLS-oriented research for the last 1.5 years so let me try clearing some of the "bad air" around the issue:

1) MPLS is NOT circuit switching ON TOP of packet switching. If you would care to do some minimal reading before you flame a subject, you would find out that MPLS is not ISO layer >= 3 but it is a "layer 2.5" technology. In other words IP datagrams are carried on top of MPLS frames pretty much the way ATM worked.

2) The reasons behind MPLS are too complex to describe here (for the intrested reader, take a look at RFC3031). But basically it was acknowledged that despite ATM being "evil" circuit switched technology does offer some advantages. That's why you can (_very_ roughly) characterize MPLS as an "IP friendly ATM", minus some of ATM's design shortcomings (that were present there due to the technology limitations at that time and ATM's intended use).
But to rebute your misconception, MPLS is NOT about "routing IP datagrams fast", nor "replacing CIDR". Again, if you care to skim the mentioned RFC it is acknowledged that this _were_ some advantages few MPLS proponents claimed but this is simply not true, as you correctly state: Efficient algorithms for IP address lookup and routing are implemented in hardware by several vendors (incl. cisco, btw...) so MPLS doesn't have any edge there.

3) About "Traffic Engineering being a load of crap" I would say that few of the top 10 largest carriers in US might disagree a bit. Get a hold of an educated MCI network operations engineering (say MCI/UUNET) and ask how much improvement (and revenue) TE gives them. And yes, the reaction is "WOW".

And QoS... Same deal- load of crap.
4) Well, QoS is too broad a topic to disuss in any relevance here. But in saying that you automatically excluded _all_ mechanisms for traffic differentiation in a network. Enough said.

Also, to end this, MPLS is _not_ only about TE/QoS/IP fast switching. It is used for fast network restoration, it is extended for supporting WDM in a similar manner (see "Generalized"MPLS), etc. People w/ some network education might care to take a look here for a overall view on the MPLS-related topics.

All in all I would dare to say that your posting is the worst kind of mis-information:It contains a grain of truth and mixes completely different and unrelated subjects as "comparisons" (OPenGL w/ CIDR)

For the rest of the readers, the necessary grain of salt when reading the linked article: In IETF there is a lot of politics around MPLS (disguised in "technical debates") -- surprise,surprise. For example if someone cares to browse the MPLS mailing list archives Mr. Randy Bush long opposed BGP/MPLS VPNs (described initially in RFC2547.IIRC there is also draft updating it). Which happen to be a technology cisco pushes very hard and which Mr. Bush opposes violently.
What particular agenda Mr. Bellovin has escapes me. But I assume (again, this is _speculation_) since AT&T made a _huge_ investment in ATM in the past do not see MPLS (which is simply a better competening technology) so favorably.

All in all, remember that the most competent answer is "I don't know.It depends".


My $0.02
Florian-Daniel Otel
http://www.ce.chalmers.se/staff/otel

You should look at the source for Xtraceroute, a program which plots the location of "hops" in a traceroute on a 3-D globe. Once you mix it with this innovative, free (as in speech!) GIS solution, you should be able to realize the power of Open Source.

OK, so when this is slashdotted, here is a list of mirrors for all you downloaders out there! Linux-Mandrake 8.0 release candidate mirrors for i586 processors.

Austria, France, Germany , Sweden

--

Yes, we here in Sweden are probably going to fold under pressure. But atleast we made a good stand.
Some years ago, there was a lot of turbulence when Zenon Panoussis was in court with the Church of Scientology (Actually a real interresting read). Using a law here in Sweden: offentlighets principen, he handed in the texts. An action that resulted in that the text went accessible to everyone.

After realizing this CoS's laywers tried to make a change in our Grundlag (I.e think constitution). A laywer with that attitude, is very hard to stop, and is bound to have a lot of resources. But if the Netherlands can make a stand for it... then I will be proud of you.

Why not celebrate Pi approximation day instead? It's on an easier to remember day: 22/7.

The guy who runs that page, Martin Rebas, offers other number treats, including the -2 club for people who can't even remember 2 digits of pi.

Why not celebrate Pi approximation day instead? It's on an easier to remember day: 22/7.

The guy who runs that page, Martin Rebas, offers other number treats, including the -2 club for people who can't even remember 2 digits of pi.

Why not celebrate Pi approximation day instead? It's on an easier to remember day: 22/7.

The guy who runs that page, Martin Rebas, offers other number treats, including the -2 club for people who can't even remember 2 digits of pi.

I made no such claim of perfection - you read that into my post.

My apologies then.

I agree with you to some extent that the US constitution has probably influenced other constitutions. But the US constitution in turn was clearly inspired by other constitutions as well. Many good constitutions are significantly older. While not all of them (and associated laws) included what we today consider basic rights from the start, they laid the groundwork. And modern democracy is really quite young, in any nation. For example, many modern nations did not have universal suffrage until well into the 20th century. (1921 in Sweden and 1947 in the US.)

The Swedish constitutions or "grundlagar" (they are actually four) date back to the 14th century, and many basic principles of democracy have been part of those constitutions for hundreds of years. Two examples are the freedom of press (prohibition of censorship, etc) and offentlighetsprincipen that were both made part of the constitutions of Sweden in 1766, ie 22 years before the US constitution was drafted. The offentlighetsprincip deserves special attention, since it probably has nothing quite comparable in other constitutions except the Finnish. It guarantees access to most documents and communication at courts, govermental agencies and institutions.

That principle was reason for a dispute with the US Congress a few years ago (acting on behalf of lobby groups with no real national interest in the issue) when Swedish authorities published the Bible of Scientology and made copies available to anyone in the world. It all began after a citizen began sending the Bible to parliament, courts and other institutions. Letters of protest sent by a US congressman and a US commerce agency spokesman also became public, much to their surprise and dismay. All these texts automatically became public according to the constitution, there was no way around it. The principle has been the cause of many politicians' fall, since the media routinely browse new documents and find out things they otherwise would not have.

For more info about the Swedish constitution:
ICL - Swedish Constitution
The Finnish-Swedish Offentlighetsprincipen (s.c.nordic FAQ-related texts)

For more (but partly outdated) information about the very fascinating Scientology case in Sweden, these sites are recommended:

Failed US pressure on Sweden
Zenon vs CoS - the A.R.S. Posts
Operation Clamblake: Zenon Panoussis vs. Cult of Scientology

Moving on to the federal constitution of Switzerland, it is admittedly significantly younger (from 1848, although its democratic traditions are quite old and direct democracy has been an integral part of the country's history for some time. In my opinion, the Swiss constitution is the best overall, despite that the democracy comes with a price: slow decision making.

If anyone wants more info about the Swiss constitution, I whole-heartedly recommend the book "The Referendum - Direct Democracy in Switzerland" by US political scientist, professor Kris Kobach. The following URL can also be useful:

Global Ideas Bank - Exporting the Swiss constitution
ICL - Swiss Constitution

In 1960, Joe Kittinger went up in a helium balloon. This man is sometimes regarded as the first man in space, although he just went 20 miles up (outside the atmosphere, anyway).

A recent BBC documentary showed a film from this event, as the guy was smart enough to bring a film camera ;-)

Read more at http://fy.chalmers.se/~f3aamp/teaching/np/balloon. html and http://www2.tsixroads.com/corinth/jk016.html.

Look, folks, object orientation is just one tool of many in the big box of software tools. Use it when appropriate, use something else when it isn't. This guy rants rants about OOP basically on three grounds, all of which are straw-man agruments:

1. OOP doesn't live up to the hype of its most zealous proponents (What does?)
2. When you do stupid things with OOP, you get stupid results. (What did you expect?)
3. Contrived, obviously-false statements about OOP are not true. Examples taken from the document: "Myth: Only OOP has automatic garbage collection", "Myth: Only OO databases can store large, multimedia data", "Myth: Components can only be built with OOP", and so on. These aren't legitimate myths widely believed by folks who use OOP; these are straw men propped up so that he could knock them down.

The reality is that OOP is a good tool for solving a lot of common problems. It's also a lousy tool for solving a lot of other common problems. When OOP isn't the right tool, don't use it.

Just use the right tool to begin with. When it comes to programming paradigms, there are lots of tools in box:

• rule based
• procedural
• functional
• object oriented
• logic based
• contstraint based
• declarative (often in terms of w/ functional and logic based)

Use the right tool for the job. You'll be glad you did. (And you won't have to put up a web site just to rant about your bad experiences with using a hammer to place dry-wall screws.)

Look, folks, object orientation is just one tool of many in the big box of software tools. Use it when appropriate, use something else when it isn't. This guy rants rants about OOP basically on three grounds, all of which are straw-man agruments:

1. OOP doesn't live up to the hype of its most zealous proponents (What does?)
2. When you do stupid things with OOP, you get stupid results. (What did you expect?)
3. Contrived, obviously-false statements about OOP are not true. Examples taken from the document: "Myth: Only OOP has automatic garbage collection", "Myth: Only OO databases can store large, multimedia data", "Myth: Components can only be built with OOP", and so on. These aren't legitimate myths widely believed by folks who use OOP; these are straw men propped up so that he could knock them down.

The reality is that OOP is a good tool for solving a lot of common problems. It's also a lousy tool for solving a lot of other common problems. When OOP isn't the right tool, don't use it.

Just use the right tool to begin with. When it comes to programming paradigms, there are lots of tools in box:

• rule based
• procedural
• functional
• object oriented
• logic based
• contstraint based
• declarative (often in terms of w/ functional and logic based)

Use the right tool for the job. You'll be glad you did. (And you won't have to put up a web site just to rant about your bad experiences with using a hammer to place dry-wall screws.)