MHST 2014 – vẫn lối mòn cũ

Nhân sự kiện cuộc thi MHST 2014 khép lại và các giải được công bố chính thức, xin được có vài lời nhận xét với hy vọng BTC sẽ lắng nghe, điều chỉnh và hoàn thiện qui chế cũng như cách thức tổ chức để có được những mùa thi hiệu quả, đúng với mục tiêu chung đặt ra ban đầu, đáp ứng mong đợi của cộng đồng xã hội.

Điểm qua cả 5 dự án lọt vào chung khảo, có thể dễ dàng nhận thấy những lỗi sơ đẳng đối với 1 dự án muốn được gọi là PMTDNM:

  • Các vấn đề về giấy phép phát hành như: không thông báo giấy phép phát hành, không kèm theo bản sao toàn văn giấy phép…
  • Vấn đề về tổ thức cộng đồng (dù là sơ khai): không thấy các dự án tổ chức kênh liên lạc tối thiểu (hoặc ít nhất là không thấy thông báo công khai trên kho mã nguồn chính).
    Không rõ các dự án này giao tiếp công khai với các thành viên trong cộng đồng cũng như end-user như thế nào?
  • Vấn đề về phát hành: 4/5 dự án chưa thấy phát hành phiên bản nào?! (sử dụng tagged trên git)
    Không lẽ BGK chấm trên phiên bản zero?
  • … và còn nhiều nữa nếu đem xem xét kỹ & chấm điểm PoF cẩn thận.

Trong ba mặt cơ bản bắt buộc của một dự án PMTDNM (theo thông lệ quốc tế): i. mã nguồn sẵn sàng và có thể tải về trên Internet, ii. phát hành theo giấy phép được OSI approved (căn cứ theo giấy phép được thông báo trên kho mã nguồn) và iii. tổ chức cộng đồng (dù chỉ sơ khai, đủ thể hiện mong muốn thực hiện tổ chức), các dự án trên mới chỉ đạt được một. Nếu xem xét kỹ các tiêu chí và tổ chức chấm điểm PoF, nhiều vấn đề khác sẽ xuất hiện và đòi hỏi dự án cần được hoàn thiện để có thể chính thức được cộng đồng nhìn nhận là một PMTDNM.

Có thể thấy, những nền tảng nguyên lý cơ bản của nhất của mô hình phát triển PMTDNM đều không được quan tâm đầy đủ và trên thực tế bị break hoàn toàn. Ở đây, lỗi xuất phát từ phía đội phát triển, là các bạn SV. Tuy nhiên, nguyên nhân sâu xa phải kể đến sự thiếu kinh nghiệm và/hoặc sâu sát của mentors và đặc biệt là BGK cũng như BTC.

Chúng ta đang từng bước hoàn thiện mình, nhưng những vẫn đề cơ bản mang tính nguyên lý cần phải được tuân thủ sớm từ đầu. Việc một cuộc thi “SV viết PMNM” như MHST, được tổ chức bởi một tổ chức mang tính đại diện cho cộng đồng PMTDNM VN như VFOSSA lại không lấy tiêu chí phát triển đúng mô hình PMTDNM lên hàng đầu có thể coi là một bước “cải lùi”, khiến cho những nỗ lực khuyến khích tham gia đóng góp phát triển PMTDNM trong toàn thể cộng đồng, đặc biệt là giới trẻ, các bạn SV, có nguy cơ bị ảnh hưởng ít nhiều.

Kiến nghị chung: đưa vào tiêu chí một dự án tham gia MHST bắt buộc phải được phát triển theo mô hình PMTDNM (nếu không, sẽ buộc phải loại bỏ tại thời điểm chấm giải).

P.S. bài viết thể hiện quan điểm cá nhân của tác giả, không phải quan điểm chính thức của VFOSSA cũng như bất cứ tổ chức, cá nhân nào khác.

13 đặc điểm của một nhân viên cần sa thải ngay lập tức

Đuổi việc nhân viên không phải lúc nào cũng là quyết định dễ dàng với các nhà quản lý. Thế nhưng, với một nhân viên có những đặc điểm dưới đây, việc sa thải là thật sự cần thiết.

1. Thường xuyên phàn nàn

Những nhân viên tệ thường xuyên phàn nàn và đối với họ chẳng có gì đủ tốt để hài lòng cả.

2. Luôn bào chữa

Họ không bao giờ chịu trách nhiệm cho hành động của mình, thay vào đó là tìm mọi lý do để bào chữa.

3. Thiếu nhiệt huyết

Khi một dự án mới được triển khai, họ thường tỏ ra không mấy hứng thú.

4. Không giúp đỡ những người khác

