Haiku Updater

SigmaNunki · September 9, 2004, 4:31am

togs_01 wrote:

umccullough, if the step was taken to have an app that polls a feed every 24 hours or so, why not just go one step further. Instead of a URL that requires the PEBKAC's intervention to manually download, why not have the user say "Yes, install that, no not that one, that one." and let it download and patch. That's what I'm proposing.

The Mac OS X updater is a perfect example of this. It periodically checks for updates and when there is one/are some, it pops up a window with a list with check boxes. Highlight one, it gives a short description. The user then selects what (s)he wants and it goes to work downloading and installing. And there is *always* one marked "security update".

Do I want my security update promptly, yes. Do I want to have to wait for the next release package to have it, NO. That is unless people want Windows like security, but I’d rather think that people here are smarter than that.

And by the way, according to Theo (OBSD founder, programer, etc) has stated that it takes on average 1 hr to find, fix, patch and make that patch availible to fix a bug, expliotable or not, given a good description of the problem. I’ll say it again, 1 hr. Do I want to wait a month for the next pack (or even a day for that matter) when it’s availible now, NO.

togs_01 wrote:

If you give people an option to avoid doing something that wasn't their idea - or "to do it later", ninety-nine percent of the time, they don't do it later. Just look at all the people who got caught by various viruses and worms (WinXP example) that could've been fixed (in at least one case) by applying a patch available six months ago. User decision is bad. User training is good. Automation, even better. I myself scrutinize Windows patches, and install most of them. I'm avoiding the "downgrade" to SP2, though.

People are lazy, ain't it true.

tb100 · September 10, 2004, 3:41pm

I agree with MYOB that I don’t want millions of seperate patches for every issue, that some users will have and some won’t, leading to the inevitable incompatiblity issues and things.

I see a Be-type release model (the 5.0.1 and 5.0.3 updates). If and when security holes are discovered and fixed, hotfixes would probably be useful too.

I think it would be useful to have a small app to check for these updates and automatically offer to download and install them. They should of course also just be available on the website for people like MYOB who may not have a simple way for updater type apps to access stuff on the net.

SN, your thing about recompiling bits of BSD to fix a simple issue will also apply to Haiku - in that you can grab the source off CVS and recompile bits if you want. It’s impossible to do this simply for a user though, as a change that fixes the bug you’re annoyed by may also require some other changes not in the base release - the update point releases (5.0.1 etc) would be tested as a whole system to ensure it all worked together with no issues. Normal users should stick with those official point releases as they should be considered “stable”.

Simon

SigmaNunki · September 11, 2004, 6:23am

tb100 wrote:

SN, your thing about recompiling bits of BSD to fix a simple issue will also apply to Haiku - in that you can grab the source off CVS and recompile bits if you want. It's impossible to do this simply for a user though, as a change that fixes the bug you're annoyed by may also require some other changes not in the base release - the update point releases (5.0.1 etc) would be tested as a whole system to ensure it all worked together with no issues. Normal users should stick with those official point releases as they should be considered "stable".

I don't believe that I said that a normal user would be able to do this. In fact I expect them not to be able to do it, that's why I'm for the updater.

I only stated that it is the way that OBSD does it (which is a primarily techie OS). I believe that I stated that Mac OS X has it right with there updater. It’s a nice, easy efficient way for a user to update there system.

But if the patch didn’t provide all nessassary alterations for the prior release then it isn’t a good patch now is it. Your point is quite moot there as a proper patch would include such changes. And if the team responsible for this doesn’t check to make sure then they aren’t doing there job no are they.

And OBSD has 3 tags in there CVS:

Release
Patch branch
Current

What I am proposing is that the update keep the user at the level of the patch branch. This would mean that the user would have all nessasary bug fixes. And why would it matter if there are a lot of them? It is after all automated.

eisman · November 11, 2004, 6:58am

It would be good to have an OS-updater for Haiku.
But then there have to be setup mirrors, I don’t think that this will be a problem.

Something like urpmi (Mandrake) or apt-get (debian) would be nice, gui will be also nice.
but commandlines will do also.

remi_grumeau · November 12, 2004, 10:20am

Quote:

Something like urpmi (Mandrake) or apt-get (debian) would be nice, gui will be also nice. but commandlines will do also.

Commandlines ??? He men, i’m not using BeOS to type things in Terminal !!!
That’s mainly why i love BeOS, no commadline to type down. I don’t want it to be a Linux like.

The Yab language shown at last BeGesitert is a very good way to me to delete commandlines from a everyday user experience. If you need muckups for a GUI, just ask, i would be very happy to help but please, no commandline tools !!!

