Dragonflybsd Presentation

[EM1897 at aol.com]

In a message dated 2/22/2005 12:17:48 PM Eastern Standard Time, Bill Hacker <wbh at xxxxxxxxxxxxx> writes:

>EM1897 at xxxxxxx wrote:
>
>> In a message dated 2/22/2005 10:37:12 AM Eastern Standard Time, Bill Hacker <wbh at xxxxxxxxxxxxx> writes:
>> 
>> 
>>>Eduardo Tongson wrote:
>>>
>>>
>>>>UPDATED
>>>>
>>>>http://spunge.org/~glassjaw/dfly.pdf
>>>>size: 133337 bytes
>>>>
>>>>After all the suggestions, corrections and comments
>>>>I hope I didn't fuct up somewhere.
>>>>but as usual corrections are very welcome
>>>>
>>>>DragonFlyBSD community thank you very much...
>>>>
>>>>
>>>>--
>>>>Eduardo Tongson     
>> 
>> [snip]
>> 
>>>Page 11.
>>>
>>>I *shudder* when I see the word 'distro', as it implies Linanarchy - 
>>>where items seem to be collected on the whim of any of 200+ entities.
>>>
>>>The BSD's have traditionally been more of a 'whole' system, where 
>>>everything needed is there, tested at soem point in time, and proven to 
>>>work together.
>>>
>>>Despite code changes and a tilt toward binary vs source dissemination, I 
>>>have seen no departure from that proven model.
>>>
>>>Can a word be found that better reflects BSD-style cohesiveness? 
>>>'Releases' comes first to my mind....
>> 
>> 
>> I think you are missing the point of the separation of
>> kernel and "system". A HUGE advantage LINUX has is the
>> ability to pop in virtually any version kernel without
>> having to change the "distribution". 
>
>I suppose it doesn't work any worse <g>
>
>> While an artifact
>> might be entrepreneurial companies seeing an opportunity
>> to do things a bit differently, thus creating variants 
>> that you may not like, it is a major pitfall of the BSDs.
>> Upgrading entire systems in the field to bump your kernel
>> up is a big issue.
>
>Horsehit.
>
>> With LINUX you only have to upgrade
>> the pieces that you care about, and the kernel. A "release"
>> should only include things that change, not all new
>> binaries.
>>
>
>Yep. That's a production BSD box, mate.
>
>> 
>
>A hobbyist or developer sitting right next to the box all day, or a 
>'newbie' uisng *N*X as a personal worksation might buy your viewpoint. 
>Servers are another matter entirely.
>
>And I am not a newbie.  Monroe-matic, IBM unit-record, 401, 701, WE M33 
>(analog), AN/FSQ-7, AN/GSA-51, GA-SPC-12, Varian Data 520i, 620i, 
>Honeywell, Data General, DEC, Univac, Singer, Friden, SDS-930, many, 
>many IBM, HP, various 6502, 8080, Z-80, 6809, and most anything since on 
>OSI-48, S-100, ISA, EISA, PCIMG, PCI, PISA, VME and Multibus at one time 
>or another...

Its interesting, because from my perspective you have it
exactly backwards. If your box is in your lab or on a high speed net AND you have someone competent enough around to figure it out if something fails, then the pain of doing it
"your way" is fine. But consider that the box is in romania
where they have a T1 line into the COUNTRY, manned by a marginal tech who probably doesn't know un*x at all. First of all,  it takes all day to download a dist, and an ISP isnt willing to take his machine down for an hour to rebuild all his binaries (and a machine running at 70% interrupt usage takes a LONG time to do a buildworld while losing packets like crazy, so leaving it up isnt really an option). Being able to just deliver a kernel is a big advantage. 

As for your disdain for LINUX, I didnt say it was good
or better or anything of the sort. I just said that 
the separation of kernel and binaries has significant
advantages.