Are you sure you're talking about OLEDB then? Because it's in widespread use, so it's not vaporware. Either you're confused and calling a particular, promised OLEDB _provider_ vaporware, or you're thinking of something else.
Wait, are you calling OLEDB a "database filesystem"?
OLEDB's a db-abstraction technology to provide a db-like interface to multiple providers, one of which can be a filesystem, but that's not its primary purpose. Sure, it's nice that there are providers for Excel and other non-RDBMS, but OLEDB simplifies the heck out of integrations that otherwise would have to use ODBC or some vendor-specific interface.
At the time OLEDB was born, around the time of ODBC 2.0, you couldn't really plug in random RDBMS engines behind an ODBC application. You still couldn't with the first versions of OLEDB, but it was a lot closer.
My DVR (Comcast-supplied Motorola 6208) has the very, very annoying problem of excessive fan noise. Since I don't own it, I can't rip it apart to silence the loud hissing when it gets a little warm (which it does at the drop of a hat while watching tv). Well, I could, but if I screw up, I don't want to pay for the privilege of owning a slow, noisy set-top box. I also can't expand the disk space with the version I have, by attaching firewire or usb drives.
That said, everything else you mentioned is spot on. I don't think it's worth replacing my two pain points for the hassle of integrating channel listings, getting device drivers working, or dealing with a big, ugly, old box (or spending $1500 to build a pretty, tiny box).
I think people might be solving the wrong problem, but I guess I am not the target audience.
I'd just like to say that I'm happy to hear that one of the people who bitches about how powerful their old tools were and refuses to learn anything else has removed himself from the workforce.
For hardware TCP/IP processing to be useful, you need to be say 2x the speed of the CPUs memcpy() function!
Not at all true. Dipping into Ricardian economics, you can conclude that the best, most valuable, purpose of the primary CPU is to process user input and to execute applications. If another CPU can be introduced into the computational economy such that it can perform a task, even if at a lower rate than the primary CPU, thus freeing up the primary CPU to perform its most valuable task more efficiently, then computational trade with that CPU is a win.
The secondary CPU does not need to be 2x as fast at processing TCP/IP as the primary CPU. It merely needs to process it well enough that it can take the load off the primary CPU.
Now, if the primary CPU has to sit around and wait for the secondary CPU to accomplish its task, thereby creating an opportunity cost in computation, then yes, the secondary CPU needs to be significantly faster for its presence to be justified.
Remember that these are the same people who think you want Viagra so badly that they should misspell it to get around your misguided spam filters, or that giving their messages subject lines like "Bobby, if you ever do that again I will kill you," will increase the chances that you'll buy their farm animal porn.
And your finances, of course. By the time you put a decent criminal defense attorney on retainer, you're out $10k, at a minimum. You don't get that back when the judge gives you a summary dismissal or the DA says,"whoops!"
You must not have scanned many books, dvds, and cds in yet. The current version is a little faster, but with thousands of books in mine, it takes just long enough to start up that I think it has crashed. The random pauses while it collects its thoughts when I use the scroll bar are a joy, too.
If you would look behind the first few hours of Emacs usage you would know that Emacs is propably the most advanced development environment today.
Nice try, if wrong.:-)
My biggest beef with Emacs is usually that I do too much with it. I tend to run GNUS in the same instance as the rest of development, and guess what -- it's single threaded! There's no reason that grabbing email via nnimap should keep me from doing anything else.
To get emacs up to the same level of functionality as, say, IDEA, I'd have to spend about twelve months writing modules that don't exist today. The modules that do exist, such as folding.el or ecb.el, are nice efforts, but mere shadows of the similar functionality offered on an application that actually is an IDE, instead of an IDE toolkit.
But, since I've only been using emacs for fourteen years, what do I know?;>
I've watched more experienced emacs users than yourself make the switch from emacs to IDEA, and they all regret not switching earlier.
I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?).
Not to be snotty (oh, come on, this is/., so I'll have to snot this up a bit.) but you're probably using a tiny subset of the language if you're relying on your understanding of the SDK. You're probably wasting a lot of time trying to remember if it's put() or add() or addElement(), all things your IDE should tell you, and you shouldn't need to store in your brain.
The people I've worked with who insist on using vi or emacs for Java dev work are usually working about 50% or less the speed of people using a quality IDE such as IDEA or VisualAge/Java. Class and method completion alone speed up programming and also expose you to a lot more of the API than you can reasonably expect to hold in your head, especially with the speed at which the SDK has been increasing lately.
Without IDEs, people usually know two data structures, Vector and Hashtable, and the myriad classes in the Collections API are more of a novelty than anything else. If they know more than two collections, they know the non-reentrant versions of each of the above two classes.
I've also watched some of those holdouts switch from emacs to IDEA, and it's truly a "holy shit" moment. You're doing yourself a professional disservice not to be using them.
If tools are so magical that their users don't know the real theory and practice behind them, they end up relying on them to do any work.
At some point, you need to give up and assume that an abstraction is opaque. Otherwise, you'll be stuck at a relatively low level in terms of what you'll be able to do in life.
Our entire society has advanced at the same rate with which we have lost touch with the more concrete necessities of survival. The people of ten thousand or so years ago were not appreciably "dumber" than we are. What they did lack was a lot of knowledge, especially of the abstract. They knew, however, which berries were edible and which weren't, how to avoid getting eaten by bears or rabid chipmunks, how to avoid freezing without the use of an electric heater, etc.
These are all things we've had to give up over the millennia on our way to an advanced civilisation. In the future, we will have to give up more.
Almost all people writing object oriented software don't really need to know about electron tunnelling and capacitance. They may need to know about garbage collection, but usually only when something goes wrong in their application. That usually happens once or twice a year, but not on a daily basis, and not for much longer. The entire purpose of the virtual machine is abstracting away a lot of the lower level details -- and this is a good thing!
I think it's useful to be able to write trivial programs in a primitive tool such as emacs/JDEE. However, I can all but guarantee that you can do it faster and with a much higher quality with a real IDE.
Slashdot Mirror
You obviously don't remember the brouhaha several years ago when many "large US corps" rescinded offers en masse due to an economic shortfall.
Or he has a hell of a commute from Ohio.
What's five hundred million between friends? :-)
:P
nice catch.
They both appear to make roughly the same amount of money, at least based on their income statements.
http://finance.yahoo.com/q/is?s=YHOO&annual
http://finance.yahoo.com/q/is?s=GOOG&annual
Who knows what will happen this year, though. It could go either way.
Isn't Yahoo! search now inktomi, which was part of the Overture acquisition? And wasn't Orkut one of those "20%" projects by a Google engineer?
Previous and Next what? How does that differ from < and >? And how do "<" and ">" differ from " < " and " > "?
;>
You thought it was pretty simple, or you're pretty simple?
Are you sure you're talking about OLEDB then? Because it's in widespread use, so it's not vaporware. Either you're confused and calling a particular, promised OLEDB _provider_ vaporware, or you're thinking of something else.
Wait, are you calling OLEDB a "database filesystem"?
OLEDB's a db-abstraction technology to provide a db-like interface to multiple providers, one of which can be a filesystem, but that's not its primary purpose. Sure, it's nice that there are providers for Excel and other non-RDBMS, but OLEDB simplifies the heck out of integrations that otherwise would have to use ODBC or some vendor-specific interface.
At the time OLEDB was born, around the time of ODBC 2.0, you couldn't really plug in random RDBMS engines behind an ODBC application. You still couldn't with the first versions of OLEDB, but it was a lot closer.
My DVR (Comcast-supplied Motorola 6208) has the very, very annoying problem of excessive fan noise. Since I don't own it, I can't rip it apart to silence the loud hissing when it gets a little warm (which it does at the drop of a hat while watching tv). Well, I could, but if I screw up, I don't want to pay for the privilege of owning a slow, noisy set-top box. I also can't expand the disk space with the version I have, by attaching firewire or usb drives.
That said, everything else you mentioned is spot on. I don't think it's worth replacing my two pain points for the hassle of integrating channel listings, getting device drivers working, or dealing with a big, ugly, old box (or spending $1500 to build a pretty, tiny box).
I think people might be solving the wrong problem, but I guess I am not the target audience.
The B&M Gates Foundation gave out a little more than a billion dollars in each of 2002 and 2003 (based on the reported financials on the website).
Google's market cap is about fifty billion, about as good a sense of "worth" as we can come up with.
I know you were just pulling that out of your ass, but do please try harder next time.
I'd just like to say that I'm happy to hear that one of the people who bitches about how powerful their old tools were and refuses to learn anything else has removed himself from the workforce.
Not at all true. Dipping into Ricardian economics, you can conclude that the best, most valuable, purpose of the primary CPU is to process user input and to execute applications. If another CPU can be introduced into the computational economy such that it can perform a task, even if at a lower rate than the primary CPU, thus freeing up the primary CPU to perform its most valuable task more efficiently, then computational trade with that CPU is a win.
The secondary CPU does not need to be 2x as fast at processing TCP/IP as the primary CPU. It merely needs to process it well enough that it can take the load off the primary CPU.
Now, if the primary CPU has to sit around and wait for the secondary CPU to accomplish its task, thereby creating an opportunity cost in computation, then yes, the secondary CPU needs to be significantly faster for its presence to be justified.
Remember that these are the same people who think you want Viagra so badly that they should misspell it to get around your misguided spam filters, or that giving their messages subject lines like "Bobby, if you ever do that again I will kill you," will increase the chances that you'll buy their farm animal porn.
NeXTSTEP used monolithic Mach, not microkernel Mach.
:-)
As demonstrated by fifteen-year-olds around the world, ignorance yields boredom.
And your finances, of course. By the time you put a decent criminal defense attorney on retainer, you're out $10k, at a minimum. You don't get that back when the judge gives you a summary dismissal or the DA says,"whoops!"
Vindictive is fun. :-)
;-)
"We'd like to wrap this up quickly because we have this other huge project to discuss with you, that will take all of your resources for months!"
See if you can get the "all payment at completion" deal for that one, too.
Should click on the poor guy's google links to help pay for the slashdotting. His server is probably a smoking crater by now. :-)
A/S/L?
"a little bit slow"?
You must not have scanned many books, dvds, and cds in yet. The current version is a little faster, but with thousands of books in mine, it takes just long enough to start up that I think it has crashed. The random pauses while it collects its thoughts when I use the scroll bar are a joy, too.
That's fine for a developer, but you need to do a clean build before pushing to production.
My first reaction to that picture was to wonder who screwed up the color balance to make everyone look so pallid.
GO OUTSIDE OCCASIONALLY, PEOPLE!
Nice try, if wrong.
My biggest beef with Emacs is usually that I do too much with it. I tend to run GNUS in the same instance as the rest of development, and guess what -- it's single threaded! There's no reason that grabbing email via nnimap should keep me from doing anything else.
To get emacs up to the same level of functionality as, say, IDEA, I'd have to spend about twelve months writing modules that don't exist today. The modules that do exist, such as folding.el or ecb.el, are nice efforts, but mere shadows of the similar functionality offered on an application that actually is an IDE, instead of an IDE toolkit.
But, since I've only been using emacs for fourteen years, what do I know?
I've watched more experienced emacs users than yourself make the switch from emacs to IDEA, and they all regret not switching earlier.
Not to be snotty (oh, come on, this is
The people I've worked with who insist on using vi or emacs for Java dev work are usually working about 50% or less the speed of people using a quality IDE such as IDEA or VisualAge/Java. Class and method completion alone speed up programming and also expose you to a lot more of the API than you can reasonably expect to hold in your head, especially with the speed at which the SDK has been increasing lately.
Without IDEs, people usually know two data structures, Vector and Hashtable, and the myriad classes in the Collections API are more of a novelty than anything else. If they know more than two collections, they know the non-reentrant versions of each of the above two classes.
I've also watched some of those holdouts switch from emacs to IDEA, and it's truly a "holy shit" moment. You're doing yourself a professional disservice not to be using them.
At some point, you need to give up and assume that an abstraction is opaque. Otherwise, you'll be stuck at a relatively low level in terms of what you'll be able to do in life.
Our entire society has advanced at the same rate with which we have lost touch with the more concrete necessities of survival. The people of ten thousand or so years ago were not appreciably "dumber" than we are. What they did lack was a lot of knowledge, especially of the abstract. They knew, however, which berries were edible and which weren't, how to avoid getting eaten by bears or rabid chipmunks, how to avoid freezing without the use of an electric heater, etc.
These are all things we've had to give up over the millennia on our way to an advanced civilisation. In the future, we will have to give up more.
Almost all people writing object oriented software don't really need to know about electron tunnelling and capacitance. They may need to know about garbage collection, but usually only when something goes wrong in their application. That usually happens once or twice a year, but not on a daily basis, and not for much longer. The entire purpose of the virtual machine is abstracting away a lot of the lower level details -- and this is a good thing!
I think it's useful to be able to write trivial programs in a primitive tool such as emacs/JDEE. However, I can all but guarantee that you can do it faster and with a much higher quality with a real IDE.
You've obviously never worked in Manhattan in the summer.
*Sproing*
It's all worth it for the eye candy.
Blair Witch was not an amateur film. It was done outside the major studio system, but it wasn't amateur. Small businesses are not amateur efforts. :-)