As for the other bit, do we need to put up a big sign that says "Are you crazy? Do you want to download an additional 120 MB that you will never use?!" (and that's just user-end issues, which completely ignores the cost to Patrick of providing binary downloads).
Really, once an app exceeds a few MB (unless it's only available on CD/DVD), the benefits of a Universal Binary are marginal at best, and most people would be better served with choosing between two single-binary downloads (and hey, it saves the developer from needing to run lipo!)
While I very well understand and support Patricks choice of non-UB downloads, I still think UB is more userfriendly choice. You don't download NeoOffice everyday and anyways many Mac owners have at least occasional access to fast net.
At OOo side, we get already problems with people trying to run wrong architecture builds. Especially new (intel) Mac owners might not know what processor they are using. Just that they have a MacBook Pro or something like that.
Now, with good webpages (like NeoOffice's), lot's of the problems can be avoided altogether, but choosing which version to get is still unnecessary work for the users.
It's very likely that once there is good Neo 2.0 available and much more intel Macs around, the amount of downloads will be much bigger than what it is currently.
In order not to get into trouble with the success, I'd suggest getting a good deal with some university, so that they would host the download(s), or with Apple directly...
Also, even though it would require additional software install, I would highly recommend putting Bittorrent much more prominently as the main download source. There needs to be seed(s) of course, but it would considerably balance the peek download bandwith. Maybe like "Want UB build? Then use Bittorrent "
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Apr 02, 2006 12:38 pm Post subject:
Universal Binaries adds nothing for most users. It's trivial to look at the browser info string and direct folks to the download that best matches their platform (e.g. PPC vs Intel).
The increase in size will increase download time for all users, downloading things that they might not need. The bigger concern, though, is the impact that it has on available download bandwidth. Believe it or not, the Neo binaries suck away a lot of bandwidth from the mirrors (talking gigabytes/month+ here). If things were shifted to a universal binary, the bandwidth needed just to sustain existing downloads would double for no good reason
Getting a UB build is trivial and doesn't require a brain surgeon. Build OOo on both platforms, write a script to lipo together all of the dylibs and executables (not scripts) in solver, erase the instset build directory, then rebuild the module.
If we were the type of application that's distributed solely on CD or DVD, then universal binary is no problem at all. It's only 100 MB of wasted disk space per user installation. But we're not distributed on CD or DVD...so each megabyte counts.
If we were the type of application that's distributed solely on CD or DVD, then universal binary is no problem at all. It's only 100 MB of wasted disk space per user installation. But we're not distributed on CD or DVD...so each megabyte counts.
FWIW, putting the installer and all of the language packs for the 70+ languages for one platform in NeoOffice 2.0 barely fits on a CD. So, I will have to sell two Neo 2.0 CDs: one for PowerPC and one for Intel.
As for the other bit, do we need to put up a big sign that says "Are you crazy? Do you want to download an additional 120 MB that you will never use?!" (and that's just user-end issues, which completely ignores the cost to Patrick of providing binary downloads).
Really, once an app exceeds a few MB (unless it's only available on CD/DVD), the benefits of a Universal Binary are marginal at best, and most people would be better served with choosing between two single-binary downloads (and hey, it saves the developer from needing to run lipo!)
While I very well understand and support Patricks choice of non-UB downloads, I still think UB is more userfriendly choice. You don't download NeoOffice everyday and anyways many Mac owners have at least occasional access to fast net.
1. As to your comment about fast net, I live in an area with EV-DO (part of the 3G data link system) and I have an older cell phone that will do 'only 100kb/s' It takes quite a bit of time on that datalink. Of course, i can always walk over to the University area and take advantage of 'free' WiFi.
2. Try and build one of Pavel's UB builds. Note: this is not complete yet and does not completely work. When I did the .app file took about 570 or so MB (it compressed to a much smaller space in the .dmg file.) This is unnecessary waste of hard drive space to have code sitting around that does nothing.
3. You can use a browser detect statement (I do at my real job) and find out what architecture someone is using and send them to the proper download page. Clobber-Net does not allow this (sadly I had to rename them to state what they really are) or this would be implemented when you log in. All they do is look at your machine type (MacIntosh) and direct you to the MacOSX page. Maybe we could fix it there.....
Posted: Sun Apr 02, 2006 5:57 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
jjmckenzie51 wrote:
I just wanted to advise that the Wziards (IZ 63030) bug affects NeoOffice.org
I will run the patch given for this problem and then rebuild NeoOffice
Isn't this the "missing empty directories" bug that I mentioned in this topic a couple weeks ago? If so, the NeoOffice 2.0 installer already takes care of that issue. If you look at the NeoOffice makefile, you will note that I ignore the Mac OS X installer that OOo creates and, instead, use the *.sw and *.install files that are built by OOo in the instsetoo_native module on all platforms.
Posted: Sun Apr 02, 2006 6:05 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
pluby wrote:
jjmckenzie51 wrote:
I just wanted to advise that the Wziards (IZ 63030) bug affects NeoOffice.org
I will run the patch given for this problem and then rebuild NeoOffice
Isn't this the "missing empty directories" bug that I mentioned in this topic a couple weeks ago? If so, the NeoOffice 2.0 installer already takes care of that issue. If you look at the NeoOffice makefile, you will note that I ignore the Mac OS X installer that OOo creates and, instead, use the *.sw and *.install files that are built by OOo in the instsetoo_native module on all platforms.
Thanks. I wanted the clarification because the Wizards do not work and I got the missing directory error. Maybe it is my build. However, I'm going to re-run it as I ended up with an error when making the Slovian (sp?) language pack which should not have occurred according to Smokey.
Posted: Sun Apr 02, 2006 6:13 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
jjmckenzie51 wrote:
Thanks. I wanted the clarification because the Wizards do not work and I got the missing directory error. Maybe it is my build. However, I'm going to re-run it as I ended up with an error when making the Slovian (sp?) language pack which should not have occurred according to Smokey.
I just fired up Neo 2.0 with the latest code (the last checkin was yesterday) and I have no problems with the wizards. My fix is handled in the installer portion of the Neo build so after you cvs update, delete the build.package file and delete any build.neo_*_patch files that cvs marks as updated (i.e. status "P" or "U"). cvs updating is not enough to force rebuild of the necessary Neo parts. Note that you should never see cvs show a status of "M" or "C". If you see this, you have modified a file and cvs will not update the file.
As for the language packs, I use the hdiutil command to create *.dmg files. For some reason, I have noticed that every so often hdiutil will fail for no reason on Mac OS X 10.4.x. If the hdiutil command becomes a problem, just comment it out in the makefile as creating the *.dmg files is only necessary when I do an official release.
Edit: I just committed a change to the makefile that changes the version name to "NeoOffice 2.0 Early Access". So, if you cvs update after tonight's 3:00 am sync (well, really 5:00 am to be safe), delete the build.neo_configure file to force the new version to propagate through the Neo build.
Posted: Sun Apr 02, 2006 7:27 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
pluby wrote:
jjmckenzie51 wrote:
Thanks. I wanted the clarification because the Wizards do not work and I got the missing directory error. Maybe it is my build. However, I'm going to re-run it as I ended up with an error when making the Slovian (sp?) language pack which should not have occurred according to Smokey.
I just fired up Neo 2.0 with the latest code (the last checkin was yesterday) and I have no problems with the wizards. My fix is handled in the installer portion of the Neo build so after you cvs update, delete the build.package file and delete any build.neo_*_patch files that cvs marks as updated (i.e. status "P" or "U"). cvs updating is not enough to force rebuild of the necessary Neo parts. Note that you should never see cvs show a status of "M" or "C". If you see this, you have modified a file and cvs will not update the file.
I did a fresh checkout and that may have been what broke the build. I went back and may restart it from fresh code.
Update Did a fresh build and removed the NeoOffice-2.x user directory and all of the directories installed. Now to get that Welcome to NeoOffice box fixed!
Posted: Fri Apr 07, 2006 1:07 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
jjmckenzie51 wrote:
I did a fresh checkout and that may have been what broke the build. I went back and may restart it from fresh code.
Update Did a fresh build and removed the NeoOffice-2.x user directory and all of the directories installed. Now to get that Welcome to NeoOffice box fixed!
FYI. I just committed changes that correct the "first run" wizard. In that wizard, I correct the license dialog to display the GPL license and I added support for importing NeoOffice 1.2.x or NeoOffice/J 1.1.x user preferences.
After today's anoncvs sync (i.e. 5:00 pm PDT today), you will need to delete the following folders/files, do a cvs update, and invoke make:
build.neo_vcl_patch
build.desktop_patch
desktop
Also, after you build this, be sure to delete your ~/Library/Preferences/NeoOffice-2.x folder to verify that the user preferences import works.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Apr 07, 2006 7:18 pm Post subject:
mith wrote:
OPENSTEP wrote:
Good point. I forgot about the language packs. That'd make it necesary do to DVD only and not CD. Bleh.
Ed, didn't you install a Torrent tracker a long time ago? That should help the distribution of big files.
The torrent tracker I had in the neo.org domain was taken down because it was being both hacked as well as used for other materials that weren't neo related. Right now the azul (?) project is hosting all of the torrents for neo as well as initial seeding.
Posted: Fri Apr 07, 2006 7:27 pm Post subject: Re: Wizards bug in OpenOffice.org 2.0.2 rc code
pluby wrote:
jjmckenzie51 wrote:
I did a fresh checkout and that may have been what broke the build. I went back and may restart it from fresh code.
Update Did a fresh build and removed the NeoOffice-2.x user directory and all of the directories installed. Now to get that Welcome to NeoOffice box fixed!
FYI. I just committed changes that correct the "first run" wizard. In that wizard, I correct the license dialog to display the GPL license and I added support for importing NeoOffice 1.2.x or NeoOffice/J 1.1.x user preferences.
This did not fix the shrunken Welcome to Neo Box that I got as well as all of the text on the screen being incorrect (I would enclose a screen shot, but that belongs on the NoeZilla...)
In any case, I'm doing a build with gcc-3.3 to see if the Preferences folder is improperly constructed from a gcc-4.0.1 build.
I will open an BugZilla and attach a screen shot and my zipped Preferences folder (or do you prefer tgz files?)
Update Sometime during all of my testing a (null).plist file appeared in my ~/Library/Preferences directory. This file disturbed the font settings for the on-screen text (this is critical during the Welcome to NeoOffice phase.) Deleting this file as well as the NeoOffice-2.x directory corrected the problem. I created a Neo BugZilla entry to track this error and for historical purposes.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
"