Câu cửa miệng của những người này là ‘Đó chẳng phải việc của tôi’ khi đồng nghiệp hoặc ai đó đề nghị sự giúp đỡ.

5. Chuyên ngồi lê đôi mách

Những người hay ngồi lê đôi mách, nói xấu người này với người kia sẽ ảnh hưởng xấu đến tinh thần đoàn kết của các nhân viên cũng như văn hóa của công ty.

6. Nói dối

Một nhân viên hay nói dối và thích bịa chuyện là mối nguy hiểm rất lớn cho công ty của bạn.

7. Thể hiện như mình biết tất cả mọi thứ

Họ thể hiện giống như mình biết hết mọi thứ và những điều bạn nhắc đến chẳng có gì là mới với họ cả.

8. Không có tinh thần làm việc theo nhóm

Một nhân viên chỉ khăng khăng làm theo ý mình mà không để ý đến ý kiến của các thành viên khác trong nhóm sẽ ảnh hưởng đến lợi ích của công ty.

9. Thiếu trách nhiệm

Những nhân viên thiếu trách nhiệm thường đi làm muộn, không hoàn thành kế hoạch và chẳng bao giờ giữ lời hứa của mình.

10. Thiếu sáng tạo

Một nhân viên tốt sẽ luôn suy nghĩ, tìm tòi những cái mới trong khi một nhân viên tệ chỉ ngồi một chỗ và chờ xem người khác nói phải làm gì tiếp theo.

11. Không bao giờ đặt câu hỏi

Họ không hứng thú với việc đặt câu hỏi và học thêm những điều mới.

12. Thiếu tập trung

Những nhân viên kiểu này thường dễ dàng bị sao nhãng trong công việc.

13. Không phát triển

Một nhân viên không bao giờ cố gắng để trở nên tốt hơn sẽ chẳng thể giúp ích gì nhiều cho công ty của bạn.

-st-

Tại sao ra quyết định đồng thuận tốt hơn cho các dự án PMTDNM

Nhiều người trong chúng ta sử dụng mô hình ra quyết định đồng thuận (Consensus-based decision making) trong các dự án PMTDNM như Apache’s lazy consensus model, nhưng phần lớn chúng ta thực hiện hay thậm chí đặt thành qui định cuối cùng theo qui trình biểu quyết theo đa số (Majority-based decision making).

Trong mô hình biểu quyết theo đa số, những người bất đồng quan điểm bị gạt sang một bên — nhóm đa số buộc phải đặt nhóm bất đồng thiểu số vào vị trí những kẻ thua trong cuộc biểu quyết. Trong mô hình ra quyết định đồng thuận, trách nhiệm của cả nhóm là luôn lưu tâm đến các mối lo ngại của những người bất đồng quan điểm.

Nhìn chung, các quyết định đồng thuận bắt buộc nhóm phải tập trung dàn xếp một giải pháp tốt nhất có thể. Khi mọi người bị đặt vào vị trí thắng/thua, họ có xu hướng suy nghĩ cứng nhắc vào một hoặc hai đầu, thứ mà chưa chắc đã đại điện cho giải pháp tốt nhất có thể (rất có thể nằm đâu đó ở giữa).

Thông thường, để đạt được sự đồng thuận, chỉ cần làm rõ một số ý hiểu nhầm hoặc thực hiện một số điều chỉnh nhỏ so với đề xuất ban đầu. Tuy nhiên, sự xuất hiện phiếu trắng (-0) , kể cả khi không có phiếu chống (-1) nào, cũng cho thấy, đề xuất ban đầu nên được suy nghĩ thêm. Phiếu trắng từ những người lãnh đạo nhóm càng khuyến khích những người khác cân nhắc khả năng cần phải bổ sung thêm để đề xuất nhận được sự ủng hộ hoàn toàn.

Hiện tại, những dự án, cộng đồng PMTDNM lớn như CentOS, Fedora đã và đang áp dụng mô hình ra quyết định đồng thuận này.

Đánh giá khả năng phát triển của một dự án PMTDNM

Tính đến thời điểm này, có tới trên dưới 400,000 dự án phần mềm tự do nguồn mở trên toàn thế giới, và nhiều dự án mới được phát sinh mỗi ngày; từ những dự án thu hút hàng ngàn, hàng chục ngàn, thậm chí hàng trăm ngàn lập trình viên, tới những dự án chỉ với duy nhất 1 người phát triển. Câu hỏi đặt ra là làm thế nào để xác định được tiềm năng phát triển, hướng tới thành công của một dự án PMTDNM (không phân biệt dự án lớn/nhỏ, dự án mới/lâu năm…). Một trong các phương pháp được sử dụng nhiều nhất là phương pháp “Tính chỉ số khả năng một dự án PMTDNM đang trên con đường dẫn tới Thất bại – Points of FAIL”.

