हाय सब लोग, मंगलवार फिर से आ गया

  • Index
  1. नेटवर्क स्थिति और 0.6.1.18 2) baz 3) ???
    1. Net status and 0.6.1.18

परीक्षण और सूक्ष्म समायोजन का एक और सप्ताह बिताने के बाद, हमने आज दोपहर पहले एक नया रिलीज़ जारी किया, जो हमें एक अधिक स्थिर वातावरण में ले आएगा, जहाँ से हम आगे सुधार कर सकें। हालाँकि, जब तक यह व्यापक रूप से परिनियोजित नहीं हो जाता, तब तक हमें शायद ज्यादा प्रभाव दिखाई नहीं देगा, इसलिए यह देखने के लिए कि यह कैसा चलता है, हमें कुछ दिन इंतज़ार करना पड़ सकता है, लेकिन मापन निश्चित रूप से जारी रहेंगे।

हाल ही में zzz ने नवीनतम बिल्ड्स और रिलीज़ के बारे में जिन पहलुओं का ज़िक्र किया, उनमें से एक यह था कि अब backup tunnels की संख्या बढ़ाना, यदि इसे समानांतर tunnels की संख्या घटाते हुए किया जाए, तो काफ़ी प्रभाव डाल सकता है। हम तब तक नए leases नहीं बनाते जब तक हमारे पास पर्याप्त संख्या में लाइव tunnels नहीं होते, इसलिए किसी लाइव tunnel के विफल होने पर backup tunnels को तुरंत तैनात किया जा सकता है, जिससे किसी क्लाइंट के सक्रिय lease के बिना रहने की आवृत्ति कम हो जाती है। हालांकि यह केवल लक्षण पर एक छोटा-सा समायोजन है, और नवीनतम रिलीज़ मूल कारण को संबोधित करने में मदद करनी चाहिए।

    1. baz

“baz”, वह नई मशीन जो bar ने दान की थी, आखिरकार आ गई है, एक amd64 turion लैपटॉप (बूट डिस्क पर winxp के साथ, और बाहरी ड्राइव्स के जरिए कुछ और OS भी लगाने की योजना है)। पिछले कुछ दिनों से मैं इसे भी परख रहा हूँ, इस पर कुछ डिप्लॉयमेंट आइडियाज़ टेस्ट करने की कोशिश कर रहा हूँ। एक समस्या जिसमें मैं फँस रहा हूँ, वह है windows पर gcj को चलाना। और ख़ास तौर पर, एक आधुनिक gnu/classpath के साथ gcj। जो सुनने में आ रहा है, वह काफ़ी नकारात्मक है - इसे या तो mingw में नैटिव रूप से बनाया जा सकता है या linux से क्रॉस-कम्पाइल किया जा सकता है, लेकिन इसमें ऐसी समस्याएँ हैं, जैसे कि जब भी कोई exception किसी dll boundary को पार करता है तो segfault (सेगमेंटेशन फॉल्ट) हो जाना। तो, उदाहरण के लिए, अगर java.io.File (जो libgcj.dll में स्थित है) कोई exception थ्रो करता है, और उसे net.i2p.* में किसी चीज़ द्वारा (जो libi2p.dll या i2p.exe में स्थित है) कैच किया जाता है, poof, बस, ऐप क्रैश हो जाता है।

हाँ, तो हालात कुछ खास अच्छे नहीं दिख रहे। अगर कोई win32 विकास में तुरंत शामिल होकर मदद कर सके तो gcj समुदाय की काफी रुचि होगी, लेकिन व्यावहारिक समर्थन निकट भविष्य में दिखाई नहीं देता। तो, लगता है कि हमें Windows पर sun JVM का उपयोग जारी रखने की योजना बनानी होगी, जबकि *nix पर gcj/kaffe/sun/ibm/etc का समर्थन करेंगे। मेरा मानना है कि यह इतना भी बुरा नहीं है, क्योंकि JVMs की पैकेजिंग और वितरण की समस्याएँ तो *nix उपयोगकर्ताओं को ही होती हैं।

    1. ???

ठीक है, मैं मीटिंग के लिए पहले ही देर से हूँ, तो मुझे इसे यहीं समेटकर irc विंडो पर टैब कर लेना चाहिए, मेरा खयाल है… कुछ ही देर में मिलते हैं ;)

=jr