rduke15 writes “You think you know how to parse a domain name for validity? Well, in case you haven’t noticed, things are getting tougher as registrars keep …
IDN에서 사용하려고 하는 Punycode를 언급하고 있는 RFC 3492 [RFC3492]는
특정 encoding의 requirement에 대해 다음과 같은 이유를 들고 있다.
* Efficient encoding: The ratio of basic string length to extended
string length is small. This is important in the context of
domain names because
RFC 1034 [
RFC1034] restricts the length of a
domain label to 63 characters.
기사에서 ‘weird’하다고 표현하고 있는 인코딩의 예는 다음과 같다.
(H) Korean (Hangul syllables):
u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j
psd879ccm6fea98c
Simon P. Chappell writes “Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it’s no …
Life is busy enough without writing your own infrastructure code. With all of the high-quality frameworks available today, it’s no longer necessary to even think about writing low-level code (except as a technical exercise, or to express your inner geek :-) Our problem today, is to review and select the best available framework for our needs.
몇년 전만 해도 ‘자신의 라이브러리를 구축하라’는 조언이 절대적인 진리였지만,
현재는 그렇지않다. 인터넷 환경에 힘입어 product-quality를 가진 framework와 component들이
무료로 배포되고 있다. reusability와 팀 환경을 감안했을 때,
‘자신만의 라이브러리’는 무용지물이 될 수도 있다.
따라서, 현재까지 개발해오던 습성을 어느 정도는 버리기 시작해야할 것이다.
이러한 습성의 변화는 직관적으로 두가지 국면에서 발생할 것이다.
– 자신만의 라이브러리를 구축하기 보다는 좋은 품질의 라이브러리를 찾을 것.
(우리는 이미 많은 시간을 좋은 툴과 라이브러리를 ‘찾는’ 데에 시간을 들이고 있다.)
– 라이브러리를 구축할 때, 자신만의 용도로 만들기 보다는 개발/사용의 공유를 통해 발전시킬 것.
(물론 ‘자신만의 라이브러리’의 필요가 완전히 사라지지는 않는다.)
raptor21 writes “Ace’s hardware has an article with feature list of technologies in Solaris 10 or whatever it is called today. Interesting stuff like DTrace, …
눈에 띄는 feature들..
“Fire Engine” TCP/IP stackA complete re-write of Sun’s TCP/IP stack, with more features from IPv6 and more performance and scalability. Fire Engine will also support TCP/IP Offload Engines (TOEs) – it is expected that Sun’s 8-core Niagara processor will feature this. Without hardware optimisation, the processor demands are quite painful for multiple 1Gbit channels or single 10Gbit Ethernet channels, so expect TOEs to become a common feature of future servers. This article from The Register has good information on Fire Engine.
Gigabit 환경을 위한 중요한 도약인 듯.
Solaris Zones (“Project Kevlar”)A next generation of the software based partitions in Solaris, which aim for high isolation – they can be individually re-booted, dynamically created and faults outside the kernel won’t affect other zones. Future UltraSPARC processors are expected to have (unspecified) hardware features to improve upon this.
소프트웨어의 안정성을 격리하기 위해서 machine을 분리할 필요가 없어지는 것인가?
ZFS (Zettabyte File System)ZFS is a completely new POSIX-compliant Unix file-system that aims to push not only performance, scalability and reliability into the next generation, but also manageability – Sun presented two papers at the Self Manage ’03 conference. The first is about ZFS’s self-tuning abilities and some features that make it simpler to administer in the first place – storage can be very complex to setup and administer, and improving on this is a major goal of ZFS. The second paper is about ZFS’s Existential QoS for Storage, a simpler way of specifying QoS (Quality of Service) requirements for storage. Note: a Zettabyte is 270 bytes, or 1,180,591,620,717,411,303,424 bytes.
paper를 봐야할 겠지만, self-tuning에 QoS라니. 2^70 = (2^10)^7 = (10^3)^7 bytes = (10^3) ^ 4) GB인가…
