Slashdot Mirror

I think what people are losing site of here is the options you are provided with in OpenSource. While on a Windows platform there are relitivly few companies that make server software(ie FTPd, http), while on the OpenSource Platforms there are many more choices.

How many people would run WuFTPD on a production box while there are other options around like Pure-FTPD or ProFTPD?

But for windows for example there are relitivly few closed source HTTP Servers. Namely IIS, while on the open source side there is everything from Apache to Abyss.

So what this brings me to, another point of Open Source Software, because there are many *options* in a production enviroment for the choice in software, the only costs of changing to a product that is more secure is the time to install it. While in closed source to get Microsofts newsest and most secure IIS 6+++ bundeld with Windows ZP 2003, you will have to shell out a few grand. Thats where security matters in the end, how much money does it cost you in a production enviroment. We are a bunch of capitalists at heart you know :-)

I think what people are losing site of here is the options you are provided with in OpenSource. While on a Windows platform there are relitivly few companies that make server software(ie FTPd, http), while on the OpenSource Platforms there are many more choices.

How many people would run WuFTPD on a production box while there are other options around like Pure-FTPD or ProFTPD?

But for windows for example there are relitivly few closed source HTTP Servers. Namely IIS, while on the open source side there is everything from Apache to Abyss.

So what this brings me to, another point of Open Source Software, because there are many *options* in a production enviroment for the choice in software, the only costs of changing to a product that is more secure is the time to install it. While in closed source to get Microsofts newsest and most secure IIS 6+++ bundeld with Windows ZP 2003, you will have to shell out a few grand. Thats where security matters in the end, how much money does it cost you in a production enviroment. We are a bunch of capitalists at heart you know :-)

ALSA = lowlevel soundcard drivers
JACK = highlevel audio (PCM) API

So JACK is using ALSA to output audio. The nice thing about JACK is that it's the first serious attempt in the Linux (Unix) world to get a professional audio API in the hands of developers. SGI's dmSDK was promising but that project seem to have stalled, i.e. no open development going on (no CVS). JACK also replaces arts and esd when it comes to multiplexing audio output. The only problem is that developers may find they have to redesign their whole audio application in order to fit inside the JACK (callback based) framework.

A typical Linux/Unix audio application opens a special file and starts writing the audio data to it. The application will block on the write() (or read() when recording). This works fine for simple things like playing an mp3 or doing some window manager sound. It gets hairy when you try to sync multiple audio applications and achieve low latency at the same time. With jack this is as easy as pie, because the applications are driven by the JACK callback. So when it is time for the soundcard to get its next buffer JACK simple calls the process() function of all the connected audio applications. Every application has the chance to insert its own piece of audio data (or inspect what's already there), all app will always write the exact same amount of samples per callback, which keeps them in perfect sync. You can also do cool things like create your own ports and wire JACK aware apps together. In short, it rocks :-) ..and it makes Linux a worthy competitor to OS X's CoreAudio.

More on this at the JACK website

Shameless plug :-) AlsaPlayer was the first released JACK app, mainly because of its BeOS heritage (the internals work exactly like the ancient BeOS audio_server, which was callback based).

-adnans

DivX 4 is based on the MoMuSys MPEG4 implementation. The license for this specifies that derived versions must remain compatible with the MPEG4 specs, so DivX 4 is basically the same as MPEG4 (but DivX uses AVI as a container format instead of QuickTime). FFmpeg has a codec for MPEG4, and it can play most DivX 4 videos.

http://ispman.sf.net

If you can code a bit of perl etc, try using this project for your isp and help us improve it.

good luck.

If I decided to stop using that software, is that EULA still binding?

Some clauses in the EULA for AOL Instant Messenger 4.0 and later are labeled to "survive termination of this License." Because one of those terms said that I couldn't use third party software to access AOL's servers, I clicked "Disagree." My winbox still runs AIM 3.0, whose EULA doesn't have such restrictions.

If it is still binding, for how long?

In perpetuity, unless you believe in reincarnation.

Fact: EULAs can last longer than the copyright on the software (which is nearly perpetual anyway).

If I decided to stop using that software, is that EULA still binding?

