"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."
So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
So you believe that the one control is roughly 1/3 the cost of the entire product? If we take away marketing, retail mark-up, etc, that could put a $180 part to at least 50% of the cost of the drier (which has a motor and drive parts, the rotating drum with bearings, 3 other controls, the external housing, assembly, shipping, etc, etc, etc.)
For the truck, the parts are probably environmentally qualified, so that makes them more costly than the stuff from Fry's.
But the cost for safety design and certification -are already paid for- in the product. There's no justification for trying to recoup engineering costs for subsequent repair parts.
There is carrying cost for repair parts. If the item cost $5 to make, I don't expect to buy it for $5, due to inventory costs, transportation costs, etc.
So no, I don't accept that the cost of either of these two items is at all reasonable, even factoring in safety and environmental qualifications. (I've worked on safety-critical and embedded vehicle projects, as well as inventory control systems where we had to calculate carrying costs as part of the 'reorder point' calculation, so I claim some specific domain experience.)
With respect to Apple, they have set a specific market. If that's not your market, OK, go elsewhere.
"To Engineer Is Human: The Role of Failure in Successful Design" by Henry Petrosky http://www.amazon.com/Engineer... We learn much more from failure.
"The Design of Design, Essays from a Computer Scientist" by Frederick Brooks http://www.amazon.com/Design-E... This isn't as well known or quite as easy to read as "Mythical Man-Month."
Both of these books should take you outside of 'pure coding' into thinking about the systems the code is part of, and how those systems interact with humans and with other systems.
Last year (2014), I had to download Adobe Acrobat to submit a form to the US Treasury dept. The only way you could do this was Acrobat, it used PDF and Adobe proprietary form submission. (I couldn't use Apple Preview.app to fill out the form.)
This year (2015), Treasury added the obvious alternative, a fully on-line Web form. I guess that's progress.
I would expect the San Bernardino case to be a 'full trial' investigation, so any subsequent prosecutions from evidence obtained from this phone would be subject to criminal law procedures.
But would the Cellebrite methods be subject to Discovery by the defendant's attorneys?
Both the chain-of-evidence issue (establishing and maintaining the environment) and the discovery issue were raised by Apple in its opposition, pointing out that a 'cracking facility' had substantial costs associated with it.
But (a) I don't have a Linux box. Part of the discussion here is the ubiquity of Emacs, so a good quality Emacs that fits well in Mac OS X is relevant. I'd expect Emacs to be part of any (reasonable) Linux distribution, (b) which windowing environment would be running on my Linux box if I had one? (c) when I actively cranked out code for a living on Sun workstations, the only reason I ran the window manager was to get screen acceleration for my terminal windows, one of which ran old-fashioned Emacs. (the second was the command line shell for running the compiler, and the third ran Rogue/NetHack, to give me something to do while compiling:-) )
NO! I should have mentioned that. THE ONLY WAY to file this form ("substantial penalties for failure to file" and they will go after you because of money-laundering initiatives) is through Adobe Acrobat!!
Treasury Dept requires the use of Adobe Acrobat to fill out and submit the 'foreign bank account' form (I have to report every year on my Canadian RRSP - 401k equivalent- since it's more than $10k.)
You would think the obvious way to do this is with a (secure) website. But no, that's not how Treasury does it. Instead, they have to have some back-end that extracts information from the specially crafted PDF that can only be submitted through Acrobat Reader (you can't just email or upload the filled-out PDF form.)
So every year I install Acrobat, fill out the form, and then uninstall Acrobat Reader (letting Mac OS X Preview.app handle all other PDF duties.)
Frankly, I've never been much of a fan of IDEs. My biggest project used Rational Apex, which was a full up IDE (long before Eclipse, etc.) The most productive programmers on that project, though, used a text editor (Emacs or VI) and ran the compiler from the command line. No point wasting cycles on fancy GUIs that mostly got in the way. The only time I cranked up the Rational IDE was to run the debugger, and any time I had to run a debugger, it was a direct admission that I had -no clue- what my code (or someone else's code) was doing, and I considered that a personal defeat.
Usually, I had an Emacs session, a command line session, and a terminal session running rogue (for something to do while the compiler/linker was running, I could usually knock off a level or two.)
When I was doing Real Work writing software, I developed the classic Emacs 'carpal tunnel' in the left hand from stretching the pinkie too much for moderator keys. A couple other people I know who are dyed-in-the-wool Emacs users have also developed that.
Yes, I can. Emacs run from the terminal is the classic Emacs experience. Aquamacs has a lot tighter integration with Mac OS X including better handling of both frames and windows.
I think the SDOs (ISO, ANSI, IEEE, etc) made a fundamental mistake when they decided to accept patented technologies as part of formal (de jure) standards.
If I were King, the FRAND license cost for any patent that appears in a de jure standard would be $0. If the patent-holder won't give up the rights, then the technology should not appear in a standard. Now that clearly would restrict what can be standardized, but that's a tradeoff that both society and patent holders should accept.
(And technology R&D funded by governments should be royalty/license free. DoD certainly used to do that, and look at the advantages -commercial companies- have gotten from the fact that the basic Internet protocols are royalty free/not patented.)
I think that's a fair summary. The Military got into a huge case of "commercial industry is better" (despite evidence to the contrary for large software intensive systems.) The Ada compiler vendors charged high prices to their captive market, discouraging commercial use with the bar to entry being too high. C, on the other hand, had $99 PC compilers (or cheaper) and it was easier to learn the basics (but it takes at least as much time to become competent in C as in Ada, particularly when you take into account learning all the idioms and conventions on the one hand, and the things to -not do- on the other hand.)
There has been (and still is) pockets of Ada usage in transportation (air traffic control, avionics, train control) where the safety of large software systems is a driving consideration. The primary viable Ada compiler is open source, see http://www.adacore.com/
Availability of Ada programmers is not the issue (although it's often used as an excuse.) My back-of-the-envelope calculation is there are at least 100k people in the US with Ada training. The problem is that most of them are making much more money doing C (in part because Ada provided a good foundation for reasoning about software systems, making them better-than-average C programmers.) Case-in-point: My friend who was making $100+/hr doing C, and never got an offer for more than about $55/hr for Ada. That being said, he often does prototyping in Ada, and then if necessary recodes the application into C or Java.
DoD got in many respects what it wanted, a 'universal language' with low entry cost, lots of cheap programmers, and commercial tools, from C. Unfortunately, they also got the 'throw low cost bodies at it' culture that produces so much crappy software.
Slashdot Mirror
One of the great parody ads: http://www.funnyfakeads.com/pi...
And the background for it: https://en.wikipedia.org/wiki/...
"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."
So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
So you believe that the one control is roughly 1/3 the cost of the entire product? If we take away marketing, retail mark-up, etc, that could put a $180 part to at least 50% of the cost of the drier (which has a motor and drive parts, the rotating drum with bearings, 3 other controls, the external housing, assembly, shipping, etc, etc, etc.)
For the truck, the parts are probably environmentally qualified, so that makes them more costly than the stuff from Fry's.
But the cost for safety design and certification -are already paid for- in the product. There's no justification for trying to recoup engineering costs for subsequent repair parts.
There is carrying cost for repair parts. If the item cost $5 to make, I don't expect to buy it for $5, due to inventory costs, transportation costs, etc.
So no, I don't accept that the cost of either of these two items is at all reasonable, even factoring in safety and environmental qualifications. (I've worked on safety-critical and embedded vehicle projects, as well as inventory control systems where we had to calculate carrying costs as part of the 'reorder point' calculation, so I claim some specific domain experience.)
With respect to Apple, they have set a specific market. If that's not your market, OK, go elsewhere.
The mechanical timer broke on my (gas) drier. The part cost $180, for a drier that probably cost $500-$600.
The cost for the ABS (computer) module on my 2000 Nissan Frontier was $1.8k.
Will we legislate 'reasonable prices' for repair parts? And who determines 'reasonable'? (Same argument goes for other aspects of 'repairability'.)
"To Engineer Is Human: The Role of Failure in Successful Design" by Henry Petrosky http://www.amazon.com/Engineer...
We learn much more from failure.
"The Design of Design, Essays from a Computer Scientist" by Frederick Brooks http://www.amazon.com/Design-E...
This isn't as well known or quite as easy to read as "Mythical Man-Month."
Both of these books should take you outside of 'pure coding' into thinking about the systems the code is part of, and how those systems interact with humans and with other systems.
And then what? You cannot snail-mail the file. It had to be electronically submitted.
The problem with that was there is no mechanism to -submit- the resulting PDF except through Adobe Acrobat. That's the real flaw!
(And if that did work, one could just grab the form via screen capture.)
Last year (2014), I had to download Adobe Acrobat to submit a form to the US Treasury dept. The only way you could do this was Acrobat, it used PDF and Adobe proprietary form submission. (I couldn't use Apple Preview.app to fill out the form.)
This year (2015), Treasury added the obvious alternative, a fully on-line Web form. I guess that's progress.
http://www.cnbc.com/2016/04/24...
Jeans and black shirt. But then, how many industries exist based on copying Apple's design chops?
But the discussion of "DLLs" does provide a hint.
Why not, CERT? Don't you think this is relevant?
I would expect the San Bernardino case to be a 'full trial' investigation, so any subsequent prosecutions from evidence obtained from this phone would be subject to criminal law procedures.
But would the Cellebrite methods be subject to Discovery by the defendant's attorneys?
Both the chain-of-evidence issue (establishing and maintaining the environment) and the discovery issue were raised by Apple in its opposition, pointing out that a 'cracking facility' had substantial costs associated with it.
You can read about it here: https://www.irs.gov/Businesses...
Fair enough...
But (a) I don't have a Linux box. Part of the discussion here is the ubiquity of Emacs, so a good quality Emacs that fits well in Mac OS X is relevant. I'd expect Emacs to be part of any (reasonable) Linux distribution, (b) which windowing environment would be running on my Linux box if I had one? (c) when I actively cranked out code for a living on Sun workstations, the only reason I ran the window manager was to get screen acceleration for my terminal windows, one of which ran old-fashioned Emacs. (the second was the command line shell for running the compiler, and the third ran Rogue/NetHack, to give me something to do while compiling :-) )
NO! I should have mentioned that. THE ONLY WAY to file this form ("substantial penalties for failure to file" and they will go after you because of money-laundering initiatives) is through Adobe Acrobat!!
Treasury Dept requires the use of Adobe Acrobat to fill out and submit the 'foreign bank account' form (I have to report every year on my Canadian RRSP - 401k equivalent- since it's more than $10k.)
You would think the obvious way to do this is with a (secure) website. But no, that's not how Treasury does it. Instead, they have to have some back-end that extracts information from the specially crafted PDF that can only be submitted through Acrobat Reader (you can't just email or upload the filled-out PDF form.)
So every year I install Acrobat, fill out the form, and then uninstall Acrobat Reader (letting Mac OS X Preview.app handle all other PDF duties.)
Frankly, I've never been much of a fan of IDEs. My biggest project used Rational Apex, which was a full up IDE (long before Eclipse, etc.) The most productive programmers on that project, though, used a text editor (Emacs or VI) and ran the compiler from the command line. No point wasting cycles on fancy GUIs that mostly got in the way. The only time I cranked up the Rational IDE was to run the debugger, and any time I had to run a debugger, it was a direct admission that I had -no clue- what my code (or someone else's code) was doing, and I considered that a personal defeat.
Usually, I had an Emacs session, a command line session, and a terminal session running rogue (for something to do while the compiler/linker was running, I could usually knock off a level or two.)
Too late! I've already posted and disqualified myself.
When I was doing Real Work writing software, I developed the classic Emacs 'carpal tunnel' in the left hand from stretching the pinkie too much for moderator keys. A couple other people I know who are dyed-in-the-wool Emacs users have also developed that.
What other software produces its own injury? ;-)
Yes, I can. Emacs run from the terminal is the classic Emacs experience. Aquamacs has a lot tighter integration with Mac OS X including better handling of both frames and windows.
Mod parent up, this is my experience, too. (And I love Aquamacs on my Mac.)
Why is it I don't have moderator points when I really want them?
Well, I've worked on several IEEE and ISO standards projects in software, so I do have experience with the processes.
Standards activities might well be the way you describe, but those I've worked on are not.
I think the SDOs (ISO, ANSI, IEEE, etc) made a fundamental mistake when they decided to accept patented technologies as part of formal (de jure) standards.
If I were King, the FRAND license cost for any patent that appears in a de jure standard would be $0. If the patent-holder won't give up the rights, then the technology should not appear in a standard. Now that clearly would restrict what can be standardized, but that's a tradeoff that both society and patent holders should accept.
(And technology R&D funded by governments should be royalty/license free. DoD certainly used to do that, and look at the advantages -commercial companies- have gotten from the fact that the basic Internet protocols are royalty free/not patented.)
I think that's a fair summary. The Military got into a huge case of "commercial industry is better" (despite evidence to the contrary for large software intensive systems.) The Ada compiler vendors charged high prices to their captive market, discouraging commercial use with the bar to entry being too high. C, on the other hand, had $99 PC compilers (or cheaper) and it was easier to learn the basics (but it takes at least as much time to become competent in C as in Ada, particularly when you take into account learning all the idioms and conventions on the one hand, and the things to -not do- on the other hand.)
There has been (and still is) pockets of Ada usage in transportation (air traffic control, avionics, train control) where the safety of large software systems is a driving consideration. The primary viable Ada compiler is open source, see http://www.adacore.com/
Availability of Ada programmers is not the issue (although it's often used as an excuse.) My back-of-the-envelope calculation is there are at least 100k people in the US with Ada training. The problem is that most of them are making much more money doing C (in part because Ada provided a good foundation for reasoning about software systems, making them better-than-average C programmers.) Case-in-point: My friend who was making $100+/hr doing C, and never got an offer for more than about $55/hr for Ada. That being said, he often does prototyping in Ada, and then if necessary recodes the application into C or Java.
DoD got in many respects what it wanted, a 'universal language' with low entry cost, lots of cheap programmers, and commercial tools, from C. Unfortunately, they also got the 'throw low cost bodies at it' culture that produces so much crappy software.