[squeak-dev] CommandLineUIManager

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Fri Nov 8 21:24:49 UTC 2019


@Chris:


> I believe it has nothing to do with my command.  Even if you try to just run

>    squeak -version
> in that environment, I think you'll get the same error.


No, this one works:


5.0-201810071412  Mon Oct  8 09:30:27 UTC 2018 gcc 4.8 [Production Spur 64-bit VM]
CoInterpreter VMMaker.oscog-eem.2437 uuid: 0e97c106-dd0b-437b-b1aa-e15257288c3f Oct  8 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2432 uuid: 7b14d114-0e04-4e46-b8a7-4b5e6d87f5fe Oct  8 2018
VM: 201810071412 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
...


(Just wondering why the current Trunk image is delivered with a VM that has version 5.0 ...)

Creating the squeak.conf did not change the behavior for me.

I am using a Ubuntu WSL.


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
Gesendet: Freitag, 8. November 2019 14:34 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] CommandLineUIManager

On Wed, Nov 06, 2019 at 09:30:44PM -0800, tim Rowledge wrote:
>
>
> > On 2019-11-06, at 7:43 PM, Chris Muller <asqueaker at gmail.com> wrote:
> > There are two flavors of the Linux VM, you're using the version of the VM that's a little better, but requires you to install a file into your security limits that allows it to work.
> >
> > Create a text file called "squeak.conf" with these contents (between the horizontal lines):
> >
> > *       hard    rtprio  2
> > *       soft    rtprio  2
>
> The daft thing is that this problem was purportedly fixed in linux kernels as of {mumble-mumble} years ago. Raspbian, for example, does not need it and Raspbian is based on a very conservative branch of Debian
>

Uhmm... it's not a "problem" that needs to be fixed. The Rasbian
distribution of Debian Linux is typically intended as single-user
system on which you can safely assume that if the user does something
dumb, then it serves him/her right when the system locks up.

In the general case of a multi-user system, you don't want someone
to elevate their thread priorities and accidentally lock up the
entire system. That's why you are not allowed to use real time
scheduling priority in ordinary user applications.

Some Linux distributions enforce this by default, and others do
not. I think that it more or less depends on the intended audience
for the distribution.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191108/d4eeb12b/attachment.html>


More information about the Squeak-dev mailing list