The key to my argument was: People are going to access your database behind your back, and they aren't going to use your abstraction layer (which you didn't port to PHP3 or VB6 or whatever, no matter how many dozen languages you did support) when they do it. I've seen it happen. I've even had to do it myself.
Although the primary language is Java, I expect the only way non-Java folks will even be able to connect to, query from, and submit to our future data stores are through a web service accessible from all modern languages. Besides, there's no other choice. Relational databases with locking are simply algorithmically unsuitable.
Yes, I know what VSC is and does. It versions files.
I know what Time Machine is and does. It versions files AND PROVIDES AND API TO QUERY HISTORY WITHIN AN APPLICATION (that's utilized by the built-in software). This lets you pull out 1 record from your address book database and restore it to the present without restoring the rest of that file. Or pull 1 entry (including metadata, photo, and any other information spread across multiple files) out of the iPhoto database and return it to the present. It also lets you do queries... so I could search for "SEMW" in Address Book back through time and find the entry before it was deleted from within Address Book's UI.
And I made no claims about which came first. Just that they're very different pieces of software and that SVC only solves half the problem (file backup and retrieval).
Perhaps you could tell me what steps I'd have to take in SVC to do the following: Search through my address book to when SEMW still existed and restore that 1 record to the present. In Time Machine, that's open address book, click on Time Machine, type "SEMW" into the search, hit return, click restore. Now that's utility!
FYI, you can't be charged for contempt for complying with a court order to the best of your ability.
You certainly can. It won't stick, and you'll be released on appeal. But be prepared to spend a little time in jail if you take the attitude expressed in your post. And your lawyer will certainly appreciate the fees he gets defending you and your company from the sarbox litigation, successful or not.
However, you can't prove a negative. When the court requests the records, and you produce a pile of encrypted garbage or no logs at all and assert they weren't relevant anyway,... well, don't drop the soap in the showers when doing time for contempt.
Note that if you're a publicly traded company, SarbOx requires that your IM server keep logs of all employee correspondence for a certain amount of time. There are several Jabber/XMPP servers that can be configured to conform to SarbOx, but I'm not aware of any which do with a default install. You really don't want to be the one sent to jail when you can't produce the requested IM records during the court proceedings.
If all Time Machine did was back up batches of files, you might have a point. However, Time Machine is also a backup retrieval system. And not one that's just limited to files-- you can retrieve individual photos, address book records, etc., from your backup. And you can search back through time to the last time your query changed.
So Shadow Volume Copy addresses about 1/2 of what Time Machine does, but does it without requiring a separate volume.
they are taking a lead out off Apples book again, "release often and charge alot for overglorified service packs"
Huh? Each one of Apple's point releases brought as much utility to the user as Vista brings over XP. You're probably one of those folks who thinks that Shadow Volume Copy and/or rsync is "basically the same" as Time Machine, too, aren't you? Or that batch files and Automator are basically the same? Don't believe what the Windows (super)sites tell you on this stuff.
Then you have to implement your conflict recovery in a consistent and correct way in every programming language anyone in the organization is using
Yup, pretty much. Preferably you provide mechanisms to make this easy in a library you distribute along with the DB access tools.
Safety checks belong in the database to ensure they'll actually happen.
Not if you want your database to operate distributed across the planet with thousands or hundreds of thousands of simultaneous writers.
This is exactly the sort of response I mentioned in my original message. Folks whose livelihood depend on traditional database ideas will fight tooth and nail to preserve the status quo.
My Math/CS program didn't have any class that taught a particular language. Most of the classes had some primary language, but you were expected to learn it yourself outside the coursework. In various courses I used C, C++, Lisp, Scheme, SML, Prolog, and a few others. Everyone's biased towards how they chose to learn, but I think it's the breadth that taught me the most rather than just some low-level C hacking.
As for Java, I think it's one of the most advanced languages in its balance between functionality and the ability to debug and maintain the code. The simple syntax feels a little limiting at first, but after maintaining some code for a few years you grow to love it. Parsers are trivial and thus all the IDEs have powerful analysis and refactoring tools, and it's very easy to see what's going on. The object model is simple and operators almost always do the same thing all the time. I really don't miss slugging through dozens of obscure.h files mentally parsing macros.
However, I honestly don't know what learning CS is like in Java, as I went to school just before the "big bang" of Java, WWW, ubiquitous e-mail, etc. I could imagine it being a little harder to learn some of the data structures and algorithms, since the ones included in the language are so rich. And threading and concurrency is so much easier in Java than almost all the languages that came before it I'm not sure whether current CS students even know what dilemnas philosophers faced at round eating tables.
Yeah, hitting the ground as slow as possible is always good... it's not a bad thing to shoot for on regular landings, too:).
It's true that everyone with a pilot's certificate has done engine loss procedures ad nauseam. However, as far as I know (I only have my Private Pilot's ticket) it is not required to train on dual simultaneous engine loss on short final in a large jet aircraft. It simply "never" happens. So... you're both right. It's a situation way outside of the typical contingency and training envelope, but not a completely foreign concept... you keep it at best glide until you've made the airport and keep the plane under control, then slow down as much as you can and hope for the best.
Finally, I would take issue with the idea that this scenario is not something that pilots train for. I have known a number of pilots who have said that they train for engine failure-based crash landings on other forms of aircraft (usually light aircraft) and while this is not the exact same scenario, the same principles apply (keep control of the aircraft as long as possible, and slow down as much as possible).
I never said any such thing. I'm a pilot myself, and agree that pilots train for this from very early-on. However, you definitely do NOT "slow down as much as possible"-- you set the plane to Vy, which is defined as the speed at which the aircraft achieves "max glide", or the best glide ratio. If you're landing in air without significant up or downdrafts, that also translates to the maximum distance over the ground per foot of lost altitude. (With downdrafts, maximum travel over ground may be significantly higher than Vy if you can get out of the downdraft quickly.)
However, once you've cleared obstacles and it becomes apparent you will not make the runway, then you slow down to the minimum airspeed possible to reduce the energy of impact (which is relative to the square of speed, making this important).
Also, a quick review of accident reports will show that fuel starvation is still a plurality of the identified causes for small aircraft crashes, despite the training. It's instantly something to focus on when you have multiple simultaneous engine failure along with lack of fire... if the investigation is ruling that unlikely, so be it. My original comment about that being a likely cause based on the news reports still held.
By the way, I agree that the pilots maneuvered the plane expertly during this crash landing. I think the jury is still out whether they did something wrong before the situation became critical, though-- we just don't know. It's pretty rare for a crash to be due to a single failure of anything, mechanical or human.
no, as I mentioned I didn't read the report. But the only other case I'm familiar with where a jet lost both engines at once was when a fuel leak occurred, the pilot misdiagnosed the problem and opened the crossover feed between the tanks, dumping all the fuel out the leak and starving both engines. I'm not saying that's exactly what happened here, but something related to the fuel supply still seems likely to me.
Our company's IT dept automatically sets all the machines to go to sleep after 30 minutes of inactivity-- at least for laptops. (And to go into password-protected screen saver after 5.) These types of policies seem like a reasonable compromise between being "green" and keeping folks productive. (Much more reasonable than their policies surrounding which sites they block in their firewall.)
But in the end, the more paternalistic a company is, the more the employees are going to act like children.
America's Army also helped me learn the exact angle at which to fire a 203 as soon as I come out of a tunnel near the bridge to hit the guys getting out of the convoy on the other side! And to close doors in people's faces if I think they have a grenade! And always fire machine guns into vents if I think there might be movement! AA is incredibly educational.
I've only read the news reports, but the most salient facts I've seen are: 1. Both engines cut out simultaneously, and 2. There was no fire despite major wing and undercarriage damage.
IMHO, the overwhelmingly likely cause is fuel exhaustion due to either excessive fuel burn during the flight or insufficient fuel aboard on takeoff. It's a very common cause of aircraft loss, although not as much in commercial aviation. Either one of the above would make me a little suspicious of fuel exhaustion, but both together raise big red flags in my mind.
But loss of fuel is the only thing I can think of for two turbines to fail simultaneously. Each is essentially its own generator and a self-contained mechanical unit. The only thing they share is a control system (which you suspect) and a fuel supply (which I suspect).
you can't scale the system beyond a single client having write access unless you give up correctness...or explicitly manage it. Detecting the conflicts is significantly cheaper and more parallelizable than preventing them-- then it's a matter of doing something reasonable about it after-the-fact.
Basically, I'd like a setup where I don't have to put up with the stuff that you just mentioned you're willing to put up with.
I have two 19" external monitors which are identical and side-by-side. I like that arrangement. It's a setup my work laptop (a Dell) supports nicely. In addition, the Dell snaps out and in in 5 seconds so I can pop off to a meeting. Who wants to spend 30 seconds to dock/undock? Especially since I use almost all the ports (ethernet, VGA, DVI, 3 USB 2.0s, audio,...) Apple's supposed to be about making things elegant and easy. Yet the current lineup of machines are hacky and hard to use from a hardware perspective.
By the way, I also like two buttons. Maybe I should just give up my 18 years of Mac loyalty and buy a Dell already and stop complaining.
The BookEndz are very hacky and don't allow you to have two external monitors as I mentioned in my post (which you even quoted, apparently without reading).
A colleague of mine replied anonymously to my post and said things much more eloquently than I could. No, it's nothing to do with table design or adjustments... it's a fundamental shortcoming of relational theory. Relational databases require transactional integrity and therefore a centralized locking system. There is no way to scale it beyond a certain point.
It's a speaker-independent, continuous speech recognizer that can be configured to do everything from simple commands to full-text dictation. It's not Dragon's stuff, but it's pretty good.
Nope, the parent poster is closer to the truth. The frequency of mutation, the types of mutation that happen, and the likelihood that a mutation will affect anything at all are all determined by the genome. It is definitely possible to select for faster or slower genetic drift. And it's not a new theory that evolution has optimized for the genetic drift (and reproductive rates) that best matches the rate of change of our environment over the past million years.
Yup. I'm holding on to my G5 tower for now until Apple either ships a reasonable desktop computer (ie. one with a slotted video card and a good mainstream processor) or a laptop with a docking station that will let me have 2 monitors but still snap it out and go.
I've been waiting almost 5 years so far. I'm hoping they do this before I'm forced to go to the dark side.
Dang, sometimes I wish someone other than Apple made "normal" computers that ran MacOS X.
Speaking as someone who works for a company whose product uses a database that is neither relational nor object-oriented, I can say from experience that folks who have devoted a significant amount of their lives to mastering that methodology see anything else as a threat. There are definitely use-cases for non-relational databases-- they're used at both Google and Amazon, as well as many other places. You can either burn significant effort defending your decision to go non-relational, or you can move on and ignore these folks and produce great products. The problem is that sometimes they make good points (especially about some aspects of indexing), but it's almost always lost in the "but... but... but... you're not relational!" argument.
Slashdot Mirror
Ah, to be young and naive.
There's no other viable choice... the Quicktime infrastructure is the Microsoft Office of A/V editing.
The key to my argument was: People are going to access your database behind your back, and they aren't going to use your abstraction layer (which you didn't port to PHP3 or VB6 or whatever, no matter how many dozen languages you did support) when they do it. I've seen it happen. I've even had to do it myself.
Although the primary language is Java, I expect the only way non-Java folks will even be able to connect to, query from, and submit to our future data stores are through a web service accessible from all modern languages. Besides, there's no other choice. Relational databases with locking are simply algorithmically unsuitable.
I think you completely missed my point.
Yes, I know what VSC is and does. It versions files.
I know what Time Machine is and does. It versions files AND PROVIDES AND API TO QUERY HISTORY WITHIN AN APPLICATION (that's utilized by the built-in software). This lets you pull out 1 record from your address book database and restore it to the present without restoring the rest of that file. Or pull 1 entry (including metadata, photo, and any other information spread across multiple files) out of the iPhoto database and return it to the present. It also lets you do queries... so I could search for "SEMW" in Address Book back through time and find the entry before it was deleted from within Address Book's UI.
And I made no claims about which came first. Just that they're very different pieces of software and that SVC only solves half the problem (file backup and retrieval).
Perhaps you could tell me what steps I'd have to take in SVC to do the following: Search through my address book to when SEMW still existed and restore that 1 record to the present. In Time Machine, that's open address book, click on Time Machine, type "SEMW" into the search, hit return, click restore. Now that's utility!
FYI, you can't be charged for contempt for complying with a court order to the best of your ability.
You certainly can. It won't stick, and you'll be released on appeal. But be prepared to spend a little time in jail if you take the attitude expressed in your post. And your lawyer will certainly appreciate the fees he gets defending you and your company from the sarbox litigation, successful or not.
However, you can't prove a negative. When the court requests the records, and you produce a pile of encrypted garbage or no logs at all and assert they weren't relevant anyway, ... well, don't drop the soap in the showers when doing time for contempt.
Note that if you're a publicly traded company, SarbOx requires that your IM server keep logs of all employee correspondence for a certain amount of time. There are several Jabber/XMPP servers that can be configured to conform to SarbOx, but I'm not aware of any which do with a default install. You really don't want to be the one sent to jail when you can't produce the requested IM records during the court proceedings.
If all Time Machine did was back up batches of files, you might have a point. However, Time Machine is also a backup retrieval system. And not one that's just limited to files-- you can retrieve individual photos, address book records, etc., from your backup. And you can search back through time to the last time your query changed.
So Shadow Volume Copy addresses about 1/2 of what Time Machine does, but does it without requiring a separate volume.
they are taking a lead out off Apples book again, "release often and charge alot for overglorified service packs"
Huh? Each one of Apple's point releases brought as much utility to the user as Vista brings over XP. You're probably one of those folks who thinks that Shadow Volume Copy and/or rsync is "basically the same" as Time Machine, too, aren't you? Or that batch files and Automator are basically the same? Don't believe what the Windows (super)sites tell you on this stuff.
Then you have to implement your conflict recovery in a consistent and correct way in every programming language anyone in the organization is using
Yup, pretty much. Preferably you provide mechanisms to make this easy in a library you distribute along with the DB access tools.
Safety checks belong in the database to ensure they'll actually happen.
Not if you want your database to operate distributed across the planet with thousands or hundreds of thousands of simultaneous writers.
This is exactly the sort of response I mentioned in my original message. Folks whose livelihood depend on traditional database ideas will fight tooth and nail to preserve the status quo.
My Math/CS program didn't have any class that taught a particular language. Most of the classes had some primary language, but you were expected to learn it yourself outside the coursework. In various courses I used C, C++, Lisp, Scheme, SML, Prolog, and a few others. Everyone's biased towards how they chose to learn, but I think it's the breadth that taught me the most rather than just some low-level C hacking.
.h files mentally parsing macros.
As for Java, I think it's one of the most advanced languages in its balance between functionality and the ability to debug and maintain the code. The simple syntax feels a little limiting at first, but after maintaining some code for a few years you grow to love it. Parsers are trivial and thus all the IDEs have powerful analysis and refactoring tools, and it's very easy to see what's going on. The object model is simple and operators almost always do the same thing all the time. I really don't miss slugging through dozens of obscure
However, I honestly don't know what learning CS is like in Java, as I went to school just before the "big bang" of Java, WWW, ubiquitous e-mail, etc. I could imagine it being a little harder to learn some of the data structures and algorithms, since the ones included in the language are so rich. And threading and concurrency is so much easier in Java than almost all the languages that came before it I'm not sure whether current CS students even know what dilemnas philosophers faced at round eating tables.
Yeah, hitting the ground as slow as possible is always good... it's not a bad thing to shoot for on regular landings, too :).
It's true that everyone with a pilot's certificate has done engine loss procedures ad nauseam. However, as far as I know (I only have my Private Pilot's ticket) it is not required to train on dual simultaneous engine loss on short final in a large jet aircraft. It simply "never" happens. So... you're both right. It's a situation way outside of the typical contingency and training envelope, but not a completely foreign concept... you keep it at best glide until you've made the airport and keep the plane under control, then slow down as much as you can and hope for the best.
Finally, I would take issue with the idea that this scenario is not something that pilots train for. I have known a number of pilots who have said that they train for engine failure-based crash landings on other forms of aircraft (usually light aircraft) and while this is not the exact same scenario, the same principles apply (keep control of the aircraft as long as possible, and slow down as much as possible).
I never said any such thing. I'm a pilot myself, and agree that pilots train for this from very early-on. However, you definitely do NOT "slow down as much as possible"-- you set the plane to Vy, which is defined as the speed at which the aircraft achieves "max glide", or the best glide ratio. If you're landing in air without significant up or downdrafts, that also translates to the maximum distance over the ground per foot of lost altitude. (With downdrafts, maximum travel over ground may be significantly higher than Vy if you can get out of the downdraft quickly.)
However, once you've cleared obstacles and it becomes apparent you will not make the runway, then you slow down to the minimum airspeed possible to reduce the energy of impact (which is relative to the square of speed, making this important).
Also, a quick review of accident reports will show that fuel starvation is still a plurality of the identified causes for small aircraft crashes, despite the training. It's instantly something to focus on when you have multiple simultaneous engine failure along with lack of fire... if the investigation is ruling that unlikely, so be it. My original comment about that being a likely cause based on the news reports still held.
By the way, I agree that the pilots maneuvered the plane expertly during this crash landing. I think the jury is still out whether they did something wrong before the situation became critical, though-- we just don't know. It's pretty rare for a crash to be due to a single failure of anything, mechanical or human.
no, as I mentioned I didn't read the report. But the only other case I'm familiar with where a jet lost both engines at once was when a fuel leak occurred, the pilot misdiagnosed the problem and opened the crossover feed between the tanks, dumping all the fuel out the leak and starving both engines. I'm not saying that's exactly what happened here, but something related to the fuel supply still seems likely to me.
Our company's IT dept automatically sets all the machines to go to sleep after 30 minutes of inactivity-- at least for laptops. (And to go into password-protected screen saver after 5.) These types of policies seem like a reasonable compromise between being "green" and keeping folks productive. (Much more reasonable than their policies surrounding which sites they block in their firewall.)
But in the end, the more paternalistic a company is, the more the employees are going to act like children.
America's Army also helped me learn the exact angle at which to fire a 203 as soon as I come out of a tunnel near the bridge to hit the guys getting out of the convoy on the other side! And to close doors in people's faces if I think they have a grenade! And always fire machine guns into vents if I think there might be movement! AA is incredibly educational.
I've only read the news reports, but the most salient facts I've seen are:
1. Both engines cut out simultaneously, and
2. There was no fire despite major wing and undercarriage damage.
IMHO, the overwhelmingly likely cause is fuel exhaustion due to either excessive fuel burn during the flight or insufficient fuel aboard on takeoff. It's a very common cause of aircraft loss, although not as much in commercial aviation. Either one of the above would make me a little suspicious of fuel exhaustion, but both together raise big red flags in my mind.
But loss of fuel is the only thing I can think of for two turbines to fail simultaneously. Each is essentially its own generator and a self-contained mechanical unit. The only thing they share is a control system (which you suspect) and a fuel supply (which I suspect).
you can't scale the system beyond a single client having write access unless you give up correctness ...or explicitly manage it. Detecting the conflicts is significantly cheaper and more parallelizable than preventing them-- then it's a matter of doing something reasonable about it after-the-fact.
Basically, I'd like a setup where I don't have to put up with the stuff that you just mentioned you're willing to put up with.
...) Apple's supposed to be about making things elegant and easy. Yet the current lineup of machines are hacky and hard to use from a hardware perspective.
I have two 19" external monitors which are identical and side-by-side. I like that arrangement. It's a setup my work laptop (a Dell) supports nicely. In addition, the Dell snaps out and in in 5 seconds so I can pop off to a meeting. Who wants to spend 30 seconds to dock/undock? Especially since I use almost all the ports (ethernet, VGA, DVI, 3 USB 2.0s, audio,
By the way, I also like two buttons. Maybe I should just give up my 18 years of Mac loyalty and buy a Dell already and stop complaining.
The BookEndz are very hacky and don't allow you to have two external monitors as I mentioned in my post (which you even quoted, apparently without reading).
A colleague of mine replied anonymously to my post and said things much more eloquently than I could. No, it's nothing to do with table design or adjustments... it's a fundamental shortcoming of relational theory. Relational databases require transactional integrity and therefore a centralized locking system. There is no way to scale it beyond a certain point.
Carnegie Mellon open-source sphinx years ago: http://cmusphinx.sourceforge.net/html/cmusphinx.php
It's a speaker-independent, continuous speech recognizer that can be configured to do everything from simple commands to full-text dictation. It's not Dragon's stuff, but it's pretty good.
They even have a pure Java version of it: http://cmusphinx.sourceforge.net/sphinx4/
Nope, the parent poster is closer to the truth. The frequency of mutation, the types of mutation that happen, and the likelihood that a mutation will affect anything at all are all determined by the genome. It is definitely possible to select for faster or slower genetic drift. And it's not a new theory that evolution has optimized for the genetic drift (and reproductive rates) that best matches the rate of change of our environment over the past million years.
Heh, I rest my case.
Yup. I'm holding on to my G5 tower for now until Apple either ships a reasonable desktop computer (ie. one with a slotted video card and a good mainstream processor) or a laptop with a docking station that will let me have 2 monitors but still snap it out and go.
I've been waiting almost 5 years so far. I'm hoping they do this before I'm forced to go to the dark side.
Dang, sometimes I wish someone other than Apple made "normal" computers that ran MacOS X.
Speaking as someone who works for a company whose product uses a database that is neither relational nor object-oriented, I can say from experience that folks who have devoted a significant amount of their lives to mastering that methodology see anything else as a threat. There are definitely use-cases for non-relational databases-- they're used at both Google and Amazon, as well as many other places. You can either burn significant effort defending your decision to go non-relational, or you can move on and ignore these folks and produce great products. The problem is that sometimes they make good points (especially about some aspects of indexing), but it's almost always lost in the "but... but... but... you're not relational!" argument.