I am currently in the process of doing exactly what you describe and can attest to the intense level of stress that it brings. There is always stress at work, but for where I am entering I find it to be much greater. Previously I concerned myself with doing a good job to a) keep my job and b) keep the company happy. Now I concern myself with these same tasks, however c) I feel a greater level of risk now that I am making and am responsible for the tactical decisions and d) as I try to delegate more it becomes my burden to make difficult decisions when employees can't perform.
I consider myself lucky that my boss is intentionally working on a gradual transition for this so as to minimize shock to both myself and the organization.
The iPhone 5C was released in 2013, which is plenty of time for Apple engineers to learn from their mistakes. From what I understand, the newer iPhones have better hardware encryption which prevent many types of attacks. This implies that there were security gaps identified later, and these have been designed out in later models.
Somehow I doubt that the temperature inside of your pants pocket is 85 deg C (queue joke). You need MLC flash for any reasonable amount of video storage capacity. MLC flash does not hold up well to high temperatures within the normal industrial operating range let alone from a data recovery standpoint in case of fuel fire (800 deg C or so?), even with insulation.
I could see it being difficult to justify the costs if you can't provide a reasonable guarantee that the data could be recovered in the event of an incident.
I work for a railway black-box manufacturer and we have had government authorities travel thousands of miles with the recovered memory device in their hands to personally deliver it to our office for data recovery. Chain of custody is an issue after incidents, which becomes more difficult to guarantee with wireless transmissions.
There could also be legal issues and lawsuits if the streamed data didn't match the data recovered from the onboard recorders. That being said, real-time data could help search and rescue. Even if not admissible or thrown out of court there are obvious humanitarian benefits to that.
think about it. 10 small(or just light, space isn't an issue so much as weight) boxes that save the stream, have the memory on robust enough media(flash). the boxes would need to weight a kilo each to be quite robust.
Crash-protected enclosures will save the memory from impact and shock but it's a bit trickier to protect it from the ensuing fuel fire. The volume of data required to protect video in this manner makes that difficult to achieve. Controls and system feedback is much easier to manage from a memory-consumption standpoint.
I have dual output formats. One is a binary image (.bin) that is loaded via custom PC software to a custom bootloader (glorified flash programmer) running on the target. This is the same.bin as we deliver to the customer. The other is a ELF file (default IAR EWARM.elf output I think) which I believe is what is used by the JTAG. I believe the.bin is auto-generated after link-time from the.elf; I had to set an option for this. The.bin is then further post-processed to add some special data such as CRC at well-defined locations.
Generally I try to load the.bin with our PC tools (the "normal" update path) and then debug with JTAG from that rather than auto program/load/execute the.elf. If I'm lazy I program directly with the JTAG.
I don't know the MSP430 at all and couldn't comment on how our ARM approach differs from it, or if there are any other funny technical gothcas involved. If it's of any interest, we are using TI's Luminary Micro ARMs.
It's also illegal to go around and kill people with a gun. Still happens. You can't protect people by taking away rights. Criminals are going to commit crimes.
Ah, the "laws just get broken, so lets not have laws" defense!
That's not what he said at all. There already are laws. He's talking about a shift from permissive to restrictive.
Speaking as a Canadian with completely different firearm laws, if I am bringing a pistol to the range and get pulled over and found to have forgotten any of several pieces of paper the police can ransack my house, confiscate everything, and either put me in prison or bankrupt me in a legal battle. All that because of a relatively small handful of thugs in the large population centers such as Toronto and one maniac who went on a shooting spree 25 years ago.
So yes, one should very much oppose introduction of hollow laws which will have no effect other than to criminalize innocent people.
I once interviewed someone with "proficient in C" on their resume. To them I handed a piece of paper with a single function on it that was a very simple string copy called myfunc(). The questions were:
What does this function do? Copies a string
What is a better name for this function? Anything else with "copy" in it, really
What in this function could go wrong? Buffer overflow
These are trivial questions for anyone who has done any real work in C, and it weeds out the liars if they can't answer any of the questions even with liberal leading.
One could also argue that the amount of time it took to retrain the replacement such that they actually are a replacement could be roughly equivalent to the fired employee getting a grip on his situation. Both your and the GGGP's arguments are valid but at the same time completely irrelevant without knowledge of the timeframes involved.
Furthermore, what does "not pulling his weight" even mean? That superficially it appeared he wasn't doing work because he had to go to court a lot, but no one noticed him coming in early or in the evenings to make up for it? Or that he actually sat there and stared at a monitor all day weeping into his coffee?
I speak as someone who is at this time watching a close friend go through a very similar situation while at the same time having trouble myself. His employer is squaking about him taking too much time off for court, however he always makes up for it that same week or week end. In my experience it's not the work life that is affected, since that is an escape, at least after the initial wounds have healed and some flexibility is provided. It's the home life where the problems lie. I would certainly hope any employer would give a grace period for said initial wounds and be understanding to some degree of court requirements so long as time is made up...
The problem is that GCC will always give you a different binary every time you compile from the same source. This makes it impossible that the binary you received comes from the source you claim to have used.
This is not true.
Where I work I generate embedded firmware using GCC. When the code is ready, QA is provided a tag of the sources and CRCs I generate from my build, and then they build the source code and verify their CRCs against mine to ensure they can build and release what I intended. These CRCs are then published along with the binary when released to the customer, who has the ability to pull the code and build tools from escrow in case we go bankrupt. They know they can built the code 100% identical to what we provided them.
Where you may get into trouble is using macros like __DATE__ and __TIME__. One solution is to run a binary diff against the two executables and manually verify that only this changed. The other is of course to just not use them.
The initial problem with these I have found is that you can end up with e.g. COM12 after plugging in the adapter. The fiddling you have mentioned then becomes necessary. The more insidious problem I have seen is when the COM port number mapping changes, since it's really not a "fixed" port. Now you foist the task of fiddling on to the guy in the field, who may in no way be qualified (rightly so) to do such a task.
As an example, the FTDI drivers by default key the port number on the USB device's serial number. Plug in a different adapter, you get COMn+1. As luck would have it, FTDI does provide a registry setting to adjust this behaviour but you need to know it's there first.
Even worse regarding fiddling is if your application does fancy things with Windows overtop of the COM port. For example, running a null model Internet dialler (ppp). God help the poor soul who needs to fiddle with that mess while the customer is breathing down your neck. What we did was add in to our application some C/Win32 code to allow "reconfiguration" of the ppp dialler in the event the COM port mapping changes. We found that to be a poorly documented black art API that would sometimes require a reboot, sometimes not.
Regarding paths forward to deal with the general problem of RS-232 obsolecense in consumer laptops I see no adequate alternatives. Ethernet/TCP? Lack of a standardized IP addressing configuration makes it too cumbersome to field personnel since all vendors will implement their interfaces differently. USB? See the preceeding paragraphs. Couple that with the fact that the complexity of the protocols and software required to implement communication via TCP and USB are ridiculous to that of RS-232, there is no reasonable solution that I have seen yet. In an embedded system, UART (RS-232/422/485) core I/O routines can be written in one or two dozen lines of code. Lines of code for TCP/IP and USB stacks easily number in the thousands, and may also require a multitasking OS for certain API requirements. Because of this, UART interfaces aren't going away any time soon.
Considering my past experience as a seventeen-year-old, I was a bad driver because I acted like a seventeen-year-old, not because I was new to driving.
I got my Ontario G1 (learners permit) when I was 16 years old. I drove with my parents in my high school parking lot a few times but never really got into it because my bicycle or public transportation could get me everywhere I wanted to be and cost me next to nothing. This license ended up expiring after 5 years, and I had to get it again because it was easier for ID than going through the hoops for an "age of majority card" so I could continue buying beer (age is 19 in Ontario). Three years after that - 24 years old, and now 8 years after I first got my learners - I finally learned to drive and upgraded my license through the required road test to being able to drive alone/unsupervised since this was a prerequisite for the girl I was after at the time. I've been driving ever since.
I don't know what it's like to be 17 and driving, but I have always felt like I skipped the insanity period. As much as I despise the insurance companies, I can fully understand why they charge more for younger drivers age-wise.
My personal favourite, that seemed to rise and fall in popularity around here last year or the year before, is wearing a hood while driving. I'm not sure about most other people, but I for one don't turn MY ENTIRE UPPER BODY to look over my shoulder, like those guys must have to.
Often programmers are somewhat trapped in the office while the marketing and management get to travel and wine and dine clients. Thus throwing them some bones such as food and conference travel balances out the equation.
This.
I am in a relatively unique position that some software testing and occasionally actual bug fixes as a result of said testing cannot be done anywhere other than on customer property. In my case, this is railway cars/yards across North America. Accordingly, most of these locations are in major cities due to them being transportation hubs. Very infrequently Japan and Germany come up. While not the same as a vacation with the family, these trips are worth more to me than what the company ends up paying. Bonus when I can actually manage to bring the family.
In a similar vein, I think every programmer should have some direct exposure to the customer. A five minute off-the-cuff conversation with them during a break in a meeting is solid gold compared to being hidden specifications and poorly translated information from managers / meeting minutes.
Along with the company houses came the company store — one in each community, stocked with everything that the miner or his family would ever need. These were quality goods, but they came with a high price; everything could be charged on credit against the miner's pay envelope, and few families escaped being in perpetual economic bondage. Over time, company stores in Nova Scotia's coal-mining towns became symbols of corporate oppression and in times of labour unrest were the objects of looting and violence.
Yes absolutely, depending on the type of software you write. I've seen cases where someone removed an unused variable from the stack in a C function which, because of the change in stack sizing, caused a previously unknown buffer overrun to now corrupt a different, used variable. All sorts of hilarity ensued when this caused a problem in release builds only and not debug builds, which of course the developer was using exclusively.
If you make such a change to the braking system in my car, you're damn right I want that entire code base retested. If it's a change to some simple financial software, I still want some modicum of retest so I don't get embarassed by breaking a previously working program to my customers, but might forego the entire week-long test.
No offense intended, but you sound like a number of college co-op students I've been charged with in the past. People new to the neighborhood trying to prove something with all of the great new tech they've been learning in school or on their own time. Certainly that is not inherently a bad thing, but often they don't understand the big picture particularly with regards to existing documentation, library dependencies / escrow environments, and test / V&V efforts.
made the code more elegant (refactoring)
As a general rule, I kill this in the cradle. A noble cause, but rife with risk and not worth it unless certain new requirements can justify such a change.
Slashdot Mirror
All the world for a mod point!
I am currently in the process of doing exactly what you describe and can attest to the intense level of stress that it brings. There is always stress at work, but for where I am entering I find it to be much greater. Previously I concerned myself with doing a good job to a) keep my job and b) keep the company happy. Now I concern myself with these same tasks, however c) I feel a greater level of risk now that I am making and am responsible for the tactical decisions and d) as I try to delegate more it becomes my burden to make difficult decisions when employees can't perform.
I consider myself lucky that my boss is intentionally working on a gradual transition for this so as to minimize shock to both myself and the organization.
The iPhone 5C was released in 2013, which is plenty of time for Apple engineers to learn from their mistakes. From what I understand, the newer iPhones have better hardware encryption which prevent many types of attacks. This implies that there were security gaps identified later, and these have been designed out in later models.
Somehow I doubt that the temperature inside of your pants pocket is 85 deg C (queue joke). You need MLC flash for any reasonable amount of video storage capacity. MLC flash does not hold up well to high temperatures within the normal industrial operating range let alone from a data recovery standpoint in case of fuel fire (800 deg C or so?), even with insulation.
I could see it being difficult to justify the costs if you can't provide a reasonable guarantee that the data could be recovered in the event of an incident.
I work for a railway black-box manufacturer and we have had government authorities travel thousands of miles with the recovered memory device in their hands to personally deliver it to our office for data recovery. Chain of custody is an issue after incidents, which becomes more difficult to guarantee with wireless transmissions.
There could also be legal issues and lawsuits if the streamed data didn't match the data recovered from the onboard recorders. That being said, real-time data could help search and rescue. Even if not admissible or thrown out of court there are obvious humanitarian benefits to that.
think about it. 10 small(or just light, space isn't an issue so much as weight) boxes that save the stream, have the memory on robust enough media(flash). the boxes would need to weight a kilo each to be quite robust.
Crash-protected enclosures will save the memory from impact and shock but it's a bit trickier to protect it from the ensuing fuel fire. The volume of data required to protect video in this manner makes that difficult to achieve. Controls and system feedback is much easier to manage from a memory-consumption standpoint.
Why would the government pay for work which is out of spec?
What government would admit their project failed?
...before "FUCK! FINALLY!" were out of my mouth. Good luck to my American friends.
I would mod this AC up if only I had the points.
I have dual output formats. One is a binary image (.bin) that is loaded via custom PC software to a custom bootloader (glorified flash programmer) running on the target. This is the same .bin as we deliver to the customer. The other is a ELF file (default IAR EWARM .elf output I think) which I believe is what is used by the JTAG. I believe the .bin is auto-generated after link-time from the .elf; I had to set an option for this. The .bin is then further post-processed to add some special data such as CRC at well-defined locations.
Generally I try to load the .bin with our PC tools (the "normal" update path) and then debug with JTAG from that rather than auto program/load/execute the .elf. If I'm lazy I program directly with the JTAG.
I don't know the MSP430 at all and couldn't comment on how our ARM approach differs from it, or if there are any other funny technical gothcas involved. If it's of any interest, we are using TI's Luminary Micro ARMs.
It's also illegal to go around and kill people with a gun. Still happens. You can't protect people by taking away rights. Criminals are going to commit crimes.
Ah, the "laws just get broken, so lets not have laws" defense!
That's not what he said at all. There already are laws. He's talking about a shift from permissive to restrictive.
Speaking as a Canadian with completely different firearm laws, if I am bringing a pistol to the range and get pulled over and found to have forgotten any of several pieces of paper the police can ransack my house, confiscate everything, and either put me in prison or bankrupt me in a legal battle. All that because of a relatively small handful of thugs in the large population centers such as Toronto and one maniac who went on a shooting spree 25 years ago.
So yes, one should very much oppose introduction of hollow laws which will have no effect other than to criminalize innocent people.
Indeed
I once interviewed someone with "proficient in C" on their resume. To them I handed a piece of paper with a single function on it that was a very simple string copy called myfunc(). The questions were:
What does this function do? Copies a string
What is a better name for this function? Anything else with "copy" in it, really
What in this function could go wrong? Buffer overflow
These are trivial questions for anyone who has done any real work in C, and it weeds out the liars if they can't answer any of the questions even with liberal leading.
One could also argue that the amount of time it took to retrain the replacement such that they actually are a replacement could be roughly equivalent to the fired employee getting a grip on his situation. Both your and the GGGP's arguments are valid but at the same time completely irrelevant without knowledge of the timeframes involved.
Furthermore, what does "not pulling his weight" even mean? That superficially it appeared he wasn't doing work because he had to go to court a lot, but no one noticed him coming in early or in the evenings to make up for it? Or that he actually sat there and stared at a monitor all day weeping into his coffee?
I speak as someone who is at this time watching a close friend go through a very similar situation while at the same time having trouble myself. His employer is squaking about him taking too much time off for court, however he always makes up for it that same week or week end. In my experience it's not the work life that is affected, since that is an escape, at least after the initial wounds have healed and some flexibility is provided. It's the home life where the problems lie. I would certainly hope any employer would give a grace period for said initial wounds and be understanding to some degree of court requirements so long as time is made up...
With what (trusted) compiler?
This is curious. I use IAR EW for ARM and do not have any problems doing build verification checksums.
This is a silly idea for open source software, the only industry I've seen apply it is perhaps the least-open one in the world.
This requirement also exists in the rail transit industry.
You may be interested in this article. We have had mixed success with it.
The problem is that GCC will always give you a different binary every time you compile from the same source. This makes it impossible that the binary you received comes from the source you claim to have used.
This is not true.
Where I work I generate embedded firmware using GCC. When the code is ready, QA is provided a tag of the sources and CRCs I generate from my build, and then they build the source code and verify their CRCs against mine to ensure they can build and release what I intended. These CRCs are then published along with the binary when released to the customer, who has the ability to pull the code and build tools from escrow in case we go bankrupt. They know they can built the code 100% identical to what we provided them.
Where you may get into trouble is using macros like __DATE__ and __TIME__. One solution is to run a binary diff against the two executables and manually verify that only this changed. The other is of course to just not use them.
We were there first anyway...
No, you were not.
The initial problem with these I have found is that you can end up with e.g. COM12 after plugging in the adapter. The fiddling you have mentioned then becomes necessary. The more insidious problem I have seen is when the COM port number mapping changes, since it's really not a "fixed" port. Now you foist the task of fiddling on to the guy in the field, who may in no way be qualified (rightly so) to do such a task.
As an example, the FTDI drivers by default key the port number on the USB device's serial number. Plug in a different adapter, you get COMn+1. As luck would have it, FTDI does provide a registry setting to adjust this behaviour but you need to know it's there first.
Even worse regarding fiddling is if your application does fancy things with Windows overtop of the COM port. For example, running a null model Internet dialler (ppp). God help the poor soul who needs to fiddle with that mess while the customer is breathing down your neck. What we did was add in to our application some C/Win32 code to allow "reconfiguration" of the ppp dialler in the event the COM port mapping changes. We found that to be a poorly documented black art API that would sometimes require a reboot, sometimes not.
Regarding paths forward to deal with the general problem of RS-232 obsolecense in consumer laptops I see no adequate alternatives. Ethernet/TCP? Lack of a standardized IP addressing configuration makes it too cumbersome to field personnel since all vendors will implement their interfaces differently. USB? See the preceeding paragraphs. Couple that with the fact that the complexity of the protocols and software required to implement communication via TCP and USB are ridiculous to that of RS-232, there is no reasonable solution that I have seen yet. In an embedded system, UART (RS-232/422/485) core I/O routines can be written in one or two dozen lines of code. Lines of code for TCP/IP and USB stacks easily number in the thousands, and may also require a multitasking OS for certain API requirements. Because of this, UART interfaces aren't going away any time soon.
Considering my past experience as a seventeen-year-old, I was a bad driver because I acted like a seventeen-year-old, not because I was new to driving.
I got my Ontario G1 (learners permit) when I was 16 years old. I drove with my parents in my high school parking lot a few times but never really got into it because my bicycle or public transportation could get me everywhere I wanted to be and cost me next to nothing. This license ended up expiring after 5 years, and I had to get it again because it was easier for ID than going through the hoops for an "age of majority card" so I could continue buying beer (age is 19 in Ontario). Three years after that - 24 years old, and now 8 years after I first got my learners - I finally learned to drive and upgraded my license through the required road test to being able to drive alone/unsupervised since this was a prerequisite for the girl I was after at the time. I've been driving ever since.
I don't know what it's like to be 17 and driving, but I have always felt like I skipped the insanity period. As much as I despise the insurance companies, I can fully understand why they charge more for younger drivers age-wise.
My personal favourite, that seemed to rise and fall in popularity around here last year or the year before, is wearing a hood while driving. I'm not sure about most other people, but I for one don't turn MY ENTIRE UPPER BODY to look over my shoulder, like those guys must have to.
Often programmers are somewhat trapped in the office while the marketing and management get to travel and wine and dine clients. Thus throwing them some bones such as food and conference travel balances out the equation.
This.
I am in a relatively unique position that some software testing and occasionally actual bug fixes as a result of said testing cannot be done anywhere other than on customer property. In my case, this is railway cars/yards across North America. Accordingly, most of these locations are in major cities due to them being transportation hubs. Very infrequently Japan and Germany come up. While not the same as a vacation with the family, these trips are worth more to me than what the company ends up paying. Bonus when I can actually manage to bring the family.
In a similar vein, I think every programmer should have some direct exposure to the customer. A five minute off-the-cuff conversation with them during a break in a meeting is solid gold compared to being hidden specifications and poorly translated information from managers / meeting minutes.
and the groceries at the company store (not quite, but we are getting there)
Many people HAVE been there, and it didn't work out well for them:
Along with the company houses came the company store — one in each community, stocked with everything that the miner or his family would ever need. These were quality goods, but they came with a high price; everything could be charged on credit against the miner's pay envelope, and few families escaped being in perpetual economic bondage. Over time, company stores in Nova Scotia's coal-mining towns became symbols of corporate oppression and in times of labour unrest were the objects of looting and violence.
Yes absolutely, depending on the type of software you write. I've seen cases where someone removed an unused variable from the stack in a C function which, because of the change in stack sizing, caused a previously unknown buffer overrun to now corrupt a different, used variable. All sorts of hilarity ensued when this caused a problem in release builds only and not debug builds, which of course the developer was using exclusively.
If you make such a change to the braking system in my car, you're damn right I want that entire code base retested. If it's a change to some simple financial software, I still want some modicum of retest so I don't get embarassed by breaking a previously working program to my customers, but might forego the entire week-long test.
No offense intended, but you sound like a number of college co-op students I've been charged with in the past. People new to the neighborhood trying to prove something with all of the great new tech they've been learning in school or on their own time. Certainly that is not inherently a bad thing, but often they don't understand the big picture particularly with regards to existing documentation, library dependencies / escrow environments, and test / V&V efforts.
made the code more elegant (refactoring)
As a general rule, I kill this in the cradle. A noble cause, but rife with risk and not worth it unless certain new requirements can justify such a change.