닌텐도 스위치, 소니 플스 FreeBSD를 사용하다.

FOSS|2019. 8. 16. 05:10

 

약간 오래된 발표자료이긴한데, FreeBSD의 현재에 관해 잘 알 수 있는 발표다. FreeBSD가 리눅스 만큼은 아지만, 여전히 산업계에서 많이 쓰이고 있다는 사실을 알 수 있다. 특히, 일본회사에서 많이 쓰는데, 소니 플레이스테이션 닌텐도 스위치가 대표적인 예이다(비디오에서 17:45를 보자). 리눅스는 커널을 고치면 공개해야 하지만 FreeBSD는 그럴 필요가 없어서 뭔가 해킹의 위협에 늘 시달리는 게임기 업체들이 많이 쓰는 것 같다.

댓글()

Intent to Implement: WebGPU

WebKit|2018. 6. 12. 16:40

드디어 WebGPU를 Chromium에서 구현하나 보다. (관련글)


다음은 bink-dev에 올라온 글의 일부이다. 애플이 WebKIt에 Metal을 이용해서 만든 WebGPU와 얼마나 비슷한지 궁금하다. 같은 이름인 것으로 보아 애플의 제안이 많이 받아들여진 것 같다. 


Spec:

Work-in-progress IDL: https://github.com/gpuweb/gpuweb/blob/master/design/sketch.webidl

The “GPU for the Web” community group is approaching resolution on most-high level issues, but hasn’t looked at the detail or user-experience of the API yet.


Summary

The WebGPU API is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It will provide modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is being developed by the “GPU for the Web” W3C community group.


Motivation

Applications on the Web are becoming ever more interactive, which increases the demand for programmable 3D graphics, image processing, and GPU access in general. WebGL and WebGL 2 fulfill some of this demand, but do not match the features or performance of modern native graphics APIs.


WebGPU will close the gap in terms of performance, and introduce “GPU compute” functionality to the Web. This will help porting native applications to WASM that require native features, and will unlock the performance of GPU-accelerated scientific computing on the Web (including machine learning).


In addition WebGPU will give developers more predictable performance by being in the style of “explicit GPU APIs” and by being designed to map efficiently on all modern native graphics APIs.

댓글()

Code Reading 남들이 짠 코드 읽기...

기타|2018. 5. 6. 14:16

처음 개발자로서 일할때는 모든 프로젝트가 정말 바닥부터 코딩을 했다. 한마디로 main으로 코딩을 시작했다. 이런 코딩은 아주 재밌다. 내가 모든 것을 지배하니까..
그런 즐거움도 잠시 대기업이 들어간 이후 부터 지금까지 남들이 짜 놓은 방대한 코드에 뭔가 기능을 구현해야했다. 이때 부터 본격적인 코드 읽기가 시작되었다. 방대한 코드를 이해하는 것은 쉽지 않다. 그냥 코드만 읽어서는 절대 이해할 수 없는 것이 코드 읽기다. 오죽하면 Code Reading이라는 책도있다.  그래서 지금까지 경험한 것을 잠깐 공유하려고 한다.

1. gdb로 step into를 통해 프로그램 동작을 이해한다.
call graph를 복사해 놓고 sequence diagram을 그려 놓으면 좋다. 이것을 바탕으로 class diagram을 그려놓고 프로그램 전체 구조를 이해한다. 그리고 layered architeture diagram을 그려 놓는 것도 좋다.

2. 버그를 잡는다.
오픈소스인 경우 버그를 잡아본다. 그러면서 코드를 이해한다. 버그를 잡은 경우에는 어떻게 잡았는지

잘 문서화 해 놓는다

. 이렇게 여러군데 버그를 잡다보면 부분 부분 이해가 늘어나고 어느새 전체 구조를 이해하게된다.

3. 기존 문서나 비디오 등을 꼭 본다.
기존 개발자가 만들어 놓은 기술 문서, 기술 토크 비디오를 찾아서 질리도록 본다. 사실 코드가 자주 바뀌지만, 대부분 경우, 문서가 자세한 경우가 드물기 때문에 좀 오래된 문서들도 도움이 된다.

