Re: [discuss] Authoxy 3.0 - Daemon Port does not stick
on 31/01/04 08:54, Kurt Seemann at [EMAIL PROTECTED] wrote: Hi Heath, etal. Two things, ONE: I have noticed that since updating to authoxy 3, both on Panther 10.3.2 and Jaguar 10.2.8, some odd things happen. In Jaguar, Authoxy 3, when the daemon in running (127.0.0.1) it too often loses its port dropping to 'unknown'. This seems to cause failure to access the net, in my case via system prefssoftwareupdates. I noticed if I turn authoxy off then on again, it correctly establishes the port (8080) and I can then successfully execute the SWUpdate function. However, in Panther, using Authoxy 3.0, I seem to be able to do the SWUpdate, even when port unknown is shown. Is this issue known? I am thinking I may need to go back to v2.3 of authoxy for jaguar10.2.8. ??? TWO: I know I have mentioned it before, but my university technicians won't budge on the issue that our autoproxy script is correctly written and functioning just fine, eventhough its not compatible with Macs (perceived as another weak feature of macs I think). One technician reckons Mozilla and an old netscape version used to handle *.cgi autoproxy scripts, but that now both don't either on Macs. We use the following script: http://config.scu.edu.au/cgi-bin/proxy.cgi The position is that the *.cgi script is working just fine, they see no reason to move to *.pac. What is the difference between a *.pac and *.cgi auto proxy anyway? Can Authoxy be tweaked to specifically accommodate a *.cgi autoproxy script and/or a *.cgi autoproxy script somehow? Many thanks Kurt I think there are some cosmetic issues with Authoxy 3, the port number being one of them. But, this has been present for a long time. When you open Authoxy pref pane *after* the daemon is running, it always report unknown port number... -Laurent. -- Laurent Daudelin AIM/iChat: LaurentDaudelinhttp://nemesys.dyndns.org Logiciels Nemesys Software mailto:[EMAIL PROTECTED] bytesexual /bi:t`sek'shu-*l/ adj.: [rare] Said of hardware, denotes willingness to compute or pass data in either big-endian or little-endian format (depending, presumably, on a mode bit somewhere). See also NUXI problem.
Re: [discuss] Authoxy 3.0 - Daemon Port does not stick
on 03/02/04 04:04, Heath Raftery at [EMAIL PROTECTED] wrote: This is, and always has been, by design! Looks like I need to revise the interface there. The thing is, when the Preference Pane is used the start the daemon, the PP knows the port number it used to start the daemon with. After you close System Preferences and re-open it, there is no way for the Preference Pane to know whether it started the daemon, whether the port number has changed since, whether startAuthoxy was used to restart the daemon, or whether the preferences has changed, so to be safe it reports the port as unknown. The daemon will continue to run on the port you started it, completely independent of the status reported in the Preference Pane. I realise this really should be made clearer. Heath, I think it would be less confusing if you were not displaying the unknown. I think that's why people assume something is wrong. Since getting the port number is not that much reliable, why don't you stop displaying it at all? What is it good for if you can only display when you start the daemon? -Laurent. -- Laurent Daudelin AIM/iChat: LaurentDaudelinhttp://nemesys.dyndns.org Logiciels Nemesys Software mailto:[EMAIL PROTECTED] Blue Screen of Death n.: [common] This term is closely related to the older Black Screen of Death but much more common (many non-hackers have picked it up). Due to the extreme fragility and bugginess of Microsoft Windows, misbehaving applications can readily crash the OS (and the OS sometimes crashes itself spontaneously). The Blue Screen of Death, sometimes decorated with hex error codes, is what you get when this happens. (Commonly abbreviated BSOD.)
Re: [discuss] Speed question
on 03/09/04 11:43, Steven Stratford at [EMAIL PROTECTED] wrote: Question: Seems slow. Are there ways/tricks for speeding things up? Our network is 100baseT so it¹s not slow when I connect directly to our proxy server. I've been using Authoxy since version 2.1 (or 2.2 maybe) and I've never noticed any slowdown. Not that there isn't any, just that I've never noticed them if there are some. I regularly transfer files from my PeeCee to my PowerBook, also over a 100BaseT connection, through a DHCP setup. -Laurent. -- Laurent Daudelin AIM/iChat: LaurentDaudelinhttp://nemesys.dyndns.org Logiciels Nemesys Software mailto:[EMAIL PROTECTED] fudge: 1. vt. To perform in an incomplete but marginally acceptable way, particularly with respect to the writing of a program. I didn't feel like going through that pain and suffering, so I fudged it -- I'll fix it later. 2. n. The resulting code.
Re: [discuss] Speed question
on 03/09/04 20:04, Steven Stratford at [EMAIL PROTECTED] wrote: It might be because I have to use NTLM? --Steve On 9/3/04 5:44 PM, Laurent Daudelin [EMAIL PROTECTED] wrote: on 03/09/04 11:43, Steven Stratford at [EMAIL PROTECTED] wrote: Question: Seems slow. Are there ways/tricks for speeding things up? Our network is 100baseT so it¹s not slow when I connect directly to our proxy server. I've been using Authoxy since version 2.1 (or 2.2 maybe) and I've never noticed any slowdown. Not that there isn't any, just that I've never noticed them if there are some. I regularly transfer files from my PeeCee to my PowerBook, also over a 100BaseT connection, through a DHCP setup. -Laurent. Quite possible but only Heath would be able to tell for sure... -Laurent. -- Laurent Daudelin AIM/iChat: LaurentDaudelinhttp://nemesys.dyndns.org Logiciels Nemesys Software mailto:[EMAIL PROTECTED] Brooks's Law prov.: Adding manpower to a late software project makes it later -- a result of the fact that the expected advantage from splitting development work among N programmers is O(N) (that is, proportional to N), but the complexity and communications cost associated with coordinating and then merging their work is O(N^2) (that is, proportional to the square of N). The quote is from Fred Brooks, a manager of IBM's OS/360 project and author of The Mythical Man-Month (Addison-Wesley, 1975, ISBN 0-201-00650-2), an excellent early book on software engineering.
Re: [discuss] Problems with Authoxy 3.2?
on 08/03/06 22:10, Heath Raftery at [EMAIL PROTECTED] wrote: I've been doing a bunch of testing on 3.2 really trying to stress it hard. I'm afraid I simply cannot reproduce these issues. The odd thing is that basically very little has changed in the connection side of things, so this has got me beat at the moment. I have seen the unable to create new processes thing come up occasionally though and am considering some workarounds. In the mean time, you could try increasing the maximum number of processes allowed by the system using sysctl: To show the current limit: % sysctl kern.maxproc To change the limit: % sudo sysctl -w kern.maxproc=1000 And on my end I'll look into setrlimit and alternative ways to invoke processes (perhaps akin to Apache or Squid). Regards, Heath I have been running for about a week with a larger number of maximum processes and I have to report that Authoxy 3.2.5 hasn't given me any problem so far, none whatsoever. I followed the directions in at MacOSXHints.com to permanently increase those limits through a launchd config file. My soft limit is currently 512 and my hard limit is 2048. No problem so far. -Laurent. -- Laurent Daudelin AIM/iChat: LaurentDaudelinhttp://nemesys.dyndns.org Logiciels Nemesys Software mailto:[EMAIL PROTECTED] larval stage: n. Describes a period of monomaniacal concentration on coding apparently passed through by all fledgling hackers. Common symptoms include the perpetration of more than one 36-hour hacking run in a given week; neglect of all other activities including usual basics like food, sleep, and personal hygiene; and a chronic case of advanced bleary-eye. Can last from 6 months to 2 years, the apparent median being around 18 months. A few so afflicted never resume a more `normal' life, but the ordeal seems to be necessary to produce really wizardly (as opposed to merely competent) programmers. See also wannabee. A less protracted and intense version of larval stage (typically lasting about a month) may recur when one is learning a new OS or programming language.
