As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download the image and vm separately, from different sources. Say you get your vm from apt-get, rpm, or yum. And then we release a new image. Maybe people will just see everything fail. The Cog vm is a big jump. You use it, and you can't readily go back to the interpreter. Jecel is going to look at what vms Linux users are using. Are they still 3.x vms? That sort of thing. The mechanism for Linux users to get what we make is a little different. But since you clearly are in the loop, I don't think any of this kind of delay would apply to you. I'd say its more a communications thing than a technical challenge.
Chris
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download the image and vm separately, from different sources. Say you get your vm from apt-get, rpm, or yum. And then we release a new image. Maybe people will just see everything fail. The Cog vm is a big jump. You use it, and you can't readily go back to the interpreter. Jecel is going to look at what vms Linux users are using. Are they still 3.x vms? That sort of thing. The mechanism for Linux users to get what we make is a little different. But since you clearly are in the loop, I don't think any of this kind of delay would apply to you. I'd say its more a communications thing than a technical challenge.
Chris
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
On 19/10/11 16:16, Derek O'Connell wrote:
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download the image and vm separately, from different sources. Say you get your vm from apt-get, rpm, or yum. And then we release a new image. Maybe people will just see everything fail. The Cog vm is a big jump. You use it, and you can't readily go back to the interpreter. Jecel is going to look at what vms Linux users are using. Are they still 3.x vms? That sort of thing. The mechanism for Linux users to get what we make is a little different. But since you clearly are in the loop, I don't think any of this kind of delay would apply to you. I'd say its more a communications thing than a technical challenge.
Chris
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
One exception springs to mind, the olpc maintainers are currently packaging the VM to include the XO-1.75 which is ARM based IIRC.
Would be a good idea to get a working group together that includes package maintainers since they best know their own requirements.
On 19.10.2011, at 17:16, Derek O'Connell wrote:
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download the image and vm separately, from different sources. Say you get your vm from apt-get, rpm, or yum. And then we release a new image. Maybe people will just see everything fail. The Cog vm is a big jump. You use it, and you can't readily go back to the interpreter. Jecel is going to look at what vms Linux users are using. Are they still 3.x vms? That sort of thing. The mechanism for Linux users to get what we make is a little different. But since you clearly are in the loop, I don't think any of this kind of delay would apply to you. I'd say its more a communications thing than a technical challenge.
Chris
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
What we want (or what I think we should aim for) is that a user installs the squeak-vm package from their distro, and that's all to make double-clicking any image work. The same should be true if you type "squeak some.image" on the command line, too.
That requires "squeak" to be a shell script (which it already is, also used in the .desktop files) which decides which VM to run based on the image version (this part has not been implemented yet). The VM package would contain two VMs. One interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share the plugins.
The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a closure image:
https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
Debian has more recent 4.x VMs:
http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-v...
But only the unstable Debian one can open a Cog image, so we think we should not release 4.3 as Cog image, yet.
- Bert -
On Wed, Oct 19, 2011 at 5:35 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.10.2011, at 17:16, Derek O'Connell wrote:
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download
[snip]
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
What we want (or what I think we should aim for) is that a user installs the squeak-vm package from their distro, and that's all to make double-clicking any image work. The same should be true if you type "squeak some.image" on the command line, too.
That requires "squeak" to be a shell script (which it already is, also used in the .desktop files) which decides which VM to run based on the image version (this part has not been implemented yet). The VM package would contain two VMs. One interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share the plugins.
The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a closure image:
https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
Debian has more recent 4.x VMs:
http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-v...
But only the unstable Debian one can open a Cog image, so we think we should not release 4.3 as Cog image, yet.
FreeBSD ports tree has 3.9. Perhaps I should volunteer to be the maintainer. It's a matter of time.
On 19 October 2011 20:33, Gary Dunn garydunnhi@gmail.com wrote:
On Wed, Oct 19, 2011 at 5:35 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.10.2011, at 17:16, Derek O'Connell wrote:
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download
[snip]
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
What we want (or what I think we should aim for) is that a user installs the squeak-vm package from their distro, and that's all to make double-clicking any image work. The same should be true if you type "squeak some.image" on the command line, too.
That requires "squeak" to be a shell script (which it already is, also used in the .desktop files) which decides which VM to run based on the image version (this part has not been implemented yet). The VM package would contain two VMs. One interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share the plugins.
The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a closure image:
https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
Debian has more recent 4.x VMs:
http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-v...
But only the unstable Debian one can open a Cog image, so we think we should not release 4.3 as Cog image, yet.
FreeBSD ports tree has 3.9. Perhaps I should volunteer to be the maintainer. It's a matter of time.
Drop "Takeshi MUTOH" <mutoh at openedu.org> a mail: he did some work a few years ago for Squeak 3.10. Maybe he can give some insight into the platform-specific oddities.
At any rate, count me in as a beta tester for anything that doesn't require a headful image; my FreeBSD access is strictly remote, via a shell.
frank
-- Gary Dunn Honolulu
On Wed, Oct 19, 2011 at 10:08 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 19 October 2011 20:33, Gary Dunn garydunnhi@gmail.com wrote:
On Wed, Oct 19, 2011 at 5:35 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 19.10.2011, at 17:16, Derek O'Connell wrote:
On 19/10/11 15:56, Chris Cunnington wrote:
As I understand it, we don't have the same kind of present and immediate control over distribution of the vm and the image, as we do with Mac and PC. I think with Linux it's more likely you'll download
[snip]
Thanks for the explanation. I don't have a complete overview on all distro's but the main packaging formats can surely handle dependencies so that end-users don't end up with a mismatched vm/image. If more safety is needed then why not have cog/start-up-script do a one-time back-up of the image automatically? I'm guessing package maintainers would be more than happy to quickly get to the point of sourcing one vm for Squeak/Etoys/Scratch, etc.
-D
What we want (or what I think we should aim for) is that a user installs the squeak-vm package from their distro, and that's all to make double-clicking any image work. The same should be true if you type "squeak some.image" on the command line, too.
That requires "squeak" to be a shell script (which it already is, also used in the .desktop files) which decides which VM to run based on the image version (this part has not been implemented yet). The VM package would contain two VMs. One interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share the plugins.
The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a closure image:
https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
Debian has more recent 4.x VMs:
http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-v...
But only the unstable Debian one can open a Cog image, so we think we should not release 4.3 as Cog image, yet.
FreeBSD ports tree has 3.9. Perhaps I should volunteer to be the maintainer. It's a matter of time.
Drop "Takeshi MUTOH" <mutoh at openedu.org> a mail: he did some work a few years ago for Squeak 3.10. Maybe he can give some insight into the platform-specific oddities.
Takeshi is the port maintainer. I will write to him, question is do I have the nerve to offer to take over the job.
There could be an issue with the MIT license vs the BSD license vs. the GPL 3.0 which the newer gcc compiler is released under. I can't build a VM from source because it requires a gcc compiler that FreeBSD development team refuses to use due to GPL 3.0. I am not an attorney, so I can't say anything more than it seems like a smoke cloud without much of a fire.
Bert Freudenberg wrote:
What we want (or what I think we should aim for) is that a user installs the squeak-vm package from their distro, and that's all to make double-clicking any image work. The same should be true if you type "squeak some.image" on the command line, too.
That requires "squeak" to be a shell script (which it already is, also used in the .desktop files) which decides which VM to run based on the image version (this part has not been implemented yet). The VM package would contain two VMs. One interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share the plugins.
The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a closure image:
https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
Debian has more recent 4.x VMs:
http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-v...
But only the unstable Debian one can open a Cog image, so we think we should not release 4.3 as Cog image, yet.
Here is another interesting link to a page that Bert maintains which shows where Squeak bugs get tracked for all the versions out there (which is a good first approximation of what versions are out there):
http://wiki.squeakland.org/display/sq/Bug+Tracking
There are two different use cases we are interested in handling. The first is making things nicer in the future for Linux users. That can be done with new or changed code on both the image side and the VM packages. The second use case, which the survey will be for, is making the 4.3 image usable for users who got their current VMs from their distribution instead of from squeak.org. In this situation we can't make any modifications to the VM since these won't get included in all distributions soon enough to help.
Of course, we have to be reasonable. I am stuck in Fedora 10, for example (their installation system can deal with RAID in the root partition, but their upgrade system can't). And during a long time I was stuck with a 3.7-7 VM because newer ones broke diacritical marks for all but the Etoys images. It wouldn't make any sense to try to support someone in that situation. That has been fixed and I now use a 4.0.3-2202 VM. Using that with a proposed 4.3 image gets me
+ exec padsp /usr/local/lib/squeak/4.0.3-2202/squeakvm Squeak4.3alpha-11636.image This interpreter (vers. 6502) cannot read image file (vers. 6505).
Here I used the command line. I couldn't test double clicking on the image file since my system seems to have associated .changes and .sources files with Squeak but not .image files. It would be nasty if this failed without even an error message as the above (which is probably too confusing for many people as it is).
One proposal is to distribute the 4.3 image so it can be loaded by older VMs. But that just means we will face this problem again for 4.4.
It will take me a while to look at all the Linux systems, but I expect to see some with no Squeak at all, some with Etoys (so downloading a Squeak image will use the VM that came with that), some with just the VM (because of wierd ideas of what Open Source don't allow the image) and others with VMs and images related by some dependency mechanism. The last case is the only one we wouldn't have to worry about, at least in theory.
The situation for Windows and Mac OS X is a little better, but there is still room for confusion.
-- Jecel
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunnington -
Derek O'Connell -
Frank Shearar -
Gary Dunn -
Jecel Assumpcao Jr.