The purpose of using a specific name behind a project is so that people identify with that project’s identity in an effective way.

Recently there has been some developments involving SorceryNet making a fork of the charybdis IRC server implementation.  This is fine, of course, the license allows it, and they renamed it to SorIRCd as would be the standard procedure in matters like these, which is fine.

However, now they wish to add back the Charybdis string in the version output.  There are ways that this can be done where it does not infringe on our rights as holder of the charybdis name.  But no…

Here is how they intend to set their version string:

SorIRCd-3.0.0(3.0.0-3-ga71dc30)-Charybdis3.2

In and of itself, this is mostly OK, but it raises some questions about Charybdis: What is charybdis? Is it a patchset to SorIRCd? The fact that the second question is raised makes it an obvious infringement.

This leaves me somewhat concerned as there is an obvious infringement of the charybdis name going on, and it may result in actual confusion.  Since the coder is an Anope developer, maybe I ought to just tack on -Anope2.0 to the end of Atheme’s version string and see what they say about it.  Maybe they will get my point then…

Greetings!  I’m the guy who made bitcoin difficulty shoot up from 45.0 to 181.5 for a while.  My apologies for that by the way; I was not expecting it to rise that high.

Many people on the bitcoin forums seem to have watched the process, some even drawing up conspiracy theories about how I am related to some banker who wants to enforce the system.  Others implied that I used the resources of my employer to do this.  I would like to say that the forum thread is absolutely hilarious.

The purpose was to demonstrate in two ways that the Bitcoin system can be attacked.  This was demonstrated with higher than expected success in both areas:

• cause an effective denial of service through taking control of the proof-of-work difficulty by ensuring that there was an artificial inflation in available compute resources;
• cause speculation in the bitcoin economy, especially the exchanges (e.g. a ‘bank rush’);

The first aspect has been partially hedged against in the Bitcoin 0.3.2 client.  This is a good thing, as it should (at least according to my own review of the change) ensure that people who have access to large amounts of compute resources cannot effectively game the proof-of-work difficulty level.  This ensures that people who do not have the same level of access as I do have a fair chance at solving a block and getting coins.

The second one is harder, and it is a problem typically seen with “dark” currencies.  This problem is also seen in real life: look at our own stock exchanges and currency rate.  There is evidence of speculation in the USD->EUR market, for example.  Speculation is going to be a hard problem to deal with when there is ultimately no regulation or enforcement from an oversight party.  But, this is the nature of bitcoin, so I don’t expect that ‘bug’ to be corrected.  The ‘bug’ could also be considered a ‘feature’, as in theory, the market can ignore the speculators.  The question is: will the market ignore the speculators.

I think bitcoin has a lot of potential in the microcurrency area, especially for MMOs.  Consider for example, Second Life.  You buy stuff in Second Life (clothing, objects, property, etcetera).  Now consider if we decentralized that environment… made it where anyone could run the server software (this is already possible with OpenSim).  Now we need a viable form of commerce that is not biased to any particular party. This is where BitCoin shines.  Because BitCoin is truly independent, it allows for the possibility for inter-grid commerce.

I do not believe that bitcoin will ever replace actual money.  Some people would like for it to replace actual money, but frankly I am not one of those people.  I do however, see places where BitCoin is a practical solution to a problem that exists.  BitCoin could really improve and innovate the way micropayments work in games.  Is it the only solution?  No.  MochiMedia has MochiCoins.  But the problem here is: MochiCoins are backed by a single individual party, MochiMedia.  Therefore, MochiCoins are worth whatever MochiMedia says they are worth.  With BitCoin, a game vendor can take the BTC revenue they get from their games and sell it on the market to yield the highest possible profit.

Linden Lab implemented it’s own microcurrency, called Linden Dollars, or L$ for short.  One way that speculation is avoided is through manipulating the value of the currency.  Unfortunately, even with such manipulation, people still speculate in it.  People speculate in it, because they have deduced the pattern at which their L$ is valued or devalued, so they can buy when it is at it’s lowest price and sell it when it’s the highest.  In order to ensure the stability of BTC value as a currency, a solution to the speculation problem has to be found early.

