http://www.kendraschaefer.com/2012/06/chinese-standard-web-fonts-the-ultimate-guide-to-css-font-family-declarations-for-web-design-in-simplified-chinese/

http://preview.tinyurl.com/kctg2k9 Warning, link contains profanity. Here is an excerpt:

There’s a moral to this story boys and girls. Inform, teach, explore. Don’t gain the elitest attitude that only the few computer guru’s deserve the k-nowledge. That will get society nowhere. If something is not done to show Americans the light, then it will all go to hell. All computers will turn into entertainment systems. Inventiveness will be left to the evil, who’s only goal is to get money from you. If you are in disbelief, just turn on your T.V. Didn’t MTV start out as a new media form? Now-a-days, theres about .1% M in MTV, and about 99% ads and manipulation. Lets give a wakeup call to the world. Lets make it big and loud. NOW, not tomorrow.

https://twitter.com/IronMountain/status/431123025845420032 Another 9 casualties have been tacked onto the 10,000 to 20,000 miners that die each year from accidents. These were firemen. Perhaps they may have took a dozen lives off the annual casualty list in their courageous acts.

Before you start: it is probably a better idea to run headless operating systems because of the immense overhead compounded by software emulation since OVZ doesn’t support hardware virtualization (qemu-kvm). Watch the CPU usage, and make sure you have adequate RAM. Successfully tested with FreeBSD-10.0-RELEASE i386 running inside Ubuntu 13.10 i686.

1
2

# apt-get install qemu-system
$ qemu-img create -f qcow2 freebsd.qcow2 5G

Formatted capacity will be 4.6GB with FreeBSD’s default UFS2 filesystem. a minimal install without the ports collection takes approximately 550MB.

1

$ qemu -localtime -cdrom FreeBSD-10.0-RELEASE-i386-dvd1.iso -m 256 -boot d freebsd.qcow2 -net nic,vlan=0,model=rtl8139 -net user -vnc :3

256MB of memory is more than enough to get by with for the install. -k may be necessary if you are planning to select an alternative keyboard layout during the install. Connect to :5903 via VNC to control it. No authentication is set up, so it might pose a security risk. During the install, install sshd and ntpd too. After you’re done installing,

1

$ qemu -hda freebsd.qcow2 -boot c -m 256 -localtime -net nic,vlan=0,model=rtl8139 -net user -vnc :3

, edit /etc/ssh/sshd_config and set PermitRootLogin to Yes, and do a service sshd restart . VNC is quite clunky to use on a daily basis, not to mention that all data is transferred unencrypted. It would be trivial to use iptables to deny external access and access it via an ssh tunnel only, though. For general use:

1

$ qemu -hda freebsd.qcow2 -boot c -m 256 -localtime -net nic,vlan=0,model=rtl8139 -net user,mynet0,hostfwd=tcp::9527-:22

This forwards tcp port 22 on the guest to port 9527 on all interfaces of the host. Unfortunately, I haven’t found a way to forward ports while the guest is running. Here is an idea of how resource-intensive the guest is: [caption id=”attachment_182” align=”alignnone” width=”150”] Screenshot of htop on a completely idle FreeBSD guest in QEMU[/caption] This translates to [caption id=”attachment_183” align=”alignnone” width=”150”] htop screenshot of CPU usage on the host with an “idle” freeBSD guest[/caption] Something doesn’t seem right. htop on FreeBSD that I just installed from pkg has abnormal CPU usage. I suspect this is due to the Linux compatibility layer. Let’s take another shot of htop on the host with nothing running on the guest besides system daemons like syslogd and cron: At this point, strangely,

1
2

# uptime
 5:33PM  up  3:49, 2 users, load averages: 0.48, 0.37, 0.29

The guest CPU seems to be trying to squeeze blood from a turnip. I have no clue why the apparent load is so high, yet top inside the guest bizarrely shows 99.6% idle. Perhaps I will experiment with the qemu -smp option since my VPS has 3 cores assigned to it to see if the guest will be able to use additional cores effectively…

