Most embedded guys are batting out of their league and don't have a clue when it comes to security... and I say that as an embedded guy who often has to do exactly that to get the product out.
Most embedded development I've done is far from 'software engineering' - it's whack and hack until the tests pass(often because you loosened the testing requirements).
Gee man, get a spine and at least raise a stink about the problem next time. I understand that sometimes you gota just deliver what you got for business reasons but if you keep doing that without making a point about the quality and security of the solution, eventually they will *rightly* hold you responsible for the failures. Such stuff can get hard to hide on a resume. Do the *right* thing as often as you can and when someone forces you into doing the wrong thing, document the issue, if for nothing else but to CYA.
The US also has laws against fraud and racketeering. Doesn't seem to apply to companies over a certain size.
That was the ORIGINAL position that I was debating as not true... Seems that you are now trying to change positions.
CAPTCHA: You lost..
Now if you are debating some OTHER position, fine, but that position really seems to be about the law doing what you think is fair. I've heard no evidence that suggests that the law is not being applied to large companies, and your very own arguments indicate that these "large" companies ARE being prosecuted, you just don't like the level of punishment they receive and think it should be more. THAT is a different issue from where this all started.
The problems that GIT has are well documented elsewhere (or actually NOT well documented) as the case may be. My primary issue with GIT is that it is non-intuitive, not that it doesn't have the features I need or that it doesn't work. Add to that the sorry state of the documentation for the project and you should "get" my objections to using "git". The diagnostic messages from the tool are cryptic, documentation is anything but clear and the ways you can use the tool are varied. Once you understand how to make it do what you need, it just works, but the learning curve is high and the documentation is limited. But that's the Travois' way...
Your mileage may vary and I reserve the right to change my mind in the future...
Look, I don't care what the Hollywood elites want to throw their PR machines onto, it's usually bogus from them anyway. For the most part it's about the show, the PR the "look at me!" mind set with them. If their efforts manage to actually *help* somebody, I'm totally happy for everybody involved, knock yourselves out, raise money enjoying rubber chicken at $10,000/plate or recording PSA's for free.
Just remember that all this hoopla is only really about 2 things. 1. Public Relations and keeping your face in front of the paps so your photo shows up more often to keep your prospective fan base alive between your actual paying gigs... 2. For some, a secondary point is to assuage their feelings of guilt for being so affluent and living in such opulent surroundings. They tell themselves they ARE good people, after all they did all this AIDS/Cancer/Feed the Children/SPCA and PETA stuff for free..
Be happy anytime good comes out of something and stop complaining that their issue of the day is the wrong one in your eyes. Be happy even if their motives for doing good are no good. Just be happy that good is being done and let the rest go. Then go out and do what YOU think is right...
Actually, for git, I would strongly recommend you NOT use the GUIs like Tortoise, at least until you have an excellent understanding of what git does. Therefore, the work instructions I provide my development staff are written using the command line interface.
So to answer your question, No, I'm not afraid of the command line.
My comments about git where about the specific situation faced by the person asking the question in the article. Git isn't the tool he needs... Actually, I don't think any tool out there will help him. Surely none of the source code management tools would be anything but trouble for his business...
I'm not saying git couldn't provide you with merge tools for Office documents, I'm saying that by default it doesn't provide merging for Office documents. So if you have a conflict in an Office document, git will only let you pick which of the two documents to keep, it doesn't provide a means of merging the documents.
But, this is NOT unique to git... Subversion, ClearCase and others all have the same issue....
If they have a compromised machine on your network, you are hosed in more ways than them being able to change your router firmware. I think the bigest risk at that point is someplace else...
Oh I use get *everyday* actually... Sorry to burst your bubble...
Git stores office documents as blobs because the commonly installed merge tools do not support Office documents, spreadsheets and such. So there is that.. Then there is the git mindset that Trovolas explains as "The opposite of what CVS does" in his deadpan way. The problem is, CVS actually got some things right and in departing from the tool he hated when building git means some of git is wrong.
The problem I see with Git for source code, is how the branching and merge stuff works with push and pull. You have to be VERY clear about your understanding of what Git does and you have to develop a process for git that fits your Configuration Management strategy. Sometimes this is NOT intuitive to the casual user of git due to the terms they picked and the default behavior of git when you don't provide all the parameters for certain commands. However, if you have a process that specifies all this for your users, git works OK, but I find my developers just have to apply the "magic wand" commands in the process w/o understanding what they are actually doing. This tells me that git is just too complex and nobody wants to learn it.
So I ask you, do you end up with multiple copies of essentially the same document with minor edits laying around? I'm guessing that is "No".
I dare say that your process precludes multiple people from editing the same document at the same time, that if Bob has an edit to do and Alice needs to put her changes in the same document, she waits, or calls Bob and asks him to close the document. You have a process that works for you and avoids having to merge changes from separate documents into one.
The original article described a situation that sounds like a bunch of people who have lost a lot of their changes in the past, which means the merge problem is not solved, and they have a process problem. If you don't have this issue, you don't have a process problem..
Very true.. They do load their own UI instead of LUCI but it's an older scaled down version of OpenWRT. Most will also let you login using a "secret" handshake packet that turns on ssh I think, so you can login to the console and play around with the thing.
My 4300 with OpenWRT and the default LUCI install is worlds better though. I get all sorts of cool features that the stock firmware only dreams of. I get 802.11Q VLANs, so I can have multiple wired networks, separate control of the radios where I can create multiple wireless LANs, keep them separated from my wired network, my DMZ and a whole host of really nice to have things. Turns that consumer router into quite the nicely featured router/VPN end point/Firewall/fileserver or what ever I need it to be. For that reason I have 2 of them...
Usually the only network interface UBoot is configured to use is on the local network side, on a wired interface and the IP address used is non-routable. You are not getting your alternate firmware loaded without being physically present with the router, connected by a wire, so some external party isn't going to compromise your router this way...
Except, with a star towing you, it might be possible to use the star for an energy source to keep the O2 flowing and stuff like that... In the vast nothingness of space, there isn't much to scavenge, energy wise..
Still, I'm not sure being that close to a fusion reactor is worth the radiation exposure....
Which is a "process" fix... User A edits document A, B edits B and then you combine them to display the document...
Look, I'm not advocating for a serialized work flow persay, I'm advocating for elimination of the "merge" of disparate documents and I'm advocating that they need to fix the PROCESS or nothing they can buy or install will be helpful.
I get it, you don't like the LAW.... Get the law changed if you want, but don't fool yourself, the law applies to big, small and everything in between.
You must not write software.... The Evils of MERGING cannot be over estimated. Us software engineers go to great lengths to avoid having to do a difficult merge process because it is error prone, time consuming and messy...
If you don't design your process to avoid the merge, you will be forever doomed to spend your resources trying to do merges.
Tools *can* help you, but only if the process model of the tool matches your process close enough. But good tools usually cost lots of money, even the free ones, when you install and configure them. Training your employees to use them is costly too. Most tools will force you into process changes.
I suggest you START by adapting the process to fix your problems. If that is simply not possible, and you are sure a tool will save you (unlikely), then you will need to adapt your process to fit the tool you choose.... But I don't care what direction you end up going, the process WILL change. The low risk move is to forget the tool and fix the process if you can.
So you are suggesting they depart form Office and use some other tools?
Where I see what you are suggesting would work, I'm pretty sure the costs incurred in the implementation of such a solution is going to be way up there and unless you have carefully considered the business needs and designed the process and trained the team in both the process and the tools you will put this place out of business.
I've seen things like this happen. I saw a catering company that worked just fine on paper, they had an ordering system, inventory control system and fulfillment system all based on paper. They went out and tried to automate the system, all at once, and it failed horribly because they went and did the whole process in a new tool that didn't match their business. They struggled for nearly a year, loosing orders, loosing money, loosing customers before the bugs got ironed out, but by then it was too late. They went bankrupt.
Go for the low hanging fruit here. It's cheaper, quicker and a whole lot less risky. Fix the process and only let one person edit a document at a time...
You simply have to solve the multiple editors problem to avoid the nasty merge problem. Unfortunately, not avoiding the merge when possible IS a process problem. Fixing the process doesn't take tools, it takes a bit of thought followed by communicating the new process to the team.
Until they solve the multiple editors problem, all the configuration management in the world won't help them. However, if they fix the process problem, any of the common configuration management tools would work just fine.
Further, just going out and adopting a tool and trying to adapt your process to match the tool is likely to be plain foolishness. If you are not sure that your process and the tool make the same assumptions, you just put a huge wrench in the works of the company. People will look at the tool to be the problem and blame it for not getting their work done, and it's likely they will be right.
Fix the process.... First and foremost it's the process that needs to fit the business. After that, tools must fit the process, or forget it, they are a waste of resources. There are FEW instances where it makes sense to adapt processes to match a tool, and usually those come about because some PHB purchased the tool from a slick sales team and now you are forced into the tool, but hopefully that's something that rarely happens where you work...
So, you now admit that these companies ARE pursued and convicted but you don't like the amount of the fines applied? So be it, but the initial contention that these companies do not get the law applied to them has been shown as false.
The companies pay the fines which are defined in law, so your real objection is to the LAW, not that companies skirt the law and are never caught. They ARE caught and fined in accordance with law as I contended from the start. You need to work on getting the law changed...
So what is your objection? That they don't get caught and punished or that you think they should be punished more? Look, If you don't like how much these companies get fined, that's NOT the same as saying the law doesn't apply to them, because obviously you now admit that it does. Your objection is to the cost of the fines which is established IN LAW.
The law applies to them, you just don't like the law... But that's not where this tread started...
The problem you have is a "process" problem. If everybody is editing documents all over the place at the same time on shared drives, you simply cannot avoid the *real* problem and that is a process one. CVS or RCS, or any other "version control system" cannot fix the process problem.
You need to think about why the "process" allows multiple people to be editing the same document at the same time. If you continue to allow this practice, your issue becomes a question of "how to merge" all this input back into ONE document. Unfortunately, Merging is pretty much *always* guaranteed to be a hard problem, especially when you are merging things that are complex in structure. Source code is bad enough, but you are dealing with stuff that most revision control systems just store as binary blobs and can usually only tell you that copy x is different than copy y, but not what the changes actually are.
So, your FIRST responsibility here is to solve the problem with your process that leads to multiple editors having the file open at once and pare that down to the minimum number of editors you can (hopefully ONE at a time) and then deal with the difficult merge task that's left. I'll warn you that you may need to enforce the process using file permissions, only giving limited people write access to the file on the share so only they can change it. Everybody else has to go though them.
THEN, you can implement just about ANY revision management system you want, or if your access controls are well enough established, just keep everything on a common share that everybody can read, but only by going though the process can they change things... If you *must* have revision management, go with something that can parse the internal changes of the files you store as much as possible. For Office documents, I would assume Microsoft has tools for that, beyond just sharepoint...
Lord help you if you do... It's bad enough for source code, but it's horrible for Office documents.... On the plus side, everybody has their own local repository so loosing data due to drive failures is minimized over having everything on a server, but all that pushing and puling with merging is painful on things like word documents...
Yea.... My brain was messed up... After remembering that Decibels means 1/10th of a bel by definition, this means that +40DB is 10,000 (four zeros) by definition... This 3db is double thing is a short hand rule that is "close enough" for slide rule math and what I originally was taught to use when doing calculations like this.
So... given the problem with the rule of thumb approximation I used, I'm not going to try and defend the math that got me the wrong answer..
Slashdot Mirror
Most embedded guys are batting out of their league and don't have a clue when it comes to security... and I say that as an embedded guy who often has to do exactly that to get the product out.
Most embedded development I've done is far from 'software engineering' - it's whack and hack until the tests pass(often because you loosened the testing requirements).
Gee man, get a spine and at least raise a stink about the problem next time. I understand that sometimes you gota just deliver what you got for business reasons but if you keep doing that without making a point about the quality and security of the solution, eventually they will *rightly* hold you responsible for the failures. Such stuff can get hard to hide on a resume. Do the *right* thing as often as you can and when someone forces you into doing the wrong thing, document the issue, if for nothing else but to CYA.
The US also has laws against fraud and racketeering. Doesn't seem to apply to companies over a certain size.
That was the ORIGINAL position that I was debating as not true... Seems that you are now trying to change positions.
CAPTCHA: You lost..
Now if you are debating some OTHER position, fine, but that position really seems to be about the law doing what you think is fair. I've heard no evidence that suggests that the law is not being applied to large companies, and your very own arguments indicate that these "large" companies ARE being prosecuted, you just don't like the level of punishment they receive and think it should be more. THAT is a different issue from where this all started.
The problems that GIT has are well documented elsewhere (or actually NOT well documented) as the case may be. My primary issue with GIT is that it is non-intuitive, not that it doesn't have the features I need or that it doesn't work. Add to that the sorry state of the documentation for the project and you should "get" my objections to using "git". The diagnostic messages from the tool are cryptic, documentation is anything but clear and the ways you can use the tool are varied. Once you understand how to make it do what you need, it just works, but the learning curve is high and the documentation is limited. But that's the Travois' way...
Your mileage may vary and I reserve the right to change my mind in the future...
What a troll... Who cares?
Look, I don't care what the Hollywood elites want to throw their PR machines onto, it's usually bogus from them anyway. For the most part it's about the show, the PR the "look at me!" mind set with them. If their efforts manage to actually *help* somebody, I'm totally happy for everybody involved, knock yourselves out, raise money enjoying rubber chicken at $10,000/plate or recording PSA's for free.
Just remember that all this hoopla is only really about 2 things. 1. Public Relations and keeping your face in front of the paps so your photo shows up more often to keep your prospective fan base alive between your actual paying gigs... 2. For some, a secondary point is to assuage their feelings of guilt for being so affluent and living in such opulent surroundings. They tell themselves they ARE good people, after all they did all this AIDS/Cancer/Feed the Children/SPCA and PETA stuff for free..
Be happy anytime good comes out of something and stop complaining that their issue of the day is the wrong one in your eyes. Be happy even if their motives for doing good are no good. Just be happy that good is being done and let the rest go. Then go out and do what YOU think is right...
Actually, for git, I would strongly recommend you NOT use the GUIs like Tortoise, at least until you have an excellent understanding of what git does. Therefore, the work instructions I provide my development staff are written using the command line interface.
So to answer your question, No, I'm not afraid of the command line.
My comments about git where about the specific situation faced by the person asking the question in the article. Git isn't the tool he needs... Actually, I don't think any tool out there will help him. Surely none of the source code management tools would be anything but trouble for his business...
I'm not saying git couldn't provide you with merge tools for Office documents, I'm saying that by default it doesn't provide merging for Office documents. So if you have a conflict in an Office document, git will only let you pick which of the two documents to keep, it doesn't provide a means of merging the documents.
But, this is NOT unique to git... Subversion, ClearCase and others all have the same issue....
If they have a compromised machine on your network, you are hosed in more ways than them being able to change your router firmware. I think the bigest risk at that point is someplace else...
So we've established that the original "They don't get caught" theory is incorrect and you object to the level of punishment....
Stop complaining that they don't get caught and go get the law changed...
Oh I use get *everyday* actually... Sorry to burst your bubble...
Git stores office documents as blobs because the commonly installed merge tools do not support Office documents, spreadsheets and such. So there is that.. Then there is the git mindset that Trovolas explains as "The opposite of what CVS does" in his deadpan way. The problem is, CVS actually got some things right and in departing from the tool he hated when building git means some of git is wrong.
The problem I see with Git for source code, is how the branching and merge stuff works with push and pull. You have to be VERY clear about your understanding of what Git does and you have to develop a process for git that fits your Configuration Management strategy. Sometimes this is NOT intuitive to the casual user of git due to the terms they picked and the default behavior of git when you don't provide all the parameters for certain commands. However, if you have a process that specifies all this for your users, git works OK, but I find my developers just have to apply the "magic wand" commands in the process w/o understanding what they are actually doing. This tells me that git is just too complex and nobody wants to learn it.
Well It's cheaper than clearcase.... That's something..
So I ask you, do you end up with multiple copies of essentially the same document with minor edits laying around? I'm guessing that is "No".
I dare say that your process precludes multiple people from editing the same document at the same time, that if Bob has an edit to do and Alice needs to put her changes in the same document, she waits, or calls Bob and asks him to close the document. You have a process that works for you and avoids having to merge changes from separate documents into one.
The original article described a situation that sounds like a bunch of people who have lost a lot of their changes in the past, which means the merge problem is not solved, and they have a process problem. If you don't have this issue, you don't have a process problem..
Very true.. They do load their own UI instead of LUCI but it's an older scaled down version of OpenWRT. Most will also let you login using a "secret" handshake packet that turns on ssh I think, so you can login to the console and play around with the thing.
My 4300 with OpenWRT and the default LUCI install is worlds better though. I get all sorts of cool features that the stock firmware only dreams of. I get 802.11Q VLANs, so I can have multiple wired networks, separate control of the radios where I can create multiple wireless LANs, keep them separated from my wired network, my DMZ and a whole host of really nice to have things. Turns that consumer router into quite the nicely featured router/VPN end point/Firewall/fileserver or what ever I need it to be. For that reason I have 2 of them...
Usually the only network interface UBoot is configured to use is on the local network side, on a wired interface and the IP address used is non-routable. You are not getting your alternate firmware loaded without being physically present with the router, connected by a wire, so some external party isn't going to compromise your router this way...
Until Virgin Galactic starts selling tickets,
I thought they already had started selling tickets....
Except, with a star towing you, it might be possible to use the star for an energy source to keep the O2 flowing and stuff like that... In the vast nothingness of space, there isn't much to scavenge, energy wise..
Still, I'm not sure being that close to a fusion reactor is worth the radiation exposure....
Which is a "process" fix... User A edits document A, B edits B and then you combine them to display the document...
Look, I'm not advocating for a serialized work flow persay, I'm advocating for elimination of the "merge" of disparate documents and I'm advocating that they need to fix the PROCESS or nothing they can buy or install will be helpful.
I get it, you don't like the LAW.... Get the law changed if you want, but don't fool yourself, the law applies to big, small and everything in between.
You must not write software.... The Evils of MERGING cannot be over estimated. Us software engineers go to great lengths to avoid having to do a difficult merge process because it is error prone, time consuming and messy...
If you don't design your process to avoid the merge, you will be forever doomed to spend your resources trying to do merges.
Tools *can* help you, but only if the process model of the tool matches your process close enough. But good tools usually cost lots of money, even the free ones, when you install and configure them. Training your employees to use them is costly too. Most tools will force you into process changes.
I suggest you START by adapting the process to fix your problems. If that is simply not possible, and you are sure a tool will save you (unlikely), then you will need to adapt your process to fit the tool you choose.... But I don't care what direction you end up going, the process WILL change. The low risk move is to forget the tool and fix the process if you can.
So you are suggesting they depart form Office and use some other tools?
Where I see what you are suggesting would work, I'm pretty sure the costs incurred in the implementation of such a solution is going to be way up there and unless you have carefully considered the business needs and designed the process and trained the team in both the process and the tools you will put this place out of business.
I've seen things like this happen. I saw a catering company that worked just fine on paper, they had an ordering system, inventory control system and fulfillment system all based on paper. They went out and tried to automate the system, all at once, and it failed horribly because they went and did the whole process in a new tool that didn't match their business. They struggled for nearly a year, loosing orders, loosing money, loosing customers before the bugs got ironed out, but by then it was too late. They went bankrupt.
Go for the low hanging fruit here. It's cheaper, quicker and a whole lot less risky. Fix the process and only let one person edit a document at a time...
You simply have to solve the multiple editors problem to avoid the nasty merge problem. Unfortunately, not avoiding the merge when possible IS a process problem. Fixing the process doesn't take tools, it takes a bit of thought followed by communicating the new process to the team.
Until they solve the multiple editors problem, all the configuration management in the world won't help them. However, if they fix the process problem, any of the common configuration management tools would work just fine.
Further, just going out and adopting a tool and trying to adapt your process to match the tool is likely to be plain foolishness. If you are not sure that your process and the tool make the same assumptions, you just put a huge wrench in the works of the company. People will look at the tool to be the problem and blame it for not getting their work done, and it's likely they will be right.
Fix the process.... First and foremost it's the process that needs to fit the business. After that, tools must fit the process, or forget it, they are a waste of resources. There are FEW instances where it makes sense to adapt processes to match a tool, and usually those come about because some PHB purchased the tool from a slick sales team and now you are forced into the tool, but hopefully that's something that rarely happens where you work...
So, you now admit that these companies ARE pursued and convicted but you don't like the amount of the fines applied? So be it, but the initial contention that these companies do not get the law applied to them has been shown as false.
The companies pay the fines which are defined in law, so your real objection is to the LAW, not that companies skirt the law and are never caught. They ARE caught and fined in accordance with law as I contended from the start. You need to work on getting the law changed...
So what is your objection? That they don't get caught and punished or that you think they should be punished more? Look, If you don't like how much these companies get fined, that's NOT the same as saying the law doesn't apply to them, because obviously you now admit that it does. Your objection is to the cost of the fines which is established IN LAW.
The law applies to them, you just don't like the law... But that's not where this tread started...
The problem you have is a "process" problem. If everybody is editing documents all over the place at the same time on shared drives, you simply cannot avoid the *real* problem and that is a process one. CVS or RCS, or any other "version control system" cannot fix the process problem.
You need to think about why the "process" allows multiple people to be editing the same document at the same time. If you continue to allow this practice, your issue becomes a question of "how to merge" all this input back into ONE document. Unfortunately, Merging is pretty much *always* guaranteed to be a hard problem, especially when you are merging things that are complex in structure. Source code is bad enough, but you are dealing with stuff that most revision control systems just store as binary blobs and can usually only tell you that copy x is different than copy y, but not what the changes actually are.
So, your FIRST responsibility here is to solve the problem with your process that leads to multiple editors having the file open at once and pare that down to the minimum number of editors you can (hopefully ONE at a time) and then deal with the difficult merge task that's left. I'll warn you that you may need to enforce the process using file permissions, only giving limited people write access to the file on the share so only they can change it. Everybody else has to go though them.
THEN, you can implement just about ANY revision management system you want, or if your access controls are well enough established, just keep everything on a common share that everybody can read, but only by going though the process can they change things... If you *must* have revision management, go with something that can parse the internal changes of the files you store as much as possible. For Office documents, I would assume Microsoft has tools for that, beyond just sharepoint...
Lord help you if you do... It's bad enough for source code, but it's horrible for Office documents.... On the plus side, everybody has their own local repository so loosing data due to drive failures is minimized over having everything on a server, but all that pushing and puling with merging is painful on things like word documents...
Yea.... My brain was messed up... After remembering that Decibels means 1/10th of a bel by definition, this means that +40DB is 10,000 (four zeros) by definition... This 3db is double thing is a short hand rule that is "close enough" for slide rule math and what I originally was taught to use when doing calculations like this.
So... given the problem with the rule of thumb approximation I used, I'm not going to try and defend the math that got me the wrong answer..