I really didn't want to upgrade yet (only suckers pay for .0 releases) but the new version broke XScreenSaver so I needed to test it. ("Screen savers must not use garbage collection! No wait, screen savers must use garbage collection! No wait, screen savers must not use garbage collection!")
The iOS version is still "awaiting review", but if those of you who are able could build and try that version yourselves, I'd appreciate it. I think I've fixed the performance problem on Retina iPads.
A decade later, and still nobody at Apple knows how to estimate completion times:
(And that was after the "about 20 minutes" timer starting over from scratch once. Total actual time, about an hour and a half.)
Also, isn't it about time that upgrading MacPorts after having upgraded the OS wasn't a colossal pain in the ass that takes fully half a day of fucking around? Jesus.
Anyone know how to delete all the slideshow screensavers from the list in preferences ("Floating" and "Flip-up" and whatnot)? The others you can just delete from /System/Library/Screen Savers/ but I can't tell where these live.
All the resources for the "Floating", "Flip Up", etc seem to be in:
/System/Library/PreferencePanes/DesktopScreenEffectsPref.prefPane/Contents/Resources/ScreenEffects.prefPane/Contents
That though is the limit of my OS X tracking down abilities, if you find a way to disable them, would be awesome to know.
Yeah, I found that, and deleting either DesktopScreenEffectsPref.prefPane or ScreenEffects.prefPane or lower files just breaks everything.
Interestingly, I deleted all the .png files in:
/System/Library/PreferencePanes/DesktopScreenEffectsPref.prefPane/Contents/Resources/ScreenEffects.prefPane/Contents/Resources
And reopened System Preference - Desktop & Screen Savers again in some weird hope they would be blank. Instead, a whole different set of images appeared. Which I have no clue where they could be.
Looks like this now:
http://dl.dropbox.com/u/16150705/Screen%20Shot%202012-07-27%20at%201.19.01%20AM.png
It is just me, or this is going after the "longest ever path ever" prize?
I keep searching for the longest path...
http://valis.cs.uiuc.edu/~sariel/misc/funny/longestpath.mp3 (via http://valis.cs.uiuc.edu/~sariel/misc/funny/ ).
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/usr/include/c++/4.2.1/ext/pb_ds/detail/basic_tree_policy/basic_tree_policy_base.hpp ?
$ find /Applications/Xcode.app/Contents/ -depth +20 | wc -l
2700
$ find /Applications/Xcode.app/Contents/ -depth +27 | wc -l
3
Uhm, surely you must know that Homebrew is MacPorts done right?
Seconding this.
Thirding that.
What they said.
You may have to tweak some ruby code if you have exotic requirements, but there are enough examples that you can put a new package description together without actually learning ruby.
Does homebrew get conflicting dependencies right yet, or does it still punt that to the user?
Last time I looked, it was great at the simple stuff, but threw up it's hands and said "your problem bud!" to anything difficult. MacPorts at least made an effort.
(Updating MacPorts from SL -> ML took an age, but required no intervention from me whatsoever. Unless I've missed something and in reality it's horribly broken & I just haven't noticed yet?)
Download page lists the wrong size for the .dmg at least -- I figure you might have forgotten to update that in the shuffle.
I eagerly await your future post on all the ways that 10.8 blows goats.
I'm curious how you would estimate the time remaining for a running shell script. That's the primary stumbling block to an accurate installer progress estimate.
(Someone must have "improved" my code for the progress bar since I left, because although my algorithm had to make a lot of guesses, I made sure it could never go negative.)
Well obviously the general problem as you've stated it is the halting problem, but that's not the goal. The goal is, "how long will this installation of this particular known set of software take." That's not the same problem, and I can think of a bunch of tricks you could throw at it. But for the last decade, every time estimate the installer has ever shown me has been comical. I mean, not just off by half a minute, but truly joke-worthy.
E.g., "I just installed N MB of libraries, and now I know the speed of the disk I'm writing to, and so I can bet that ranlib tends to take M seconds per MB to run."
Maybe that one in particular wouldn't help, but, geez, even something brute force like: compiling a list of "here's how long an install of this particular OS took to run on each of our testing machines, and here's what drives they had in them" and then hard-coding the estimated completion time on the customer's machine based on the closest match there, would be better than what it does today.
Yes. Those ideas are good ones, and I used several of them. But the killer is the shell script, at the end of a long install, that does anything more complex than just running a list of commands. IIRC, the developer tools package scripts are like this. These scripts have workloads that may depend on the particulars of your specific computer, they might act very differently depending on any number of conditions, and the script authors have no interest in adding, or maintaining, the hypothetical metadata that the installer could use.
The way I did it, I computed an estimate for the whole install based on what I knew, multiplied and capped it to some arbitrary limit, and then had the estimate run exponentially down to zero. I figured the exact estimate was much less important than setting proper expectations. This still was far from perfect, mostly because the scripts run near the end of the installation would make any whatever estimates calculated up to that point pretty worthless.
I'm amused/disappointed that someone decided they could "finally get it right," with the result being a taunt-worthy screenshot. They should have at least checked for negative time remaining. :/
Screen savers are obsolete