Some clauses in the EULA for AOL Instant Messenger 4.0 and later are labeled to "survive termination of this License." Because one of those terms said that I couldn't use third party software to access AOL's servers, I clicked "Disagree." My winbox still runs AIM 3.0, whose EULA doesn't have such restrictions.

If it is still binding, for how long?

In perpetuity, unless you believe in reincarnation.

Fact: EULAs can last longer than the copyright on the software (which is nearly perpetual anyway).

I did a superficial investigation on source control systems, and found some very interesting really free ones, like Aægis.

Does someone know if free alternatives to BK were considered, and if so why a semi-free one was choosen? If BK was better, specifically how it compared to Aægis and other alternatives?

My SF project is an IM protocol library used in about 10 IM clients (libyahoo) and another SF project is a client based on this library (GTKYahoo).

I'm sorry to say that of all the people in my two AUTHORS files I think only one was a girl and she didn't do any developing; only testing. I wish more girl geeks "did OSS" but IM doesn't seem to be an arena I've seen 'em in.

Maybe the Jabber ppl can comment.

My SF project is an IM protocol library used in about 10 IM clients (libyahoo) and another SF project is a client based on this library (GTKYahoo).

I'm sorry to say that of all the people in my two AUTHORS files I think only one was a girl and she didn't do any developing; only testing. I wish more girl geeks "did OSS" but IM doesn't seem to be an arena I've seen 'em in.

Maybe the Jabber ppl can comment.

First of all, there's simple biology. Guys and gals are different, as we all started noticing in grade school. Guys tend more towards sciences; girls more towards the humanities. Certainly, there are a number who do just the opposite. But think of the twin stereotypes of the high-school social outcast: the poetry club and the computer club. Which is going to be predominantly male? Which predominantly female? It doesn't take a genius to figure it out.

It's tough for girls to break into the geek clique, because we guys, having been deprived of female company, have a certain degree of trouble viewing the female members as other than date material. Think back to when you were in high school and college: the few girls who were into computers and technology were probably constantly being pestered and/or fawned over. Some gals can put up with that; some even enjoy the attention. But for others it makes them quite uncomfortable. So a group which is predominantly male becomes even more so, as females are driven away by testosterone poisoning.

Lastly, I figure that women are not nearly as idealistic as men. Think about it: we guys are not exactly down-to-earth. We philosophise; we blather on about the big picture; we act very silly indeed. Women are, I believe, rather more practical. And--let's face it--Free Software is not exactly the most practical course to follow. It appeals to the idealistic adolescent male mindset, the sort which dreams of dying for some girl, of fighting the good fight, of generally being a bloody nuisance &c. Heck, it's why I'm writing !

true, swapping (actually, its technically called paging - swapping generally refers to moving an entire address space between RAM and a storage device) is the end for such systems. however, the design of the VM code affects things long before we get to swapping. in particular, it interacts in important ways with the buffer cache, which can affect streaming performance on most filesystems. ps. you'll love ardour even more when its finished!