Bài viết này đề cập đến phương pháp này cùng chi tiết về cách tính điểm PoF (Points of FAIL) cho một dự án PMTDNM. PoF càng lớn nghĩa là dự án càng đang tiến gần đến điểm “Chết”.Trên thực tế, mục đích chính của hệ thống tính điểm PoF là chỉ ra các điểm chưa tốt của dự án PMTDNM, khuyến khích mỗi dự án tự điều chỉnh nhằm đi đến mục tiêu thành công cuối cùng. Các thuộc tính được xem xét cho một dự án cùng PoF cho mỗi thuộc tính bao gồm:

Tổng độ lớn mã nguồn (Size):

  • Nếu độ lớn mã nguồn của dự án >100MB: +5 PoF
  • Nếu mã nguồn nén lại vẫn có độ lớn >100MB: +5 PoF

Hệ thống quản lý mã nguồn (Source Control):

  • Không có hệ thống quản lý mã nguồn công khai (VD: cvs, svn, bzr, git, hg…): +10 PoF
  • Có hệ thống quản lý mã nguồn công khai, nhưng:
    • không có web viewer: +5 PoF
    • không có tài liệu hướng dẫn sử dụng cho người mới: +5 PoF
    • hệ thống quản lý mã nguồn tự tạo: +30 PoF
    • trên thực tế, không được sử dụng: +50 PoF

Dịch từ mã nguồn (Building From Source):

  • Không có tài liệu hướng dẫn dịch từ mà nguồn: +20 PoF
  • Có tài liệu nhưng không chính xác: +10 PoF
  • Mã nguồn được cấu hình bằng một shell script tự viết bằng tay: +10 PoF
  • Mã nguồn được cấu hình bằng cách sửa trực tiếp vào tệp cấu hình: +20 PoF
  • Mã nguồn được cấu hình bằng cách sửa thủ công vào các tệp header: +30 PoF
  • Mã nguồn không cấu hình được trước khi dịch: +50 PoF
  • Mã nguồn được dịch bằng công cụ khác, không phải GNU Make: +10 PoF
  • Mã nguồn được dịch bằng công cụ nguồn đóng: +50 PoF
  • Mã nguồn được dịch bằng công cụ tự tạo: +100 PoF

Gói kèm (Bundling):

  • Mã nguồn chỉ phát hành với các dự án khác mà nó phụ thuộc vào: +20 PoF
  • Mã nguồn không thể dịch riêng nếu không dịch mã gói kèm trước: +10 PoF
  • Mã gói kèm đã bị chỉnh sửa: +40 PoF

Thư viện (Libraries):

  • Chương trình chỉ dịch ra thư viện tĩnh (static libraries): +20 PoF
  • Chương trình có thể dịch ra thư viện chia sẻ (shared libraries) nhưng không đánh phiên bản: +20 PoF
  • Không cố gắng sử dụng các thư viện hệ thống (system libraries) sẵn có: +20 PoF

Cài đặt hệ thống (System Install):

  • Chương trình cố gắng cài đặt vào thư mục /opt hoặc /usr/local: +10 PoF
  • Không có “make install”: +20 PoF
  • Chương trình không hoạt động ngoài thư mục mã nguồn: +30 PoF

Các “dị điểm” trong mã nguồn (Code Oddities):

  • Mã nguồn sử dụng dấu xuống dòng kiểu Windows (“DOS format” files): +5 PoF
  • Mã nguồn phụ thuộc vào một tính năng cụ thể của chương trình dịch: +20 PoF
  • Mã nguồn phụ thuộc vào một lỗi cụ thể của chương trình dịch: +50 PoF
  • Mã nguồn phụ thuộc vào bất cứ thứ gì trong bộ Microsoft Visual Studio: +100 PoF

Giao tiếp (Communication):

  • Dự án không có thông báo phát hành trên nhóm thư (mailing list): +5 PoF
  • Dự án không có nhóm thư: +10 PoF
  • Dự án không có trình quản lý lỗi (bug tracker): +20 PoF
  • Dự án không có website: +50 PoF
  • Là một dự án ảo (vaporware) trên Sourceforge: +100 PoF

