Fedora 17 chính thức phát hành

Cộng đồng Fedora trân trọng gửi tới toàn thể các bạn hữu trong cộng đồng FOSS tại VN và trên toàn thế giới, Fedora 17 đã chính thức được phát hành với tên mã Beefy Miracle: http://vn.fedoracommunity.org/2012/05/29/announcing-fedora-17-relish-it/

Phiên bản mới đã ngay lập tức có mặt trên Virror. Các bạn có thể download tại địa chỉ: http://virror.hanoilug.org/fedora/releases/17/Live/

Và nếu bạn đang ở Hà Nội, đừng quên tham dự Fedora 17 Release Party Hà Nội với chúng tôi tại địa điểm thường lệ, LollyBooks Cafe, số 18, ngõ 131 Thái Hà vào 6:00 PM, chiều thứ 6, 1/6/2012. Thông tin chi tiết xem tại: https://fedoraproject.org/wiki/Release_Party_F17_Hanoi

Một lần nữa, xin cảm ơn những đóng góp của các thành viên Fedora Vietnam: Nguyễn Hà Dương, Nguyễn Năng Thắng và tất cả các bạn cho Fedora nói riêng và FOSS nói chung. Viva FOSS, Happy sharing!!!

Trương Anh Tuấn
Fedora Contributor

The 3rd day at FUDCon KL 2012

It’s the last day in KL. To be honest, this day is not so exciting as two previous days. It may simply cause by the feelings (everyone is more tired after several days working hard) or by the quality of talks or both.

I was impressed with the talk “Spam fighting with Postscreen” by Christoph. The presentation analysed spam issues, how they do effect onto the whole email systems (network, hardware, time, fishing, malware, etc.) and how we can do to fight against them with Postscreen. I saw it’s a big thing to learn then I will try it as soon as I come back.

The day was exciting back with closing ceremony from Red Hat guy. He shared about how FOSS community important, how Fedora, Red Hat as well as the remain FOSS community to collaborate to make a better world.

Last, but so exciting thing is the small lottery with two tablet gifts from OSCC-MAMPU. The day closed with a big luck for a volunteer (he got the bigger tablet :D). That’s also a big thanks from all of us to organizers and volunteers who make the FUDCon success.

Thanks to all for getting together to make the Fedora community stronger and stronger.

Truong Anh Tuan
Reported from Hanoi (after safe trip back from KL)

The 2nd day at FUDCon APAC KL 2012 – time for improving Fedora activities and contributions in APAC

This article is special for noting all our activities here for the goals of improving Fedora activities and contributions in APAC in the future.

Things need to be discussed have been prepared in APAC ambassadors weekly meetings and put all to a wiki page. Before the FUDCon, everything was in place. Firstly, I thought we should have a separated session where everyone can join together to discuss prepared things face to face. So, after discussion with KageSenshi (he’s also the main organizer), I recognized the, this is not a regular talk and it’s better to discuss internally, among Fedora contributors, not publicly for everyone since people who are not Fedora contributors may not understand what we discuss at all. That should save time for both Fedora contributors and other FUDCon participants. Then we were completely right.

A *small* discussion (about one and a half hour) among over ten Fedora contributors at FUDCon was decided and arranged so quickly. We discussed a lot of things about how to get the APAC bi-weekly meetings more efficient. They should be for making decisions, not for discussions, although we can sometimes discuss a little more before making decisions. Therefore, all discussions should be discussed via mailing list, trac, etc. as much as possible before the meeting. Agenda of meetings should be also reduced to focus on which should be opened in the meeting for decision making. That should be also good to get the most active ambassadors to come, although it’s still open for everyone.

Beside that, we discussed more about the budget allocation and budget approval process in Fedora world wide as well as in APAC, media/swags distributions process in APAC, FreeMedia program and Mentoring program. KageSenshi told us about his CampusCamp idea. I think, it’s good idea for making/encouraging the Sharing culture in APAC.

