반응형

아이언 맨 골수 팬이 제작한 아이언맨 슈트입니다.

놀랄만큼 정교하고, 여러가지 기능도 포함이 되어있더군요.

멋진 슈트 였습니다. 

아래 동영상과 이미지를 링크 했습니다.



사진=앤서니 리가 제작한 수트(위), 영화 ‘아이언맨’ 포스터








반응형
system 내의 binary 호환성을 갖추기 위해서는 가장 먼저 고려해야 할 사항이 바로 ABI를 맞추는 것이다.
 
ABI 란? 
Application Binary Interface 의 약자로, 바이너리(binary), 즉 실행파일이나 라이브러리 간의 저수준(low level)의 인터페이스를 의미합니다.
호출형식이나 데이터 형식이 동일한 모듈들끼리만 모듈내의 함수 호출이나 데이터 사용이 가능해 지는 것이 당연하겠죠?
 
ABI를 결정하는 가장 큰 요소는 Compiler입니다. 
C++ Compiler의 경우, 각 compiler별로 name mangling 규칙이 다른데요.
이때문에 서로다른 compiler에서 만들어진 바이너리간의 호출이 불가능해질 수도 있게 됩니다.
                 name mangling 참조  
 
Compilervoid h(int)void h(int, char)void h(void)
Intel C++ 8.0 for Linux _Z1hi _Z1hic _Z1hv
HP aC++ A.05.55 IA-64
IAR EWARM C++
GCC 3.x and higher
Clang 1.x and higher[3]
GCC 2.9.x h__Fi h__Fic h__Fv
HP aC++ A.03.45 PA-RISC
Microsoft Visual C++ v6-v10 (mangling details) ?h@@YAXH@Z ?h@@YAXHD@Z ?h@@YAXXZ
Digital Mars C++
Borland C++ v3.1 @h$qi @h$qizc @h$qv
OpenVMS C++ v6.5 (ARM mode) H__XI H__XIC H__XV
OpenVMS C++ v6.5 (ANSI mode)   CXX$__7H__FIC26CDH77 CXX$__7H__FV2CB06E8
OpenVMS C++ X7.1 IA-64 CXX$_Z1HI2DSQ26A CXX$_Z1HIC2NP3LI4 CXX$_Z1HV0BCA19V
SunPro CC __1cBh6Fi_v_ __1cBh6Fic_v_ __1cBh6F_v_
Tru64 C++ v6.5 (ARM mode) h__Xi h__Xic h__Xv
Tru64 C++ v6.5 (ANSI mode) __7h__Fi __7h__Fic __7h__Fv
Watcom C++ 10.6 W?h$n(i)v W?h$n(ia)v W?h$n()v
 

 

ABI는 calling convention,  데이타 타입, 사이즈(size),argument , 등등에 대한 내용이 있습니다.

 

인텔의 경우 iBCS라는 인텔에서 정의한 표준을 정의 하고 있습니다.

 

 

 

 
 
EABI 란 ? 

Embedded ABI 

 

 

EABI( 임베디드 애플리케이션 바이너리 인터페이스 )는 임베디드 운영 체제 와 함께 사용하기 위한 파일 형식 , 데이터 유형, 레지스터 사용, 스택 프레임 구성 및 임베디드 소프트웨어 프로그램 의 기능 매개변수 전달에 대한 표준 규칙을 지정합니다 .

EABI를 지원하는 컴파일러는 다른 컴파일러에서 생성된 코드와 호환되는 개체 코드를 생성하므로 개발자는 한 컴파일러로 생성된 라이브러리를 다른 컴파일러로 생성된 개체 코드와 연결할 수 있습니다. 자체 어셈블리 언어 코드를 작성하는 개발자는 호환 컴파일러에서 생성된 어셈블리와 인터페이스할 수도 있습니다.

