I'm pretty sure it was announced that Rosetta Mini was being depreciated, but now there is a whole bunch of new Rosetta Mini work out there. I was wondering if the Rosetta Mini application will now be updated to reduce the disk usage as well?

BTW, what the difference between Rosetta and Rosetta Mini ? What part is "mini" ?

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=4394#56015

From that short description one could infer that "mini" is newer and has chances to become better too - so why deprecation then?

I'm pretty sure it was announced that Rosetta Mini was being depreciated, but now there is a whole bunch of new Rosetta Mini work out there. I was wondering if the Rosetta Mini application will now be updated to reduce the disk usage as well?

BTW, what the difference between Rosetta and Rosetta Mini ? What part is "mini" ?

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=4394#56015

From that short description one could infer that "mini" is newer and has chances to become better too - so why deprecation then?

That was 2008, things have changed. Mini is no longer newer. It's in fact quite the opposite, now that Rosetta 4.15 is out, with 4.20 coming very soon.

That was 2008, things have changed. Mini is no longer newer. It's in fact quite the opposite, now that Rosetta 4.15 is out, with 4.20 coming very soon.

So, all "that time new" features were included into "main" app perhaps?
Ok, that enough for my curiosity, thanks.

I'm pretty sure it was announced that Rosetta Mini was being depreciated, but now there is a whole bunch of new Rosetta Mini work out there. I was wondering if the Rosetta Mini application will now be updated to reduce the disk usage as well?

BTW, what the difference between Rosetta and Rosetta Mini ? What part is "mini" ?

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=4394#56015

My usual answer is "no-one knows". And after reading that I think it still applies after all this time

---

Still working out some kinks. I also included more frequent checkpointing for the comparative modeling protocol which lacked checkpoints within a model trajectory. If all goes well after another app updated and testing phase on Ralph, then I'll phase in the new app version on R@h, one or two platforms per day to prevent excessive network IO.

Now doing Tasks with v4.20.
Disk usage has dropped form 13GB down to just over 2GB.
A great improvement, a job well done.

---

Grant
Darwin NT

Still working out some kinks. I also included more frequent checkpointing for the comparative modeling protocol which lacked checkpoints within a model trajectory. If all goes well after another app updated and testing phase on Ralph, then I'll phase in the new app version on R@h, one or two platforms per day to prevent excessive network IO.

Now doing Tasks with v4.20.
Disk usage has dropped form 13GB down to just over 2GB.
A great improvement, a job well done.

I was looking at the same thing an hour ago. 8.9Gb for Rosetta and I had to use a 12Gb cache, recently increased from 10gb.
Rosetta now using 1.63Gb.
I reduced the disk cache to 8Gb - only as a staging post because I can hardly believe it really only needs to be nearer 4Gb or less

---

As for the captcha, I can add it to the registration / email forms to replace the internal spam filtering when I get a chance but that's definitely low priority.

That's a shame, hopefully you can get that done and lift the filtering soon. On a positive note, I re-attached and everything is going well, so you clearly didn't need my testing.

I'd like to attract attention to my other post that got drowned out, if possible: https://boinc.bakerlab.org/rosetta/forum_thread.php?id=13894&postid=95809#95809

On a final note, I'd like to request IPv6 support be added to the boinc-files.bakerlab.org domain. The other 2 domains (boinc.bakerlab.org & bwsrv1.bakerlab.org) already support it. This will allow me to add 2 maybe 3 more hosts. But finishing the HTTPS work should be higher priority.

Over 20 4.20 WUs and it only uses 1.61GB, now that's good!

---

I'd like to attract attention

Bump, admin?

I'd like to attract attention

Bump, admin?

Those URLs should be https. I'm not sure what is going on with your host.

---

Those URLs should be https. I'm not sure what is going on with your host.

Thanks for the follow up.
Unless this was fixed after I re-attached my machines then it's not just me. But I will try re-attach them again soon.

Have you tried doing a search for "http:" in all .XML files in the BOINC data directory?

Yes I did on my mac for ralph@h. I haven't switched R@h yet since I'm letting the tasks complete.

---

Sorry funkydude, I was wrong. There were indeed some remaining http references in some xmls and I think I traced the issue. This is hopefully fixed now but will only be active with new jobs submitted by our group. Currently queued and running jobs will still have some URLs with http. I'll check again after new jobs get submitted.

edit:

Additionally, the 4.20 app download URLs are still using http unfortunately since they were released before the SSL update. The next app update will use https.

---

There were indeed some remaining http references in some xmls and I think I traced the issue. This is hopefully fixed now but will only be active with new jobs submitted by our group. Currently queued and running jobs will still have some URLs with http. I'll check again after new jobs get submitted.

This explanation makes perfect sense for the upload_url because it appears once for every single task i.e. it appears 24 times in the config file when running 24 tasks.
So obviously this URL is tied to the generated tasks themselves and as you already said, we need to wait for brand new tasks.

However, are you sure this applies to the scheduler?
From my original post
BOINC/global_prefs.xml

<source_scheduler>http://bwsrv1.bakerlab.org/rosetta_cgi/cgi</source_scheduler>

Not only does this also only appear once, but it also appears in XML files for other projects.
For example, this is a GPUGRID XML file:
BOINC/sched_request_www.gpugrid.net.xml

<source_scheduler>http://bwsrv1.bakerlab.org/rosetta_cgi/cgi</source_scheduler>

I believe this is because I'm using the web preferences set by R@H, so the GPUGRID XML files ends up with a reference to your scheduler to know my BOINC preferences.

Are you sure this can only be fixed by more work and isn't some setting on the back end of the website?

I'm not sure how one can update that global preference via the web site. I just edited the xml but that isn't convenient. If anyone knows, please post instructions here. I suppose I can modify the database records but I'm not completely sure that would cause problems or not and don't want to take that risk.

---

I'm not sure how one can update that global preference via the web site. I just edited the xml but that isn't convenient. If anyone knows, please post instructions here. I suppose I can modify the database records but I'm not completely sure that would cause problems or not and don't want to take that risk.

From what I see there are only 2 options.

1) You update the database for all users, then they gradually migrate to HTTPS the next time each user contacts the server for more work.
2) Attempt to get users to edit their BOINC preferences on rosetta themselves.

I think number 1 is the only realistic option, but if anyone wants to follow step 2, here how to do it (and how I did it).
The following steps will enable HTTPS protection for your BOINC configuration.

> Log into the Rosetta@Home website and go to your account.
> Click on "Computing preferences".
> Click "Edit Preferences" at the bottom.
> Change anything you want. e.g. "Store at least X days of work". If you don't want to change anything just change it back straight after.
> Click "Update preferences" at the bottom.
---
> At this point you can either edit your preferences again to undo your change, or you can proceed with the next step.
> Open up your BOINC manager, select the Rosetta@Home project and click the "Update" button.

That's it. Your preferences are now encrypted with HTTPS instead of using HTTP.

While this works, it is a really convoluted method that next to no one is going to bother following.

While this works, it is a really convoluted method that next to no one is going to bother following.

...and even then it would only be for folks that presently use R@h for the preferences. If my preferences were coming from another project, you wouldn't want to trigger a change that suddenly starts using R@h for computing preferences.

What determines the project I get my preferences from? Is it as simple as the most recent timestamp on a change wins?

---

Rosetta Moderator: Mod.Sense

What determines the project I get my preferences from? Is it as simple as the most recent timestamp on a change wins?

YEs. The last edited will be used.