Budget allocation and approval processes with in APAC as well as all the Fedora community should be one of the most important things. You know, Fedora has been funded from several sponsors and the biggest one is Red Hat; but how to use that fund more efficiently is still a big question. IMO, funds should be put to right persons, for right activities, in right places and at the right time. To get this done, we (Fedora community) need to have a clearer budget allocation process and update that information to everyone; also, in APAC, we should have a more efficient approval process where fund requests would be reviewed carefully but faster, and reimbursement, e.g., would be done much faster. I know a proposal is being discussed within FAmSCo and some others. I will follow it and contribute more to.

In the whole day to tried to catch all up and got some other face to face meetups with other Fedora contributors who can not join previous discussion to discuss more with them. It’s great to see that all of them also agree with us.

I noted all discussed items in the memo. Then I will create a wiki to put these things all for everyone to contribute and discuss more later.

Thanks KageSenshi for your great idea and thanks everyone for all your contributions. I myself believe that APAC community must be better and better after FUDCon KL.

Last but not least, the 2nd day closed with a exciting FUDPub. See all funny pictures here.

Then now, the last day of FUDCon started…. 🙂

Truong Anh Tuan
Reported from KL

The 1st day in KL – Keynote from cwickert and Barcamp-style sessions

The day-0: flying to KL. It is not difficult to find to the venue. Thanks for Fedora Malaysia and organizers for your good preparation, especially the travel booklet. Then I can give my hands to help them get the last things done in time.

The FUDCon day-1 started with an interesting keynote given by Christoph Wickert about Leadership in Fedora. He got all understand how Fedora leadership organized, advantages and comparison with leadership in general.  Fedora does not have leaders in the same meanings as general leadership. Fedora “leaders”, if we can call that, should be more similar as guides. Everyone is equal in a flat situation, you can contribute things as many as you want. Fedora participating model is open, flat, flexible, mutating, autonomous and guidance.

The slide beside should be good to summarize what we got from the keynote.

And thanks Ankur Sinha for his nice video of the keynote.

After keynote is time for barcamp-style sessions. A lot sessions were introduced and then fifteen of them has been voted to be held in the afternoon. Honestly, the topics were not so hot as their names :). I saw, almost FUDCon participants are newbies. They are students at APIIT-UCIT. Over a half of them even have never used Linux. Therefore, the talks should be easy to understand for them.

Some other sessions, especially ones presented by Christoph (I attended) are more interesting (IMHO :). We discussed about a mechanism to collaborate with other available FOSS communities and then some LiveUSB stuffs/issues. Unluckily, there is no members from other FOSS communities attend the session then there is no final decision. This may be an interesting topic, however, so it should be continued on the mailing list.

For ones have Facebook access, you can see all my nice pictures shared on Facebook.

Reported from KL by
Truong Anh Tuan, Fedora Contributor

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

Startup Guide for KVM on CentOS 6

I recently made the leap from CentOS 5.6 to CentOS 6 on my primary KVM host, and had to modify how I setup the KVM host to begin hosting virtual machines. Below is a start to finish guide to get you hosting VMs using KVM. These instructions are very specific to CentOS 6.

For this I assume you have setup your server using the “Minimal” option when installing CentOS 6. You must also have the Virtualization features enabled for your CPU. This is done in your host’s BIOS.

Optionally you can skip the first section, Installing KVM, if you check all 4 “Virtualization” software categories during the install.

Installing KVM

If you choose the “Minimal” option during CentOS 6 then this step is necessary. To get the full set of tools there are 4 software groups to install…

  • Virtualization
  • Virtualization Client
  • Virtualization Platform
  • Virtualization Tools

To install run

yum groupinstall "Virtualization*"

dejavu-lgc-sans-fonts is necessary or all the fonts in virt-manager will show as squares

yum install dejavu-lgc-sans-fonts

Once the install is finished verify that the KVM kernel module is loaded.