EABI는 임베디드 시스템의 제한된 리소스 내에서 성능을 최적화하도록 설계되었습니다. 따라서 EABI는 복잡한 운영 체제에서 커널과 사용자 코드 간에 이루어지는 대부분의 추상화를 생략합니다. 예를 들어, 더 작은 실행 파일과 더 빠른 로딩을 허용하기 위해 동적 연결을 피할 수 있으며, 고정된 레지스터 사용을 통해 더 컴팩트한 스택과 커널 호출을 허용하고, 권한 있는 모드에서 응용 프로그램을 실행하면 장치 드라이버를 호출하는 간접적인 작업 없이 사용자 지정 하드웨어 작업에 직접 액세스할 수 있습니다. EABI의 선택은 성능에 영향을 미칠 수 있습니다. 

널리 사용되는 EABI에는 PowerPC , Arm EABI   MIPS EABI 포함됩니다. C 라이브러리와 같은 특정 소프트웨어 구현은 보다 구체적인 ABI 형성하기 위해 추가적인 제한을 부과할 있습니다 가지 예는 ARM GNU OABI EABI이며 ARM EABI 하위 집합입니다.

 
 
Link: en.wikipedia.org
An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.
 
 
 
 
 
 
반응형

Framework 개발에서 조직과 관련된 part article에 재미있는 내용이 있어서 공유합니다.

 

 

Conways Law

- 여러분이 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 여러분은 4단계로 구분된 컴파일러를 얻게 될것이다.

 

이 내용이 무슨 예기인가 하면,

팀 구조가 소프트웨어의 구조가 된다는 것입니다. 따라서 당연히 팀을 구성한 후 요구사항을 분석한다면, 팀 구조에 맞춰 분석이 이뤄지기 때문에, 팀 구조 그대로 소프트웨어 구조가 나올 수 밖에 없다는 예기….

 

때문에 소프트웨어가 어떤 특성을 가지고 있는지 파악되기도 전에 소프트웨어의 큰 구조를 정해버리는 것과 같은 오류를 범한 것과 같다는 의미 입니다..

 

그래서 팀을 구성하기 이전, 프로젝트의 도메인 전문가나 구성원 전체가 모여, 프로세스를 정제한 후에 프로세스에 맞게 조직을 구성할 필요가 있다는 의미입니다.

 

 

[조직 구조에 따른 설계방법]

 

만약, 이미 조직이 구성되어있다면, 조직 구조와 문화를 이해해서 적합한 프레임워크를 구성해야 한다.

 

-       팀의 크기를 고려할 것

만약 프레임워크를 개발하는 팀은 작은 반면에 프레임워크를 사용하고자 하는 팀이 많다면 모든 팀의 요구사항을 들어주기는 거의 불가능하다그렇기 때문에 파레토의 법칙인 80/20 룰에 의거해서 프레임워크를 구성해야 된다. 프레임워크 사용자들이 가장 많이 활용하고 사용하는 부분들을 집중적으로 만들어야 한다.

반면 프레임워크를 구성하는 팀의 여유가 있어, 충분히 많은 기능을 설계할 수 있다면, 많은 요구사항들을 수렴할 수 있기 때문에 모듈간의 일관성을 유지하는데 초점을 두고 구축해야 한다.

일관성을 유지하기 위해서는 끊임없이 프로토타입을 만들고 Feedback을 받아 설계를 정제해야 한다.

 

-       조직의 문화를 고려해라.

만약 조직이 고객중심의 문화를 가지고 있는 화사라면, End-2-End 시나리오들을 먼저 추출한 후 시나리오를 잘 지원하기 위한 형태로 프레임워크를 설계해야 된다.

반면 기술을 중요하게 생각하는 하위 레벨의 회사라면, 기술의 변화를 쉽게 수용할 수 있게 확장성을 중요시 여겨 설계해야 한다.

 

-       조직의 의사 결정 메커니즘을 고려해라.