Mr.Jones · November 13, 2004, 1:01am

MYOB > Your idea about solving hotfixes with seldomreleased “servicepacks” R1, R2 and so on is likely cause a lot of frustration for users connected 24/7 (well… 24 hours, 7 days a week). I would definitely want a hotfix immediately. There is no problem in having an updater IF the hotfixes/bugfixes etc. are coded properly.And the risk for breaking the API is in no way smaller with “servicepacks”, just look at SP2 for WinXP (I feel sorry for those who have to use XP… I run Win2K and FC2 as dualboot, with linux as default OS - since I can’t run BEOS on a duron anyway )

I don’t see the problems with dependencies (on Haiku that is), after all I’ve used windoze for years (against my will… couldn’t get OS/2 running… and you know… the games… the primary reason to have a Windoze system installed… … productivity belongs to another platform, be it Haiku (in the future) or linux-distros or mac or whatever… anything but windoze for productivity), but in Windows you often have to install app#2 if you want app#1 to work. Many apps wont work without IE and don’t forget the whole problem with “can I uninstall this DLL or not?? oh I don’t know… I guess I have to let it be…” - I mean… Just look at the mess in any Windoze system folder…

As long as the setup-system is created in a clever way dependencies wont be a problem.

Anyway… the updater spoken of in this thread is apparently meant only for OS-updating and backwordscompatibility shouldn’t be a problem, unless we are talking about a severe bug, in which case the system would probably be unbootable without the fix, why nobody has to worry about dependencies and backwordscompatiblity when it comes to OS-updates.

My idea of a update-solution would be something like synaptic for FC2. (Those who don’t know synaptic I can say it’s a frontend for apt-get…)

Well… perhaps I should explain it differently.

The user should have an update-client.
This update-client connects to the update-server.
The client sends information about hardware and software to the server.
The server sends information back regarding available updates.
The user chooses which updates to download and/or install.
The client downloads updates from the server.
The client may install the updates (or this can be done manually).

This way of doing it should be firewall-friendly. At least for software firewalls installed at the user’s own pc.

It shouldn’t be exactly like synaptic since it has a less-intuitive GUI… or perhaps I should say it isn’t too easy to understand.

The system-updater should be pretty configurable. E.g. have some advanced settings, where the user could add more servers so all updates (incl. updating and/or installing of 3rd party apps from other servers) could be done thru this updater. However, as a default only the OS-update-server should be available. Other servers should only be added by the user.

Perhaps an API could be/should be created for this purpose? I mean an InstallApplication-something-API?

In case this (in Haiku R2) should require root-status / Admin-rights, then this could be enabled pretty much as in linux (-su root or in synaptic just write password in the popup-window when you try to update your system while being logged on as normal user). In windows you have to log off as user and log on as admin to update your system - this is bothersome for most people, right?

Damn… I shouldn’t have had access to the forum, I just do looooong entries…

BTW: Thanks Kurtis, for activating my profile … I’m in!!! I’m in!!!

SigmaNunki · November 13, 2004, 3:31am

Mr.Jones wrote:

since I can't run BEOS on a duron anyway :( )

Um, I run BeOS and I have a Duron.

Mr.Jones · November 13, 2004, 1:35pm

SigmaNunki wrote:

Mr.Jones wrote:
since I can't run BEOS on a duron anyway :( )
Um, I run BeOS and I have a Duron.

Nice to know … Can anyone recommend a cheap but good multiCPU-motherboard for Socket A (Notice: I’m looking at Duron MP (all those with FSB at 266 mHz or more))

Mr.Jones · November 13, 2004, 1:40pm

BTW: Forgot to mention that the Updater ought to have a resume-function, in case something went wrong during download. Download from multiple servers (e.g. downloading from update-server AND mirror-sites) should also be supported, as well as downloading from other clients downloading these updates (e.g. something like BitTorrent).

Anyway… it looks like I’m gonna be 30 before Haiku R2 is released… Hurry dudes :roll:

myob · November 13, 2004, 3:08pm

SigmaNunki wrote:

Mr.Jones wrote:
since I can't run BEOS on a duron anyway :( )
Um, I run BeOS and I have a Duron.

I also ran on a Duron for a year or so.

SigmaNunki · November 13, 2004, 4:38pm

Mr.Jones wrote:

BTW: Forgot to mention that the Updater ought to have a resume-function, in case something went wrong during download. Download from multiple servers (e.g. downloading from update-server AND mirror-sites)

