Slashdot Mirror

...but close: getindi. More of a "share stuff with the groups I'm in", e.g., your softball team, church choir, etc.

> So no, it is not ready for the desktop and
> it will not be until MS and Macromedia decide so.

At least there's a Flash 9 player for Linux now, so that's nice. We couldn't do an indi Linux port until that happened... now I'm working away on it. Well, back to GtkWidget and all that...

> Don't worry, our search engine can read your email, too.
> Love,
> Google.

Just one more reason to use indi for the important stuff.

> Look, most of us want a database system we can use for our
> own limited but still important purposes. We don't need a
> lot of enterprise-level crud bogging us down.

So true. I'm running a small database (only 20 million records), and PostgreSQL is more than sufficient. We use it in production, too, and it's quite solid.

Maybe someday when we get up to 100 TB or so we'll think about something else, but by then PostgreSQL will probably be capable of handling that load as well...

> I don't think that Mr. Bezos would
> recognize a Web 2.0 application

On the other hand, Amazon is doing a bunch of innovative things, like the Simple Storage Service (S3). We're using S3 for indi (with encryption, of course), and it's very, very handy; it keeps us from having to build out a big storage infrastructure.

There's also the Elastic Computing Cloud (EC2) they're doing. I was at a Rails Edge conference last week and James Duncan Davidson did a nifty presentation on deploying Rails apps. The really neat thing, though, was that he deployed it to an EC2 machine rather than a local directory or even a local VMWare instance. Very cool stuff.

there is a "more info" button at the top which goes to
http://www.getindi.com/index2.html
with all the details

> Do most SWF site developers take
> visitors on dial-up Internet connections

Here's a better place for Flash: as the UI for a desktop app. getindi!

see http://getindi.com/

....for the important stuff, use indi. And yes, I'm working on the Linux port...

> It's very unwise to use a hosted-server solution to store
> confidential or private data unless it's encrypted
> and you hold the only keys

And it's not a bad idea to send such documents over an encrypted transport like indi rather than via unsecured email.

> It's too bad Rails 1.2 wasn't released with mongrel

Well... maybe. I agree, Mongrel rocks, we use it for indi and it's quite solid.

But does Rails really need to depend on it? I think the current solution - using Webrick for development and then deploying to a full-up Apache+mod_proxy_balancer_Mongrel - works pretty well.

> To the contrary, the websites a programmer
> can create with Rails are very worthwhile.

I should add - it's working very well for us (getindi!), and there's a lot more to our site than the glittery front end.

...on this sort of thing, Security Now. They had a good explanation last year of all the things the Sony "rootkit" did, like hiding files with the prefix "$sys$". The podcasts are pretty short (20 mins), definitely worth a listen to ease your morning commute.

Also, getindi!

> Flash is a proprietary software app that uses
> proprietary protocols that are becoming ubiquitous on the internet.

But it's slowly opening up, and there are some good frameworks out there for it, like ActionStep. ActionStep is good enough to support building a desktop application. And MTASC is a great open source Flash compiler.

...now I can get back to work on the Linux port of indi. It's one of the few Flash desktop apps out there, and it's a shame not to have it on Linux.

Besides, it'd be a waste of all that code I wrote for the Evolution extension!

> home servers that will control your entertainment,
> television, telephony, and your home automation system

My goodness. This strikes me as being a little out of touch. Most folks I know don't have a home automation system and they use whatever the phone company brings in for their phone lines, with maybe a little Skype. And that's a small maybe.

I think a more interesting battle is to secure and improve communications within and around the current stuff. So while I still have email accounts and mailing lists and such, I use indi to share pictures with my relatives. It's our one spam-free and ad-free comms mechanism...

The blurb on parallel constructs is well said. This has been said on Slashdot before, but with more and more computers getting multicore CPUs, it behooves us to figure out ways to get apps to use multiple threads of execution.

We can do this by multithreading in a single process, which the latest release of PMD does. This is kind of complicated, although using a good concurrency library certainly helps. Or we can separate concerns, like moving the user interface into a separate process like we do with indi. Either way, no sense in leaving CPU power on the table...

> While technically inclined individuals tend to want control,
> Platt argues, most people just want something that works.

And after "most people" have used a program for a certain amount of time, they'll also want control. That's part of programming - figuring out a way to make an app immediately accessible while still allowing advanced users to do what they need to do.

For the app I work on, indi, it should be easy to create a secure channel, but maybe it's a little harder to customize your profile stylesheet. But that's OK because most people won't be aware of what their profile contains until after they've used indi for a while and have created a couple of channels. Then they'll want their family channel profile to look different than their "project team" profile.

> People should not be entering data that can be used against them

Or they should use a system that lets them display only the appropriate profile details for each group or person or whatever - like indi.

