Slashdot Mirror

er, did i miss flac in there somewhere? It's lossless, fast and compresses quite well....why leave it out?

A very useful and free mail email scanning tool that is fast & GPL. (Please visit the sourceforge link if at all possible).

Mailscaner at Sourceforge

Mailscanner website

I am a fan of AMSN myself.
Specially because it gives you the wonderful oportunity to learn TK/TCL
(just a nice thought only, never get round to it)

I use to like a lot JMSN (which being Java runs on Windows) ..
again can learn JAVA via the source code.
But for some very weird reason I never could make it run on Mandrake.
Worked OK on Suse.
- Not that I would go back to Suse just for one applet's sake ... dread the thought!

I am a fan of AMSN myself.
Specially because it gives you the wonderful oportunity to learn TK/TCL
(just a nice thought only, never get round to it)

I use to like a lot JMSN (which being Java runs on Windows) ..
again can learn JAVA via the source code.
But for some very weird reason I never could make it run on Mandrake.
Worked OK on Suse.
- Not that I would go back to Suse just for one applet's sake ... dread the thought!

Anybody see the need (well, want) for a real open source FPS engine?

Anybody see the need (well, want) for a real open source FPS engine?

Back then I created a project on sourceforge called Mail Receipt. I was way wrong; the idea is as old as the hills.

[goes away to dig further]

Hmmm, seems you are right. Sorry about the semi-snide comment, but my initial search didn't show anything that would indicate that lavc was nothing more than a wrapper around a bunch of codecs, and nothing indicated that the "mpeg4" in its list of dozens of codecs was in fact an original implementation.

From what little I've found, it seems that everyone agrees that lavc and xvid easily beat DivX5, but people have differing opinions about lavc and xvid quality, although many believe lavc is faster in the encode.

Here's one quote - "It seems that libavc gives a (very) little more detailed image. On the other hand, XviD has an excellent processing at high bitrate and shows less 'blocks'."

Is lavc available on Windows for encoding? Sounds like it would be interesting to try, especially wrt it's encode speed for a home PVR solution.

Oh wait, think I answered my own question - ffvfw (http://ffdshow.sourceforge.net/ffvfw.html). Oddly enough, doom9 shows ffvfw encoding *way* slower than xvid, and in reading through their test scenes and comparisons, I think xvid comes out pretty well ahead of ffvfw in terms of quality. http://www.doom9.org/index.html?/codecs-203-5.htm

Of course if I was using Linux, I bet that would make choosing libavcodec a lot easier :)

