I still have a mail in the pipeline but I just wanted to respond here with short comments. On Sun, 27 Sep 2015, Anton Aylward wrote:
On 09/27/2015 06:34 PM, Linda Walsh wrote:
Anton Aylward wrote:
On 09/27/2015 03:53 AM, Linda Walsh wrote: Linda, you've made a generalization that isn't valid.
Not everyone uses the same backup strategy.
Wrong and that's not what I do.
I am NOT wrong when I say "Not everyone uses the same backup strategy."
She meant the first statement, not the second. Poor quoting.
Not so primitive -- incremental backups aren't supported by many tars.
They only need to be supported by ONE version of tar its its the version that comes with Linux, with Suse, RH, Mageia. I don't know about the non-RPM systems like ubuntu.
Incremental tar is pretty primitive. You need a solution wrapped around it, a suite of scripts (or even a single script) to make good use of it. Tar is also rather primitive by default in ways of knowing the progress of your backup. I tried using some SIG feature (signal) but failed thus far. Rsync is lightyears ahead in that regard and that's really only a small step. Actually I was doing just that: writing a tar script (combined with LVM snapshot) in a nice user interface (just readline menus) but I quit doing it for now. I also wrote a script that can extract the dumps from the tar and compare it to an increment tar and then show you the differences between the two (additions, removals, updates) -- something that is not supported or offered by default. Forgot to upload it, it would have been on github by now.
Often 'efficiency' is confused with speed. if I want speed I'd get more memory and faster CPU with more cores, a faster SSD, or perhaps not even use Linux!
What she means is that poor designs cause more work, the way I have been saying. If you spend 30 hours designing something and then 60 building it, you will in the end have a vastly more efficient system than if you spend 2 hours designing it (or not even) and then 30 building it. The reason is because the better system is going to save you time. Often software requires an investment, it pays off in the long run. Perhaps "better" is subjective as you have been indicating. In that case a more objective statement would be that in general the more time you spend in advance, the more time you will save later on. Is that system better? It is a more efficient way of spending time. It is not better. It just saves time. If you have no need for these time savings then the system might not be better (if you are having to be the one building it). Because in that case the investment might not pay off. Typically for personal use the investment/payoff balance is different. As you have indicated. But the more people work together, or products are created that follow designs that are more elegant but require more time to build, the more in the end time is used more efficiently and also more effectively across the board. This is then what we call "good design" or "better design". But if these solutions do not exist and you need something working in 2 days (or less), then obviously it won't be "better" to start designing a long-term system. I mean, I agree with that Anton. The reason I do so much scripting myself is because I sense and see that the ready made solutions are often stuff or things I disagree with and that take time learning. Better then to use the 'primitive' tools that I already know, and I can whip up something myself faster than it takes to learn the tools I disagree with. And the benefit of that is that: a) I get something that is perfect onto me, and b) I become more adept at using what is already there, including libraries I write myself for these purposes.
"Efficient" can also mean maintainable, sometimes under adverse conditions by poorly trained people. The DC9 has a reputation of being serviceable in jungle considerations with the most primitive of machine shops making spare parts.
And you see (perhaps) in Himalayan and Turkistan countries that they all use vehicles that are older and more robust and more serviceable in adverse weather conditions. No fancy modern cars with electronic systems that break down and are not repairable by the common mechanic. They are probably not even common mechanics, they are experts. People in those or such regions need to be able to fix everything they use. But that doesn't really negates, but rather informs or reinforces the fact that proper thinking in advance of construction may yield rewards later on. Just think of any computer game. You can't design or build a computer game in incremental steps. It's gotta have ONE release. It needs to be thought out in advance, completely designed, and then built. There is no time or even a reason to do it in any other way.
its no a poor design, its either adequate or not.
I keep saying Context is Everything and it is. My context is not yours.
If "poor" is subjective and relates to good/bad/better/worse, then perhaps you might be right. But the word is used in a sense of an implicit context. It is assumed (and rightly so, I believe) that the needs of many users converge to a single point. Given then, a common interest, or a shared need across many people, we can call one design poor and the other good. But "poor" is less subjective than "good". Poor also means the opposite of rich. Perhaps a car that can only run for 10 miles is adequate to your needs (or at least you think it is) but that doesn't define it as "rich". It is perfectly clear that a car that can instead run a 100 miles would be a much richer design, most likely. Richness is then a measure of complexity and feature-abundance. It is also a meaure of power and operational possibility, ie. the condition of not needing a fundamental redesign to support a higher level function. If you always design incrementally, you may run into a necessity of constantly redesigning your system because you didn't realise beforehand or take into account higher level needs. A richer design is also a simpler design, and because of its simplicity it can do more. It has less obstacles or hindrances embedded in its design. You can say that car that can do a 10 miles is adequate to your needs (at least today) but you might have been mistaken about that and realize that the next day you need it to be able to do 15 miles, and now you have a problem because you need to redesign and rebuild the thing, whereas if you had been less indigent you would be enjoying the fruits of a richer labour. This is what Linda calls poor and rich design, if I may be so bold. It is really a quite general assumption or idea. I don't think many people would disagree with it.
I've designed my system to be able to be quickly backed up or restored using DVDs. Perhaps your multi-terabyte databases would prove inefficient if you tried backing them up in 5G chunks! But in my *context* its quick, easy, and because its not inconvenient, it gets done, so its an efficient /system/.
Context is Everything
Take care that you are not limiting yourself in what you want to do because or just because you feel your current system *should* be good enough for you. This DVD system... one day you may start feeling annoyed by it but you feel it "should" be adequate. 5GB file systems is also a pretty big concession (or even sacrifice, if I may be so) to make. You have basically designed your filesystem/computer setup/structure around the /SIZE of DVDs/. That is VERY odd thing to do. That constitutes to me as "poor" and that is not something subjective. It is relative to other things that are "less poor" but it is still objective even if it is not absolute. In the absolute, everything is all thing. In the absolute, a thing is both poor AND rich. But in relative terms, to me this comes across as 'poor'. Because it requires you to make so much concessions. So just to be quick I will say that context determines good/bad but it does not determine poor/rich. Relation to other designs determines poor/rich. Adequate is related to needs. Needs may change over time. You may also lie to yourself about your needs and accept a lesser solution than you could have had (based on your experience and what is possible to experience). A poor solution may also keep you stuck in a situation where progressively, or increasingly, your needs are not or not longer met. But it can also mean that you have a reason to deny that your solution is poor.
It's the same with many solutions these days -- some through faster processors and more space at solutions to avoid the cost of better design. They get what they pay for.
There you go again, assuming that 'efficient' means 'speed'.
Actually she is saying or appears to be saying that "speed" causes "inefficiency" to be less noticable. That does not mean speed and efficiency are the same thing, although in this case efficiency IS related to the time it costs you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org