Phát hành (Releases):

  • Dự án không thực hiện phát hành theo phiên bản tuần tự (Major, Minor): +10 PoF
  • Dự án không thực hiện phát hành theo phiên bản: +20 PoF
  • Dự án không có phát hành: +50 PoF
  • Dự án chỉ phát hành dưới dạng một file gắn kèm một bài viết trên diễn đàn/website: +100 PoF
  • Bản phát hành chỉ dưới khuôn dạng .zip: +5 PoF
  • Bản phát hành chỉ dưới khuôn dạng OSX .zip: +10 PoF
  • Bản phát hành chỉ dưới khuôn dạng .rar: +20 PoF
  • Bản phát hành chỉ dưới khuôn dạng .arj: +50 PoF
  • Bản phát hành chỉ dưới khuôn dạng nén tự tạo: +100 PoF
  • Bản phát hành giải nén không vào thư mục riêng chứa số hiệu phiên bản (e.g. glibc-2.4.2/): +10 PoF
  • Bản phát hành giải nén không vào thư mục riêng (e.g. glibc/): +25 PoF
  • Bản phát hành giải nén vào một thư mục con mức sâu (e.g. home/johndoe/glibc-svn/tarball/glibc/src/): +50 PoF

Lịch sử (History):

  • Chương trình được rẽ nhánh từ một dự án khác: +10 PoF
  • Các lập trình viên chính không tham gia dự án cha (trong trường hợp rẽ nhánh): +50 PoF
  • Là phần mềm nguồn đóng trước khi nguồn mở hóa:
    • 1-2 năm: +10 PoF
    • 3-5 năm: +20 PoF
    • 6-10 năm: +30 PoF
    • trên 10 năm: +50 PoF

Giấy phép (Licensing):

  • Giấy phép không được ghi trong từng tệp mã: +10 PoF
  • Mã nguồn tự thân chứa sự không tương thích của các giấy phép: +20 PoF
  • Mã nguồn không có thông báo về mục đích của giấy phép: +30 PoF
  • Mã nguồn không bao gồm một bản sao toàn văn giấy phép: +50 PoF
  • Mã nguồn không nêu rõ giấy phép: +100 PoF

Tài liệu (Documentation):

  • Chương trình không có lịch sử thay đổi (changelog): +10 PoF
  • Chương trình không kèm theo bất cứ tài liệu nào: +20 PoF
  • Không công bố bất cứ tài liệu nào trên website: +30 PoF

Chỉ số tổng hợp (FAIL METER):

  • 0 PoF: Hoàn hảo! Các chỉ số đều hướng tới thành công!
  • 5-25 PoF: Bạn đang làm tốt, nhưng hoàn toàn có thể tốt hơn.
  • 30-60 PoF: Bạn làm chưa tốt. Cần cải tiến.
  • 65-90 PoF: Bạn làm rất không tốt. Cần thay đổi sớm (theo các chỉ số bị cộng điểm cao ở trên).
  • 95-130 PoF: Con tàu sắp chìm rồi!
  • 135+ PoF: Dự án đã hoàn toàn thất bại.

Còn chần chờ gì nữa, hãy thử nhẩm tính PoF của dự án PMTDNM của bạn! 🙂

Nguồn: http://www.theopensourceway.org/

CyanogenMod 10 Bootcamp at Community Space Hanoi

Participants: @CyanogenMod @cmpitg @hai_np @tatuan @playingwithsid @mrddragon

My mission: hack the tablet Google Nexus 7 with Jelly Bean 4.2 installed to *upgrade* to CM10

Location: http://khonggiancongdong.org/

Results: MISSION COMPLETED.

Steps:

  1. Enable USB debugging mode: By tapping on “Build number” seven times, you have unlocked USB  debugging mode on Android 4.2 and higher. You can now enable/disable it  whenever you desire by going to “Settings” -> “Developer Options”  -> “Debugging” ->” USB debugging”.
  2. Download softwares:
    • ALREADY downloaded CM10 Nightlybuild 20121123 yesterday night.
    • NOT download the Google apps for Jelly Bean 4.1.2 (the device currently running JB 4.2)
    • Download ClockworkMod 6.0.1.9 for grouper (my device)
  3. PUSH the software to device’s sdcard:
    • sudo ./adb push ~/Downloads/cm-10-20121123-NIGHTLY-grouper.zip /sdcard/
  4. Unlock the bootloader
    • Reboot to bootloader: sudo ./adb reboot bootloader
    • Unlock the bootloader: sudo ./fastboot oem unlock (then select YES to unlock)
  5. Install Recovery software
    • I chose ClockworkMod (NOT touch version): sudo ./fastboot flash recovery ~/Downloads/recovery-clockwork-6.0.1.9-grouper.img
  6. Install Cyanogenmod 10 Nightlies and Google apps
    • Select the option to Wipe data/factory reset.
    • Then go to “Install zip from sdcard”; “Choose zip from sdcard”
    • First, select your Cyanogenmod 10 Nightlies.zip
    • Then, select your Google Apps.zip (I have to BACK to download and push/upload it to device’s sdcard)

That’s ALL 😉

Then it would reinstall all your recent apps automatically.

However, I do not know how to resync all app’s settings :). That would be an interesting open issue for next hacks.

