Whatever you do doc, be sure the person you let handle your server is of an adult mind and not some kid with a propensity for porn or warez. Make sure you check your logs and files from time to time, (i.e., DAILY) until you are reasonably confident you are dealing with a straight shooter. Otherwise you might find yourself trying to convince a magistrate that the stuff the police found on your computer for sharing and distribution was not put there by you.
Running a Q2 server is not very difficult and I would encourage you to do it yourself and look at it as a learning opportunity. Promotion is simple, have a decent server and list it on a few web sites and list it here, on R1ch's server and on gametracker.com and a few other places and your server will thrive.
11 hops is pretty good. I am 15 hops away from my favorite server.
I don't know where Reaper gets the idea you didn't drop any packets, the traceroute doesn't include that information. If you get * * * it doesn't mean you lost frames, it means the router at that hop doesn't process traceroute frames of that type or the host is unreachable with that protocol. Many ISPs block ICMP ECHO frames at their borders to prevent abuse. Linux traceroute uses UDP packets IIRC, it doesn't use ICMP ping frames so the profile will be similar with the UDP frames in game. Client frames are frequent and small, server downlink frames are larger, probably 20 or 40 bytes vs 200 or 400 depending on the game action.
The ping profile is fairly flat, your ping is under 1 ms until you get into level3.net but they are a major backbone carrier and the ping will vary with time of day. Notice Tampa1 had a low ping at that time.
Remember, the return frame from a ping is under no obligation to follow the exact reverse path back to you as the outbound frame.
Those intermediate hops are excellent for your ISP. I wouldn't change a thing.
The best indicator of the path between you and the server is the netgraph in the game. If it's low, green and flat with minimal spikes, you are getting good performance.
you were making a modem? how does the analog data get demodulated in hardware? then the processor (an asic or regular processor on the motherboard or pc) gets this data, which is binary, and reads the data as a digit dialed?
No modem. It was a repeater controller. The morse was for ID purposes. The DTMF was for control signalling - telecommand. You commanded the system with a DTMF pad. Mitel MT8870 chip did the encode/decode. Phase locked loops and some digital filters in the chip, as I recall. Microprocessors weren't up for DSP applications, at least not affordable systems at that time. The chip set a bit and a 4 bit decode when it received a valid tone. I used the bit to issue an interrupt and the ISR would read the nibble and pass it off to the command buffer. End of the command string was signalled by dropping the radio carrier.
I used to be into computers because it was interesting to get into the guts of them and make them do what you wanted them to do. I designed several of my own microcomputer systems, several of which were dedicated to remote control and communications. I've toyed with RCA1802's, 8080A's, Z80's, 6502's, 6809's, Z180/64180, x86's, PDP8, PDP10, MicroVAX, and all kinds of assembly languages and HLL's. I have coded RTOS's and foreground/background systems. I have generated morse code and decoded DTMF with microcomputers. In my job I work daily with machine tool CNC controls and electomechanical systems. I no longer find "learning how something works" to be as entertaining as it used to be. Now my computers are tools. Linux is a tool. If I have to get down and dirty and turn a crank on a crufty user interface I am not entertained or enlightened. All I want to do is get some work done without having to reinvent the wheel.
You will find this is the attitude of 99% of users worldwide, they are not lazy. They just have more important things to do that learn the guts and tortured logic of why things are done certain ways in Linux. The problem with Linux advocates is they are so into the "isn't this cool" attitude that they can't identify with the "just get it done" user base. They don't care about "su", "cp" or "mv" or 10,000 other cryptic and nonsensical commands and their switches in Linux. This is why consumers buy Windows pre-installed and Macs with OS/X and applications preinstalled. They don't want to know what's inside, they just want to do cool stuff. Today, without effort, with one hand and minimal keyboarding or reading.
Whirlingdervish(Q2C) correctly described it. It's called "distance clipping" or Z-clipped. I have had it in OpenGL mode too. One map even fades to space for me leaving me totally blind in a world of sky. I can't remember the map name offhand. Really fun when it happens, not! The range of vision simply starts reducing and fades to zero range, then magically starts receding again until I get full range again. R1Q2 client, R1GL graphics.
Which version of SP3? There were RC1, RC2, a general release, a general re-release after they found problems in SP3 on some systems.
I generally try to stay at least 2 to 3 months behind the power curve on updates unless there is a real reason to get it (like a security issue).
Locate the COMCTL32.DLL in windows/system32 and right click it to get properties. Report your version info for the DLL. The File Version in the top of the Version tab and the Product Version from the list boxes.
In spite of not knowing, I had a laptop here that I could afford to update and test. I ran pakscape in SP2 and it works OK with SP2's comctl32, version 5.82.2900.2982 6.0.2900.2982.
I then tried to update to SP3 using WU. Ho hum. It forced a WGA download, validated the system and listed SP3 as available after 10 minutes of grinding on my hard drive. I clicked on the Install button and it barfed, telling me I didn't accept the EULA... duh, what EULA? It never asked. Is this the EULA that says they do anything they want while sit and take it? I tried 3 more times with the same result.
I will reboot and try again but if it fails the update again it'll be a while before I can post what I find because SP3 won't be on my list of "nice to have". One of the rumors is that SP3 is supposed to make XP more "Vista-like". If this update problem is any indication, yep, it's more Vista-like alright.
If you really want to see if SP3 is the culprit, I would recommend going back to the pre-SP3 restore point and trying pakscape again. My examination of pakscape shows a VC 6.0 compiled executable with nothing special or tricky inside so I can't explain why it would fail. MS makes a big deal of backwards-compatibility testing so if the SP broke it I would be surprised... but then this update bug is surprising too.
Update: OK. I have tried Express and Custom updates. All fail to install SP3 for failed EULA acceptance. I am downloading the 316MB file directly but won't have time to install it for a while.
svchost.exe is the program that spawns services in Windows. (the equivalent of daemons in *nix world) Svchost.exe is the service starting service. He looks at the installed services list in the registry and starts them all up.
McAfee is sadly lacking any documentation about your Trojan. It was discovered only 1 month ago and they have a detection profile for it but it looks like they don't have a removal process or any technical information about it. I am not sure what the "mem" designation means in McAfeesh but it might mean memory resident. That would mean it's being loaded and their memory scanner found it but not the executable file. It could be deposited from a malicious web page.
Use the Process Explorer that Reaper listed. That is an excellent tool for looking at processes in the system. In the tree view of processes, your Trojan will be lurking as a child of one of the many svchost.exe processes. If it is packed with one of the many packers used to hide these kinds of programs it will be purple and stand out like a sore thumb. It will also have an unknown publisher and won't "Verify" with a digital signature. Use P. Exp. to find the executable. It will usually be in an odd-ball place, masquerading as a Windows/system32 file but not in the proper directory. In really bad infections it can be in the Windows/system32 folder and they can be hard to kill.
Kill the process in P. Exp. and immediately delete the file. Beware, some trojans have guards that are also running, usually as DLL's that will restore the file and the trojan process as fast as you can kill it. Safe mode can sometimes get past this. You always want to identify the executable file that is your Trojan.
Another good tool is Autoruns from the Sysinternals.com (now Microsoft) This one lists the registry settings that initiate the processes at boot. You can sometimes kill the startup of your Trojan directly at the registry, then kill the file.
CCleaner is another good tool.
Activate Windows Defender and run a scan. Believe it or not, it's actually quite a good tool for getting rid of this kind of junk. It will also run compatibly with other A-V products.
Get rid of McAfee, it's bloatware as bad as Symantec. These products are so bloated they have become exploitable.
Get NOD32 from Eset. It's still an efficient A-V product without bloat. You can even use their free trial to get rid of this thing once you get rid of McAfee.
If you have the executable identified upload it to www.virustotal.com for scanning and see if it goes by another name.
Yes, but when you put it in the context of (about) 2000 operations per second on 2 42-bit words it's bit-wise fairly comparable to those first microprocessors like the 4004, 8008. Being a hacker on a UNIVAC meant you could decode all 42 bits of a memory word in that oscilloscope in your head and spot the bad tube.
Just think. From 1951 to 1961 we went from vacuum tubes and 29,000 pounds to SSI chips and computers that could be airborne. From 1961 to 1971 we had computers in small boxes that could navigate to the moon on 100 watts of power. From 1971 to 1981 we had microprocessors that could run space probes all the way to Mars and two probes (Voyager 1 and 2 using 2 RCA 1802's each at 100kHz) that are still running after 41 years in space. From 1981 to 1998 we had huge advances in CPU speed and memory, going from 64kB memories to 640kB and more. From 1998 to 2008 we went from 300 baud dialup and acoustic modems and ASCII art to 50Mbps fiberoptic cables and near terabyte disk drives and computers that can consume upwards of 500 watts of power just for cpu, memory and hard drives. Er, um... what was that about 100 watts?
We can now surf porn and video of some doofus cracking his nuts on a handrail with a skateboard on YouTube faster than any other culture on the planet.
"UNIVAC I used 5,200 vacuum tubes,[4] weighed 29,000 pounds (13 metric tons), consumed 125 kW, and could perform about 1,905 operations per second running on a 2.25 MHz clock. The Central Complex alone (i.e. the processor and memory unit) was 4.3 m by 2.4 m by 2.6 m high. The complete system occupied more than 35.5 m² of floor space."
Memory was 1000 words.
The tubes were binary, that is, they were either on or off, like our current computer technology but the data states were represented as pulse trains signifying the value of the word being represented. All the words were equal length so you could think of a word as being sent in an almost Morse code fashion. The basic pulse frequency of the word clock was 1MHz and it took 42 microseconds to transmit one word. One machine word was a 42 bit serial train of pulses clocked at 1MHz.
Storage was mercury delay lines. The computer could never pass today's environmental impact requirements.
The computer only had 8 instructions or an opcode of 3 bits and 2 bits of word and 2 bits of channel selectors for manipulating main memory or the operands of the instructions. Main "memory" was an acoustic delay line of 16 words. You might think of these 16 words as today's instruction/data pipeline.
Yes, you toggled it, but that was to load the program. Much like was done on the first microprocessor machines like the MITS Altair 8800, Imsai 8080 or Cromemco. Once the program was loaded, it would operate until it malfunctioned or hit the halt instruction. Often it was a race to see which would happen first.
All in all an amazing piece of engineering for its day.
I don't think it's as much as a working for free issue as much as it's not centrally managed. Everyone who codes for Linux is trying to satisfy a perceived need or solve a particular problem. There is certainly no way to control the organic growth of the collection. As you say, the transparency for users comes last. Solving the immediate needs of the nerd community is first. If there is useability feedback on a particular tool, it comes from other nerds who may or may not think about unsophisticated users.
Well, I am sorry if that appeared to be a surprise but the tone of the majority of the writers in this thread appeared to me to be reasonable but perhaps there were undertones along lines I am unaware. Your page was somewhat rambling and hard to understand but your posture here in this thread is far from putting things aside. At every response to your original posts you appear to be lashing out an "I can't trust you...", etc at every turn. Perhaps if things are that irrepairable you would be better off remembering it's supposed to be a game and we are all supposed to be in it for the fun. When it's not fun anymore and your not getting paid big bucks to do it, it's time to stop and move on to something else.
Peak oil? The greatest impediment to our economic reformation is the current "low" price of oil. Europe is paying upwards of twice the price for gasoline as the U.S. The market prices are not associated with "production costs" but speculation and premiums on availability. This is why oil company profits are up. Consumption is fixed, supply is controlled, this is why prices are "unstable". The peak oil phenomenon may work for individual wells and fields but exploration and exploitation of existing reserves will mitigate the decline. Further, yes the world IS full of oil. It was produced when the planet was formed out of the primordial gasses. One only has to look at Titan to know that methane (natural gas) and hydrocarbons (oil) are abundant where no life exists.
The economies of the world need to back off the idea that you can live in the suburbs and commute 40 miles to work and back every day and they don't have to fly coast to coast for a 2 hour meeting anymore. Internetworking is the key to solving these problems and only increasing the cost of transportation will control the "rationing" of it for things like food, real material goods fabrication of plastics and polymers. Burning it is BAD. It's time we learned that. Air transportation needs to decline, cars need to become more efficient, even to the point of them becoming "luxury" items. Decentralization of industries and investment in public transportation are paramount and these things won't happen until they become cheaper in comparison to continuation of the status quo.
Show Posts