There ARE 100's of good looks for GNOME, you just haven't looked (and thats why you made that ignorant comment!
Go here and get the best themes for GNOME!
You can also visit this website!

You should try Fedora though since bluecurve looks really slick!

DjVu also supports real text embedded together with the image, plus their position in tscanned bitmap. So you can search for text within a DjVu file. Works really neat.

And [Ff]ree DjVu viewers can be obtained for multiple platforms.

Disclaimer: I work for the company the sells the commercial version of DjVu, LizardTech

DjVu is licensed from AT&T labs, and has both a commercial component and an open source component called DjVuLibre. The technology works by analyzing documents, particularly scanned color documents, for hard edges. Hard edges typically indicate text, while smooth, continuous tones indicate background images. DjVu then "segments" the two types of imagery on the page into different layers and compresses them using different formats for optimal compression and quality.

Okay, enough marketing. While it does have some warts, it's a pretty cool technology to work with. That, of course, and I'm happy to have any job these days.

I see I'm not the only one with one. The nice things about it is that it's built like a tank (weights it too), and can handle legal size. The only downsides is the resolution isn't as high as modern scanners, and that sheet-feeder is bulky.

Anyway I run the output through this and a bit of OCR (doesn't have to be perfect), and store it in a Database.

• Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS. Currently, Bochs can be compiled to emulate a 386, 486, Pentium, Pentium Pro or AMD64 CPU, including optional MMX, SSE, SSE2 and 3DNow instructions

This was made possible by a Pocket PC port of Bochs, a DOS emulator.

Not quite. Bochs is a IA-32 (x86) emulator that allows other architectures (such as ARM commonly used in handheld devices) to emulate a IA-32 chip.

From the website:

Bochs is a highly portable open source IA-32 (x86) PC emulator written in C++, that runs on most popular platforms. It includes emulation of the Intel x86 CPU, common I/O devices, and a custom BIOS.

...they fired up Ettercap on a switch and watched the packets?

Network administrators in corporations have been doing that for many years now (at least where I work), although they tend to use it to debug and track down virii.

OK, this idea goes way back to CoreWars. PHP or Redcode? Hmm. Not so easy to decide ... :-)

A future version could offer the option of running the filesystems in userspace if you want.

There are two separate systems for doing this in Linux today: LUFS and FUSE.

I don't believe anyone's bothered to port the existing kernel-based filesystems to either because they, y'know, work and are faster, but it would be possible to do so.

A future version could offer the option of running the filesystems in userspace if you want.

There are two separate systems for doing this in Linux today: LUFS and FUSE.

I don't believe anyone's bothered to port the existing kernel-based filesystems to either because they, y'know, work and are faster, but it would be possible to do so.

I've followed this thread with interest, but now that I've gone looking for this libavcodec, all I've found is that libavcodec wraps ffmpeg which supports a large number of actual video codecs (http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC 19), which includes "FFmpeg Video 1".

So my question to you is, what actual video encoding codec did you have libavcodec/ffmpeg using? Was it in fact "ffmpeg video 1"? Or was it another? There are a lot of different video codecs in the above reference that ffmpeg/libavcodec can encode with.., and ffmpeg video 1 is noted as being "lossless", which doesn't sound like something that could compete against any type of mpeg4 at the same bitrate...

I seriously don't think you actually know what codec you happened to be using, just that it was wrapped up in the libavcodec library being used by mplayer.

Second-guessing who's behind it is a waste of valuable time. Unless you believe in fairy tales, it will almost surely never be known who exactly is financing the effort. We can infer that whoever it is, they have a desire to influence public opinion. That is, after all, why people write books.

A better use of time is to think what your Windows-running friends might like: burn copies of OpenOffice for Windows or Freeduc or KnoppiXMAME, all of which will run or boot from Windows machines.

Help someone new fall in love with free software...today!

I think Mac OS X is structured like a microkernel but everything's compiled and statically linked together for speed. With this setup, you can have your clean design but you still get rid of the context switches. That said, the design itself will impose some overhead (though the tradeoff may be worth it).

Another solution is to use a safe language to eliminate the need for address space separation and let the kernel JIT code when it's loaded. Compilation techniques for safe languages are getting better and better so performance is becoming less of an issue. One example is Brix, which runs everything in kernel space (even applications).

However, I don't know how you would deal with a misbehaving process in a shared address space (i.e. how would you write an OOM killer?). The Spin OS has a way of detecting badly-behaving code, but I think that dynamically-loadable code is restricted in what kind of functions it's allowed to perform.

The Geronimo Project has been working on this same copncept for about 2 years now. Why reinvent the wheel?

I was pretty fed up with autoconf myself, and wrote a little C app to emulate it. Initial ./configure time dropped to a second and reconfigure is instantaneous. I would recommend it for your simpler projects: bsconf.c and bsconf.h, the latter being the configuration file.

I was pretty fed up with autoconf myself, and wrote a little C app to emulate it. Initial ./configure time dropped to a second and reconfigure is instantaneous. I would recommend it for your simpler projects: bsconf.c and bsconf.h, the latter being the configuration file.

You can find it at pmk.sourceforge.net

Or else, you can have a look at A-A-P, by nobody else than Bram Moolenaar, the author of the One True Editor, a.k.a. ViM :-)

There is also Package-framework, by Tom Lord, the author of the infamous Arch SCM.

I was about to mention SCons, too, but other people already did (it always pay to check other comments just before posting, especially on /. :-)

