rpm experiences [was: Backing up whole system]

[Robert L Cochran]

I entirely agree with Rahul. There are many more tools and choices out 
there now compared to when I started programming in 1981. Back then it 
was just assembler, COBOL, and CICS and a bit of database stuff (also 
IBM style.) Now the list goes on and on. In modern development, you have 
to take into account the many security concerns and the ability to 
rapidly distribute code over the Internet. You can release this morning 
and have hundreds to tens of thousands of users tonight. That is 
changing the entire face of applications development as one's user base 
finds bugs rapidly (and sometimes these are show stoppers) and one's 
code is actively attacked by malware. So approaches to software 
development become ever more complex. They have to be.

Bob



On 05/10/2009 01:32 PM, Rahul Sundaram wrote:
> On 05/10/2009 10:24 PM, Gene Heskett wrote:
>
>    
>>> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
>>>
>>> Rahul
>>>        
>> Which, if printed, is still 29 pages, Rahul.
>>      
>
> Number of pages is a very meaningless metric to decide the scope of
> useful documentation. I have worked as a technical writer and
> determining the usefulness or conciseness of a document is a much harder
> task than simply counting the number of pages. You can shorten the
> number by reducing the size of the font. Would that make it more
> concise, suddenly?
>
> Note that above page can be shortened by excluding information or adding
> more references but it all depends on the audience.
>
>    
>> Clear and Concise writing seems to be a lost art.  There has been 10x more
>> pages written on rpm now, than Kernigan&  Ritchie put in the original C book,
>> but that book, and its successor (I have both) can be used for a demo of how
>> to write clear, concise docs.
>>      
>
> K&R C book is reference material. Hardly a beginner introduction. Ask
> someone who has actually spend time building both RPM and DEB packages,
> which one has been easier and why. Finding a random PDF online and
> blaming the tool is hardly the sensible thing to do.  Simplicity is not
> the same as simple.
>
> Building software is inherently a complex task. Tools can only help so
> far. RPM is only a small part of it. Eventually you will have to learn
> different source code management tools (earlier just cvs. now add git,
> mercurial and more), compiler and other core utilities (sed, awk, perl
> ...), build automation tools (again, these keep increasing - autotools,
> cmake and so on), build system tools and so on. After years, one will
> barely have scratched the surface of the full scope of these.
>
> Rahul
>
>