References:

  • http://forum.cyanogenmod.org/topic/58795-unlock-root-install-cyanogenmod-10-nightlies/
  • http://dottech.org/87439/how-to-unlock-usb-debugging-mode-on-android-4-2-jelly-bean-and-higher-guide/

10 hiểu lầm về phần mềm tự do nguồn mở

Trong một thời gian dài, đề cập đến phần mềm tự do nguồn mở trong một môi trường kinh doanh là không thể tưởng tượng nổi. May mắn thay, thời gian đã thay đổi, phần mềm tự do nguồn mở ngày nay thường được cân nhắc đầu tiên. Nhưng những tiến bộ đáng kể đó không hoàn toàn loại bỏ một số quan niệm sai lầm trong tâm trí của người sử dụng. Vì vậy, sẽ rất hữu ích khi liệt kê một vài nhận thức hoàn toàn sai về phần mềm tự do nguồn mở:

1. Phần mềm tự do nguồn mở chỉ dành cho Linux

Hầu hết người sử dụng cùng chung điểm này. Khi nói về phần mềm tự do nguồn mở, cuộc nói chuyện, không sớm thì muộn, hầu như chắc chắn xoay sang Linux. Công chúng dường như luôn luôn giả định các phần mềm tự do nguồn mở chỉ dành cho Linux. Trong thực tế có rất nhiều dự án phần mềm tự do nguồn mở hoạt động đa nền tảng hoặc thậm chí chỉ chạy trên Windows. Trang web phần mềm tự do nguồn mở cho Windows liệt kê danh sách một loạt các phần mềm tự do nguồn mở dành cho hệ điều hành của Microsoft. Tuy nhiên, trang web không bao gồm danh sách các dự án cực lớn như Apache, MySQLDrupal.

2. Phần mềm tự do nguồn mở luôn luôn miễn phí

Để được coi là phần mềm tự do nguồn mở, điều kiện cần là mã nguồn phải được chia sẻ tự do. Điều đó không đồng nghĩa rằng bản thân các ứng dụng chắc chắn miễn phí. Thực tế, có nhiều công ty kiếm tiền từ các dự án phần mềm tự do nguồn mở của họ. Thông thường, các nhà cung cấp có xu hướng cung cấp kèm theo các dịch vụ như hỗ trợ, bổ sung tính năng hoặc tạo ra một phiên bản cộng đồng miễn phí.

Khi một công ty bán một phiên bản cộng đồng, nó thường là một biến thể rút gọn của sản phẩm thương mại nguồn mở. Một ví dụ tuyệt vời của phương pháp này là Zimbra, một phần mềm máy chủ thư điện tử và công cụ cộng tác mạnh mẽ, cung cấp cả phiên bản nguồn mở miễn phí, kèm theo mã nguồn đầy đủ và phiên bản thương mại với nhiều tính năng hơn và khả năng tiếp cận mã nguồn hạn chế hơn.

3. Phần mềm tự do nguồn mở không được hỗ trợ

Vấn đề hỗ trợ thường rất quan trọng đối với các công ty lớn. Một số phần mềm tự do nguồn mở cung cấp hỗ trợ, một số kèm theo phụ phí, một số miễn phí. Đôi khi, có những diễn đàn hoặc danh sách thư hỗ trợ. Một vài trường hợp khác, có thể liên lạc với các nhà phát triển đã tạo ra hoặc đang làm việc trong dự án. Thậm chí một vài phần mềm tự do nguồn mở không có một công ty với đường dây nóng hỗ trợ 24/7, điều đó không có nghĩa là không có hỗ trợ. Phương án hỗ trợ chắc chắn có sẵn, cho dù hỗ trợ đó có thể không tương đồng với những suy nghĩ, tính toán của công ty.

4. Bạn cần truy cập toàn bộ vào mã nguồn

Mặc dù việc này thường không phải là vấn đề quan tâm của người dùng bình thường, tuy nhiên, nó cũng vẫn khá quan trọng trong hoàn cảnh vẫn còn một số quan niệm sai lầm đáng kể. Phần mềm tự do nguồn mở cho bạn khả năng truy cập toàn bộ vào mã nguồn, nhưng không có nghĩa là bạn bắt buộc phải quyền truy cập nếu chỉ muốn sử dụng phần mềm.

Đây là một điều huyễn hoặc đã kéo dài trong một thời gian dài. Chỉ vì mã nguồn được phát hành và có sẵn không có nghĩa là nó luôn cần thiết. Trong thực tế, người dùng có thể không bao giờ phải động tới mã nguồn trong toàn bộ quãng thời gian sử dụng phần mềm tự do nguồn mở. Nhưng mỗi khi bạn hoặc công ty của bạn muốn thay đổi một ứng dụng, mã nguồn sẽ luôn sẵn sàng.