To sum it up : there is no shortage of alternatives to the incredibly hairy Autoconf/Automake nightmare. The problem is, people are still using them for the very same reason they use CVS instead of Arch/Subversion, or Sendmail instead of Postfix/Exim : because they're considered ``standard'' tools, and people feel more comfortable with software they know to be used by plenty of other people (millions of programmers can't all be wrong. Can they ?). I really hope they'll stop making this kind of mistakes soon, so I won't need to curse them everytime I have to debug some Autoconf breakage...

The open source Clubdata project might be of interest.

I'll second that! The MSP430 is a really fun MCU and easy(fast) to get started with.
You'll get a devkit (with JTAG programmer) from Olimex for cheap (~20$).
And it works fine with MSPGCC.
This page holds your hand during your first gdb session.

I've used this setup in several projects with no real problems.

Yeah. I hear it uses WASTE.

You've already found gputils its a great place to start...

For the pic16f and 18f series also check out the small device c compiler (works with other MCU's too).

There is a related GNU pic site at www.gnupic.org it lists pretty much everything you might need.

You asked about development tools for platforms other than windows - but in true /. style i'm going to ignore that: :p

winpicprog - i've found is quite good, i've yet to find anything in linux or bsd quite as complete...
-----------
As far as programming resources go since I'm actualy focusing on compiling c code for the pic using sdcc i've found that:
Nathan Hursts page on sdcc and the pic14 port (for pic 16 series)
and
Martin Dubuc's pic16 port
have been invaluable resources.

I've been using the BASIC Stamp Tools for Linux for a while now. It uses the (unfortunately) beerfree parallax pbasic tokenizer so. If you don't want to use the BS, the Atmel AVR series is well supported by open source software, and really fast as well (native code vs. interpreted).

EFF's solution has been to quietly accept e-gold since 1999. Freenet takes e-gold, too.
http://102948-USD10.e-gold.com would give a gram to EFF (they had it working before, and now they've somehow managed to bust it! Sigh...).

http://767764-USD20.e-gold.com
donates $20 worth to Freenet (or you can use their page at donate )

We may not have the hype or marketing-budget of other systems, but we've been around since 1996 (and, frankly, Slashdot should have taken e-gold since at least a year ago, it's not like sci.e-gold.com is all that hard to use!). (And yes, I'll still click anyone from Slashdot a bit of e-gold to play with if you send me an account number!)
JMR

Speaking ONLY for Jim Ray, the Barbarous Relic of the e-gold system!

Ndiswrapper is supposed to do the same thing as Linuxant, I believe, although open source.

http://ndiswrapper.sourceforge.net

Jeff Raskin can take a hike as far as I'm concerned.

Apple should still be listening to Tog he has some good ideas.

.*SEXUAL(LY)?.*EXPLICIT.*

BEAUTIFUL--SEXUAL----MONKEYS---EXPLICT!!

.*SEXUAL(LY)?.EXPLICIT.*

Use OpenVPN. It is more secure than CIPE and is carried over UDP - just like CIPE. In fact, OpenVPN can be used many places where IPSec can't because it is tunnelled over UDP, whereas IPSec requires its own protocol. I am using it on dozens of machines running RedHat 7.2, 7.3, and 9. Should be no problem with Fedora.

Fractal, schmactal. Hacked-2-Basics lets you "play" a VT100 like a musical intrument, with sounds derived from things like the Linux kernel and DOOM.WAD interpreted as 8-bit mono PCM samples. Uses pure write(2) to /dev/dsp. Written to run on computers so low-end that a musician can set fire to them onstage.

Yes, I'm blabbering about my own musical project but so is everyone else on this story.

Therefore, if these particles are capable of replication, they must rely on some host cell for additional complex components, which places them in the category of 'not-truly-alive-on-their-own', like the viruses.

At this time, it is more correct to refer to these things as 'nano-spheres', NOT 'nanobacteria'.

mhack

Net Sprocket has been Open Sourced and merged with OpenPlay. It is currently a mature and working product for Mac OS 9, OS X, Win32, and Linux. The Posix version could probably be built on just about any Posix OS.

Apple's OpenPlay site
OpenPlay on SourceForge

Another program (written in Java incidentally) which among other things generate music: Grammidity

It works on the "evolve" principle where you "mate" two objects, and then let either the user or some algorithm decide which of the children are most successful and can evolve further.

Any ideas?

The obvious suggestion, of course, is to get it pre-compiled from Fink. They apparently are on an older 1.11 version, but I'd imagine they'll try to backport security fixes quickly... maybe.

The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs :pserver on the internet. Instead run cvs :ext over ssh. That won't necessarily stop authorized users from escalating their privs (although for this exploit it does), but should totally protect you from "cold calling" attacks.

As for those specific error messages- I don't have a Mac with me here, but I've noticed before that the OS X setup of standard libraries is different from what BSD (and Linux and other Unix) normally use. They don't have the same library files much source code assumes it can find, so the Apple-provided compiler makes some secret substitutions to allow software to build. But that's guesswork, and it can sometimes guess wrong, producing inscrutable situations until you sit down with "nm" and "ld" to work out exactly what's happening. (Probably more trouble than it's worth)

