SoylentNews

put movement of active unit into a function

created <init> and <quit> reserved aliases in exec (irc.php), which i'll eventually use for loading/saving game data (in addition to timed saves).

used cmd.php (attached to * alias which runs on every received line of data) to fire commands on a 330 numeric event (whois/logged in as) to make startup a bit easier - automatically sets player alias lock to "civ" (in game channel only) and outputs a status command, so that when a player joins a game channel, they can start moving their active unit pretty much straight away (after a 2 or so second delay in processing login script).

IRCiv wiki page created: http://wiki.soylentnews.org/wiki/IRCiv

latest source pushed to github: https://github.com/crutchy-/test

next up... adding a settler unit and getting the active unit cycle function working

IRCiv is a little game (and game engine of sorts) for building stuff like in "Civilization"-branded games.

Currently it piggybacks as a couple of scripts for the exec bot. Refer to the wiki for more info on exec: http://wiki.soylentnews.org/wiki/IRC:exec

Implemented some basic unit movement last night. Can use "up" or "u" action on the active unit (along with equivalents in the 3 other directions).

The game is being gradually developed/tested most nights (Australian time) in the #civ channel of Soylent IRC. Feel free to join, but be aware that you may get pinged by the bot a fair bit (you're always free to duck in and out whenever you like of course).

Other stuff that has been implemented already:
- auto-login on join/logout on part
- logins based on nickserv account name (using whois), so means that players must be registered with nickserve
- supports nick changes
- map generator has been developed (random landmasses based on a couple of parameters)
- map image dump
- map text file dump
- player settings and flags system
- player active unit status output to either game channel or private message (based on "public_status" flag)

Currently development is mainly in PHP, but using the exec bot system, game features/modules can be developed in any language.
Each command runs as a separate script in its own process instance, but can easily communicate with IRC and access persistent game data.
The project is open-source (GPL2) and can be found here: https://github.com/crutchy-/test
Feel free to fork or pilfer, but please share your changes/derivatives.
Anyone interested in contributing to the current project, look for crutchy in #soylent or #civ on IRC.

So ... I've recently gotten back into minecraft, and figured that perhaps there are other MC players here at SN, so I wanted to know if there was enough interest to setup a MC server in general. I'd probably use CraftBukkit, and I'm open to running mods if others are interesting. Leave a message below if you'd be interested.

Mods I'd like to run:
  * Traincraft
  * Railcraft
  * Mystcraft (useful for getting new ores without having to reset maps; age creation would be restricted to admins though; mystcraft is a server hog).

Leave your thoughts below.

Since we've got a fair number of complaints about us running too many site news articles, I'm going to condemn this to my journal, then link it next time we *do* post something about the site. For a large portion of today (4/16), SoylentNews users had issues with commenting, and moderation was completely hosed. This was due to a backend change; we shifted the site behind a loadbalancer in preparation of bringing up a new frontend and give us considerably more redundancy and latitude with working with the backend.

This change had been setup on dev for the last week with us testing it to see what (if anything) broken, and it was discussed and signed off by all of the staff. Last night, I flipped the nodebalancer to connect to production instead of dev, then changed the DNS A record for the site to point at the loadbalancer.

I stayed up for several hours at this point to ensure nothing odd was going on, and satisfied that the world would keep spinning, I went to bed. What I found though was I broke the formkeys system. Slash knows about the X-Forwarded-By header, a mechanism for when a site is behind a proxy on how to relay client IP information (this mechanism was already used by both varnish and nginx), however, for security reasons, we strip out the XFF header from inbound connections unless its on a specific whitelist. On both dev and production, we had whitelisted the nodebalancer to pass this header in properly.

Or so we thought. Linode's documentation doesn't mention, but the IP address listed in the admin interface is *not* the IP used to connect to the site; instead it uses a special internal IP address which isn't listed or documented anywhere. Our security precautions stripped out the X-Forwarded-By header, and made it appear that all inbound users were coming from the same IP. This wasn't noticed on dev as slash ignores the formkeys system for admins, and the few of us beating on it with non-admin accounts weren't able to do enough abuse to trigger the formkey limiters.

Our peak hours are generally evenings EDT, which means the low traffic at night wasn't enough to trip it either (or at least no one on IRC poked me about it, nor were there any bugs on it on our github page. However, once traffic started picking up, users began to clobber each other, commenting broke, and the site went to straight to hell. When I got up, debugging efforts were underway, but it took considerable time to understand the cause of the breakage; simply reverting LBing wasn't an easy fix since we'd still have to wait for DNS to propagate and we needed the load balancer anyway. After a eureka moment, we were able to locate the correct internal IPs, and whitelist them, which got the site partially functional again. (we have informed Linode about this, and they said our comments are on its way to the appropriate teams; hopefully no other site will ever have this same problem).