4. 프로젝트내에 있는 작은 데모, 테스트케이스 코드를 본다.
이들 프로그램은 꼭 필요한 코드만 담겨져 있어서 이해가 쉽다.

5. Design Pattern에 익숙해진다.
많은 프로젝트가 익숙한 Design Pattern을 사용한다. 디자인 패턴에 익숙할 수록 코드 이해가 빠르다.

6.  Concurrent programming, IPC에 익숙해진다.
Chromium이 Multiple Process Model을 도입한 이후, 프로그램 동작을 이해하기가 까다로워졌다.

7. API에 익숙해진다.
당연한 이야기지만, 윈도면 윈도 API, 유닉스면 POSIX API에 익숙해져야 한다..

8. Domain knowledge에 익숙해진다.
웹브라우저를 개발한다면, 웹기술에 익숙해져야 하듯이, 게임을 만든다면, 게임 자체를 이해해야 한다.

9. Refactoring을 해본다.
한동안 Blink Editing component을 기여한적이 있었다. Chromium 코드 가운데 복잡하기로 악명 높은 코드다. 여러 사람이 개발을 했고 Editing API가 표준화가 덜 된 탓도 있다. 어찌되었던 이런 시도는 코드 건강에 좋다.

지금 끝도 없는 방대한 코드를 보려다가, 그냥 두서 없이 정리해보았다. 자 이렇게 남의 코드를 볼 노력으로 그냥 나만의 프로그램을 만들자. ㅎㅎ

참고로 읽어본 글

댓글()

리눅스 크롬 브라우저 File-picker 드디어 modal 지원

WebKit|2016. 12. 10. 05:00

크롬 브라우저 55 부터 file-picker가 modal로 뜹니다. 그전까지는 modal이 아니라 오동작하는 경우가 많았습니다. 대표적인 경우가 gmail에서 file attach하다가 다른 페이지로 이동할 수 있었지요. 실수로 이런 경우가 많았나봅니다. 처음 버그 수정 부터 계속 patch를 다듬고 reviewer를 위해 기술문서도 작성하는 등, 실제 patch가 반영되는데까지 1년이 넘게 걸렸습니다. 몇 번 land되었다가 2번 revert되고 이후 regression만 3번 정도 있어서 이 부분도 수정해야했습니다. 이번주에도 regression하나 수정했습니다. 직접적인 버그는 아니였지만.. gmail팀의 지원 사격이 없었으면 아직도 이 patch는 림보에 빠져서 영원이 못나올 뻔 했습니다. 어찌되었던 기쁘군요.


관련 버그


Patch

  • https://codereview.chromium.org/1624793002
  • https://codereview.chromium.org/2398723002/
  • https://codereview.chromium.org/2418733004/
  • https://codereview.chromium.org/2554133003/




댓글()

크로미움 프로젝트 커미터 (Chromiun Project Committer)

FOSS|2016. 11. 6. 04:33

얼마전 크로미움 프로젝트 커미터(Chromiun Project Committer)가 되었다. 프로젝트에 기여한지 3년이 되었지만, 사실상 다른 업무로 많은 기여를 하지 못했다. 올해 어느 정도 여유가 생겨서 평소에 관심이 있었던 Blink엔진의 Editing 부분에 집중적으로 기여했다. 