The answer is a definate maybe. The problem with Linux PDAs is that they all use their own data format, and more often than not, not follow any standard. What a Linux PDA lacks (and something I'm putting into my PDA environment, DynaPad) is a data-store like that of the Newton. On the current generation of Linux PDAs, most syncing seems to be achieved by coping TXT or XML files, or in some cases, having a sync app. However, this sync app doesn't know about new databases and records, other than those it's been explicitly told about- and this is more often than not limited to Contacts and Dates. It's really quite sad.

PicoGUI's still in need of developers, authors, and artists. We need developers to write PicoGUI applications and help debug/extend/port pgserver. We need authors to write more documentation. We could even use some artists (preferably with some programming knowledge) to make some more themes. If you're interested in helping, join the pgui-devel mailing list or stop by the #picogui IRC channel on irc.openprojects.net.

PicoGUI's still in need of developers, authors, and artists. We need developers to write PicoGUI applications and help debug/extend/port pgserver. We need authors to write more documentation. We could even use some artists (preferably with some programming knowledge) to make some more themes. If you're interested in helping, join the pgui-devel mailing list or stop by the #picogui IRC channel on irc.openprojects.net.

Why windows does not run off a ramdrive. I mean, modern PCs all have at least 512MB ram, why not load up Windows once, and then never access the disk drive again?

In fact, many if not most minimalistic Linux distro's do this. Specifically, Linux Router Project do this. I use it extensively. The kernel boots and the file system decompresses to a RAM drive. It's very fast.

The guys over at XviD have almost fully rewritten OpenDivX from scratch in GPL'ed code - it's now running faster than both DivX 4.12 and the old DivX 3.11 (MS-MPEG43), as well as creating smaller files with identical quantizers (a standard measure of motion estimation efficiency). MPEG4IP are working on a complete .MP4 file format implementation, also. -h

No, it's slow because of a combination of low-memory and running some things out of flash ROM. ROM is slower than RAM.

The Agenda did not remotely have any serious human factors involved in the hardware design.

It/s not as bad as you say. I carry mine everyday, never have problems with it's design. Reportedly the VR3Rechargable that never made it to market was thinner.

The user interface was badly designed.

It's an excuse, but it's under GPL. Look at AGToys and numerous other projects where people re-designed it. I think if Agenda had had more time and $$$ to hire a couple usability nerds, it would have gone much better.

Agenda's web site really didn't contain a whole lot of information that was helpful and only contained a few pieces of documentation here and there. There seemed to be this attitude of "if you want help or support or information, check out the agenda community".

You and I agree on that one. Luckily the community is still quite strong.

I bought one. I enjoy it. I wish I had more time to develop on it. I wish it had 16MB. I wish they didn't go out of busines. But what the hell, I've had fun.

...reminds me of the ShowEQ project, months ago, feverishly releasing fixes for changes made by Verant. Not all of those (if any) were intentional, though.

First, obviously any minimally decent relational-like, even SQL database is better than any non-relational (object, hierarchical) one &ndash& before proceeding please read Database Debunkings. So substituting MS SQL Server for NTFS should be A Good Thing(tm).

Second, SQL isn't a good implementation of the relational model... so it doesn't matter what's the management system behind it (MS SQL, DB/2, Oracle), if it's SQL it's not ideal -- a really relational system should be faster, have less arbitrary restrictions, and do everything a hierarchical or OO database management system could possibly do. But still SQL would be far better than any hierarchical or OO filesystem.

Third, as a SQL implementation MS SQL isn't quite ideal, and Jet (Access, Exchange, the registry) is simply horrible. So while this will probably improve Windows feature-wise, it will make Windows even more bloated, perhaps even less stable and slower. But if they manage to fix the database engine, it could even make Windows faster and more stable.

Fourth, this has already been done. By Oracle. It's called iFS (sorry but I couldn't access Oracle site to get a better page), and exports SMB and other filesystems. As Oracle is too big, proprietary and isn't even SQL compliant, and iFS does not support NFS, I didn't care much about it, but I may have an opportunity to use it as a kind of version control for binaries very shortly.

Last but not least, this idea should be adopted by the Free Software comunity ASAP. We should create a really relational implementation, ideally based on Tutorial D -- there's already a SourceForge project, but nothing has been done up to now. Then this would became a Hurd filesystem (because of Hurd's flexibility) to be ported to Linux. That would blow Longhorn out of water.

If we don't do it better than Microsoft, and if computers continue to get faster and Windows less unreliable, we could have serious competition, say some two or three generations after Longhorn.

MediaXW is doing the trick for me. Adds the required mime-type handling, so clicking in your browser opens up media player and starts to play the stream.

it doesn't bode well for mass acceptance if it takes more than a miniscule amount of effort to make it work.

With this, it's no more effort than, say, Quicktime. Download the player/plugin - install it, the end.

Cheers,
Ian

You don't get the point.

You can't simply fix a broken protocol by tunneling it over a secure connection. IRC wasn't made with security in mind, and it shows. Stunnel is no more than a temporary and very dirty hack, until something better shows up. That might be SILC, or this project I've started along with a few other IRC addicts: CIRCUS.

Then there's other fixes regarding network scalibility, for instance. And don't forget the boom of IM in the last few years, which has shown quite a few features which IRC is lacking, and an updated protocol might take a shot at improving user experience, going way beyond what IRC can offer.