5. Phần mềm tự do nguồn mở chỉ dành cho lập trình viên

Rất nhiều công chúng dường như nghĩ rằng bởi vì bản chất của phần mềm tự do nguồn mở, chỉ có các lập trình mới sử dụng. Sự nhầm lẫn có thể phát sinh từ sự sẵn có của mã nguồn và kèm theo giả định rằng sự sẵn có của mã nguồn có nghĩa rằng chỉ có những người biết làm thế nào để đọc, chỉnh sửa, và xây dựng lại mã nguồn đó mới có thể và nên sử dụng nó.

Trong thực tế, bất cứ ai cũng có thể sử dụng phần mềm tự do nguồn mở mà không đòi hỏi phải có các kỹ năng để sửa đổi và xây dựng lại phần mềm.

6. Bạn đang vi phạm luật pháp với việc ứng dụng phần mềm tự do nguồn mở

Trước hết phải cảm ơn SCO. Mọi người đã từng nghĩ ứng dụng phần mềm tự do nguồn mở có thể là bất hợp pháp. Nhưng may mắn thay, tất cả đã thay đổi kể từ sau khi SCO bị thua kiện tại tòa án. Sử dụng phần mềm tự do nguồn mở không vi phạm pháp luật sở hữu trí tuệ. Và đó không phải là một trường hợp duy nhất thất bại khi cố gắng chứng minh phần mềm tự do nguồn mở đã vi phạm về sở hữu. Vì vậy, hoàn toàn có thể khẳng định rằng nếu bạn đang sử dụng phần mềm tự do nguồn mở, bạn không bị coi là một kẻ nổi loạn vi phạm pháp luật.

7. Bạn phải là một chuyên gia nếu muốn sử dụng phần mềm tự do nguồn mở

Điểm này liên quan đến các điểm trước. Vẫn còn nghe thấy câu hỏi cũ, “Bạn có phải tự viết các trình điều khiển để sử dụng?” Câu trả lời đã rõ một thời gian dài, không. Nhiều người vẫn tin rằng phần mềm mã nguồn mở chỉ dành cho chuyên gia, những người có thể biên dịch phần mềm ngay trong giấc ngủ. Không phải như vậy.

Trong thực tế, hầu hết các dự án phần mềm tự do nguồn mở hiện tại không yêu cầu phải biên dịch, cài đặt từ mã nguồn. Hầu hết các nền tảng đều hỗ trợ các phần mềm dưới dạng đóng gói sẵn, giúp cho việc cài thêm phần mềm vào máy tính dễ dàng như cài đặt phần mềm thương mại, trong một vài trường hợp, thậm chí còn dễ dàng hơn. Và quá trình sử dụng hầu hết các phần mềm tự do nguồn mở là như nhau. Giống như tất cả những điều để làm với máy tính, khi trí thông minh của người sử dụng máy tính trung bình giảm, tính dễ sử dụng phần mềm tự do nguồn mở tăng lên.

8. Thật khó để tìm thấy phần mềm tự do nguồn mở cần thiết

Phần mềm nguồn mở ở khắp mọi nơi, có sẵn trên Download.com, trong kho phần mềm Android, trong tiện ích thêm/bớt phần mềm trên các bản phân phối Linux, và từ các trang web trên toàn cầu. Chỉ cần một phép tìm kiếm trên Google là bạn có thể tìm thấy phần mềm tự do nguồn mở.

Có các trang web được dành riêng cho phần mềm tự do nguồn mở trên các nền tảng cụ thể, và thậm chí cả Microsoft cũng có một trang web phần mềm tự do nguồn mở riêng. Phần mềm tự do nguồn mở đã đi qua một chặng đường dài từ cội nguồn trong con đường tìm về bản ngã, cạnh tranh với phần mềm thương mại độc quyền giống như trong câu phương ngôn tìm kim trong đống cỏ.

9. Phần mềm miễn phí và phần mềm chia sẻ cũng là phần mềm tự do nguồn mở

Hầu hết các người dùng đã quen thuộc với phần mềm miễn phí và phần mềm chia sẻ. Hai loại phần mềm là không giống như phần mềm tự do nguồn mở. Nếu mã nguồn phần mềm không được cung cấp, thì các phần mềm đó chắc chắn là không phải là phần mềm tự do nguồn mở.

 

 

10. Không nhiều người sử dụng phần mềm tự do nguồn mở