> 1. Maybe you don't *want* data to be portable.

And if that's the case, you might want to look at indi. You can send pictures/movies/documents/whatever over channels, but it's all encrypted and only you and the people in your group can descrypt it. Kind of like email without the spam and attachment size limits. But secure.

> Email will continue to be the corporate
> IT bedrock it's been for the last decade.

Unless people start using a spam-free alternative, like indi.

e.g., get indi. Sure cuts down on spam, and you can reliably transfer large files within a group of people.

Plus, it's probably the largest desktop out there that uses Flash for its primary user interface. w00t!

> You might as well build native x86 code linked against
> Windows libraries for all the portability you have.

That's a good point. Still, the VM does serve as an insulating layer against OS changes. But Microsoft is pretty good about not breaking backwards compatibility, so that's not a great advantage. Any idea if there's a C# to native compiler out there? Googling around, I came up with this thing.

The app I work on uses Ruby and Flash to be crossplatform; working out pretty well so far...

Right here, w00t!

It's supplanted Apache+FastCGI as the preferred way of deploying Rails apps in a very short time and seems to be a much better solution all around. "gem install mongrel mongrel_cluster" sure beats the steps necessary to get FCGI running.

I wonder how many people have upgraded to Apache 2.2 in order to get mod_proxy_balancer to balance between Mongrel instances... that's why I did it for indi.

> They compare PostgreSQL 8.2 vs MySQL 4.1.20 and MySQL 5.1.20a.

Mod parent up and all that. We're using PostgreSQL 8.2 for a small (18 million records) database and are pleased as punch with it. And here, too.

> Because it's not compiled, it seems like it's not a
> good idea for really large projects either.

Hm, I think if you're doing a large site - e.g., multiple app servers - the speed at which the language's opcodes are processed won't be the bottleneck. It'll be database queries or the network connections or something like that.

Anyhow, it's working pretty well for us so far...

> Java vs typical web languages isn't the sort of fight
> Java minds on a performance front. Performance certainly
> isn't the thing that makes a servlet/jsp design suck.

Well said indeed. The bottleneck there is rarely the VM, it's the database queries or the network connections or disk I/O or something else. That's the strange thing about the "x doesn't scale" argument where x == Ruby|Python|Java - once you get a certain number of servers, the speed at which the language opcodes are being processed fades into the background.

> Find someone who switched from Java to flash for performance.
> It's got flexible networking and rendering that wipe the
> floor with flash.

I think Flash has an edge here in that there seem to be more people who know how to do whizzy graphics in Flash than in Java. I mean, my perception is that not many folks have done much working with the Java 2D API.

But Flash is starting to get some good frameworks for user interfaces - witness ActionStep. We're using it for indi and it's working out well.

> 8.2 is positioned as a performance release.

We've only got a small database (17 million records or so), and PostgreSQL 8.1 has been handling it fine. But I'm still looking forward to seeing how 8.2 improves things.

And we're using it in another production system, too, which is going to get pretty big (I hope). Lively times!

I recently upgraded RubyForge to Apache 2.2 and it's been such an improvement. mod_cache is great, the worker MPM is solid, and now I can run ViewVC under mod_python. And there's mod_proxy and mox_proxy balancer for making Rails apps work nicely with Mongrel. If you're still back on 1.3, I highly recommend 2.2.

One nice thing about these drives is that the filesystems can be read by any OS without hassles. This means we can include both a Mac and a PC binary (and a Linux one, once I get cracking on that) for indi on a drive and you can move your data from machine to machine with nary a hitch. Good times.

> If you feel strongly enough about it, find another
> job where such issues are not likely to arise.

That's the crux of the matter. There are approximately one slew of jobs out there that won't be morally questionable, and you'll sleep better at night knowing that you're not enabling nasty behavior. It's a small victory but an important one.

Also, for Flash UI goodness, try ActionStep. It's an open source, BSD licensed UI framework for Flash. We use it in indi and it's good stuff.

> For those of us who can't afford to run a commercial database package,
> and have been running open source databases from the beginning,
> this isn't news. MySQL and Postgres are your friends.

Right on. Those of us with over 16 million records in a PostgreSQL database are pretty happy with what we're seeing. And we're willing to run the same database on production servers as well.

Here's our Rails site: getindi. Even uses RJS for those thingies in the sidebar, good times. On the backend, Apache 2.2 + mongrel_cluster + PostgreSQL. Good times...

> There's a ton of open source libraries out there

Right on, like ActionStep. We've built indi in it and it looks good, it's fast, and the API is continually improving. Good times.

> you can create AJAX-based Web applications very easily with RoR

