[ 필수문제 1번 ]
UDP로 reliable transport 만드는 그 자체로 이미 금기인데..... - _-);;;;
그리고 TCP가 꽤 잘만들어진 물건이라, 하나 고치면 하나 빵꾸남.
예를들어 나는 TCP checksum 관련한 문제를 많이 봤어.
TCP가 IP주소를 차용한 덕에 추상화 계층 침범으로 터널링 때 체크섬 미갱신 문제가 빵빵 터진다던지,
이더넷 프레임 CRC하고 중복되어 연산/전기 낭비다, 뭐 이런 문제점이 있어.
그래서 이걸 없앤다고 가정해보자.
그러면 중간에 CRC를 제대로 처리 안하는 하드웨어가 있다던지
뭔가 기상천외한 물리/데이터링크계층을 쓰는 곳이 있다던지 하면
그 구간 내에서 데이터 손실이 났을 때 검증이 안되는 문제점이 있음.
뭐 이런 느낌으로 푸는 문제 ㅇㅇ
[ 필수문제 2번 ]
시대가 시대이니만큼 EFI+GPT로 가자.
전원버튼 → NVRAM 설정값 로드 → EFI 파티션 검색 → EFI 상의 바이너리(부트로더) 검색 및 실행 → 커널 로드 → 기본 서비스 시작 및 드라이버 로드
참 쉽죠?
이게 BIOS의 경우에는
CPU 초기와 직후 HDD에 저장된 MBR을 7C00로 복사라던지 하는 과정이 있고
문제 키워드에 인터럽트 초기화 관련해서 적으라는 것 같은데,
솔직히 어디까지 적으라는건지 잘 모르겠음.
너무 답이 열려있어서 그냥 버려두긔.
[ 필수문제 3번 ]
SQL은 뭐다? 언어.
NoSQL은 CRUD 못하나? 다 하지.
그래서 NoSQL 서버에 SQL로 프론트엔드 단다고 생각하고 하면 못할건 없음.
문제는 인덱싱이나 join 같은 부분에서 성능이 잘 안나올뿐...
근데 NoSQL의 용도나 설계를 고려해볼 때,,, 이건 뭘 해도 절대로 빠르게 안되;;;
범위를 넓혀서 프로시져 같은걸로 가면 골치아픈데
Mongo 같은건 서버단에 JS 함수 저장 가능함.
카싼드라는 백엔드로 돌리면서 살짝 만져본게 전부라 자세히는 모르겠음.
[ 필수문제 4번 - 셀프문제 ]
생략.
이런건 문제라기 보다는 짧은 에세이를 쓰라는 걸로 들리는데...?;;;;
[ 선택문제 1번 ]
테이블에 무게 m이고 마찰계수 u(정지), v(운동)인 쇠붙이와
고정된 자석이 서로 d만큼 떨어져있다고 할 때,
알짜힘 F(m, u, v, d) > 0 을 d에 두고(?) 풀어서 나온 식을 코드로 짜면 된다...는게 일단 정론인데....
이게 문제를 보건데 u와 v가 상수가 아니라 u(x,y), v(x,y)로 두고 풀라는 소리같긴 하다.
근데 이게 컴퓨터공학 문제는 아닌데.....? - _-)?????
[ 선택문제 2번 ]
그래서 문제를 푸는데,
객체지향 = C/C++/Java,
함수형 = LISP/ML/Haskell
이렇게 가정하고 쓸게.
- 자동차 ECU - 객체지향 - 실시간 처리 유닛으로 자원 요구량 최소화 필요
- 네트워크 라우터 (router) - 객체지향 - 시간요구조건 충족이 우선
- Android 와 같은 Operating System - 객체지향 - 전력소모량, CPU타임 등 자원량 최적화 필요
- 하이패스와 같은 통행료 징수 시스템 - 객체지향/함수형 - 특별한 요구사항 없음
- 비행기 오토파일럿(Auto-pilot) 시스템 - 객체지향 - 소프트웨어 실행절차 검증 필요
- 기차표 예매 시스템 - 객체지향/함수형 - 특별한 요구사항 없음
객체지향이 많은 이유는,
함수형은 LISP이나 Haskell이나 아직 업계차원의 경험이 부족해서,
돈버는데 쓰라고 추천은 못함...
다만 Lisp의 경우엔 메타프로그래밍을 이용한 생산성 극대화를 꾀할 수 있고
하스켈은 무결점 프로그래밍으로 소프트웨어 에러를 대폭 줄일 수 있는 장점이 있음.
기타 등등.
지구는 둥그니까~
근데 타원
타원 위의 점과 중심점 간의 거리를 d라고 두고
F = m1*m2/(d^2) 하고,
이걸 중력가속도 g로 나누면 체중이 됨. ㅇㅇ
근데 내가 위도의 수학적 정의를 몰라서 여기까지 밖에 못하겠다.
어차피 시험장에 가면 상수라던지 이런 것도 안주잖아?
버려버려.
그런건 함수 인자로 받아먹는다고 해 ㅇㅇ
오랜만에 저 자짤 붙여봄 _-_)ㅋㅋㅋ
글 잘 봤습니다. 근데 하스켈의 언어명세에는 템플릿 메타 프로그래밍은 정의돼있지 않습니다. GHC의 확장기능 중 하나로 지원되는데 하스켈 커뮤니티에선 흑마술 취급하는 기능이더라고요. 더불어 C++의 메타 프로그래밍은 튜링완전한 능력을 가지고 있기 때문에 문제가 뭔진 모르겠지만 오히 c++이나 리습이 적당해면 적당했지 하스켈을 컴파일타임 계산용으로 사용하
근데 이거 넥슨 문제 맞아?
모던(?) 하스켈 언어 명세는 GHC 이식체 그 자체라고 하는 슬픈 현실이라... 사실 그래서 나도 하스켈 버렸으빈다 ㅇㅇ 하스켈 컴파일러 둘은 못나와요.
는건 기행이라고 생각합니다. 그리고 순수 함수형 언어인 하스켈도 객체지향, 절차형 프로그래밍을 할 수 있습니다. 둘 다 언어단의 지원이 아닌 라이브러리단에서 가능한데요. 객체지향은 Lens를 사용하면 되고(수학적으로도 일관된 접근방식입니다.) 절차지향은 Prelude (기본 라이브러리)의 Monad 타입 클래스를 사용하면 됩니다. GHC에서는 모나드의 사용
을 돕기위해 do-notation같은걸 지원하기도 하지만 단순한 syntactic sugar일뿐이고 결국 중심에 있는건 모나드입니다.
짤줍 ㅎ
GHC가 플래그십 컴파일러인데는 이견이 없지만 그게 하스켈을 버려야할 이유인 데에는 납득할 수가 없네요. 오라클 JVM안쓰는 자바 개발바들의 비율이 얼마나 되는지를 생각해보면 de facto컴파일러의 존재가 언어의 성패를 좌우하진 않는다고 생각합니다.
아니 GHC를 버리니까 하스켈 컴파일러가 남지 않았을 뿐입니다. 이건 단순히 언어를 넘어서 코드 관리 및 엔지니어링적 측면을 고려한 결정이기 때문에 놔두세열
그리고 template haskell이 흑마법이기는 하지만 오히려 C++ 메타프로그래밍보다는 훨씬 깔끔하죠. 그리고 이미 작성된 모듈을 TH로 끌어들이는 식으로 작업하면 작성도 크게 어렵지 않습니다.
뭐 저도 갓칠도사님을 가만히 안내비둘(?) 생각은 아니었습니다. 근데 GHC 말고도 하스켈 컴파일러가 있긴 합니다. HUGS, UHC등인데여 GHC에 비해 개발도구의 지원이 적고 퍼포먼스가 떨어지지만 하스켈의 언어명세 구현엔 충실했다고 생각합니다. 자꾸 비교해서 그렇지만 자바도 마찬가지 아닌가요?
그리고 Lens가 OOP라는건 금시초문이라 신기해서 찾아봤는데, 딱히 그런식으로 설명이 나오지는 않습니다.
하스켈 커뮤니티가 좀 안좋은게, 타 컴파일러에 대한 관심이 지나치게 적다는 점입니다. GHC에서도 상생이 불가능한 방향으로 모든 하스켈 코드와 작업환경/커뮤니티를 변화시키고 있어서...
Lens는 읽기 쉬운 문서가 몇 없고 만든 사람의 ppt와 음질구린 소개 동영상 등이 많다는게 단점입니다. (어쩌면 하스켈 전반적으로 그럴 수도...?)
http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html
여기가 그나마 쉬워보입니다. 하스켈에서는 보통 객체를 인코딩하는 방식으로 레코드를 사용합니다. 근데 하스켈의 Nested Record의 안쪽 레코드를 수정하는 문법은 자바만큼 끔찍한데요. Lens는 이런 불편을 라이브러리단에서 해결해줍니다. 제가 말한 수학적 일관성이란 Composability였는데요. 함수형 프로그래밍 언어의 라이브러리 답게 렌즈와 다른 렌즈를 조합해서 새로운 렌즈를 만드는게 자연스럽고 Sound합니다.
타 컴파일러에 대한 관심이 지나치게 적다는 건 생각해보지 못했는데... UHC나 HUGS관련된 글을 자주 못 본거 같긴 합니다. 그나마 기억나는게 GHC의 복잡성때문에 하스켈을 가르치기가 어려워서 우리는 UHC로 하스켈을 가르친다 같은 내용이었는데 달린 댓글이 그럼 GHC에서 추가기능 다 끄고 Haskell2010 명세만 사용하게 하면 되지 느리고 도구의 지원도 적은 UHC를 사용할 필요가 있는거냐 등이었습니다. 또 하스켈은 아니지만 순수 함수형 프로그래밍 언어인 Agda의 백엔드로 UHC를 사용한다는 글입니다. 링크는
http://www.staff.science.uu.nl/~swier004/Publications/UtrechtAgdaCompiler.pdf
여기 있습니다.
상생이 불가능한 방향이라는게 어떤 방향인지는 잘 모르겠지만 GHC가 LLVM처럼 하위호환성 다 부수고 새로운 혁신을 만들고 있는건 사실입니다. 가장 최근에 일어난 기억나는 변화는 Functor-Applicative-Monad Proposal이고(근데 이건 Haskell 2014의 변동사항이긴 합니다.) GHC 8.0에 포함될 레코드 필드 오버로딩, Injective Type Families (Dependent Type 도입의 초석입니다.) 등이 있습니다.
음음;; 제가 하스켈을 모르는 것도 아니고 어느정도 써봤고, lens도 써봐서 뭔지는 다 압니다;;; HUGS는 시도는 좋았는데 이젠 한물 간 프로젝트고, UHC는 가장 좋은 대안이지만 아무리 잘 봐준도 해도 GHC에 비교하기는 좀 힘듭니다;; 그리고 하스켈에 문서가 없다는건 진짜 동감하는데, 어차피 타입이랑 이름만 맞춰도 얼추 돌아가는 동네라서 _-_)ㅋㅋㅋㅋ
도사님 오랜만이십니다.
리눅스에서 dll 인젝션 어떻게 쓰나요?
이 글을 읽고 꼬추가 폭발했습니다..
말은 쉽게하지 겉핥기식으로 써놨구만 니가 저거 정교하게 보고서 식으로 쓴다고 해봐 쓰지도 못할거같은데
개나소나 니처럼 씨부리기는 쉬워
야이뇬아 제목은 읽었냐. 그리고 저거 쓰는데도 30분 걸렸어. 너처럼 개나소나 씨부리기는 참 쉼죠잉? 응?