"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.

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.