Pickling is really trivial. Hell, I've worked on a pickler for C++. Perl has a plethora of picklers (say that 10 times fast), including Data::Dumper, FreezeThaw, and Storable. Then there's Java's Serializable. It's really not a terribly interesting problem, orthogonal persistence is. Orthogonal persistence where you have an interpreter or other such runtime environent that can be started and stopped and moved around in the meantime, possibly with multiple processes attached to the runtime simultaneously. The "orthogonal" means that you don't do anything special (like pickling) to persist objects and retrieve them from the persistent store, they're just there when you want them, and their lifecycle is indefinite when you create them.

Any programmable MUD is an example of such orthogonal persistence. Squeak and Self would be others. Personally I wouldn't mind such an environment for Python, but I'm not holding my breath.

...and found esky, a purely userspace checkpoint/resume implementation.

KStars is part of KDE and also in Debian. It's much better and under active development.

David

Requires you to download a newer JVM. Not a big deal.

Hard as hell to get connected to another client, because there's no central server.

It's not turnkey. You must search and find peers to put in your hosts file. It doesn't work 'out of the box'.

There's no way to search for files.

Download speeds are poor, due to encryption and other factors relating to anonymity, I believe

Frequently, files will download partially or with zero length, but have their correct name, implying it is complete. (Morpheus/KaZaA use temp names until a file completes, which is nice.)

Freenet runs a small web server for configuration and retrieval. The web interface is 'programmer friendly', but not user friendly.

Files must be 'inserted' into the network. This is a pain if you're trying to share 40gb of mp3 files, or change what is shared daily.

Frost is a Freenet client which supports discussion boards and keyword-searching. It requires that you have already installed Freenet, but works well. It has an active community of users, and continues to be improved on a daily basis.

We did a significant amount of work in this vein with Swarmcast and have been building a lot of the (rather complex) technology necessary for Reliable Multicast

Multicast is not panacea though, because it is not very widely deployed on the Internet, and since there is no caching in Multicast, all of the receivers must be downloading near the same time to realize the bandwidth savings...So in many ways P2P caching has advantages over multicast, which is why we do both.
--
Justin Chapweske, Onion Networks

It's amazing how closely this lawsuit coincides with the release of Napshare v1.0. Napshare v1.0 being the best Gnutella client out there.

Based loosely on GTK-Gnutella, it has the best features I've seen in any type of downloader. You feed it a string to search for, the minimum file size, a string that the files SHOULD NOT contain, and the minimum server speed if you like. (someone I know *cough**cough*) personally downloaded Jurassic Park 3 and Pulp Fiction in the past 2 days since they got Napshare... and that's 700MB/piece over a SLOW cable-modem (30KBps/7KBps).

Did I mention it's been running for two days constantly, under heavy load, without any memory leaks, and not a single crash.

...which I suspect is what they're doing.

It's easy (almost trivial) to instrument a parser to build (say) a Python data structure representing a tree (I wrote some code to do this a while ago; see the CVS repository of http://sf.net/projects/dtct, and please try not to laugh). Applying a diff algorithm to a parse tree (or putting it back out into text and running diff on it, or comparing varieties of text, and so forth) is really quite simple, and not so prone to many workarounds as the system you mention (where using inlines, macros, pragmas modifying compilation &c could have significant effect).

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

Multithreading is found in the commercial Common Lisp environments and in the CMUCL/x86 port. CLOCC maintains several libraries for cross-implementation usage of non-standard features such as networking. CLIM solves the GUI problem, the problem is that there was no free CLIM implementation for a long time due to legal issues. Finally, a free CLIM is being developed: McCLIM and I'm sure they can use help. As for iteration, perhaps your mind has been clouded by Paul Graham; who has an irrational fear of the LOOP macro. The LOOP macro, however, provides one of the most powerful iteration constructs I've seen; and it's not parenthesized like the DO macro is. Example:

(loop for x from 1 to 10 summing x do (format t "~&~A" x))

Prints out a list of numbers from 1 to 10 and the sum of them all at the end.
The equivalent DO:

(let ((sum 0))
(do ((x 1 (1+ x)))
((> x 10) sum)
(incf sum x)
(format t "~&~A" x)))

