freghar

If you use some script to do this update, please include a file (ie. HEAD) with current git commit hash information (like I did for my svn mirror), so people can actually refer to particular commit when reporting bugs. http://www.assembla.com/code/mangos-svn-mirror/subversion/nodes -- see GIT_HEAD

All forks do initially share git objects, thus they take up ~0 additional space when created. Anyway, I actually wrote an email (about a year ago) to github maintainers regarding this issue and the reply was something like "we don't like to delete repos, but excluding them from the network graph is a nice idea" .. well, I guess it was never really implemented. And yes, I did mention those forks are useless ones without even a single push.

Good news - all the mirrors are back online. The issue was most likely in motherboard's SATA interface.

As Lynx3d explained, you need to diff against the base of the ahbot branch. Doing a "git diff branch1 branch2" prints out ALL differences (except entire file additions/removals) between those branches.

I'm sorry for the downtime of all those mirrors + the SD2 git mirror, I have - however - major problems setting up my new machine. First, there was an unnoticed known_hosts error, which caused the update script to fail for the last ~7days before I recognized it. Since all the services were moving to a new machine, I decided to solve this problem once I have all the things moved (it was supposed to happen in ~5 days after move). I managed to set-up the new machine fine, everything went okay, hardware tests as well, then I noticed a strange "silent data corruption" on both hard drives in RAID1. Simply said almost no file could be read twice with the same md5 hash. I'm still investigating it. This said, I'm going back to the old hardware - for a while. The repo updating script should be up-and-running today/tomorrow.

lol ... what's the point? It either works or errors down, no need for that kind of magic.

Then go on, mister.

Sure it is! You don't need to manually assign an IRQ to it in BIOS

I agree the only possible documentation here is doxygen (including warnings what the function shouldn't be used to, point to a better one for that usage, ...). Anything else is just too unreal here ..

Careful about defaults - mysql doesn't need this specific line to "use the defaults" - it can even cause slowdowns/crashes whenever the defaults change (and you forget to update the line).

That's true. ScriptDev2 is a C++ scripting library, LUA could be *just* another scripting library, mangos can run with any scripting library you create, not just with SD2. The (most likely) correct way of LUA implementation would be to write a small translational C/C++ library for mangos and implement all LUA processing above it, using this C/C++ piece of code as an abstract layer. Inserting "run my all-in-LUA script library" code into mangos itself is not that clean.

That should be - in fact- blizzlike: (a config option would be nice)

Well the original post was based more on functionality than theory. It's true that "standard" RAID1 is just dumb mirror, but that's only theory, nothing more. You can connect two drives to some very simple hub and duplicate every single I/O voltage change the motherboard sends (and vice versa) - in which case you're gonna have even slower access. My "version" of RAID1 is really RAID1 - the data are stored as RAID1 specifies, there are no stripes (unlike RAID10). If you mount the mirrored partition via mount(8), it'll behave as you would expect it to. Wikipedia says -- which doesn't conflict with anything the FreeBSD driver does. It simply uses smart I/O scheduling to read from more drives simultaneously. Furthermore I can't find any RFC on RAID / RAID1, is there any? Where do you take this "standard" from? Even http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1_performance actually DOES mention the performance boost.

A nice example of what not-so-well documented code can cause .. is trinity project. I've heard rumors about duplicated functions doing the same thing, misusing some of the subsystems, crashes and "hacks", just "because they can't understand the code". A good documentation would help to drastically reduce such things. However there's no documentation how *something* should be implemented, no publicly-available policy for changing files and adding "hacks", both projects do it the way they like it (because nobody knows how "the other side" does it) - which results in great incompatibilities between both projects. This might be intentional, but I believe it isn't.

I knew there will be always trolls quoting wikipedia. Maaan, think a bit! World isn't that easy as RAID1 = slow and RAID0 = double performance. see http://www.tomshardware.co.uk/forum/250390-14-does-raid-increase-read-speed - there's also a guy quoting wikipedia + replies to his post I personally own a FreeBSD storage server (well, not "I", but the company I work for) and can confirm the "RAID1 is faster for read than RAID0". edit: And about RAID 4/5/6 - it's true the read is stripped, so it might achieve read performance similar to RAID0, but write performance is a lot slower - thanks to parity recalculations.

You can disassemble the binary and do your work in ASM. There's no other easy way.

Do you really believe it's _THAT_ way slower? Have you done any C++ vs LUA vs Python benchmarks? I assume you know that LUA doesn't need to compile the code each time it's executed. I know this kind of topic is here somewhat often, but I'd really like to see some benchmarks if anyone has done any.

Just a note about disk I/O - RAID4/5/6 isn't about performance, it's about space. For read performance, RAID1 (or any combination 1+0 / 0+1) wins. RAID1 can be theoretically (and is) even faster than RAID0 - the reads aren't limited to some stripes, driver can stripe the reading dynamically (ie. it can read last 1KB of some file from the same drive, without the need of seeking and reading it from the second one). It can even reach ~70% of RAID0 write performance - just by writing to both drives independently and syncing data+metadata during idle states. None of this is currently in the Linux MD driver (it was, I dunno why they disabled it), it can't read from several RAID1 drives in parallel. On the other side, FreeBSD can - it has even several policies for that. If you need a LOT of drives, you can go for RAID 0+1 with HDDs in couples of 2 drives (forming RAID1). So the setup would be simply RAID0 spanning over <insert value here> RAID1 arrays. When one of the drives fail, simply replace it (or use a spare one) and resync just the small piece. And about network - if one Gbit connection isn't enough, you can always use two or more cards on each machine and do some form of load balancing (there are IIRC kernel patches for it as well). You, of course, need to use several DB connections to benefit from that - I don't know if mangos supports that.

You're right, I forgot about that. Believe it or not, most of those people actually prefer to "have dozens of patch files", just because it's easier for their brains.

Indeed he can. He can't, however, use classic .gitignore file (because it's tracked, so he would need to commit it anyway). The solution is to use .git/ignore file in the repo dir itself. At least AFAIK.

Indeed it does affect the client (to some extent).

Yeah, you would most likely need to change the DBC files, probably both on client and server. However I suggest doing no changes to DBC.

git reset --hard before the pull

Indeed, I took a short look at files in src/game/ and they have their copyright header intact.

AFAIK nested SELECT and a JOIN is something a bit different - looks like the nested SELECT is done each time for each column selected via FROM - at least from the time estimate. And the JOIN performance issue isn't as obvious as it might look like. Today's storage engines are more optimized for using JOINs, they cache references. Think about the fragmentation - rows aren't stored on the disk as they appear in your DB browser, reading one superlong row (which is done each time, even if you SELECT only one column) from (possibly) many fragments and wasting many pages of cache can be slower than using one or two JOINs, especially on tables using proper indexes. Moreover, the fragmentation occur both on file level and on DB level (ie. longtext dynamic size columns). See http://getmangos.eu/wiki/Development_ideas - database section ... doing too many JOINs isn't good, keeping all in one table is not good as well.