Uh, what? That's not having it. That's having the compatibility next to it.
false. you buy one part; that part can execute x86 code. the chip, therefor, has x86 compatibility. your next point even seems to admit it, while pointing out the (correct) fact that the compatibility simply wasn't very good. but that's not the same as not existing.
PowerPC was explicitly designed to make 68k emulation easier.
false, as a sibling has noted. PowerPC's designed happened to make emulation easy, but that was a selection criteria, not a design criteria.
Yes, and when you compete successfully, you replace.
false, for two reasons. first, successful competition does not need to lead to monopoly or monoculture, so your premise isn't any good. second, even if you believe it is, it only holds if you're competing within the same market, and the point is PowerPC, mainly, didn't. further, you entirely (i suspect intentionally) ignore the real point of the comment, was that up the thread the claim was made that PowerPC failed because it didn't have backward compatibility, while it did. you also seem to think PowerPC is dead, which isn't the case at all.
y'know, i'm embarrassed to say i never made that connection before. that's a really interesting line of thought. still, MIPS was having lots of other problems, including a rather big split in focus between high-end servers and embedded systems, two markets with very different design constraints; schizophrenia probably did them in. that and getting in bed with WIntel. PA-RISC was a pretty obvious knock-off, but no sympathy for HP making their own stupid decisions. the most direct and disappointing casualty was likely Alpha, who really lacked anyone who cared for it at all after DEC got eaten.
lack of chip-level backwards compatibility is an issue, but not a deal breaker. that can be reasonably managed, and has in plenty of cases you can point to without trying too hard. these examples failed to deliver on their promise for entirely unrelated reasons.
look at the examples given, and you'll see compatibility wasn't really a factor for the first two, either. Itanic had explicit backwards compatibility, at first in hardware (through the use of a separate embedded core), then in software. that compatibility failed to save it from other market forces. i'm not sure what you think backward compatibility did to PowerPC. it wasn't compatible with "the chip it replaced" (the Motorola 68k series), sure, but Apple managed that transition quite well, including backwards compatibility higher up the stack (Apple, you'll note, has a history of handling these potentially fatal cut-overs very well). it wasn't compatible with the x86, but it was never designed to replace that; rather, it competes with it.
PowerPC failed to compete effectively against Intel/AMD in the laptop and desktop market, thus Apple was pretty much forced to switch. PowerPC was (and still is) doing quite well in very many embedded applications. Apple was the highest profile PowerPC user, but they never represented anything close to the majority of the market. most of the engineering work went into environments where a different set of trade-offs were appropriate.
if what you're saying were true, we ought to expect to see OS X's market share decrease after the clones were killed; the inverse is true. the primary reason for PowerPC's failure to remain competitive on performance in the desktop or laptop markets is that it simply wasn't the focus of the main designer and manufacturer, IBM. Apple machines (including clones) were always a minority of the PowerPC market, and IBM (and Motorola, then Freescale) simply focused on the larger market. IBM also focused a lot of its engineering efforts on POWER, rather than PowerPC, for the very high end stuff, which while it had a limited trickle-down effect for the PowerPC stuff Apple eventually saw, it was delayed by a generation and had a different set of trade-offs on power consumption and heat generation that was reasonable for Apple's products (where's my G5 laptop again?).
HP/Intel would have done better, technically, to work on Alpha, but they couldn't sufficiently dominate the market for their tastes in that case. half the point was to have something that they controlled, and Alpha, while technically great, was already too widespread for that. which, really, is the most important response to the original parent's point. what was AMD supposed to do, sit around while Intel dictated what the terms of the next stage of the market would be? what gives Intel some inherent right to that sort of dominance? AMD did exactly the right thing, from a business perspective: they saw what they believed to be a strategic mistake that left a market hole open, and produced a product to fill it. turns out they were right. turns out it was the right thing to do technically, too. when Itanium hype was at its peak, i remember lots of actual engineers i knew (and even some subset of the tech press) pointing out that EPIC was really just tweaked VLIW, and that had been tried and failed a few times. amd64 has consistently outperformed IA64.
even the quote in the summary is misleading. yes, IA64 is still plodding along in the high-end server market, but it's even an also-ran there. POWER and amd64, in particular, continue to trounce it, both for your normal "server" market and for the really high end scientific cluster stuff (it's got, what, one spot on the top500 list?). it's a pretty substantial failure, really all around.
you could make a reasonable argument that RDB systems are the "most versatile" way to store your data, but "best" is a much harder claim. for one thing, that versatility comes at a cost, including more complex server code, higher resource costs, and increased development and testing time. in a lot of cases, that ability to do arbitrary joins is entirely wasted: your data set is much more rigid than that. in your corporate directory, you're never going to join telephone numbers against department names, or titles against room numbers. here, typical RDB systems offer too little intelligence and too much weight. in other cases, those being described in the original article, the costs are simply unbearable. replication and distribution of relational databases is a real problem. even if everything can be stored locally, if your data set is large enough the RDB overhead is still going to hurt. this shows up in a lot of scientific or financial systems. RDB systems provide a very good compromise overall, sort of a least common denominator, but are no silver bullet. you characterize things like this as "regressions", which is true in the sense that they basic tech has been around for a long time, but the point is that the engineering tradeoffs change over time. it's not unreasonable to say that what tended to be a very good default tradeoff with the hardware, networking, and data sets common a decade ago might not be the best default tradeoff today.
it's even worse than that. joins are the most costly part of DBs, but in more ways than people usually mean when they say that. sure, they're the most costly in terms of cpu time and disk access time on the DB server, but they're also often the most costly in terms of application design, testing, maintenance, and so on. the two common ways of removing joins from the picture are views or, as you note, moving them to the application. views can, depending on implementation, eliminate the cpu cost, and in conjunction with other tuning procedures, the disk cost, but do nothing about the other costs. moving the joins into the application saves cpu time on the DB server, but does nothing for disk access time (and makes some of the other tuning methods harder), and has no impact on the other costs (and yes, it'll make your application more of a mess).
um, there are applications other than web sites out there. take a look at sawzall, hancock, brook, or aurora. the data sets those applications get used for simply will not fit in a relational database without massive efforts in distribution and replication (and that introduces other problems). the stuff google's doing with BigTable is fascinating (er, if your into that kinda thing), and is very non-RDB. oh, and it's used for web sites.
no reason to assume that from the text. comparing disk-based to disk-based, something designed to just do key/value pairs (or tuples, even) is going to perform better than something designed to provide more flexibility.
part of the issue with the current generation of relational databases is that in the significant majority of cases (i'd say 3/4 in my experience, across multiple industries and applications), the relations are very static and, with only a little bit of intelligence, trivially obvious. in these cases, all the JOIN and FROM mechanics end up being simply unneeded overhead. you end up with extra work for the application developer to understand and represent these and a bunch of extra work on the database server to put them together. you also end up with the structure of the database being embedded in the application, which is a maintenance nightmare. to a degree, the "view" feature common to most large RDBs addresses these, but in those cases you often end up with the same maintenance issues (just shifted from the app developer to the DBA) and the view ends up needing to know just as much about the internals of the DB as the application code otherwise would have (although that is still an improvement, since presumably whoever's putting new views on your DB server knows about the DB structure anyway). and unless you build a set of views designed to accommodate any reasonable use of your data up front (rather than doing it as needed for a given application, which is the standard practice), the time for this remains in your application development timeline, and complicates testing. also, even this partial solution is unavailable if there's no direct relationship between whoever presents the data and whoever's writing the app.
in these cases, an IRDB (I=implicit) system, where the server can construct the "views" dynamically based on a trivial understanding of the database, yields simpler queries, reduced maintenance, and faster application development and testing cycles. in your example, invoice in the first table is always going to join against invoice in the second; you're not going to try and join invoice against items, or join customer to items (which isn't the same as saying you can't query for customer given items, or vice versa).
But you need to hire Percona to get the same performance out of MySQL that you get from SQL Server out of the box.
this has not been my experience. at least with version 8 (two back from current), performance was miserable compared to either mysql or postgresql of comparable vintage. this was my first serious experience using mssql, but with no tuning on either side, both mysql and postgresql outperformed mssql by a factor of about 2. while we never got the database on the production system swapped out (development was underway to replace the application it was supporting anyway), and thus i can't speak to mysql or postgresql's reliability in the same use environment, mssql was very unstable. the database would hang indefinitely if either a query or the resulting data was too large, and, as near as we could tell, once every other month or so for no particular reason. the data set was tens of thousands of records a month going back a few years, which is not a trivial sum of data, but shouldn't be considered a lot for a modern database. while it's not a direct comparison, i've used mysql in several production projects and have seen less than a half dozen hangs in production total. i've only used postgresql in production on one project, but have seen no production hangs.
Or have the NSA mod it for you! Did everyone suddenly forget that we're not talking about an off-the-shelf model here? Unless one of these "armchair security experts" has any real details on the mods the NSA has performed on this device, this entire topic is stupid.
agreed, it's quite good. a bit long, and dense in parts (not bad, per se, but heavy); you might consider breaking it down a bit depending on the structure of your program.
see, that's kinda the reaction i was going for. i wish i'd gone to your school; my administration mostly just squirmed and looked at me uncomfortably.;-)
of course, the reality is that all these naming discussions are stupid. they're all really describing the system, not naming it, and from that perspective "GNU/Linux" is exactly as correct as "Linux" or "BSD/Linux" or "xorg/GNU/apache/perl/Bell Labs/Apple/Linux" - they just choose to describe different parts. the name of the system is "Slackware Linux", "Debian GNU/Linux" (because Debian said so), or "Knoppix". saying "GNU/Linux" does not name a system; people who make systems get to name them.
you can get systems with more or less GNU on them, just like you can get systems with more or less xorg or Sun on them. running "open source based box" without GNU isn't nearly as hard as you think it is (see, for example, Inferno and Plan 9). granted, people writing under the GNU banner are prolific, but many systems ship by default with very little, and at least some can be had with none.
you're also setting up a very convenient double-standard. you'd have just as much trouble (if not more) finding a system (open or closed) that BSD code hasn't touched; that doesn't mean there ought to be systems called BSD/Windows95 or BSD/OS/2.
not really. i over-simplified and omitted history.
more precisely, the project started as an effort to add whatever "extra stuff" was necessary to a dramatically neutered linux kernel to make it work as a BIOS. that only lasted a few years; since then (circa 2001) the focus has been on that "extra stuff", and that's what the name "LinuxBIOS" has refereed to for most of the project's existence.
it might not be "that bad", but it certainly isn't that good, either. yes, the certainly could do better with some reasonable investment, particularly if they simply picked a different pre-existing starting point. they probably need good driver coverage, but certainly not as broad as Linux; if they dropped CGA cards, obscure tape drives, and token-ring network adaptors, they're probably not going to hurt the utility of the finished system. and yes, i have no problem believing that, with a year or so and enough funding to hire a good bunch of developers, talking an existing, but more interesting/modern system than Linux, and adding driver support and porting applications should be no real problem at all.
i'm no Hurd fan, but at least it'd be different. you mention compatibility, but that's not always a good thing. if their goals are to have something of interest to others, useful for themselves, and which stimulates a local IT industry, and they're willing to put some real money into it, doing something that explicitly isn't X11 and POSIX-ish might be worthwhile. it's just disappointing nobody's trying it.
I understand the desire for countries to have their own systems software; there's a lot of benefits you wouldn't get from just slapping some fonts and custom admin tools on top of an existing distribution. But if they're going to go this route, isn't anyone willing to be a bit more creative than tweaking Linux? Is that really the best we can do? Given the massive market forces on normal capitalist enterprises, I understand why Linux is so attractive; it's sort of a least-common-denominator effect, combined with being at least reasonably accessible (mostly C, no too-obscure extensions, &c). But governments (any of them, regardless of what the rest of the economic system looks like) are not normal capitalist enterprises. If the intent is to produce something worthwhile, stimulate a local software industry, and be secure in your result, couldn't Russia (or China, or the US, or EU, or Germany, or any number of other sufficiently large governments) work on something that actually advances the state of software, rather than a nationalized/localized version of a modern rehash of 30+ year old ideas?
Slashdot Mirror
no, no, no... they were way ahead of their time. those were 500 heavily DRM'd cassettes. if you tried dubbing it, you just got 19200 baud screeches.
oh, bloody hell, where're my mod points when i need 'em? best /. comment in a month.
false. you buy one part; that part can execute x86 code. the chip, therefor, has x86 compatibility. your next point even seems to admit it, while pointing out the (correct) fact that the compatibility simply wasn't very good. but that's not the same as not existing.
false, as a sibling has noted. PowerPC's designed happened to make emulation easy, but that was a selection criteria, not a design criteria.
false, for two reasons. first, successful competition does not need to lead to monopoly or monoculture, so your premise isn't any good. second, even if you believe it is, it only holds if you're competing within the same market, and the point is PowerPC, mainly, didn't. further, you entirely (i suspect intentionally) ignore the real point of the comment, was that up the thread the claim was made that PowerPC failed because it didn't have backward compatibility, while it did. you also seem to think PowerPC is dead, which isn't the case at all.
did i miss the announcement where /. would start posting non-english stories? the grammar looks similar, but that certainly isn't english vocabulary.
y'know, i'm embarrassed to say i never made that connection before. that's a really interesting line of thought.
still, MIPS was having lots of other problems, including a rather big split in focus between high-end servers and embedded systems, two markets with very different design constraints; schizophrenia probably did them in. that and getting in bed with WIntel.
PA-RISC was a pretty obvious knock-off, but no sympathy for HP making their own stupid decisions. the most direct and disappointing casualty was likely Alpha, who really lacked anyone who cared for it at all after DEC got eaten.
lack of chip-level backwards compatibility is an issue, but not a deal breaker. that can be reasonably managed, and has in plenty of cases you can point to without trying too hard. these examples failed to deliver on their promise for entirely unrelated reasons.
look at the examples given, and you'll see compatibility wasn't really a factor for the first two, either.
Itanic had explicit backwards compatibility, at first in hardware (through the use of a separate embedded core), then in software. that compatibility failed to save it from other market forces.
i'm not sure what you think backward compatibility did to PowerPC. it wasn't compatible with "the chip it replaced" (the Motorola 68k series), sure, but Apple managed that transition quite well, including backwards compatibility higher up the stack (Apple, you'll note, has a history of handling these potentially fatal cut-overs very well). it wasn't compatible with the x86, but it was never designed to replace that; rather, it competes with it.
PowerPC failed to compete effectively against Intel/AMD in the laptop and desktop market, thus Apple was pretty much forced to switch. PowerPC was (and still is) doing quite well in very many embedded applications. Apple was the highest profile PowerPC user, but they never represented anything close to the majority of the market. most of the engineering work went into environments where a different set of trade-offs were appropriate.
if what you're saying were true, we ought to expect to see OS X's market share decrease after the clones were killed; the inverse is true. the primary reason for PowerPC's failure to remain competitive on performance in the desktop or laptop markets is that it simply wasn't the focus of the main designer and manufacturer, IBM. Apple machines (including clones) were always a minority of the PowerPC market, and IBM (and Motorola, then Freescale) simply focused on the larger market. IBM also focused a lot of its engineering efforts on POWER, rather than PowerPC, for the very high end stuff, which while it had a limited trickle-down effect for the PowerPC stuff Apple eventually saw, it was delayed by a generation and had a different set of trade-offs on power consumption and heat generation that was reasonable for Apple's products (where's my G5 laptop again?).
HP/Intel would have done better, technically, to work on Alpha, but they couldn't sufficiently dominate the market for their tastes in that case. half the point was to have something that they controlled, and Alpha, while technically great, was already too widespread for that.
which, really, is the most important response to the original parent's point. what was AMD supposed to do, sit around while Intel dictated what the terms of the next stage of the market would be? what gives Intel some inherent right to that sort of dominance? AMD did exactly the right thing, from a business perspective: they saw what they believed to be a strategic mistake that left a market hole open, and produced a product to fill it. turns out they were right.
turns out it was the right thing to do technically, too. when Itanium hype was at its peak, i remember lots of actual engineers i knew (and even some subset of the tech press) pointing out that EPIC was really just tweaked VLIW, and that had been tried and failed a few times. amd64 has consistently outperformed IA64.
even the quote in the summary is misleading. yes, IA64 is still plodding along in the high-end server market, but it's even an also-ran there. POWER and amd64, in particular, continue to trounce it, both for your normal "server" market and for the really high end scientific cluster stuff (it's got, what, one spot on the top500 list?). it's a pretty substantial failure, really all around.
you could make a reasonable argument that RDB systems are the "most versatile" way to store your data, but "best" is a much harder claim.
for one thing, that versatility comes at a cost, including more complex server code, higher resource costs, and increased development and testing time.
in a lot of cases, that ability to do arbitrary joins is entirely wasted: your data set is much more rigid than that. in your corporate directory, you're never going to join telephone numbers against department names, or titles against room numbers. here, typical RDB systems offer too little intelligence and too much weight.
in other cases, those being described in the original article, the costs are simply unbearable. replication and distribution of relational databases is a real problem. even if everything can be stored locally, if your data set is large enough the RDB overhead is still going to hurt. this shows up in a lot of scientific or financial systems.
RDB systems provide a very good compromise overall, sort of a least common denominator, but are no silver bullet. you characterize things like this as "regressions", which is true in the sense that they basic tech has been around for a long time, but the point is that the engineering tradeoffs change over time. it's not unreasonable to say that what tended to be a very good default tradeoff with the hardware, networking, and data sets common a decade ago might not be the best default tradeoff today.
it's even worse than that. joins are the most costly part of DBs, but in more ways than people usually mean when they say that. sure, they're the most costly in terms of cpu time and disk access time on the DB server, but they're also often the most costly in terms of application design, testing, maintenance, and so on.
the two common ways of removing joins from the picture are views or, as you note, moving them to the application. views can, depending on implementation, eliminate the cpu cost, and in conjunction with other tuning procedures, the disk cost, but do nothing about the other costs. moving the joins into the application saves cpu time on the DB server, but does nothing for disk access time (and makes some of the other tuning methods harder), and has no impact on the other costs (and yes, it'll make your application more of a mess).
um, there are applications other than web sites out there. take a look at sawzall, hancock, brook, or aurora. the data sets those applications get used for simply will not fit in a relational database without massive efforts in distribution and replication (and that introduces other problems). the stuff google's doing with BigTable is fascinating (er, if your into that kinda thing), and is very non-RDB. oh, and it's used for web sites.
no reason to assume that from the text. comparing disk-based to disk-based, something designed to just do key/value pairs (or tuples, even) is going to perform better than something designed to provide more flexibility.
part of the issue with the current generation of relational databases is that in the significant majority of cases (i'd say 3/4 in my experience, across multiple industries and applications), the relations are very static and, with only a little bit of intelligence, trivially obvious. in these cases, all the JOIN and FROM mechanics end up being simply unneeded overhead. you end up with extra work for the application developer to understand and represent these and a bunch of extra work on the database server to put them together. you also end up with the structure of the database being embedded in the application, which is a maintenance nightmare.
to a degree, the "view" feature common to most large RDBs addresses these, but in those cases you often end up with the same maintenance issues (just shifted from the app developer to the DBA) and the view ends up needing to know just as much about the internals of the DB as the application code otherwise would have (although that is still an improvement, since presumably whoever's putting new views on your DB server knows about the DB structure anyway). and unless you build a set of views designed to accommodate any reasonable use of your data up front (rather than doing it as needed for a given application, which is the standard practice), the time for this remains in your application development timeline, and complicates testing. also, even this partial solution is unavailable if there's no direct relationship between whoever presents the data and whoever's writing the app.
in these cases, an IRDB (I=implicit) system, where the server can construct the "views" dynamically based on a trivial understanding of the database, yields simpler queries, reduced maintenance, and faster application development and testing cycles. in your example, invoice in the first table is always going to join against invoice in the second; you're not going to try and join invoice against items, or join customer to items (which isn't the same as saying you can't query for customer given items, or vice versa).
this has not been my experience. at least with version 8 (two back from current), performance was miserable compared to either mysql or postgresql of comparable vintage. this was my first serious experience using mssql, but with no tuning on either side, both mysql and postgresql outperformed mssql by a factor of about 2.
while we never got the database on the production system swapped out (development was underway to replace the application it was supporting anyway), and thus i can't speak to mysql or postgresql's reliability in the same use environment, mssql was very unstable. the database would hang indefinitely if either a query or the resulting data was too large, and, as near as we could tell, once every other month or so for no particular reason. the data set was tens of thousands of records a month going back a few years, which is not a trivial sum of data, but shouldn't be considered a lot for a modern database.
while it's not a direct comparison, i've used mysql in several production projects and have seen less than a half dozen hangs in production total. i've only used postgresql in production on one project, but have seen no production hangs.
Or have the NSA mod it for you! Did everyone suddenly forget that we're not talking about an off-the-shelf model here? Unless one of these "armchair security experts" has any real details on the mods the NSA has performed on this device, this entire topic is stupid.
agreed, it's quite good. a bit long, and dense in parts (not bad, per se, but heavy); you might consider breaking it down a bit depending on the structure of your program.
oh, all the stickers come off. trust me.
see, that's kinda the reaction i was going for. i wish i'd gone to your school; my administration mostly just squirmed and looked at me uncomfortably. ;-)
(pardon the self-reply)
of course, the reality is that all these naming discussions are stupid. they're all really describing the system, not naming it, and from that perspective "GNU/Linux" is exactly as correct as "Linux" or "BSD/Linux" or "xorg/GNU/apache/perl/Bell Labs/Apple/Linux" - they just choose to describe different parts. the name of the system is "Slackware Linux", "Debian GNU/Linux" (because Debian said so), or "Knoppix". saying "GNU/Linux" does not name a system; people who make systems get to name them.
you can get systems with more or less GNU on them, just like you can get systems with more or less xorg or Sun on them. running "open source based box" without GNU isn't nearly as hard as you think it is (see, for example, Inferno and Plan 9). granted, people writing under the GNU banner are prolific, but many systems ship by default with very little, and at least some can be had with none.
you're also setting up a very convenient double-standard. you'd have just as much trouble (if not more) finding a system (open or closed) that BSD code hasn't touched; that doesn't mean there ought to be systems called BSD/Windows95 or BSD/OS/2.
not really. i over-simplified and omitted history.
more precisely, the project started as an effort to add whatever "extra stuff" was necessary to a dramatically neutered linux kernel to make it work as a BIOS. that only lasted a few years; since then (circa 2001) the focus has been on that "extra stuff", and that's what the name "LinuxBIOS" has refereed to for most of the project's existence.
for the authoritative story, here's the name change announcement from about a year ago.
because it isn't linux, and really has nothing to do with linux. the original name was a marketing gimmick.
it might not be "that bad", but it certainly isn't that good, either. yes, the certainly could do better with some reasonable investment, particularly if they simply picked a different pre-existing starting point. they probably need good driver coverage, but certainly not as broad as Linux; if they dropped CGA cards, obscure tape drives, and token-ring network adaptors, they're probably not going to hurt the utility of the finished system. and yes, i have no problem believing that, with a year or so and enough funding to hire a good bunch of developers, talking an existing, but more interesting/modern system than Linux, and adding driver support and porting applications should be no real problem at all.
i'm no Hurd fan, but at least it'd be different. you mention compatibility, but that's not always a good thing. if their goals are to have something of interest to others, useful for themselves, and which stimulates a local IT industry, and they're willing to put some real money into it, doing something that explicitly isn't X11 and POSIX-ish might be worthwhile. it's just disappointing nobody's trying it.
I understand the desire for countries to have their own systems software; there's a lot of benefits you wouldn't get from just slapping some fonts and custom admin tools on top of an existing distribution. But if they're going to go this route, isn't anyone willing to be a bit more creative than tweaking Linux? Is that really the best we can do?
Given the massive market forces on normal capitalist enterprises, I understand why Linux is so attractive; it's sort of a least-common-denominator effect, combined with being at least reasonably accessible (mostly C, no too-obscure extensions, &c). But governments (any of them, regardless of what the rest of the economic system looks like) are not normal capitalist enterprises. If the intent is to produce something worthwhile, stimulate a local software industry, and be secure in your result, couldn't Russia (or China, or the US, or EU, or Germany, or any number of other sufficiently large governments) work on something that actually advances the state of software, rather than a nationalized/localized version of a modern rehash of 30+ year old ideas?