Integrating televisions with other technologies never seems to work out. TV with VCR combo... TV with DVD combo... TV with Fire Stick Combo... Just buy the TV you want and fork out the $40 for the Fire Stick.
At last, we finally have undeniable proof that Donald J. Trump is a deep cover Russian agent sent here decades ago to hand the U.S. over to Russia! And to think, they called us all delusional, hysterical crackpots, with zero critical thinking skills, all throwing childish temper tantrums because our candidate lost a close election. The fools! Vindication is now ours!
If this technology shows promise in spreading the Good News and making more disciples of Jesus Christ, then we will use it. Just like the printing press, radio, and internet before it. if it's just a distraction or poor use of resources, as I suspect it is, we'll just go with what works.
After watching a video of this engine fire, I kept looking for some kind of variable geometry component and didn't see it. It turns out there isn't one. The thrust pattern itself changes shape as a function of altitude to achieve the extra efficiency. This promotional video from Rocketdyne shows how it works.
Just posting this as a curiosity, but one of our Sunday School teachers at Church came along something interesting while preparing for a lesson. He somehow got sidetracked into some of the lesser known Jewish teachings (can't remember the Hebrew name for these,) and found this theory about Adam and Eve. The theory said that God took not a rib from Adam to create Eve, but rather Adam's penis bone. This explains not only the lack of a baculum in humans but also the reason the scrotum has a ridge of tissue in the middle to symbolize the scar Adam incurred from its removal. It at least made for a light-hearted start to Sunday School that morning.
there's no "universal spare part database" that manufacturers upload to
And if there was, they'd still want the $50 to download the part file so you could print it yourself. Heck, I ran across a book on amazon the other day that was $25 for hardcover or $25 for kindle.
Totally concur with others pointing out Amazon offers redundancy if you choose to use it.
We had webservers, database (master/slave,) and other services split across usa-east and usa-west.
When usa-east started showing problems, we:
*) Took the usa-east webservers out of round robin DNS (ttl 1hr)
*) Verified the slave (in usa-west) was up to date, shut down the master (usa-east,) and converted the slave to master.
*) Updated all webservers to point to the new master.
*) Cranked up new usa-west webservers / updated round robin DNS
I believe Amazon offers mechanisms to do this automatically or we could just always write our own failover scripts, but this is the tradeoff me made. We were willing to trade some service degradation by switching over manually in exchange for avoiding the pitfalls of false-positive detection. Very much an application specific tradeoff, not for everyone, but it worked for what we are doing.
The key was to avoid putting all eggs in the usa-east basket and splitting up across usa-west, even though we incur additional bandwidth fees, ie master/slave replication transfer is full fee between regions.
We were never concerned about cascading failures effecting multiple availability zones in a give region nor did it matter for us - our redundancy requirement was geographical diversity, not partitions within a datacenter. We were thinking natural disaster, but the architecture covered us in this case as well.
The coolest thing to me is just how quickly we were able to shuffle around these resources to avoid a problem area - a couple of hours. There's no way we could have done it so quickly with what we had before - a combination of our own colocated servers and VPS.
He couldn't be more dead-on regarding the Japanese. When I worked for a telecom vendor, we had a major project to adapt our software and hardware for NTT (Nippon Telephone & Telegraph.)
Two things I remember most:
*) The call we got about our 'defective' hardware. Turns out our own specifications called for 4 mounting screws to be included for a given circuit pack. We shipped 5. The call, after much cultural posturing, boiled down to "You mean you think our installers are imcompetent? You think so little of us?"
*) We had another circuit pack that had a severe overheating problem - when it hit this failure mode the heatsinks* would drop off into the bottom of the shelf. One of our executives told them "This is by design. It shortens the time to total failure, which reduces the overall fire risk." He was fired the next day.
[*the card had 3 DSPs, each with a heatsink that wasn't physically mounted, but stuck on with some kind of conductive glue.]
Ok, it allows third-party downloadable apps (their own app store?,) but "media-server functions have been omitted."
Can I pull media from my linux fileserver or not?
If the omitted functions just means it doesn't have local storage, then fine. I'm just hoping they don't cripple or disallow apps that can remotely fetch media.
If I could get that plus Netflix on a ~$100 box, I'd be all over it.
I had a professor in college, along with several colleagues and students, working on a formal proof for nuclear power plant control software. They had been been working for 5 years and, at the time, were about 10% complete.
Obviously, at that rate, the time to complete the formal proof is probably longer than the lifetime of the particular control system they were targeting.
Hopefully Formal Methods have come a long way since I last studied them 10 years ago. In any case, congratulations to this team of researchers at NICTA.
You should take your own words to heart, my friend.
This gentlemen lacks the academic credentials, actual work experience in a nuts-and-bolts IT role, and the track record of success in such a role to be an effective leader in this appointment. Bachelor of Arts? Masters in Public Policy? Please.
The idea that managers in one field (ie healthcare) can be interchanged into another (ie IT) is a myth. It's a bush-league mistake and one that is very costly and damaging.
It has to be said, over, and over again: you can't manage what you don't know. The worst managers I've met in this industry were non-technical, woke up one morning and decided they were engineers, then went about destroying projects and teams. An absolute disaster.
I just recently read Dune for the first time. Did I miss something? Triumvirate? Space Guild / Bene Gesserit / Emperor? Still don't see the parallel with the federal executive branch (though it's early and caffeine levels are low)
You sure are inconsistent. One second you oppose "one-size-fits-all zealotry" and the next you claim that the best solution for the above example is C. Give me a break. You've said nothing meaningful about what the network service actually does, but you're sure that C is most likely the best choice.
I believe you may have missed my point with the examples. I presented three separate problem domains and recommended three separate languages that might be appropriate given the very high-level descriptions I provided [I didn't mean to imply C/Java/Perl were the only choices]. One point of the examples is to show that "one-size-fits-all" for all three, in their totality, is likely sub-optimal. This most certainly is consistent with my point.
There are a host of reasons why C makes a poor choice for any network service. The high rate of security problems caused by incompentent developers nears the top of that list. To ignore that and recommend C anyway demonstrates a lack of real-world experience or very poor judgement.
Other languages do not have incompetent programmers or are excluded from security problems? Who's lacking real-world experience and demonstrating poor judgement here?
I think programmer competency is a bit of a red-herring since it could effect any project, regardless of language or problem domain. My point remains: pick the right tool for the right job. As a corollary, picking the right people (ie competent) for the job is equally as important.
There's nothing that turns me off more than the one-size-fits-all zealotry that often comes from the Java camp. One size does not fit all. It never has, and it never will.
Programming languages are tools. Pick the appropriate tool for the specific job. More specifically, understand the capabilities and deficiencies of a wide range of languages and map those appropriately to the specific problem domain you've been asked to tackle.
Examples:
*) Production quality, single-user, cross-platform application: Java is at the top of my list.
*) Production quality network service with deterministic behavior under load and soft-to-firm response-time requirements: Hard to beat C w/ Linux here.
*) Quick and dirty lab-only tool to thrash through some test results: Yep, it's Perl.
Engineering is all about trade-offs. Understanding your problem and the tools you have to solve it with are critical. Making a poor choice, especially early on, can be disastrous. Even though I don't discount the performance enhancements Java has enjoyed over the years, I'd be very hard-pressed to select a virtual-machine based language/system for any performance critical application requiring a deterministic response.
Pounding a square peg into a round hole by insisting on one language for everything doesn't demonstrate a lot of design-maturity or sophistication on the part of those making such claims.
I've worked this into my interview questions for new hires as well and have found it to be a pretty good indicator of who I'm dealing with, experience-wise. (hint: the guy who insisted on smalltalk for everything did not get the job)
Ability to "lock" the scheduler, so that the game gets 100% CPU until it unlocks (effectively making it a single process OS like DOS while in this mode).
Linux supports the ability to change the scheduling policy to something other than the default egalitarian multiuser policy to two other policies (FIFO & Round Robin w/ preemption & priorities) which more closely resemble a real-time scheduler [which I think is what you are getting at].
- Dell Dimension 2400N - Intel(R) Celeron(R) Processor at 2.4GHz with 400MHz front side bus - 128MB Shared DDR SDRAM at 333MHz - FreeDOS(TM) included in the box, ready to install - Dell(TM) Quietkey(R) Keyboard - Dell(R) 2-Button Scroll Mouse - 40GB ATA/100 Value Hard Drive - No Floppy Drive Included - No monitor - Integrated Intel(R) 3D Extreme Graphics - Integrated Audio - No Speakers - Integrated 10/100 Ethernet - No Modem - 1 Year Limited Warranty plus 1 Year On-site Service
Beef up the memory a little and you got yourself a nice home file server or project box.
My company, a telecom equipment provider, has several times in the past tried to move design engineering work to companies in India. As a software architect, my experience has been:
1) The Indian contractors have excellent attitudes, are friendly, and want to do a good job. I still keep in touch with one guy who was here in the states for a few months - before he went back for his arranged marriage - picked out by his mom from a book.
2) They are excellent at following a set of predefined steps to solve a problem, but run in to real difficulty if the problem requires deviating from their memorized steps. My education professor friend tells me this has to do with how their education system works. Deviation from the presented method is discouraged.
3) The language and timezone differences are both killers. It's frustrating and unproductive for all parties involved.
My company is on its third attempt at outsourcing design work to India. The first two attempts failed and the managers responsible for the transition are no longer with the company. They had no idea what they were getting into, which is a shame, since they were both decent managers. The current attempt acknowledges the failures of the past and is to focus more narrowly on software areas we think they are capable of handling. The result of this exercise has been a long list of stable software that hasn't changed in years and rarely has a problem. This, of course, leaves everyone questioning 'why are we doing this again?'.
Slashdot Mirror
Integrating televisions with other technologies never seems to work out. TV with VCR combo... TV with DVD combo... TV with Fire Stick Combo... Just buy the TV you want and fork out the $40 for the Fire Stick.
At last, we finally have undeniable proof that Donald J. Trump is a deep cover Russian agent sent here decades ago to hand the U.S. over to Russia! And to think, they called us all delusional, hysterical crackpots, with zero critical thinking skills, all throwing childish temper tantrums because our candidate lost a close election. The fools! Vindication is now ours!
If this technology shows promise in spreading the Good News and making more disciples of Jesus Christ, then we will use it. Just like the printing press, radio, and internet before it. if it's just a distraction or poor use of resources, as I suspect it is, we'll just go with what works.
After watching a video of this engine fire, I kept looking for some kind of variable geometry component and didn't see it. It turns out there isn't one. The thrust pattern itself changes shape as a function of altitude to achieve the extra efficiency. This promotional video from Rocketdyne shows how it works.
You rang?
Not thin enough,
Just posting this as a curiosity, but one of our Sunday School teachers at Church came along something interesting while preparing for a lesson. He somehow got sidetracked into some of the lesser known Jewish teachings (can't remember the Hebrew name for these,) and found this theory about Adam and Eve. The theory said that God took not a rib from Adam to create Eve, but rather Adam's penis bone. This explains not only the lack of a baculum in humans but also the reason the scrotum has a ridge of tissue in the middle to symbolize the scar Adam incurred from its removal. It at least made for a light-hearted start to Sunday School that morning.
there's no "universal spare part database" that manufacturers upload to
And if there was, they'd still want the $50 to download the part file so you could print it yourself. Heck, I ran across a book on amazon the other day that was $25 for hardcover or $25 for kindle.
Totally concur with others pointing out Amazon offers redundancy if you choose to use it.
We had webservers, database (master/slave,) and other services split across usa-east and usa-west.
When usa-east started showing problems, we:
*) Took the usa-east webservers out of round robin DNS (ttl 1hr)
*) Verified the slave (in usa-west) was up to date, shut down the master (usa-east,) and converted the slave to master.
*) Updated all webservers to point to the new master.
*) Cranked up new usa-west webservers / updated round robin DNS
I believe Amazon offers mechanisms to do this automatically or we could just always write our own failover scripts, but this is the tradeoff me made. We were willing to trade some service degradation by switching over manually in exchange for avoiding the pitfalls of false-positive detection. Very much an application specific tradeoff, not for everyone, but it worked for what we are doing.
The key was to avoid putting all eggs in the usa-east basket and splitting up across usa-west, even though we incur additional bandwidth fees, ie master/slave replication transfer is full fee between regions.
We were never concerned about cascading failures effecting multiple availability zones in a give region nor did it matter for us - our redundancy requirement was geographical diversity, not partitions within a datacenter. We were thinking natural disaster, but the architecture covered us in this case as well.
The coolest thing to me is just how quickly we were able to shuffle around these resources to avoid a problem area - a couple of hours. There's no way we could have done it so quickly with what we had before - a combination of our own colocated servers and VPS.
He couldn't be more dead-on regarding the Japanese. When I worked for a telecom vendor, we had a major project to adapt our software and hardware for NTT (Nippon Telephone & Telegraph.)
Two things I remember most:
*) The call we got about our 'defective' hardware. Turns out our own specifications called for 4 mounting screws to be included for a given circuit pack. We shipped 5. The call, after much cultural posturing, boiled down to "You mean you think our installers are imcompetent? You think so little of us?"
*) We had another circuit pack that had a severe overheating problem - when it hit this failure mode the heatsinks* would drop off into the bottom of the shelf. One of our executives told them "This is by design. It shortens the time to total failure, which reduces the overall fire risk." He was fired the next day.
[*the card had 3 DSPs, each with a heatsink that wasn't physically mounted, but stuck on with some kind of conductive glue.]
Ok, it allows third-party downloadable apps (their own app store?,) but "media-server functions have been omitted."
Can I pull media from my linux fileserver or not?
If the omitted functions just means it doesn't have local storage, then fine. I'm just hoping they don't cripple or disallow apps that can remotely fetch media.
If I could get that plus Netflix on a ~$100 box, I'd be all over it.
I had a professor in college, along with several colleagues and students, working on a formal proof for nuclear power plant control software. They had been been working for 5 years and, at the time, were about 10% complete.
Obviously, at that rate, the time to complete the formal proof is probably longer than the lifetime of the particular control system they were targeting.
Hopefully Formal Methods have come a long way since I last studied them 10 years ago. In any case, congratulations to this team of researchers at NICTA.
That's an interesting theory, except Bolden did not serve in the Air Force - he's a Marine.
The IMDB page lists him as 'rumored' as well.
You can't criticize what you don't know either.
You should take your own words to heart, my friend.
This gentlemen lacks the academic credentials, actual work experience in a nuts-and-bolts IT role, and the track record of success in such a role to be an effective leader in this appointment. Bachelor of Arts? Masters in Public Policy? Please.
The idea that managers in one field (ie healthcare) can be interchanged into another (ie IT) is a myth. It's a bush-league mistake and one that is very costly and damaging.
It has to be said, over, and over again: you can't manage what you don't know. The worst managers I've met in this industry were non-technical, woke up one morning and decided they were engineers, then went about destroying projects and teams. An absolute disaster.
Ahh - gotcha - thanks
I just recently read Dune for the first time. Did I miss something? Triumvirate? Space Guild / Bene Gesserit / Emperor? Still don't see the parallel with the federal executive branch (though it's early and caffeine levels are low)
You sure are inconsistent. One second you oppose "one-size-fits-all zealotry" and the next you claim that the best solution for the above example is C. Give me a break. You've said nothing meaningful about what the network service actually does, but you're sure that C is most likely the best choice.
I believe you may have missed my point with the examples. I presented three separate problem domains and recommended three separate languages that might be appropriate given the very high-level descriptions I provided [I didn't mean to imply C/Java/Perl were the only choices]. One point of the examples is to show that "one-size-fits-all" for all three, in their totality, is likely sub-optimal. This most certainly is consistent with my point.
There are a host of reasons why C makes a poor choice for any network service. The high rate of security problems caused by incompentent developers nears the top of that list. To ignore that and recommend C anyway demonstrates a lack of real-world experience or very poor judgement.
Other languages do not have incompetent programmers or are excluded from security problems? Who's lacking real-world experience and demonstrating poor judgement here?
I think programmer competency is a bit of a red-herring since it could effect any project, regardless of language or problem domain. My point remains: pick the right tool for the right job. As a corollary, picking the right people (ie competent) for the job is equally as important.
There's nothing that turns me off more than the one-size-fits-all zealotry that often comes from the Java camp. One size does not fit all. It never has, and it never will.
Programming languages are tools. Pick the appropriate tool for the specific job. More specifically, understand the capabilities and deficiencies of a wide range of languages and map those appropriately to the specific problem domain you've been asked to tackle.
Examples:
*) Production quality, single-user, cross-platform application: Java is at the top of my list.
*) Production quality network service with deterministic behavior under load and soft-to-firm response-time requirements: Hard to beat C w/ Linux here.
*) Quick and dirty lab-only tool to thrash through some test results: Yep, it's Perl.
Engineering is all about trade-offs. Understanding your problem and the tools you have to solve it with are critical. Making a poor choice, especially early on, can be disastrous. Even though I don't discount the performance enhancements Java has enjoyed over the years, I'd be very hard-pressed to select a virtual-machine based language/system for any performance critical application requiring a deterministic response.
Pounding a square peg into a round hole by insisting on one language for everything doesn't demonstrate a lot of design-maturity or sophistication on the part of those making such claims.
I've worked this into my interview questions for new hires as well and have found it to be a pretty good indicator of who I'm dealing with, experience-wise. (hint: the guy who insisted on smalltalk for everything did not get the job)
Linux supports the ability to change the scheduling policy to something other than the default egalitarian multiuser policy to two other policies (FIFO & Round Robin w/ preemption & priorities) which more closely resemble a real-time scheduler [which I think is what you are getting at].
> man sched_setscheduler
for more info.
"The metric system is the tool of the devil! My car gets forty rods to the hogshead and that's the way I likes it." Abe Simpson
The specs on the $319 Dell:
- Dell Dimension 2400N
- Intel(R) Celeron(R) Processor at 2.4GHz with 400MHz front side bus
- 128MB Shared DDR SDRAM at 333MHz
- FreeDOS(TM) included in the box, ready to install
- Dell(TM) Quietkey(R) Keyboard
- Dell(R) 2-Button Scroll Mouse
- 40GB ATA/100 Value Hard Drive
- No Floppy Drive Included
- No monitor
- Integrated Intel(R) 3D Extreme Graphics
- Integrated Audio
- No Speakers
- Integrated 10/100 Ethernet
- No Modem
- 1 Year Limited Warranty plus 1 Year On-site Service
Beef up the memory a little and you got yourself a nice home file server or project box.
1) The Indian contractors have excellent attitudes, are friendly, and want to do a good job. I still keep in touch with one guy who was here in the states for a few months - before he went back for his arranged marriage - picked out by his mom from a book.
2) They are excellent at following a set of predefined steps to solve a problem, but run in to real difficulty if the problem requires deviating from their memorized steps. My education professor friend tells me this has to do with how their education system works. Deviation from the presented method is discouraged.
3) The language and timezone differences are both killers. It's frustrating and unproductive for all parties involved.
My company is on its third attempt at outsourcing design work to India. The first two attempts failed and the managers responsible for the transition are no longer with the company. They had no idea what they were getting into, which is a shame, since they were both decent managers. The current attempt acknowledges the failures of the past and is to focus more narrowly on software areas we think they are capable of handling. The result of this exercise has been a long list of stable software that hasn't changed in years and rarely has a problem. This, of course, leaves everyone questioning 'why are we doing this again?'.
Yep, you get a segmentation fault and a nice core file with lots of good information like a stack trace, registers, globals, etc.
A quick example:
main()
{
unsigned char *com1_control_register = (unsigned char *)0x3fc;
*com1_control_register=0;
}