Also the LOOP macro provides yet more keywords for all sorts of handy features which aren't so easy to do with DO; collecting, appending, finally, initially, if/else, etc... Please read the section in the HyperSpec about LOOP, Section 6.1
I even once wrote a finite-state-machine entirely within a single LOOP macro that processed the Unix mbox format. It's quite nearly a language in itself (speaking of which, FORMAT is in a similar category, except for formatted output instead).

I would argue that CL is better at bit-twiddling than C is. Take a look at the CLHS Section 12.1.1.3.2 and the functions BYTE, LDB, and DPB. It's a different perspective than the C view, but more interesting since you can extract and replace any number of bits that you want. Also it's not dependent on 8 bits per byte.

Still, there are many areas where CL just doesn't have the sheer effort put into the libraries, likely due to the lack of manpower. Particularly in the Free-software category; Lisp has a tradition extending long before the current wave of Free-software and while many commercial vendors will provide good support and lots of libraries, the Free implementations often lack this. Many Lisp programmers use the commercial Lisps and have the features they want; if not they ask/pay the vendor to implement them. Another issue is that Common Lisp is not Unix-centric, unlike *ahem* most popular languages today. CL was designed to be workable in any environment, so the designers could not take shortcuts with things like pathnames, executable formats, system libraries, or other system-dependent issues. After all; Common Lisp was conceived in the era of the Lisp Machine. Unix was just another OS in the vast array. Finally, it is unfair to compare the Common Lisp standard against a single-implementation language such as Perl. Standards cost $$$$$ and require a great deal of effort and responsibility. If a Common Lisp implementation does not comply with the standard then it is at fault. But with Perl, whatever Larry Wall does goes. Even if it breaks all your code; too bad.

Some interesting sites with regard to libraries:

• CLiki
• cCLan

