Europe. Most of Southern Europe has no cable network whatsoever, and CATV penetration in the north is pretty bad (~50% I think). VoDSL needs no extra infrastructure, just 'clean' copper. mPhase could make *loads* of money.
Well, one thing that you might want to consider is that as per FCC regs, phone lines have strict QoS (Quality of Service) rules, mainly for 911-lifeline services. In other words if your phone line goes down, the phone company (probably your local Bell) *has* to fix it ASAP. As long as the network routing part of the deal (the DSL provider's job) is also decent (i.e. 99+% uptime) your DSL Video service *should* be way more reliable than Cable.
It's not 60 channels, it's UNLIMITED channels. mPhase basically uses an 1.2-1.4 DSL link to pipe ONE channel of video down your phone line into their set-top box. The number of channels is limited by how much bandwidth they have going into the ELEC's central office. Basically, their set-top "dials in" into a video stream. What I'd like to find out is how (and if) you can do time-shifts (i.e. TiVo or VCR-like services).
At least that's my understanding of the technology --the bitrate was back-of-the-envelope bitrate of an MPEG2/4 video, I am sure others can do better.
Re:Other low-level data storage systems out there?
on
MySQL FS
·
· Score: 2
Well, I am glad you're happy, but just about anything implementing a b-tree or skip-list implementation exclusively in RAM will get blazing speeds. The problem of course is, what happens when your application's needs exceed practical RAM sizes (say 7-8GBs these days)?
I think a well-balanced solution with cache and FS-level access (ReiserFS maybe, in a coupla years from now) will do better. Although, I am really more impressed with SGI's XFS.
Re:Other low-level data storage systems out there?
on
MySQL FS
·
· Score: 2
Hmm... yes, Reiser maybe a way to go. Some benchmarks are in order. But, alas, SQL-based DBs are still too slow for what I am planning. SQL commands/queries etc. maybe interpreted to some intermiadate language/bytecode, *but* the real slowdown comes from the abstraction layers needed to support SQL queries and the like.
Again, for a normal application you're absolutely right. But if you want to push/crunch a few GBs around in a coupla minutes, every little slowdown counts:-)... That's why most high-end datamining applications don't use RDBMSs...
Re:Other low-level data storage systems out there?
on
MySQL FS
·
· Score: 2
Well, SQL wont work --I just don't need (or want) the slow down from interpreting and abstracting SQL commands --and yes, I want *all* the speed I can get.
I am looking for something way lower level. ReiserFS isn't a bad solution, I just dont believe that their plugin API is mature enough to base another project on top of --or am I wrong?
Re:Other low-level data storage systems out there?
on
MySQL FS
·
· Score: 2
No, not quite that low-level:-)... B/B* tree implementation and the ability to handle well over 2GB of data comfortably (speed wise) is also a must --say around the neighborhood of ~1TB. Multi-user capabilities are also good, and ACID would be cool, but not a must.
Other low-level data storage systems out there?
on
MySQL FS
·
· Score: 2
Let me go OT for just a second here: does anybody out there know of any open-source systems out there that can do large-scale data storage *without* SQL? I am thinking of a simple C/C++ API that you can use to retrieve and write data from/to tables/fields, nothing much fancier than that.
So far, my best be seems to be ColdStore. Any other pointers?
Warning: this is a plug; I am a member of the PHPSlash core team.
Check out PHPSlash. The current release doesn't do users or moderation, but it *does* have templates, an extensible class library (in OOP PHP), session management and some features that I believe are unique, like the ability to file stories in more than one sections or topics. PHPSlash used to be a port of Slashcode, but it's now a 100% clean-room implementation, written from the ground up for PHP.
Packard and Hewlett were two great gentlemen. I was at Stanford when Packard died in 1996; only then, reading the man's obituary did I realize that the two of them and their families had given tens (if not hundreds) of millions to the school they dropped out from.
And the reason I hadn't realized that was that most of the buildings they funded had the names of others (on their request), most notably Dr. Terman's, their EE prof who pushed them to form a company and helped them out when HP was still two guys out of a garage.
To add: the 747 design is a derivation from the Boeing design entry in the large military cargo transport bid (the YC-4?); Boeing lost to the (now) Lockheed C-5 Galaxy.
Little did Lockheed now that Boeing would turn around and use the failed design to create one of the most successful commercial products of all time --which ultimately, along with the B-52, made Boeing into the giant that is today...
Sorry. I work for a datamining company; I use Java/C++/C/Shell/Python/SQL/XML/some esoteric stuff you've never heard of. The installations that I develop need GBs of RAM and tens and hundreds of GB of disk space. Linux doesn't have a chance there --and I know, because I also administer Linux Beowulf clusters (real ones, not one in my basement) on the side. The only thing that Linux does well compared to an enterprise OS is that it includes all the little utilities and shortcuts that make an admin's life easier.
However, the fact that a Linux box maybe (and that's a big maybe) easier to administer than a Solaris/AIX/HPUX box doesn't make it better; technology should make it better and Solaris/AIX especially are years ahead.
As for the text argument: I do *a lot* of XML. XML is great because it gives a better lower common denominator than flat text, but clearly it's not the end-all, be-all. Components/Objects over intranet/internet will be way more important: XML may be used to describe them and integrate them, but ultimately they would have to be delivered in some sort of compiled form.
I will go one step further than you. Linux is a nice lightweight server OS and a decent alternative embedded systems OS. It is not a threat to MS in the server arena: Solaris is. It is not a threat to MS on the client. OS X could be, maybe, but KDE/Gnome are not even in the running.
Let me explain: on the server Linux is still holding strong because the number one use of low-end, x86-based servers has been pushing text along (maybe some files too) and Linux/Gnu/Apache/Perl/PHP have been more than adequate --actually quite excellent-- for that. However, the unix-heads (and I am one) keep ignoring that that's not where the future is, Linux will die and soon. Sun's Java/Brazil/JNI/whatever and Microsoft's.NET are about pushing services, objects and components, not text. The OSS field is too fractured to attempt anything close --witness KParts, Bonobo, Xparts, etc, etc.
As for the client... one word: Office. Rented, copy-protected, or whatever else it is still by far the best (never mind widely used) suite in existence.
Look at MS's corporate history. They have never tried to get into the hardware game and they were ultimately very successful --partially-- due to that. I doubt they're getting into hardware any time soon; I am guessing they will take it upon themselves to establish the X-Box brand and will then license it to box manufacturers (Sony, Dell being the obvious choices for different reasons).
I am sorry, this is no flame, but when I hear a Perl advocate call Python's syntax "picky" I have to smile... you mean keeping your code blocks properly idented is harder than _$->@{}?
I am willing to wager that you haven't tried Python; I used to make fun of the whitespace thing too before I actually coded in the language. Just find a reasonable size project (a coupla hundred lines of code will do) and try out Python. You will change your mind.
Python will also be part of.NET along with Perl, and it can do SOAP as well. Moreover, JPython already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.
Java has found its best niche on the server side. Every big-time server implementation I am aware of uses Java, if not for the full app, at least for the middleware. The reason is simple: compared to anything else on the server-side, Java is faster to develop, already has probably every binding and interface you can think of, and it's pretty damn fast compared to the other solutions.
Personally, for non-enterprise level stuff, I am partial to Python: as clean in syntax as Java, even faster to develop, cross-platform, totally free (as in BSD free) and if you absolutely need to, you can compile it to Java bytecode and stick it in your enterprise solution as well.
And in the coming VM war between Java and.NET, Python is happy to work on both (there is a Python interpreter written in Java and Active State announced one that will compile to.NET's VM).
I respectfully disagree; I particularly disagree with your definition of 'insight'. Insight is that spark of brilliance that cuts through a problem and either reduces it down to its essense or, ultimately, solves it. This is not a communal process. It's something that takes genius. True, unadulterated genius.
If insight was indeed a communal process, frogleaps in science would be commonplace. You wouldnot *have* a list of brilliant scientists to list, like you did. The fact that you do proves that someone (Einstein, Archimedes...) made that frogleap. That was the insight. The people around them set the stage, defined the problem, then poured over their solutions, validating them and ultimately making them famous; but they didnot provide any insight...
One thing that I've never seen in the OSX reviews (and I have read most if not all that I've come across) is a feature-by-feature list of things shared between OSX and Darwin. Does anybody that has played with both (or just Darwin) care to make a stab at it?
I am most interested in things like the Frameworks concept, bundles (i.e. ".app" directories) from the NeXT world, NetInfo and of course, XML configuration.
I don't really care about Aqua, Java support or Display PDF. All those are nice toys but I just want a clean, 21st century Unix, and Darwin looks like the best contender...
...from/. POV of the world is anything outside the US. SuSE is way more popular in Europe than RedHat is here. And I am sorry, but VA despite being y'all's employer is completely irrelevant. VA could go away tomorrow and with the exception of SourceForge noone would be the wiser.
The KDE League means that we're back to square 1: competition and flame wars galore. I say that's a good thing --the competition part.
There are better reasons than cost to create UCAVs:
G-forces. At this day and age, the true limit of a fighter's performance isn't engine power or structural integrity: it's how many Gs the pilot can stand. Even with the best pressure suits, a UCAV has an obvious advantage.
PIO (Pilot Induced Oscillation): if you're gonna pull any tricky aerodynamics like the X-45 does (inverted swept wing, stealth profile) you need dynamically unstable aircraft. The problem with unstable designs in fighters is usually that the pilot overcompensates flight corrections --i.e., the resolution of the human is much lower than the resolution that the flight corrections must be made; in essence, the pilot is correcting the aircraft at a lag. Modern control systems of course correct for this already --by trying to determine what the pilot *wants* to do, rather than what he's putting in the stick-- but with higher Gs (and thus higher speeds) the human is the weak link.
Weight, of course. If I remember my Design courses correctly, the extra systems for the pilot account for about 20%-25% of a fighter's Take Off Gross Weight: armor plating, cockpit controls, air conditioning, etc. Weight is an aircraft's Number 1 limiting design factor.
OTOH there is one huge disadvantage to a UCAV: in a dog-fight, or whenever human perception is needed to reduce the decision tree to something manageable, they will always (well, for the next few decades anyway) be outmanned. Pun intended.
... your choice should also depend on the hardware and the amount of time you want to spend tweaking the config. The Beowulf I help admin has bleeding-edge hardware that requires proprietary (closed-source, commercial) drivers that are usually packaged for RedHat, even tested against RH-specific kernels. Yes, I could probably take the RPM apart and install them on another distro, but then I couldn't really use the OEM's support as they would come back with 'we don't support that'.
So, in *practice* your best choices would be, in my experience, RedHat for Beowulf-type clustering (process distribution) and TurboLinux for high-availability clustering (fail-overs)...
True; however, I think that part of the functionality is horse crap --it's part of the whole '99 delusion that businesses would change the way the do business because of the internet. That's what created the whole B2B explosion and that's really what's bringing it down. Truth of the matter is that companies weed out their suppliers and providers (including service providers); they don't try to *enlarge* that pool, they try to make it smaller and smaller (less paperwork, better 'synergy' and all that).
The number of goods that are so commoditized that would make this irrelevant is insignificant IMHO. I mean, even if you trade in scrap metal, you'd like to know where you're getting that scrap from and if that supplier can send you that scrap in-time.
I am not saying that this somehow makes UDDI less important --trust me, getting ERP systems to talk to 1-2 other ERP systems is hard enough--, I just think that that's there for buzzword compliancy...
This is a 2nd generation EDI (Enterprise Data Interchange). EDI is a horrible, horrible mess. UDDI is supposed to take the incredible pain and suffering that the EDI specification has caused the ERP industry and make it go away.
UDDI is not about ASPing (although it will help those companies that do that), and its not about Web applications. It's about massive ERP systems talking to each other and coordinating with minimum human intervention. Say I am IT for XYZ MegaStores Inc. My business analysts have finalized an order of 1000 ABC Electronics Thingamagics that need to be shipped thru EFG Freight. Instead of me producing a flat text file with some massive scripting and e-mailing it or otherwise transmitting it to ABC and/or EFG (or actually trying to use EDI for that), UDDI would enable me to send that data into my ERP system's UDDI module which would then take care of the communication and translation process. It's all about B2B data interchange in a big scale...
Of course, this kind of freedom should enable other things, like on-the-fly auctions, just-in-time shipping (down to the hour or minute even) and other cool little supply chain optimization wonders. Of course, that's exactly what EDI was supposed to achieve in the first place...
BTW (shameless plug follows): if you think that the above description sounded cool or are otherwise into data-warehousing and massive data-mining and other real cool tech and looking for a job in Atlanta, e-mail me.
Slashdot Mirror
Europe. Most of Southern Europe has no cable network whatsoever, and CATV penetration in the north is pretty bad (~50% I think). VoDSL needs no extra infrastructure, just 'clean' copper. mPhase could make *loads* of money.
Well, one thing that you might want to consider is that as per FCC regs, phone lines have strict QoS (Quality of Service) rules, mainly for 911-lifeline services. In other words if your phone line goes down, the phone company (probably your local Bell) *has* to fix it ASAP. As long as the network routing part of the deal (the DSL provider's job) is also decent (i.e. 99+% uptime) your DSL Video service *should* be way more reliable than Cable.
:-)...
Of course, usual disclaimers apply
It's not 60 channels, it's UNLIMITED channels. mPhase basically uses an 1.2-1.4 DSL link to pipe ONE channel of video down your phone line into their set-top box. The number of channels is limited by how much bandwidth they have going into the ELEC's central office. Basically, their set-top "dials in" into a video stream. What I'd like to find out is how (and if) you can do time-shifts (i.e. TiVo or VCR-like services).
At least that's my understanding of the technology --the bitrate was back-of-the-envelope bitrate of an MPEG2/4 video, I am sure others can do better.
Well, I am glad you're happy, but just about anything implementing a b-tree or skip-list implementation exclusively in RAM will get blazing speeds. The problem of course is, what happens when your application's needs exceed practical RAM sizes (say 7-8GBs these days)?
I think a well-balanced solution with cache and FS-level access (ReiserFS maybe, in a coupla years from now) will do better. Although, I am really more impressed with SGI's XFS.
Hmm... yes, Reiser maybe a way to go. Some benchmarks are in order. But, alas, SQL-based DBs are still too slow for what I am planning. SQL commands/queries etc. maybe interpreted to some intermiadate language/bytecode, *but* the real slowdown comes from the abstraction layers needed to support SQL queries and the like.
:-)... That's why most high-end datamining applications don't use RDBMSs...
Again, for a normal application you're absolutely right. But if you want to push/crunch a few GBs around in a coupla minutes, every little slowdown counts
Well, SQL wont work --I just don't need (or want) the slow down from interpreting and abstracting SQL commands --and yes, I want *all* the speed I can get.
I am looking for something way lower level. ReiserFS isn't a bad solution, I just dont believe that their plugin API is mature enough to base another project on top of --or am I wrong?
No, not quite that low-level :-)... B/B* tree implementation and the ability to handle well over 2GB of data comfortably (speed wise) is also a must --say around the neighborhood of ~1TB. Multi-user capabilities are also good, and ACID would be cool, but not a must.
Let me go OT for just a second here: does anybody out there know of any open-source systems out there that can do large-scale data storage *without* SQL? I am thinking of a simple C/C++ API that you can use to retrieve and write data from/to tables/fields, nothing much fancier than that. So far, my best be seems to be ColdStore. Any other pointers?
Warning: this is a plug; I am a member of the PHPSlash core team. Check out PHPSlash. The current release doesn't do users or moderation, but it *does* have templates, an extensible class library (in OOP PHP), session management and some features that I believe are unique, like the ability to file stories in more than one sections or topics. PHPSlash used to be a port of Slashcode, but it's now a 100% clean-room implementation, written from the ground up for PHP.
Packard and Hewlett were two great gentlemen. I was at Stanford when Packard died in 1996; only then, reading the man's obituary did I realize that the two of them and their families had given tens (if not hundreds) of millions to the school they dropped out from.
And the reason I hadn't realized that was that most of the buildings they funded had the names of others (on their request), most notably Dr. Terman's, their EE prof who pushed them to form a company and helped them out when HP was still two guys out of a garage.
That's class people...
To add: the 747 design is a derivation from the Boeing design entry in the large military cargo transport bid (the YC-4?); Boeing lost to the (now) Lockheed C-5 Galaxy.
Little did Lockheed now that Boeing would turn around and use the failed design to create one of the most successful commercial products of all time --which ultimately, along with the B-52, made Boeing into the giant that is today...
Sorry. I work for a datamining company; I use Java/C++/C/Shell/Python/SQL/XML/some esoteric stuff you've never heard of. The installations that I develop need GBs of RAM and tens and hundreds of GB of disk space. Linux doesn't have a chance there --and I know, because I also administer Linux Beowulf clusters (real ones, not one in my basement) on the side. The only thing that Linux does well compared to an enterprise OS is that it includes all the little utilities and shortcuts that make an admin's life easier.
However, the fact that a Linux box maybe (and that's a big maybe) easier to administer than a Solaris/AIX/HPUX box doesn't make it better; technology should make it better and Solaris/AIX especially are years ahead.
As for the text argument: I do *a lot* of XML. XML is great because it gives a better lower common denominator than flat text, but clearly it's not the end-all, be-all. Components/Objects over intranet/internet will be way more important: XML may be used to describe them and integrate them, but ultimately they would have to be delivered in some sort of compiled form.
I will go one step further than you. Linux is a nice lightweight server OS and a decent alternative embedded systems OS. It is not a threat to MS in the server arena: Solaris is. It is not a threat to MS on the client. OS X could be, maybe, but KDE/Gnome are not even in the running.
.NET are about pushing services, objects and components, not text. The OSS field is too fractured to attempt anything close --witness KParts, Bonobo, Xparts, etc, etc.
Let me explain: on the server Linux is still holding strong because the number one use of low-end, x86-based servers has been pushing text along (maybe some files too) and Linux/Gnu/Apache/Perl/PHP have been more than adequate --actually quite excellent-- for that. However, the unix-heads (and I am one) keep ignoring that that's not where the future is, Linux will die and soon. Sun's Java/Brazil/JNI/whatever and Microsoft's
As for the client... one word: Office. Rented, copy-protected, or whatever else it is still by far the best (never mind widely used) suite in existence.
Look at MS's corporate history. They have never tried to get into the hardware game and they were ultimately very successful --partially-- due to that. I doubt they're getting into hardware any time soon; I am guessing they will take it upon themselves to establish the X-Box brand and will then license it to box manufacturers (Sony, Dell being the obvious choices for different reasons).
I am sorry, this is no flame, but when I hear a Perl advocate call Python's syntax "picky" I have to smile... you mean keeping your code blocks properly idented is harder than _$->@{}?
I am willing to wager that you haven't tried Python; I used to make fun of the whitespace thing too before I actually coded in the language. Just find a reasonable size project (a coupla hundred lines of code will do) and try out Python. You will change your mind.
ObPythonPostInPerlThread:
.NET along with Perl, and it can do SOAP as well. Moreover, JPython already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.
Python will also be part of
Java has found its best niche on the server side. Every big-time server implementation I am aware of uses Java, if not for the full app, at least for the middleware. The reason is simple: compared to anything else on the server-side, Java is faster to develop, already has probably every binding and interface you can think of, and it's pretty damn fast compared to the other solutions.
.NET, Python is happy to work on both (there is a Python interpreter written in Java and Active State announced one that will compile to .NET's VM).
Personally, for non-enterprise level stuff, I am partial to Python: as clean in syntax as Java, even faster to develop, cross-platform, totally free (as in BSD free) and if you absolutely need to, you can compile it to Java bytecode and stick it in your enterprise solution as well.
And in the coming VM war between Java and
I respectfully disagree; I particularly disagree with your definition of 'insight'. Insight is that spark of brilliance that cuts through a problem and either reduces it down to its essense or, ultimately, solves it. This is not a communal process. It's something that takes genius. True, unadulterated genius.
If insight was indeed a communal process, frogleaps in science would be commonplace. You wouldnot *have* a list of brilliant scientists to list, like you did. The fact that you do proves that someone (Einstein, Archimedes...) made that frogleap. That was the insight. The people around them set the stage, defined the problem, then poured over their solutions, validating them and ultimately making them famous; but they didnot provide any insight...
We do know how this works for science: great insights do NOT come from peer review; the stereotypical mad scientist is a stereotype for a reason.
Peer review *validates* scientific and engineering works. It does not create them.
One thing that I've never seen in the OSX reviews (and I have read most if not all that I've come across) is a feature-by-feature list of things shared between OSX and Darwin. Does anybody that has played with both (or just Darwin) care to make a stab at it?
I am most interested in things like the Frameworks concept, bundles (i.e. ".app" directories) from the NeXT world, NetInfo and of course, XML configuration.
I don't really care about Aqua, Java support or Display PDF. All those are nice toys but I just want a clean, 21st century Unix, and Darwin looks like the best contender...
...from /. POV of the world is anything outside the US. SuSE is way more popular in Europe than RedHat is here. And I am sorry, but VA despite being y'all's employer is completely irrelevant. VA could go away tomorrow and with the exception of SourceForge noone would be the wiser.
The KDE League means that we're back to square 1: competition and flame wars galore. I say that's a good thing --the competition part.
G-forces. At this day and age, the true limit of a fighter's performance isn't engine power or structural integrity: it's how many Gs the pilot can stand. Even with the best pressure suits, a UCAV has an obvious advantage.
PIO (Pilot Induced Oscillation): if you're gonna pull any tricky aerodynamics like the X-45 does (inverted swept wing, stealth profile) you need dynamically unstable aircraft. The problem with unstable designs in fighters is usually that the pilot overcompensates flight corrections --i.e., the resolution of the human is much lower than the resolution that the flight corrections must be made; in essence, the pilot is correcting the aircraft at a lag. Modern control systems of course correct for this already --by trying to determine what the pilot *wants* to do, rather than what he's putting in the stick-- but with higher Gs (and thus higher speeds) the human is the weak link.
Weight, of course. If I remember my Design courses correctly, the extra systems for the pilot account for about 20%-25% of a fighter's Take Off Gross Weight: armor plating, cockpit controls, air conditioning, etc. Weight is an aircraft's Number 1 limiting design factor.
OTOH there is one huge disadvantage to a UCAV: in a dog-fight, or whenever human perception is needed to reduce the decision tree to something manageable, they will always (well, for the next few decades anyway) be outmanned. Pun intended.
... your choice should also depend on the hardware and the amount of time you want to spend tweaking the config. The Beowulf I help admin has bleeding-edge hardware that requires proprietary (closed-source, commercial) drivers that are usually packaged for RedHat, even tested against RH-specific kernels. Yes, I could probably take the RPM apart and install them on another distro, but then I couldn't really use the OEM's support as they would come back with 'we don't support that'.
So, in *practice* your best choices would be, in my experience, RedHat for Beowulf-type clustering (process distribution) and TurboLinux for high-availability clustering (fail-overs)...
True; however, I think that part of the functionality is horse crap --it's part of the whole '99 delusion that businesses would change the way the do business because of the internet. That's what created the whole B2B explosion and that's really what's bringing it down. Truth of the matter is that companies weed out their suppliers and providers (including service providers); they don't try to *enlarge* that pool, they try to make it smaller and smaller (less paperwork, better 'synergy' and all that).
The number of goods that are so commoditized that would make this irrelevant is insignificant IMHO. I mean, even if you trade in scrap metal, you'd like to know where you're getting that scrap from and if that supplier can send you that scrap in-time.
I am not saying that this somehow makes UDDI less important --trust me, getting ERP systems to talk to 1-2 other ERP systems is hard enough--, I just think that that's there for buzzword compliancy...
This is a 2nd generation EDI (Enterprise Data Interchange). EDI is a horrible, horrible mess. UDDI is supposed to take the incredible pain and suffering that the EDI specification has caused the ERP industry and make it go away.
UDDI is not about ASPing (although it will help those companies that do that), and its not about Web applications. It's about massive ERP systems talking to each other and coordinating with minimum human intervention. Say I am IT for XYZ MegaStores Inc. My business analysts have finalized an order of 1000 ABC Electronics Thingamagics that need to be shipped thru EFG Freight. Instead of me producing a flat text file with some massive scripting and e-mailing it or otherwise transmitting it to ABC and/or EFG (or actually trying to use EDI for that), UDDI would enable me to send that data into my ERP system's UDDI module which would then take care of the communication and translation process. It's all about B2B data interchange in a big scale...
Of course, this kind of freedom should enable other things, like on-the-fly auctions, just-in-time shipping (down to the hour or minute even) and other cool little supply chain optimization wonders. Of course, that's exactly what EDI was supposed to achieve in the first place...
BTW (shameless plug follows): if you think that the above description sounded cool or are otherwise into data-warehousing and massive data-mining and other real cool tech and looking for a job in Atlanta, e-mail me.