개별적인 맨 파워들을 중시하는 회사라면 대부분 Time to market을 잘 지원할 수 있어야 되므로 빠른 의사 결정이 지원하는 것에 중점을 두고 설계해야 한다. 또한 계층적인 조직구조를 가진 회사는 서로 간의 이질적인 의사 표현 방법을 통합하고 상호 운영하는데 초점을 맞추어야 할 것이다.

 

 

 

 

반응형


http://www.pcraft.kr/282 

 http://froom.tistory.com/302

Froom.kr

 http://blog.naver.com/hotdog4956?Redirect=Log&logNo=10083199553
핫​독​스​튜​디​오​
     
     
     



'Link' 카테고리의 다른 글

dropbox  (0) 2009.04.30
Palm OS developr link  (0) 2009.02.18
[For M4800] Smart phone , MITs , Window Mobile, Finedrive  (0) 2009.01.30
Nokia wiki  (0) 2009.01.20
반응형

이 글은 미카님의 2010년 5월 20일의 미투데이 내용입니다.

반응형

Lee Loc hyun

Born in suncheon. Korea.

1995 - 1999. BFA at Chonnam National University. Gwangju. Korea.

2000 - 2006. Stay in France

2003. 2005. Ecole Superieur des Art-decoratifs de strasbourg France.

