Slashdot Mirror

First, off I totally support "anti" (now revealed as Sherman), but there *were* bomb-making instructions on the site. It has been cached by an incensed Carnegie-Mellon professor who thinks that there is nothing illegal in this information I think if you look at it you will see that there is *much* more comprehensive information on making bombs available all over the place. (The Monkeywrencher's Guide) comes to mind.

Raise the fist has had a lot of effectiveness in serving as a focal point for Black Bloc anarchists in SoCal. There was a large presence at the Democratic National Convention where they were attacked by rubber bullet firing police (along with a lot of other folk). This was followed up with a peaceful MayDay demonstration which was *really* beaten up by the LongBeach PD (about 120 kids out of 150 arrested). One of the guys that defended himself Rob "Ruckus" Middaugh is now doing 2-3 because he had a parole violation, he was closely associated with the site which was trying to raise support for his cause.

They also kept a database of pictures of undercover feds from demonstrations and logs of IP addresses of government agencies that were monitoring the site. Basically they were looking for an excuse to take the site down and it seems that Sherman may have given it to them by the alleged cracking that he engaged in (this is something that puzzles me: why focus on the bombs if the cracking is all the evidence that they have?)

These are all young kids doing what they believe in. They are involved in all sorts of DIY community projects and are sincere and active. My heart goes out to them.

Professor Dave Touretzky at CMU (the guy that runs the well-known DECSS gallery, has a mirror of the previous contents of the raisethefist website here. The content for which the site was raided was apparantly the Reclaim Guide, which contains detailed instructions on defensive and offensive tactics for rioters faced with riot police.

Professor Dave Touretzky at CMU (the guy that runs the well-known DECSS gallery, has a mirror of the previous contents of the raisethefist website here. The content for which the site was raided was apparantly the Reclaim Guide, which contains detailed instructions on defensive and offensive tactics for rioters faced with riot police.

Carnegie Mellon University

Is Mac OS X a Threat to Linux?

In short, yes! On March 24, Apple Computer, Inc. released its next-generation operating system, Mac OS X (the "X" is pronounced as "ten," for the version number of the operating system) to Macintosh addicts around the world. While this isn't such a big deal to some, others view it as a new beginning that could squash all thoughts of a desktop Linux for the general public.

What's this, "Apple out-maneuvering Linux?" you say? Well, maybe not as a server platform for the immediate future, but just think about this for a second: Would it be possible for Apple to deflate the hopes and dreams of developers worldwide of bringing Linux to the desktop? The short answer to this is yes, but it's more complicated than that.

Aside from the fact that an apple is a fruit and a penguin is a flightless waterfowl, there used to be a big difference between the Apple Macintosh operating system and Linux. Apple had a nice GUI; Linux did not. Linux had a command line; Mac OS did not. Linux is a multitasking OS that supports multiple processors; Mac OS is not. Linux runs on just about anything these days; the Mac OS runs on, well, Apple equipment. Linux is free (well, sort of, depending on your method of install); Mac OS X will set you back $129.

So, the lines were pretty clear about the differences between Linux and Mac OS. But lately, that clarity has been blurred as Apple rolls out Mac OS X to the public. The new Mac OS now has preemptive multitasking and support for up to two processors, which is still a far cry from Linux's support for up to 16 processors, but it's a move in the right direction.

Traditionally, the only control Apple users had over their system was via the Control Panels and scripting system functions with AppleScript, MacPerl, or ResEdit. However, with Mac OS X's BSD base, Apple users were given something they've always wanted: a latch to take a peek into Apple's core.

At the core of Mac OS X is a kernel built on the Mach 3.0 kernel, BSD 4.4, and Darwin (Apple's open source kernel project), giving network and system administrators the ability to use Unix programs and add them to their Macintoshes. When combined, these components offer a rock-solid operating system that's hard to beat. (OK, I know that Mac OS X has its fair share of bugs, so no flames, please.)

One of the advantages of Mac OS X is that it now offers Macintosh users with a command line on top of a slick, stable GUI, known as Aqua. With OS X's BSD core, Macintosh users will now be able to use GNU software. This means they will be able to run tools like Emacs, vi, Apache, and even XFree86 and the GIMP (something that Adobe Systems should fear). If you're looking for a place to download ports of GNU tools that run under Mac OS X, you should visit the GNU-Darwin Project on SourceForge.

One of the downsides of OS X is that it requires you to have a native G3 or G4 processor. This means you have to be running a G3 Mac, an iMac or iBook, a PowerBook G3 or better, or any of the G4 models and above. So, if you have an older 604 PowerPC-based Mac, you can't run OS X (that is, unless upgrade manufacturers, such as Sonnet Technologies release updates to their processor software). For now, though, if you want to run OS X your best bet is to run it on native hardware.

One group that stands to lose a chunk of the market is the Mac-based Linux distributions, such as MkLinux, LinuxPPC, or Yellow Dog Linux (YDL) from Terra Soft Solutions. Up to now, these were your best options for running Linux on the Mac, with LinuxPPC and YDL leading the pack. But OS X changes this landscape significantly. The downside to running Linux on your Mac in a dual-boot configuration (as with Windows) is that if you want to access any of your Mac apps, you had to either reboot, or install and run Mac-On-Linux. Neither option is ideal, but now OS X allows you to work in the command line, and run your Mac apps right along with them--no rebooting required.

Is Mac OS X a Threat to Linux?

In short, yes! On March 24, Apple Computer, Inc. released its next-generation operating system, Mac OS X (the "X" is pronounced as "ten," for the version number of the operating system) to Macintosh addicts around the world. While this isn't such a big deal to some, others view it as a new beginning that could squash all thoughts of a desktop Linux for the general public.

What's this, "Apple out-maneuvering Linux?" you say? Well, maybe not as a server platform for the immediate future, but just think about this for a second: Would it be possible for Apple to deflate the hopes and dreams of developers worldwide of bringing Linux to the desktop? The short answer to this is yes, but it's more complicated than that.

Aside from the fact that an apple is a fruit and a penguin is a flightless waterfowl, there used to be a big difference between the Apple Macintosh operating system and Linux. Apple had a nice GUI; Linux did not. Linux had a command line; Mac OS did not. Linux is a multitasking OS that supports multiple processors; Mac OS is not. Linux runs on just about anything these days; the Mac OS runs on, well, Apple equipment. Linux is free (well, sort of, depending on your method of install); Mac OS X will set you back $129.

So, the lines were pretty clear about the differences between Linux and Mac OS. But lately, that clarity has been blurred as Apple rolls out Mac OS X to the public. The new Mac OS now has preemptive multitasking and support for up to two processors, which is still a far cry from Linux's support for up to 16 processors, but it's a move in the right direction.

Traditionally, the only control Apple users had over their system was via the Control Panels and scripting system functions with AppleScript, MacPerl, or ResEdit. However, with Mac OS X's BSD base, Apple users were given something they've always wanted: a latch to take a peek into Apple's core.

At the core of Mac OS X is a kernel built on the Mach 3.0 kernel, BSD 4.4, and Darwin (Apple's open source kernel project), giving network and system administrators the ability to use Unix programs and add them to their Macintoshes. When combined, these components offer a rock-solid operating system that's hard to beat. (OK, I know that Mac OS X has its fair share of bugs, so no flames, please.)

One of the advantages of Mac OS X is that it now offers Macintosh users with a command line on top of a slick, stable GUI, known as Aqua. With OS X's BSD core, Macintosh users will now be able to use GNU software. This means they will be able to run tools like Emacs, vi, Apache, and even XFree86 and the GIMP (something that Adobe Systems should fear). If you're looking for a place to download ports of GNU tools that run under Mac OS X, you should visit the GNU-Darwin Project on SourceForge.

One of the downsides of OS X is that it requires you to have a native G3 or G4 processor. This means you have to be running a G3 Mac, an iMac or iBook, a PowerBook G3 or better, or any of the G4 models and above. So, if you have an older 604 PowerPC-based Mac, you can't run OS X (that is, unless upgrade manufacturers, such as Sonnet Technologies release updates to their processor software). For now, though, if you want to run OS X your best bet is to run it on native hardware.

One group that stands to lose a chunk of the market is the Mac-based Linux distributions, such as MkLinux, LinuxPPC, or Yellow Dog Linux (YDL) from Terra Soft Solutions. Up to now, these were your best options for running Linux on the Mac, with LinuxPPC and YDL leading the pack. But OS X changes this landscape significantly. The downside to running Linux on your Mac in a dual-boot configuration (as with Windows) is that if you want to access any of your Mac apps, you had to either reboot, or install and run Mac-On-Linux. Neither option is ideal, but now OS X allows you to work in the command line, and run your Mac apps right along with them--no rebooting required.

• Structure and Interpretation of Computer Programs
• Common Lisp HyperSpec
• Common Lisp the Language, 2. ed
• Common Lisp - A gentle Introduction to symbolic computation
• The Scheme Programming language, 2. ed
• Reflections on trusting trust
• Lisp: Good News, Bad News. How to Win Big
• John McCarthy's homepage
• Dennis Ritchie's homepage
• Various classic papers it's a shame ACM never bothered to continue adding to
• Another list of classic papers (this time related mostly to programming language design)
• GTK-Gnome Application Development (not a classic, though, as the field is too young)
• KDE 2.0 Development (not a classic though, as the field is too young)
• Eric Weissteins Mathworld
• Compilers and compiler generators - an introduction with C++ (although I'm not too sure if it deserves being called a classic...)
• Parsing techniques - A practical guide
• Art of assembly language programming (never was a dead tree, but good anyway)
• Paul Carters 386 assembly book (same comment as above)
• An Introduction to Scheme and its Implementation (see comment above)
• How to design programs - An introduction to programming and computing (not a classic, yet!)
• The Gutenberg archives contains much non-copyrighted classic fiction in ASCII format
• Sacred texts has copies of or links to many religious text for various major (or minor) religions

• Structure and Interpretation of Computer Programs
• Common Lisp HyperSpec
• Common Lisp the Language, 2. ed
• Common Lisp - A gentle Introduction to symbolic computation
• The Scheme Programming language, 2. ed
• Reflections on trusting trust
• Lisp: Good News, Bad News. How to Win Big
• John McCarthy's homepage
• Dennis Ritchie's homepage
• Various classic papers it's a shame ACM never bothered to continue adding to
• Another list of classic papers (this time related mostly to programming language design)
• GTK-Gnome Application Development (not a classic, though, as the field is too young)
• KDE 2.0 Development (not a classic though, as the field is too young)
• Eric Weissteins Mathworld
• Compilers and compiler generators - an introduction with C++ (although I'm not too sure if it deserves being called a classic...)
• Parsing techniques - A practical guide
• Art of assembly language programming (never was a dead tree, but good anyway)
• Paul Carters 386 assembly book (same comment as above)
• An Introduction to Scheme and its Implementation (see comment above)
• How to design programs - An introduction to programming and computing (not a classic, yet!)
• The Gutenberg archives contains much non-copyrighted classic fiction in ASCII format
• Sacred texts has copies of or links to many religious text for various major (or minor) religions

Mathematiticians have invented a language called ML (Meta Language) which is a functional language in which you can write mathematical formulas almost as you would mathematically define them.
In the area of functional progamming you should also consider Common Lisp which is a well known functional language used mostly for AI.

On the properiatry side, many mathematical algorithms get coded in MatLab which provides built-in matrix manipulation and lots of additional libraries (you'll probably find out most of the stuff you want to write is already there...)

In any case, the progamming language should be tightly fitted to the application.

Is Mac OS X a Threat to Linux?

In short, yes! On March 24, Apple Computer, Inc. released its next-generation operating system, Mac OS X (the "X" is pronounced as "ten," for the version number of the operating system) to Macintosh addicts around the world. While this isn't such a big deal to some, others view it as a new beginning that could squash all thoughts of a desktop Linux for the general public.

What's this, "Apple out-maneuvering Linux?" you say? Well, maybe not as a server platform for the immediate future, but just think about this for a second: Would it be possible for Apple to deflate the hopes and dreams of developers worldwide of bringing Linux to the desktop? The short answer to this is yes, but it's more complicated than that.

Aside from the fact that an apple is a fruit and a penguin is a flightless waterfowl, there used to be a big difference between the Apple Macintosh operating system and Linux. Apple had a nice GUI; Linux did not. Linux had a command line; Mac OS did not. Linux is a multitasking OS that supports multiple processors; Mac OS is not. Linux runs on just about anything these days; the Mac OS runs on, well, Apple equipment. Linux is free (well, sort of, depending on your method of install); Mac OS X will set you back $129.

So, the lines were pretty clear about the differences between Linux and Mac OS. But lately, that clarity has been blurred as Apple rolls out Mac OS X to the public. The new Mac OS now has preemptive multitasking and support for up to two processors, which is still a far cry from Linux's support for up to 16 processors, but it's a move in the right direction.

Traditionally, the only control Apple users had over their system was via the Control Panels and scripting system functions with AppleScript, MacPerl, or ResEdit. However, with Mac OS X's BSD base, Apple users were given something they've always wanted: a latch to take a peek into Apple's core.

At the core of Mac OS X is a kernel built on the Mach 3.0 kernel, BSD 4.4, and Darwin (Apple's open source kernel project), giving network and system administrators the ability to use Unix programs and add them to their Macintoshes. When combined, these components offer a rock-solid operating system that's hard to beat. (OK, I know that Mac OS X has its fair share of bugs, so no flames, please.)

One of the advantages of Mac OS X is that it now offers Macintosh users with a command line on top of a slick, stable GUI, known as Aqua. With OS X's BSD core, Macintosh users will now be able to use GNU software. This means they will be able to run tools like Emacs, vi, Apache, and even XFree86 and the GIMP (something that Adobe Systems should fear). If you're looking for a place to download ports of GNU tools that run under Mac OS X, you should visit the GNU-Darwin Project on SourceForge.

One of the downsides of OS X is that it requires you to have a native G3 or G4 processor. This means you have to be running a G3 Mac, an iMac or iBook, a PowerBook G3 or better, or any of the G4 models and above. So, if you have an older 604 PowerPC-based Mac, you can't run OS X (that is, unless upgrade manufacturers, such as Sonnet Technologies release updates to their processor software). For now, though, if you want to run OS X your best bet is to run it on native hardware.

One group that stands to lose a chunk of the market is the Mac-based Linux distributions, such as MkLinux, LinuxPPC, or Yellow Dog Linux (YDL) from Terra Soft Solutions. Up to now, these were your best options for running Linux on the Mac, with LinuxPPC and YDL leading the pack. But OS X changes this landscape significantly. The downside to running Linux on your Mac in a dual-boot configuration (as with Windows) is that if you want to access any of your Mac apps, you had to either reboot, or install and run Mac-On-Linux. Neither option is ideal, but now OS X allows you to work in the command line, and run your Mac apps right along with them--no rebooting required.

Yeah, I'm a Karma whore. That's why I'm AC.

there's a mile of similar commentary on the internet (such as neil postman, clifford stoll, etc.). robert kraut carried out the 'internet paradox' surveys that became the sociological proof of this effect, although the earlier findings were later recast.

If you click on the link, you'll see that the first article is called "Internet Paradox Revisited," and in it Kraut et al. report a followup of the same participants from the original study, showing that the statistically significant but small relationship between Internet use and depression reported in the original paper disappeared over time. Kraut and his colleagues are responsible scientists: they never represented their first study as "sociological proof" (social science is probabilistic rather than deterministic, and most good social scientists are allergic to using the word "proof" in discussing their work), and they should be applauded for publishing data that contradict what they said earlier. In fact, Internet users look pretty well adjusted in the followup. As the original poster pointed out, maybe the people in this study are getting better at coping with new technology and integrating it into their social lives.

there's a mile of similar commentary on the internet (such as neil postman, clifford stoll, etc.). robert kraut carried out the 'internet paradox' surveys that became the sociological proof of this effect, although the earlier findings were later recast.

i'm not saying that there are not social changes caused by the introduction of new information technologies. we are information driven beings, after all. however, we have to be wary of assigning values to them that are either ultimately 'good' or 'bad,' as despite all these changes, we somehow seem to be able to cope with them ...

A tutorial on Verilog is made available from a CMU professor. I think that Verilog will be more than sufficiently C-like to ease me into the PLD world.

I am aware of the huge difference of what kinds of behavior you are programming when you are using programmable logic devices vs. microcontrollers. But just because I am looking at a different paradigm doesn't mean it wouldn't be nice if some of my skills would transfer. I want to gain proficiency in PLD's because of the fact they can implement functionality otherwise requiring complex circuits. This is useful and I can't currently use it in my designs without another engineer to do the PLD.

I was really curious about the accessibility of the language. Java-like syntax would make it easier to entice more people to try to learn this skill, as Java is familiar to many people in the environments in which I work. I would bet Verilog has gained many adopters b/c of its similarity to C, who would otherwise use schematic entry to program PLD's, or avoid the parts altogether

To function well in the climate and level of embedded development today, you have to be able to do both sides of the equation if you want to be at all independent. I have seen horrific program design choices by people formally trained in EE, and I have seen atrocious, laughable circuits from those formally trained in CS.

A software guy sees a fault in a product and says it is a hardware problem.A hardware guy sees a fault in a product and says it is a software problem. The real engineer fixes the damn problem and tells the other two to grow up and pull their heads' out of their asses.

CMU 15251 Course Document and Cheating Policy

His policy encourages collaboration and specifically forbids cheating. It itemizes various types of cheating, for example copying from another student, letting another student copy you, and looking at someone else's files online (even if they forgot to set their file permissions).

Furthermore, he requires all of the students in his class to sign a statement saying that they have read and understand the cheating policy. Not only does that discourage some students from cheating, but it also makes it much easier for him to get students into serious trouble with the school when they are caught.

In addition to the course document, here's more or less what he had to say on the first day of class: (I apologize for paraphrasing; this is how I remember it) "Nobody plans to cheat. You all must be very smart, or you wouldn't be here. You think you're going to try hard and do well in this class. But later in the semester you'll get busy with other classes and activities, and all of a sudden an assignment will be due in one day and you haven't started. Or you'll be taking a test and realize that you forgot to study an important equation. Or you'll work hard on an assignment and almost completely get it working, but get stuck on one subroutine. Even though you never planned on cheating, all of a sudden you'll find yourself in a circumstance like that and it will seem tempting."

(BTW, I shouldn't have to say this, but Prof. Rudich's cheating policy is copyrighted. If you're a teacher or T.A., don't copy his cheating policy without his permission. That would be just as dishonest as cheating!!! If you want to use it, contact him and I'm sure he'd be delighted to let you use it, as long as you give him credit.)

I've posted this before, but if you want a use-specific case, you often have to do it yourself or pay $$ for a custom job.

If you are looking for something small and easy to move around yet is upgradable, consider doing something like this:
my server

Built into a small briefcase, I can carry it to school and have it running without even opening it. Running linux I can ssh in and do everything I need. It runs a generic Slot1 mobo with 3 pci slots so you can conceivably throw in your favorite PCI Radeon or GF2, a 1 gig PIII, 3 slots worth of RAM, and have a pretty good machine.

Brad Myers homepage

has several papers and links (but many old and not maintained.)

If you really want to start from the bottom up, before they became ubiquitous, windowing systems were a common topic in computer graphics , and some of the older texts cover how to do it from the bare framebuffer up.
Folley and Van Damm has been revised too often so they've probably dropped all of that for more coverage on 3D, etc. but my old copy of Sproull and Newman (sp? I don't have the text on hand to check) has all that (and even some notes on programming for Tektronix type vector displays! ).

Look at old SIGGGRAPH journals.
( 20-30 years ago, this was THE topic! )

And look at things like:
FRESCO & Berlin
Amulet
Sqeak (morphic) and Self UI papers.
OpenDoc
News
GnuStep/NextStep/Cocoa

Ignore the folks that say the world doesn't need another windowing system: the world still needs a better one, but if you don't come up with any better ideas, you might consider helping out on an existing project, rather than starting a new one from scratch. There are a lot of good ideas already out there that lack implementations and users!

Hack Proofing Windows 2000 Server

It's fiction... and since it deals with computers I'm guessing it goes under Science.

This is a lot more than just Linux with a NeXTish interface. It's also the entire GNUstep package, a very nice object-oriented application framework.

That being said, you can still just install GNUstep on FreeBSD (and for NeXT purists, that would certainly be closer to the original than Linux).

Is Mac OS X a Threat to Linux?

In short, yes! On March 24, Apple Computer, Inc. released its next-generation operating system, Mac OS X (the "X" is pronounced as "ten," for the version number of the operating system) to Macintosh addicts around the world. While this isn't such a big deal to some, others view it as a new beginning that could squash all thoughts of a desktop Linux for the general public.

What's this, "Apple out-maneuvering Linux?" you say? Well, maybe not as a server platform for the immediate future, but just think about this for a second: Would it be possible for Apple to deflate the hopes and dreams of developers worldwide of bringing Linux to the desktop? The short answer to this is yes, but it's more complicated than that.

Aside from the fact that an apple is a fruit and a penguin is a flightless waterfowl, there used to be a big difference between the Apple Macintosh operating system and Linux. Apple had a nice GUI; Linux did not. Linux had a command line; Mac OS did not. Linux is a multitasking OS that supports multiple processors; Mac OS is not. Linux runs on just about anything these days; the Mac OS runs on, well, Apple equipment. Linux is free (well, sort of, depending on your method of install); Mac OS X will set you back $129.

So, the lines were pretty clear about the differences between Linux and Mac OS. But lately, that clarity has been blurred as Apple rolls out Mac OS X to the public. The new Mac OS now has preemptive multitasking and support for up to two processors, which is still a far cry from Linux's support for up to 16 processors, but it's a move in the right direction.

Traditionally, the only control Apple users had over their system was via the Control Panels and scripting system functions with AppleScript, MacPerl, or ResEdit. However, with Mac OS X's BSD base, Apple users were given something they've always wanted: a latch to take a peek into Apple's core.

At the core of Mac OS X is a kernel built on the Mach 3.0 kernel, BSD 4.4, and Darwin (Apple's open source kernel project), giving network and system administrators the ability to use Unix programs and add them to their Macintoshes. When combined, these components offer a rock-solid operating system that's hard to beat. (OK, I know that Mac OS X has its fair share of bugs, so no flames, please.)

One of the advantages of Mac OS X is that it now offers Macintosh users with a command line on top of a slick, stable GUI, known as Aqua. With OS X's BSD core, Macintosh users will now be able to use GNU software. This means they will be able to run tools like Emacs, vi, Apache, and even XFree86 and the GIMP (something that Adobe Systems should fear). If you're looking for a place to download ports of GNU tools that run under Mac OS X, you should visit the GNU-Darwin Project on SourceForge.

One of the downsides of OS X is that it requires you to have a native G3 or G4 processor. This means you have to be running a G3 Mac, an iMac or iBook, a PowerBook G3 or better, or any of the G4 models and above. So, if you have an older 604 PowerPC-based Mac, you can't run OS X (that is, unless upgrade manufacturers, such as Sonnet Technologies release updates to their processor software). For now, though, if you want to run OS X your best bet is to run it on native hardware.

One group that stands to lose a chunk of the market is the Mac-based Linux distributions, such as MkLinux, LinuxPPC, or Yellow Dog Linux (YDL) from Terra Soft Solutions. Up to now, these were your best options for running Linux on the Mac, with LinuxPPC and YDL leading the pack. But OS X changes this landscape significantly. The downside to running Linux on your Mac in a dual-boot configuration (as with Windows) is that if you want to access any of your Mac apps, you had to either reboot, or install and run Mac-On-Linux. Neither option is ideal, but now OS X allows you to work in the command line, and run your Mac apps right along with them--no rebooting required.

.. and the team really does great work. But, the SMB protocol is a moving target, we had to see that several times in the past. The Samba team has always managed to readapt to new protocol versions. Everyone who has worked with Windows' network Neighborhood knows that SMB is also a really really broken protocol which only works with much patience.
Wouldn't it be just better to invent a very new protocol, and provide clean clients for all major operating systems (Linux, BSD, windows 9x/NT, etc.). For Linux/Unix/BSD, something better than NFS is really required - NFS sucks (security? etc.)
I'm a bit thinking about efforts like Coda which is in the Linux kernel for years now, and there also exists a Windows client. Last time I checked there was no NT client which makes Coda practically useless at this stage.
But I think a clean, well designed, secure and stable protocol would be a benefit for big company's networks and for home networks. I work as developer, but I often help our admins. It's a network of w2k, NT4, Linux and FreeBSD machines (about 60 computers). The Windows machines always suck... in many cases because SMB doesn't work as it should.

I forget how long it takes to decrypt a DVD

EfDTT by Charles Hannum, whose source code fits under half a kilobyte, can descramble CSS data in real-time using only 10% of a G4 Cube's CPU power. Think of what an implementation that uses more tables can do.

I forget how long it takes to decrypt a DVD

EfDTT by Charles Hannum, whose source code fits under half a kilobyte, can descramble CSS data in real-time using only 10% of a G4 Cube's CPU power. Think of what an implementation that uses more tables can do.

1. The web wasn't ready for video
2. Storage for video is expensive

The darn thing got my location right within a 15 kilometers range

No distances were given (latitude and longitude, but they're in a weird format...longitude was given as "-115.17" when something like 1156'48" W would be the usual method), but it nailed both IPs I fed it as being in Las Vegas. (When you consider that reverse-mapping one address gets you lasvegas.net and the other gets you lvcm.com, that probably shouldn't be too surprising.)

Given how easy it would be to fool a geolocation system (especially given nearly everybody else in this thread), I don't see how this is really supposed to be effective...or is it really supposed to be more like CSS, which only thwarts fair use and small-scale copying while doing nothing to stop mass production of "counterfeit" DVDs? There's no reason (other than the bandwidth on my cable-modem connection) why I couldn't open my Squid proxy up to the world. In addition to getting almost no ads, you would appear to be browsing from Vegas instead of wherever you are really located. (How's that for MLP? :-) ) What's to stop someone from doing this elsewhere, either as a free service or for profit, and enable people to bypass whatever geographic restrictions are placed on a website?

Please stop thinking in terms of inferior languages like C and Java as if they were the be-all end-all of computing.

1) stop arguing about politics; the republicans have taken over and there's no stopping them
2) stop trying to lose weight; its not gonna happen
3) stop trying to have a love life; its not gonna happen (see #2 for details)
4) stop hoping to get into my #1 college; ill get rejected, just like i got deferred

its been such a great year..

I basically already said a Master's was more important (#2758850), but I forgot to mention one important detail:

Carnegie Mellon offers a 1-year Master's program in e-Business!

Also, a PhD in Computer Science gets you LESS salary in the long run, even less than a BS.

On the group's page they don't offer any code, but there's a screen shot, some research papers and links to other articles, and a link to Andrej Bauer's (of Forum 2000 fame) Gallery of Random Art.

On the group's page they don't offer any code, but there's a screen shot, some research papers and links to other articles, and a link to Andrej Bauer's (of Forum 2000 fame) Gallery of Random Art.

I was referring to this code:
MakeNotAccidentallyClickable(widget);
That's what I meant by "example".

Yes, I wrote that -- but it's a direct translation of the comment someone else told me couldn't be replaced with a function name.

Ok, perhaps I made a straw man. The point I was trying to make is that there must be more details to the situation, whatever they are; and because your code didn't specify them, the problems you found in my commented version of the code may or may not exist in yours. One can't know without more information.

You're absolutely correct. However, this situation MUST be left to the wisdom of the programmer. There's simply nobody else to trust! If the programmer's wrong, he'll write wrong comments as well as wrong function names, and most likely wrong code as well. (See "peer review" and "pair programming" for some solutions to this.)

Perhaps I can sum up my thoughts this way. Programmers make mistakes.

Just a quick interruption: so do maintainers. The programmers shouldn't assume the maintainers are going to make all the mistakes in the book, and neither should the maintainers assume that about the programmers. A lot of common programming practice seems to assume that a horde of idiots are going to take over the code tomorrow, so anything I don't finish today will get destroyed and perverted. This results in late hours, aggressive comments (like "DON'T TOUCH THIS!"), a lack of tests (because you don't think the later programmers will have the wisdom to improve you code), and so on. Some cynicism is appropriate; after all, the later programmers will have at best a foggy memory of what you were thinking when you wrote it; however, at the same time, it's just as likely that the later programmers will understand the overall problem BETTER than you do.

It's hard to tell mistakes apart from deliberate decisions without some indication of the programmer's frame of mind.

This is true, and it's why I want code to be self-documenting. The code has to wisely and correctly make comments unneeded; you can't just delete the information contained in a comment. The advantage is huge: you go from *two* sources if information which may contradict each other (don't tell me that you've never seen out-of-sync comments ;-) to one source which is automatically tested.

Thus, comments are only unnecessary in perfect code.

Not really true. There's no such thing as perfect code; comments are unneeded in code which tells the same story as the comments would. And such code (unlike perfect code) is not overly hard to construct.

If you choose to encode your comments using function names, rather than the features provided by the language specifically for the purpose, that's your choice;

Pardon, but function names are usually more of a language feature than comments; they're checked by the language, they're part of the syntax... Comments are just bolt-ons. And this IS the purpose of function names; but most people don't use them wisely.

but it's not yet clear to me that it is a beneficial one.

Well, I've given some reasons above. To me, the biggest two are as follows:

1. information can't get out of sync.
2. all information appears in two contexts: actual use (in the code), and prototypical use (in a unit test). Function names will look dramatically bad if they're chosen inappropriately. Comments can be ignored.

Comments can get out of sync with the code, in which case all of their "benefits" go to waste; and they can appear in only one place, and aren't checked there.

Have you ever come across (or written) any material that discuss the pros and cons of your approach?

It's a critical component of Extreme Programming, which is being discussed pro and con in a lot of places. I can also link to a few semi-balanced discussions (good paper, but biased toward the rather management-heavier SEI CMM model, which is needed for some projects). BTW, I was going to provide a con link, but the one I found is BAD -- hasty generalizations are just FLYING. Every single "danger" he cites is completely unjustified by experience and study, and many of the quotes he makes are out of context. It looks more like a Usenet post than a web article.

Oh, here's dmoz's directory page.

Anyhow, to implement what I'm describing you'll need at least Refactoring and Unit Testing from XP's arsenal. There's no reason you should have to adopt more, although once you have those in the others usually can be added at will. You also have to practice egoless programming -- don't be offended if someone changes the name of one of your functions; instead, make sure that the name is still appropriate to the use (if it's not, we have a bug being formed, since the person misunderstood the purpose of the function; you should show him a unit test in which the old name makes sense but the new one doesn't).

To me, function decomposition already serves three purposes: information hiding, code reuse, and divide-and-conquer problem solving. Adding a fourth criterion--of allowing comments to be encoded as function names--seems to raise the possibility that the criteria may conflict, and one may have to be sacrificed for another. Looking at the list, I know which is first on my chopping block.

Information hiding: true, but part of the purpose of IH is exposing only the correct information. That's part of the job of the function's name. So really, these two work together.

Code reuse: how can you reuse code if you don't know what it does? By choosing a good name, you are able to tell when things are being reused, and how appropriate they are to the situation. Note that the first time you extract a function, it'll have a very specific name (because you probably took it from a comment). The first time you reuse that function, you'll probably want to think of a little better name, and you'll probably also make some code changes -- the code worked in the one special case before, but now it has to work in two cases. As you keep reusing, your code keeps becoming easier to reuse; the name and the code keep becoming more general. So those two work together as well.

Divide-and-conquer: indeed, this is important -- but it's hard to argue that bad naming will help your strategy here.

-Billy

I used the internet in Beijing over the summer (over several dialup lines and an ISDN line), and had no problems viewing websites like CNN, Voodoo Extreme, AnandTech, or Astalavista, or telnetting to my university's server.

Specifying gestures by example, Dean Rubine, ACM SIGGRAPH Computer Graphics , Proceedings of the 18th international conference on Computer graphics July 1991, Volume 25 Issue 4

It is a part of the Andrew Toolkit, historical source is at here.

It is a part of OpenAmulet now.

Perhaps a mouse is NOT a stylus.

it's clear you're only talking about Exchange 5.5.

Yes.

E2k has been out for well over a year and doesn't

The next version is always the one that works with MSFT stuff, isn't it?

The corruption of mail store you mentioned on improper shutdown is iffy at best

SCSI RAID system. No faults. No other files lost/corrupted/etc. System on UPS. No improper shutdowns of system that I know of.

Poof. Instant time and space savings, even if spread across 20-30 servers

Yes, this is the advantage of using a database to store messages. However, sendmail will not send a single message 30 separate times to 30 recipients at a remote sever; it sends it once. So the time savings are still there. On the remote system, the single messages gets exploded into X number of files, where X=number of local recipients. This is a downside of using separate files for each mailbox. So, no space savings.

I suppose it would be possible to have procmail strip attachments into files, and have an imapd re-assemble the messages when requested. Or, I could use Cyrus.

It has a unified message store, which is a blessing and a curse. Blessing for efficiency purposes, curse for recovery and migration purposes.

Disney, as the creator of [Pinocchio and the Jungle Book], gave us them to begin with. They gave that much back.

No. DisneyCo gave us derivative works of those stories. Collodi gave us Pinocchio, and Kipling gave us The Jungle Book. And there's no way to fix the bugs I find in the plot lines of most movies (especially many action movies and teen flicks) because they're proprietary.

corporate greed creates issues and Congress's buyability compounds them.

So solving this buyability will solve the problems of patents on obvious inventions, patents on inventions that have clear prior art, effectively perpetual copyright, DMCA, and SSSCA. Where do we start in reducing this buyability?

your attitude re copyright (or what I could get of it from your message) was analogous to the attitude of those people that take open source software and disparage the hobbyists that maintain it

In that case, you could have used the "GPL violation" example.

The folks at Digital Fountain are indeed using a highly-tuned (and proprietary) version of tornado codes. I also recommend the following papers if you're interested in what I think has the potential to be the greatest thing since TCP: tornado codes + end-system multicast

<shameless plug>
I'm currently working on a research project with John and others that integrates tornado codes and end-system multicast into a Freenet-like system. Best of all, it's GPL'd!
</shameless plug>

...that the link to the original lycos at Carnegie Mellon University still works.

I bought one from dynamism.com and installed linux. Comments and details

There are already at least two programs that can translate between C and English:

• BabelBuster
• c2eng2c

--Bruce

All CMU students, check out this and be sure to show up!

My sister is an engineer at VA Tech, and they have one of these deals with MS. If you attend the college, you pay the "Bill bill" and have to purchase Win2k, Office, and a long list of other software. You have to have a machine with certain specs. Part of your money goes to keep some consulting group on campus to do Windows tech support.

Frankly, I strongly prefer CMU. CMU's approach is that you can use whatever you want to as long as you get the work done. They try not to use things like .doc, but if you run into one, you need to be able to handle it.

BTW, if you're thinking about college and like ECE or CS, go to CMU. Seriously. Most colleges are pretty much MS camps...CMU had a bunch of CS faculty hired away a few years ago by MS and is still pissed off about it. As a result, the college is fairly anti-MS. There's an even breakdown in Macs/Win/Solaris boxes in campus clusters, possibly somewhat in favor of Solaris (and a few Linux clusters) because of all the engineering types. Recently, MS wanted to give a .NET workshop, and the professor who okayed them coming was told by the dean to cancel it and apologize to a number of people offended by bringing MS onto campus.

In a game theory class I have, the professor distributed documents as Word files. I thought about asking him to change, then just shrugged and fired up AbiWord. The next day in class, the professor said "due to popular demand, future documents will be distributed as .PDF files". CMU's Computing Services officially supports (some variants) of Linux. All the network people are UNIX folks. All of the for-majors CS classes are taught on UNIXes. My intro to systems class was taught on a cluster of high-end Linux boxes donated by Intel, and operating systems class on Solaris. While most classes accept a Windows format (Prof. Rudich, who teaches a fantastic CS theory class, said on the first day of class "You *can* use MS Equation Editor, but things are going to be painful for you. I recommend LaTeX"), they generally lean toward UNIX. The compilers used are gcc (or sometimes cc, in the case of Solaris). gdb is the debugger of choice. Just about every CS major uses emacs.

In a day when many colleges have a computer science curriculum that pretty much amounts to job training in Visual Basic and Visual C++, it's a nice change.

Anyway, if you don't want to put up with Windows, Windows, Windows, MS, blah, blah, blah all the way through college and want some cool professors, keep CMU in mind.

Cool UNIX CMU stuff includes Festival, *the* UNIX speech synth program,
Coda and AFS, the only good distributed filing systems out there (unless you count InterMezzo, also a CMU project)...it goes on and on and on. CERT has a home at CMU. The guy that was one of the designers of grep's algorithms will lecture to you on it, right after you hear about SML from the guy that was one of its creators. If you like CS research on distributed stuff, computer vision, AI, graphics, you name it, it's probably here.

-- A happy student

My sister is an engineer at VA Tech, and they have one of these deals with MS. If you attend the college, you pay the "Bill bill" and have to purchase Win2k, Office, and a long list of other software. You have to have a machine with certain specs. Part of your money goes to keep some consulting group on campus to do Windows tech support.

Frankly, I strongly prefer CMU. CMU's approach is that you can use whatever you want to as long as you get the work done. They try not to use things like .doc, but if you run into one, you need to be able to handle it.

BTW, if you're thinking about college and like ECE or CS, go to CMU. Seriously. Most colleges are pretty much MS camps...CMU had a bunch of CS faculty hired away a few years ago by MS and is still pissed off about it. As a result, the college is fairly anti-MS. There's an even breakdown in Macs/Win/Solaris boxes in campus clusters, possibly somewhat in favor of Solaris (and a few Linux clusters) because of all the engineering types. Recently, MS wanted to give a .NET workshop, and the professor who okayed them coming was told by the dean to cancel it and apologize to a number of people offended by bringing MS onto campus.

In a game theory class I have, the professor distributed documents as Word files. I thought about asking him to change, then just shrugged and fired up AbiWord. The next day in class, the professor said "due to popular demand, future documents will be distributed as .PDF files". CMU's Computing Services officially supports (some variants) of Linux. All the network people are UNIX folks. All of the for-majors CS classes are taught on UNIXes. My intro to systems class was taught on a cluster of high-end Linux boxes donated by Intel, and operating systems class on Solaris. While most classes accept a Windows format (Prof. Rudich, who teaches a fantastic CS theory class, said on the first day of class "You *can* use MS Equation Editor, but things are going to be painful for you. I recommend LaTeX"), they generally lean toward UNIX. The compilers used are gcc (or sometimes cc, in the case of Solaris). gdb is the debugger of choice. Just about every CS major uses emacs.

In a day when many colleges have a computer science curriculum that pretty much amounts to job training in Visual Basic and Visual C++, it's a nice change.

Anyway, if you don't want to put up with Windows, Windows, Windows, MS, blah, blah, blah all the way through college and want some cool professors, keep CMU in mind.

Cool UNIX CMU stuff includes Festival, *the* UNIX speech synth program,
Coda and AFS, the only good distributed filing systems out there (unless you count InterMezzo, also a CMU project)...it goes on and on and on. CERT has a home at CMU. The guy that was one of the designers of grep's algorithms will lecture to you on it, right after you hear about SML from the guy that was one of its creators. If you like CS research on distributed stuff, computer vision, AI, graphics, you name it, it's probably here.

-- A happy student

My sister is an engineer at VA Tech, and they have one of these deals with MS. If you attend the college, you pay the "Bill bill" and have to purchase Win2k, Office, and a long list of other software. You have to have a machine with certain specs. Part of your money goes to keep some consulting group on campus to do Windows tech support.

Frankly, I strongly prefer CMU. CMU's approach is that you can use whatever you want to as long as you get the work done. They try not to use things like .doc, but if you run into one, you need to be able to handle it.

BTW, if you're thinking about college and like ECE or CS, go to CMU. Seriously. Most colleges are pretty much MS camps...CMU had a bunch of CS faculty hired away a few years ago by MS and is still pissed off about it. As a result, the college is fairly anti-MS. There's an even breakdown in Macs/Win/Solaris boxes in campus clusters, possibly somewhat in favor of Solaris (and a few Linux clusters) because of all the engineering types. Recently, MS wanted to give a .NET workshop, and the professor who okayed them coming was told by the dean to cancel it and apologize to a number of people offended by bringing MS onto campus.

In a game theory class I have, the professor distributed documents as Word files. I thought about asking him to change, then just shrugged and fired up AbiWord. The next day in class, the professor said "due to popular demand, future documents will be distributed as .PDF files". CMU's Computing Services officially supports (some variants) of Linux. All the network people are UNIX folks. All of the for-majors CS classes are taught on UNIXes. My intro to systems class was taught on a cluster of high-end Linux boxes donated by Intel, and operating systems class on Solaris. While most classes accept a Windows format (Prof. Rudich, who teaches a fantastic CS theory class, said on the first day of class "You *can* use MS Equation Editor, but things are going to be painful for you. I recommend LaTeX"), they generally lean toward UNIX. The compilers used are gcc (or sometimes cc, in the case of Solaris). gdb is the debugger of choice. Just about every CS major uses emacs.

In a day when many colleges have a computer science curriculum that pretty much amounts to job training in Visual Basic and Visual C++, it's a nice change.

Anyway, if you don't want to put up with Windows, Windows, Windows, MS, blah, blah, blah all the way through college and want some cool professors, keep CMU in mind.

Cool UNIX CMU stuff includes Festival, *the* UNIX speech synth program,
Coda and AFS, the only good distributed filing systems out there (unless you count InterMezzo, also a CMU project)...it goes on and on and on. CERT has a home at CMU. The guy that was one of the designers of grep's algorithms will lecture to you on it, right after you hear about SML from the guy that was one of its creators. If you like CS research on distributed stuff, computer vision, AI, graphics, you name it, it's probably here.

-- A happy student

I've had to take a long hiatus from my project for various reasons, but now that the appeal was lost, I plan to restart it. On my list of things is to change from my style of translation to Jonathan Baccash's, which is better in several ways, while retaining my code's ability to deal with preprocessor directives (which Mr. Baccash's code lacks). If anyone feels like sending me diffs, I'd be much obliged.

www.contrib.andrew.cmu.edu/~sager

Speech recognition is a pain in the ass. They almost certainly just want to use telephone tones.

Very large dictionary VR is still a little unpredictable, even when they're trained to one specific person. For limitted dictionary (say, a few dozen words), speaker independent(*) VR is an awful lot more successful. One such project was on slashdot a long time ago and has been in development since - Sphinx.

As for picking out spoken numbers, back in the days when I was figuring out how to do simple VR I trained myself to the point where I could recognise a number (between 0 and 30 or so) by only looking at a graph of it's waveform - creating a markov model for that purpose would get results as good if not better.

(* This depends, in Sphinx's case, on the quality of the language model. A language model well suited for recognising mid-west American accents would work poorly on Icelandic... for obvious reasons.)

Ian Woods

postfix,
cyrus-imapd,
squirrel mail,
and procmail

Now for all your backup stuff, write a procmail line to save a copy of all mail. Its really easy. You could extend these tools to do everything exchange does in an afternoon, and continue supporting your outlook clients.

Also, it's a sealed environment, so you don't have to have OS-level user accounts for mail users -- a security bonus.

Ever done any 3d work? I do some pretty crappy stuff but faster processors = faster render time. Same with compiling stuff.

However, I definitely agree with you about improving hard drive / memory

Ever compiled a linux kernel? Done 3d rendering? I do some 3d stuff (just for entertainment, pretty crappy stuff but the rendering is much faster on faster computers.