Squeak-4.5-All-In-One.zip
Locked
 
|
[hidden email] has shared the following file:  Okay, I went back to the one in Craig's dropbox to preserve all the file permissions, then simply re-fixed the squeak.ini and added in the two shortcuts.Tested on Linux and Windows, just need Mac signing and testing. Thanks again.
|
|
|
> ...just need Mac signing and testing. Okay, tested on Linux, Windows, and Mac, and Apple-signed. http://bit.ly/1s5VkpV (Dropbox). -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
Hi Craig
On 12.10.2014, at 01:44, Craig Latta <[hidden email]> wrote: >> ...just need Mac signing and testing. > > Okay, tested on Linux, Windows, and Mac, and Apple-signed. > > http://bit.ly/1s5VkpV (Dropbox). The app does not run for me: $ spctl -a -t exec -vv Squeak-4.5-All-in-One.app Squeak-4.5-All-in-One.app: rejected source=no usable signature could that have to do with changes in 10.9.5[1]? Best -Tobias [1]: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205 |
|
|
> The app does not run for me: > > $ spctl -a -t exec -vv Squeak-4.5-All-in-One.app > Squeak-4.5-All-in-One.app: rejected > source=no usable signature > > could that have to do with changes in 10.9.5? Hm, I don't have an older MacOS to check when this started, but the situation with regard to creating and expanding ZIP archives without messing with the signature/contents correlation has become annoying (as I thought it might). For the signature to be valid, the .app directory has to be compressed and uncompressed by itself (no siblings), and it has to be done with the Mac Finder GUI (not from zip/unzip on the command line, in either MacOS or another OS that has access to the filesystem). So... the release is now a ZIP archive that contains the two non-Mac launch scripts, along with another ZIP archive which contains the .app directory. This also means that non-Mac users will get the "__MAC" and ".DS_Store" debris after uncompressing, as well. I still think all this is tolerable. However, I'll say again here that I strongly prefer having the .app directory be the root of our release artifact, a totally self-contained thing, and leaving it to users to set up launch shortcuts appropriate to their local system (given a directory structure that is obvious enough for them to realize how to do it). When the release has other stuff at a sibling or higher level than the .app directory, I think people are more likely to think, mistakenly, that they can duplicate, copy, rename, and move things around without breaking them. I realize I disagree with the 4.5 release manager (Chris) on this, but I still want to be on record. New bits at [1]. thanks, -C [1] http://bit.ly/1CBwx1I (Dropbox) -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
re: Squeak-4.5-All-in-One.zip
|
|
Hi Craig,
On Sun, Oct 12, 2014 at 1:08 PM, Craig Latta <[hidden email]> wrote:
I have a 10.6.8 machine. I'm checking this now. For the signature to be valid, the .app directory has to be Why uncompressed by itself? If one uncompresses an archive containing a foo.app with a bar sibling, that will surely produce exactly the same bits in foo.app as uncompressing an archive that contains only foo.app. The decompression program would be broken if it creates different bits, right? So... If the archive is created in two steps, the first as you state including only Squeak-4.5-All-in-One.app, using the finder, and then, via the command line using zip -u to add the siblings how can that not work? It can't produce a different Squeak-4.5-All-in-One.app without zip being hopelessly broken, which it isn't, right?
It doesn't have to be this way. Use zip -u to add the siblings at a later date.
Craig, you are a decent human being, but your attitude on this is so discourteous to users. Why *should* they have to unpack and decode the structure of a .app, especially when they might be WIndows or Linux users only. Why don't you see it as an obligation to provide a pleasant and simple install step to that community rather than asking them to perform a manual step? I don't understand. I want to go on record therefore that I think providing the scripts is important, especially for newbies, a group we surely want to appeal to. When the release has other stuff at a sibling or higher best, Eliot
|
re: Squeak-4.5-All-in-One.zip
|
|
On Sun, Oct 12, 2014 at 6:12 PM, Eliot Miranda <[hidden email]> wrote:
and the app runs just fine on 10.6.8.
best, Eliot
|
|
|
On 13.10.2014, at 03:14, Eliot Miranda <[hidden email]> wrote: > On Sun, Oct 12, 2014 at 6:12 PM, Eliot Miranda <[hidden email]> wrote: > Hi Craig, > > On Sun, Oct 12, 2014 at 1:08 PM, Craig Latta <[hidden email]> wrote: > > > The app does not run for me: > > > > $ spctl -a -t exec -vv Squeak-4.5-All-in-One.app > > Squeak-4.5-All-in-One.app: rejected > > source=no usable signature > > > > could that have to do with changes in 10.9.5? > > Hm, I don't have an older MacOS to check when this started, but the > situation with regard to creating and expanding ZIP archives without > messing with the signature/contents correlation has become annoying (as > I thought it might). > > I have a 10.6.8 machine. I'm checking this now. > > and the app runs just fine on 10.6.8. Then it might be a “version 1 vs Version 2 signature” as in the Apple note... > > > For the signature to be valid, the .app directory has to be > compressed and uncompressed by itself (no siblings), and it has to be > done with the Mac Finder GUI (not from zip/unzip on the command line, in > either MacOS or another OS that has access to the filesystem). > > Why uncompressed by itself? If one uncompresses an archive containing a foo.app with a bar sibling, that will surely produce exactly the same bits in foo.app as uncompressing an archive that contains only foo.app. The decompression program would be broken if it creates different bits, right? So... > > If the archive is created in two steps, the first as you state including only Squeak-4.5-All-in-One.app, using the finder, and then, via the command line using zip -u to add the siblings how can that not work? It can't produce a different Squeak-4.5-All-in-One.app without zip being hopelessly broken, which it isn't, right? > > > So... the release is now a ZIP archive that contains the two > non-Mac launch scripts, along with another ZIP archive which contains > the .app directory. This also means that non-Mac users will get the > "__MAC" and ".DS_Store" debris after uncompressing, as well. > > It doesn't have to be this way. Use zip -u to add the siblings at a later date. > > > I still think all this is tolerable. However, I'll say again here > that I strongly prefer having the .app directory be the root of our > release artifact, a totally self-contained thing, and leaving it to > users to set up launch shortcuts appropriate to their local system > (given a directory structure that is obvious enough for them to realize > how to do it). > > Craig, you are a decent human being, but your attitude on this is so discourteous to users. Why *should* they have to unpack and decode the structure of a .app, especially when they might be WIndows or Linux users only. Why don't you see it as an obligation to provide a pleasant and simple install step to that community rather than asking them to perform a manual step? I don't understand. I want to go on record therefore that I think providing the scripts is important, especially for newbies, a group we surely want to appeal to. > > When the release has other stuff at a sibling or higher > level than the .app directory, I think people are more likely to think, > mistakenly, that they can duplicate, copy, rename, and move things > around without breaking them. I realize I disagree with the 4.5 release > manager (Chris) on this, but I still want to be on record. > > New bits at [1]. > > > thanks, > > -C > > [1] http://bit.ly/1CBwx1I (Dropbox) |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot-- > Why uncompressed by itself? If one uncompresses an archive > containing a foo.app with a bar sibling, that will surely produce > exactly the same bits in foo.app as uncompressing an archive that > contains only foo.app. The decompression program would be broken if > it creates different bits, right? So... > > If the archive is created in two steps, the first as you state > including only Squeak-4.5-All-in-One.app, using the finder, and then, > via the command line using zip -u to add the siblings how can that > not work? It can't produce a different Squeak-4.5-All-in-One.app > without zip being hopelessly broken, which it isn't, right? Hey, I don't claim knowledge of why MacOS 10.9.5 behaves as it does, or that it should behave as it does (in fact, it seems rather stupid). I'm only relaying that, as far as I can tell: - If you sign the .app, then make a ZIP archive with the .app folder and the scripts as siblings, then unarchive it, then MacOS 10.9.5 Gatekeeper rejects the signature (unless you have Gatekeeper turned off). - If you use anything other than the Mac Finder GUI to make the archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the signature (unless you have Gatekeeper turned off). > > ...the release is now a ZIP archive that contains the two non-Mac > > launch scripts, along with another ZIP archive which contains the > > .app directory. This also means that non-Mac users will get the > > "__MAC" and ".DS_Store" debris after uncompressing, as well. > > It doesn't have to be this way. Use zip -u to add the siblings at a > later date. No; it's the Mac-Finder-GUI way of making the ZIP that adds the debris, apparently. At that later date, you've already lost, either by using the Mac Finder GUI to make the ZIP (and getting a good signature on open, and debris) or making the ZIP some other way (and getting a bad signature on open). > > I still think all this is tolerable. However, I'll say again here > > that I strongly prefer having the .app directory be the root of our > > release artifact, a totally self-contained thing, and leaving it to > > users to set up launch shortcuts appropriate to their local system > > (given a directory structure that is obvious enough for them to > > realize how to do it). > > Craig, you are a decent human being but... Yikes, Eliot. I don't think any of this has anything to do with what kind of human beings we are, and making that part of the discussion is hyperbolic to the point of histrionic. Please calm down? > ...your attitude on this is so discourteous to users. Clearly we disagree about that. Specifically, the new users with whom I have worked see the expression of a clear boundary as to what can be moved around and renamed as a courtesy. > Why *should* they have to unpack and decode the structure of a .app... Indeed, I would prefer that they not have to do that (I don't even like having to use ".app" in a directory name). I see a tradeoff between that and running into confusion later over where each piece of the release artifact is supposed to live, and what it can be named. I think the lesser evil here, and the greater courtesy, is for the release artifact to be a self-contained directory. I realize we disagree. > ...especially when they might be Windows or Linux users only? ...and Mac users who prefer to use the command line. In the Appsterdam community here, I'd say there's an even split between Mac devs who prefer the command line and those who don't. They are all newcomers to Squeak. I use all the host platforms on which Squeak runs, regularly. I'm exploring how to make an all-in-one release artifact in the least contorted way. I don't think anything I've suggested is a slight against the users of any of the platforms/usage configurations. (What I *really* want, in addition to what we've done so far, is the option to install the system, launch it, stop it, etc., from a web browser. It would be something like the system launchers in Parallels and VMWare. But security constraints on all the platforms pretty much force us to have the user handle a downloaded ZIP file directly.) > Why don't you see it as an obligation to provide a pleasant and > simple install step to that community rather than asking them to > perform a manual step? On the contrary, I do see an obligation to make the installation process as pleasant as it can be. Those users are already performing manual steps: downloading the ZIP file manually, unpacking it manually, and putting the contents somewhere in their filesystem manually (especially in the use case you seem to care about most, putting the contents in a directory which is already in their executables search path). Given that they are already performing these manual steps, I don't see what I propose as onerous. I'm curious as to why you didn't say anything sooner, after the all-in-one approach started years ago. > I want to go on record therefore that I think providing the scripts > is important, especially for newbies, a group we surely want to > appeal to. Yes, we surely want to appeal to newbies. I think equating disagreeing with you on this with neglecting newbies is disingenuous. Anyway, yeesh. The decision was up to Chris and he made it (and he agrees with you); this issue is over, for 4.5 anyway. I don't see a lack of unanimity about it as a dire thing. Let's debate namespaces and modules instead. :) thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
Hi,
On 13.10.2014, at 16:19, Craig Latta <[hidden email]> wrote: > > Hi Eliot-- > >> Why uncompressed by itself? If one uncompresses an archive >> containing a foo.app with a bar sibling, that will surely produce >> exactly the same bits in foo.app as uncompressing an archive that >> contains only foo.app. The decompression program would be broken if >> it creates different bits, right? So... >> >> If the archive is created in two steps, the first as you state >> including only Squeak-4.5-All-in-One.app, using the finder, and then, >> via the command line using zip -u to add the siblings how can that >> not work? It can't produce a different Squeak-4.5-All-in-One.app >> without zip being hopelessly broken, which it isn't, right? > > Hey, I don't claim knowledge of why MacOS 10.9.5 behaves as it > does, or that it should behave as it does (in fact, it seems rather > stupid). I'm only relaying that, as far as I can tell: > > - If you sign the .app, then make a ZIP archive with the .app folder > and the scripts as siblings, then unarchive it, then MacOS 10.9.5 > Gatekeeper rejects the signature (unless you have Gatekeeper > turned off). > > - If you use anything other than the Mac Finder GUI to make the > archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the > signature (unless you have Gatekeeper turned off). > >>> ...the release is now a ZIP archive that contains the two non-Mac >>> launch scripts, along with another ZIP archive which contains the >>> .app directory. This also means that non-Mac users will get the >>> "__MAC" and ".DS_Store" debris after uncompressing, as well. >> >> It doesn't have to be this way. Use zip -u to add the siblings at a >> later date. > > No; it's the Mac-Finder-GUI way of making the ZIP that adds the > debris, apparently. At that later date, you've already lost, either by > using the Mac Finder GUI to make the ZIP (and getting a good signature > on open, and debris) or making the ZIP some other way (and getting a bad > signature on open). > This is because the codesgining will store some stuff in resource files, which are only preserved if ._stuff files or __MACOSX folders are present. >>> I still think all this is tolerable. However, I'll say again here >>> that I strongly prefer having the .app directory be the root of our >>> release artifact, a totally self-contained thing, and leaving it to >>> users to set up launch shortcuts appropriate to their local system >>> (given a directory structure that is obvious enough for them to >>> realize how to do it). >> >> Craig, you are a decent human being but... > > Yikes, Eliot. I don't think any of this has anything to do with > what kind of human beings we are, and making that part of the discussion > is hyperbolic to the point of histrionic. Please calm down? > >> ...your attitude on this is so discourteous to users. > > Clearly we disagree about that. Specifically, the new users with > whom I have worked see the expression of a clear boundary as to what can > be moved around and renamed as a courtesy. > >> Why *should* they have to unpack and decode the structure of a .app... > > Indeed, I would prefer that they not have to do that (I don't even > like having to use ".app" in a directory name). I see a tradeoff between > that and running into confusion later over where each piece of the > release artifact is supposed to live, and what it can be named. I think > the lesser evil here, and the greater courtesy, is for the release > artifact to be a self-contained directory. I realize we disagree. > >> ...especially when they might be Windows or Linux users only? > > ...and Mac users who prefer to use the command line. In the > Appsterdam community here, I'd say there's an even split between Mac > devs who prefer the command line and those who don't. They are all > newcomers to Squeak. > > I use all the host platforms on which Squeak runs, regularly. I'm > exploring how to make an all-in-one release artifact in the least > contorted way. I don't think anything I've suggested is a slight against > the users of any of the platforms/usage configurations. > > (What I *really* want, in addition to what we've done so far, is > the option to install the system, launch it, stop it, etc., from a web > browser. It would be something like the system launchers in Parallels > and VMWare. But security constraints on all the platforms pretty much > force us to have the user handle a downloaded ZIP file directly.) > >> Why don't you see it as an obligation to provide a pleasant and >> simple install step to that community rather than asking them to >> perform a manual step? > > On the contrary, I do see an obligation to make the installation > process as pleasant as it can be. Those users are already performing > manual steps: downloading the ZIP file manually, unpacking it manually, > and putting the contents somewhere in their filesystem manually > (especially in the use case you seem to care about most, putting the > contents in a directory which is already in their executables search > path). Given that they are already performing these manual steps, I > don't see what I propose as onerous. > > I'm curious as to why you didn't say anything sooner, after the > all-in-one approach started years ago. > >> I want to go on record therefore that I think providing the scripts >> is important, especially for newbies, a group we surely want to >> appeal to. > > Yes, we surely want to appeal to newbies. I think equating > disagreeing with you on this with neglecting newbies is disingenuous. > > Anyway, yeesh. The decision was up to Chris and he made it (and he > agrees with you); this issue is over, for 4.5 anyway. I don't see a lack > of unanimity about it as a dire thing. Let's debate namespaces and > modules instead. :) > > > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > |
|
|
In reply to this post by ccrraaiigg
Okay, so I actually had posted the prior one you gave me to the FTP
site, the one without the embedded Zip, before I saw this new one, WITH the embedded zip. Between Tobias' and Eliot's responses, Tobias> The app does not run for me: Eliot> and the app runs just fine on 10.6.8. Tobias> Then it might be a “version 1 vs Version 2 signature” as in the Apple note... I can't tell what our status is. Can the one Craig signed and I posted (w/o the embedded zip) be run by Mac users or not? >> Why uncompressed by itself? If one uncompresses an archive >> ...snip... >> > - If you sign the .app, then make a ZIP archive with the .app folder > and the scripts as siblings, then unarchive it, then MacOS 10.9.5 > Gatekeeper rejects the signature (unless you have Gatekeeper > turned off). Can't you sign the .app + the two scripts together? > - If you use anything other than the Mac Finder GUI to make the > archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the > signature (unless you have Gatekeeper turned off). > >> > ...the release is now a ZIP archive that contains the two non-Mac >> > launch scripts, along with another ZIP archive which contains the >> > .app directory. This also means that non-Mac users will get the >> > "__MAC" and ".DS_Store" debris after uncompressing, as well. >> >> It doesn't have to be this way. Use zip -u to add the siblings at a >> later date. > > No; it's the Mac-Finder-GUI way of making the ZIP that adds the > debris, apparently. At that later date, you've already lost, either by > using the Mac Finder GUI to make the ZIP (and getting a good signature > on open, and debris) or making the ZIP some other way (and getting a bad > signature on open). > >> > I still think all this is tolerable. However, I'll say again here >> > that I strongly prefer having the .app directory be the root of our >> > release artifact, a totally self-contained thing, and leaving it to >> > users to set up launch shortcuts appropriate to their local system >> > (given a directory structure that is obvious enough for them to >> > realize how to do it). You keep mentioning this feature about setting up custom launch shortcuts but ignoring my rebuttal that the audience the All-In-One is designed for is for newbies. Newbies are the ones who have only just heard about Squeak and are saying, "Just Show Me Squeak Right Fucking Now". The group you're referring to, who wants to unzip the All-In-One, and then set it up in custom locations with shortcuts for repeated access over the long-term, those folks are not who the All-In-One is targeting. Besides that, the shortcut scripts are not an impediment to doing what you said anyway. If anything, they "document" where and how to launch it and so if they want to move them to a different place, they'll know how. The type of person who is adventurous enough to customize it will not "fold" and whine "hey it didn't work when I moved / renamed / whatever." In fact, they would probably find the documentation on squeak.org about the invididual components (.image, .changes, vm, .sources) and set it up truly custom, and now this person is a totally disparate audience from the All-In-One audience. > ...snip... > >> Why don't you see it as an obligation to provide a pleasant and >> simple install step to that community rather than asking them to >> perform a manual step? > > On the contrary, I do see an obligation to make the installation > process as pleasant as it can be. Those users are already performing > manual steps: downloading the ZIP file manually, unpacking it manually, Done at this point. Once unpacked, it's ready to run. > and putting the contents somewhere in their filesystem manually > (especially in the use case you seem to care about most, putting the > contents in a directory which is already in their executables search > path). No, the $PATH variable has nothing to do with launching Squeak from the All-In-One. This makes no sense to me.. > Given that they are already performing these manual steps, I > don't see what I propose as onerous. If I downloaded a ZIP and I found another Zip inside it, I would think that the .sh and .bat were things that would unpack that zip FOR ME. Assuming I figured out that was wrong,I would then wonder am I supposed to put this inner-zip? In the same directory or can it stand alone elsewhere? If it has to be in teh same dir, then why the fuck didn't the authors just put it that way? It's totally confusing, irritating, and repelling. Exactly the opposites we want newbies to feel. The goal is to get them into the image as quickly and easily as possible. >> I want to go on record therefore that I think providing the scripts >> is important, especially for newbies, a group we surely want to >> appeal to. > > Yes, we surely want to appeal to newbies. I think equating > disagreeing with you on this with neglecting newbies is disingenuous. C'mon. When Eliot said you are a decent human being, he was simply expressing his disagreement in a way that was trying to avoid you becoming upset. It appears he failed, but at least he tried. > Anyway, yeesh. The decision was up to Chris and he made it (and he > agrees with you); this issue is over, for 4.5 anyway. I don't see a lack > of unanimity about it as a dire thing. Let's debate namespaces and > modules instead. :) I appreciate that, but I don't know if we've made any progress whatsoever from the original post though, which expressed that the All-In-One was having trouble for Mac users.. I have no Mac. What's our status of the one that's there now? > > > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > |
|
|
In reply to this post by ccrraaiigg
Having watched the recent discussions about troubles with the all-in-one release, I'd just like to make the observation that it might be time to forget the all-in-one. I personally don't like to have to download a bunch of extra large files if I just am interested in the release for a certain platform. And cluttering up the Mac .app folder with other stuff for other platforms just seems somehow really wrong.
In my opinion it is pretty easy for a newbie to decide up front whether to download for Windows, Linux or Mac and have a nicely tailored install for that platform. My vote is to streamline the release process by dropping the all-in-one and just have separate downloads for each platform. Ken G. Brown, from my iPhone > On Oct 13, 2014, at 08:19, Craig Latta <[hidden email]> wrote: > > > Hi Eliot-- > >> Why uncompressed by itself? If one uncompresses an archive >> containing a foo.app with a bar sibling, that will surely produce >> exactly the same bits in foo.app as uncompressing an archive that >> contains only foo.app. The decompression program would be broken if >> it creates different bits, right? So... >> >> If the archive is created in two steps, the first as you state >> including only Squeak-4.5-All-in-One.app, using the finder, and then, >> via the command line using zip -u to add the siblings how can that >> not work? It can't produce a different Squeak-4.5-All-in-One.app >> without zip being hopelessly broken, which it isn't, right? > > Hey, I don't claim knowledge of why MacOS 10.9.5 behaves as it > does, or that it should behave as it does (in fact, it seems rather > stupid). I'm only relaying that, as far as I can tell: > > - If you sign the .app, then make a ZIP archive with the .app folder > and the scripts as siblings, then unarchive it, then MacOS 10.9.5 > Gatekeeper rejects the signature (unless you have Gatekeeper > turned off). > > - If you use anything other than the Mac Finder GUI to make the > archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the > signature (unless you have Gatekeeper turned off). > >>> ...the release is now a ZIP archive that contains the two non-Mac >>> launch scripts, along with another ZIP archive which contains the >>> .app directory. This also means that non-Mac users will get the >>> "__MAC" and ".DS_Store" debris after uncompressing, as well. >> >> It doesn't have to be this way. Use zip -u to add the siblings at a >> later date. > > No; it's the Mac-Finder-GUI way of making the ZIP that adds the > debris, apparently. At that later date, you've already lost, either by > using the Mac Finder GUI to make the ZIP (and getting a good signature > on open, and debris) or making the ZIP some other way (and getting a bad > signature on open). > >>> I still think all this is tolerable. However, I'll say again here >>> that I strongly prefer having the .app directory be the root of our >>> release artifact, a totally self-contained thing, and leaving it to >>> users to set up launch shortcuts appropriate to their local system >>> (given a directory structure that is obvious enough for them to >>> realize how to do it). >> >> Craig, you are a decent human being but... > > Yikes, Eliot. I don't think any of this has anything to do with > what kind of human beings we are, and making that part of the discussion > is hyperbolic to the point of histrionic. Please calm down? > >> ...your attitude on this is so discourteous to users. > > Clearly we disagree about that. Specifically, the new users with > whom I have worked see the expression of a clear boundary as to what can > be moved around and renamed as a courtesy. > >> Why *should* they have to unpack and decode the structure of a .app... > > Indeed, I would prefer that they not have to do that (I don't even > like having to use ".app" in a directory name). I see a tradeoff between > that and running into confusion later over where each piece of the > release artifact is supposed to live, and what it can be named. I think > the lesser evil here, and the greater courtesy, is for the release > artifact to be a self-contained directory. I realize we disagree. > >> ...especially when they might be Windows or Linux users only? > > ...and Mac users who prefer to use the command line. In the > Appsterdam community here, I'd say there's an even split between Mac > devs who prefer the command line and those who don't. They are all > newcomers to Squeak. > > I use all the host platforms on which Squeak runs, regularly. I'm > exploring how to make an all-in-one release artifact in the least > contorted way. I don't think anything I've suggested is a slight against > the users of any of the platforms/usage configurations. > > (What I *really* want, in addition to what we've done so far, is > the option to install the system, launch it, stop it, etc., from a web > browser. It would be something like the system launchers in Parallels > and VMWare. But security constraints on all the platforms pretty much > force us to have the user handle a downloaded ZIP file directly.) > >> Why don't you see it as an obligation to provide a pleasant and >> simple install step to that community rather than asking them to >> perform a manual step? > > On the contrary, I do see an obligation to make the installation > process as pleasant as it can be. Those users are already performing > manual steps: downloading the ZIP file manually, unpacking it manually, > and putting the contents somewhere in their filesystem manually > (especially in the use case you seem to care about most, putting the > contents in a directory which is already in their executables search > path). Given that they are already performing these manual steps, I > don't see what I propose as onerous. > > I'm curious as to why you didn't say anything sooner, after the > all-in-one approach started years ago. > >> I want to go on record therefore that I think providing the scripts >> is important, especially for newbies, a group we surely want to >> appeal to. > > Yes, we surely want to appeal to newbies. I think equating > disagreeing with you on this with neglecting newbies is disingenuous. > > Anyway, yeesh. The decision was up to Chris and he made it (and he > agrees with you); this issue is over, for 4.5 anyway. I don't see a lack > of unanimity about it as a dire thing. Let's debate namespaces and > modules instead. :) > > > thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > |
|
|
In reply to this post by Tobias Pape
Hoi-- Tobias writes: > This is because the codesigning will store some stuff in resource > files, which are only preserved if ._stuff files or __MACOSX folders > are present. I can believe that. I haven't looked into the details of what the signing actually does. *** Chris writes: > Okay, so I actually had posted the prior one you gave me to the FTP > site, the one without the embedded Zip, before I saw this new one, > WITH the embedded zip. > > Between Tobias' and Eliot's responses, > > Tobias> The app does not run for me: > Eliot> and the app runs just fine on 10.6.8. > Tobias> Then it might be a “version 1 vs Version 2 signature” as in > Tobias> the Apple note... > > I can't tell what our status is. Can the one Craig signed and I > posted (w/o the embedded zip) be run by Mac users or not? Apparently it's fine on 10.6.8, where Gatekeeper doesn't exist (Apple introduced it in MacOS 10.7.5, see [1]). On MacOS 10.9.5, Gatekeeper rejects the signature. > Can't you sign the .app + the two scripts together? No; well, not with the scripts where you want them. The thing being signed has to conform to a particular Apple "bundle" format, which wants everything to be rooted in the .app directory. There are a bunch of other constraints, too, most prominently for us the one about arbitrary stuff disallowed in .app/Contents. That's what got this whole conversation started. > You keep mentioning this feature about setting up custom launch > shortcuts but ignoring my rebuttal that the audience the All-In-One is > designed for is for newbies. I'm not ignoring anything you'd said, we simply disagree. In particular, we disagree about how much to treat a Squeak newbie like a newbie with regard to their host platform. > Newbies are the ones who have only just heard about Squeak and are > saying, "Just Show Me Squeak Right Fucking Now". Was that profanity really necessary? Anyway, the way things were a month ago, command-line and Windows Squeak newbies were already having to go into the .app folder to start Squeak. They had to have exactly as much host platform knowledge before the Gatekeeper-caused change as after. > The group you're referring to, who wants to unzip the All-In-One, and > then set it up in custom locations with shortcuts for repeated access > over the long-term, those folks are not who the All-In-One is > targeting. That's not the use case I get from Eliot. His *primary* concern in the 2014-10-02 board meeting was that someone could put the contents of the ZIP in a place already included in their search paths (like /usr/local/bin), and then "just type the name of the script" to run Squeak. > Eliot> Why don't you see it as an obligation to provide a pleasant and > Eliot> simple install step to that community rather than asking them > Eliot> to perform a manual step? > > Craig> On the contrary, I do see an obligation to make the > Craig> installation process as pleasant as it can be. Those users are > Craig> already performing manual steps: downloading the ZIP file > Craig> manually, unpacking it manually... > > Done at this point. Once unpacked, it's ready to run. Not to Eliot's satisfaction as I understood it in the 2014-10-02 board meeting, no. He wanted the results of the installation to include a script in one of his search paths, so that he could type the name of the script from a shell with an arbitrary working directory, and have it run. For that to happen, the installation must include putting the contents of the ZIP in a particular place (like /usr/local/bin). > No, the $PATH variable has nothing to do with launching Squeak from > the All-In-One. This makes no sense to me.. Hey, this is just what I heard Eliot saying. Apparently you heard something else. There's another board meeting on Thursday... > If I downloaded a ZIP and I found another Zip inside it, I would think > that the .sh and .bat were things that would unpack that zip FOR ME. Great, we can make them do that. > If it has to be in teh same dir, then why the fuck didn't the authors > just put it that way? Chris, please calm down. This issue is already settled, and by you no less. I only wanted to speak my view for the record. Why don't you just let my dissenting comments stand and move on? I don't understand why you're getting so upset about this. > I don't know if we've made any progress whatsoever from the original > post though, which expressed that the All-In-One was having trouble > for Mac users. We've made substantial progress: we've figured out how to make a ZIP file which jumps through all the hoops set for it. The latest one I made is such a ZIP, at [2]. The one currently on squeak.org, as I discussed in detail above, is not (bad signature). Apparently we should make one more version with Linux and Windows scripts that unzip the .app folder if it hasn't been unzipped already, or forget the all-in-one approach altogether (or forget about Apple signatures :). *** Ken G. Brown writes: > Having watched the recent discussions about troubles with the > all-in-one release, I'd just like to make the observation that it > might be time to forget the all-in-one. I personally don't like to > have to download a bunch of extra large files if I just am interested > in the release for a certain platform. And cluttering up the Mac .app > folder with other stuff for other platforms just seems somehow really > wrong. As I said in [3], an all-in-one release gives users the significant convenience of having a single artifact to take between platforms. I actually do meet new users who care about platform portability. We can also make the Squeak app manage multiple user images, so users need not have multiple copies of the Squeak app around just to run multiple images, nor need to understand any conventions about the Resources folder. That makes having a single artifact that can move between platforms even more valuable. > In my opinion it is pretty easy for a newbie to decide up front > whether to download for Windows, Linux or Mac and have a nicely > tailored install for that platform. Sure; if it were up to me I'd do all four: Windows, Linux, Mac, and all-in-one. thanks, -C [1] https://en.wikipedia.org/wiki/Gatekeeper_(OS_X) [2] http://bit.ly/1CBwx1I (Dropbox) [3] http://bit.ly/ZXYW4u (lists.squeakfoundation.org) -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
>> Can't you sign the .app + the two scripts together?
> > No; well, not with the scripts where you want them. The thing being > signed has to conform to a particular Apple "bundle" format, which wants > everything to be rooted in the .app directory. Could the scripts be placed in the .app directory then, as siblings of the Contents dir? >> ... >> Newbies are the ones who have only just heard about Squeak and are >> saying, "Just Show Me Squeak Right Fucking Now". > > Was that profanity really necessary? It (and the double-quotes and capitalization) was me portraying the use-case from the actor's POV, a grumpy-newbie, to emphasize the importance of the newbies "first kiss" impression of Squeak. >> The group you're referring to, who wants to unzip the All-In-One, and >> then set it up in custom locations with shortcuts for repeated access >> over the long-term, those folks are not who the All-In-One is >> targeting. > > That's not the use case I get from Eliot. His *primary* concern in > the 2014-10-02 board meeting was that someone could put the contents of > the ZIP in a place already included in their search paths (like > /usr/local/bin), and then "just type the name of the script" to run Squeak. Okay. We'll have to ask Eliot about that. To me, that use-case is secondary to the more important one (above) to get the grumpy-newbie kissing instead of cussing. >> If I downloaded a ZIP and I found another Zip inside it, I would think >> that the .sh and .bat were things that would unpack that zip FOR ME. > > Great, we can make them do that. > >> If it has to be in teh same dir, then why the fuck didn't the authors >> just put it that way? > > Chris, please calm down. (I was simply role playing the primary actor of this use-case again, the grumpy-newbie). >> I don't know if we've made any progress whatsoever from the original >> post though, which expressed that the All-In-One was having trouble >> for Mac users. > > We've made substantial progress: we've figured out how to make a > ZIP file which jumps through all the hoops set for it. The latest one I > made is such a ZIP, at [2]. Earlier in this thread, you wrote: ---------- Craig> For the signature to be valid, the .app directory has to be compressed and uncompressed by itself (no siblings), and it has to be done with the Mac Finder GUI (not from zip/unzip on the command line, in either MacOS or another OS that has access to the filesystem). Craig> So... the release is now a ZIP archive that contains the two non-Mac launch scripts, along with another ZIP archive which contains the .app directory. This also means that non-Mac users will get the "__MAC" and ".DS_Store" debris after uncompressing, as well. ----------- I've read it 3 times, sorry if I'm being dense: I'm not understanding the causaility in the first paragraph that leads to the requirement of the inner-Zip mentioned in the second paragraph. If "the .app directory has to be compressed and uncompressed by itself (no siblings)", fine, but why the inner zip instead of just staying iwth the "Squeak-4.5-All-in-One.app"? Since we can't have siblings to the .app, here is a second-best Zip structure I hope we can do: Squeak-4.5-All-in-One.app Contents squeak.bat squeak.sh Can that be done? > The one currently on squeak.org, as I > discussed in detail above, is not (bad signature). Apparently we should > make one more version with Linux and Windows scripts that unzip the .app > folder if it hasn't been unzipped already, or forget the all-in-one > approach altogether (or forget about Apple signatures :). |
|
|
Hi Chris-- > > > Can't you sign the .app + the two scripts together? > > > > No; well, not with the scripts where you want them. The thing being > > signed has to conform to a particular Apple "bundle" format, which > > wants everything to be rooted in the .app directory. > > Could the scripts be placed in the .app directory then, as siblings of > the Contents dir? No, that's what got this conversation started in the first place (when Apple changed their signing code for MacOS 10.9.5). The bundle format that the signing code now requires does not allow for siblings of the Contents directory. That's why I suggested putting those scripts in .app/Contents/LinuxAndWindows/. Since there's only one choice of where to look next at the ".app" and "Contents" levels, and "LinuxAndWindows" is obvious, even an impatient newbie will find the scripts, and we avoid any ZIP-within-a-ZIP silliness. > I'm not understanding the... requirement of the inner-Zip... The format of the contents of the ZIP has to be a certain way for the signing-zip-unzip process to yield a valid signature. This includes the .app directory itself having no siblings, and there being no siblings of .app/Contents/. Please, if yer gonna get angry, get angry at Apple (and tell them!). I certainly will. I think it's incredibly stupid that I'm not allowed to have a .app/README file. It's Unix heresy! :) Let's please save any further discussion of this for the next board meeting, when we can all speak interactively. Thanks! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
|
|
On Wed, Oct 15, 2014 at 02:57:54PM +0200, Craig Latta wrote:
> > Let's please save any further discussion of this for the next board > meeting, when we can all speak interactively. Thanks! Happily our next board meeting is tomorrow, so I'm sure we can sort out any confusion. However, I do want to note for the record that figuring out implementation issues such as this is the business of the Squeak community at large, not the board. So if we come up with any great ideas tomorrow, let's make sure that we contribute them to the community right here on squeak-dev for discussion. FWIW, I'm not a big proponent of the all-in-one as a primary release artifact. But having said that I think that Craig's point of view has merit, based on the fact that he has actually tried it out on a range of actual new users. I also agree with Craig's position that it is up the the release manager to take care of the release artifacts. It is perfectly OK to agree to disagree, and we dissenters should simply note our point of view and move on. Dave |
|
|
> ...figuring out implementation issues such as this is the business of > the Squeak community at large, not the board. Oh, indeed, good point. I was only noting an opportunity to move a conversation between two people who happen to be on the board from email to an interactive board meeting. :) Thanks for clarifying. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |