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.
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.
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?
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…
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.
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
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.
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.
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.
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?
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.
If the QA is done well enough, you shouldn't need a system updater.
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.
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…
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.
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.
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.
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
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 does not need a Windows-update esque updater. At all.
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.
Haiku does not need a Windows-update esque updater. At all.
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
(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.
(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.
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.
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.
You forget that if a patch in any way breaks compatibility with a part of the API,
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.
MYOB wrote:
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
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.
MYOB wrote:
Haiku does not need a Windows-update esque updater. At all.
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…