Trong thực tế, bạn có thể đang sử dụng phần mềm tự do nguồn mở. Bạn có đang sử dụng trình duyệt Firefox? Nếu vậy, bạn đang sử dụng phần mềm tự do nguồn mở. Nhiều người sử dụng phần mềm tự do nguồn mở mà không biết. OpenOffice, ThunderbirdPidgin, Drupal, WordPressGnuCash, Notepad++, và nhiều sản phẩm nữa hiện đang được sử dụng rộng rãi. Và đó thậm chí còn chưa tính các đoạn mã nguồn tự do được đưa vào phần mềm thương mại.

Xu hướng phát triển

Phần mềm tự do nguồn mở giờ đây không còn phải chịu sự kỳ thị. Nhiều ứng dụng phần mềm tự do nguồn mở được xem như  tương đương hoặc tốt hơn với các phần mềm thương mại. Xu hướng này đang tiếp tục, đặc biệt là khi nhiều người dùng chuyển từ máy tính để bàn truyền thống sang các ứng dụng dựa trên đám mây hoặc ảo hóa.

Nếu bạn đang xem xét việc chuyển từ phần mềm đóng sang phần mềm tự do nguồn mở, có nhữngđiều bạn nên biết, nhưng rất ít thứ bạn phải biết. Tự trang bị thông tin đúng đắn, quá trình chuyển đổi của bạn sang phần mềm tự do nguồn mở sẽ trôi trảy. Ngoài ra, nếu bạn đã có kinh nghiệm trong phần mềm tự do nguồn mở, có lẽ bạn đã gặp phải quan niệm sai lầm phổ biến khác mà bạn muốn chia sẻ.

source: zdnet.com

Software Freedom Day Hanoi, 17 Sep 2011, time for freedom celebration

Hello,

Welcome you all back.

SFD Hanoi 2011 has been done even more than successfully. We talked about FOSS and the freedom of software development and business all the day.

The day started at 8:45 AM (15 munites later than schedule) with celebration speech from Dr. Nguyen Hong Quang from IFI about SFD, FOSS, the community, etc.

Then, the main section of the day continued at 9:00 AM. MC Nguyen Ha “Yang” Duong introduced overall activities in the day, then he started the morning sessions with a barcamp-style vote campain.

All the morning presentations were introduced shortly by presenters then voted by partcipants one by one:

  1. Exploring FOSS world with Apache Maven (by Mr. Lai Trung Hieu from eXo Platform SEA): 19 votes.
  2. How to make MONEY with FOSS (by me): 30 votes (wow, me first :).
  3. Messaging and Collaboration with Zimbra Collaboration Suite (by me):  19 votes.
  4. Collaborative Development in FOSS community (by me): 14 votes :(.
  5. Ubuntu 11.04 and the Ubuntu-VN community (by Mr. Nguyen Ha Duong, Ubuntu-VN leader): 30 votes.
  6. Mozilla Localization (by Mr. Ha Quang Duong, HanoiLUG, Mozilla Localization team Vietnam): 17 votes.

As voting results, my presentation started the day :). I see it’s so hot to know how to make/earn money with FOSS :).  However, my presentation focused on the development/community and legal factors with a little business ones. In my view, to make a sustainable business, they should understand how FOSS developed in the community as well as the legal related issues; business factors should be similar with other types of business. This view was shared completely by participants. See my presentation here.

Next, Yang and Khanh introduced Ubuntu-VN community and live demonstrated Ubuntu 11.04 with Unity. Over a half of participants are Ubuntu-VN members so they were also interested in the session :).

After some other presentations, some new participants also registered their ones so a new voting time needed to be held. One after one, the morning session was over so fast.

After lunch, the activities in the day was back with a questions and answers session moderated by Mr. Le Trung Nghia from Ministry of Science and Technology, one of the most active FOSS activists in Vietnam with the well-known blog VNFOSS. A lot of interesting questions were asked and Mr. Nghia as well as all participants discussed a lot about FOSS and the community.

Next was the workshop time with three parallel workshops. Beside “Kernel hackings” (by Yang) and “Linux command lines” (by Ha Quang Duong), I got a mini workshop to introduce about Fedora Community, how to join with us, how to make contribution to Fedora Project. Then, I introduced how to make a Fedora package and I see that’s the most interesting thing to participants :). After the workshop, I considered to build a separated Fedora Contributors (at this time, Fedora users and contributors have still participated in local LUGs). I tried to introduce and PR the FAD-Hanoi 2011 (scheduled on October). However, finally, I thought I should try to build the separated Fedora users and contributors in Vietnam first. With a separated (small) community, we can do our own events and activities much easier.

The day was closed with an exciting bidding session where we sold four T-shirts with 200k VND :).

An exciting day was closed. Thanks to all my friends and participants who made this happened.

See all of you in the next FOSS events and in the SFD 2012 next year.

See some SFD pictures on Facebook and Picasa.

Yours faithfully,

