Microsoft started MSSQL at 4.0, skipping the previous numbers to make the product *look* more mature. So, if the numbers are renormalized, MSSQL 7.0 is their 3.x effort. And yes, compared to their previous efforts, one might call it 'getting it right'.
Of course, that doesn't mean it doesn't totally suck ass compared to Oracle, DB2, Informix, or even *Postgres*.
Which is a shame considering cursors are high performance basic components in Oracle and Postgres.
Re:It's the logical move
on
The New Zelda
·
· Score: 2
You're right that '-kun' is *way* too informal, but '-sama' is almost unused in modern Japanese. You might use '-sama' when addressing the emperor or perhaps your corporate superior several levels up.
Conker's had a tiny production run and almost no media push. The exposure Conker's did get was driven by the game media's curiosity, as opposed to the more normal "We are [$BigGameCompany]. Push this game."
And Rare isn't part of Nintendo and has always struggled against their mold.
It takes time to turn a company around. Nintendo is still, by and large, rated G.
The server will work fine until 10-11 pages are trying to be rendered at the same time. When this happens each page slows down to a point to where the system seems to get backlogged with requests. it's not too much time until there are 30-40 pages trying to render at the same time. We have a hefty database (running on an SGI
Origin class server) and it doesn't seem to really be the bottle neck.. but the CPU's on that machine are at 100% and creeping..
The strange thing is when we are running in a low concurrency environment the pages are lightning fast...
That's an obvious threading problem. The CPUs are spinning at 100% just checking and releasing locks & mutexs. When you are in low concurrency the threads can get enough time to themselves to complete and don't trip over each other. In your high load situation the threads can't get enough time to finish computing. Such poor design, along with bloat and general obtuseness, have kept me from deploying Java "app servers" (read: boondoggle) in any kind of production environment.
Remember: threads are hard. And locking will fill an exponential resource space. If you're just going to throw faster hardware at it, you should switch back to process based arch.
That's why your Perl,Python, and PHP services deal with heavy loads better - no thread contention. OTOH, they have all that process creation overhead (which is linear rather than exponential like lock contention), so if you can fix your thread bugs you can beat them.
Re:Don't read Alexander
on
Mob Software
·
· Score: 1
If you want to buy a good architecture book, buy one with lots of pictures.
Yes... a picture book would be more appropriate for the intellectual level of an Anonymous Coward...
Re:How is it different from "The Bazaar?"
on
Mob Software
·
· Score: 5, Insightful
Firstly, it's written by Richard Gabriel. You young 'uns might not know him, but us old school LISPers listen, and intently to what he has to say. Accomplishments? One of the original LISP hackers, professor at Stanford, master of all things OOP, founded and buried Lucid, written a huge pile of enriching documentation. ESR, whatever the merits of his fetchmail and Python work, doesn't have that cred level yet.
Secondly, and more importantly, this article covers substantially more ground than "...&the Bazaar". Open source, for instance, is more or less taken as a given, which makes sense since Gabriel has been hacking since the 70's...
But what you perceive as poetry is really the meat of the argument. Gabriel is trying to employ reasoning from Christopher Alexander's "A Pattern Language" to demonstrate how we should build software. The OO pattern guys have read this book, but they have only figured out the fully technical aspect. Gabriel is writing about the patterns of software that pursue Quality, and one of the dominant ones is that the users are the developers, and vice versa.
As an aside, he even demonstrates that cathedrals were built over generations without a written design; successive builders only shared a common Pattern. So there goes the cathedral/bazaar distinction!
Read his stuff. Then read Alexander. You'll be the better developer for it.
You probably already know this, but fsync isn't as relevant to perf as it was on Postgres7.0 and lower. 7.1 uses write-ahead-logging (same as Oracle) and writes that info into tables when it's convenient. 7.0 and lower had to write into the tables & indexes on each fsync, which means moving around a hell of a lot more data. That's really why 7.1 blows the doors off MySQL in recent tests. That's also why InnoDB is so fast -- it has WAL as well. As an aside, InnoDB has an 8k row limit...sound familiar? -It should, Postgres had that last year.
As for data lossage, well, there's a lot to discuss about on-disc caches and power supplies, SCSI vs. IDE. The best guarantee against data loss is still a big-ass UPS and some really fscking attentive operators.
"They laughed at Einstein. They laughed at Newton. But they also laughed at Bozo the clown."
Take this over to comp.databases. There you will find a small, but extremely vocal, crowd of ODM developers with a habit of completely failing to learn relational theory. That, I suppose, more than anything else is the worst -- they dub their products 'post-relational', without ever learning what 'relational' is.
More importantly, you must learn the distinction between data models and programming languages. See my previous post for more details.
I'd like to see an object data model (ODM) open source database come into the scene. Now that would cause a ruckus, challenging both the bottom line and validity of the relational model!
It might affect the bottom line, but unless an ODM can bring a rigorous assault on relational math, it will do jack shit to relational validity. Last I checked, 'open-source' is not a formal theoretical attack.
Relational is a theoretic description of how to store data, validate it, normalize it. There is no corresponding theory in OO, there is only the developer's style or taste. RDBMSes correctly fill the need for validated data storage for multiple applications written in different languages. ODBs are bound to one programming language, and one object model. RDBMSes query data and return sets; ODBs navigate through object pointers according to the style of the object model. What this all leads to is that RDBMSes are general purpose data stores, whereas ODMs are limited to use by 1 client application as an object store -- an ODM is a glorified embedded DB.
There is a distinction here between OO in programming languages, which is a fine way to structure code, and OO in databases, which is simply a misnomer -- a stored object has no behavior, it's just data. ODMs are really Network Model databases, which were disposed of in the 70s. Go read the theory and the history.
It just means you are going to have to run more than one query to get the exact data you want.
Thereby ensuring that your application runs slow as hell!! After all, why instantiate all that overhead talking to the DB, searching the DB cache, scanning disc, and returning data once, when I can do it a half-dozen times!!!
The MySQL crowd just continues to remain ignorant of the fact that full SQL-92 support is not wanking, and it is certainly not a perf hit.
Databases just don't lend themselves to fragmented development the way operating systems do.
Please back up that assertion. While you are doing that, I would like to remind you that the Postgres developers have never actually met in person. Yours is the same argument that every commercial software provider has employed over the last 5 years against free software. I think the truth of the matter, that no one yet knows real theory behind project management, is far more frightening.
In regards to databases, what you have omitted is that the database problem is 2 decades younger than the operating systems problem. The OS problem was solved by the mid '70s. The RDBMS problem has only been 'solved', if you think it has been, by the early '90s. Linux was able to follow much more well-trod ground than Postgres, and I expect the development time of the latter to consequently lag. I have not, OTOH, seen any evidence supporting your assertion.
Ah, okay, I see. After Origin cancelled UX and UO2, and everyone left, and Lord British burned all the design documentation in effigy, I made the reasonable assumption that there was just nothing left for them to work on.
> >It (DOOM) was designed by talented people with
> >good skills and academic degrees in computer science.
> None of us had degrees in computer science. Romero, Adrian, and I don't have any degrees at all,
> and Kevin's is in political science.
Do you see a lot of these kinds of assumptions? The rest of the article doesn't show this bias, but I assumed this kind of mistake, coming from a CS prof, is the ivory tower trying to claim validity on a subject they have ignored.
OTOH, syntax *can* change semantics, and at the very least a difference in syntax can highlight particular semantics for a user. Ruby OO features may be almost entirely incorporated into Python and Perl, but Ruby's better syntax for these features can make it a better language to teach these in. IMOH, that assertion is true - it is easier to be fully OO in Ruby than in Py/Pl.
Some other semantic structures that *aren't* in Py/Pl are Smalltalk-like messaging, Sather iterators, metaclasses, blocks and closures (which will be supported in the next Python, sort of supported in current Perls), blah, blah, etc. It's fun! As an aside on the internals, the Ruby GC is a non-compacting generational GC whereas Python & Perl still do reference counting. I have a lot of hope for good code speed in Ruby as it matures.
c'mon. It took MS that long to get some competent OS engineers working for them. Hopefully this time the process will be faster. 64-bit VMS!! Go, Cutler, go!!
I'll skip the "supposedly" remark and go to the dates. You aren't even close. The Book of Mormon is a compilation of the writings of various authors from about 600 BC to aprox AD 400.
Yeah, 'supposedly' is a bit cheap. But let's review the intra-textual dates, shall we?:
Ether: unestablished beginning presumably around the abandonment of Sumeria, final chapter around 400 BC to 200 BC when the people of Limhi found the last survivor.
Nephi and crew: begins a few years before the sack of Jerusalem in 578 BC. Text continues up to...
Mormon, who collated the records, stuck 'em on gold plates, and handed them off the Moroni to be buried on the hill of Shim. Best estimates for this is around 700 to 800 AD.
So, like I said, "sources compiled around 700 to 800 AD".
Of course, proving all this is a bit difficult considering there are no physical records. Every other non-cult religion out there has a paper trail a mile wide, covering the disputes, history, and hereses of the religion, and the culture, habits, trade, etc of its followers. The BoM has precisely none of that. Consequently? Zero believability.
Anyhow, you've used your one AC reply for the thread. Please log in if you're going to misread my writing again.
New Testament -> 367 AD, compiled from a broad selection of works written from AD 50-100. Sources in several languages; also many sources were omitted from the modern canon, these compose the Apocrypha.
Qur'an -> late 600s AD, compiled from many works Mohammed wrote in the desert. (on numerous materials.) Many preserved records, made all the more odd given a period of history wherein Islam was prone to burning books.
B. of Mormon -> 1830's, supposedly from sources compiled around 700 or 800 AD. No existing sources known.
Anyhow, this all totally ignores the rest of the world's religions, most of whom are less warlike (and hopefully more apropos for the naming of geek books).
IIRC, at the time the competition's cards supported 1028x1028 textures. Although I am not a graphics programmer, I can see how simple access and maniplulation on one large object is superior to cobbling one together myself from forcibly smaller components.
although why Larry won't just accept '+' for string concatenation I cannot understand.
Confuses string-to-number casting. It's easy to see that { "42" . "21 dollars" -> "4221 dollars" } and { "42" + "21 dollars" -> 63 }. There are no such assurances if '+' is used for string concantenation.
Interestingly, Ruby used to have this auto-magical string-to-number casting, but matz took it out some time ago, as it hides too many type errors. Use "String.to_i" if you need it.
I'm not sold on the rest of the syntax changes. Cleaning up ${everythingimaginable}; yeah, wonderful, but the new command syntax.... '~' for string concat?? Look where the key for '~' is -- horrid idea. We already have CTRL in a stupid place; why does Larry want to exerbate this bad keyboard layout??
Slashdot Mirror
Of course, that doesn't mean it doesn't totally suck ass compared to Oracle, DB2, Informix, or even *Postgres*.
Which is a shame considering cursors are high performance basic components in Oracle and Postgres.
You're right that '-kun' is *way* too informal, but '-sama' is almost unused in modern Japanese. You might use '-sama' when addressing the emperor or perhaps your corporate superior several levels up.
Mwuwhahahahahahahaha!!!
And Rare isn't part of Nintendo and has always struggled against their mold.
It takes time to turn a company around. Nintendo is still, by and large, rated G.
I went looking in the bug reports for something that might clue me in, but de nada. Can you tell us what the next rev of /. is backed by?
Remember: threads are hard. And locking will fill an exponential resource space. If you're just going to throw faster hardware at it, you should switch back to process based arch.
That's why your Perl,Python, and PHP services deal with heavy loads better - no thread contention. OTOH, they have all that process creation overhead (which is linear rather than exponential like lock contention), so if you can fix your thread bugs you can beat them.
Secondly, and more importantly, this article covers substantially more ground than "...&the Bazaar". Open source, for instance, is more or less taken as a given, which makes sense since Gabriel has been hacking since the 70's...
But what you perceive as poetry is really the meat of the argument. Gabriel is trying to employ reasoning from Christopher Alexander's "A Pattern Language" to demonstrate how we should build software. The OO pattern guys have read this book, but they have only figured out the fully technical aspect. Gabriel is writing about the patterns of software that pursue Quality, and one of the dominant ones is that the users are the developers, and vice versa.
As an aside, he even demonstrates that cathedrals were built over generations without a written design; successive builders only shared a common Pattern. So there goes the cathedral/bazaar distinction!
Read his stuff. Then read Alexander. You'll be the better developer for it.
As for data lossage, well, there's a lot to discuss about on-disc caches and power supplies, SCSI vs. IDE. The best guarantee against data loss is still a big-ass UPS and some really fscking attentive operators.
Take this over to comp.databases. There you will find a small, but extremely vocal, crowd of ODM developers with a habit of completely failing to learn relational theory. That, I suppose, more than anything else is the worst -- they dub their products 'post-relational', without ever learning what 'relational' is.
More importantly, you must learn the distinction between data models and programming languages. See my previous post for more details.
Relational is a theoretic description of how to store data, validate it, normalize it. There is no corresponding theory in OO, there is only the developer's style or taste. RDBMSes correctly fill the need for validated data storage for multiple applications written in different languages. ODBs are bound to one programming language, and one object model. RDBMSes query data and return sets; ODBs navigate through object pointers according to the style of the object model. What this all leads to is that RDBMSes are general purpose data stores, whereas ODMs are limited to use by 1 client application as an object store -- an ODM is a glorified embedded DB.
There is a distinction here between OO in programming languages, which is a fine way to structure code, and OO in databases, which is simply a misnomer -- a stored object has no behavior, it's just data. ODMs are really Network Model databases, which were disposed of in the 70s. Go read the theory and the history.
The MySQL crowd just continues to remain ignorant of the fact that full SQL-92 support is not wanking, and it is certainly not a perf hit.
In regards to databases, what you have omitted is that the database problem is 2 decades younger than the operating systems problem. The OS problem was solved by the mid '70s. The RDBMS problem has only been 'solved', if you think it has been, by the early '90s. Linux was able to follow much more well-trod ground than Postgres, and I expect the development time of the latter to consequently lag. I have not, OTOH, seen any evidence supporting your assertion.
Ah, okay, I see. After Origin cancelled UX and UO2, and everyone left, and Lord British burned all the design documentation in effigy, I made the reasonable assumption that there was just nothing left for them to work on.
> >good skills and academic degrees in computer science.
> None of us had degrees in computer science. Romero, Adrian, and I don't have any degrees at all,
> and Kevin's is in political science.
Do you see a lot of these kinds of assumptions? The rest of the article doesn't show this bias, but I assumed this kind of mistake, coming from a CS prof, is the ivory tower trying to claim validity on a subject they have ignored.
There's nothing left at Origin. How could they possibly have the resources to do this correctly?
Some other semantic structures that *aren't* in Py/Pl are Smalltalk-like messaging, Sather iterators, metaclasses, blocks and closures (which will be supported in the next Python, sort of supported in current Perls), blah, blah, etc. It's fun! As an aside on the internals, the Ruby GC is a non-compacting generational GC whereas Python & Perl still do reference counting. I have a lot of hope for good code speed in Ruby as it matures.
c'mon. It took MS that long to get some competent OS engineers working for them. Hopefully this time the process will be faster. 64-bit VMS!! Go, Cutler, go!!
- Ether: unestablished beginning presumably around the abandonment of Sumeria, final chapter around 400 BC to 200 BC when the people of Limhi found the last survivor.
- Nephi and crew: begins a few years before the sack of Jerusalem in 578 BC. Text continues up to...
- Mormon, who collated the records, stuck 'em on gold plates, and handed them off the Moroni to be buried on the hill of Shim. Best estimates for this is around 700 to 800 AD.
So, like I said, "sources compiled around 700 to 800 AD".Of course, proving all this is a bit difficult considering there are no physical records. Every other non-cult religion out there has a paper trail a mile wide, covering the disputes, history, and hereses of the religion, and the culture, habits, trade, etc of its followers. The BoM has precisely none of that. Consequently? Zero believability.
Anyhow, you've used your one AC reply for the thread. Please log in if you're going to misread my writing again.
Anyhow, this all totally ignores the rest of the world's religions, most of whom are less warlike (and hopefully more apropos for the naming of geek books).
Does this mean TeX is the Apocrypha?
IIRC, at the time the competition's cards supported 1028x1028 textures. Although I am not a graphics programmer, I can see how simple access and maniplulation on one large object is superior to cobbling one together myself from forcibly smaller components.
Tell us more, Mike!!
Would that be anything like a little rat dance on a keyboard??
Interestingly, Ruby used to have this auto-magical string-to-number casting, but matz took it out some time ago, as it hides too many type errors. Use "String.to_i" if you need it.
I'm not sold on the rest of the syntax changes. Cleaning up ${everythingimaginable}; yeah, wonderful, but the new command syntax.... '~' for string concat?? Look where the key for '~' is -- horrid idea. We already have CTRL in a stupid place; why does Larry want to exerbate this bad keyboard layout??