lsmod | grep kvm

You should see either kvm_intel or kvm_amd depending on your host’s CPU manufacturer.

At this point I chose to reboot the server. This allows services to be started and udev rules for KVM to be applied. This will also allow dbus to create the machine-id file, otherwise you would see something like the below when running virt-manager

# virt-manager
Xlib:  extension "RANDR" missing on display "localhost:10.0". process 1869: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open /var/lib/dbus/machine-id": No such file or directory See the manual page for dbus-uuidgen to correct this issue. D-Bus not built with -rdynamic so unable to print a backtrace Aborted

If you receive that D-Bus error and would prefer not to restart then run this command to generate the necessary machine-id file

dbus-uuidgen > /var/lib/dbus/machine-id

Final configuration steps

The server I run KVM on is headless, but I still like using virt-manager. So we must install the necessary tools to do X11 forwarding through SSH.

yum install xorg-x11-xauth

# If you plan to use VNC to connect to the virtual machine's console locally
yum install tigervnc

Now when you connect through SSH be sure to pass the -X flag to enable X11 forwarding.

Optional: Using an alternate location for VM images with SELinux

With SELinux enabled, special steps must be taken to change the default VM store from/var/lib/libvirt/images. My particular server I choose to keep all images and ISOs for VMs under /vmstore. The steps below give your new store the correct security context for SELinux.

# this package is necessary to run semanage
yum install policycoreutils-pythonsemanage fcontext -a -t virt_image_t "/vmstore(/.*)?"
restorecon -R /vmstore

To activate this store you must open virt-manager, select your host, then do Edit-> Host Details. Under the Storage tab you can add your new storage volume.

Optional : Network Bridging for Virtual Machines

If you wish for your virtual machines to be accessible remotely then you must use network bridging to share your host’s network interface with the virtual machines. The setup requires linking one of your host’s physical interfaces with a bridge device. First copy your physical interface’s ifcfg file to create the new bridge device, named br0.

cp /etc/sysconfig/networking-scripts/ifcfg-eth0 /etc/sysconfig/networking-scripts/ifcfg-br0

Modify ifcfg-br0 to have the IP information in ifcfg-eth0 and remove, or comment out, that information in ifcfg-eth0. Below are examples of ifcfg-eth0 and ifcfg-br0. The highlighted lines are important.

/etc/sysconfig/networking-scripts/ifcfg-eth0

DEVICE=eth0
HWADDR=00:18:8B:58:07:3B
ONBOOT=yes
BRIDGE=br0

/etc/sysconfig/networking-scripts/ifcfg-br0

DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.1.0.3
NETMASK=255.255.255.0

Once those two files are configured restart the network service

service network restart

Optional: Managing libvirt with standard user account

Beginning in CentOS 6 access to managing libvirt is handled by PolicyKit. It’s always a good practice to do your daily administration tasks as some user besides root, and using PolicyKit you can give access to libvirt functions to a standard account.

First we create the necessary config file to define the access controls. The file must begin with a numeric value and have the .pkla extension.

vim /etc/polkit-1/localauthority/50-local.d/50-libvirt-remote-access.pkla

Here’s an example of the file I used to give access to a single user. Be sure to put your desired username in place of username on the highlighted line.

[libvirt Management Access]
Identity=unix-user:username
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

  • You can optionally replace Identity=unix-user:username with Identity=unix-group:groupname to allow access to a group of users.

Finally restart the libvirtd daemon to apply your changes.

/etc/init.d/libvirtd restart

Creating the first virtual machine

You are now ready to create your virtual machines.

Create the virtual disk

With the version of virt-manager shipped with CentOS 6 you cannot create qcow2 images from within the GUI. If you wish to create your new VM with a qcow2 format virtual disk you must do so from the command line, or see the next section for RPMs to upgrade virt-manager.

Update: Through some testing I’ve found that performance can be greatly improved if the preallocation is set when creating a qcow2 image.