http://programmers.stackexchange.com/questions/60544/why-do-game-developers-prefer-windows tl;dr OpenGL had many functions like multitexturing, shaders, hardware T&L support for quite a long time…. with vendor-specific extensions. MS had a lot of time to mess up and learn, and it didn’t help that there were so many complete rewrites of OpenGL by so many different vendors before the ARB came in and provided their half-hearted fixes. Fast forward to the launch of Vista; MS slipped up again by not providing D3D10 support on XP; and Vista was, well, not the best OS of its time. D3D10 hardware runs D3D9 like a walk in the park, and game developers still provide DX9 compatibility (a year later and Crysis still supports DX9.) OpenGL got their stuff together too late with the release of OpenGL 3.0 with GLSL, and Win7+DX11 is taking everyone by storm. New cards like the HD 5850 are nearly twice as fast as the previous ATI RV770 cards, and OpenGL goes back to picking up the mess made after their mad race.

https://www.mtgox.com/press_release_20140210.html https://en.bitcoin.it/wiki/Transaction_Malleability

This page was last modified on 21 January 2013, at 02:49.

From the #bitcoin channel on Freenode, at UTC +8 time:

[19:15:21] <@gmaxwell> Plarkplark: the issue is https://en.bitcoin.it/wiki/Transaction_Malleability (known since at least 2011)

Funny how they didn’t panic earlier, when Bitcoin was on cloud 9. Meanwhile in China, where the end of Chinese New Year is theorized to be contributing to the chaos: The rollercoaster isn’t nearly as severe. And meanwhile in the #unobtanium altcoin channel…