Any ideas?

The obvious suggestion, of course, is to get it pre-compiled from Fink. They apparently are on an older 1.11 version, but I'd imagine they'll try to backport security fixes quickly... maybe.

The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs :pserver on the internet. Instead run cvs :ext over ssh. That won't necessarily stop authorized users from escalating their privs (although for this exploit it does), but should totally protect you from "cold calling" attacks.

As for those specific error messages- I don't have a Mac with me here, but I've noticed before that the OS X setup of standard libraries is different from what BSD (and Linux and other Unix) normally use. They don't have the same library files much source code assumes it can find, so the Apple-provided compiler makes some secret substitutions to allow software to build. But that's guesswork, and it can sometimes guess wrong, producing inscrutable situations until you sit down with "nm" and "ld" to work out exactly what's happening. (Probably more trouble than it's worth)

Seriously, your solution to the problem makes the source closed to the world and only open to input from 'trusted' people. Managing the list of trusted people would be a huge job on a large project where a million code monkeys are contributing.

Oh my! Here's another poster with no idea how OSS actually works.

Guess what: there really IS a small list of trusted people, and somebody works manage which of the million possible helpers deserves to

Handling "millions" is actually a simple problem for a computer programmer. Any good coder is familiar with binary tree division, which allows you to handle lists of any size with just a few (max ~7) layers of hierarchal control.

If you want to restrict contributions to people you really trust then don't put your CVS repository on a public server.

Try this: go over to sourceforge.net, pick a random project, and add a file into the CVS tree. Good luck, you'll need it. The only way you can contribute is to convince a live human project-member that your code is worthwhile.

All you'd really need to do is put together a UI and an indexing service... both easy to do with .NET and not terribly difficult to do with Java.

Oh, I think some of those products also index the messages stored in your e-mail client. Not sure how you'd go about that... but at least you could leave an API so somebody else who knows could do it.

Dude, you need to download and install JunkMatcher. It works awesome in compliment to Mail.app's built-in filter, and it's free as in beer.

Native Win32 ports of grep, tail and just about most unix tools

enjoy

No, you aren't.

Grab smartmontools and run them on your drive (like "smartctl -a /dev/hda" or similar). Most SCSI and most newer ATA drives will maintain a SMART error log of any defects/problems. smartmontools will also print drive attributes (for most drives) that can tell you when a drive is about to fail, before it actually does.

Enter JunkMatcher Central.

it uses rules based filtering to complement Mail.app's methods. And, as a bonus, you can have it mark what it finds as junk mail, which trains mail.app.

It requires some tweaking, but is great, updated often, and free!

It's called mplayer. For the Windows users, use Media Player Classic with Real Alternative (among other download sites).