>As anybody who has seen the movie knows, the Fifth Element is a sexy red-head.
Maybe if you're director Luc Besson (who married her, if I remember correctly). To the rest of us, she's an androgynous anorexic chick with dyed fluorescent orange hair. Sexy by the Aeon Flux standard, I guess...
Java (or at least, the class library) has the problem of bring caught between a rock and a hard place for client application development. One the one hand, people want the download to be small, but on the other hand, developers want a full-featured class library.
One solution to this would be to have a reduced class library for applets vs. standalone client development, but Sun chose not to do this. (Right now the size of the JRE installer is about 12-15MB depending on platform.) Presumably the motivation was to have a single platform for developers to target, and to avoid a situation where users would still have to download "the rest of Java" because they only had a reduced applet runtime.
Another solution would be to get OS vendors to bundle the JRE with their operating system. For an underdog OS vendor this would look like a great idea - just bundle this free thing and you get all these apps. But for Microsoft this would clearly not be a desirable outcome, so it's not surprising that they fought it. They were eventually prevented from bundling a (slightly) crippled Java, but a strategy of just refusing to bundle Java would have worked just about as well.
A third option almost happened - get a third party to bundle the JRE. Netscape did this, and as lots of folks are aware, the Netscape Java VM had some problems. One of them was the decision to defer VM startup until the first applet was encountered, leading to the cursed "Starting Java..." lockup that froze the whole browser (if not the whole computer) for several seconds. Users got used to the idea that Java = system lockup. The second problem was just VM quality. I've spoken to a couple of employees of Netscape about this, and they both point the finger at Sun, saying that basically what they shipped was heavily based on Sun code that (according to them) was very buggy. I had a mental picture of a mostly clean-room implementation but apparently Sun and Netscape collaborated very closely on the Netscape VM and it still had lots of bugs. So developers and users got used to the idea that Java = buggy. Of course the bundle-with-Netscape strategy worked for a while anyway, but when Netscape became less desirable, it ceased to be an effective vehicle for bundling a JRE.
>we've found we get the best results (e.g., as close to running universally as possible) by compiling on Linux
So when you *compile* your Java app on Windows or Mac OS, the resulting.class files are less compatible with your target web clients than when you compile it on Linux?
I think you need to rephrase that.
Or, perhaps you can explain why the.class files that come out of the compiler on Windows are different from the ones that come out of the compiler on Linux, and further that this is why your web app is more compatible with client OS's and browsers.
Maybe you're using an unusual compiler? I dunno. I've never heard of anything like this.
>>Which is why a Java shell is needed. >And how is that going to work with C/C++ programs?
What a red herring this is. But, I'll play along anyway.
It could just ignore them, because those aren't part of the problem domain. Rather than trying to reinvent the wheel, it could do something new and different, and let existing tools continue to do a good job at what they were meant for.
Alternatively, it could duplicate something like sh, and behave similarly.
You suggest that Java can't run C or C++ programs, cannot "handle signals", cannot manage environment variables, and cannot manage pipes. Why? To my knowledge, all of these except for fine control over signal handling are readily addressed by java.lang.Runtime and java.lang.Process.
Unless you really care deeply about precise signal handling behavior you'd probably not need to go into undocumented territory (sun.misc.Signal and sun.misc.SignalHandler). Of course, if you got all of these things, you could then gleefully complain that this shell is not portable, since those concepts don't exist on all of the platforms that Java is available on. (Try and guess why they aren't documented.)
>Linux is the best platform when you have no requirements for the platform.
Yes, Linux satisfies an empty set of requirements perfectly. Or, not at all, depending on whether the question you're asking is "how many requirements were satisfied? (0)" or " how many requirements were NOT satisfied? (0)".
OTOH, all other operating systems are equally satisfactory under these conditions... even those with no features, because they don't even exist.
I haven't seen anybody mention this so I thought I ought to:
In Java, == and Object.equals(Object) mean different things. == compares two object references and evaluates to true if they are the same. Object.equals(Object) compares two objects and evaluates to true if their value is the same. == will tell you about identity, while Object.equals(Object) will tell you about value equivalence. Value equivalence is something that the class author has discretion over, so it's necessarily something you'd want to override. reference equality doesn't change, so you don't need to.
If you were to (somehow) overload == so that it did a value-based comparison of objects, that would obscure the ability to determine if two references pointed to the same object. This would a Very Bad Situation.
I'm not arguing for or against operator overloading in general, I'm just pointing out that == and Object.equals(Object) mean different things in Java, and those are both necessary things.
It's very rare that a checked exception can never happen, in my experience. It's not that hard to do this if you really think it'll never happen, and it's safer:
} catch (UnexpectedCheckedException uce) {// Should never happen but just in case...
throw new RuntimeException("Wow, didn't expect this", uce);// handy new 1.4 constructor }
>It's all about job security with these guys. They've always got FUD prepared like >* You can't rely on that other vendor's database because it will not scale >* You can't rely on that other vendor's database because it will corrupt your data >* Don't let developers write DDLs or they will crash the database >* Moving business logic out of the database will cause huge performance problems
Based on your other posts and the fact that you keep sticking up for MySQL and disparaging the features that it lacks, I'd have to guess that in each of these cases the DBA was right and you were wrong.
MySQL cannot scale up as well as Oracle, DB2, or MS SQL Server. That may not matter much for most projects, but for folks at the UPS and Wal-Mart end of the scale, it matters.
MySQL even with InnoDB has major flaws and missing features that make it a lot easier to corrupt your data compared to other SQL DBMSs. This would be excusable except for the fact that MySQL happily accepts DDL and DML that uses these features, and quietly does the wrong thing. Would you use a crypto product that claimed 128-bit keys but just used ROT-13? The vendor assures you that most people don't really need encryption, and hey, it's really a lot faster!
Moving logic out of the database very often can do horrible things to performance. You are aware that in-memory access is faster than getting something over the network, right? DBMSs also use very carefully tuned algorithms and data structures, which brand-new application code typically does not. Even if it does, why are you duplicating code that already works?
Whether your DDL crashes databases, I can't say. I've never seen DDL that bad. I've never seen a database crash. (I have seen Java code that wedged an E450 so that it was totally unresponsive and frozen and had to be manually power cycled in order to get it running again.)
>The first three things you listed have all been MySQL features ever since they added the InnoDB engine
from Creating InnoDB Tables: To create an InnoDB table, you must specify and ENGINE = InnoDB or TYPE = InnoDB option in the table creation SQL statement:
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=InnoDB; CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) TYPE=InnoDB;
Do I also have to say "pretty please can I have a real database now?"
>As for "stored procedures, views, triggers,..." these fall under the category of --USELESS FEATURES--
OK, you've just revealed yourself as someone who has never worked on a project that involved large data volume. When you get to that point, triggers and stored procs are your friend. Otherwise have fun setting up that gig-E between your MySQL server and application server.
Oh wait, let me guess... same box?
Here's a hint: the key to a multitier architecture is that code runs in multiple tiers. There's a reason for that. It's not "useless".
They can get platform independence (which I can only guess means database product independence in this case) by using a persistence framework that supports multiple back-ends.
I've seen this sort of thinking before but not at this level of boneheadedness. Application developers in general want to live in application-land and not leave, possibly because application-land involves a ton of complicated technologies that they already understand and they'd rather not have to learn how to make DHTML do table sorting or how to optimize a query or analyze a query plan. That's understandable if not ideal for the project.
The problem is clearly the "everything looks like a nail" issue. In this case it's even worse because full-featured (="not MySQL") SQL DBMSs have a bunch of features that were added to minimize the pain of client-server architectures, and these features can be useful in modern multitier architectures. I find T-SQL and PL/SQL to be pretty wimpy languages, but it doesn't take a month to learn enough of them to write a trigger or stored proc that can make a gigantic difference in terms of performance.
The thing that worries me more is the approach of using the database as little more than a transactional flat file, with no constraints and no thought given to the data model other than whatever's easiest for the person writing the load/save code. That sort of approach is very risky from a transactional sense (transactions happen for individual row updates atomically rather than for the whole multi-object operation, forcing developers to use an application-layer transaction manager for what could be a simple transaction at the DB layer) and from the sense of longevity (it's unsafe to touch the database unless you go through the application's persistence layer).
Usually what this ends up with (in my experience) is a situation where application developers slowly reimplement[1] the stuff that's already in the DBMS, except they do a worse job and miss a whole bunch of stuff that the big SQL DBMS vendors worked through and nailed down in the mid- to late 90s.
My own solution for this was to take a job working on an application built with a wimpy RAD scripting language, to "see how the other side lives" so to speak, because there's really no way to avoid leaning heavily on the DBMS in such an architecture. That certainly validated my inclination to be anal-retentive about declarative constraints, and actually we only needed two triggers.
I think the biggest thing that teams can do going forward to avoid this sort of problem is to make DMBS skills a mandatory part of the architect's skill set, and to use hard-skills tests when hiring developers. The architect needs to have SQL skills beyond trivial select/update/insert/delete, and somebody on the team should be a "database developer". To me that role means that you're not an application developer and not a DBA, but somewhere in between - the person who writes (or approves) the hairy SQL statements, writes (or approves) the data model and changes to it, and perhaps most importantly, who knows how to look at a slow chunk of code that hits the DB and can fix it, whether that means a stored proc or changing the application code or data model, or calling the DBA over for some low-level optimization (which in my experience is never the problem). This sort of person is apparently also most likely to be found riding a unicorn because I've not had a lot of success finding them, but they are out there.
[1] on a project-by-project basis, on their employer's dime, instead of improving the user-facing functionality of the application
Back in the earlier days of Java (1.1.6-1.1.8 era, 1997-98 I think) there was very little in the way of off the shelf persistence management. You had servlets and JDBC and that was about it. Everybody rolled their own database interface layer, and basically what worked well was to have the hand-written SQL hidden in a small set of classes that each know how to various persistence operations for one object. This practice has been canonized as the Data Access Object pattern and works pretty well.
Even with modern persistence frameworks like Hibernate (highly recommended, BTW) that have caching, you can hide that activity in a DAO and decide later whether you need to replace the autogenerated SQL with some fancy hand coded stuff. Complex object-relational mappings (i.e. not a simple table=class setup) are actually expressed declaratively so that's not something the coders have to worry about.
The point is that it's encapsulated, so any "impure" decisions that you must make in order to get the system working properly for real-world use are very localized.
I would say that mapping the object model to the data model directly in such a way that you can't change it later is actually a counterexample of encapsulation. Ideally they should look pretty similar but be mapped by some intermediate layer that can adjust for the differences.
>every vendor seems to think that the standardized language is inadequate >and yet they make no roads towards improving the standard.
That's a pretty bold claim (equivalent to "no SQL database vendors are helping to improve the SQL standard"). I suspect that the major vendors have quite a bit of involvement in the ISO SQL standards process, but that they also have customers asking for features NOW, and demanding backward compatibility in new releases.
If company A has a proprietary extension that provides a feature you need, and company B scolds you for not being willing to wait several years for a standard to come out that provides access to that feature in a sane and efficient way, what would you do?
IMO the correct answer is that you should use proprietary hacks now (isolating them in the code so that they can be un-hacked later), and at the same time, you should lean on the vendor to implement the standards that have already been published, and to hurry up with the next version of the standard.
>Hierachical databases are by definition unstructured (LDAP,
This nonsense about calling anything that isn't strictly tabular "unstructured" has got to stop. "Structured" is NOT a synonym for "relational".
LDAP has objectclasses, and an objectclass's attributes are typed. It's hardly "unstructured".
If you want to think of it in these terms, an objectclass is like a table; an attribute is like a column. Maybe add a table with columns for dn, table name, and an FK to the PK of each table, and voila, you've got a SQL DBMS back-end for an LDAP directory. (No, it's not optimized for ad hoc querying, but that's not what LDAP is for either, and it'd be blazing fast for lookups by DN.)
>It's no longer just enough to come up with a good idea; it must be marketed.
When was having a great idea and not telling anybody about it enough? "Build a better mousetrap..." is just a saying.
Cleanliness of code has never been a critical success factor. Ask IBM, or Microsoft, or Apple (especially Woz - the Apple II was full of impressive hacks, but they were hacks).
It might work well for a different usage scenario: ripping a DVD.
The first step would be getting the data off of the DVD. Clearly that wouldn't be parallelizable unless you had multiple copies of the DVD (or some sort of hideous DVD multicast SAN).
The second step (decryption) would probably be parallelizable. I don't know much about how CSS works but I imagine that it would be a fairly easy task to split the ciphertext into blocks for distribution and decryption.
The third step (recompression) could be split up for parallelization by scene.
The fourth step would be serial - reassembling the compressed movie into a single file, or maybe a few files if a maximum size (say, 700MB) for each single file were desired.
Ideally, the second and third steps could be combined. Empirically it's clear that it's possible to jump to a scene without decrypting the entire title up to that point, so it should be possible to split the encrypted scene data out, pass it to a node, and get back that same scene in recompressed form.
Splitting things up this way would probably also overcome the problem the parent post describes (that of not wanting every frame to be a key frame). Starting each scene as a key frame would add trivial overhead at worst; at best this is what a serial encoding process would do anyway since the frame content probably changes drastically with each scene change anyway.
Here are three gotchas that can make this sort of thing less appealing than it may seem at first:
Problem type: The problem may not be well suited to running on a bunch of PCs (especially when the agent app isn't allowed to take 100% of the machine's resources to accimplish the task) over typical office networks. Basically if the app needs to communicate frequently with other nodes, or if a huge data set is involved (or both), latency or bandwidth issues might outweigh the possible advantage of putting more CPUs to work.
Security: The data may be highly sensitive, in which case you might not want to put it on ordinary desktop PCs that might have untrustworthy users, spyware, etc.
Configuration: The configuration of your office's PCs may vary enough to make the cost of getting a companywide desktop cluster working unacceptably high. You'd have to pick a few target configurations and settle for that. Hopefully drivers and such wouldn't matter as much as CPU, RAM, disk, and OS version, but there are still companies that are just now getting their desktops updated to Win2K. There's also the headache of installing yet another required application on a large number of heterogeneous machines, which is virtually guaranteed to result in confusing installation problems. Oops, our app crashes if the user has this or that service pack installed. Oops, our app requires strong encryption. You could build your app on top of some sort of moderately portable framework or VM or whatever but that will have system requirements too, and probably will have some surprising gotchas when deployed in a real-world environment.
>As much as I love Apple, OSX is very bloated, yet does not scale to the hardware at all (i.e. OSX is the same whether you install it on 300Mhz G3 or 2.5Ghz G5)
That's not true. What about Quartz Extreme? That stuff only turns on if you have a suitable video card (unless you use the hack that turns it on anyway, which makes it crazy slow).
Mostly though you're right, but that's true of pretty much all desktop OS's right now - it doesn't care how much CPU or RAM or HD you have; you get what you get and it's either slower or faster, period. Maybe I'm forgetting some examples...?
If you want to argue that booting into text mode is "scaling with hardware" that's kinda weak - neither automatic nor tied to hardware. You can run X11 on a 486 and text mode on an Opteron; that doesn't prove anything other than that Unix is cool.:)
because I got an invite yesterday and Mozilla's Junk Mail filter tagged it as spam.
SpamAssassin didn't, though, which proves that those scheming bastards obviously rigged Mozilla 1.7 so that it would filter gmail invitations. There's no other explanation, right?
It couldn't be because the invitation email looks a lot like spam...?
Who said it (the MP3 trojan referenced by the parent post) wasn't a trojan? I said: "You know that trojan wasn't actually found in the wild, right?" That would be your clue that I think it is in fact a trojan.
Now, this other trojan is different. Clearly it too is a trojan. The distinction is that the one you mentioned (fake Word prevew) apparently was found in the wild, which makes it a real threat, as opposed to something that an AV company made up so that they could declare victory against it. (Actually I wasn't aware of that one; if I had been I would have pointed that out as a more viable argument against "no trojans" than the not-found-in-the-wild MP3 trojan.)
Unless that secure hardware device has audio ouput jacks, there is some point at which the DRM'd content is un-DRM'd for playback, and there's vulnerable software that can be hacked to save a cleartext version of the content instead of (or in addition to) playing it back. If the hardware device somehow can verify the playback app, how about a stub audio hardware driver that just saves the "output" as a.wav file? How about a little USB device that pretends to be a set of USB speakers, but what it really does is to stream the audio back into the computer where a companion app can save it to a.wav file?
Face it, the *entire computer system* has to be tamper-proof from end to end, looking like a black box that DRM'd content goes into and analog audio comes out of, or else someone is going to find a weak point and exploit it.
And remember that "thought to be tamper-proof" and "designed to be cryptographically secure" are not the same as "actually tamper-proof" and "actually cryptographically secure". CSS was broken because one of the trusted partners goofed in their implementation. Microsoft can't make a browser that is secure after however many years and however many critical updates and service packs; why should we think that they (or anyone else) can make a DRM system that is?
Slashdot Mirror
But the USPS charges $0.32 in order to let you send that check. That's almost as much as Apple's cut. You're hardly winning.
>As anybody who has seen the movie knows, the Fifth Element is a sexy red-head.
Maybe if you're director Luc Besson (who married her, if I remember correctly). To the rest of us, she's an androgynous anorexic chick with dyed fluorescent orange hair. Sexy by the Aeon Flux standard, I guess...
She is funny, though. "Multipass!"
Java (or at least, the class library) has the problem of bring caught between a rock and a hard place for client application development. One the one hand, people want the download to be small, but on the other hand, developers want a full-featured class library.
One solution to this would be to have a reduced class library for applets vs. standalone client development, but Sun chose not to do this. (Right now the size of the JRE installer is about 12-15MB depending on platform.) Presumably the motivation was to have a single platform for developers to target, and to avoid a situation where users would still have to download "the rest of Java" because they only had a reduced applet runtime.
Another solution would be to get OS vendors to bundle the JRE with their operating system. For an underdog OS vendor this would look like a great idea - just bundle this free thing and you get all these apps. But for Microsoft this would clearly not be a desirable outcome, so it's not surprising that they fought it. They were eventually prevented from bundling a (slightly) crippled Java, but a strategy of just refusing to bundle Java would have worked just about as well.
A third option almost happened - get a third party to bundle the JRE. Netscape did this, and as lots of folks are aware, the Netscape Java VM had some problems. One of them was the decision to defer VM startup until the first applet was encountered, leading to the cursed "Starting Java..." lockup that froze the whole browser (if not the whole computer) for several seconds. Users got used to the idea that Java = system lockup. The second problem was just VM quality. I've spoken to a couple of employees of Netscape about this, and they both point the finger at Sun, saying that basically what they shipped was heavily based on Sun code that (according to them) was very buggy. I had a mental picture of a mostly clean-room implementation but apparently Sun and Netscape collaborated very closely on the Netscape VM and it still had lots of bugs. So developers and users got used to the idea that Java = buggy. Of course the bundle-with-Netscape strategy worked for a while anyway, but when Netscape became less desirable, it ceased to be an effective vehicle for bundling a JRE.
>we've found we get the best results (e.g., as close to running universally as possible) by compiling on Linux
.class files are less compatible with your target web clients than when you compile it on Linux?
.class files that come out of the compiler on Windows are different from the ones that come out of the compiler on Linux, and further that this is why your web app is more compatible with client OS's and browsers.
So when you *compile* your Java app on Windows or Mac OS, the resulting
I think you need to rephrase that.
Or, perhaps you can explain why the
Maybe you're using an unusual compiler? I dunno. I've never heard of anything like this.
>>Which is why a Java shell is needed.
>And how is that going to work with C/C++ programs?
What a red herring this is. But, I'll play along anyway.
It could just ignore them, because those aren't part of the problem domain. Rather than trying to reinvent the wheel, it could do something new and different, and let existing tools continue to do a good job at what they were meant for.
Alternatively, it could duplicate something like sh, and behave similarly.
You suggest that Java can't run C or C++ programs, cannot "handle signals", cannot manage environment variables, and cannot manage pipes. Why? To my knowledge, all of these except for fine control over signal handling are readily addressed by java.lang.Runtime and java.lang.Process.
Unless you really care deeply about precise signal handling behavior you'd probably not need to go into undocumented territory (sun.misc.Signal and sun.misc.SignalHandler). Of course, if you got all of these things, you could then gleefully complain that this shell is not portable, since those concepts don't exist on all of the platforms that Java is available on. (Try and guess why they aren't documented.)
>Linux is the best platform when you have no requirements for the platform.
Yes, Linux satisfies an empty set of requirements perfectly. Or, not at all, depending on whether the question you're asking is "how many requirements were satisfied? (0)" or " how many requirements were NOT satisfied? (0)".
OTOH, all other operating systems are equally satisfactory under these conditions... even those with no features, because they don't even exist.
I haven't seen anybody mention this so I thought I ought to:
In Java, == and Object.equals(Object) mean different things. == compares two object references and evaluates to true if they are the same. Object.equals(Object) compares two objects and evaluates to true if their value is the same. == will tell you about identity, while Object.equals(Object) will tell you about value equivalence. Value equivalence is something that the class author has discretion over, so it's necessarily something you'd want to override. reference equality doesn't change, so you don't need to.
If you were to (somehow) overload == so that it did a value-based comparison of objects, that would obscure the ability to determine if two references pointed to the same object. This would a Very Bad Situation.
I'm not arguing for or against operator overloading in general, I'm just pointing out that == and Object.equals(Object) mean different things in Java, and those are both necessary things.
It's very rare that a checked exception can never happen, in my experience. It's not that hard to do this if you really think it'll never happen, and it's safer:
// Should never happen but just in case... // handy new 1.4 constructor
} catch (UnexpectedCheckedException uce) {
throw new RuntimeException("Wow, didn't expect this", uce);
}
>It's all about job security with these guys. They've always got FUD prepared like
>* You can't rely on that other vendor's database because it will not scale
>* You can't rely on that other vendor's database because it will corrupt your data
>* Don't let developers write DDLs or they will crash the database
>* Moving business logic out of the database will cause huge performance problems
Based on your other posts and the fact that you keep sticking up for MySQL and disparaging the features that it lacks, I'd have to guess that in each of these cases the DBA was right and you were wrong.
MySQL cannot scale up as well as Oracle, DB2, or MS SQL Server. That may not matter much for most projects, but for folks at the UPS and Wal-Mart end of the scale, it matters.
MySQL even with InnoDB has major flaws and missing features that make it a lot easier to corrupt your data compared to other SQL DBMSs. This would be excusable except for the fact that MySQL happily accepts DDL and DML that uses these features, and quietly does the wrong thing. Would you use a crypto product that claimed 128-bit keys but just used ROT-13? The vendor assures you that most people don't really need encryption, and hey, it's really a lot faster!
Moving logic out of the database very often can do horrible things to performance. You are aware that in-memory access is faster than getting something over the network, right? DBMSs also use very carefully tuned algorithms and data structures, which brand-new application code typically does not. Even if it does, why are you duplicating code that already works?
Whether your DDL crashes databases, I can't say. I've never seen DDL that bad. I've never seen a database crash. (I have seen Java code that wedged an E450 so that it was totally unresponsive and frozen and had to be manually power cycled in order to get it running again.)
>The first three things you listed have all been MySQL features ever since they added the InnoDB engine
..." these fall under the category of --USELESS FEATURES--
from Creating InnoDB Tables:
To create an InnoDB table, you must specify and ENGINE = InnoDB or TYPE = InnoDB option in the table creation SQL statement:
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=InnoDB;
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) TYPE=InnoDB;
Do I also have to say "pretty please can I have a real database now?"
>As for "stored procedures, views, triggers,
OK, you've just revealed yourself as someone who has never worked on a project that involved large data volume. When you get to that point, triggers and stored procs are your friend. Otherwise have fun setting up that gig-E between your MySQL server and application server.
Oh wait, let me guess... same box?
Here's a hint: the key to a multitier architecture is that code runs in multiple tiers. There's a reason for that. It's not "useless".
They can get platform independence (which I can only guess means database product independence in this case) by using a persistence framework that supports multiple back-ends.
I've seen this sort of thinking before but not at this level of boneheadedness. Application developers in general want to live in application-land and not leave, possibly because application-land involves a ton of complicated technologies that they already understand and they'd rather not have to learn how to make DHTML do table sorting or how to optimize a query or analyze a query plan. That's understandable if not ideal for the project.
The problem is clearly the "everything looks like a nail" issue. In this case it's even worse because full-featured (="not MySQL") SQL DBMSs have a bunch of features that were added to minimize the pain of client-server architectures, and these features can be useful in modern multitier architectures. I find T-SQL and PL/SQL to be pretty wimpy languages, but it doesn't take a month to learn enough of them to write a trigger or stored proc that can make a gigantic difference in terms of performance.
The thing that worries me more is the approach of using the database as little more than a transactional flat file, with no constraints and no thought given to the data model other than whatever's easiest for the person writing the load/save code. That sort of approach is very risky from a transactional sense (transactions happen for individual row updates atomically rather than for the whole multi-object operation, forcing developers to use an application-layer transaction manager for what could be a simple transaction at the DB layer) and from the sense of longevity (it's unsafe to touch the database unless you go through the application's persistence layer).
Usually what this ends up with (in my experience) is a situation where application developers slowly reimplement[1] the stuff that's already in the DBMS, except they do a worse job and miss a whole bunch of stuff that the big SQL DBMS vendors worked through and nailed down in the mid- to late 90s.
My own solution for this was to take a job working on an application built with a wimpy RAD scripting language, to "see how the other side lives" so to speak, because there's really no way to avoid leaning heavily on the DBMS in such an architecture. That certainly validated my inclination to be anal-retentive about declarative constraints, and actually we only needed two triggers.
I think the biggest thing that teams can do going forward to avoid this sort of problem is to make DMBS skills a mandatory part of the architect's skill set, and to use hard-skills tests when hiring developers. The architect needs to have SQL skills beyond trivial select/update/insert/delete, and somebody on the team should be a "database developer". To me that role means that you're not an application developer and not a DBA, but somewhere in between - the person who writes (or approves) the hairy SQL statements, writes (or approves) the data model and changes to it, and perhaps most importantly, who knows how to look at a slow chunk of code that hits the DB and can fix it, whether that means a stored proc or changing the application code or data model, or calling the DBA over for some low-level optimization (which in my experience is never the problem). This sort of person is apparently also most likely to be found riding a unicorn because I've not had a lot of success finding them, but they are out there.
[1] on a project-by-project basis, on their employer's dime, instead of improving the user-facing functionality of the application
Back in the earlier days of Java (1.1.6-1.1.8 era, 1997-98 I think) there was very little in the way of off the shelf persistence management. You had servlets and JDBC and that was about it. Everybody rolled their own database interface layer, and basically what worked well was to have the hand-written SQL hidden in a small set of classes that each know how to various persistence operations for one object. This practice has been canonized as the Data Access Object pattern and works pretty well.
Even with modern persistence frameworks like Hibernate (highly recommended, BTW) that have caching, you can hide that activity in a DAO and decide later whether you need to replace the autogenerated SQL with some fancy hand coded stuff. Complex object-relational mappings (i.e. not a simple table=class setup) are actually expressed declaratively so that's not something the coders have to worry about.
The point is that it's encapsulated, so any "impure" decisions that you must make in order to get the system working properly for real-world use are very localized.
I would say that mapping the object model to the data model directly in such a way that you can't change it later is actually a counterexample of encapsulation. Ideally they should look pretty similar but be mapped by some intermediate layer that can adjust for the differences.
>every vendor seems to think that the standardized language is inadequate
>and yet they make no roads towards improving the standard.
That's a pretty bold claim (equivalent to "no SQL database vendors are helping to improve the SQL standard"). I suspect that the major vendors have quite a bit of involvement in the ISO SQL standards process, but that they also have customers asking for features NOW, and demanding backward compatibility in new releases.
If company A has a proprietary extension that provides a feature you need, and company B scolds you for not being willing to wait several years for a standard to come out that provides access to that feature in a sane and efficient way, what would you do?
IMO the correct answer is that you should use proprietary hacks now (isolating them in the code so that they can be un-hacked later), and at the same time, you should lean on the vendor to implement the standards that have already been published, and to hurry up with the next version of the standard.
>Hierachical databases are by definition unstructured (LDAP,
This nonsense about calling anything that isn't strictly tabular "unstructured" has got to stop. "Structured" is NOT a synonym for "relational".
LDAP has objectclasses, and an objectclass's attributes are typed. It's hardly "unstructured".
If you want to think of it in these terms, an objectclass is like a table; an attribute is like a column. Maybe add a table with columns for dn, table name, and an FK to the PK of each table, and voila, you've got a SQL DBMS back-end for an LDAP directory. (No, it's not optimized for ad hoc querying, but that's not what LDAP is for either, and it'd be blazing fast for lookups by DN.)
The Konfabulator home page suggests that it wasn't licensed.
>it matters how nifty the case is
Funny you should mention that. Apple's first computer didn't even have a case.
>It's no longer just enough to come up with a good idea; it must be marketed.
When was having a great idea and not telling anybody about it enough? "Build a better mousetrap..." is just a saying.
Cleanliness of code has never been a critical success factor. Ask IBM, or Microsoft, or Apple (especially Woz - the Apple II was full of impressive hacks, but they were hacks).
It might work well for a different usage scenario: ripping a DVD.
The first step would be getting the data off of the DVD. Clearly that wouldn't be parallelizable unless you had multiple copies of the DVD (or some sort of hideous DVD multicast SAN).
The second step (decryption) would probably be parallelizable. I don't know much about how CSS works but I imagine that it would be a fairly easy task to split the ciphertext into blocks for distribution and decryption.
The third step (recompression) could be split up for parallelization by scene.
The fourth step would be serial - reassembling the compressed movie into a single file, or maybe a few files if a maximum size (say, 700MB) for each single file were desired.
Ideally, the second and third steps could be combined. Empirically it's clear that it's possible to jump to a scene without decrypting the entire title up to that point, so it should be possible to split the encrypted scene data out, pass it to a node, and get back that same scene in recompressed form.
Splitting things up this way would probably also overcome the problem the parent post describes (that of not wanting every frame to be a key frame). Starting each scene as a key frame would add trivial overhead at worst; at best this is what a serial encoding process would do anyway since the frame content probably changes drastically with each scene change anyway.
Here are three gotchas that can make this sort of thing less appealing than it may seem at first:
Problem type: The problem may not be well suited to running on a bunch of PCs (especially when the agent app isn't allowed to take 100% of the machine's resources to accimplish the task) over typical office networks. Basically if the app needs to communicate frequently with other nodes, or if a huge data set is involved (or both), latency or bandwidth issues might outweigh the possible advantage of putting more CPUs to work.
Security: The data may be highly sensitive, in which case you might not want to put it on ordinary desktop PCs that might have untrustworthy users, spyware, etc.
Configuration: The configuration of your office's PCs may vary enough to make the cost of getting a companywide desktop cluster working unacceptably high. You'd have to pick a few target configurations and settle for that. Hopefully drivers and such wouldn't matter as much as CPU, RAM, disk, and OS version, but there are still companies that are just now getting their desktops updated to Win2K. There's also the headache of installing yet another required application on a large number of heterogeneous machines, which is virtually guaranteed to result in confusing installation problems. Oops, our app crashes if the user has this or that service pack installed. Oops, our app requires strong encryption. You could build your app on top of some sort of moderately portable framework or VM or whatever but that will have system requirements too, and probably will have some surprising gotchas when deployed in a real-world environment.
>As much as I love Apple, OSX is very bloated, yet does not scale to the hardware at all (i.e. OSX is the same whether you install it on 300Mhz G3 or 2.5Ghz G5)
:)
That's not true. What about Quartz Extreme? That stuff only turns on if you have a suitable video card (unless you use the hack that turns it on anyway, which makes it crazy slow).
Mostly though you're right, but that's true of pretty much all desktop OS's right now - it doesn't care how much CPU or RAM or HD you have; you get what you get and it's either slower or faster, period. Maybe I'm forgetting some examples...?
If you want to argue that booting into text mode is "scaling with hardware" that's kinda weak - neither automatic nor tied to hardware. You can run X11 on a 486 and text mode on an Opteron; that doesn't prove anything other than that Unix is cool.
Sweet! Then even on big iron you could have 100% of your CPU resources going to stupid Vonage ads.
>On the plus side, at least they'll have first mover advantage no matter how buggy. Hey, it worked for Windows...
Were they the first mover? (scratches head) That's not quite how I remember it happening.
because I got an invite yesterday and Mozilla's Junk Mail filter tagged it as spam.
SpamAssassin didn't, though, which proves that those scheming bastards obviously rigged Mozilla 1.7 so that it would filter gmail invitations. There's no other explanation, right?
It couldn't be because the invitation email looks a lot like spam...?
Nah.
Actually I was just being lazy and using ?? as a two-character wildcard. ??AA would match both MPAA and RIAA.
Example:
$ touch MPAA RIAA
$ ls ??AA
MPAA RIAA
But thanks for your hotheaded profane insults anyway.
>What about it makes it "not a trojan"?
Who said it (the MP3 trojan referenced by the parent post) wasn't a trojan? I said: "You know that trojan wasn't actually found in the wild, right?" That would be your clue that I think it is in fact a trojan.
Now, this other trojan is different. Clearly it too is a trojan. The distinction is that the one you mentioned (fake Word prevew) apparently was found in the wild, which makes it a real threat, as opposed to something that an AV company made up so that they could declare victory against it. (Actually I wasn't aware of that one; if I had been I would have pointed that out as a more viable argument against "no trojans" than the not-found-in-the-wild MP3 trojan.)
Unless that secure hardware device has audio ouput jacks, there is some point at which the DRM'd content is un-DRM'd for playback, and there's vulnerable software that can be hacked to save a cleartext version of the content instead of (or in addition to) playing it back. If the hardware device somehow can verify the playback app, how about a stub audio hardware driver that just saves the "output" as a .wav file? How about a little USB device that pretends to be a set of USB speakers, but what it really does is to stream the audio back into the computer where a companion app can save it to a .wav file?
Face it, the *entire computer system* has to be tamper-proof from end to end, looking like a black box that DRM'd content goes into and analog audio comes out of, or else someone is going to find a weak point and exploit it.
And remember that "thought to be tamper-proof" and "designed to be cryptographically secure" are not the same as "actually tamper-proof" and "actually cryptographically secure". CSS was broken because one of the trusted partners goofed in their implementation. Microsoft can't make a browser that is secure after however many years and however many critical updates and service packs; why should we think that they (or anyone else) can make a DRM system that is?