Truong Anh Tuan
Fedora Ambassador and Packager
HanoiLUG member and FOSS activist in Vietnam

Cấm xuất hàng sang Mỹ nếu vi phạm bản quyền

TT – Ngày 1-8, Cục Quản lý cạnh tranh (Bộ Công thương) cho biết một số bang của Mỹ bắt đầu áp dụng đạo luật vi phạm bản quyền sở hữu trí tuệ trong lĩnh vực công nghệ thông tin đối với doanh nghiệp xuất khẩu hàng hóa sang Mỹ có vi phạm về bản quyền.

Theo đạo luật này, hàng hóa của doanh nghiệp có vi phạm về bản quyền sẽ không được bán tại thị trường Mỹ. Hành vi vi phạm bản quyền được xét ở khâu sản xuất trực tiếp lẫn khâu phân phối, quảng bá hoặc bán sản phẩm.

Chẳng hạn, doanh nghiệp sản xuất xuất khẩu dệt may, giày, nhựa… khi sử dụng máy tính có cài các phần mềm liên quan đến Windows, Word, Excel (cũng như nhiều phần mềm khác có liên quan trong lĩnh vực sản xuất)… mà không có bản quyền thì sản phẩm sản xuất hoàn chỉnh vẫn bị xem là vi phạm.

Đạo luật nêu rõ doanh nghiệp Mỹ muốn nhập khẩu hàng hóa phải yêu cầu đối tác nước ngoài gửi thư bảo đảm cam kết không có vi phạm bản quyền. Nếu đối tác có vi phạm bản quyền, doanh nghiệp Mỹ có quyền đơn phương chấm dứt hợp đồng nhập khẩu mà không bị xem là vi phạm hợp đồng.

Theo ông Phạm Xuân Hồng – phó chủ tịch Hiệp hội Dệt may Việt Nam, hiện các doanh nghiệp sản xuất, xuất khẩu có quy mô phần lớn đều sử dụng phần mềm liên quan đến quy trình sản xuất có bản quyền.

Theo TTO.

Rethinking business: time for “shared value”

One of the world’s leading business thinkers says companies need to retool their approach to profit by working with society to create “shared value,” and not regarding it as a costly “externality.”

Michael Porter, the famed author of Competitive Strategy, says the business sector has become estranged from the rest of the community, even among those who are pro-business, because of its narrow approach to making profit.

He said in an interview with the BBC that “there’s a widespread view … that business today is actually profiting at the expense of social needs and communities.”

“There’s been this shorter-term view of how to create profitability, and also been this narrowing of what the responsibility of the company is.”

Companies today are trying to “persuade people to buy more, to buy things that they may not need, that may not even be good for them,” he said.

Where businesses once used to consider they had some responsibility for the welfare of the communities where they operated, they are now “trapped in a bubble” and don’t understand that these societal factors “have a profound effect on their proficiency and productivity,” Porter says.

He points to firms such as GE, Google, Intel, Johnson & Johnson and Unilever that are creating “shared value by reconceiving the intersection between society and corporate performance.”

“The purpose of the corporation must be redefined as creating shared value, not just profit per se,” Porter said in a Harvard Business Review essay he co-authored. This means recognizing that “societal needs, not just conventional economic needs, define markets.”

“It also recognizes that social harms or weaknesses frequently create internal costs for firms—such as wasted energy or raw materials, costly accidents, and the need for remedial training to compensate for inadequacies in education,” he writes.

“Food companies that traditionally concentrated on taste and quantity to drive more and more consumption are refocusing on the fundamental need for better nutrition.

“Intel and IBM are both devising ways to help utilities harness digital intelligence in order to economize on power usage. [US bank] Wells Fargo has developed a line of products and tools that help customers budget, manage credit, and pay down debt.

“Sales of GE’s Ecomagination products reached $18 billion in 2009—the size of a Fortune 150 company. GE now predicts that revenues of Ecomagination products will grow at twice the rate of total company revenues over the next five years.”

Many “so-called externalities” actually create internal costs on the firm, such as excess packaging of products and greenhouse gases, which are costly to the company as well as the environment.

“Wal-Mart, for example, was able to address both issues by reducing its packaging and rerouting its trucks to cut 100 million miles from its delivery routes in 2009, saving $200 million even as it shipped more products. Innovation in disposing of plastic used in stores has saved millions in lower disposal costs to landfills.”

Porter says businesses must take the lead in bringing business and society back together.

“The recognition is there among sophisticated business and thought leaders, and promising elements of a new model are emerging. Yet we still lack an overall framework for guiding these efforts, and most companies remain stuck in a ‘social responsibility’ mind-set in which societal issues are at the periphery, not the core.”

Source: Green Channel