# With preallocation
qemu-img create -f qcow2 -o preallocation=metadata CentOS-6.0-x86_64-Template.qcow2 20G

# Without preallocation
qemu-img create -f qcow2 CentOS-6.0-x86_64-Template.qcow2 20G

  • NOTE: Replace the filename “CentOS-6.0-x86_64-Template” with your desired name, and also replace “20G” with the desired max size of the virtual disk.

Now when creating your virtual machine select to use an existing virtual disk.

Source: itscblog.tamu.edu

Fedora 16 Arrives, Cloud Friendly

Cloud and virtualization technologies now feature in latest version release

The Red Hat sponsored Fedora Project has announced availability of version 16 of the free and open-source operating system distribution. Fedora 16 now features “Aeolus Conductor” as a feature enhancement designed to create and manage cloud instances across a variety of cloud types. OpenStack tools have also been included to help configure and run cloud compute and storage infrastructures; new too is HekaFS, a technology based on GlusterFS to enable cloud-ready distributed parallel filesystems. Lastly in the cloud category, the Pacemaker-cloud application service has now been incorporated to improve availability.

Red Hat reminds us that Fedora Project developers collaborate closely with upstream free software project teams to try and provide the best experience for users; that access and integration of new features can hopefully lead to wider and further innovation. The Fedora Project aims to release a new version of its free operating system approximately every 6 months. According to Red Hat, this rapid development cycle encourages collaboration and the inclusion of the latest, most cutting-edge open-source features available. Fedora is built by community members from across the globe, and the Fedora Project’s transparent and open collaboration process has attracted more than 24,000 registered contributors.

In terms of virtualization technologies, Fedora 16 has been peppered with SPICE USB to offer sharing and audio volume messaging for virtualized desktops; Virtual Machines Lock Manager protects users from starting the same virtual machine twice or adding the same disk to two different virtual machines; and Virt-manager Guest Inspection allows read-only browsing of guest filesystems and the Windows Registry.

“The open source community sets a new bar for technical excellence in the creation of this release,” said leader of the Fedora Project Jared Smith. “Fedora 16 combines the newest advancements in open source virtualized and cloud computing environments with significant under-the hood-improvements — all while continuing to improve the operating system’s usability. The Fedora Project’s commitment to advancing free and open source software is absolutely reflected in what the community delivered in Fedora 16.”

Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70

After a long illness, Dennis Ritchie, father of Unix and an esteemed computer scientist, died last weekend at the age of 70.

Ritchie, also known as “dmr”, is best know for creating the C programming language as well as being instrumental in the development of UNIX along with Ken Thompson. Ritchie spent most of his career at Bell Labs, which at the time of his joining in 1967, was one of the largest phone providers in the U.S. and had one of the most well-known research labs in operation.

Working alongside Thompson (who had written B) at Bell in the late sixties, the two men set out to develop a more efficient operating system for the up-and-coming minicomputer, resulting in the release of Unix (running on a DEC PDP-1) in 1971.

Though Unix was cheap and compatible with just about any machine, allowing users to install a variety of software systems, the OS was written in machine (or assembly) language, meaning that it had a small vocabulary and suffered in relation to memory.

By 1973, Ritchie and Thompson had rewritten Unix in C, developing its syntax, functionality, and beyond to give the language the ability to program an operating system. The kernel was published in the same year.

Today, C remains the second most popular programming language in the world (or at least the language in which the second most lines of code have been written), and ushered in C++ and Java; while the pair’s work on Unix led to, among other things, Linus Torvalds’ Linux. The work has without a doubt made Ritchie one of the most important, if not under-recognized, engineers of the modern era.

His work, specifically in relation to UNIX, led to him becoming a joint recipient of the Turing Award with Ken Thompson in 1983, as well as a recipient of the National Medal of Technology in 1998 from then-president Bill Clinton.

Source: techcrunch.com