If I have one of my PPC Amigas in the closet for 6 months or a year, how will I get it updated then?? It's not that far-fetched for someone not to have an Amiga temporarily out of use. My old µA1 has been in the closet for almost a year now as a backup in case my SAM fails. Periodically I get it out and apply the updates I have collected on my SAM hard drive. It seems to me that updates that are required for a future update should be retained on the server.
I can't see that would be any problem with that. If component 'a' has to upgraded to least version nn, before component 'b' can be installed, then the fact that a more recent version of 'a' is on the server won't cause an issue.
Components aren't currently removed from the server, although only the most recent version is usually held as far as I know.
I don't think anybody was suggesting it should update without user confirmation. Scanning automatically saves a click that the user is going to have to do anyway.
But the user may want to make other selections before scanning, choose which servers to scan etc.
It's not a simple either or / on off decision process.
You've managed to disagree with me by posting a quote which backs up what I said. How is that even possible?!
It sounded like you were saying the ONLY reason for an ellipsis is that it will open a requester (and by implication that the ellipses were incorrect for AmiUpdate). But the Style Guide says it can be a window (or requester).
And the reason for a window is that it allows the user to make further choices (or even change their mind). So for example, it would NOT be within the spirit of the Style Guide for Workbench's "Icon/Delete..." to immediately start deleting files just because it opened a progress *window* . Whether or not AmiUpdate should start scanning without user permission is debatable.
Quote:
I don't think anybody was suggesting it should update without user confirmation.
That was only my initial (mis?)reading of what was being suggested. If I was mistaken, then my fault for reading the thread too quickly...
@boradblues Quote:
But the user may want to make other selections before scanning, choose which servers to scan etc.
It's not a simple either or / on off decision process.
I don't think anybody was suggesting it should update without user confirmation. Scanning automatically saves a click that the user is going to have to do anyway.
FWIW the update handler in Ubuntu works the same way as AmiUpdate in this respect and I don't see a problem with it. Also AmiUpdate can be configured to do scheduled scans in the background. If the user has this functionality enabled it would be a waste of time to scan again every time the AmiUpdate window is opened (at the very least such functionality should be optional and disabled by default).
You've managed to disagree with me by posting a quote which backs up what I said. How is that even possible?!
It sounded like you were saying the ONLY reason for an ellipsis is that it will open a requester (and by implication that the ellipses were incorrect for AmiUpdate). But the Style Guide says it can be a window (or requester).
And the reason for a window is that it allows the user to make further choices (or even change their mind). So for example, it would NOT be within the spirit of the Style Guide for Workbench's "Icon/Delete..." to immediately start deleting files just because it opened a progress *window* .
OK, so you got me on a technicality of what a "requester" is. I was considering the AmiUpdate window a requester as it is requesting input. I don't consider a deletion progress window a requester.
So, if delete were to start deleting with a progress window without checking first, would that menu item warrant the ellipsis? I would agree that it wouldn't. However, the style guide would suggest that it should due to its interpretation that windows and requesters are two different things, and a window, therefore, is not requesting any input, as that is a requester's job. What if it had an "abort" button?
Actually I don't think that's a menu style guide issue, it's a general user interface issue. "Don't do destructive things without checking with the user". That's probably in the style guide somewhere.
edit I'm not going to start holding up Windows as a fantastic example of user interface design, however I've just noticed that Firefox has hit the same problem. Things like "Open File..." and "Print..." are as you would expect, but "Print Preview", "Options" and even "About Firefox" are sans ellipsis. Even more confusingly, "Subscribe to This Page..." and "Report Web Forgery..." don't open any windows (they just change the contents of the current window).
I can't see that would be any problem with that. If component 'a' has to upgraded to least version nn, before component 'b' can be installed, then the fact that a more recent version of 'a' is on the server won't cause an issue.
Components aren't currently removed from the server, although only the most recent version is usually held as far as I know.
How about if component 'a' v1.1 required component 'b' v1.1, however a later version of component 'b' happened to require v1.2 of component 'a'? At this point in time on the server component 'b' would not be offered because component 'a' is still at v1.0, and component 'a' would not be offered because component 'b' is at v1.0.
That's a simplistic example but a circular dependency like that could easily happen with several intermediary components in the mix.
I can't see that would be any problem with that. If component 'a' has to upgraded to least version nn, before component 'b' can be installed, then the fact that a more recent version of 'a' is on the server won't cause an issue.
Components aren't currently removed from the server, although only the most recent version is usually held as far as I know.
How about if component 'a' v1.1 required component 'b' v1.1, however a later version of component 'b' happened to require v1.2 of component 'a'? At this point in time on the server component 'b' would not be offered because component 'a' is still at v1.0, and component 'a' would not be offered because component 'b' is at v1.0.
That's a simplistic example but a circular dependency like that could easily happen with several intermediary components in the mix.
That type of issue shouldn't occur, the dependencies are typically of the form
program a version y depends on library b of at least version x
the reverse dependency wouldn't make then sense then.
Hopefully such reverse and circular dependencies will be spotted and fixed if accidentally created.
If I have one of my PPC Amigas in the closet for 6 months or a year, how will I get it updated then??
The same way you update any Windows PC. Update, install, reboot, repeat.
Besides, I'd rather focus on real problems and not made up ones. When we do hit an actual circular dependency, etc. we'll just fix it right then and there. And hey, if somebody is really stuck I'll just email them the missing file.
With AmigaOS, you can still get personalized service.
And as far as Elipses goes, it was meant to signify that further user input was required, via whatever means.
Therefore, AmiUpdate fits in nicely with this, for various reasons which are (or should be) obvious.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Scanning automatically saves a click that the user is going to have to do anyway.
seems pretty handy one, as for now i plays with amiupdate, and have found that its a bit annoing all the time to press "scan" when you run it to do the scan actually. So i just go to the settings, and while there is "Perform Self-Update check when started manually", will be nice to have "Perform Self-Scan when started manually" (or so). So all who want as it now, will have default state, but those who want to dbl-click on icon and just nothing else to do and wait till scan is done, can ON such option.
With the changes that's gone on,more drivers should be added as standard in the next release of OS4.x to get users online.
My A1200 has not being online for about 3 to 4 years and in a way force users to go online in-order to receive updates. I have always got my updates & download via a PC for my classic amiga.
2 - Then at any follow restart all i got is a DSI crash:
Quote:
Crash log for task "SYS:System/AmiUpdate/AmiUpdate" Generated by GrimReaper 53.5 Crash occured in module kernel at address 0x0184150C Type of crash: DSI (Data Storage Interrupt) exception
I've submitted an entry to the AmiUpdate bug tracker along with a GR crash log: http://www.amiupdate.net/
Comparing your crash log to mine it looks like it's exactly the same issue that I have. Only the kernel offsets are slightly different (the disassembly is the same) but that's to be expected since the kernel is different for each supported h/w.
Thanks, as info version 2.25 add that comparing to 2.24:
Quote:
AmiUpdate 2.25 (12.12.2012)
- Hopefully tracked down and fixed the invisible docky problem.
So it should only (theorically) be related to the docky functionalities, altrough here i use the program with a setting to not show any icon in dock (AppIcon only on my system)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
. Whether or not AmiUpdate should start scanning without user permission is debatable.
