[openbeos] Re: Updating OSes bit by bit

  • From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 24 May 2004 15:45:13 -0400

AFA source based patching - like I said - this is a distro related issue. I 
don't personally have any plans to build a system that does source based 
patching. Be didn't and I don't see that it is a huge win. That isn't to say 
that SOMEONE can't. It just isn't me, nor will I assign it to someone. 

AFA testing - I never said that testing is a complete replacement for patching 
or that we all write perfect code. As Dijkstra once said, testing can't show 
the absence of bugs. But did you ever notice that BeOS needed a lot fewer 
patches than other operating systems? Testing can reduce the number of patches. 
So can betas. By the time the OS hits "real" end users, it should be of such 
quality that you shouldn't need to install half a gig of patches to make it 
work. Look at the patches that Linux (stable branch) has. Most of them are 
tiny, obscure security holes that are issues only for servers. That is the 
level of quality that I hope for. That functionality works and that if there 
are issues, they have to be exploited explicitly and deliberately. That most of 
the bugs that are found are cases where we can fix it in the next release in 
good conscience. 


On 2004-05-24 at 15:28:58 [-0400], Plüss Roland wrote:
> @ Linus:
> you got point there. the thing here is that you can drive linux in fact the 
> way you want. i'm driving linux the LFS way meaning i completly compile my 
> system from scratch and only source based stuff gets on it. this is the hard 
> way but a satisfactory one too. for those who still want the power there is 
> gentoo automating the process. if you only can say: "install me this" and the 
> os downloads, compiles and installs the sources itself it's not really a 
> hazzle for the user. but this requires the os to implement this facility in 
> the system structure (in obos case as a server, kinda like the package 
> utility already there, only at source level). so there could be a layer above 
> the source which hides it or shows it to the user depending on his taste.
> @ Michael:
> "Obviously Roland knows, understands and likes these things." :=) obviously 
> i'm a coder and thus like very much fiddeling with the make tripple: tar 
> -xvjf ... ; make; make intall... LOL anyways... i point up to the reply to 
> Linus: there is a way to deal with it. it just is a bit more tricky than 
> simply use binary install. beos apps are indeed much smaller. has been one of 
> the first things i noticed back then in beos r5 times. the main problem here 
> is also that in a windows system so many components are linked in a cubersome 
> way that patching one usually unrolls a rat tail which causes an ackward lot 
> of subsequent patches needed. beos has the chance to be different... please 
> don't mess it up guys ;=)
> you stated here you gonna test this heavily to avoid the need for patching. i 
> donno what to say but... i hope you've been just kidding. there's nothing 
> like the perfect code and especially in a os where lots of components speak 
> together and the user is the most unstable factor one can imagine (DAU does 
> not exist for nothing) that a simple hidden bug can greatly cause headaches. 
> i would not rely on the dev team beeing that perfect to not letting slip in a 
> mean bug. i expect you to deliver much more sophisticate code than it is in 
> linux but do not think that the possibility for patching does not have to be 
> dealt with in advance. i definitly not want to see OBOS crank up because once 
> upon the time a really mean bug hits daylight without the devers having taken 
> into account this possibility.
> just my two cents.
> so don't get me wrong. the dev team is good, real good but you know... it is 
> the small arrow at the right place that fells the giant ;=)
> Roland

Other related posts: