Cuộc họp nhà phát triển I2P - 20 tháng 12, 2005

15:20 <jrandom> 0) chào 15:20 <jrandom> 1) Tình trạng mạng 15:20 <jrandom> 2) cập nhật I2PSnark 15:20 <jrandom> 3) Giao diện blog Syndie 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) chào 15:20 * jrandom vẫy tay 15:20 <jrandom> ghi chú trạng thái hàng tuần đã đăng tại http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 15:22 <jrandom> được rồi, nhảy vào 1) Tình trạng mạng 15:22 <jrandom> Tôi không có nhiều điều để bổ sung ngoài những gì trong ghi chú trạng thái. 15:22 <+Complication> Nếu không vì thỉnh thoảng bị OOM (hết bộ nhớ), tôi dám gọi là tốt 15:22 <jrandom> kiểm thử tải trông khá hứa hẹn, cho thấy chúng ta còn nhiều dư địa để cải thiện hiệu năng 15:23 <+Complication> Và tôi đoán các OOM 15:23 <jrandom> hê, OOM liên quan đến i2psnark? hay từ trước đó? 15:23 <+Complication> góp phần làm chập chờn, khi các instance i2p-bt, i2psnark, hoặc i2p-rufus làm... những thứ. 15:24 <zzz> Lý thuyết của tôi là lưu lượng torrent tăng đang phần nào làm giảm độ tin cậy của IRC 15:24 <+Complication> (có lẽ tôi không nên gọi điều kỳ quặc của SAM là OOM, vì tôi chưa xem kỹ, nhưng nó chắc chắn là một trong các yếu tố) 15:24 <jrandom> hừm, tôi không chắc, vì tình trạng irc tương tự như trước các cập nhật snark gần đây 15:25 <+Complication> Băng thông ổn định, đặc biệt các tunnel cũng ổn... chỉ thỉnh thoảng bị crash 15:26 <zzz> Dù sao tôi lạc quan rằng các sửa lỗi build tunnel sắp có trong 0.6.1.8 sẽ cải thiện trải nghiệm IRC của mọi người 15:26 <+Complication> Vì các lý do đã biết, hy vọng chúng sẽ biến mất khi đến lúc :) 15:26 <jrandom> ừ, tôi cũng nghĩ vậy zzz, nên có lẽ chúng ta sẽ phát hành trong ngày mai hoặc sớm sau đó 15:26 <+legion> Ừm irc có thể quá nhạy, có lẽ dùng thứ gì đó như jabber sẽ tốt hơn? 15:26 <zzz> đặc biệt với người dùng máy chậm và/hoặc kết nối chậm 15:27 <jrandom> jabber sẽ không thay đổi tình hình 15:27 <+Complication> Đặc biệt với mức dự phòng tunnel là 2 15:28 <+bar> tôi nói irc là một cái "crap-o-meter" tuyệt hảo để đo thời tiết của mạng 15:28 <+legion> Ừ, gió thổi nhẹ là irc 'toang' ngay 15:28 <+bar> chính xác :) 15:28 <+Complication> Tôi nhận thấy sau bản sửa "shitlisting", "Recent" thường luôn vượt "Known" 15:29 <+Complication> Có phải vì "Known" không gồm các peer bị "shitlist", trong khi "Recent" có? 15:29 <jrandom> ừ, irc là một góc nhìn tốt, vì nó cho thấy biến thiên đáng kể giữa các người dùng khác nhau (ví dụ dreamtheaterfan luôn gặp rắc rối, v.v.) 15:30 <jrandom> ờ, điều đó hợp lý Complication 15:30 <+Complication> (Tôi không chắc có phải vậy không, chỉ đoán thôi) 15:30 <jrandom> (vì các peer bị shitlist bị loại khỏi netDb, nhưng hồ sơ của họ không bị xóa) 15:32 <+Complication> Vậy các chỉ báo có vẻ OK (chỉ muốn hỏi phòng khi không phải vậy) 15:33 <jrandom> được, còn gì về 1) Tình trạng mạng không? 15:33 <jrandom> nếu không, hãy chuyển sang 2) cập nhật I2PSnark 15:33 <tealc_> có những cập nhật kiểu gì? 15:34 <jrandom> xem http://dev.i2p.net/pipermail/i2p/2005-December/001240.html để biết danh sách ngắn gọn ;) 15:34 <jrandom> về cơ bản I2PSnark nay có thể xử lý nhiều torrent cùng lúc trên một I2P destination, có giao diện web, và được tích hợp vào bảng điều khiển router 15:35 <tealc_> tôi đang chạy các bản build CVS mới nhất và i2psnark gây ra nhiều lỗi heap bộ nhớ hay gì đó 15:35 <+Complication> ...và nó cũng xử lý các torrent do Azureus tạo với meta-tag kỳ lạ. 15:35 <+Complication> Mà trước đây nó bị kẹt ở đó. 15:35 <jrandom> à, đúng, vẫn còn vài thứ tôi đang debug ở đó tealc_ 15:35 <jrandom> (như đã đề cập trong ghi chú trạng thái hàng tuần ;) 15:35 <jrandom> à đúng Complication 15:36 <jrandom> ồ, thêm nữa, bên Azureus đã sửa một bug trong tracker (máy chủ theo dõi) của họ vốn khiến I2PSnark không dùng được nó 15:36 <jrandom> (vì vậy những người chạy tracker Azureus trước B16 nên nâng cấp khi thuận tiện nhất) 15:37 <+bar> tôi muốn có khả năng tắt dễ dàng việc i2psnark tự khởi động (cho các tình huống băng thông thấp, v.v.) 15:38 <jrandom> cái đó thêm vào chắc cũng dễ thôi 15:38 <+bar> nghe tuyệt 15:39 <jrandom> được, còn gì về 2) cập nhật I2PSnark không? 15:40 <jrandom> nếu không, chuyển sang 3) Giao diện blog Syndie 15:40 <zzz> giơ hai ngón cái cho i2psnark mới - làm tốt lắm 15:41 <jrandom> cảm ơn, mjw đã làm phần việc khó, khiến snark rất dễ mở rộng 15:41 <jrandom> được, như đã nói trong ghi chú trạng thái, syndie giờ có giao diện blog mới 15:42 <jrandom> Tôi nghĩ nó sẽ mang lại sự cân bằng giữa danh sách trắng và danh sách đen, xử lý các vấn đề spam khác nhau mà người dùng gặp phải 15:43 <jrandom> chúng tôi sẽ phát hành trong bản tới, nên mọi người có thể dùng thử trong một hai ngày nữa 15:43 <+legion> Spam có thực sự sớm trở thành vấn đề lớn không? 15:44 <+Complication> legion: như có người đã vui lòng minh họa, có thể đấy 15:44 <jrandom> không, danh sách đen xử lý tác giả flood, còn danh sách trắng xử lý spammers tạo nhiều tác giả 15:44 <dust> (tính ẩn danh làm bộc lộ điều tệ nhất ở một số người) 15:44 <jrandom> (vậy spamming không phải vấn đề) 15:45 <+Complication> (Dù tôi nghĩ anh chàng đó tái tạo khóa để tránh bị cho vào danh sách đen vĩnh viễn, điều này *có* làm chậm đôi chút.) 15:45 <+Complication> Tuy không chậm nhiều, và tôi hoàn toàn đồng ý danh sách trắng cũng tốt. :) 15:46 <+bar> có lẽ một giải pháp hashcash có thể khả thi về sau, nếu cần 15:46 <jrandom> nếu cần, nhưng tôi không thấy lý do 15:46 <+bar> đồng ý, hiện tại tôi cũng không 15:46 <+Complication> bar: kiểu như "đừng hiển thị trừ khi họ chịu khó crunch vài con số"? 15:47 <+bar> đúng, gì đó theo hướng đó 15:47 <+Complication> Nghe có thể làm được, dù có lẽ không cần. 15:47 <+bar> có lẽ vậy. 15:47 <jrandom> nếu một nhóm spammer flood với vô số tác giả mới liên tục, mọi người vẫn có thể báo cho người khác về tác giả mới bằng cách đăng bookmark và tham chiếu blog trong blog của chính họ 15:47 <+Complication> Hoặc đúng hơn, hy vọng là không cần. 15:48 <+Complication> Có thể nên cân nhắc liệu Syndie có thể chứa được chức năng như vậy không, phòng khi cần. 15:49 <jrandom> ừ, có thể, với các header trong bài blog hoặc trong metainfo của chính blog 15:49 <jrandom> ờ, metadata (chết tiệt bt!) 15:51 <jrandom> được, nếu không còn gì về 3) Syndie, hãy nhảy sang 4) ??? 15:51 <jrandom> ai còn gì muốn nêu trong cuộc họp không? 15:51 <+legion> có, vài chuyện 15:52 <+legion> đầu tiên là clunk 15:52 <jrandom> tuyệt, ừ clunk nghe thú vị 15:52 <+legion> Như tôi đã nói hôm nay trong i2p-chat, tôi đang cố biên dịch nó với Cygwin và/hoặc MinGW. 15:53 <+legion> Tới giờ chỉ client bị hỏng, phần còn lại bao gồm server biên dịch được và có vẻ hoạt động 15:53 <jrandom> hay đó 15:54 <tealc_> i2p có thể trở thành một mớ rối thực sự cho chương trình giám sát vô hạn của George Bush. Hẹn gặp các bạn ở trại tử thần, nhớ mang bài nhé 15:54 <+legion> Đang cố không chỉ truy ra vì sao client hỏng, mà còn sửa nó. Lúc này tôi đang bí. 15:56 <+legion> Điều khác tôi muốn bàn: có thể đưa một tunnel mặc định tới máy chủ jabber của tôi vào bản cập nhật tới không? Chỉ để việc thử jabber dễ hơn cho ai muốn dùng. 15:57 <tethra> 20:34:37 <jrandom> if a set of spammers were flooding with lots of new authors all the time, people could still tell other people about new authors by posting their bookmarks and blog references in their own blog <--- có lẽ điều gì đó theo cách polecat kết hợp độ tin cậy có thể đóng vai trò ở đây? (tức là vừa chặn spammers -vừa- quảng bá tác giả phổ biến.) 15:57 <tethra> </$0.02> 15:58 <+polecat> Đó sẽ là một ví dụ sơ khai cho ý tưởng mạng lưới tin cậy của tôi, với heuristic chuyển giao tin cậy 100%, đúng vậy. 15:58 <jrandom> legion: hừm, thêm một cấu hình ở trạng thái tắt thì khá dễ cho người dùng mới, nhưng điều tôi lưỡng lự là chuyện lọc theo giao thức (và client nào rò rỉ thông tin gì). trải nghiệm của bạn với các client khác nhau thế nào? 15:59 <jrandom> ừ, còn nhiều chỗ để tích hợp các thước đo tin cậy vào syndie 16:01 <+legion> Theo tôi biết thì jeti không rò rỉ, trừ phần filetransfer, vốn đã bị tắt trong thiết lập server của tôi. Có thể phiên bản jeti tiếp theo sẽ sửa. Ngoài ra tôi không rõ các client khác. 16:02 <+legion> Tôi biết chắc group chat là ổn, bất kể client nào; chỉ có liên lạc ngoài group chat mà một số client có thể rò rỉ, dù tôi không chắc. 16:03 <jrandom> hừm, rò rỉ không phải là vấn đề boolean, mà là vấn đề /thông tin nào/ client rò rỉ, chứ không phải có rò rỉ chút thông tin nào hay không 16:04 <+legion> Đúng, dĩ nhiên tôi ám chỉ thông tin quan trọng như địa chỉ IP, dù client tốt nếu có rò rỉ thì cũng chỉ báo là 127.0.0.1 hoặc localhost 16:06 <+legion> Vì vậy tôi khuyên chỉ dùng các client đã biết là không rò rỉ, như jeti. 16:07 <zzz> bạn có thể thêm một cột 'đã xác minh-không rò rỉ' vào bảng client của bạn không? 16:07 <jrandom> sẽ hữu ích nếu bạn viết tài liệu về jeti rò rỉ và không rò rỉ những gì (tương tự như những gì postman đã tổng hợp cho proxy smtp và pop) 16:08 <+legion> Theo nhà phát triển của jeti, nó không rò rỉ thứ gì làm suy giảm tính ẩn danh. Điều đó chắc chắn không nghi ngờ. Tôi cũng đã xem qua mã nguồn và không thấy gì khiến tôi nghĩ khác. 16:09 <jrandom> nhà phát triển nói vậy thì có thể chắc chắn, nhưng nhà phát triển hiểu thế nào về ẩn danh lại là chuyện khác ;) 16:09 <+legion> Ừ zzz tôi có thể thêm một cột như vậy 16:09 <jrandom> Tôi không nghi ngờ khả năng jeti hoạt động đúng, nhưng chúng ta cần biết điều đó có nghĩa là gì 16:10 <zzz> có vẻ việc không rò rỉ chỉ có thể xác minh bằng cách truy vết giao thức 16:10 <zzz> chứ không phải bằng cách xem mã nguồn hay hỏi nhà phát triển 16:12 <jrandom> được, còn ai có gì nữa cho cuộc họp không? 16:12 <+bar> chỉ nhắc đừng quên jbigi cho amd64 16:13 <+bar> (nhưng tôi cá là nó nằm trong danh sách việc cần làm của bạn) 16:13 <jrandom> ừ :) 16:13 <jrandom> (win amd64, tức là linux amd64 đã chạy rồi) 16:13 <jrandom> nhưng, nếu không còn gì nữa... 16:14 * jrandom kết thúc 16:14 <+bar> đúng, win amd64. 16:14 * jrandom *baf* kết thúc cuộc họp