어느 오픈소스 프로젝트나 커미터가 되려면 많은 노력이 필요하다. 어떻게 보면 쉽고 어떻게 보면 어렵다. 크로미움 프로젝트의 경우, 주요한 10개의 patch를 기존 커미터들이 평가하는데, 반대 없이 3명 이상의  +1을 받아야 한다.  기여한 patch의 개수는 중요하지 않다.  실제 버그를 수정하고, Feature를 개발하고 성능을 높이고, refactoring도 큰 수준으로 해야 다른 커미터로 부터 커미터 지명을 받을 수 있다. 사실 구글 직원이 아니면 이런 기여를 하기가 쉽지 않다. 누가 멘토를 해주는 것도 아니고, 자기 스스로 문제를 찾고 feature를 개발해야 하는데, 구글의 허락 없이는 feature를 추가하는 것은 불가능하다. 주요 feature들은 이미 Googler들에게 할당되어 있기 때문에 새로운 분야를 찾는 것 역시 어렵다. 그래서 가장 쉬운 것이 버그를 잡는 것이다. Issue Tracker에 등록된 버그를 해결하는 것이 빠른 일이지만, 사실상 Googler들이 해결 안하는 버그들 역시 고치기 어려운 것이 대부분이다. :-( 하지만, 기역할 분야를 결정하고 하나 하나 버그를 잡다보면 코드를 이해하게 되고, 비슷한 버그를 쉽게 수정할 수 있다. 이때, 가능한 많은 사람들이 관심을 가져주는 급한 버그를 해결하면 더 의미가 있다. 아래는 이번에 커미터가 되기 위해 제출한 주요 patch 목록이다.

Blink Editing

  1. [Issue 226941] Contenteditable issues related to backspace handling
  2. [Issue 318925] Copy and paste sometimes removes spaces between words
  1. [Issue 310149] ContentEditable:   is forced on SPACE between text nodes
  2. [Issue 335955] Unwanted spans inserted in contentEditable elements
  3. [issue 571420] chrome hangs on when creating bullet list in contenteditable
  1. [Issue 634482] Formatting tags converted to spans with styles on cut/paste
  2. [Issue 625802] Unnecessary quote appears after clicking on indent more option in compose box.
  3. [Issue 582225] document.queryCommandState isn't working well with <sub> and <sup>
  4. [Issue 584939] document.queryCommandState returns true for bold, italic, underline, and strikethrough after selecting image
  5. [Issue 385374] queryCommandState can return true for both list types
 

Linux and Wayland support

  1. [Issue 408481] System dialogs (e.g. 'Save As...') are not modal on Ubuntu
  2. [Issue 473228] Make *::ShowWithWindowState(minimized, maximized, fullscreen) consistent across platforms
  3. Issue 578890 upstream wayland backend for ozone

한국인 크로미움 커미터는 이미 9명이 있다. 많은 대기업에서 크로미움 기반으로 브라우저를 개발하고 있어서 그 수가 많은 편이다.  이렇게 다양한 사람들이 함께 내가 사용하는 웹브라우저를 개발한다는 것이 오픈소스가 주는 매력이 아닐까 싶다. 지금 이 순간도 수 많은 사람들이 크롬 브라우저에서 문서를 편집할 때 마다, 내가 추가한 코드가 실행된다고 생각하면 개발자로서 이 보다 보람찬 일은 없을 것이다.

댓글()

Crosswalk을 소개한 블로그글

Web|2016. 3. 31. 02:14

오픈소스의 가장 큰 장점은 외부로 부터 참여를 이끌어내는 것이다. 일반적인 참여 방식으로 버그 찾거나 잡는 것이 있지만, 프로젝트를 소개하고 사용법을 알려주는 글도 프로젝트를 운영하는 사람들 입장에서 큰 도움이 된다. 우연찮게 Crosswalk을 소개한 블로그를 찾게 되었다. 단순히 소개만 한 것이 아니라 집적 patch를 올린 과정도 상세하게 소개해서 오픈소스에 프로젝트 기여하고 싶은 개발자에게 도움이 될 것 같아 여기 소개한다.


댓글()

오픈소스 코드 문서화가 어려운 또는 쓸모 없는 이유

FOSS|2013. 3. 20. 01:30
많은 개발자들이 Open Source Project에 참여하기 어렵다고 불평하는 것 중 하나가 문서화다. 방대한 코드에 버그를 수정하고 기능을 추가하는 일은 쉽지 않다. 그래서 Code에 대한 어느 정도 문서화나 안내서가 있으면 좋은데, 그런 문서를 찾기가 쉽지 않다. 있다고 하더라고 오래된 문서들이다.

왜 그럴까? WebKit Project에 참여하는 입장에서 생각해보면, 코드가 너무 빠르기 변경되기 때문에 문서화하기 어렵다고 이야기할 수 있다. 어느 정도 대략적인 문서화(요구사항 및 디자인 문서) 정도는 가능하지만, 실제 구현된 내용을 Class 수준으로 이야기하는 것은 어려운 일이다.  가능은 하지만, 글쎄, 한달 정도 지나면 Class 코드에 많은 부분이 변경되어 있을 것이다. 실제로 WebKit2의 Hardware Acceleration 코드인 Coordinated Compositing를 분석하고 문서화하려고 노력하고 있는데, 지난 몇 달간 없어진 Class도 있고 Class이름은 대부분 변경되었고, UI Process와 Web Process간의 message도 절반이상 제거되었다. 개발자들이 끓임없이 refactoring하기 때문이다. 일반 프로젝트에서는 refactoring은 잘 하지 않는다. 일단 기능이 구현되어 정상 동작하면 그만이기 때문이다. 하지만, Open Source Proejct는 다르다. 잘 동작하는 기능이라고 하더라도 좀 더 이해하기 쉬운 code를 만들기 위해서 끊임없이 Refactoring을 한다.

이런 상황에서 개발자는 code를 문서화하기 보다는 보다 이해하기 쉽고 간결한 code를 만들기 위해 노력한다. Class, variable, method이름 하나 하나가 제대로 지어졌는지 또 생각하고 의미가 명확한 이름으로 바꾸려고 노력한다.

오랜 시간을 들여 상세하게 문서화를 하려고 했던 나의 시도는 결국 실패하고 말았다. Code를 이해하고, 변경되지 않는 핵심 부분을 문서화 하는 것은 좋다. 하지만, 가장 좋은 문서화는 바로 쉬운 Code를 작성하는 것이다. 가끔 주석으로 설명된 문장들이나 그림들이 성경의 한 구절처럼 느껴질 때가 있는데, 이런 것들이 진정한 문서화 같다.


Source: https://joone-foss.blogspot.com/2013/03/blog-post.html


댓글()

Ubuntu의 새로운 Display Server, Mir

카테고리 없음|2013. 3. 13. 19:13
Canonical이 Ubuntu에서 Wayland대신 새로운  Display Server인  Mir를 개발하겠다고 발표하여 인터넷이(lwn.net, Google Plus) 뜨겁게 달아오르고 있다.

Intel주도로 X-Window를 대체하는 Display Server Protocol인 Wayland와 Window & Compositing manager인 Weston 이개발되고 있다. Mobile기기에 리눅스 적용이 확대되고 GPU, Touch Interface가 기본으로 적용되면서 X-Window를 개선하기 위한 많은 노력들이 있어왔다. 하지만, X는 proxy역할만 할 뿐 많은 기능을 compositing manager가 하고 있고, X가 하던 mode setting등과 같은 기능은 커널로 옮겨갔다. 이미 Android도 X-Window 대신 자체 개발한 Window Manager를 사용한다.

Canonical이 Ubuntu에서 Wayland를 사용하겠다고 발표하는 등 X를 대체하는 de-facto표준으로 자리를 잡나 싶었는데, Mir의 발표 소식은 많은 오픈소스 개발자를 어리둥절하게 만들었다.  이유라는 것이 Wayland의 input기능 확장이 어렵다는 것인데, Wayland 개발자들은  Waylnad는 충분히 Ubuntu의 요구사항을 만족하고 있으면 문제가 없다고 대응하고 있다.

Ubuntu가 너무 커버렸나? 어찌돼었던 그들은 Desktop보다는 Mobile에 집중하면서 Wayland로 대응하기 늦다고 생각했던 것 같다. 하지만 이미 Wayland는 Android에서 동작하고 있다.

새로운 시도라면 나쁘지 않지만, 비슷한 것을또 다시 개발하겠다는 것은 시간의 낭비가 아닐 수 없다. Unity를 보라. GNOME Shell에 비하면 무엇이 좋은지 알수가 없다. 물론 Wayland개발이 좀 느리다는 비판도 있었다. 하지만, Wayland Proejct에  함께 참여해서 발전시켜나가도 늦지 않았을텐데, 여로모로 아쉬운 결정이다.

Display Server는 중요한 컴포넌트의 하나이다. 지금까지 Open Source Desktop이 발전할 수 있었던 것은 X-Window라는 de-facto표준이 있었기 때문이다. 이런 표준이 깨지면, Client Application의 호환성을 유지하기가 상당히 어려워진다.

다음 세대 Display Server를 위한 경쟁은 이제 시작되었다.

댓글()