Re: Multiple Window managers in xstartup?
James Weatherall wrote: Brad, Are you sure that the SunOS clause is being run? Why are you not simply running dtsession directly: /usr/dt/bin/dtsession? Because, if you want a session that is as close to a real CDE login session, there is alot more that /usr/dt/Xsession does than just run dtsession. If this really is what Brad wants, then I think he'll get the best results from editing his xstartup file to have nothing run (at least for Solaris) and then start vncserver with the '-query localhost' argument. His first connectino with VNC viewer will give him the DtLogin screen and he'll have to login, but this method gives the most identical login environment to sitting at the machine itself. -Kyle What happens if you run it directly from within your window-managerless VNC desktop? ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Master Router List
Dragos Maciuca wrote: I was wondering if there is, or if we can start, a master (SOHO) router list identifying features and problems. Here is what I have in mind: I recently bought three Netgear wireless routers (one for myself and one each for my parents and my wife's parents). As it turns out, the wired part works great with VNC, but not any computers connected wirelessly. I've seen several posts regarding this problem on this list. It seems, however, that Linksys routers do work fine with VNC over wireless. On the other hand, Netgear has a nice feature that in DHCP mode you can reserve addresses based on MAC. Some D-Links and Linksys routers don't seem to have this feature, which may be useful to many. I think most Linksys don't have the 'Static' DHCP addressing ability. But THe WRT54G and WRT54GS models have alternate 3rd party firmware available that add this and many other features that Linksys hid or left out entirely. Some of these firmware packages are starting to be ported to other brands and models now too. More info can be found on http://linksysinfo.org/ If you have had problems with VNC on a linksys router then chances are these firmware updates will fix that too. If not report it to the author and it'll probably be fixed in the next release. -Kyle So, what's the best way to list router models and pros and cons for each. Thanks! ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL requirement?
Rex Dieter wrote: If the GPL doesn't cover this case, then I have to say that the GPL is weaker than I thought... and could be abused. Abuse is what the GPL is supposed to prevent, I aggree. The thing to remember here is that the original copyright holder is a special case. The wording we're disscussing I think is designed to stop someone who recieves the GPL sources (and possibly makes changes) from then removing the build script from the package in order to make it harder for it's customers to take advantage of the rights granted by the GPL. As I stated earlier, In the case of the original author, there's no logicla reason that an author would leave out the build scripts. At least I can't think of one, if they don't want the customers to take advantage of the GPL rights, then why are they using the GPL as the license for this code? I would suggest that if they have a build script they would include it, but On the other hand, if they don't have one already, and dont' use one, I'm not sure if the GPL requires them to make one. The webpage that offers the down load could just say: > > Run this to build: > > gcc -o foobar -I ./include *.c > Or something similiar as instructions. Also, if it's really that easy, then I think it could be left as a 'given'. I really think that the text of the license is intended to ensure that eveything the original author distributed is propagated, and that nothing is lost. There are many cases in other Open source software where the sources that are release, no matter how they are built, do not produce the same programs as the binaries that are distributed. This is the major type of abuse the GPL is trying to protect us from. -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: "The" script used to generate the (GPL) rpm on the VNC website is in the sources? Really? If so, I'll shut up and go away. Promise? ;) Just kidding. I haven't looked, but from what others have said there is a sscript or Makefile that will build the binaries from the sources. Since this was provided in the original GPL sources it is required to be distributed in the future also. I personally beleive that the orignal copyright holder could if they chose exclude even this file, since it only makes things easier. Though I don't understand why they'd GPL it at all if they wanted to make building the program harder? Most people GPL something to make it easier. Once the program is built, once the binaries exist, they can Zip them up, tar them up, jar them up, or make an RPM it doesn't matter. There may be ways to both compile the sources and put them into an RPM in one step, but that's not the only way. It's also possible to put binaries that were made some other way into an RPM. Even if there was a specfile for putting those binaries in an RPM, that specfile won't automatically also be able to build them from the sources. 'Prefferred form' means you can't offer the sources up compressed with some compression program that you wrote, or that is proprietary, or only availabe on a specifc platform. The term is vague in order to try to be 'future proof'. When the GPL started the internet hadn't really caught on. There were more than one large networks, and the 'preferred form' manytimes was still a tarfile on a magnetic tape. Since then the internet has arrived, and the 'preffered form' is now downloads, in any easily expanded archive format. The source format doesn't have to match the binary format. This is what it boils down to surely, and I humbly disagree. Have you ever heard of anyone else making this claim? How was it resolved? -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: James Weatherall wrote: The source code we supply is exactly the code used to create the binaries contained in the downloadable RPM. Except for the specfile used to actually generate the downloadable RPM, of course. Why are you so resistant to releasing the specfile? You're assuming that there is one. You're assuming that they use one. They are plenty of other ways to build software and make an RPM. What makes you think they use a specfile? Get over it. Move on already. -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: On Mon, 16 May 2005, Kyle McDonald wrote: If they were *only* providing tarball binaries, this would be true. However, in the case of binary rpms, the "preferred" form the Source Code (as defined by the GPL) is clearly either a src.rpm or the (already-provided) tar-file + rpm specfile. That's your 'prefferred form'. There's nothing in there that defines the preffered form. And 'available for download off the internet in any acceptable file format' is probably about as specific a consensus as you'll get the public to aggree too for a preffered form. Well, "preferred form" and "scripts used to generate the binaries" both apply. In the case of binary rpms, a specfile is used to generate them. I find it difficult to interpret it any other way. If they provide *anything* the will generate the *binaries* themselves they are in compliance. No-one is required to allow you to reproduce the RPM itself. Also lets say that being able ot regenerate the RPM itself was a requirement. There are other ways that a build script or Makefile which was included with the sources could also generate the RPM, and that would meet that requirement, and still wouldn't be a specfile. A specfile is a convience. Not a requirement. Automating the RPM building also is a convience and a bonus, Not a requirement. Unless you have pointers to statements from RMS or the FSF that say otherwise? If so then they're even more crazy, and dictatorial, than I thought. -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: In this case, a *binary rpm* is what is being distributed... the "preferred form of the work" and "scripts used to control compilation and installation" is rpm specfile and/or src.rpm. No, It doesn't have to be a specfile. It can be any script or config files that successfuly creates the binaries from the sources. One of these is included in the tar file. So it's not *your* prefferred format. Big deal. It's the trend and probably most practiced method of source distrubution and building since sources were being distributed and built. The fact that after they build the binaries, the build an RPM to distibute them in, doesn't change anything. I suppose if you knew for a fact that a specfile existed, and that that was what was used by RealVNC to build the sources and build the RPM, then you could ask for that. I'm not sure you can demand it. But in many cases the specfile doesn't even exist. The script or Makefile that is included coudl know how to make the binary RPM. That would render the specfile unneeded. As a mtter of fact, most open source projects probably don't include these. Most of the time the people (The re-distributors) who repackage them into linux distributions create them to document the specific (out of the many) way they built thier binary RPM. I do beleive they must offer the sources, but even they aren't required to provide the specfile. Do you have any statements from RMS or the FSF that imply they beleive the GPL requires this? How does what RealVNC distribute currently satisfy the definition of "Source Code" for binary rpms? They only have to provied the source for the program itself. Not for the RPM. -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: and theirs to distribute how they see fit. True, provided it complies with their (own) licensing terms. Any copyright holder of any work can relicense it at anytime with new terms. So the copyright holder doesn't have to live by anything they've done in the past. Of course the copy right holder would have to live with public opinion, reprocussions. One could apply multiple licenses, but one can not start with GPL source and produce something that is not *at least* GPL as well. The copyright holder can remove licenses also. They choose to nolonger offer the software as GPL at anytime. They couldn't revoke the rights of those who already received the program under GPL, but they can stop being a source for new users to get the program at any time, and they can refuse to distribute new improvements they make to the program. And RealVNC complies with this by making the sources available as a tar file. If they were *only* providing tarball binaries, this would be true. However, in the case of binary rpms, the "preferred" form the Source Code (as defined by the GPL) is clearly either a src.rpm or the (already-provided) tar-file + rpm specfile. That's your 'prefferred form'. There's nothing in there that defines the preffered form. And 'available for download off the internet in any acceptable file format' is probably about as specific a consensus as you'll get the public to aggree too for a preffered form. GNU and GPL were around for a long time before Linux, Red-Hat and RPM's. They don't define the 'preferred format' for anything. -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
James Weatherall wrote: Kyle, If we release binaries under the GPL then we have to honour the license's requirements to make the source code to those binaries available, in the same way as anyone else does, which we do. If we didn't do that, we'd be failing to honour the license under which we'd distributed the software. That's true. I was only pushing the envelope to show how ridiculous his claims were and how generous you already are. I beleive that if you took the same sources, licensed them under a different license (which is within your rights.) and produced and distibuted only binaries under that licenese you wouldn't be failing to honour the GPL. It's your's to do what you want with. That's the only redeeming quality of the GPL. It's also the case that if even one of the binaries we distribute is GPL and it's distributed alongside other binaries then they must be GPL licensed too, even if the entire thing is owned by us. I can see that, if you choose to license that binary under the GPL then you must choose to license the others that way too if they are distributed together. However I still maintain (not that you'd do it, this is an academic brainstornm after all...) that there's nothing stopping you from releasing them under a different license which allows the source to be omitted. You can change the license at any time. This was done (as I understand it by Ghostscript for ages.) Each new version was released without sources and non-gpl'd for paying customers only. Once a new version was ready to replace it, then the sources and binaries were made available for the previous version under the GPL. Note, I'm not claiming that you can change the rights of anyone who recieved the sources under the GPL once they have them. Those rights you've granted forever. But you could stop granting thos rights to people who get the software from you in the future. Of course they can just go get the source from someone who got it before you changed the license so I don't know what'd you'd gain. The fact that we own VNC simply means that we can release binaries under other licensing terms if we wish. It doesn't allow us to bundle GPL-licensed software with software under other licenses. I aggree, but if all the software is software you're the copyright holder of, then you can change the license so that none of it is GPL. and then bundel it however you wish. (Again purely academically speaking.) -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: Kyle McDonald wrote: Rex Dieter wrote: RealVNC is violating the GPL (unknowningly or not) by failing to provide the (preferred) source to the binary they distribute. On top of that, it's trechnically impossible for Real-VNC to violate the GPL. I suggest you read the GPL then (relavent section 3 appended). It says that GPL binaries that are distributed *must* include source. I can't see how Real-VNC doesn't have to comply with that. They own VNC. It's theirs to license how they see fit, and theirs to distribute how they see fit. In fact I beleive technically only the source they provide really is GPL'd. Even if the binaries are produced from those sources, they could be provided under any other license. This is a special case though. You dont' see it mostly in the Open Source world. But it does occur. The copyright holder retains all rights to the code they release under GPL. They are free to do anything they want with it, including makeing changes that they don't release unde GPL. The GPL doesn't say the source has to be included in the same file the binaries are in. It actually offers several ways to distribute the sources. And RealVNC complies with this by making the sources available as a tar file. But as I wrote above, they could just as easily decalse the binaries they release as being released under some new binary-only license. It's all up to them. They own the code. -Kyle -- Rex --- 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: src.rpm/specfile, GPL violation
Rex Dieter wrote: RealVNC is violating the GPL (unknowningly or not) by failing to provide the (preferred) source to the binary they distribute. Given other conversations on here about GPL issues, I'd be surprised if there was really anything underhanded going on here. On top of that, it's trechnically impossible for Real-VNC to violate the GPL. They are the original Copyright holders of the work. They can license and distribute only the files they want to under the GPL. If you don't get the file from them under the GPL then that file is not licensed under the GPL. If they were modifying someone else's GPL work and the *re*distributing it, without a file the original author had included, then there'd be something fishy. But they are the original author of VNC (at least as I understand it.) -Kyle ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: What good is VNC's GPL?
Steve Bostedor wrote: I misread section 3a and thought it was saying that you could only charge as much as the working version for the source but it really says that you can only charge as much as it physically costs you to distribute the source. As far as delivering the source, they are obligated to deliver it upon request. Where does it say that? I read that you *must* choose *one* of the three A, B, or C, options. A) Doesn't say anything about releasing the source upon request. It only states that the sources must accompany the binaries, and that you must give the person recieving both no less rights and options you have and no more restrictions than you have. B) does require you to offer and distribute the sources to 'any third party', but only if you have *not* included them with the binaries in the first place. Obviously as Wez stated this is all irrelevant if they're already violating the GPL in other ways. I was only refuting the claim that if you found a company on the web distributing a comercial proudct that was based on a GPL one, that you can just walk (or email as the case may be) in and demand the source code. I beleive that if they're distributing under option A, then you may have to: 1.) pay for one copy and get the source with it. or 2.) find someone who has paid for one copy, and get them to re-distribute the source (and/or binaries) as the GPL allows them to do. -Kyle The only option they are given is to charge for the delivery or not. In the end, though, they are obligated to deliver. Neither company has delivered to date and Smart code has promised NEVER to deliver at any cost. That is a direct violation of the licensing terms. - Steve -Original Message- From: Kyle McDonald [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 9:40 AM To: Steve Bostedor Subject: Re: What good is VNC's GPL? Steve Bostedor wrote: Actually, I think you're wrong about them 'oweing' us anything. The GPL states that they only have to offer, and provide the sources to the people they distribute the binaries to. This means theonly people that are 'owed' the sources are the paying customers. Of course once a paying customer has the source the GPL let's them do whatever they want with it. So they can give it away for no-cost if they like and the person they bought it from can't say a thing. (and they shouldn't come under any reprisals from the seller for doing so, but that seems to be ignored by the FSF in at least one case - www.sveasoft.com ) But they *don't have to* give the source to us just because we ask. -Kyle This has turned into a fun and interesting debate. Now for my 2 cents ... Again. ;) They do, according to the section of the GPL that I pasted in a previous email, have to provide the source when asked for. In fact, their product must be distributed either WITH the source or there must be a visible link on their website to get the source. The can charge no more than the cost of their compiled product for the source code but they can not reject requests to purchase the source code. Ok. Well, charging no more for the source only than they charge for the binary that includes source, is not that different than only letting people who buy the binary have the source. I mean paying the price of the binary to get the source is just like buying the binary with source and then ignoring the binary. But reading the GPL snippet in your other message, I don't see any text that says 'you can charge no more for the source than you do for the binaries' Actually a vendor who chooses option A *can* only give the source to those who get the binaries by including the sources in with the binaries and charging the one price for that. This particular company distributes a free shareware version of their software. That free download must, according to the GPL, have the source code with it. It's really all in black and white and in only the first few sections of the GPL. Option A says the source must be with it, but they're also free to choose Option B, which allows them to charge a seperate fee for the source at a later time. -Kyle -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ooO(_)Ooo- -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive
Re: What good is VNC's GPL?
Mark Jacobs wrote: Has anyone managed to get the source code off of these guys? If not, *that* is what they are doing wrong, just like SmartCode would not give out their source code, even though it should be exactly the same as the code that you can request from Wez himself. GPL means you must release the source on request, otherwise you cannot claim it is GPL. If you cannot claim it is GPL, then you cannot use that GPL source code in your product. Therefore, it is clear-cut, and there is no ambiguity here. Both companies *owe* us the source code, and we should be able to email them once, and get it. Actually, I think you're wrong about them 'oweing' us anything. The GPL states that they only have to offer, and provide the sources to the people they distribute the binaries to. This means theonly people that are 'owed' the sources are the paying customers. Of course once a paying customer has the source the GPL let's them do whatever they want with it. So they can give it away for no-cost if they like and the person they bought it from can't say a thing. (and they shouldn't come under any reprisals from the seller for doing so, but that seems to be ignored by the FSF in at least one case - www.sveasoft.com ) But they *don't have to* give the source to us just because we ask. -Kyle -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ooO(_)Ooo- ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: What good is VNC's GPL?
Yury Averkiev wrote: So called "Bob Smith" you have been told already that the control is a wrapper (set of hooks around TightVNC files) - so it doesn't violetes GPL. Is the tightVNC (or other GPL) code linked together in the same DLL with your new 'wrapper' code?? Did you have to edit any tightVNC (or other GPL) code to create a DLL version of tightVNC? If the answer to either of these questions is 'yes' then I'm sorry to inform you that your product *does* violate the GPL. If your code is in a seperate DLL from the the tightVNC (and other GPL) code, then you *might* (I'm not lawyer ;) ) have an argument. I think that would still require you to release any and all edits you made to any tightVNC and other GPL source code files while you were turning it into a DLL. (Does TightVNC provide a DLL already?) Note: you actually need to release all the changed tightvnc files, diffs and patches aren't enough - at least the last time I checked. Also even to release your product in that fashion, tightVNC (and the other code it includes) might (I'm not sure) actually need to be licensed under the LGPL not the GPL by the copyright holder to the public, and I doubt any of the VNC code has ever been licensed with the LGPL. There are alot of people in this world who like the GPL very much, many beleive in it like a religion, and are very vehement in it's enforcement. These people take alot of stands based just on the principal of the thing. Many can be very vocal. I wouldn't assume that someone who asks these questions is anyone in particular, or is out to get you. Complying with the GPL tends to get you much better press and relations than thumbing your nose at it. That will get you a huge amount of really *bad* press. Personally I think the GPL has problems, I wouldn't use it on code I invent, and I can't stand the way Richard Stallman (the author of the GPL) thinks or speaks. But I personally am for all the rules and licenses to be obeyed and enforced. So I'm interested in the answers to those 2 questions (and then I may have more) and I'm interested to see how this whole thing turns out. -Kyle -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ooO(_)Ooo- ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: vncserver shouldn't run .vnc/xstartup when xdmcp options are used.
William Hooper wrote: Kyle McDonald said: Here's the patch. I'm surprised I haven't seen any response to this message. Maybe I'm the only one who uses the -query option?? -Kyle Vncserver is just a script for convenience (like startx). Once you get to a certain point of complexity, it doesn't make sense to use it. I guess. But there is functionality in 'vncserver' that is useful even when -query is used. Like the code that searches for an unused vnc port. Most of the time -query is used you are passing a more precise set of options to the X server, so it makes sense to use Xvnc directly. I run login servers that many of my users run vncservers on. I find that all my users are much happier with their environment in their vnc session of they go through the full login process and environment setup that XDMCP gives you. I noticably less support calls when I started educatingmy users on this option. Unfortunately the only support calls I still get are when people try to use the -query and they have clients setup in their xstartup script. That only causes problems. It doesn't seem to be that complicated to skip the xstartup when XDMCP is in use. I can't have all the users running Xvnc directly with no mechanism to search for an empty display number, and none of the other conviences 'vncserver' supplies. I'd basically end up rewriting a parallel 'vncserver' script myself. -Kyle -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ooO(_)Ooo- ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: vncserver shouldn't run .vnc/xstartup when xdmcp options are used.
Here's the patch. I'm surprised I haven't seen any response to
this message. Maybe I'm the only one who uses the -query option??
-Kyle
-
--- vncserver Tue Jan 25 16:28:29 2005
+++ vncserver.new Tue Jan 25 16:25:08 2005
@@ -54,7 +54,8 @@
# Check command line options
&ParseOptions("-geometry",1,"-depth",1,"-pixelformat",1,"-name",1,"-kill",1,
- "-help",0,"-h",0,"--help",0);
+ "-help",0,"-h",0,"--help",0,"-query",1,"-broadcast",0,
+ "-indirect",1);
&Usage() if ($opt{'-help'} || $opt{'-h'} || $opt{'--help'});
@@ -147,6 +148,9 @@
$cmd .= " -rfbwait 3";
$cmd .= " -rfbauth $vncUserDir/passwd";
$cmd .= " -rfbport $vncPort";
+$cmd .= " -query $opt{'-query'}" if ($opt{'-query'});
+$cmd .= " -indirect $opt{'-indirect'}" if ($opt{'-indirect'});
+$cmd .= " -broadcast" if ($opt{'-broadcast'});
# Add font path and color database stuff here, e.g.:
#
@@ -157,6 +161,7 @@
foreach $arg (@ARGV) {
$cmd .= " " . "edString($arg);
}
+
$cmd .= " >> " . "edString($desktopLog) . " 2>&1";
# Run $cmd and record the process ID.
@@ -168,36 +173,38 @@
sleep(3);
-warn "\nNew '$desktopName' desktop is $host:$displayNumber\n\n";
+warn "\nNew '$desktopName' desktop is $host:$displayNumber\n";
+warn "Log file is $desktopLog\n\n";
-# Create the user's xstartup script if necessary.
+if ( !($opt{'-broadcast'} || $opt{'-indirect'} || $opt{'-query'})) {
-if (!(-e "$vncUserDir/xstartup")) {
-warn "Creating default startup script $vncUserDir/xstartup\n";
-open(XSTARTUP, ">$vncUserDir/xstartup");
-print XSTARTUP $defaultXStartup;
-close(XSTARTUP);
-chmod 0755, "$vncUserDir/xstartup";
-}
+# Create the user's xstartup script if necessary.
+if (!(-e "$vncUserDir/xstartup")) {
+warn "Creating default startup script
$vncUserDir/xstartup\n";
+open(XSTARTUP, ">$vncUserDir/xstartup");
+print XSTARTUP $defaultXStartup;
+close(XSTARTUP);
+chmod 0755, "$vncUserDir/xstartup";
+}
-# Run the X startup script.
+# Run the X startup script.
-warn "Starting applications specified in $vncUserDir/xstartup\n";
-warn "Log file is $desktopLog\n\n";
+warn "Starting applications specified in
$vncUserDir/xstartup\n\n";
-# If the unix domain socket exists then use that (DISPLAY=:n)
otherwise use
-# TCP (DISPLAY=host:n)
+# If the unix domain socket exists then use that (DISPLAY=:n)
otherwise use+# TCP (DISPLAY=host:n)
-if (-e "/tmp/.X11-unix/X$displayNumber" ||
--e "/usr/spool/sockets/X11/$displayNumber")
-{
-$ENV{DISPLAY}= ":$displayNumber";
-} else {
-$ENV{DISPLAY}= "$host:$displayNumber";
-}
-$ENV{VNCDESKTOP}= $desktopName;
+if (-e "/tmp/.X11-unix/X$displayNumber" ||
+-e "/usr/spool/sockets/X11/$displayNumber")
+{
+$ENV{DISPLAY}= ":$displayNumber";
+} else {
+$ENV{DISPLAY}= "$host:$displayNumber";
+}
+$ENV{VNCDESKTOP}= $desktopName;
-system("$vncUserDir/xstartup >> " . "edString($desktopLog) .
" 2>&1 &");
+system("$vncUserDir/xstartup >> " .
"edString($desktopLog) . " 2>&1 &");
+}
exit;
--
_
-ooO( )Ooo
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. | [EMAIL PROTECTED]
1 Network Drive \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o)fax: (781) 442-1542
ooO(_)Ooo-
___
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
vncserver shouldn't run .vnc/xstartup when xdmcp options are used.
Hi, I might be wrong, but I always have problems when I run vncserver with -query, -indirect, or -broadcast, because not only do the XDMCP windows appear but the clients in my .vnc/xstartup script also try to connect. Sometimes I even end up with 2 windows mangers trying to connect, and worse sometimes the 'wrong' one starts first. It seems to me that vncserver should skip the xstartup if any of those options are used. Currently I make sure xstartup is empty, or has everything commented out when I use these options, but it's a pain to edit the file back and forth. I wish it could just be there for when I need it and ignored the rest of the time. I have a patch for the vncserver script, but I"m not sure I started wit the latest version. Please let me know if you think the patch would be useful. -Kyle -- _ -ooO( )Ooo Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc. | [EMAIL PROTECTED] 1 Network Drive \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ooO(_)Ooo- ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Setenv Variables on a VNC Session
Kaplan, Andrew H. wrote: I tried the same procedure while omitting step 2. This time the program appears to be loading, but the gui does not appear. The only message that appears on the screen indicates the database is loading. After five minutes, the program has still not loaded. Make sure that $DISPLAY is really already set to point the VNC server. (not to the machine where you're rinning the viewer.) -Kyle -Original Message- From: Kyle McDonald - Eagle CAD [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 4:07 PM To: Kaplan, Andrew H. Cc: [EMAIL PROTECTED] Subject: Re: Setenv Variables on a VNC Session Kaplan, Andrew H. wrote: I am trying to get a particular program to run via a VNC connection, but am currently unable to do so. The program does run when invoked via a Hummingbird client connection. Here is the procedure that works on the Hummingbird connection and I am trying to get to work on the VNC: 1. Connect to the remote client via a telnet session. 2. Type setenv DISPLAY :0.0 3. Type setenv FOCUS /FOCUS 4. /usr/tools/cms/bin/focus_data_center The above procedure works fine via Hummingbird, but not so with VNC. Anyone have insight into this? Thanks. Try skipping step 2 in the VNC session. DISPLAY should already be set to the right value. You shouldn't need to set it again. Also :0.0 is likely the wrong value if you want it to run in VNC. If this still doesn't work, you'll have to post more details, like the error messages you get when running the application. -Kyle -- _ ---ooO( )Ooo--- Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc.| Enterprise Server Products[EMAIL PROTECTED] 1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ---ooO(_)Ooo--- ___ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Setenv Variables on a VNC Session
Kaplan, Andrew H. wrote: I am trying to get a particular program to run via a VNC connection, but am currently unable to do so. The program does run when invoked via a Hummingbird client connection. Here is the procedure that works on the Hummingbird connection and I am trying to get to work on the VNC: 1. Connect to the remote client via a telnet session. 2. Type setenv DISPLAY :0.0 3. Type setenv FOCUS /FOCUS 4. /usr/tools/cms/bin/focus_data_center The above procedure works fine via Hummingbird, but not so with VNC. Anyone have insight into this? Thanks. Try skipping step 2 in the VNC session. DISPLAY should already be set to the right value. You shouldn't need to set it again. Also :0.0 is likely the wrong value if you want it to run in VNC. If this still doesn't work, you'll have to post more details, like the error messages you get when running the application. -Kyle -- _ ---ooO( )Ooo--- Kyle J. McDonald (o o) Systems Support Engineer Sun Microsystems Inc.| Enterprise Server Products[EMAIL PROTECTED] 1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184 Burlington, MA 01803 (o o)fax: (781) 442-1542 ---ooO(_)Ooo--- ___ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
XDMCP time rollover bug?
Hello.
My coworkers and I regularly use the -query option to 'vncserver'.
Unfortunately after the server has been up and running for a long time
our session is disconnected and the Xvnc dies.
I have been asking around and I was pointed to the following
X11/XFree86 bug report which has been fixed for a little while now.
I checked the file in question in the vnc-3.3.7-unixsrc.tgz and it
appears that this bug still exists in RealVNC.
Is it possible to get this incoporated into a future release of
RealVNC?
Thanks,
-Kyle
--
_
---ooO( )Ooo---
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc.|
Enterprise Server Products[EMAIL PROTECTED]
1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o)fax: (781) 442-1542
---ooO(_)Ooo---
Received: from phys-d3-ha21sca-1 (phys-d3-ha21sca-1.SFBay.Sun.COM
[129.145.155.163]) by josie.East.Sun.COM
(8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hALNxPm28600 for
<@josie.East.sun.com:[EMAIL PROTECTED]>; Fri, 21 Nov 2003 18:59:25
-0500 (EST)
Received: from Sun.COM (almas.SFBay.Sun.COM [129.145.23.120]) by
ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16
(built May 14 2003)) with ESMTP id
<[EMAIL PROTECTED]> for [EMAIL PROTECTED]
(ORCPT [EMAIL PROTECTED]); Fri, 21 Nov 2003 15:59:24 -0800 (PST)
Date: Fri, 21 Nov 2003 15:59:24 -0800
From: Alan Coopersmith <[EMAIL PROTECTED]>
Subject: [Fwd: Xserver: overflow condition in XdmcpWakeupHandler()]
To: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1)
Gecko/20030711
Original Message
Subject: Xserver: overflow condition in XdmcpWakeupHandler()
Resent-Date: 21 Feb 2002 11:07:00 -
Resent-From: [EMAIL PROTECTED]
Resent-To: [EMAIL PROTECTED]
Date: Thu, 21 Feb 2002 02:47:18 -0700 (MST)
From: Paul Anderson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Xserver: rollover condition in XdmcpWakeupHandler()
VERSION:
X.Org: R6.6
XFree86: Current 4.2 CVS tree as of 18-Feb-2002
CLIENT MACHINE and OPERATING SYSTEM:
HP-UX
DISPLAY TYPE:
N/A
WINDOW MANAGER:
N/A
COMPILER:
ANSI cc on HP-UX
Others?
AREA:
Xserver
SYNOPSIS:
It looks like there is a rollover condition in
xc/programs/Xserver/os/xdmcp.c:XdmcpWakeupHandler()
which can cause XDM sessions to be terminated.
DESCRIPTION:
The XDMCP code calculates its timeout time incorrectly
when the time wraps from 0x to 0x.
The routine XdmcpWakeupHandler() currently has the following
comparison in its 'else if' condition:
else if (timeOutTime && GetTimeInMillis() >= timeOutTime)
{
if (state == XDM_RUN_SESSION)
{
state = XDM_KEEPALIVE;
send_packet();
}
else
timeout();
}
A problem with this test occurs when we wrap back to 0 every 49+
days. When this occurs, Xservers with active XDMCP sessions
will send XDM_KEEPALIVE messages to the XDMCP host continually
for ~3 minutes. If the host computer cannot reply to all of the
keep-alive messages in time, the Xservers seem to assume that the
host is dead, and the server terminates any XDM sessions.
Whether or not the session is closed will depend on the network
load, etc.
If the test in the 'else if' branch is changed from:
else if (timeOutTime && GetTimeInMillis() >= timeOutTime)
to:
else if (timeOutTime && (int)(GetTimeInMillis() - timeOutTime) >= 0)
the problem is avoided. As a result, the XDM_KEEPALIVE
sessions aren't sent continuously.
REPEAT BY:
You could wait the 49+ days for the rollover to occur. Or
the following sample program indicates the differences
in the two comparisons used in the 'else if' branch.
This might not reconstruct the problem exactly, but it
should indicate whether or not a compiler generates
code that will hit the problem.
#include
#include
unsigned int timeOutTime, GetTimeInMillis, GetTimeInSec;
int millis;
main()
{
int test1, test2, timeOut;
int n; int days;
/* Start with time of day close to the value where
* (time_of_day_in_sec*1000) overflows an unsigned int.
*/
GetTimeInSec = 49*24*3600 + 16*3600; /* 49 days, 16 hours*/
GetTimeInMillis = 0;
millis = 0;
timeOut = 2; /* Always set time out to 2 millisec */
timeOutTime =