Cool idea, if there are mirrors or even if they are required. Since the Haiku's population is so small it probably won't be necessary.

Perhaps something like the program keeps a list of servers only aquired from the main server. Then it checks for updates and selects a random site 1 to download update 1 from, then selects random site 2 (not random site 1) to download update 2 from, and so on.

Once the download completes, the integrity check could be a MD5 or SHA1 to make sure nothing bad happened along the way. These should be aquired only from the main server to make sure any funny business is avoided. Since they are quite small (128 and 160 bit strings respectively) this would not provide a bandwidth issue.

Mr.Jones wrote:

as well as downloading from other clients downloading these updates (e.g. something like BitTorrent).

This, although a good idea in theory, would just add needless complication to the issue. Not to mention that this project would be reinventing the wheel.

If something like BitTorrent was used, it’d just as well be BitTorrent. But since the user base is so small it doesn’t make sense to have such a large scale network going.

Plus the server will have to keep up old updates for people reinstalling, installing for the first time, etc. It’d just be a matter of time before the server would have to have a few hundred ports open. Security issues abound.

It’s best to keep such things simple.

Mr.Jones · November 13, 2004, 5:14pm

SigmaNunki wrote:

Mr.Jones wrote:
BTW: Forgot to mention that the Updater ought to have a resume-function, in case something went wrong during download. Download from multiple servers (e.g. downloading from update-server AND mirror-sites)
Cool idea, if there are mirrors or even if they are required. Since the Haiku's population is so small it probably won't be necessary.
Perhaps something like the program keeps a list of servers only aquired from the main server. Then it checks for updates and selects a random site 1 to download update 1 from, then selects random site 2 (not random site 1) to download update 2 from, and so on.

Once the download completes, the integrity check could be a MD5 or SHA1 to make sure nothing bad happened along the way. These should be aquired only from the main server to make sure any funny business is avoided. Since they are quite small (128 and 160 bit strings respectively) this would not provide a bandwidth issue.

Nice thinking there … me like … Sooner or later mirrors will be needed - in 10 years from now we are likely to have a userbase of 10^6 users or more … Anyway, it’s very important with a resume-function and a checksum function to avoid the kind of problems which is common with synaptic in Fedora Core 2 (incomplete installs cannot be resumed or installed again - pisses me off :evil: ).

SigmaNunki wrote:

Mr.Jones wrote:
as well as downloading from other clients downloading these updates (e.g. something like BitTorrent).
This, although a good idea in theory, would just add needless complication to the issue. Not to mention that this project would be reinventing the wheel.
If something like BitTorrent was used, it’d just as well be BitTorrent. But since the user base is so small it doesn’t make sense to have such a large scale network going.

Plus the server will have to keep up old updates for people reinstalling, installing for the first time, etc. It’d just be a matter of time before the server would have to have a few hundred ports open. Security issues abound.

It’s best to keep such things simple.

Yeah… oops … multiple downloads from server and mirrors will probably do it - at least for the first couple of years.

But it would reduce bandwidth traffic seen from serverside. But yeah… whatever

eisman · November 20, 2004, 6:47pm

beosfrance wrote:

Quote:
Something like urpmi (Mandrake) or apt-get (debian) would be nice, gui will be also nice. but commandlines will do also.

Commandlines ??? He men, i’m not using BeOS to type things in Terminal !!!
That’s mainly why i love BeOS, no commadline to type down. I don’t want it to be a Linux like.

The Yab language shown at last BeGesitert is a very good way to me to delete commandlines from a everyday user experience. If you need muckups for a GUI, just ask, i would be very happy to help but please, no commandline tools !!!

It was more a way to show how it can be done, Mandrake has a gui for it, but also a commandline, the choice is yours to make. But it would be great to have a OS-updater tool, which ofcourse would be a gui one in Haiku.

SigmaNunki · November 20, 2004, 11:17pm

Mr.Jones wrote:

Anyway, it's very important with a resume-function and a checksum function to avoid the kind of problems which is common with synaptic in Fedora Core 2 (incomplete installs cannot be resumed or installed again - pisses me off :evil: ).

SHA1 or MD5 should be good enough. That's what OBSD uses :)

Mr.Jones wrote:

Yeah.. oops :P ... multiple downloads from server and mirrors will probably do it - at least for the first couple of years.
But it would reduce bandwidth traffic seen from serverside. But yeah… whatever

Well, if the users using Haiku gets to a range in the millions I’d say that there’d be enough mirrors to handle the load.