(Back to the OP's topic) Franz's Success Stories has plenty of examples of Lisp applications. Franz develops Allegro Common Lisp, a popular commercial CL.

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

Multithreading is found in the commercial Common Lisp environments and in the CMUCL/x86 port. CLOCC maintains several libraries for cross-implementation usage of non-standard features such as networking. CLIM solves the GUI problem, the problem is that there was no free CLIM implementation for a long time due to legal issues. Finally, a free CLIM is being developed: McCLIM and I'm sure they can use help. As for iteration, perhaps your mind has been clouded by Paul Graham; who has an irrational fear of the LOOP macro. The LOOP macro, however, provides one of the most powerful iteration constructs I've seen; and it's not parenthesized like the DO macro is. Example:

(loop for x from 1 to 10 summing x do (format t "~&~A" x))

Prints out a list of numbers from 1 to 10 and the sum of them all at the end.
The equivalent DO:

(let ((sum 0))
(do ((x 1 (1+ x)))
((> x 10) sum)
(incf sum x)
(format t "~&~A" x)))

Also the LOOP macro provides yet more keywords for all sorts of handy features which aren't so easy to do with DO; collecting, appending, finally, initially, if/else, etc... Please read the section in the HyperSpec about LOOP, Section 6.1
I even once wrote a finite-state-machine entirely within a single LOOP macro that processed the Unix mbox format. It's quite nearly a language in itself (speaking of which, FORMAT is in a similar category, except for formatted output instead).

I would argue that CL is better at bit-twiddling than C is. Take a look at the CLHS Section 12.1.1.3.2 and the functions BYTE, LDB, and DPB. It's a different perspective than the C view, but more interesting since you can extract and replace any number of bits that you want. Also it's not dependent on 8 bits per byte.

Still, there are many areas where CL just doesn't have the sheer effort put into the libraries, likely due to the lack of manpower. Particularly in the Free-software category; Lisp has a tradition extending long before the current wave of Free-software and while many commercial vendors will provide good support and lots of libraries, the Free implementations often lack this. Many Lisp programmers use the commercial Lisps and have the features they want; if not they ask/pay the vendor to implement them. Another issue is that Common Lisp is not Unix-centric, unlike *ahem* most popular languages today. CL was designed to be workable in any environment, so the designers could not take shortcuts with things like pathnames, executable formats, system libraries, or other system-dependent issues. After all; Common Lisp was conceived in the era of the Lisp Machine. Unix was just another OS in the vast array. Finally, it is unfair to compare the Common Lisp standard against a single-implementation language such as Perl. Standards cost $$$$$ and require a great deal of effort and responsibility. If a Common Lisp implementation does not comply with the standard then it is at fault. But with Perl, whatever Larry Wall does goes. Even if it breaks all your code; too bad.

Some interesting sites with regard to libraries:

• CLiki
• cCLan

(Back to the OP's topic) Franz's Success Stories has plenty of examples of Lisp applications. Franz develops Allegro Common Lisp, a popular commercial CL.

the full copy only really included Real Player, most of the other stuff (MP3 encoded for example) you could get of BeBits.

Or, you could wait a bit, and get OpenBeOS or BlueOS. The latter of which is based on Linux.

mlk

Spam is Free Speaaech (A Troll)

No it isn't (Baittaker543)

Yes it is (Anonymous Spammer) 30 post thread snipped

My webserver got RBL'd (warfire) So I've come here to cry instead of ditching my low-file ISP. Your technical solutions are no good.

I know more than you do (karmawhore23) I am cleverer than you.

• mail and news
• browse the web
• access ftp sites

These are really the primary applications. Multimedia is of limited relevance in third world countries. None of these applications requires a high-end computer. Even web-browsing can be done on an old 486 if text-mode browsing is acceptable (and thanks to open-source developers, browsers like links, lynx and w3m keep getting updated and are capable of viewing most online text).

So anything from a 486 onward can be used to access the Net (and to develop software) if you use a low-footprint system like Linux. We're talking about computers that can be bought for 20 bucks and less. Add another 30 bucks for an old 14" and a modem, and you`re all set - the software is free.

The "digital divide" is only a symptom of a far larger problem, the economic divide between the north and south. If you can't afford food, you are unlikely to care about Internet access. However, if you have your basic needs met, getting a cheap system set up is completely viable.

The real problem in doing so with Linux is knowledge: While there is information about everything you need to know somewhere, the information you find online and offline is of very varying quality. Without a rating database to find the most relevant texts (such as this free Linux book from South Africa) people will simply not know how and where to start. Future Linux distributions will have to become knowledge portals, guiding the user to information about everything from software development to system administration. While the distros already come with a lot of docs, many of them are not introductory, and many of the good free books are missing.

have you tried fink?

once you get it installed all you need is
$ sudo apt-get install xfree86-server
and you've got x installed!

Those are both very interesting projects. Since the superiority of deb format is universally acknowledged, I'm surprised that anybody would consider its dumber sister. Debian distribution is famous as the one that you can upgrade to the next version just by typing "apt-get dist-upgrade". That's very powerful package management. Add to this the huge number of software packages that have already been Debian format and are being actively maintained by Debian package maintainers who seem to be only too keen to share their knowledge of the format...

Those are both very interesting projects. Since the superiority of deb format is universally acknowledged, I'm surprised that anybody would consider its dumber sister. Debian distribution is famous as the one that you can upgrade to the next version just by typing "apt-get dist-upgrade". That's very powerful package management. Add to this the huge number of software packages that have already been Debian format and are being actively maintained by Debian package maintainers who seem to be only too keen to share their knowledge of the format...

Sourceforge, part of VA Software, disables downloads from Simply GNUstep, a project they host....

...after Slashdot, another part of VA Software, posts a story about it.

Way to support the community, guys.

I've been working for about 4 years now on a graphical user interface for dos as a pet project, and have learned a great number of things. So many, in fact, that i'm in the middle (still) of rewriting it. If you're intreseted, the website is http://dwin.sf.net/ and is open sourced. When the new version comes out (or the next preview) one could use it to see how it all fits together. This would be better then trying to use XWin to learn how everything works because it is smaller, simplier and very OOP (which is great for windowing systems). And yes, most of /. will call me crazy for reinventing the GUI, but heck, i've learned so much about computers in doing it that it's been a real fun time.

-Jon Gentle(atrodo@atrodo.org)

looks obvious enough to me with the 'ADVERTISEMENT' label + bounding box (and the Junkbuster scaled image inside due to my proxy).

There was a project which tried to clone MacOS X for x86.
It was based on GNUstep. It's dead now.

I started a project a while back to write a web based schema builder. Initially it was for my project (ispman) and I wanted to write the tool simply to get my hands dirty with schema stuff (i learn like that).

Its avaialable for demo at
http://ispman.sf.net/schema/editor

Its incomplete (should work as proof of concept). So if anyone interested to work on it let me know.

You can dl the source and look at the algorithms yourself.

lzip. Or just read this snippet from their faq:

1. What is lzip?
Lzip is the most advanced file compression utility ever conceived. It is literally years ahead of gzip (though admittedly gzip was around first), and makes use of mathematical transforms the bzip developers have never even heard of. The practical upshot of this is that when you use lzip, you get the best compression on the planet. Smaller file sizes; faster compression/uncompression times.

Used properly, lzip is capable of reducing a file down to 0% of its original size. Yes, you read that correctly: 0% of its original size. And regardless of file size, this can be done in constant time. Now do you see why some people are calling lzip the "holy grail" of file utilities?

2. What makes lzip different from gzip/bzip2?
Well, other than the performance benefits mentioned above, the real difference is that lzip uses a "lossy" compression scheme. Most other file compression utilities use a "lossless" compression scheme, mostly because the lossless algorithms are better understood and simpler mathematically (most programmers take shortcuts, particularly in areas that involve a lot of math).

This has two side effects. The first is that files compressed with lzip cannot be restored to their original state -- this is the "lossy" in lossy compression. The second is that the performance is vastly improved. Why don't go go back up to question number one and read that second paragraph again. We're talking about a constant-time algorithm that can reduce a file down to 0% of its original size. What's not to like?

For those who are not satisfied with the 100:1 compression ratio, lzip might as well worth considering. ;)

But it's not worth the price if you're a regular Linux user/hacker. Macs shine for video/music/image editing and a bit for desktop publishing. If your needs don't fall in that (or the "digital hub" concept), then you're better off with a good x86. You don't really need the G4, Gigawire and Firewire stuff. And that "easy to use" stuff... ;-)

And it's a "Mac fan" talking here, so I know what I'm talking about. OK, time to download iPhoto...

- Benad

The technology is very well thought out. What seperates it from things like NetBeans is that plugsins are beyond first-class objects: they are the only type of object.

Let me explain. Everything in Eclipse is a plugin. Plugins publish (as XML) things called "extension points" that other plugins hook into. All that XML is processed at bootup time, and it allows the basic Eclipse engine to do a lot without loading much Java code. Plugins declare new menu items, tool bars, editors, actions, whatever but no Java code is loaded until the user actively selects on of those new options.

I'm personally looking forward to writing some plugsin related to by own open source project, Tapestry.

I've also been very impressed by their very open process. They have an open Bugzilla and very quick response times to bugs and issues. Several suggestions I've made have already made it into the project, and they don't know me from Adam. Eclipse is not perfect, but they are very keen on improving the rough edges.

The interface is very clean and configurable, it really molds to how you, the user, want to run things. All those draggable views and all.

There's already a C/C++ plugin. I'd love to see a Python plugin (perhaps using Jython?). There's a huge amount of functionality that hasn't been documented yet (do I smell an O'Reilly book?).

I find it to be about has fast as Netbeans on my work machine (PIII 1ghz, 512MB) and a lot easier and more intuitive to use and configure. The UI is snappier (and prettier), and its loaded with features. It's like Emacs, you keep discoverring new things it does.

...than email can be filtered server-side to cull it out.

I can do that already far more effectively using tools like procmail and SpamAssassin. SpamAssassin in turn can use various RBLs and Vipul's Razor (recently mentioned here), if you choose to.

That combination has saved me from recieving and processing about 20 messages in my personal mail today alone, not to mention the other benefits of auto-filing/trashing/redirecting that using procmail gives me.

www.vim.org is cool and all, but check out vim.sf.net for a site with all kinds of Vim resources and docs.

check out the Flare Annotative Programming Language. You dont actually write IN XML... you code it in a Python-like language, which gets 'compiled' to XML (well, a tagged language that looks like XML =] ). The runtime interprets it, and allows the code to be extended (annotated) at runtime