(Diplome National d'Arts plastique) DNAP and DNSEP.

Personal Exhibition

1999. Exhibition support for young artist. Lotte gallery. Gwangju.

Group Exhibition

2009. 'Hug' space Mudaeruk , Seoul

Visitor. (#268-2 Heuk suk-dong dongjak-gu. Seoul. Korea)

Web site : http://visitors.tistory.com

2005. Duo exhibition L'issue Gallery Strasbourg France.

2005. 'Exhibition + Conference?' La Chaufferie Strasbourg. France.

2000. "Womanhood in the world, the world in womanhood"

Shinsegae Gallery. Gwangju.

1999. "A bean in a jar for growing bean sprouts.

If so, in the museum..?" Lotte Gallery, Pusan, Gwangju.

1998. "nouveau salon" Seoulcity art museum.

1998. broken 2842 (between tooth) Kumho Gallery. Gwangju.

1998. Misulsegae Megazine be awarded a special prize.

Sejong culture center, Seoul.


이 록 현 李 綠 賢

1995 - 1999. 전남대학교 예술대학 미술학과 회화전공.

2000 - 2006. 프랑스 체류

2003. 2005. Ecole Superieur des Art-decoratifs de strasbourg France.

스트라스부르그 고등장식미술학교 Art plastique DNAP 과정 DNSEP 과정 졸업.

개인전 - 1999. 젊은작가지원전 광주롯데화랑기획.

주요전시 - 2009. 포옹(HUG)전 . 무대륙 서울

방문자(visitor)전, 서울시동작구 흑석2동 268-2 http://visitors.tistory

- 2005. exposition.duale.Galerie L'issue De Strasbourg France.

- 2005. exposition.groupe et conference La Chaufferie de Strasbourg.

- 2000. "세상속 여성성 여성속 세상성" 광주 신세계 갤러리.

- 1999. "콩나물시루엔 콩 그렇다면 미술관안엔...?"광주.부산롯데갤러리교류전.

- 1998. "nouveau salon" 한,중,일,UZB,VIE, 교류전. 서울시립미술관.

- 1998. broken 이빨사이 광주금호갤러리.광주

- 1998. 미술세계대상수상전 세종문화회관. 서울

- 그 외 다수의 그룹전.





이록현(33) 씨가 광주 동구 대인시장 내 대안 갤러리인 아트 스페이스 MITE에서 오는 20일까지 두 번째 개인전을 갖는다. 
10년 만에 여는 개인전인 만큼 이 씨는 심혈을 기울여 그동안 꾸준히 작업해왔던 회화ㆍ설치ㆍ영상작 등 17점을 선별해 출품했다. 
이번 전시 주제는 존재한다는 것에 대한 물음에서 출발한다. 자연 등 우리 주위를 둘러싸고 있는 것들과 공존하지 못하고 무기력해하는 현대인의 자화상을 표현했다. 
그래서인지 그의 작품들은 그로테스크한 분위기를 풍기며, 우리 존재에 대한 두려움을 곳곳에 암시한다. 앙리 루소의 대표작 ‘잠자는 집시’를 모사한 ‘진부한 사랑’은 정면으로 시선을 향하지 못하는 집시나 그것을 무기력하게 바라보는 사자를 통해 공존의 의미를 되살린다. 
1999년 전남대 회화과를 졸업한 이록현 씨는 2000년부터 2006년까지 프랑스에 거주하면서 스트라스부르그 미술학교에서 석사를 마쳤다. 
유학을 떠나기 전인 1999년 광주롯데화랑의 젊은 작가로 선정돼 첫 번째 개인전을 갖기도 한 유망주이다. 1998년 세종문화회관에서 열린 ‘미술세계대상 수상전’을 시작으로 수차례의 그룹전에 참여했다. 
한편 아트 스페이스 MITE는 지역에서 활동하는 조각가 조승기 씨를 비롯해 김강석ㆍ김민호ㆍ최미연ㆍ양운철ㆍ오민곤 씨 등 서울ㆍ광주ㆍ경상도에서 모인 6명 작가가 의기투합해 만든 젊은 작가들을 위한 대안 전시 공간이다.       









'일상 > 스토킹' 카테고리의 다른 글

Visitor - 전시회 : 이록현  (0) 2009.02.19
반응형




Forgive my poor English.
There is Tmax Window, the 1st windows XP compatible proprietary OS from Korea.
Tmax company showed screenshot of Tmax Windows.
But it is known as they mixed images with real XP and OpenOffice suite screenshots.
http://mr-dust.pe.kr/entry/Tmaxwindow-screenshot-failed
Tmax Window is doubtful about stolen ReactOS source code:
This is a post of a tmax developer.
http://www.ubuntu.or.kr/viewtopic.php?p=28734
' 개발 초기부터 windwos 호환을 생각지도 않고 만들다가 3달 남기고 덕지덕지 붙이고 있는 상황입니다. 그것도 react OS project에 많이 참조하고 있고요. (게다가 react OS는 GPL입니다)'
to English:
In the beginning of development, windows compatiblity is not needed, but 3 months before beta release, patching is being continued. in addition to, Reactos OS project is reference(moreover reactos OS is GPLed)
Tmax changed to a new screenshot and told newspapers not to use old images.
This is new screenshots: http://twinblog.tistory.com/24
I think that Tmax window must be GPL violance.

The beta release date is July 7th 2009.



저 티맥스 OS 만드는 개발자인데요.
I am a Tmax OS developer.

솔직히 저희 OS 별 거 없습니다.
Frankly, out OS is not so cool.

기본적으로 커널은 POSIX 표준을 지원하는 unix-like 시스템이고요. (새로 만들었다고는 하지

만 BSD와 linux 소스를 많이 참조한 것으로 알고 있습니다) 각종 kernel module이나 driver도 

linux나 BSD open source driver을 porting한 것입니다. Windows manager로서는 X server를 

사용하지 않고 자체 개발한 windows manager를 사용하고요.
Basically kernel is POSIX standard unix-like system(newly made, but BSD and linux 

source is kwown as referenced)
kernel module and driver is ported from linux and BSD open source. Windows manager is 

not using X server, but that we made.

문제는 windows binary driver 호환인데요. 출시 2-3달 전에 갑자기 windows binary driver를 

호환하라는 지시가 떨어져서 개고생하고 있습니다.
Problem is windows binary driver compatiblity, before release 2~3 months, order to be 

compatible with windows binary driver, we are suffering as dogs.

이게 어떻게 된 거냐면, 개발 초기에는 linux driver를 사용하고 GDI 같은 API들만 호환한다

고 계획을 잡았습니다.
This it that, in the beginning of development, we outlined to use linux driver and be 

compatible APIs like GDI.

그런데, 출시 3달인가 놔두고 박대연 교수가 windows binay driver를 호환하라는 지시가 내려

져서 지금 windows kernel API까지 전부 호환시키느라 고생하고 있습니다.
But before 3 months before release, Proffessor Daeyon Park(the CEO of Tmax) ordered be 

compatible with windows binary driver, so we are making windows kernel API be 

compatible.

저 도 windows 호환을 중요하게 생각하지만, 어떻게 출시 3달 남기고 그렇게 밀어 붙일 수 있

는지, 참 황당하네요. 개발 초기부터 windwos 호환을 생각지도 않고 만들다가 3달 남기고 덕

지덕지 붙이고 있는 상황입니다. 그것도 react OS project에 많이 참조하고 있고요. (게다가 

react OS는 GPL입니다)
I think windows compatiblity is important. But how can it be possible in 3 months. it's 
absurd. In the beginning of development, windows compatiblity is not needed, but 3 months before beta release, patching is being continued. in addition to, Reactos OS project is reference(moreover reactos OS is GPLed)


제가 생각하는 문제는 핵심 멤버들이 OS에 대한 철학이 없다는데 있습니다.
the matter what I think is core member does not have philosophy of OS.

박대연 교수는 비지니스 마인드나 기술 마인드 모두 훌륭합니다. 하지만 그것을 수행하고 관

리해야 하는 매니져들이 그런 생각이 없어요.

Proffessor Park has good business mind and technology mind. But managers who execute and manage don't have it.

OS를 개발하는데 있어서 windows 호환 같은 거는 가장 처음부터 염두에 두고 계획을 세워야 

맞는 것 아닙니까?
When Making OS, windows compatiblity is planned at first.

지금 상황은 MAC 같은 UI에, linux 같은 범용성에, windows 같은 호환성까지 모두 갖춘 완벽

한 OS를 만들고 있는 상황입니다.
Now we are making perfect OS which has MAC-like UI, linux-like ordinarity, windows-like compatiblity OS.

게다가 주요 코더들은 석사 병특으로 들어온 20대 연구원이고요. 급하게 경력직으로 들어온 

분들은 몇달 안하고 그만 두시더라고요. 병특 1년 반 채운 친구들도 다른 회사로 옮기는 분위

기구요.
Moreover main coders is twenties aged Master of Science researchers as military service.
researchers who came in urgently quits in a few months.
Who finishes military service of 1 year and 6months, moved to other companys.



반응형

요즘 고민하고 공감하는 글이라 스크랩 해왔습니다.


호환성 (Compatibility) 이라는 말을 들어보셨나요?
  • .NET 3.0 버젼 Framework에서 .NET 2.0으로 구현했던 Application이 돌아가지 않는다면?
  • JDK 1.6버젼에서 JDK 1.4 Framework 기반의 Application이 돌아가지 않는다면?

새로 나온 제품이 아무리 좋은 기능이 많이 추가 되어 있더라도..예전 제품과 호환이 되지 않는다면, 그 제품은 잘 팔리지 않을 겁니다. 이번 POST 를 통해 우리가 Product 또는 Framework을 만들때 고려해야 되는 호환성과 여러가지 종류에 대해서 공유하고자 합니다.



Cross-Version Compatibility

 동일한 제품의 다른 버젼에서 만들어진 코드가 호환성을 가지는 지를 언급하는 말로, 예를 든다면 Microsoft SQL 2000에 사용했던 SQL 스크립트가 2005에서도 잘 돌아가는 예를 말하는 것입니다

Backward Compatibilty 와 Forward Compatbility 

하위 호환성 - 하위 제품의 소스,포멧등이 최신 제품과 호환 될때이며, 상위 호환성 - 상위 제품의 소스, 포멧등이 하위 제품과 호환될때를 말합니다.

 

많은 제품들이 하위 호환성은 잘 지원합니다. 예를 든다면 Microsoft Office 2007에서 Microsoft Office 2003이 만든 포멧들과는 잘 호환이 된다고 볼수 있습니다.

하지만 골치 아픈 문제는 상위 호환성인데, Microsoft Office 2007에서 만든 Word , PowerPoint 파일들이 2003에서도 사용할수 있을까요?

아시다시피 두 제품은 완전히 다른 파일 포멧을 가지고 있어서, 2003을 위한 별도의 변환 툴을 제공하여 상위 호환성을 제공할려고 합니다.

단순히 읽기만 되지 편집이 되지 않기 때문에, 완벽한 상위 호환성을 갖추었다고 볼수는 없습니다.

하지만 이 이면에는 또 설계자들이 고려해야 하는 골치 아픈 문제들이 숨겨져 있습니다.

Cross-Redist Compatibiltiy

 서로 다른 제품에서 만들어진 코드가 잘 호환이 되는지.

예) Oracle에서 사용한 Query가 Microsoft SQL에서도 잘 호환이 되는지?

Turbo C에서 동작하던 코드가 Visual C++ 에서도 잘 동작하는지?

Binary Compatibilty

 예전버젼에서 만들어진 바이너리 파일이 새 버젼에서도 재 컴파일 없이 잘 호환이 되는지.

Source Compatibilty

 서로 다른 버젼이지만 변경없이 소스코드 컴파일이 잘 되는지

API Compatibility

 서로 다른 버젼의 API간에 호환성을 제공하는 말로,호환성의 레벨이 Source Compatiblity보단 더 크고, Binary Compatibility 보다는 약한 경우인데요.

Source Compatbility는 입력 파라메터나 리턴값에 공변형 (Covariant) Type을 사용할수 있지만, API는 그러지 못합니다.


 호환성을 버리는 경우..

  • 정책적으로 호환성을 버리는 경우도 있습니다.

혹시 이런말은 들어보신적 있나요? .NET의 적은 JAVA가 아니라. 예전 .NET 이다.

이말의 의미는 .NET  2.0에서도 동작하는 코드가 .NET 3.0 코에서도 잘 동작하기 때문에, 굳이 개발자가 .NET 3.0을 사용하지 않는 다는 말입니다.

.NET 3.0 에 아주 좋은 기능을 넣어 놓아도, 굳이 예전 함수들을 이용해도 잘 돌아가는데 굳이 새로운 기능을 이용할 필요가 있냐? 라는 애기이지요.

물론 JDK 에서도 동일한 문제가 발생합니다.

이것은 새로운 기능을 넣은 Framework 설계자들에게는 상당히 골치 아픈 문제입니다. 훨씬 뛰어난 기능을 추가했음에도 불구하고 하위호환성으로 인해 예전 기능을 그대로 사용하기 때문이지요. 이럴땐 최악의 경우 어쩔수 없이 예전 기능을 포기하기도 합니다.

 

  • 전혀 새로운 패러다임의 등장으로 인해 내부를 다 뜯어 고쳐야 하는 경우를 위해.

이 경우는 아마 VS 6.0과 .NET의 관계이지 않을까 쉽습니다.

Web과 Web Service 라는 새로운 패러다임의 득세로 인해 과감히 VS 6.0 스타일을 버리고 새로운 .NET 을 내놓은 경우입니다.

 

또 PS3와 같이 가격적인 문제로 PS2와 호환이 안되는 제품을 출시한 예와 같이 다양한 이유가 존재할수도 있습니다. 혹시 어쩔수 없이 호환성을 포기할 수 밖에 없었던 다른 이유가 있으신 분은 같이 공유해 주시길 바랍니다.

그 이외에도 호환성에 대한 다양한 이야기가 있으면 Posting 해주시고 트랙백을 부탁드립니다.



Link: http://blog.it-hero.co.kr/blog_post_156.aspx

2008-12-18 14:16:43



+ Recent posts