Right on. Ditto with RJS - we're using them on the indi site (click the comments section to see it in action) and they work nicely. A very little bit of Ruby code gets you the Javascript functionality you want. And Rails' architecture seems to make that sort of thing easy to add.

...that seems to be up and coming in the Ruby world is RJS templates. We're using them for the new indi site and they seem pretty handy. The Javascript to Ruby translation is not perfect, of course, but they make some AJAX-ish things nicer: page.visual_effect :highlight, 'sidebar_heading', :duration =>3.

If you're in the northern Virginia area you might be interested in the next NovaRUG meeting; there'll be a presentation on RJS there. Good times...

Now to port my Ruby extension that lets you read/write from the Evolution data store. I wrote that extension to support indi, and so it hasn't been useful so far since Adobe hasn't released a Flash 8 plugin for Linux. But now it can be used with the Windows version of Evolution... good times!

We've been using the C version of BDB (via Guy Decoux's Ruby extension) as a data store for indi; it's been working pretty well. It doesn't take up much space, either, so it's easy to fit it on a flash drive.

Of course, on the backend we use PostgreSQL. Rails + PostgreSQL is good stuff.

...I'd say that Amazon is starting to turn into one of these. Their new S3 storage service is a very nifty thing; I've seen folks using it all over the place.

We're using it for the indi downloads and it's been working great - especially when paired with the Ruby API.

A "Slashdot for prior art" should be the goal.

...is Amazon's excellent S3 storage service. We're using it for the indi downloads and it works great - they handle the big files while our Rails site serves up the site itself. Also, it's easy to automate since they've got a nice Ruby API. Good times.

Anyone who has done enterprise level web-enabled applications can easily tell you the faults with all of the major players in the database field. Oracle is simply 'ok', but for most tasks, it's -to be brutally honest- over kill. Do you really need the replication features of SQL when all you are doing is cacheing emails and collecting messages from your users? At this juncture, most people are relieved because they believe that they settle for a second-teir solution such as MYsql and save the licensing fees to boot.

This might be ideal if all that you were doing was a ruby program that indexed your record collection, say for a student project in your CS class; but in the real world if you have to interface with serious e-commerce applications you will find that not only does MySqL lack even moderately advanced SQL features, but that you will be facing rising support costs for this "free" platform.

So, this brings us to PostGRESL. Now, I don't have a lot of experience with it, myself, given that I've mostly stuck to following the major database players instead of the fringe ones, but since this article addresses it, I've asked some of my friends their opinions. While it's featureful and scalable enough to meet the demands of your average medium sized shop, they've noticed that it tends to not be a viable solution for larger projects. In particular the latest industry benchmarks show PostGREsqL performing poorly compared to more mainstream vendor such as ingres.

Again, like MysQl, POSTgres demonstrates that in order to get enterprise level performance out of hobbyist level software, you're going to have to pay enterprise level fees for support as well as licenseing.

So, in conclusion, after seeing the way in which the other industry standard database solutions fail, there's only one choice a sane IT manager can make: When you need a datacenter solution which both high performant and scalable, is eoconomically viable and contains more support for the current standards the only real contender is SQL Server.

We're using PostgreSQL as the indi backend; it handles requests both from a Jabber server and a Ruby on Rails web site and web service using the native extension (i.e., written in C) driver.

It's working great so far, and since ejabberd has native integration with PostgreSQL, we'll be able to switch to that pretty easily.

We use it for testing indi on a variety of platforms - we've got preconfigured WinME/XP/2K VMs that we can fiddle with. It's great for isolating bugs like "when indi is installed on a Win2K box where Outlook has not been configured, blah happens". Nifty stuff!

> That front page of indi loads unbelievably slow.

Yup, that's just a function of the Rails 1.1 effect - getindi.com is currently sharing a DSL line with rubyforge.org, which is serving the RubyGem index that lets people install Rails with gem install rails. Yikes!

We're using it for indi with a PostgreSQL back end. It's working pretty well so far, even with a Jabber server hitting the same database.

There's an interesting post on Dharmesh Shah's blog about how startups may not want to give away their software for free. One of the points he makes is that in order to charge for something you've got to set up an infrastructure - credit card validation/debiting, SSL cert, and so on - and it's good to get that in place so you can start bringing in some money right away. It's a good read.

I suppose a middle ground might be a free, but invitation-only beta. This seems to be working well for indi, at least so far...

I did some nice charts for the indi admin pages; worked out really nicely thanks to Gruff + RMagick.

I did have a spot of trouble getting the fonts working at first, but once that was fixed, it was easy to create some nice charts with very little code.

"invitation only" makes a lot of sense... it helps you throttle the initial flood of folks until you've sorted out what people like and dislike.

We're using it for indi (built with Rails, w00t!) and the waiting list keeps growing, good times...