The last remaining item was SSL; we had originally opted out of terminating SSL on the loadbalancer, prefering to do it on the nginx instance, so Port 443 was set to TCP loadbalancing. This had the same effect as there is no way for us to see the inbound IP (I had assumed it would do something like NAT to make connections appear like they were coming from the same place). The fix was utlimately installing the SSL certificate on the load balancer, then modifying varnish to look for the X-Forwarded-Proto header to know if a connection was SSL or not. I'm not hugely happy about this as it means wiretapping would be possible between the load balancer and the node, but until we have a better system for handling SSL, there isn't a lot we can do about it.

As always, leave comments below, and I'll leave my two cents.

Hi,

So, my evening/night started like any other until I started having several nosebleeds which all occurred within one or two hours or so not to mention the headache, so like any responsible geek I decided to phone my Doctor, fortunately, he was still awake and told me to go to the hospital... (what I got told there isn't important to this journal entry)

Anyway, so when I came home the IRC server was *seemingly* down, in fact, my entire server was *seemingly* down. After contacting my ISP, I had to go through a few hoops - and as it turns out, it was a faulty switch (you'd think, they would at least be monitoring their own switches right?). They replaced it and it's all back up. Incidentally, I was going to configure Carbon (which was going to be another IRC server) last night but the hospital thing came up.

So all in all, my night sucked big time.

Hopefully, not to many of you were inconvenienced by the downtime, perhaps some of you even managed to see the sun, or at the very least, felt the wind.

Update: webchat was still down, sorry about that.

A $1,499 supercomputer on a card? That's what I thought when reading El Reg's report of AMD's Radeon R9 295X2 graphics card which is rated at 11.5 TFlop/s(*). It is water-cooled, contains 5632 stream processors, has 8 GB of DDR5 RAM, and runs at 1018MHz.

AMD's announcement claims it's "the world's fastest, period". The $1,499 MSRP compares favorably to the $2,999 NVidia GTX Titan Z which is rated at 8 TFlop/s.

From a quick skim of the reviews (at: Hard OCP, Hot Hardware, and Tom's Hardware), it appears AMD has some work to do on its drivers to get the most out of this hardware. The twice-as-expensive NVidia Titan in many cases outperformed it (especially at lower resolutions). At higher resolutions (3840x2160 and 5760x1200) the R9 295x2 really started to shine.

For comparison, consider that this 500 watt, $1,499 card is rated better than the world's fastest supercomputer listed in the top 500 list of June 2001.

(*) Trillion FLoating-point OPerations per Second.

Now that I've had some time to clear my head, I want to expand on my original feelings. I'm pissed off about this, and my temper flared through on the original post. I'm leaving it as is because I'm not going to edit it to make myself look better, and because it sums up my feelings pretty succinctly. How would you feel if something you worked on under the promise of building the best site for a community was regularly and routinely causing corporate firewalls and IDS systems to go off like crazy?

You'd be pissed. Had we known about this behaviour in advance, it would have been disabled at golive or in a point release, and a minor note would have gone up about it. Instead, I found out because we were tripping a user's firewall causing the site to get autoblocked. I realize some people feel this is acceptable behaviour, but a website should *never* trigger IDS or appear malicious in any way. Given the current state of NSA/GCHQ wiretapping and such, it means that anything tripping these types of systems is going to be looked at suspiciously to say the least. I'm not inherently against such a feature (IRC networks check for proxying for instance), but its clearly detailed in the MOTD of basically every network that does it.

There wasn't a single thing in the FAQ that suggested it, and a Google search against the other site didn't pop something up that dedicated what was being done; just a small note that some proxies were being blocked. Had the stock FAQ file, or documentation, or anything detailed this behaviour, while I might still have thought it wrong, at least I wouldn't have gotten upset about it. I knew that there was proxy scanning code in slashcode, but all the vars in the database were set to off; as I discovered, they're ignored leading me to write a master off switch in the underlying scanning function.

Perhaps in total, this isn't a big deal, but it felt like a slap in the face. I know I have a temper, and I've been working to keep it under wraps (something easier said than done, but nothing worthwhile is ever easy). CmdrTaco himself commented on this on hackernews and I've written a reply to him about it. Slashdot did what they felt was necessary to stop spam on their site, and by 2008, slashcode only really existed for slashdot itself; other slash sites run on their own branches of older code. Right or wrong, such behaviour should be clearly documented, as its not something you expect, and can (and has) caused issues to users and concerns due to lack of communication. Transparency isn't easy, but I have found its the only way to have a truly healthy community. Perhaps you disagree. I'll respond to any comments or criticisms left below.

As the title says. An injury two days ago apparently requires surgery. I will be on hiatus for as long as I need to be.

Mattie_p

EDIT: surgery is complete, she is in recovery right now. She and I are both pretty tired right now. I'm home to care for my son and my wife took over at the hospital. I'll try to keep everyone posted but there is a lot I don't know at this point.

https://github.com/crutchy-/test/blob/master/karma_published.php

bacon+
(only single +/- to differentiate from bender)

~karma bacon

~rainbow pretty text

etc

todo: quotes