They aren' THAT esoteric! I remember playing a Cthulu mythos based game just recently called Anchorhead. It was absolutely brilliant until about the halfway mark, where there was a conversation that had to be done with a half-insane street bum, and you had to ask just the right questions to get the important answers to advance.
Now, of course, Google is your friend, but the problem is that once you have cracked on this type of game and gone to the walkthrough, it's extremely difficult to stop reading the walkthrough any time you run into a slightly difficult puzzle.
But Anchorhead was a very cool game up to that conversation, which was my point:-)
[sigh] No. Go and read the DCMA. Reverse engineering an encryption algorithm for the express purpose of interoperability is permitted. Yes, reverse engineering an encryption scheme that has been obfuscated to the best of the supplier's ability is a pain in the butt, but it can be (and is) done.
That's no more restrictive than the fact that my computer won't read VHS video cassettes. What!?! You mean that the evil corporations have stopped me from exercising my legal fair-use rights by nor providing compatiility between VHS cassettes and computers! The bastards! Every single one of them!
The state of affairs around 2000, where everything was going digital, but DRM was still in it's infancy, thus allowing massive intercompatibility between digital devices, wass an aberration, not the norm. I don't remember too many people complaining for example that they had to repurchase their video collection when they moved from VHS to DVD.
The fact that we are just returning to the status quo is the reason that the masses aren't complaining loudly. If you tell the average computer users that they can't use iTunes Music Store files on another device because the files aren't compatible, that person is going to see it as being exactly the same type of problem as not being able to play an LP in a cassette player. They consider this to be reasonable (if somewhat annoying).
Of course, this wonderfully balanced, well-researched and well-written article did overlook one rather important point: The whole supernode concept lets Skype get through nearly ANY router configuration imagineable. I beat my head against a brick wall for three months trying to convince my father's ADSL modem to let through voice comms for a SIP client. No go. The only way to get a VoIP solution through was to install Skype.
I can't help feeling that you have never actually tried XP, have you?
#1 If you need the spec before hand, it's not XP. XP only needs the spec for that which is to be delivered in the next build - ie in the next week. It does not need a spec for the whole shebang
#2 XP is about delivering new features ALL OF THE TIME. If you are just refactoring code without delivering new features, it isn't XP
#3 If you don't know if a particular technique is goping to work (like in your example with problems with chip data sheets), XP has a specific mecanism for dealing with the problem, called a spike. You bash out some throwaway code that does nothing but verifies that something (an API, a chip, a comms system, whatever) works the way that you need it to work
#4 Pair programming produces higher quality code that is easier to refactor when requirements change (as they will). Paying two programmers to produce higher quality code than that which would be produced by one programmer is always a good option. Not to mention that difficult problems that may block a single programmer can often be resolved by two programmers quite rapidly. I know from experience that sometimes it may take me a day to find the right abstraction, when having a second programmer next to me would have enabled us to find a solution in maybe a couple of hours.
Anyway, from what you have described, you have never actually worken under an XP paradigm. you should give it a try sometime. It's highly rewarding, and highly effective
I feel for you. I haven't yet found a good answer to the problem, but I have a few partial answers... And of course, the idea of running without tests just horrifies me these days. Anyway, here are are few things that I have found helped for the "changing test" dilemma
1) In my team we try to make any test-case specifiable in XML. We than write tools to convert the XML to the real binary data needed for the test cases. Making changes in a handful of XML files, or in the tool that does the conversion is relatively trivial compared to rewriting raw data by hand
2) The execution of the tool itself is handled by a script, so that all test cases are regenerated when the generation tool changes
3) Scripting languages are your friend. In the unhappy case where you have to change more than a handful of XML files to accomodate, a quick script in Perl, Ruby, Python, or whatever scripting language rings your bells, to make the changes automatically will generally be less painful than doing it by hand (and more fun). As a bonus, as you do this several times, you start to discover certain scripts that are very useful generally, that can be put together to generate another tool to manage the tests.
Anyway, that's how we handle changes to the requirements that demand a rebuilding of lots of test cases...
Has anyone found any other useful tricks to deal with this?
Sure, but I'm thinking about a ship using solid wingsails that just also happen to br covered with solar cells. Cover the deck as well, and you are starting to get a decent surface area to collect solar energy. And of course, with the masts producing their own thrust, the extra 2000hp that the solar cells generate is just a bonus. Whilst it's true that this technology is not yet at the point where it could replace diesel, it would certainly be capable of producing "research" ships, that could be improved upon to eventually produce commercial cargo ships.
What. Utter. Nonsense.
If you want to play a track purchased from the iTunes Store on another player than iTunes/iPod, all you need to do is burn a CD with the track on it. There. Done. Simple. Apple has guaranteed by this method that you have exactly the same rights when buying on iTunes as you do when buying a physical CD.
Sure, the quality of the burnt CD is slightly less than that of the bought CD. If you want to slag Apple for selling lower quality recordings, then go right ahead. If you want to slag them for restricting your rights, you are a)wrong, and b) a sheep following the anti-DRM crowd that isn't smart enough to think for yourself...
Generally speaking, if you are working for a company where your philosophical outlook doesn't match theirs, it is unlikely that you will be able to change their minds. The best thing to do would be to jump ship, and find a company that is more aligned with your ideas.
For example, in my company, a huge emphasis is put on everyone coding in the same style, at least for the code that is actually delivered in the product. Utility tools that are written to support the product (compilers/debuggers,test systems, etc) can be written pretty much any way you want, in any language that you want). But for the code in the product itself, everyone has to write in exactly the same way. You want to implement the Singleton pattern in C? Ahhh, there is only One True Way to do so in my company. Want to write an assert macro that also sticks out an informative message to trace at the same time? Sorry, that's not in accordance with the One True Way to do an assert, so no soup for you!
I drove myself, (and everyone around me) insane, trying to convince management that if you want to keep the best programmers, you can't expect them to accept having to code to someone else's idea of good code. It's just going to annoy them, and they'll look elsewhere for a job. It took me a while to realise that they were never come around to the philosophy of hiring good programmers that don't care about what style code has been written in, provided that it is clear (I mean, a competent programmer should not be phased when faced with any style that is relatively clear).
Finally, looking around, I noticed that none of the really good programmers at my company spent much time working on the actual product code. They were either writing tools, or moved into management as fast as possible, depending on whether they wanted to keep coding or not.
I followed suit. I am now working on a project where I am writing a virtual machine for the product, in C, and in accordance with the pathetic coding rules, but at the same time I'm writing a high level assembler and a debugger for generating code for the VM. These two tools are written in Ruby, and I'm really enjoying the work. Enough that the code rules that I have to obey when writing the VM have become only a minor annoyance, rather than a major pain in the neck every time I sit down at my desk.
Anyway, my point is that it's highly unlikely that you will succeed in changing your company's outlook on the importance of UI design. There's too many egos, and too much inertia involved. Either you have to redefine your job so that the standard rules don't apply, or you have to change your job....
To elaborate, drivers run inside the kernel (for the performance reasons cited by the parent post). They don't have all the nice protection that an OS can give in the application space.
Incidently, this is one of the reasons Macs are more secure. Apple is much more of a control-freak about stuff being installed in a Mac. You can expect that the drivers for buses, harddrives, networking gear and graphics cards has been gone over by Apple engineers (testing as well as code valuations). In the PC "open system" world this simply isn't possible, leaving PCs far more vulnerable to exploits...
If he had a hack that works against the standard OS X drivers/hardware, he would have used a standard Mac. The fact that he used a third-party wi-fi setup speaks volumes. This vulnerability does not exist in standard Apple gear - ergo there is nothing to patch.
If there has been any pressure from Apple, I'm willing to bet that it's libel-type threats (IANAL, and certainly not an Americain lawyer).
Considering that CrossOver is at best a less-than-reliable solution, I would have thought that a better solution would be to port PC apps to the Mac using WineLib. A bit like the easiest way to bring a Unix app to Windows is to compile it against the cygwin libs....
That way the bulk of the app works straight away (getting rid of the majority of porting work), and all that remains afterwards is correcting the nitty-gritty bugs that the WineLib doesn't handle quite correctly.
If more developers did this, we would very soon have a very complete WineLib, and the question of which platform you develop for would be null and void...
I think he was just saying that if you want to run Windows apps, they are generally happier if they run inside an entire Windows environment, rather than in a system which has a whole bunch of hacks for implementing things like control panels, and the registry etc etc.
I tend to agree
It's not the same situation. OS/2 ran Windows apps out of the box. For the Mac you still have to buy and install Windows. Note that Apple is NOT selling Windows.
The real risk is Wine. If Wine ever gets to a decent level of compatibility, it could cause significant problems of the "look at what happened to OS/2" type. But really, I'm not seeing it happen any time soon.
Too much eye candy???? You are kidding right? Apple go to huge pains so that ONLY what is needed is in the interface. Let's take the web browser as an example. They got rid of one of the standard toolbar buttons by combining the "Stop" and "Reload" buttons, because they realised that you never do these two things at the same time. Brilliant. I don't know why no-one else thought of it though...
So I'm kind of curious - what eye candy were you actually talking about specifically?
As others have noted already in this thread, profile-based searches don't work, they are too easy to game. On the other hand, random searches don't work either - large terrorist organisations such as Al-Qaida could simply play the odds that at least some of their operatives would get through. 100% searches aren't economically viable. So, what to do?
Bruce Scheier had some interesting stuff to say on this a few weeks backhttp://www.schneier.com/crypto-gram-0608.html. If you want to catch organised terrorists, the only answer is good counter-intelligence.
All those searches and what not aren't designed to stop well-trained terrorists, they're aimed at nutcases that think they can strike a blow for their favourite cause. These people are susceptible to profiling, which is why you get profiled when when going through airports these days....
"Unfortunatly the biggest reason for gender tension I have seen is the catch-22 many tech girls find themselves in of wanting to be polite to nice but clueless nerds and fending off advances. Often this can make girls feel like they are under seige and make spending time with their male colleagues feel like walking through a mine field. Most nerd girls just want to be one of the guys (figuratively) and not have to worry about akward advances."
Exactly! Or at least, that's the case for me...
"Then there's the question that *really* puzzles me. I always heard the story of how Apple makes most of its revenue off its hardware sales, and that sounded reasonable enough, then (for testing, my company does web-app development) we get an Apple and find out even point releases are sold seperately as upgrades. Is it just me or does that make it look like Micrsoft is really doing *me* a favor, namely by continuing to update and support their software platform until its end of life?"
Ummm, I wouldn't get too caught up about this idea of "point releases". Apple stopped incrementing the major version number at 10, because you can write 10 as 'X' in roman numerals, which is also a way of indicating that your OS is Unix-like (OS X, AIX, Linux, etc). As a result, major version releases now receive a "point release", eg 10.1 10.2 10.3. But the name changes each time, Cheetah, Panther, Tiger, Leopard etc, indicating that it is infact a major release. Point releases within a major release eg 10.4.6, 10.4.7, 10.4.8 etc are in fact free, as are point releases in the Windows world...
Couldn't agree more. I used it to give courses on configuration management when I was the engineer in charge of a radar site in the Royal Australian Air Force. It was the episode where they mod the computer, and everyone in the holodeck gets trapped by a psycopathic virus....
Ahhh, because it isn't easier to design a system that has tougher constraints? Or maybe you want to argue that for launch, weight isn't a major constraint? Or maybe you think that technology hasn't greatly reduced the weight of most major components involved in spaceflight.
Only a goose would believe any of the things above - I'm going to give you the benefit of the doubt and assume you are not a goose (awfully generous of me, considering your comment. That really only leaves one other point of opposition - you don't think that paperwork requirements slow down development. Well let's see what Chris Thomson, a vice president of SpaceX, one of the contractors that won seed funding from NASA this week, has to say on the subject:"They say they are commercial, but the truth is they are overregulated, overstaffed government programs. We definitely want to take all of their business."
In case you missed it, note the word "overregulated" in that sentence. Still not convinced? What about the CEO, Elon Musk? here are his thoughts, given to the Joint Committee hearings on commercial spaceflight:"It is also critical that such regulatory authorities recognize the early and experimental nature of the commercial launch vehicle industry, providing only the minimum regulatory burden necessary to ensure reasonable safety for the general public."
But hey, what would he know? He's only ponying up several hundred million dollars of his own money. Guy's obviously uneducated - I suggest you give him a call and put him on the right path...
Limit your criticisms to subjects that you actually know something about...
Yes, but with modern technology, the constraints are nowhere near as harsh. For example, it is no longer necessary that a 2 tonne computer be hoisted into orbit. The need for batteries is equally muh reduced thanks to far better performance from solar panels. Recycling technologies have greatly advanced, so the weight of consumables can also be greatly reduced. Stronger lightweight materials are available.
All of that means that for an equivalent mission payload, you probably no longer need a Saturn 5 to get the job done, meaning the rockets are also smaller. We also have a lot more experience designing rockets now, so that bit's going to be easier too.
Where it all comes unstuck is that these days NASA can't afford mistakes. When Apollo missions went pear-shaped (Apollo 1 anyone?) NASA shrugged and the work continued. IIRC the next launch was only a couple of months later. When they lost the last Shuttle, they grounded the fleet for 2 years.
The paperwork designed to prevent an Apollo 1 (or a Challenger) is why it takes so long/costs so much. Get rid of the paperwork, and it could be done in at worst half the time that it's actually going to take....
Two words: Extreme Programming
Honestly, at least that way the big boss can be dragged down every month or so, and shown something that works. And if the requirements change, it's not a problem either, you make the changes.
The real problem with this type of project (actually with just about any project) is that the client only has a vague idea of what he wants. You need to give him somthing concrete that he can criticise "I don't like having the title on every screen", or, "I need a way of copying this data from here to there". People are very good at identifying what doesn't work, but knowing what does work is hard - that's why you hire experts. They get you close on the first pass, and then refine based on criticisms....
Really, anyone running a big IT project that tries to run the project in any manner that is not based on some form of Agile development methodology is just destined to fail.
My microwave (LG Solardom) has lots of buttons and a dial, but I LOVE the interface. LG had the good idea of having icons light up to tell you what you were supposed to be pressing/turning next. As it's a combination microwave/convection oven with Halogen grill, you can do some pretty complicated things (and I do). Having this simpleto use yet powerful userface is a blessing. Everytime I use it I think to myself "this is the Mac of kitchen world":-)
Thought I'd just share that:-D
Slashdot Mirror
They aren' THAT esoteric! I remember playing a Cthulu mythos based game just recently called Anchorhead. It was absolutely brilliant until about the halfway mark, where there was a conversation that had to be done with a half-insane street bum, and you had to ask just the right questions to get the important answers to advance.
:-)
Now, of course, Google is your friend, but the problem is that once you have cracked on this type of game and gone to the walkthrough, it's extremely difficult to stop reading the walkthrough any time you run into a slightly difficult puzzle.
But Anchorhead was a very cool game up to that conversation, which was my point
[sigh]
No. Go and read the DCMA. Reverse engineering an encryption algorithm for the express purpose of interoperability is permitted. Yes, reverse engineering an encryption scheme that has been obfuscated to the best of the supplier's ability is a pain in the butt, but it can be (and is) done.
That's no more restrictive than the fact that my computer won't read VHS video cassettes. What!?! You mean that the evil corporations have stopped me from exercising my legal fair-use rights by nor providing compatiility between VHS cassettes and computers! The bastards! Every single one of them! The state of affairs around 2000, where everything was going digital, but DRM was still in it's infancy, thus allowing massive intercompatibility between digital devices, wass an aberration, not the norm. I don't remember too many people complaining for example that they had to repurchase their video collection when they moved from VHS to DVD. The fact that we are just returning to the status quo is the reason that the masses aren't complaining loudly. If you tell the average computer users that they can't use iTunes Music Store files on another device because the files aren't compatible, that person is going to see it as being exactly the same type of problem as not being able to play an LP in a cassette player. They consider this to be reasonable (if somewhat annoying).
Of course, this wonderfully balanced, well-researched and well-written article did overlook one rather important point: The whole supernode concept lets Skype get through nearly ANY router configuration imagineable. I beat my head against a brick wall for three months trying to convince my father's ADSL modem to let through voice comms for a SIP client. No go. The only way to get a VoIP solution through was to install Skype.
I can't help feeling that you have never actually tried XP, have you?
#1 If you need the spec before hand, it's not XP. XP only needs the spec for that which is to be delivered in the next build - ie in the next week. It does not need a spec for the whole shebang
#2 XP is about delivering new features ALL OF THE TIME. If you are just refactoring code without delivering new features, it isn't XP
#3 If you don't know if a particular technique is goping to work (like in your example with problems with chip data sheets), XP has a specific mecanism for dealing with the problem, called a spike. You bash out some throwaway code that does nothing but verifies that something (an API, a chip, a comms system, whatever) works the way that you need it to work
#4 Pair programming produces higher quality code that is easier to refactor when requirements change (as they will). Paying two programmers to produce higher quality code than that which would be produced by one programmer is always a good option. Not to mention that difficult problems that may block a single programmer can often be resolved by two programmers quite rapidly. I know from experience that sometimes it may take me a day to find the right abstraction, when having a second programmer next to me would have enabled us to find a solution in maybe a couple of hours.
Anyway, from what you have described, you have never actually worken under an XP paradigm. you should give it a try sometime. It's highly rewarding, and highly effective
I feel for you. I haven't yet found a good answer to the problem, but I have a few partial answers... And of course, the idea of running without tests just horrifies me these days. Anyway, here are are few things that I have found helped for the "changing test" dilemma
1) In my team we try to make any test-case specifiable in XML. We than write tools to convert the XML to the real binary data needed for the test cases. Making changes in a handful of XML files, or in the tool that does the conversion is relatively trivial compared to rewriting raw data by hand
2) The execution of the tool itself is handled by a script, so that all test cases are regenerated when the generation tool changes
3) Scripting languages are your friend. In the unhappy case where you have to change more than a handful of XML files to accomodate, a quick script in Perl, Ruby, Python, or whatever scripting language rings your bells, to make the changes automatically will generally be less painful than doing it by hand (and more fun). As a bonus, as you do this several times, you start to discover certain scripts that are very useful generally, that can be put together to generate another tool to manage the tests.
Anyway, that's how we handle changes to the requirements that demand a rebuilding of lots of test cases...
Has anyone found any other useful tricks to deal with this?
Sure, but I'm thinking about a ship using solid wingsails that just also happen to br covered with solar cells. Cover the deck as well, and you are starting to get a decent surface area to collect solar energy. And of course, with the masts producing their own thrust, the extra 2000hp that the solar cells generate is just a bonus. Whilst it's true that this technology is not yet at the point where it could replace diesel, it would certainly be capable of producing "research" ships, that could be improved upon to eventually produce commercial cargo ships.
Because it's incredibly rare to be becalmed on a cloudy day... The ideal technical solution would be to have sails and solar.
What. Utter. Nonsense. If you want to play a track purchased from the iTunes Store on another player than iTunes/iPod, all you need to do is burn a CD with the track on it. There. Done. Simple. Apple has guaranteed by this method that you have exactly the same rights when buying on iTunes as you do when buying a physical CD. Sure, the quality of the burnt CD is slightly less than that of the bought CD. If you want to slag Apple for selling lower quality recordings, then go right ahead. If you want to slag them for restricting your rights, you are a)wrong, and b) a sheep following the anti-DRM crowd that isn't smart enough to think for yourself...
Generally speaking, if you are working for a company where your philosophical outlook doesn't match theirs, it is unlikely that you will be able to change their minds. The best thing to do would be to jump ship, and find a company that is more aligned with your ideas. For example, in my company, a huge emphasis is put on everyone coding in the same style, at least for the code that is actually delivered in the product. Utility tools that are written to support the product (compilers/debuggers,test systems, etc) can be written pretty much any way you want, in any language that you want). But for the code in the product itself, everyone has to write in exactly the same way. You want to implement the Singleton pattern in C? Ahhh, there is only One True Way to do so in my company. Want to write an assert macro that also sticks out an informative message to trace at the same time? Sorry, that's not in accordance with the One True Way to do an assert, so no soup for you! I drove myself, (and everyone around me) insane, trying to convince management that if you want to keep the best programmers, you can't expect them to accept having to code to someone else's idea of good code. It's just going to annoy them, and they'll look elsewhere for a job. It took me a while to realise that they were never come around to the philosophy of hiring good programmers that don't care about what style code has been written in, provided that it is clear (I mean, a competent programmer should not be phased when faced with any style that is relatively clear). Finally, looking around, I noticed that none of the really good programmers at my company spent much time working on the actual product code. They were either writing tools, or moved into management as fast as possible, depending on whether they wanted to keep coding or not. I followed suit. I am now working on a project where I am writing a virtual machine for the product, in C, and in accordance with the pathetic coding rules, but at the same time I'm writing a high level assembler and a debugger for generating code for the VM. These two tools are written in Ruby, and I'm really enjoying the work. Enough that the code rules that I have to obey when writing the VM have become only a minor annoyance, rather than a major pain in the neck every time I sit down at my desk. Anyway, my point is that it's highly unlikely that you will succeed in changing your company's outlook on the importance of UI design. There's too many egos, and too much inertia involved. Either you have to redefine your job so that the standard rules don't apply, or you have to change your job....
To elaborate, drivers run inside the kernel (for the performance reasons cited by the parent post). They don't have all the nice protection that an OS can give in the application space. Incidently, this is one of the reasons Macs are more secure. Apple is much more of a control-freak about stuff being installed in a Mac. You can expect that the drivers for buses, harddrives, networking gear and graphics cards has been gone over by Apple engineers (testing as well as code valuations). In the PC "open system" world this simply isn't possible, leaving PCs far more vulnerable to exploits...
If he had a hack that works against the standard OS X drivers/hardware, he would have used a standard Mac. The fact that he used a third-party wi-fi setup speaks volumes. This vulnerability does not exist in standard Apple gear - ergo there is nothing to patch.
If there has been any pressure from Apple, I'm willing to bet that it's libel-type threats (IANAL, and certainly not an Americain lawyer).
Considering that CrossOver is at best a less-than-reliable solution, I would have thought that a better solution would be to port PC apps to the Mac using WineLib. A bit like the easiest way to bring a Unix app to Windows is to compile it against the cygwin libs....
That way the bulk of the app works straight away (getting rid of the majority of porting work), and all that remains afterwards is correcting the nitty-gritty bugs that the WineLib doesn't handle quite correctly.
If more developers did this, we would very soon have a very complete WineLib, and the question of which platform you develop for would be null and void...
I think he was just saying that if you want to run Windows apps, they are generally happier if they run inside an entire Windows environment, rather than in a system which has a whole bunch of hacks for implementing things like control panels, and the registry etc etc. I tend to agree
lol, I don't know, but I have been known to run cygwin in Virtual PC on my iMac G5 :-)
It's not the same situation. OS/2 ran Windows apps out of the box. For the Mac you still have to buy and install Windows. Note that Apple is NOT selling Windows. The real risk is Wine. If Wine ever gets to a decent level of compatibility, it could cause significant problems of the "look at what happened to OS/2" type. But really, I'm not seeing it happen any time soon.
Too much eye candy???? You are kidding right? Apple go to huge pains so that ONLY what is needed is in the interface. Let's take the web browser as an example. They got rid of one of the standard toolbar buttons by combining the "Stop" and "Reload" buttons, because they realised that you never do these two things at the same time. Brilliant. I don't know why no-one else thought of it though... So I'm kind of curious - what eye candy were you actually talking about specifically?
As others have noted already in this thread, profile-based searches don't work, they are too easy to game. On the other hand, random searches don't work either - large terrorist organisations such as Al-Qaida could simply play the odds that at least some of their operatives would get through. 100% searches aren't economically viable. So, what to do? Bruce Scheier had some interesting stuff to say on this a few weeks backhttp://www.schneier.com/crypto-gram-0608.html. If you want to catch organised terrorists, the only answer is good counter-intelligence.
All those searches and what not aren't designed to stop well-trained terrorists, they're aimed at nutcases that think they can strike a blow for their favourite cause. These people are susceptible to profiling, which is why you get profiled when when going through airports these days....
"Unfortunatly the biggest reason for gender tension I have seen is the catch-22 many tech girls find themselves in of wanting to be polite to nice but clueless nerds and fending off advances. Often this can make girls feel like they are under seige and make spending time with their male colleagues feel like walking through a mine field. Most nerd girls just want to be one of the guys (figuratively) and not have to worry about akward advances." Exactly! Or at least, that's the case for me...
"Then there's the question that *really* puzzles me. I always heard the story of how Apple makes most of its revenue off its hardware sales, and that sounded reasonable enough, then (for testing, my company does web-app development) we get an Apple and find out even point releases are sold seperately as upgrades. Is it just me or does that make it look like Micrsoft is really doing *me* a favor, namely by continuing to update and support their software platform until its end of life?" Ummm, I wouldn't get too caught up about this idea of "point releases". Apple stopped incrementing the major version number at 10, because you can write 10 as 'X' in roman numerals, which is also a way of indicating that your OS is Unix-like (OS X, AIX, Linux, etc). As a result, major version releases now receive a "point release", eg 10.1 10.2 10.3. But the name changes each time, Cheetah, Panther, Tiger, Leopard etc, indicating that it is infact a major release. Point releases within a major release eg 10.4.6, 10.4.7, 10.4.8 etc are in fact free, as are point releases in the Windows world...
Couldn't agree more. I used it to give courses on configuration management when I was the engineer in charge of a radar site in the Royal Australian Air Force. It was the episode where they mod the computer, and everyone in the holodeck gets trapped by a psycopathic virus....
Ahhh, because it isn't easier to design a system that has tougher constraints? Or maybe you want to argue that for launch, weight isn't a major constraint? Or maybe you think that technology hasn't greatly reduced the weight of most major components involved in spaceflight. Only a goose would believe any of the things above - I'm going to give you the benefit of the doubt and assume you are not a goose (awfully generous of me, considering your comment. That really only leaves one other point of opposition - you don't think that paperwork requirements slow down development. Well let's see what Chris Thomson, a vice president of SpaceX, one of the contractors that won seed funding from NASA this week, has to say on the subject:"They say they are commercial, but the truth is they are overregulated, overstaffed government programs. We definitely want to take all of their business." In case you missed it, note the word "overregulated" in that sentence. Still not convinced? What about the CEO, Elon Musk? here are his thoughts, given to the Joint Committee hearings on commercial spaceflight:"It is also critical that such regulatory authorities recognize the early and experimental nature of the commercial launch vehicle industry, providing only the minimum regulatory burden necessary to ensure reasonable safety for the general public." But hey, what would he know? He's only ponying up several hundred million dollars of his own money. Guy's obviously uneducated - I suggest you give him a call and put him on the right path... Limit your criticisms to subjects that you actually know something about...
Yes, but with modern technology, the constraints are nowhere near as harsh. For example, it is no longer necessary that a 2 tonne computer be hoisted into orbit. The need for batteries is equally muh reduced thanks to far better performance from solar panels. Recycling technologies have greatly advanced, so the weight of consumables can also be greatly reduced. Stronger lightweight materials are available. All of that means that for an equivalent mission payload, you probably no longer need a Saturn 5 to get the job done, meaning the rockets are also smaller. We also have a lot more experience designing rockets now, so that bit's going to be easier too. Where it all comes unstuck is that these days NASA can't afford mistakes. When Apollo missions went pear-shaped (Apollo 1 anyone?) NASA shrugged and the work continued. IIRC the next launch was only a couple of months later. When they lost the last Shuttle, they grounded the fleet for 2 years. The paperwork designed to prevent an Apollo 1 (or a Challenger) is why it takes so long/costs so much. Get rid of the paperwork, and it could be done in at worst half the time that it's actually going to take....
Two words: Extreme Programming Honestly, at least that way the big boss can be dragged down every month or so, and shown something that works. And if the requirements change, it's not a problem either, you make the changes. The real problem with this type of project (actually with just about any project) is that the client only has a vague idea of what he wants. You need to give him somthing concrete that he can criticise "I don't like having the title on every screen", or, "I need a way of copying this data from here to there". People are very good at identifying what doesn't work, but knowing what does work is hard - that's why you hire experts. They get you close on the first pass, and then refine based on criticisms.... Really, anyone running a big IT project that tries to run the project in any manner that is not based on some form of Agile development methodology is just destined to fail.
My microwave (LG Solardom) has lots of buttons and a dial, but I LOVE the interface. LG had the good idea of having icons light up to tell you what you were supposed to be pressing/turning next. As it's a combination microwave/convection oven with Halogen grill, you can do some pretty complicated things (and I do). Having this simpleto use yet powerful userface is a blessing. Everytime I use it I think to myself "this is the Mac of kitchen world" :-)
Thought I'd just share that :-D