Slashdot Mirror

Back in 2000, CMU switched to IMAP and started reccommending Mulberry as the standard mail client. I was pretty surprised by this. CMU had previously used open-source or locally developed software. Some of the locally-developed software was pretty quirky and hard to support, but they had generally been trying to make it open source or switch to open source. (For example they switched from AMS to IMAP, and were working on switching from AFS to CODA.) So I was pretty surprised when they started reccommending a closed source mail client. I remember thinking, "A closed-source, third party app? I wonder how long that's going to last..." Today I got the answer - It lasted about 5 years.

Shortly after they started using Mulberry, they started using some other closed-source third-party service called Blackboard. I wonder how long that's going to last...

You know what that means, boy? A Basselope gap!

You're missing the Link Grammar Parser:

http://www.link.cs.cmu.edu/link/

There's the Link-grammar parser, which can do grammar checking. It is being used by Abiword (2.3/2.4).

http://www.link.cs.cmu.edu/link/

Hi everyone, AbiWord-2.4, due any day now, will come with an integrated version of open-source grammar checker link-grammar. You download a beta version now. As usual it is available for Linux, Macs and Windows.

Generally agreed, but once you have your BSCS (i.e. already have the theoretical underpinning), and are a working professional in the industry, going for an MS in CIS, or, even better, SE, over an MSCS might be better. I've looked at the local universities' CS grad programs, and being 12 years out of school, I'd have to go back and re-learn a lot of the theory stuff, like the mathematics behind SQL, which just isn't relevant to me (never really was, actually). I wish there was a good MSSE program near me, maybe something like this (no language courses in there).

Dan's point isn't that CS is not useful, just that CS degrees don't cover everything that is really required to be a true software engineer. I don't think that he's making an argument for CIS or "vocational" programmers, we all know what road that leads down. I have my BS in CS and my masters from Carnegie Mellon in Software Engineering and I think that it is combination of the two that really qualifies me to be a good developer.

The fundamental problem with CS degrees is that there is ZERO focus on the business aspects of softare: management, design, process, etc. They teach the (very very important) fundamentals of programming languages, computer theory, etc. but they don't teach process, or give any sort of business sense. Students don't learn anything about development lifecycles or software architectures. This means that the average CS graduate is only suited for the build phase of development, often times, they don't have any realization that there is any other phase!

The solution for this is not to add vocational training to CS curricula but to add courses in software design (architectures/patterns/uml), software processes/lifecycles (waterfall, spiral model, evolutionary dev., CMM, ISO-9001), and software project management (business tradeoffs of software, business reasoning).

These courses should be in addition to the fundamental courses in operating systems, computer architectures, data structures, programming languages.
The addition of this sort of coursework would provide the foundation required for CS students to enter the workforce as Software Engineers capable of working on all phases of software development projects.

Dan's point isn't that CS is not useful, just that CS degrees don't cover everything that is really required to be a true software engineer. I don't think that he's making an argument for CIS or "vocational" programmers, we all know what road that leads down. I have my BS in CS and my masters from Carnegie Mellon in Software Engineering and I think that it is combination of the two that really qualifies me to be a good developer.

The fundamental problem with CS degrees is that there is ZERO focus on the business aspects of softare: management, design, process, etc. They teach the (very very important) fundamentals of programming languages, computer theory, etc. but they don't teach process, or give any sort of business sense. Students don't learn anything about development lifecycles or software architectures. This means that the average CS graduate is only suited for the build phase of development, often times, they don't have any realization that there is any other phase!

The solution for this is not to add vocational training to CS curricula but to add courses in software design (architectures/patterns/uml), software processes/lifecycles (waterfall, spiral model, evolutionary dev., CMM, ISO-9001), and software project management (business tradeoffs of software, business reasoning).

These courses should be in addition to the fundamental courses in operating systems, computer architectures, data structures, programming languages.
The addition of this sort of coursework would provide the foundation required for CS students to enter the workforce as Software Engineers capable of working on all phases of software development projects.

