[OS X TeX] 64-bit binaries in TeXLive 2010

[Alain Schremmer]

On Dec 5, 2009, at 1:07 PM, Adam R. Maxwell wrote:

>
> On Dec 5, 2009, at 7:19 AM, Herbert Schulz wrote:
>
>>
>> On Dec 5, 2009, at 8:36 AM, Alain Schremmer wrote:
>>
>>> ...
>>> 1) Being behind does not mean being lost. I am still using GWTeX.  
>>> And if, for some reason, I couldn't anymore, I could always  
>>> upgrade to TeXLive2008 which, I assume is still going to be  
>>> available.
>>>
>>
>> Howdy,
>>
>> If you were to update why would you go to TeX Live 2008 instead of  
>> 2009? There will be no more updates to 2008 while 2009 will have a  
>> year of easy updates to fix bugs, etc. Hmmm... you would have to  
>> update your OS to 10.5.8 so that TeX Live Utility (TLU) can easily  
>> do its update job; I know you're Terminal phobic so dealing with  
>> tlmgr directly wouldn't work.
>
> Yeah, what Herb said.  In addition, AFAIK you can't download MacTeX  
> 2008 anymore, much less TL 2008.  Both are gone, unless you have  
> DVD media or an old copy...but the DVD will still only be current  
> as of August 2008.

Now THAT I didn't know and sure don't understand: It can't be that  
much work to keep for the upgrade-challenged to download
>
>>> 2) The issue, I think, is whether or not the new features should  
>>> be made available on older systems and given 1), I really do not  
>>> see why as it is then the user's choice: to stay with what s/he  
>>> has or to pay the price for availing her/himself with the new  
>>> improved.
>>>
>>
>> Many of the new features are available as individual packages that  
>> you must manually install. Sometimes package interdependence means  
>> you must update a set of packages and that isn't always obvious  
>> until you try to use them. It's much nicer to just use TLU!
>
> Part of the reason I'm a big fan of tlmgr is that I tried to wedge  
> a new hyperref into gwTeX, since I needed it for compatibility with  
> a certain document class.  The dependencies on that were /not/ fun  
> to resolve manually; IIRC it took the better part of an afternoon,  
> and was really frustrating on a deadline.


>
>>>> This just pushes the question back to the developer tools and  
>>>> compilers, etc. Why should *they* move ahead in a manner that  
>>>> makes the software developed with them
>>>
>>> obsolete? If so, because it makes for sales, and, in the case of  
>>> free software, because, like the Everest, it is there.
>>>
>>
>> Given that folks putting together the ``free'' software have no  
>> profit motive it usually means that there are feature changes and/ 
>> or bug fixes if they put in the time to issue an update. It also  
>> isn't always obvious that there was a problem unless you run into  
>> it directly; that doesn't mean it won't bite you in the future.
>
> You're both right, I think.  Ideally, there would be worthwhile  
> features or bug fixes…but I've seen a fair amount of open source  
> development changes made for no apparent reason.  Without pointing  
> at any project in particular, rewriting existing code to fit the  
> random design whim of the day often introduces a slew of new bugs,  
> and is very annoying to everyone but the developer :).

I still do not understand why this has to be an "either/or but not  
both". Why can't "old" versions remain available with a short note to  
the effect that "this was working under such and such condition."

Puzzled regards
--schremmer