2018-06-27 23:21 GMT-03:00 Otto Behrens <o...@finworks.biz>: > Thanks for the effort guys. > > I tried to download the image, sources and vm separately (basically > extracted what https://get.pharo.org/64/61+vm does), but ran into fresh > trouble. > > Firstly, is "wget -O - https://get.pharo.org/64/61+vm | bash" not risky in > terms of security? It should be quite possible to inject a lovely trojan > horse with this, or not?
Yes, this is possible: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/ > > Secondly, the pharo bash script that it generates is different to the one in > the zip. The directory structure (where the image & vm goes) is also > different. Why is that? > > I started the image (http://files.pharo.org/get-files/61/pharo64.zip) with > the vm (http://files.pharo.org/get-files/61/pharo-linux-stable.zip), and got > the following, which I tried to do, but that did not take the message away: > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the pharo mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > > (I did do this). > > I reverted to the deb package for now, because this have take some time and > I can't focus on it now. > > I'll give it another shot soon, I hope > > > > On Wed, Jun 27, 2018 at 8:58 PM, Tim Mackinnon <tim@testit.works> wrote: >> >> When we get confirmation of success - we need to make sure this gets >> applied to both zeroconf and official downloads. >> >> Anything we can do to simplify and make it robust is gratefully >> appreciated as there is nothing worse than falling at the lunch hurdle. >> >> It’s cool to see so many clever minds on this. >> >> Tim >> >> Sent from my iPhone >> >> > On 27 Jun 2018, at 19:52, Hernán Morales Durand >> > <hernan.mora...@gmail.com> wrote: >> > >> > 2018-06-27 10:50 GMT-03:00 K K Subbu <kksubbu...@gmail.com>: >> >>> On Wednesday 27 June 2018 06:39 PM, K K Subbu wrote: >> >>> >> >>> >> >>> The double quotes are required here to skip splitting arguments with >> >>> embedded spaces into different words. >> >>> >> >>> I suspect the error is earlier in the image=$@ assignment. This >> >>> requires >> >>> double quotes. Double quotes are also required while calling zenity to >> >>> avoid >> >>> word splitting. >> >> >> >> >> >> My earlier fix is also in error, Sorry! >> >> >> >> Essentially, we are mixing up single value variable (image) with >> >> argument >> >> array ($@). I found a cleaner fix : >> >> >> >> ```` >> >> if [ $# -eq 0 ]; then >> >> image_count=`ls "$RESOURCES"/*.image 2>/dev/null |wc -l` >> >> if [ "$image_count" -eq 1 ]; then >> >> set -- "$RESOURCES"/*.image >> >> elif which zenity &>/dev/null; then >> >> set -- "$(zenity --title 'Select an image' >> >> --file-selection >> >> --filename "$RESOURCES/" --file-filter '*.image' --file- >> >> filter '*')" >> >> else >> >> set -- "$RESOURCES/Pharo6.1-64.image" >> >> fi >> >> fi >> >> >> > >> > Use $() instead of backticks for command substitution: >> > http://mywiki.wooledge.org/BashFAQ/082 >> > >> > Cheers, >> > >> > Hernán >> > >> >> # execute >> >> exec "$LINUX/pharo" \ >> >> --plugins "$LINUX" \ >> >> --encoding utf8 \ >> >> -vm-display-X11 \ >> >> "$@" >> >> ```` >> >> >> >> HTH .. Subbu >> >> >> > >> >> >