I would seriously look at Cyrus (http://asg.web.cmu.edu/cyrus/), which is designed to be scalable for huge numbers of email accounts. And the email users don't have to have accounts on the Unix boxes. It stores the messages in the file system but sets up index databases so that accessing the mailboxes is fast. It can also handle single-instance storage of the messages sent to multiple mailboxes.

Please point to a mail system that actually uses the file system to hard link 1000 emails like the grandparent proposed.

http://asg.web.cmu.edu/cyrus/download/imapd/overvi ew.html#singleinstance
http://doc.powerdns.com/powermail/indepth.html#AEN 824

For example, the Cyrus IMAP server supports single instance store using file system storage (Maildir-style IIRC). You don't need a database to do it.

Incidentally, this is how the Cyrus mail server implements its single instance store.

I did some investigating on expandable mail systems and the only one I found was cyrus' murder project, http://asg.web.cmu.edu/cyrus/ , and so far it's worked quite well for me. The campus supports 10's of thousands of users. I don't know of any reason why it could not be expanded to hundreds of thousands and beyond. It supports high availability and is quite fast. Also, unlike other servers it allows a single namespace, so no imap1.domain.com, imap2.domain.com, everyone is just imap.domain.com. Check it out.

Cyrus IMAP is designed for this size of installation. You can split the backends up with Murder on the front-ends to distribute load; divide mailboxes on each host between filesystems (which, you'd presumably spread over multiple disks); use a SAN and GFS or other shared-storage cluster filesystems and share the spool among servers; use the new pre-release 2.3 code with mailbox replication and use more discrete, commodity components. Lots of other features that are designed for large-scale implementations.

For authentication, of course you have choices among LDAP, Kerberos (both of which are usable even if you're stuck with a Windows domain for authentication), PAM and other things. Very flexible; too flexible for some and it can be a bit confusing.

I've been working on rewriting the HOWTO, although I haven't made a ton of progress, it may still be useful to you: http://nakedape.cc/info/Cyrus-IMAP-HOWTO and here's a presentation I put together for Linuxfest Northwest: http://nakedape.cc/info/Cyrus-IMAP-Intro.

You mention a million mailboxes, but that doesn't really mean much--that is just an estimate of storage requirements. What is more important to determine is how many concurrent users you will have and how much actual traffic--storage is cheap, memory not so much.

Though I must admit, I thought the PSP http://www.sei.cmu.edu/tsp/psp.html would not appeal to such a large audience

One name: Lenna.

Not only are image viewers developed for Porn, Porn is a standard part of the development process of image technologies, and has been since the very beginning.

Your example seems pretty easy to resolve. Compare http://en.wikipedia.org/wiki/Fruit_flies and http://en.wikipedia.org/wiki/Time_flies. It would be trivial to include a dictionary of this size and match on a "largest phrase" basis. You could in theory even build the dictionary automagically with a large enough corpus, by simply recognizing the number of times the two words appear together.

Of course, for the record, CMU's parser fails on this one. I thought for sure they'd pass, but apparently they don't have "fruit flies" in their dictionary.

FWIW, you didn't realize CMMI is based on CMM. Try reading the Carnegie Mellon link here.

• The CMMI classes i attended were by no means comprehensive.
• CMMI has been updated since i took the classes.
• There are several CMMI models, each with their own purpose.
• I am naturally predisposed against CMMI.

NASA has been using a version of realtime UNIX called VxWorks from Wind River in many of its space probes and robots. It has been evolving for decades along with various NASA probes. Its not perfect, having brought down the rovers for a couple weeks with a thread blocking problem. But it has been field tested for a long time.

It's first going to come in through the highway system, in special lanes, like when they trialed on I-15 in 1997. There's nothing for intra-city commuters for a while; That's just not technically feasible right now.

It doesn't require every single car to participate. In trials, they are probably going to use special lanes. Second, the cars have light sensors, for detecting cars around them that don't play along with the system. My guess is that eventually, after 0 (zero) controlled-car accidents (outside of crackers) it will become required to participate in the electronic transport system: Human casualities will be just way to high, and human drivers will not be trusted.

The predicitions by AHS experts that I've seen say that the first generation will roll out around 2015, and work over the wireless infrastructure that is now being sold to consumers as "Internet, computers, and toys, in the car!" The second generation is predicted and planned to roll out around 2025, and extend the system to urban core.

When people get used to doing stuff in their car other than driving, they'll quickly forget the romance of driving, just as they forget the romance of "actually seeing the other person" at the gas pump (unless you're in Oregon) or the bank teller at the ATM.

http://www.ece.cmu.edu/seminar/archives.php

Search the page for a talk by "Vivek Subramanian" (sic) entitled "Electronics Everywhere: Organic Circuits On Plastic, Paper And Even Cloth!"

More on the hardcore low-level end of things where he talks about the transistor-level construction, current limitations and ways to get the costs down to fractions of a cent per unit.

The NSA/NCSC has created classifications for trusted-OS classifications, this is quite different from standard government security levels (classified, secret, top secret, etc) - You can learn more about them at CSU

These are only for the OS itself - any other hardware and software must be approved as well for true secure system. I'd recommend the submitter take a closer look into exactly how secure the system must be.

I agree with your comments but I think it's highly dependant upon how secure the system needs to be. Find it very unlikely it will be running a trusted OS(classification A, B, or C) since it will be doing CAD work - I'm not familiar with Solidworks or OrCAD but I'm willing to guess they run on Windows... which is far from a trusted OS environment as we all know. However to give MS credit, do recall a professor who was a former NSA employee stating that a version of Windows NT achieved a C2 trusted rating.

I've been looking for a decent version of something like this for ages. I've previously investigated Agent Frank, WebMate, IProxy, and I've used WBI. All seem lacking in some way.
PPS looks promising. I'd like to see the search functionality of PPS integrated into the proxy so you can do a search right from the browser and it can show you live links......

I just add a bit on that list from top of my head.
Although I think the listed app goes beyond what the so called 'average pc user' wants, but there goes...

1. Konqueror ( http://www.konqueror.org/ )

2. Email - Sylpheed ( http://sylpheed.good-day.net/ )

3. I think Evolution is more like in this place.

4. Lately "Sound Juicer" is taking more attention too

5. VideoLAN aka VLC ( http://www.videolan.org/ ) and Ogle ( http://www.dtek.chalmers.se/groups/dvd/ ) [and Goggles ( http://www.fifthplanet.net/goggles.html ) for Ogle GUI wrapper] for DVD watching.

6. There are plenty way to do this, but the typical ones could be 'Jinzora' ( http://www.jinzora.org/ ) and 'MusicPD' ( http://www.mpd.org/ ), even plain Apache does it fine too, in a way.

8. If you want easier to manage iptables wrapper, Shorewall ( http://www.shorewall.net/ ) and there are other wrappers too.

9. KOffice ( http://www.koffice.org/ ) and by individual components, Abiword ( http://www.abisource.com/ ), Gnumeric ( http://www.gnome.org/projects/gnumeric/ ), Gnucash ( http://www.gnucash.org/ )

10. Inkscape ( http://www.inkscape.org/ ) or Sodipodi ( http://www.sodipodi.com/ ) for vector graphics.

11. Miranda ( http://miranda-im.org/ ). Windows only.

13. Hmm , Samba? ( http://www.samba.org/ ), WedDAV (Look parent post), FTP (plenty ftp daemons, ex : http://www.proftpd.org/, http://vsftpd.beasts.org/ etc)

16. GPhoto ( http://www.gphoto.org/ ), EOG ( http://www.gnome.org/ ? ), GQView ( http://gqview.sourceforge.net/ ). The latters are for just viewing mainly.

20. FreeNX ( http://www.nomachine.com/ , http://freenx.berlios.de/ ) http://www.poptop.org/ ), L2TPd ( http://sourceforge.net/projects/l2tpd ), RP-L2TPd ( http://sourceforge.net/projects/rp-l2tp/ )

24. Postfix ( http://www.postfix.org/ ), Sendmail ( http://www.sendmail.org/ ), Exim ( http://www.exim.org/ ), Cyrus ( http://asg.web.cmu.edu/cyrus/imapd/ ), Xmail ( http://www.xmailserver.org/ ), qmail ( http://www.qmail.org/ )

25. Spamassassin ( http://spamassassin.apache.org/ )

26. Same as above.

27. XSane ( http://www.xsane.org/ ) for sane frontends.

30. Buzzmachines ( http://www.buzzmachines.com/ ) I could be wrong...

31. 'various GUI frontends' - X CD Roast ( http://www.xcdroast.org/ ), K3B ( http://k3b.sourceforge.net/ )

32. Don't know any opensource ones...

You've never heard of ISO 8601?

When I first wrote an RSS generator, I was gutted to discover that the specification wanted RFC822 dates -- and the parser I was testing on required this.

It looks as if ISO8601 has won out though -- if I pick an arbitrary feed I see ISO8601 dates. Has the spec changed?

(for the puzzled, RFC822 is "Sat, 06 Jan 2000 12:00:00 GMT" -- hassle to build, hassle to machine-read. ISO8601 is "2000-01-06T12:00:00" -- much better.)

some russians and germans did it

How soon before someone embeds DeCSS or OT III in an image?

About -2 years, I say.

For computer graphics class , Dave Swanson, the Director of Madden, gave us a lecture about the "process" of making a new Madden game. I decided to joke around and ask him "Why do you need to do anything? Don't you have a monopoly?". He replied saying that he actually still works as hard as he did before the monopoly; and that his current aim is to get people who were not intrested in the Madden series before-hand into the game.
He also said that all the stories in the press are mostly an exaggeration of what is really going on.

Seriously, perl can be complicated, as there's a lot to learn...

Last year I dug a couple of months into Scheme and Common Lisp.

I could apply all the ideas that were in those languages in Perl.

If you have a look at CL2, then you will find that a whole lot of the things that are explained there can be implemented in Perl.

So, I think that learning Perl is not a matter of complexity from the language, but from the features that you can use. You can start real simple, using Perl for simple scripting, but you can grow with Perl for complex classes and applications.

I even did complex macro's in Perl. You need to write your macro code as a string, which needs then to be eval'ed at run-time. Nice feature to implement class templates.

The only thing that really sucks is the dereferencing and the curly brackets. I take COBOL (or even PL/1) any time to define and reference record types.

The other approach is to first let the world sort out what features are actually desirable, then standardize what's there and try to get implementers to converge towards the standard... Common Lisp is an example of this from programming languages.

Don't, don't, don't follow Common LISP as an example. Common LISP has been a disaster. There are far fewer people earning their living from LISP now than there were before Common LISP standard was introduced, and far fewer programs in regular use written in LISP.

Common LISP is a very bad standard. As Scott Fahlman wrote:

The result is a language that... not even its mother could love. Like the camel, Common Lisp is a horse designed by committee. Camels do have their uses.

He should know. As he says on his home page:

I was one of the principal designers of the Common Lisp language.

Common LISP essentially destroyed LISP as a usable, productive language. It made an incredible number of simply wrong technical decisions; and too many of those decisions were made by the smaller companies of the eastern United States - Symbolics, LMI, Franz - trying to write a standard which was as different as possible from InterLISP, in order to kill competition from Xerox. I'm not pretending InterLISP was brilliant or the answer to all problems. It wasn't. Like Common LISP, it was a LISP2, making an artificial distinction between data and code; and it was in many ways clumsy and unorthogonal itself. But there was a great deal of creativity coming out of the InterLISP community, which Common LISP effectively killed.

We would have been so much better with a standard based on Portable Standard Lisp, or on EuLisp, or on Scheme. We would have been so much better with no standard at all. Instead, we got a LISP2 with a bizarrely complex lambda-list syntax, with a comment syntax which was incompatible with the LISP reader (so that in-core editing and development were effectively impossible), with so many horrible design errors.

Of course, it succeeded in its primary goal. Xerox was driven out of the LISP marketplace. But the cost for LISP has been horrendous: the language has been effectively destroyed. And for what was and should be the queen of programing languages, that's a disaster.

Oh, yes - I was during the eighties a very junior member of the British Standards Institution's LISP working group. I was there. I still think LISP is the best possible programming language, but these days I use Java.

The other approach is to first let the world sort out what features are actually desirable, then standardize what's there and try to get implementers to converge towards the standard... Common Lisp is an example of this from programming languages.

Don't, don't, don't follow Common LISP as an example. Common LISP has been a disaster. There are far fewer people earning their living from LISP now than there were before Common LISP standard was introduced, and far fewer programs in regular use written in LISP.

Common LISP is a very bad standard. As Scott Fahlman wrote:

The result is a language that... not even its mother could love. Like the camel, Common Lisp is a horse designed by committee. Camels do have their uses.

He should know. As he says on his home page:

I was one of the principal designers of the Common Lisp language.

Common LISP essentially destroyed LISP as a usable, productive language. It made an incredible number of simply wrong technical decisions; and too many of those decisions were made by the smaller companies of the eastern United States - Symbolics, LMI, Franz - trying to write a standard which was as different as possible from InterLISP, in order to kill competition from Xerox. I'm not pretending InterLISP was brilliant or the answer to all problems. It wasn't. Like Common LISP, it was a LISP2, making an artificial distinction between data and code; and it was in many ways clumsy and unorthogonal itself. But there was a great deal of creativity coming out of the InterLISP community, which Common LISP effectively killed.

We would have been so much better with a standard based on Portable Standard Lisp, or on EuLisp, or on Scheme. We would have been so much better with no standard at all. Instead, we got a LISP2 with a bizarrely complex lambda-list syntax, with a comment syntax which was incompatible with the LISP reader (so that in-core editing and development were effectively impossible), with so many horrible design errors.

Of course, it succeeded in its primary goal. Xerox was driven out of the LISP marketplace. But the cost for LISP has been horrendous: the language has been effectively destroyed. And for what was and should be the queen of programing languages, that's a disaster.

Oh, yes - I was during the eighties a very junior member of the British Standards Institution's LISP working group. I was there. I still think LISP is the best possible programming language, but these days I use Java.

You realize that Exchange users are a little more demanding on a system then...

Plus, I didn't say the machines were taxed. We could have slapped on another 15,000 - 25,000 users without many issues besides more space on the SAN.

You are referring to "BD-Tree: Output-Sensitive Collision Detection for Reduced Deformable Models." Actually, the important part was a new type of bounding volume hierarchy for performing collision detection on slightly deformable objects. They were not doing simulation LOD, and it was NOT done in real time. But you are correct that there is ongoing work on simulation (physics) LOD.

arrggh! http://www.cs.cmu.edu/~dst/Secrets/E-Meter/index.h tml

I am studying in an engineering university with a new "software engineering" degree.(I got in the program at the 4th year of it's existance, so they had their first promotion last year). Half our classes don't involve coding. We get told day after day that we are not to be "computer scientists". Sure, we will start coding, but we are formed to grow to become analysts, designers, and managers. I just finished my Software quality class. We had to learn about IEEE and ISO standards, and most importantly WHY they are important. As engineers, we are liable to our products. We can lose the right to exercice our profession if we deliver crap products. Standards help us focusing on the important issues. The quality standards have little to do with the code quality. They rather sya that if you did a good analysis, detailed specs, reviews, inspections and all those planification documents with a project manager behind them to make sure they're followed, code quality will be a natural result. So, take the good programmers and put them higher up in the production chain, make them leaders, designers, managers. Make them tell other people how to work. Software has a rework percentage far higher than any other engineering domains, between 20 and 40%. Not because software isnt engineering, but because it's a new discipline. We built bridges for thousands of years now, and software for only 50. That's why you dont see bridges collapse as often as software fail. Of course, these enginerring practices are new to the field and not yet popular. People still argue their validity, businesses fear the price tag. The thing is, read about the cost of quality: http://www.asq.org/topics/coq.html (this is one example, with many more on this topic) or the SEI http://www.sei.cmu.edu/managing/managing.html these things were made by and for good programmers. TFA didnt mention this one bit. Thinking that quality comes from programmers alone displays a serious lack of vision.

The premise was that no algorithm existed for computers to be able to find where within a picture a certain object existed. But who is good at doing these things? People. Normally, a group of people would be paid to sort through hundreds of thousands of different images and find where a certain object was. But this was slow, and consumed unnecessary resources (like money). However, the ingenious people at CMU developed a clever way to make it fun, so much so that people would actually WANT to do it. By making a game.

The creater, a person whose name is Roy, spent a year working on the game. Please don't diss it too much. How would you like it if someone dissed your program that you spent your life on, making it as good as possible?

On a side note, the ESP Game was sold to Google for 1 million dollars. Not kidding.

As a computer vision researcher, I thought I'd share a little insight as to why this is helpful for the computer vision community.

Whenever one wants to train an algorithm to detect or recognize an object in a data set, one needs both the data set and the ground truth. The data set is usually a large set of images and the ground truth is some semantic information associated with each image, such as the locations of people and cars, or perhaps a representative word or category. The data set is usually easy to obtain, however the ground truth usually involves manual input. Considering that data sets regularly have more than 10,000 images, this can be quite a challenge since it can't be automated (if it could, your research would be pointless eh?).

This is where the peekaboom application comes into play. Now, the task of annotating the images with semantic information is distributed among thousands of slashdot readers and other assorted nerdy individuals. Not only does this program provide a single ground truth for researchers to analyze, but a statistical description of the ground truth, that is validated by another user guessing the semantic information.

More information about this project can be found at: http://www.cs.cmu.edu/~biglou/research.html

As an aside, a friend of mine is working on a project to turn planetary transit model fitting into a web-based game. Keep a lookout for it in the next few months.

http://www.aladdin.cs.cmu.edu/workshops/lamps05/Sl ides/Peekaboom.ppt

the one in google's index now seems to be broken

http://www.contrib.andrew.cmu.edu/~moose/sysadmin/ pricelist.html

Most OS X users probably don't even know they're running a flavor of Linux, but they can slowly get more involved with that world while as they feel comfortable.

Since no one explicitly why OS X is not Linux: OS X is based on the Mach Microkernel and FreeBSD (a BSD Unix variant, not Linux (see section "What is Linux?").

It is insane having a space vehicle that you can't launch if there are clouds, let alone rain near the launch pad

The cloud requirements (of which there are quite a number) aren't about rain; they're mainly about lightning, which poses a threat to any rocket. The shuttle is, however, like you mentioned, more succeptable to ice/debris impacts because of its side-mounted position (a configuration that we can expect few large spacecraft (especially manned ones) to repeat in the future).

However, as with all open source software, caveat emptor. We ourselves (University of California, Irvine's TeamXAR - I'm the team leader) found that CARMEN does not fail well, and in fact had to give it a few kicks each time we started it up.

Note also that the finalists (and possibly semi-finalists) will need to issue team technical reports, so while that probably won't include code, key details will emerge.

I should also state before I get a flurry of questions that we ourselves did not make the cut for the 40 semi-finalists for the September 2005 National Qualifying Event.

We had built a ton of software since our team's inception in July 2004, but did not touch a real car we got a message from DARPA effectively stating "Hi! We'll be there in about a month for a site visit. See you then!"

As to be expected, as we (a core group of 6 undergraduate students plus a few extra helpers) pulled nearly a month-straight of all-nighters to get something to show the reviewers from DARPA, not only was Murphy's Law present at our site visit, but we learned Murphy's Corollary: Murphy likes to work overtime. Nothing worked.

Three weeks later, the car was tooling around our site visit course, but of course, three weeks too late.

If you're interested in following our progress, hop to our website at http://www.ics.uci.edu/~darpagc/ or http://www.teamxar.com/

- Phil

My favorite mock table(s) of the elements are the onesfrom the inside covers of the Douglas Coupland novel, "Shampoo Planet".

I particularly like 1 H [Heaven] and 2 He [Hell].

My favorite mock table(s) of the elements are the onesfrom the inside covers of the Douglas Coupland novel, "Shampoo Planet".

I particularly like 1 H [Heaven] and 2 He [Hell].

Or, how about this revision?
http://info.bio.cmu.edu/Courses/BiochemMols/Period ic/MALElements.html

The phisher can't get the image from the bank's site without logging in as you first. The image could even be generated using hash visualisation so there wouldn't be a library of standard images for the phisher to try.

I was working on a project Life in the Atacama whose goal was to do exacty that. The idea was to have scientists pick out waypoints which may be of interest but the robot can vear off and make decisions on locations that are of interest.

The problem is, I think, is that people don't understand how the human brain processes these sorts of images, which is why most people are having limited success doing image analysis on computers like this.

Not entirely. I agree that part of the problem is that not only do we not understand how the image processing capability of the human brain works. Some of the rest of the problem is that we also don't know how to reproduce the years of specialist training surveillance experts spend to be able to detect unexpected but significant information from grainy pictures. But the most significant problem with image processing is the computer power: a decent estimate ( http://www.frc.ri.cmu.edu/~hpm/book97/ch3/retina.c omment.html ) in 1998 was that to reproduce the power of the human brain would require 100 million MIPS of computing power. This doesn't include the computing power of the nervous system and retina that seem to have significant functional value in reducing the complexity of the picture, and are virtually irreproducible in current technology.