Haiku Updater
Something I think would be really handy would be an updater. Perhaps something like Windows Update. As to the repository, maybe you could use the CVS or something - like Debian unstable.
The state that Haiku is currently in, if someone who cares to code an updater app does, couldn't they use a generic user/pass to log into CVS and grab all the changes? I'm not certain how CVS works, but think of it as automating the process.
Later on, when Haiku is at the stage of being a stand-alone Haiku, and not having to use R5 etc, then we could have an unstable branch (CVS) and a stable branch, etc.
Fleshing out the idea a little, I don't think something like this needs to be like apt-get, with thousands of applications, just specifically for system updates. After all, it's a simple process to go to BeBits and grab any app you need.
If BeOS Max ever gets back up, and they decide to do a new version, an app like this would be very handy indeed - pre-installed on Max, making it easy for people to grab the Haiku kits. Alternatively, a release on BeBits or somewhere on the Haiku site would be just as good.
Thoughts?
Cheers,
togs
Comments
Haiku Updater
For the time being, the Build Factory should be enough. You'll find the daily built tar ball of the distro plus the preferences/apps as a package and other stuff like drivers below that as compiled jam packages.
A little script using wget could be handy to automate the updating process.
Later on, with R1, I agree that a Windows Update like app would be useful.
Haiku Updater
Even though it is probably still a bit early, I definitely second the idea for a Haiku updater!
With all the different "flavors" of BeOS installs floating around (Personal Edition, Max, Developer edition, developer tools on top of personal edition, BONE extensions, etc...) it certainly adds a tremendous amount of value to have something that manages this.
Additionally, if I screw up something, it's very nice to say "uh oh, give me the latest system files and be done with it".
Personally, I quite like the control the Debian "apt-get" approach gives you over what you pull in. The "Windows update" interface is arguably more intuitive, but I wish it gave you more ability to "back up" to earlier versions, point to different distribution locations, or other such control.
The 'cygwin' setup approach isn't too bad. It gives a lot of control over the versions of packages but in a more graphical manner than Debian's apt-get. However, cygwin update UI doesn't strike me as very intuitive.
Perhaps Haiku's could be a combination of cygwin flexibility with a simple Haiku/BeOS UI that makes this management easy.
Anyway, sounds like a project that fits in the realm of release management. Have there been discussions on this topic in the past?
Haiku Updater
I think the updating system we were talking about was concerned with how to keep the system up to date, once an installable Haiku is there. Not to install testable components in all the BeOS variants that are floating about.
Since an updating app is considered quite important, the topic keeps cropping up on the mailinglists again and again. Together with a general packaging and un/installing system. Have a look into the OBOS/Haiku Mailinglist Archive. Most of the discussion should be on Glasselevator though. Unfortunately searching those archives is a bit of a drag...
Haiku Updater
My original post was concerning an updater to replace R5 kits with the new Haiku ones - the ones in the Build Factory. This would make it a hell of a lot easier for those of us who can't use CVS. Plus, I think that if the idea and the design stages are started now we could have a fully tested and featured app ready for Haiku R1.
Put it simply: I want an updater to do the work for me. :P
Really, these things are pretty much integral to any OS now. You've got all the portage, apt-get and such tools for your *nixs, Windows Update for Windows, and if there's one for MacOS, I wouldn't be suprised. It also comes back to the "user-friendly" aspect of BeOS. Right now, R5 has a slight bend for a learning curve, it'll be great if one of the harder aspects - keeping updated - is catered for from the first day of Haiku R1. Imagine, a straight line!
Sorry for being such a word smith - you can ignore the whole post except for the single line if you like :)
Haiku Updater
Hey Togs,
An updater would be cool. However something to get you unstable CVS versions of currently in development kits is quite different from the end-user focussed updater that would be included with the first user release of the OS.
And remember Haiku is not like linux - there is only 1 project and 1 homepage. So a few months after R1 there may be a "service pack"-type release that fixes some bugs in all of the Haiku components or whatever. It will not be too much hassle for a user to check the site occasionally and download and run that one update. It would be great it if a little program did the check and download for you, but not strictly vital IMHO. Certainly not vital for R1.
If you can't cope with CVS, there is the build factory. However if you are uncomfortable with code in general, it might be better to wait until the components are stable and mature before attempting to use them. When that happens, a download link to the completed kit is usually placed on the Haiku homepage.
Simon
Haiku Updater
Hey Simon,
I see your point about CVS updates. Unstable code might not be a great thing for 80% of us. Unfortunately, I don't have a box available for Haiku at the moment, otherwise I'd be posting this from BeOS. There's the computer that my brother and sister and I share, but they won't let me stuff around with it.
That said, I still think that even though Haiku is a sole organisation capable of releasing SP updates, how many users would even know, let alone bother to check the homepage? So some sort of updater would still have a place.
To add a little more to the concept, what about some sort of distributed download client like Bit Torrent that can "share" updates? This has obvious benefits on the bandwith of Haiku and for the plethora of us with high speed Internet wouldn't even be noticeable.
Cheers,
togs
Haiku Updater
As I said, togs, have a look into the Glasselevator mailinglist. Updating/packaging/distribution has been discussed in detail before. Also remember that these are R2 features, so you most probably won't find active Haiku developers working on it in earnest yet.
Multiple choices
Whatever the best choice is, I think it would be much better if multiple submissions systems were added. As much as possible in my opinion. There are always people who prefer one way to another. Paypal allows people without a visa card (students or non-us people) to make payments. However some don't like paypal either.
The goal in the end is to allow anyone who wants to make a payment to do so. There are certainly specific payment methods for japan or whatever. Maybe each BUG should suggest a preferred payment system for it's respective country?
Do you really want one of these?
One of the beautiful things about BeOS was/is the fact that you could tell exactly what OS you were running. You can say "R5" and it means something. You need (up to) a couple of pages of text to tell someone what OS you are running under other OSs.
I am not saying that we can't or shouldn't, but let's seriously consider the Be Way, here. If the QA is done well enough, you shouldn't need a system updater.
Re: Do you really want one of these?
Not to look down upon this project (I *do* support it), but this is *never* done "properly". There will always be bugs and some of them will be expliotable. There *does* need to be some sort of system updater for those that don't want to traverse a web page to look for updates every day/week/month/etc. on there own (ie people tend towards lazyness more than activist).
It'd be nice for the end user to have a application that'd do this for them. A nice user friendly application (that Be was known for), that'd make something that could be complicated for some (ie applying patches, etc) easy, which is what Be did.
Plus there is the fact that all modern OS's have such a system ie OBSD does it through CVS, Debian does it through there apt-get (I think it's apt-upgrade), Windows has one and so does Mac OS X. There are others to mention, but if this OS is going to be around then it should provide the basic conveniences that others do.
Also, the question isn't whether it is needed (because it is), it's what form will it take. The QA for the project is to make this application "needed" as little as possible.
I'd also like to say that this program would be along the lines of those support apps that I mentioned the rest of us could do that don't have the expertise to do the low level coding currently underway here.
Haiku Updater
SigmaNuki said exactly what I've been trying to say. It's more of a "when" question, instead of an "if" or "should we" question.
I appreciate what you say about doing the QA correctly, mphipps, but it's still going to be necessary, like SN said. About the only project I can think of that probably wouldn't need an updater would be OpenBSD, and they've still got their ports tree...
Cheers,
togs
Re: Do you really want one of these?
Agreed entirely. In R5, SoftwareValet was the updater. Told you if there was a new package available.
There is no point in letting joe-end-user update little bits along the way. Do it like Be, with properly numbered point releases, R1, R1.01, etc.
Re: Do you really want one of these?
So then the Haiku team will not have to release an update at every point along the way. Why not just release what is needed at a particular time? Why not make that availible via a system updater? There is no reason not to.
A perfect example is OBSD. They have the patch branch to there cvs tree which gets all the nessasary patchs applied. So, if I wanted to fix bug x on my system, I update my src tree and recompile what ever is needed.
Now Haiku should, no wait, has to implement this, in a hopefully user friendly way. I quite frankly would be quite upset if bug x - which is irritating me - was fixed, but the team responsible wanted to wait for a time in which a good amount of bugs could be fixed at one time. There is no logic behind this. If I want bug x fixed and it has been, there is no reason to prevent joe user from doing so.
You also seem not to realize that all modern operating systems already have this. Do you want to prove what an article said about this project? Do you want an OS from years ago? Or do you want a modern OS with all the modern features?
And by the way, Software Valet never told me about any updates.
Also, letting people update does not mean that there isn't properly numbered releases. Have you ever heard of the patch level. Goes something like:
x.y.z
where:
x = major version
y = minor version
z = patch level
Haiku Updater
You forget that if a patch in any way breaks compatibility with a part of the API, or whatever, you'll get certain developers releasing apps on BeBits that need this latest patch. Which 95% of users don't have. This will start creating the dependency hell that scares people from Linux
SoftwareValet only told you abouit updates when BeDepot was still running. Not sure when BeDepot closed.
Haiku does not need a Windows-update esque updater. At all.
Haiku Updater
So what do we do when something like an RPC exploit happens and we all of a sudden have hordes of worm-autobots swarming over our Internet connections. You ask me, I'd want a fix available for that pretty damn quick. Saying that no one would target Haiku because there's only 0.01 percent of users running it is ridiculous. If I could, I'd code a worm to prove my point. Saying that it wont happen is crazy too, because no one's code is perfect the first time.
The point about certain packages on BeBits requiring certain patches. If something like Windows Update was available, all of those patches would be downloaded and installed around the first 48 hours, unless a plethora of them are 10 megs each. API collision solved. I realise some people won't blindly install patches, but that's your tradeoff right there. It's like all those apps that require BONE. I can't install BONE for some reason, so I can't use those apps. I accept that. I'm sure people who scrutinize their patches will accept that, too.
This is the age of the Internet. If you can't use the Internet as a tool to stop all the people who use it as a weapon, you'd be stuffed from day one.
Cheers,
togs
Haiku Updater
(note, I can't select text for some reason hence I'm quoting everything)
In the case of an RPC-esque exploit, a proper patch updater would be released, ala R5.03, which fixed a remote execution exploit in R5.02.
A Windows Update like system would almost certainly end up being used as the sole update mechanism. I use a proxy server, my Windows boxen can't use Windows Update. That kind of updater just creates more problems than it solves.
Haiku Updater
I only see the value in an update-notifier which simply polls an RSS feed or something every day to see if there are any new updates released - and possibly use the current revision as a filter to make sure it only shows updates that you don't already have... - then when updates are available, it gives the user a URL to download/locate the update and install it.
Haiku Updater
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.
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.
Cheers,
togs
Haiku Updater
That's why things that do this should only be done at major releases. If one changes things to break compatability then that developer shouldn't be one. It's upto the devs to make sure that this doesn't happen. It's *extremely poor QA that let's this happen.
Linux devs don't care about such things. LInux *is* somebodies hobby that *really* took off. They don't care about backware compat.
But I really think that you are talking about certain programs needing certain version of certain *3rd party* libraries. I speak of the OS, *not* such things.
Not a Windows esqure updater. Something uniquely Haiku, Be inspired, that does the same job. And you shouldn't really be invoking WIndows here as there is Mac OS X... that do the same thing.
I've said it once I'll say it again. This is a feature of a modern OS, if Haiku doesn't have one...
Haiku Updater
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.
People are lazy, ain't it true.
Haiku Updater
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
Haiku Updater
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:
1) Release
2) Patch branch
3) 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.
Haiku Updater
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.
Haiku Updater
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 !!!!
Haiku Updater
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... :p .. 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.
1) The user should have an update-client.
2) This update-client connects to the update-server.
3) The client sends information about hardware and software to the server.
4) The server sends information back regarding available updates.
5) The user chooses which updates to download and/or install.
6) The client downloads updates from the server.
7) 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.. :P
BTW: Thanks Kurtis, for activating my profile ... I'm in!!! I'm in!!! :D
Haiku Updater
Um, I run BeOS and I have a Duron.
Haiku Updater
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))
Haiku Updater
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:
Haiku Updater
I also ran on a Duron for a year or so.
Haiku Updater
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.
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.
Haiku Updater
Nice thinking there :D ... 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 :P .. 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: ).
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 :P
Haiku Updater
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.
Haiku Updater
SHA1 or MD5 should be good enough. That's what OBSD uses :)
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 ;)
Haiku Updater
Well.. something like that would do it, yes.
It's not if, but when... Haiku WILL prevail :P
But yeah.. there'll be enough mirrors without a doubt
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 :D
Haiku Updater
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
Haiku Updater
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.
Re:
SigmaNunki, I'll second you on that :wink:
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 :P
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:
Change in file atributes
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:).
Re: Change in file atributes
Executables already have version number and copyright info and always have...
Haiku Updater
I think a simple RSS-like 3rd Party app would be sufficient for updating. Not everyone has the internet, and that is how most viruses are travelling these days.
5 Step scenario to get a look at my idea:
1. User installs official Haiku Distribution
2. User installs Updater application
3. User registers* 'system', 'firefox' and 'openoffice' with Updater
4. Updater checks latest version of selected groups/apps.
5. Updater somehow notifies user of the updater, with information on how to update (Possibly automatically, within 3 clicks)
x. A new version is of something is available, goto step 5.
* By register i mean selects those applications/predetermined groups
- Please remember that most users wont have the Haiku source on their systems.
- Please remember that most users hate annoying popups, or having to restart their computer because of an update.
Haiku Updater
I think, a user-friendly updater (Yes, like Microsoft Windows!) would be really good for Haiku users.
Simple.