One could get a mirror list from the main server and randomly choose a server for each download. That’d spread the load and have a simple model for the updater. Plus, people aren’t going to be downloading updates on a daily basis. We should have more confidence in the devs that that

Mr.Jones · November 22, 2004, 12:16am

SigmaNunki wrote:

SHA1 or MD5 should be good enough. That's what OBSD uses :)

Well… something like that would do it, yes.

Quote:

Well, if the users using Haiku gets to a range in the millions I'd say that there'd be enough mirrors to handle the load.

It’s not if, but when… Haiku WILL prevail

But yeah… there’ll be enough mirrors without a doubt

Quote:

One could get a mirror list from the main server and randomly choose a server for each download. That'd spread the load :) and have a simple model for the updater. Plus, people aren't going to be downloading updates on a daily basis. We should have more confidence in the devs that that ;)

Yeeesss… exactly the idea I had in mind.

And yeah… nobody can code as bad as the microserfs… And I’m convinced the devs have some selfesteem to protect, so we’ll see some niiiice code that’ll make us all happy

computrius · February 11, 2005, 3:38pm

there is one thing everyone is forgetting: something to look forward to. A tiny update installed transparently (automatically) goes un-noticed for the most part, and is un-exciting… If its NOT automated however, you tend to get more big updates with very noticable changes. This gives people something to look forward to, it gives people something to talk about I dont know about everyone else, but I would rather have the big update, and have something to look forward to than periodic boring automatic small insignificant changes

SigmaNunki · February 12, 2005, 12:17am

computrius wrote:

there is one thing everyone is forgetting: something to look forward to. A tiny update installed transparently (automatically) goes un-noticed for the most part, and is un-exciting... If its NOT automated however, you tend to get more big updates with very noticable changes. This gives people something to look forward to, it gives people something to talk about :) I dont know about everyone else, but I would rather have the big update, and have something to look forward to than periodic boring automatic small insignificant changes

Then you look forward to unaddressed security issues for good lengths of time so that you can have your one big update once in awhile? Well, I'll tell you that your excitement need not be before the update then, but might come in the form of "Hm, my system won't boot."

And no-one is talking about some transparent automatic update. That would be irresponsible to do. What if someone doesn’t want a certain update or part of one because it might (would) mess up something else that they have on there system? transparency = no choice, and no-one here is proposing that.

What I(/we? don’t want to speak for everybody here) are proposing is something like the OSX updater that regularly checks (interval is user defined) for updates and then informs the user of them. It is then up to the user to decide if (s)he wants to install one or more of them.

Also, no-one (I think) is proposing that this is for updating Haiku’s feature set. It is mainly going to be for bug/security/etc fixes, not for new features. New features are for new versions of the OS, which would come as an upgrade package… hopefully.

ie OBSD releases bug fixes when they are found, but offers new versions every 6 months.

My opinion is to follow a similar, more user freindly approach, like the OSX updater.

Mr.Jones · February 27, 2005, 6:37am

SigmaNunki, I’ll second you on that

When a security fix or bug fix is available, the user should be notified about the(se) update(s) - and then the user can decide whether or not to download (with or without automatic installation). I’d recommend updating any available security fix, just in case somebody should think differently

This approach is used by RedHat and (sometimes) Microsoft and several other companies and several linux-distroes. Unnotified updates - occasionally done by microsoft on xp - is a very big “No No”. Never force the user :evil:

The exact UI is less important to me, as long as it works properly :lol:

ModeenF · February 27, 2005, 8:09am

I hade a thought abut an updater
I don’t know if this exist but…
How about changing file atributes so that the file a have version number and creator?
You can then se prity fast what vesion it has in the tracker (and use this in an updat program). This may slowdown the system but is it not posible to not read this if it’s not chosen?

An updater program would also make it easier for tester to test a system.
But then it must have support for alpha/beta installations. So that when I want to test Haiku I can chose Beta packages in the installer

hm It was prity hard to write this in Zeta’s Firefox. Some times letter was missing:).

myob · February 27, 2005, 2:24pm

ModeenF wrote:

I hade a thought abut an updater I don't know if this exist but.. How about changing file atributes so that the file a have version number and creator? You can then se prity fast what vesion it has in the tracker (and use this in an updat program). This may slowdown the system but is it not posible to not read this if it's not chosen?
An updater program would also make it easier for tester to test a system.
But then it must have support for alpha/beta installations. So that when I want to test Haiku I can chose Beta packages in the installer

hm It was prity hard to write this in Zeta’s Firefox. Some times letter was missing:).

Executables already have version number and copyright info and always have…