2.04 GB of Downloads: Another call for selective downloads please
Well, this 2 GB is a vary large portion of the download limits for most users in this country!!
Another call for selective download controls please.
One messy and really ugly workaround is:
1) Download and print the Release Notes for the Resource Update
2) Identify and HIDE some of the larger and low-priority resources
3) Restart a few times to make sure they are hidden, then begin the download
4) Allow reindex etc to complete
5) Un-hide the larger resources one or two at a time, over as many days as desired, to manage the download sizes and traffic usage.
YUCK!
Please can we have a better way?
Comments
Please can we have a better way?
Jim, I agree that a better way needs to be available for people with download limits. While your solution isn't the ideal, I think you should put it on the wiki as a temporary work-around. At least it gives users their most important resources before they hit their limits. You may even put a Mr. Yuck face on it, if it suits your humor.
Seattle is not only the "birth place" of grunge. It is also the birth place of Mr. Yuck. PS he is not to be abused, he labels things as poison/hazardous for children.
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
Jim, I agree that a better way needs to be available for people with download limits. While your solution isn't the ideal ...
YES - far from ideal. Others can decide if hiding some of their larger but less-important resources has much merit. It would be easier if the release-notes had file sizes too.
Of the 2 GB, it seems 600 MB of this is the two Greek audio resources (Pronunciation), so I can't hide them anyway. Besides, I often use the Erasmian one. Maybe I'd hide the "Modern" one if I could.
Could we maybe have a "forked" install choice (thinking along the Ubuntu release view: rare hard-core STABLE releases and more frequent "minor" updates).
We already have the Beta and Stable channels. Maybe Logos could add 6 month channel as well, for those who need the underlying stability enhancements to the engine without needing all the "extras" that make updates like this one hard on those with limited connection issues.
Just my 2c.
Lenovo TS130 Xeon E3-1245V2 | 20GB | 256 GB SSD (OS and Logos) | 3TB WD Red | Windows 10 Pro x64
L4 & L5 Platinum, L6 Gold, L5 Reformed Gold, L6 Reformed Bronze, L7 Lutheran Silver, L7 Reformed Starter, L7 Full Feature Set
Interesting idea ...
Actually, I don't think the problem here is the update to the Logos4 application itself. Its only small.
Given that everyone was going to need a full reindex anyway, maybe Logos decided to release some pending resource updates at the same time.
P.S. Of my 2 GB download, I have an estimated 500 MB still to go, after some 6 hours already spent on the download. Indexing still future. NOT a light impact on resources.
Sorry I'm so late to this. :-)
Fortunately, several people have already stepped in to make my point: it's logistically impossible for us to "hold some of your calls." We are, in fact, trying to hold "typo" updates, and almost everything we are pushing out is in the A) or 
categories -- things that need to be kept in sync with the app.
The biggest things are generally the media resources (some of which have been updated since we shipped in order to correct important metadata errors -- this format was new to Logos 4 and we learned some things along the way) and reverse interlinears, which touch everything. It would be difficult to code the app to not crash if everyone ran different versions of the very-integral reverse interlinears.
We've been updating the rev int's because you asked for it: full-screen reverse interlinear display (which we never planned, but did in response to user requests), and then revising the database with extra fields/info to implement requested features and enhancements.
Now it's true you could argue we should have held the product, tested all of this thoroughly, gotten more user feedback before shipping, etc. That would just have taken, um, about as long as it's taken... because we've just kept working hard on it. This gets back to the many-times-argued discussion we've had in the forums: should we have held Logos 4 or shipped it? And, as I've pointed out (with no malice intended) you can choose that "hold it till it's perfect!" scenario right now by simply continuing to use Logos 3 for another six months or so. (Yes, I understand that might make you upset -- that we dared to ship short of perfection -- but I've got as many or more users on the other side who wanted it out there, and are happy with it now.)
I imagine that soon after the next major release (which should have almost all the "missing features" of Logos 3) you'll find that resource updates slow down dramatically. I find them annoying, too, but hope you realize they just mean you're getting a constantly improved product!
As for solutions: we aren't going to let you pick and choose, for all the reasons exhaustively given. It really is logistically impossible. There is hope: patching. Google Chrome and other "updated all the time" apps send down patch files that represent just the differences between version 34 and version 35 of a file. Then code runs on your machine to turn your copy of v34 into v35.
The problem is, somebody out there had the Internet turned off since v23. So they need the v23 -> v35 patch. Or the v1 -> v35 patch, which could be bigger than v35.
And while Chrome has "one app" to update, we've got 10,000+ individual resources.
I think there are solutions, and there are "off-the-shelf" solutions, extensively tested over many years, that can help with this scary-complex process. But it's still a lot more complicated than delivering the latest file, and introduces many more potential failure/corruption points.
There's also the question of the best use of our coding resources: do you want printing first, or patching? Especially since it's like that this year we'll grow out of the frequent updates phase, and things should stabilize.
There's also the question of the best use of our coding resources
Well I certainly have my opinions but they're just not happening - lectionaries, early translations such as the Gothic, Anglo-Saxon, Armenian, notes linked to multiple passages ... [:D]Seriously, while I've had to wait for some of the things that matter most to me, I think Logos has generally done a good job of prioritizing features. One of the things that continues to surprise me on the forums is the degree to which users fail to understand that in order for them to get their No. 1 priority, someone else's No. 1 priority is delayed. We can't all get it now ... although at least I am perfectly capable of wanting it all now. Thanks for taking the time to reply.
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
Way to think outside of the box Jim!
I think Bob has posted on here, that Logos managing the different versions of files, and different states of current version that users' systems would be in would be untenable from a support perspective, which has cost and quality considerations. Given how closely the resources and the versions are tied for some functions, when Logos can no longer count on there not being a mismatch, maintaining any kind of consistent quality becomes quite problematic.
Just relaying this on because it has been discussed often - please don't shoot the messenger [A]
Yes, no shooting.
I've heard this view on why we can't have selective downloads before, but I don't consider that an acceptable "solution", for customers with limited Internet traffic-caps or usage surcharges.
NOT all updates are created equal. It would be an easy matter to put any resource updates into 2 or 3 types:
A) Application updates and critical resource updates to prevent crashes or major fault conditions. If a resource is rebuilt with a critical change to its internal format, and the application would be unstable without this update, its an (A)!
C) Minor typos or lesser changes. You may want this, but it many be a low priority for you.
If a user elects to NOT take the (B) or (C) updates, it does NOT create application crashes, support issues or nighmares.
It would be easy for something to be added to the metadata for resources, by build-version, so there was some visual clue somewhere, that a given resource has outstanding (B) or (C) updates that can be downloaded.
I might be happy to have outstanding typos in some resources I hardly or never use, until I'm at a place or time, that the download and reindex is acceptable.
Any time Logos releases an updated resource, they would tag it as (A), (B) or (C) and make a comment in the release notes too.
(After 1.5 hours, I'm at 9% of my 2 GB downloads ... Internet is NOT unlimited size or speed here)
RE: Jim T and his A, B, C updates
You call support - First Question - Did you update all the 'A' updates - if not please call back after updating
You call support on Resource 'XYZ' - first question - Did you update the 'B' update on that resource - if not please call back after updating
They might also inform you of interactions of other 'B' updates on Resource 'XYZ' [Resource 'XYZ' is up to date but it requires 'ABC' to work correctly]
Or LOGOS could just break up the updates into 100 MB chunks - Laptop done and now to do the Desktop
A more likely scenario:
You call support - First Question - Did you update all the 'A' updates - if not please call back after updating
LIkely reply -> Yes I did (but I did not, I thought I did) - so after 20 minutes of investigation the tech support person asks the person to just do it again anyway and call back, and the whole sequence starts over.
You call support on Resource 'XYZ' - first question - Did you update the 'B' update on that resource - if not please call back after updating
Likely reply -> I don't know how to - my son does the updates and manages the configuration, and he is away. All I know is my system is crashing because something is wrong.
IMHO I think some hard-truth realities are these: (1) the program and data are connected. There are times when it matters what version of resource match with the version of software. So many of the comments here seem to just imply this is an arbitrary decision, but it's not - it's like saying give me half the release Logos, and you worry about supporting me that way. To compare to LInux is problematic, because Linux is used by people fully capable of maintaining it, they know how to build their own version of the distribution in most cases. We have Logos users that are really much less experienced in their desktop software. To give users the ability to uncouple software and required resources, well that is just asking for trouble, and no software developer would willingly do that. Is there a way to uncouple resources and software? Maybe, but that leads to truth #2: (2) The ideas being proposed here will take a lot of software development time and money to implement. Are we willing to forego many important functional updates for this kind of investigation, implementation, design of software to manage the revisions so Logos knows what is going on, etc.? If, just for example, sentence diagramming, printing, and PBB support were pushed out another 6 months from wherever they will end up without this work, would that be worth it? I am willing to bet most customers would say no.
Well said. [Y]
Enable-and-Submit-Log-Files | Install
The Logos4 application already, and always, knows if there is an update to itself, and if there is an update to a resource its been asked to open.
It could offer a warning before opening a resource, if its known there is a newer one. Whats so hard about that?
It could write to the log, before opening any "outdated" resource. Whats the problem?
This one really is easy!
No, not 30 lines of code. But not a support nightmare. The application already knows all about what resources have updates, and if it crashes, what ones were active. No human need get involved to automate upgrade or resource-lockout warnings, if a resource is the problem.
Jim,
Bob has answered this several times, the data IS connected to the program. Logos is not going to create a customer service nightmare to do what you are asking. Yikes! your suggestions of a half updated program or worse, without your knowing the inner workings of the program, you want to choose some updates and reject others. Most customers don't know how to even begin to do what you are asking, let alone remember what they did or did not do several months ago.
I suggest we all wait until Logos 4 is finished, and then see where we stand at that time. I wonder how many users Logos has outside the US that this is a problem for? Logos has over a half a million users and 27,000 forum members and only a dozen or so people complain about this issue.
RE: Jim T and his A, B, C updates
You call support - First Question - Did you update all the 'A' updates - if not please call back after updating
You call support on Resource 'XYZ' - first question - Did you update the 'B' update on that resource - if not please call back after updating
They might also inform you of interactions of other 'B' updates on Resource 'XYZ' [Resource 'XYZ' is up to date but it requires 'ABC' to work correctly]
Or LOGOS could just break up the updates into 100 MB chunks - Laptop done and now to do the Desktop