"They [humans] should have a password for their computer, and that's it. All other passwords are superfluous."
I don't think you have properly thought about the implications of what you are saying.
On the other hand, even with that single password, it's still either memorable, therefore easy to hack, or it isn't, in which case you turn again to the sticker on the monitor.
Of course yes, but it is not as if it would make any difference in cases like this. You should understand that (business) contracts only mean something when both parties are of similar weight. When that's not the case, it is not the letter of the contract what will save you but your ability not to paint yourself in the corner before signing (not always possible) and your negotiating abilities before that.
As someone else already cited, when making business with a big fish you are always exposed to the "I am altering the deal. Pray I don't alter it any further."
"Contract problem was my first thought when I read the summary."
No, I don't think so. It may look like a contract problem but it usually isn't.
At first it looks like "hey, let's see if I can squeeze out a bit more from my dollars" (which is why it looks like a contract problem) but in the end it results on a broken provider and a customer without a product and quite less notes in their wallet.
You may end with "contract problems" if both parties have conflicting interests, but you don't have "contract problems" on situations were both parties need necessarily to agree in the general output: the problem must be somewhere else.
In this case clearly yes. It doesn't take any technical knowledge to know that in order to deliver anything you need to stop feature creeping somewhere. The only thing that needed to be in plain English was "I have a new requirement..."; everything from that point on could perfectly be in Klingon from all management would care.
Management, specifically product management in this case, is all about setting in stone what the minimally viable product will be and then make it happen and it specifically is not bending to a partner's gut feeling about adding another bolt to it.
"We love to make fun of the useless "suits". But that's a situation where you need good executive management"
Me too.
Well, since just a "me too" seems a bit lame, I was going to say that I don't see this as a scope creeping problem but a bad management one. "But, but... poor me, Microsoft added new features with no more money, buhu, buhu!"
Even with the extra money, proper management would have said "no: we will deliver with our current feature list and done with it; come back for version two, if you want it"
"In other words, there is no methodical way to guarantee anything interesting about a piece of software, and that includes whether it works properly under every input. You can verify that it works with "typical" inputs, but there will always be some set of boundary conditions that you couldn't possibly have known to check on day one."
You can put it any way you want, since I already accepted that and asked "so what?"
You are arguing that you can't deliver flawless software by day zero (which I alredy accepted) as an excuse to not correct the flaws once they appear (which is what I make a point of).
"With cars, it's posible. With complex software it isn't. There's a reason for that."
No, with cars isn't possible either. Every major brand has recalls and maintenance programs for that very reason. The difference is that respectable brands will launch a maintenance program for a detected flaw even if it is ten years down the road and customers will enrage and go for a class action if they don't.
And cars, being physical objects will have wearing parts and, again, people won't accept a "buy a newer model" answer from the vendor ten, fifteen or even more years later when going for a replacement.
"Look up Rice's Theorem. Or work on a major software project. It goes way beyond unfair to expect a complex software system to "just work as it should" - it's mathematically impossible to make sure it does."
No problem with that. So the software doesn't work as it should when shipped? Ok. But that's not the point: I was not talking about the software not being ready when shipped but the vendor's negative to correct it. Is it ten years down the road when I step into a broken part of the product? so what?
"supporting every single ancient version just because one guy somewhere might be using it would take man-hours away"
No, no, and one thousand times no. It is not taking away hours from anywhere since your software is broken. The fact that you delivered broken software works in fact the other way around: you were allowed to take hours away to your delivery date and you are allowed to only recover them afterwards as people stump in the bugs and the need arises.
"Furthermore, the older a version of a program gets, the more of its devs switch jobs, retire, etc."
I see... so, again, what? Taking your own words, look up Rice's Theorem: you knew all that the very day you shipped the product and still you didn't plan for it? It is the vendor's problem, don't try to make it into a customer's one.
You see... the software business is in pathetic shape, we accept quality levels that would ashame any other industry and still we racionalice the statu quo to make it more palatable instead of taking professional pride into making it better.
"In-place upgrades are one thing, and they're great until one goes belly-u"
As I already told, the machine I'm writing this from was originally installed about ten years ago and upgraded in place since then, despite of the fact that, by now, it shares not a single piece of the original hardware.
In fact, in the last almost 20 years (wow, time really goes by!) I don't remember having an in-place upgrade going so bad that I couldn't recover it, and I'm talking hundreds, probably thousands of machines even working remotely on a different continent in all these years.
I'm sure that all those systems being of the Debian Stable flavour has something to do with my sucess rate.
"That may sound funny to you guys [...] Eventualy we found two servers standing next to each other, underneath a pile of cardboard boxes and rolls of toilet paper, in the building supervisors storage cupboard, both running netware 2.15 ( it was early nineeties). Both with an uptime of more than two years."
Forgetting the issue about no backups, I don't find it funny but sad: it just shows the utterly lame situation of IT the fact that something like this comes to a surprise instead of being the norm.
"know that sounds like cynical marketroidism, but sometimes you do need to do that to wean people off some hideously ancient version they're still running on an old 386 under Netware 3.1 bricked into a wall next to the second floor men's toilet."
Why do you think those people are running "some hideously ancient version they're still running on an old 386 under Netware 3.1 bricked into a wall next to the second floor men's toilet"? Do you think it's in order to upset your tech department or it might be because it does what it needs to do so if it's not broken why should I need to fix it?
To add insult to injury, remember you would have no problem supporting ancient versions of your software if there were no bugs to fix on it so what you really are doing is failing to provide the customer with a product that just works as it should without broken parts.
And you think it only "sounds" like cynical marketroidism? It *is* cynical marketroidism.
"Oh and you need linux support for all the hardware in your machine."
Are you implying Windows doesn't need support for all the hardaware in your machine? Seems a bit weird.
Re:My kingdom for an easy software reinstall tool.
on
Linux 4.0 Kernel Released
·
· Score: 3, Interesting
"Unfortunately the only technique I ever found (and I've forgotten what it was at this point) generated a text file listing *every* package installed on the machine"
Unfortunately I fail to see where's the problem.
"a list nigh guaranteed to bork a machine if I tried to import it all on a different OS version"
Not my experience.
Now, my experience: 1) Debian-based: I don't reinstall that often (now that I remember, my current setup goes in time about 10 years or maybe more). 2) Debian-based when cloning a machine: when it's been the same release, no problem at all. When the receptor is a different version (newer) I installed a minimal system and then applied the package list. It might fail on some package disappearing or changing names (usually only a few) and then it's a matter to see what failed and act accordingly. Worst case scenario, I had to extract a list of the (partial) setup on the new machine and diff old/new. 3) Red-Hat based: yes, they are not so great at upgrading in place so I had to resort to the trick in point two. It was a bit longer and required more than one iteration but far from a drama.
"And good luck sorting out the 10% of user software from the umpteen dozen pages of semi-cryptically named packages."
From time to time (I mean months or even years, here) I spend no more than an hour looking at the installed package list. I know what most of the packages do, for the minority I don't know, I read its description as provided by the package manager. If still no clue, I try to unistall it and see what reverse-dependencies are going to be unistalled, which always made clear what was happening. Not a big problem either.
Oh! by the way, a few seconds of google search showed me how to list manually installed packages both for debian-based and redhat-based systems so it seems your concern was not so much a problem even for you as to expend even a minute looking for a solution.
"So even if I managed to get my malware on a machine and then somehow got the sensitive data onto some sort of external media, I still don't have anything useful."
"the poster is paranoid and said that offsite was no longer under his complete control."
Any sysadmin will tell you that being paranoid is really a good thing, but that you need to be paranoid about the proper things. He is right about thinking anything not under his control will be under control of the one taking care of it.
So what if it is not under his control? * He won't be able to recover when need arises: make sure you have more than one copy under different stewardship and test access from time to time. * Stewardess will gain access to the contents to see/change them: cypher & checksum them and see point above to safeward the keys.
"he said he wants something less likely to survive a fire and stay onsite."
And I want round nails going softly on square pegs. Sorry, it doesn't work that way.
No, fireproof is no substitute. If you really value your data, multiple copies, at least one of them off site is the only way to go.
But, now we are talking about fireproof... that's not an absolute concept. The fireproof is rated for temperature outside, max temperature inside (or delta from outside) and time to stand it. First aka_bigred has to know is the rating of his vault: any support that can stand the internal temperature rate is valid; if the fire goes outside the rating, think of it as lost (you might be lucky though). I can attest recovering data from DAT tapes on vaults exposed around the limit of its rate.
In case it's the lattest, go please check what was the language science, both pure and applied, and engineering was written on along the second half of XIX century up to World War II.
"First, this is not an imaging system, it's an install system which installs mainly Debian based distributions, based on Fully Automatic Installation (fai-project.org)."
How is this different, then, to Debian Edu? (forget about the fact of "Edu" on its name).
It also aims for a centralized Debian environment, imaging system, centralized configurations, etc. and it's, of course, since it's been in development for some few years, much more mature than your project.
""Don't worry, no BjÃrgen KjÃrgen; it's all in English."
Nobody outside your psicotic circles worries about the richness of humanity having more languages than just English."
I do.
It could probably been said in a more "politically correct" way and, me myself being Spanish, have my own concerns about English being the "common trade" language of the world (as it has been French, German, Spanish, Latin... in the past), but I applaud the project being set in English instead of Finn, since it'll reach a greater audience (me, for one). Using English is not so Americans can benefit of it, but in order for everybody to do so.
"The plan with this system is to offer a number of different ways to manage an infrastructure and FAI is one, preseeding is another, the foreman could be a third"
Remember the old saying "He that too much embraces, holds little."
Despite of the risk of failing in your choosings (I for one have concerns on your choice on FAI), this is a project that is basically based on taking third party pieces and massaging and gluing to convince them to work together. Therefore I think, it's OK for the project to be strongly opinionated on how things need to be done, even more if the people working on it have the acumen and experience to (at least in general) choose the right tools and make them work together in a loosly coupled and modular way so each module can be exchanged for different ones.
Being said that, it's also important to understand that it is probably impossible to find a single solution that fits any environment, so having different goals for different scenarios is also OK. In this regard, I remember an old Samba tutorial: they didn't set a single environment, but they went (more or less) deploying for a short office, then for a bigger office with branches, then for a big corporation with multiple divisions and mergers. While they built it so each tutorial built on the knowledge from the previous one, each had its own worthy differences.
All in all, an interesting project, which I hope the best luck for.
"What I'm curious about is how will different algorithms from different manufacturers all react to each other?"
Like in "I'll try not to crash into anything" and then the competing brand goes with "I'll crash into everything that moves around"? Please, show me you have think of it at least for a few seconds offering a detailed example of your scenario.
"how does it know when the brakes have worn out?"
Doesn't your car have an indicator of braking pads' end of life? Mine has, and it's 15 years old.
"Is the onus on the car or the owner at that point?"
The onus is never on a thing but on a legal person. Cars are things, not legal persons.
"Will the car just refuse to turn on if it senses that work needs to be done?"
This is exactly what most cars already do, again no need to go autonomous for that.
Slashdot Mirror
"They [humans] should have a password for their computer, and that's it. All other passwords are superfluous."
I don't think you have properly thought about the implications of what you are saying.
On the other hand, even with that single password, it's still either memorable, therefore easy to hack, or it isn't, in which case you turn again to the sticker on the monitor.
"read the damn contract"
Of course yes, but it is not as if it would make any difference in cases like this. You should understand that (business) contracts only mean something when both parties are of similar weight. When that's not the case, it is not the letter of the contract what will save you but your ability not to paint yourself in the corner before signing (not always possible) and your negotiating abilities before that.
As someone else already cited, when making business with a big fish you are always exposed to the "I am altering the deal. Pray I don't alter it any further."
"Contract problem was my first thought when I read the summary."
No, I don't think so. It may look like a contract problem but it usually isn't.
At first it looks like "hey, let's see if I can squeeze out a bit more from my dollars" (which is why it looks like a contract problem) but in the end it results on a broken provider and a customer without a product and quite less notes in their wallet.
You may end with "contract problems" if both parties have conflicting interests, but you don't have "contract problems" on situations were both parties need necessarily to agree in the general output: the problem must be somewhere else.
"Just being good at "management" is not enough."
In this case clearly yes. It doesn't take any technical knowledge to know that in order to deliver anything you need to stop feature creeping somewhere. The only thing that needed to be in plain English was "I have a new requirement..."; everything from that point on could perfectly be in Klingon from all management would care.
Management, specifically product management in this case, is all about setting in stone what the minimally viable product will be and then make it happen and it specifically is not bending to a partner's gut feeling about adding another bolt to it.
"We love to make fun of the useless "suits". But that's a situation where you need good executive management"
Me too.
Well, since just a "me too" seems a bit lame, I was going to say that I don't see this as a scope creeping problem but a bad management one. "But, but... poor me, Microsoft added new features with no more money, buhu, buhu!"
Even with the extra money, proper management would have said "no: we will deliver with our current feature list and done with it; come back for version two, if you want it"
"Humans create passwords that are easy to remember, which almost invariably makes them terrible passwords."
Of course, hard to remember passwords which will get sticked in yellow over the monitor are so much better.
"In other words, there is no methodical way to guarantee anything interesting about a piece of software, and that includes whether it works properly under every input. You can verify that it works with "typical" inputs, but there will always be some set of boundary conditions that you couldn't possibly have known to check on day one."
You can put it any way you want, since I already accepted that and asked "so what?"
You are arguing that you can't deliver flawless software by day zero (which I alredy accepted) as an excuse to not correct the flaws once they appear (which is what I make a point of).
You are, again, rationalizing.
"With cars, it's posible. With complex software it isn't. There's a reason for that."
No, with cars isn't possible either. Every major brand has recalls and maintenance programs for that very reason. The difference is that respectable brands will launch a maintenance program for a detected flaw even if it is ten years down the road and customers will enrage and go for a class action if they don't.
And cars, being physical objects will have wearing parts and, again, people won't accept a "buy a newer model" answer from the vendor ten, fifteen or even more years later when going for a replacement.
"Look up Rice's Theorem. Or work on a major software project. It goes way beyond unfair to expect a complex software system to "just work as it should" - it's mathematically impossible to make sure it does."
No problem with that. So the software doesn't work as it should when shipped? Ok. But that's not the point: I was not talking about the software not being ready when shipped but the vendor's negative to correct it. Is it ten years down the road when I step into a broken part of the product? so what?
"supporting every single ancient version just because one guy somewhere might be using it would take man-hours away"
No, no, and one thousand times no. It is not taking away hours from anywhere since your software is broken. The fact that you delivered broken software works in fact the other way around: you were allowed to take hours away to your delivery date and you are allowed to only recover them afterwards as people stump in the bugs and the need arises.
"Furthermore, the older a version of a program gets, the more of its devs switch jobs, retire, etc."
I see... so, again, what? Taking your own words, look up Rice's Theorem: you knew all that the very day you shipped the product and still you didn't plan for it? It is the vendor's problem, don't try to make it into a customer's one.
You see... the software business is in pathetic shape, we accept quality levels that would ashame any other industry and still we racionalice the statu quo to make it more palatable instead of taking professional pride into making it better.
"In-place upgrades are one thing, and they're great until one goes belly-u"
As I already told, the machine I'm writing this from was originally installed about ten years ago and upgraded in place since then, despite of the fact that, by now, it shares not a single piece of the original hardware.
In fact, in the last almost 20 years (wow, time really goes by!) I don't remember having an in-place upgrade going so bad that I couldn't recover it, and I'm talking hundreds, probably thousands of machines even working remotely on a different continent in all these years.
I'm sure that all those systems being of the Debian Stable flavour has something to do with my sucess rate.
"That may sound funny to you guys [...] Eventualy we found two servers standing next to each other, underneath a pile of cardboard boxes and rolls of toilet paper, in the building supervisors storage cupboard, both running netware 2.15 ( it was early nineeties). Both with an uptime of more than two years."
Forgetting the issue about no backups, I don't find it funny but sad: it just shows the utterly lame situation of IT the fact that something like this comes to a surprise instead of being the norm.
"know that sounds like cynical marketroidism, but sometimes you do need to do that to wean people off some hideously ancient version they're still running on an old 386 under Netware 3.1 bricked into a wall next to the second floor men's toilet."
Why do you think those people are running "some hideously ancient version they're still running on an old 386 under Netware 3.1 bricked into a wall next to the second floor men's toilet"? Do you think it's in order to upset your tech department or it might be because it does what it needs to do so if it's not broken why should I need to fix it?
To add insult to injury, remember you would have no problem supporting ancient versions of your software if there were no bugs to fix on it so what you really are doing is failing to provide the customer with a product that just works as it should without broken parts.
And you think it only "sounds" like cynical marketroidism? It *is* cynical marketroidism.
"Conclusion: I need an desktop operating system that is more deterministic in behavior."
Conclusion: you need an desktop hardware that properly makes public its spec and/or provides drivers for more than just a single operating system.
Somehow I managed to do it for the last fifteen years and more.
"Oh and you need linux support for all the hardware in your machine."
Are you implying Windows doesn't need support for all the hardaware in your machine? Seems a bit weird.
"Unfortunately the only technique I ever found (and I've forgotten what it was at this point) generated a text file listing *every* package installed on the machine"
Unfortunately I fail to see where's the problem.
"a list nigh guaranteed to bork a machine if I tried to import it all on a different OS version"
Not my experience.
Now, my experience:
1) Debian-based: I don't reinstall that often (now that I remember, my current setup goes in time about 10 years or maybe more).
2) Debian-based when cloning a machine: when it's been the same release, no problem at all. When the receptor is a different version (newer) I installed a minimal system and then applied the package list. It might fail on some package disappearing or changing names (usually only a few) and then it's a matter to see what failed and act accordingly. Worst case scenario, I had to extract a list of the (partial) setup on the new machine and diff old/new.
3) Red-Hat based: yes, they are not so great at upgrading in place so I had to resort to the trick in point two. It was a bit longer and required more than one iteration but far from a drama.
"And good luck sorting out the 10% of user software from the umpteen dozen pages of semi-cryptically named packages."
From time to time (I mean months or even years, here) I spend no more than an hour looking at the installed package list. I know what most of the packages do, for the minority I don't know, I read its description as provided by the package manager. If still no clue, I try to unistall it and see what reverse-dependencies are going to be unistalled, which always made clear what was happening. Not a big problem either.
Oh! by the way, a few seconds of google search showed me how to list manually installed packages both for debian-based and redhat-based systems so it seems your concern was not so much a problem even for you as to expend even a minute looking for a solution.
"So even if I managed to get my malware on a machine and then somehow got the sensitive data onto some sort of external media, I still don't have anything useful."
In one acronym: DoS.
"the poster is paranoid and said that offsite was no longer under his complete control."
Any sysadmin will tell you that being paranoid is really a good thing, but that you need to be paranoid about the proper things. He is right about thinking anything not under his control will be under control of the one taking care of it.
So what if it is not under his control?
* He won't be able to recover when need arises: make sure you have more than one copy under different stewardship and test access from time to time.
* Stewardess will gain access to the contents to see/change them: cypher & checksum them and see point above to safeward the keys.
"he said he wants something less likely to survive a fire and stay onsite."
And I want round nails going softly on square pegs. Sorry, it doesn't work that way.
"There exist no simple system where you split the data in two parts which you need to combine to get the original copy?"
You are aware this way you are doubling your chances of losing data, while this man's attempt was to enhance his chances to preserve it, right?
"Offsite, or fireproof stuff. Your choice."
No, fireproof is no substitute. If you really value your data, multiple copies, at least one of them off site is the only way to go.
But, now we are talking about fireproof... that's not an absolute concept. The fireproof is rated for temperature outside, max temperature inside (or delta from outside) and time to stand it. First aka_bigred has to know is the rating of his vault: any support that can stand the internal temperature rate is valid; if the fire goes outside the rating, think of it as lost (you might be lucky though). I can attest recovering data from DAT tapes on vaults exposed around the limit of its rate.
"German? When was that?
Reply to This"
Are you trolling or asking in good faith?
In case it's the lattest, go please check what was the language science, both pure and applied, and engineering was written on along the second half of XIX century up to World War II.
"Why do the policiians not realize that the tools they are giving can and will be misused"
They fully know the tools will be misused. It's only they believe they can misuse them for their benefit.
"and that those same politicians are very likely to be the targets of that misuse?"
See above.
"First, this is not an imaging system, it's an install system which installs mainly Debian based distributions, based on Fully Automatic Installation (fai-project.org)."
How is this different, then, to Debian Edu? (forget about the fact of "Edu" on its name).
It also aims for a centralized Debian environment, imaging system, centralized configurations, etc. and it's, of course, since it's been in development for some few years, much more mature than your project.
""Don't worry, no BjÃrgen KjÃrgen; it's all in English."
Nobody outside your psicotic circles worries about the richness of humanity having more languages than just English."
I do.
It could probably been said in a more "politically correct" way and, me myself being Spanish, have my own concerns about English being the "common trade" language of the world (as it has been French, German, Spanish, Latin... in the past), but I applaud the project being set in English instead of Finn, since it'll reach a greater audience (me, for one). Using English is not so Americans can benefit of it, but in order for everybody to do so.
"The plan with this system is to offer a number of different ways to manage an infrastructure and FAI is one, preseeding is another, the foreman could be a third"
Remember the old saying "He that too much embraces, holds little."
Despite of the risk of failing in your choosings (I for one have concerns on your choice on FAI), this is a project that is basically based on taking third party pieces and massaging and gluing to convince them to work together. Therefore I think, it's OK for the project to be strongly opinionated on how things need to be done, even more if the people working on it have the acumen and experience to (at least in general) choose the right tools and make them work together in a loosly coupled and modular way so each module can be exchanged for different ones.
Being said that, it's also important to understand that it is probably impossible to find a single solution that fits any environment, so having different goals for different scenarios is also OK. In this regard, I remember an old Samba tutorial: they didn't set a single environment, but they went (more or less) deploying for a short office, then for a bigger office with branches, then for a big corporation with multiple divisions and mergers. While they built it so each tutorial built on the knowledge from the previous one, each had its own worthy differences.
All in all, an interesting project, which I hope the best luck for.
"What I'm curious about is how will different algorithms from different manufacturers all react to each other?"
Like in "I'll try not to crash into anything" and then the competing brand goes with "I'll crash into everything that moves around"? Please, show me you have think of it at least for a few seconds offering a detailed example of your scenario.
"how does it know when the brakes have worn out?"
Doesn't your car have an indicator of braking pads' end of life? Mine has, and it's 15 years old.
"Is the onus on the car or the owner at that point?"
The onus is never on a thing but on a legal person. Cars are things, not legal persons.
"Will the car just refuse to turn on if it senses that work needs to be done?"
This is exactly what most cars already do, again no need to go autonomous for that.