On 28.02.2017, at 03:14, Chris Muller <asqueaker at gmail.com> wrote:

> Hi Tobias,
> 
> AIO provides a compact example file of everything needed to deploy an
> application on each of the top platforms.  For no more than its
> instructional value, it is something worth keeping, IMO.  Having an
> AIO is independent of having platform-specific downloads.  Before
> making any other reasons besides the first one (cumbersome), all of
> the other ones are unnecessary for everyone to have what they want.  I
> thought someone recently announced that the All-In-One is getting
> built automatically..

I know, I also built AIOs, automatically and manually. 
And they are a pain to get right.
I know of no other programming environment/language/system that provides a one-size-fits-all download
(Except some .jar files, like Jenkins, but thats another pain)

> 
> I like Tim's idea.  We already need to solve the problem of
> conflicting directory structures to resolve between 32 and 64-bit
> VM's.  Maybe we can solve that issue and the MacOs Sierra issue
> simultaneously.

Nope. We can't make this sierra-proof.

> 
> Best,
>  Chris
> 
> PS -- Following up those links:  the first one is Hari's, we've knowm
> about the 32-bit library challenges for a decade, it is unrelated to
> the AIO and with 64-bit around the corner, it will melt away soon.

My point is not the 32/64 problem here but the LD_LIBRARY_PATH dance etc.pp.
that would be solved by having proper distribution specific downloads.

> The 2nd link was something about Metacello nothing to do with the AIO.

But sure, because the metacello problem manifested by two things
 (a) package-cache was only root-writable
 (b) We had no proper error-reporting for this case
But why did (a) happen? because our architecture compelled the user into thinking
running squeak with sudo once was necessary.
I think this is at least in part an error of the AOI. (not solely, of course, but it contributes)
 
> The 3rd and 4th were about MacOs Sierra.  We should add
> platform-specific apple install for Sierra, whose users may not even
> care about the AIO anyway.  But others will..

The Sierra thing is (apart from the VM problem due to Apple not being able to communicate)
that Apple decided to place AppBundles that are just downloaded or unpacked in the Downloads
folder are put into a _read only temporary_ location before run so we can no longer open 
images/changes read-write. How should we solve this?
 - Put the app-bundle in a read-only DMG and have the user move it somewhere else when
   opening the DMG. Thats the only way that reliably works. And that would _Also_ work for
   all other macOS or OS X versions.

So to summarise:
 - The problems with 32/64bit and heartbeat thread activation would only reliably be solved by
   providing system packages (debs/rpms with proper dependencies) for Linux distributions
   (==> not AOI-able)
 - The problem with OS X would only reliably be solved by providing the AppBundle in a
   read-only DMG. (==> not AOI-able as nobody else can open DMGs)
 - That leaves Windows, wich would tremendously benefit from cleaned-up directory structure
   (or a proper installer, for that matter, which wouldn't be too hard. Etoys did that)

I sure see  the value of an AOI (Etoys nicely names it 'Etoys to go', which I find a better name anyway)

So if someone comes up with _better_ solutions to the problems mentioned above, sure, lets do it.

But currently, we only frustrate newcomers.

Best regards
	-Tobias

> 
> On Mon, Feb 27, 2017 at 3:39 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> Ah I forgot:
>> 
>> On 27.02.2017, at 13:00, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>>> Hi,
>>> 
>> 
>> Motivation:
>> - This thread: http://forum.world.st/Attempting-to-run-Squeak-all-in-one-download-on-ubuntu-linux-tt4936001.html
>> - This issue: https://github.com/dalehenrich/metacello-work/issues/427#issuecomment-281919088
>> - This thread: http://forum.world.st/Problem-with-Squeak5-1-16549-32bit-All-in-One-tp4935860.html
>> - This thread: http://forum.world.st/Squeak5-1rc2-16535-32bit-fail-to-open-in-macOS-Sierra-tp4934524.html
>> All these are at lease partially because of the way AIOs work and how we deliver them
>> 
>> Moreover:
>> - This old post: http://forum.world.st/All-in-ones-tp4662358p4662665.html
>> - My experience from building All-in-ones for Seaside and for bi-annual courses at HPI that use Squeak.
>> 
>> 
>> Also:
>> - It does not work on ARM/RaspberryPi
>> - It does not work on BSDen (yes, I know it's rare)
>> - It does not work on RISC OS (Sorry, tim)
>> * Points above are no problem _individually_ (again, sorry, tim), but in their combination.
>> 
>>> here's a bullet point list:
>>> - macOS Sierra needs a special vm compared w/ previous ones
>>> - macOS Sierra makes it hard to _just run_ downloaded bundles/All-in-ones
>>> - all-in-ones look ugly since Yosemite due to new requiremens for code signing.
>>> - we have some indirection in the shell scripts for the linux variant
>>> - we still have this strange LD_LIBRARY_PATH dance that apparently fails on
>>>  newest Ubuntu (see recent mail)
>>> - occasionally, we have people from BSDen who also want to use Squeak.
>>> 
>>> So, I'd propose:
>>> - Ditch the AOIs.
>>> - Deliver macOS bundles as DMG, not as Zip, so as to force people to
>>>  move the bundle, so that macOS Sierra is happy to run stuff.
>>> In the long run:
>>> - Provide deb's and rpm's
>>> 
>>> 
>>> Best regards
>>>      -Tobias
>>> 
>> 
>> 
>