[19:06:55] well these unos are worth jack shit now
[19:07:17] fucking mt gox
[19:07:18] btc will be back to 900 before you know it
[19:07:26] releasing the news like that
[19:07:49] did i miss something on uno?
[19:07:51] they probably had agents in place to get that 102 buy
[19:08:08] ahahahahahahah
[19:08:09] fuck
[19:08:16] 546 USD
[19:08:16] how much btc was the 102 sell?
[19:08:20] wtf is going on
[19:08:30] end of chinese new year
[19:08:34] they want out
[19:08:47] yeah. crypto is pretty fucked right about now. :(
[19:08:57] 4k i think jawa
[19:09:13] 4k btc or 4k usd of btc?
[19:09:18] is this all bc of gox?
[19:09:23] 4k usd i think
[19:09:34] nm, just read up

EDIT: Since MTGox is in damage control mode; here’s what it had to say:

Dear MtGox Customers and Bitcoiners,
As you are aware, the MtGox team has been working hard to address an issue with the way that bitcoin withdrawals are processed. By “bitcoin withdrawal” we are referring to transactions from a MtGox bitcoin wallet to an external bitcoin address. Bitcoin transactions to any MtGox bitcoin address, and currency withdrawals (Yen, Euro, etc) are not affected by this issue.

The problem we have identified is not limited to MtGox, and affects all transactions where Bitcoins are being sent to a third party. We believe that the changes required for addressing this issue will be positive over the long term for the whole community. As a result we took the necessary action of suspending bitcoin withdrawals until this technical issue has been resolved.

Addressing Transaction Malleability
MtGox has detected unusual activity on its Bitcoin wallets and performed investigations during the past weeks. This confirmed the presence of transactions which need to be examined more closely.

Non-technical Explanation:
A bug in the bitcoin software makes it possible for someone to use the Bitcoin network to alter transaction details to make it seem like a sending of bitcoins to a bitcoin wallet did not occur when in fact it did occur. Since the transaction appears as if it has not proceeded correctly, the bitcoins may be resent. MtGox is working with the Bitcoin core development team and others to mitigate this issue.

Technical Explanation:
Bitcoin transactions are subject to a design issue that has been largely ignored, while known to at least a part of the Bitcoin core developers and mentioned on the BitcoinTalk forums. This defect, known as “transaction malleability” makes it possible for a third party to alter the hash of any freshly issued transaction without invalidating the signature, hence resulting in a similar transaction under a different hash. Of course only one of the two transactions can be validated. However, if the party who altered the transaction is fast enough, for example with a direct connection to different mining pools, or has even a small amount of mining power, it can easily cause the transaction hash alteration to be committed to the blockchain.

The bitcoin api “sendtoaddress” broadly used to send bitcoins to a given bitcoin address will return a transaction hash as a way to track the transaction’s insertion in the blockchain.

Most wallet and exchange services will keep a record of this said hash in order to be able to respond to users should they inquire about their transaction. It is likely that these services will assume the transaction was not sent if it doesn’t appear in the blockchain with the original hash and have currently no means to recognize the alternative transactions as theirs in an efficient way.

This means that an individual could request bitcoins from an exchange or wallet service, alter the resulting transaction’s hash before inclusion in the blockchain, then contact the issuing service while claiming the transaction did not proceed. If the alteration fails, the user can simply send the bitcoins back and try again until successful.

We believe this can be addressed by using a different hash for transaction tracking purposes. While the network will continue to use the current hash for the purpose of inclusion in each block’s Merkle Tree, the new hash’s purpose will be to track a given transaction and can be computed and indexed by hashing the exact signed string via SHA256 (in the same way transactions are currently hashed).
This new transaction hash will allow signing parties to keep track of any transaction they have signed and can easily be computed, even for past transactions.

We have discussed this solution with the Bitcoin core developers and will allow Bitcoin withdrawals again once it has been approved and standardized.

In the meantime, exchanges and wallet services - and any service sending coins directly to third parties - should be extremely careful with anyone claiming their transaction did not go through.
Note that this will also affect any other crypto-currency using the same transaction scheme as Bitcoin.

Conclusion
To put things in perspective, it’s important to remember that Bitcoin is a very new technology and still very much in its early stages. What MtGox and the Bitcoin community have experienced in the past year has been an incredible and exciting challenge, and there is still much to do to further improve.
MtGox will resume bitcoin withdrawals to outside wallets once the issue outlined above has been properly addressed in a manner that will best serve our customers.
More information on the status of this issue will be released as soon as possible.
We thank you for taking the time to read this, and especially for your patience.
Best Regards,
MtGox Team

2900 17/9/2015 @ 12:10pm

• Welcome! Thank you for choosing DiGi. This line is now activated. You can now enjoy FREE Internet for 2 days up to 150MB/per day. You will receive sms soon.

2900 17/9/2015 @ 12:10pm

• Surf for FREE! We have rewarded you FREE internet of 150MB valid till 11.59pm today. For usage above 150MB, charges apply according to your internet plan

2900 18/9/2015 @ 1:13am

• Surf for FREE! We have rewarded you FREE internet of 150MB valid till 11.59pm today. For usage above 150MB, charges apply according to your internet plan

2900 18/9/2015 @ 2:04pm

• Reload RM30.00 is successful. Your balance RM35.34 expires on 22/22/2222.

DiGi 29/8/2015 @ 10:21am

• Post FB updates,chat with friends online and watch videos on Youtube! All you need is a RM3@150MB internet plan to make it happen. Dial *116# to subscribe.

DiGi 29/8/2015 @ 10:21am

• Dial *128# to access info for FREE. Check account info, reload, DiGi Rewards, phone settings & grab freebies such as the Star News Alerts, Gmail sms and more!

DiGi 29/8/2015 @ 10:21am

• Your internet usage from today onwards will be charged based on your internet plan.Subscribe to an internet plan at *116# for more savings

DiGi 30/8/2015 @ 10:23am

• Need internet? Surf all you want from just as low as RM1/hour with Opera Mini now! Click http://m.opera.com to get started

DiGi 30/8/2015 @ 10:23am

• Post FB updates,chat with friends online and watch videos on Youtube! All you need is a RM3@150MB internet plan to make it happen. Dial *116# to subscribe.

DiGi 2/9/2015 @ 10:17am

• Best BDay Bonus! Stay min 3mths & get 50% more Talktime when u reload min rm30 (3days before,on & after ur B’day) Maax bonus RM250, 30 days validity. T&Cs apply

DiGi 3/9/2015 @ 10:17am

• For easy access to your accountn info & latest promotions, log on to DiGi Online Customer Service (OCS) at www.digi.com.my/ocs or call 0162211800 for more info.

DiGi 8/9/2015 @ 12:59pm

• Psst..Don’t forget to call home while ur away in China. Only for DiGi customers: dial *111* +6# to enjoy a special rate of RM3.00/min

DiGi 8/9/2015 @ 12:59pm

• Have fun on your travels! If you ever need some help from home, don’t hesitate to call the Malaysian Embassy/High Commission at +861065322531.

DiGi 8/9/2015 @ 12:59pm

• Welcome to new DiGi Best Prepaid! Enjoy great value for short calls to all local networks. Only 6sen for first 10 secs, then 20sen for next 2mins. T&Cs apply

DiGi 8/9/2015 @ 12:59pm

• Dial *128# to access info for FREE. Check account info, reload, DiGi Rewards, phone settings & grab freebies such as the Star News Alerts, Gmail sms and more!

DiGi 8/9/2015 @ 12:59pm

• Receive incoming calls and SMS for 75 days even though your validity has expired.T&Cs apply

http://etherealmind.com/allocating-64-wasteful-ipv6-not/ http://tools.ietf.org/html/rfc6177 RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Subsequently, the Regional Internet Registries (RIRs) developed and adopted IPv6 address assignment and allocation policies consistent with the recommendations of RFC 3177 [RIR-IPV6]. In 2005, the RIRs began discussing IPv6 address assignment policy again. Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised the end site assignment policy to encourage the assignment of smaller (i.e., /56) blocks to end sites. This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices.

While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future.

http://keepingitclassless.net/2013/02/assigning-ipv6-prefixes-for-customer/ IPv6 was designed with networks in mind. We have to think in terms of prefixes, instead of individual IP addresses. A /64 is the “base unit”, 1 network. http://www.ripe.net/internet-coordination/press-centre/understanding-ip-addressing

With a /56, we may have 4.7 sextillion addresses, but only a mere 256 networks, if this /64 mentality is to be held true. 256 is not a lot, folks, not for small to medium customers, and not nearly enough for large customers, and service providers, such as cloud providers.

http://lowendtalk.com/discussion/4466/lightweight-socks5-proxy

1
2
3
4
5
6
7
8
9

$ file /usr/local/bin/ssocksd
/usr/local/bin/ssocksd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, stripped
$ du -h /usr/local/bin/ssocksd
36K     /usr/local/bin/ssocksd
# pgrep ssocksd
24904
# pmap 24904
.......
 total            15104K

ssocksd takes the cake for being the lightest. 15MB RAM (shared with some other libraries) on x86_64 system, single process, no forks. The only caveat is that very little browsers support its antiquated RFC1929 simple socks auth.

https://wido.me/sunteya/setup-a-socks-proxy-server-pass-by-secure-firewall/ http://www.bock.nu/blog/secure-firewall-bypass-danted-stunnel SSH Tunneling is TCP over TCP over a single connection. Rather unreliable. Socks can handle multiple connections in a non-blocking fashion. Also, to give you security on par with SSH, make sure to use AES256 somewhere in your cipher chain;

1
2
3
4
5
6
7
8

transfusion@shell:~$ openssl ciphers -v -tls1 | grep 'AES(256)'
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256

Alternatively, if you’re not sure what to use ,

1
2

options = NO_SSLv2
ciphers = HIGH:MEDIUM

in your stunnel.conf should suffice.