If these problems can be solved, I think BTC has a very good chance at being used in some form as a microcurrency in games.  In fact, this is what I am actually hedging on.  Unfortunately, I can’t yet disclose what I intend to do with the coins I have generated, but I am sure you can probably figure out parts of it based on what I have written thus far.

I am not responsible if you mess your phone up.  Seriously.

The following requires that you root your phone.  That is not covered here, however for the Droid you can update your 2.0.1 phone with this update.zip.

Connect to your phone with adb shell, then:

$ su
# mount -o remount,rw /system
# echo 'kernel.sched_latency_ns = 600000' >> /etc/sysctl.conf
# echo 'kernel.sched_min_granularity_ns = 400000' >> /etc/sysctl.conf
# echo 'kernel.sched_features = 24188' >> /etc/sysctl.conf
# mount -o remount,ro /system
# sysctl -p
kernel.sched_latency_ns = 600000
kernel.sched_min_granularity_ns = 400000
kernel.sched_features = 24188
# exit
$ exit

Now your phone will behave a lot better.  To explain what those settings do:

Changing sched_features to 24188 disables some annoying CFS features (GENTLE_FAIR_SLEEPERS and NORMALIZE_SLEEPERS) that are stupid even on the desktop.  The other two crank the timeslice length down to 0.6ms/0.4ms.

What about BFS you say? Well BFS does not appear to perform very well on Android, and Android’s legitimate use of cgroups does not work on BFS.  However, the settings that the sysctls above change make CFS behave a lot more like BFS.

At any rate, after making these changes, my Motorola Milestone has no problems keeping up with another android phone I have (the HTC Incredible).

What does this mean?

This means that all the hype about JIT in Android 2.2 being the biggest possible source of performance improvement is a load of crap.  JIT will improve CPU-bound tasks, but it will not improve the interactivity of the underlying OS, which is what people are really complaining about.

This also proves that overclocking your phone is stupid and dangerous.  Just do the above and you won’t be damaging your phone’s hardware.  You will also get a much more noticeable performance boost out of this than you would out of overclocking your phone.

I mean, my Milestone is actually usable now.  It’s 550mhz and it has absolutely no problems keeping up with the Incredible’s 1000mhz CPU.  Just think about that.  The HTC’s CPU is being put to waste due to the way that the scheduler allocates timeslices.  If you disable the GENTLE_FAIR_SLEEPERS option, CFS becomes a very good scheduler for android, as it allows for sub-1ms timeslice deadlines.

Update: Disabling NORMALIZE_SLEEPERS on Android 1.6/2.0/2.1 is a good idea.

A picture is worth a thousand words. GTKUI for Audacious 2.4 has made significant progress due to community contribution and also due to the fact that we have made enhancement of GTKUI a 2.4 release goal.  This picture shows the new infobar, as well as integrated visualization support.

Earlier this morning, I discovered that under it’s new administration, DroneBL has initiated a block of all Kalamazoo AT&T users without any public warning or notification.  Obviously this is unacceptable, and on StaticBox we have discontinued usage of the DroneBL service as a result.

We suggest that other networks do the same and demonstrate to the new administration that stealth blocks is entirely unacceptable and leaves the provided data untrustworthy.  The new DroneBL administrators have been notified that they should find new hosting arrangements, as I still continue to provide their infrastructure.

You can read more about EFnet RBL on their own site, they include a BOPM example configuration section.

Update: The tainted data has been purged, so I guess we’re OK now.

Don’t you think so too when you watch this video?  It just seems like “get in my van, I have ice cream”.

Ah, I get it.  My website needs more warez on it to be reputable.  And this people, is why Web of Trust models don’t equate to website trust.  Here’s a tip, it has to do with internet vigilantes being morons.

Previously…

Holy shit, they actually shipped the damned thing.

Also, has anyone else noticed that CentOS is still on 5.4, while RHEL 5.5 has been out for a month now?  Is that project dead or something?