On 27.02.2017, at 21:01, Chris Muller asqueaker@gmail.com wrote:

-1 to ditching the All-In-One. Freedom is being able to simply run a binary out of a folder.

Yes, then just download the one for your platform.

If one platform requires a special bundle, then it'll require it in any case, but we should still also keep generating the All-In-One for everybody else.

The AIO is getting cumbersome to build, codesign, and correctly use for different platforms. It is ludicrous that we point people to a .bat file on Windows, just because macOS demands its top folder to be clean. And the .app bundle is confusing on all but macOS. And how do we introduce snaps[1] in the AIO.

Currently, we have this:

Let's just have this:

There's currently no actual advantage in having the AIO apart from supporting people like me who are reluctant decision makers… ;)

Let's be frank, putting the AIO on an USB stick and running from that on different platform is really really seldom…

Best regards -Tobias

[1]: https://www.ubuntu.com/desktop/snappy

On Mon, Feb 27, 2017 at 6:00 AM, Tobias Pape Das.Linux@gmx.de wrote:

...

Hi,

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

Currently the all-in-one is packaged to look like an application on macOS, which is very clever but seems to make for many problems. Does it actually need to be like that?

Would it work if we simply made our all-in-one package be a directory with the image/changes/sources and subdirectories for each vm? Hmm, well there is a possible issue with 32/64 bit confusion - ok, so how about something like / SqueakMac.app SqueakWindows.bat SqueakLinux.sh .. Ubuntu etc as required /data squeak.image squeak.changes squeak.sources /vm /linux /windows

So you see scripts relating to your OS. They start up the appropriate stuff. They ought to be able to work out 64bitness.

We also really should work on the startup experience some more. Marcel added some nice beginnings for 5.1 but I have always strongly believed that the default image needs to be locked and set up such that pretty much the first (or even only!) thing you can do is save a new image to actually work on. Hooking up a file location chooser instead of a simple singe line text entry box would help quite a lot there.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Logic: The art of being wrong with confidence...

I'd suggest to start a new GitHub repo and use TravisCI to generate and deploy the deb/rpm to Launchpad. Happy to help setting this up...

Fabio

A big, important thing that is just plain Wrong, with a capital Duh, is that when using the mac package (or AiO) when you save an image it goes into the Contents/Resources folder, buried deep within the application file where *no one will ever find it*. Re-running the application in an attempt to get back to your work simply (and arguably correctly) runs the default image.

No.

Just fricken no.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."

On 28.02.2017, at 03:27, tim Rowledge tim@rowledge.org wrote:

A big, important thing that is just plain Wrong, with a capital Duh, is that when using the mac package (or AiO) when you save an image it goes into the Contents/Resources folder, buried deep within the application file where *no one will ever find it*. Re-running the application in an attempt to get back to your work simply (and arguably correctly) runs the default image.

No.

Just fricken no.

Yep. We should adopt a copy-default-image-to-know-location-and-run-from-there-subsequently-if-no-image-given-on-commandline :D

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "E=Mc^5...nahhh...E=Mc^4...nahh...E=Mc^3...ah, the hell with it."

On 28.02.2017, at 03:14, Chris Muller asqueaker@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@gmx.de wrote:

...

Ah I forgot:

On 27.02.2017, at 13:00, Tobias Pape Das.Linux@gmx.de wrote:

...

Hi,

Motivation:

• This thread: http://forum.world.st/Attempting-to-run-Squeak-all-in-one-download-on-ubuntu...
• This issue: https://github.com/dalehenrich/metacello-work/issues/427#issuecomment-281919...
• This thread: http://forum.world.st/Problem-with-Squeak5-1-16549-32bit-All-in-One-tp493586...
• This thread: http://forum.world.st/Squeak5-1rc2-16535-32bit-fail-to-open-in-macOS-Sierra-...

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