I have found a problem with the primLocalAddess call. It returns the loopeback address 127.0.0.1 on my Debian Linux systems. On an XP, it correctly returns the machines network IP address. This appeared in attempts to use 'Connection' on a Linux network. I have talked with one person who says it works on their RedHat, so it may be a distribution related problem.
This is a complex issue related to the way the network was thrown together in Jasmine, which assumes (incorrectly) that it even makes sense to ask what one's machines local address is. In the Internet a machine may have MANY local addresses, and the loopback address is a valid answer! (the idea of a machine having a single primary address is an ancient confusion that reflected the "socket" API definers' early (mis)understanding of the Internet architecture). In the next release, the protocol we use allows machines that have multiple addresses (multiple adapters, but also the Debian default setup case where the loopback adapter is included) work fine. The next release won't have this problem, even on Debian. (the fix is entangled with a whole lot of other changes, so backporting it to Jasmine is probably not worth the effort). The linux version of primLocalAddress gets the value of hostname, and then looks its address up. Type "hostname" and see what you get on your debian machine. Most likely you are getting localhost, which of course stands for 127.0.0.1. The linux machines that "work" probably have hostnames that are not equal to localhost. You need to fix hostname to be a different name, one which defines the primary address of the machine. This is, as a say, a temporary fix. In the next release, which uses different connection technology, we actually don't use primLocalAddress at all. My debian machine changes hostname to be the actual octet string of the adapter whenever DHCP binds a new address. This works "OK" but when my laptop sees both an Ethernet and a wireless network, the local address may bounce back and forth... Alternatively, you can patch the place where we call(Continue reading)
Am 02.01.2005 um 01:16 schrieb Tom Cranbrook: > I have found a problem with the primLocalAddess call. It returns the > loopeback address 127.0.0.1 on my Debian Linux systems. On an XP, it > correctly returns the machines network IP address. This appeared in > attempts to use 'Connection' on a Linux network. > > I have talked with one person who says it works on their RedHat, so it > may > be a distribution related problem. I usually use Fedora (RedHat) for the desktop, but I think this problem may depend on the order of network interfaces. When I try "ifconfig" on my Debian router box then "eth0" is the first interface. Maybe it's "lo" for you? - Bert -
> >The linux version of primLocalAddress gets the value of hostname, and >then looks its address up. Type "hostname" and see what you get on your >debian machine. Most likely you are getting localhost, which of course >stands for 127.0.0.1. The linux machines that "work" probably have >hostnames that are not equal to localhost. > Fixing the /etc/hosts file took care of the problem. Thanks.
I'm creating a TCube and specifying a jpeg as a texture. When the cube is rendered, it's textured but the images on the faces are in different directions i.e. upside down, left-to-right, right-to-left. I'm not too bothered with the images at the top and bottom of the cube, I presume these would all be in the same direction no matter hoe many cubes were rendered. How do I specify what's "up" so that they're rendered top-down on all faces? Do I need to muck around with the OpenGL API's? Thanks. -- Sachin.
Sachin Desai wrote: > I'm creating a TCube and specifying a jpeg as a texture. When the cube > is rendered, it's textured but the images on the faces are in > different directions i.e. upside down, left-to-right, right-to-left. > I'm not too bothered with the images at the top and bottom of the > cube, I presume these would all be in the same direction no matter hoe > many cubes were rendered. They *are* all in the same direction. Depends on what you mean by "same" (looking out from the center of the cube towards each face having yourself appropriately).> > How do I specify what's "up" so that they're rendered top-down on all > faces? Do I need to muck around with the OpenGL API's? I suggest you copy or subclass TCube to define a TOrientedCube object that has a "top" that is defined, and then choose the texture-mapping for each side to correspond to that notion of "up"; while you are at it, you can allow it to have different textures on each side, and perhaps even different texture mapping transformations. You can do this either by specifying the corners of each face in the right order, or by changing the u-v mapping where the texture is applied.
Kourge, > I looked at the reciever on the stack top, here is the message: I should've said "second from the top", as it has more info in this case... Again, I wouldn't have much time to look at this by myself right now. Sorry... -- Yoshiki
To what extent has security issues been addressed in the Croquet design? I saw a reference to a user permission system on objects but nothing further. I would think that at least two main areas would be of concern. The first would be various levels of encyption, and the second would be hardening against malicious clients. Also on a related note, to what exteant is a Squeak process (and of course Croquet on top of it) sandboxed from the rest of the host system?
This is still being worked out. One aspect is external security such as encryption of communications using SSL (which we have implemented some of here at U.Wisc.). There are a host of institutional requirements for managing security and interoperating with middleware (e.g., at our university) that will involve compatibility with internet2.edu MACE standards such as signet. Another aspect is making the internal distributed object model sound. My personal hope (not speaking for anyone else) is that a capabilities based approach for the later will allow modeling of not only our own institutional environment, but also very different environments in ways that will allow them to interoperate in a consistent way. Examples of other environments might include military environments (which have a different model than I2) and global public anonymous environments. I will collect any requests, concerns, favorites and peeves in this area. Everyone should understand that Jasmine is a snapshot of a work in progress, made available so that developers can explore different aspects of Croquet. It is not intended for building secure applications. On Jan 3, 2005, at 7:26 AM, Tom Cranbrook wrote: > To what extent has security issues been addressed in the Croquet > design? I > saw a reference to a user permission system on objects but nothing(Continue reading)
>From: Tom Cranbrook <tcranbrook <at> australia.edu> >Also on a related note, to what exteant is a Squeak process (and of course >Croquet on top of it) sandboxed from the rest of the host system? Smalltalk in general, and Squeak in particular, has no security model. All processes run in the same object space and there is no protection or sandboxing of one from another. Now, Smalltalk is reflective to a very high degree, and the result is that it is theoretically possible to build any kind of security model that you want. People have talked about this for years, and I think some research prototypes have been built, but I haven't seen anything that anybody thought was good enough to give away. Squeak is a great platform to do security research, but it will take a lot of hard work to make it reliable. We might have a secure Squeak in a couple of years, but not in six months. -Ralph Johnson
RSS Feed21 | |
|---|---|
3 | |
1 | |
2 | |
1 | |
5 | |
2 | |
2 | |
3 | |
1 | |
3 | |
5 | |
1 | |
1 | |
1 | |
4 | |
3 | |
2 | |
1 | |
14 | |
15 | |
7 | |
19 | |
19 | |
21 | |
18 | |
14 | |
25 | |
21 | |
19 | |
19 | |
66 | |
32 | |
45 | |
59 | |
64 | |
60 | |
80 | |
99 | |
29 | |
87 | |
106 | |
41 | |
57 | |
60 | |
86 | |
105 | |
103 | |
96 | |
130 | |
88 | |
78 | |
49 | |
36 | |
1 | |
72 | |
36 | |
50 | |
35 | |
57 | |
64 | |
73 | |
61 | |
81 | |
111 | |
37 | |
12 | |
9 | |
14 | |
33 | |
31 | |
7 | |
29 | |
79 | |
75 | |
73 | |
49 | |
84 | |
120 | |
135 | |
311 | |
158 | |
146 |
