혹 플래시가 돌아가고 있는 페이지를 띄어놓지 않으셨나요? 제 경험으로는 메모리는 항상 많이 먹는 것 같은데, CPU 점유율이 높을 때는 플래시가 있는 페이지에서 그런 경우가 많았습니다. 파폭 문제인지 플래시 자체 문제인지, 플래시 스크립트를 엉터리로 짜놔서 그런지 알 수는 없지만 여하튼 플래시가 있는 페이지를 닫으면 정상으로 돌아오더군요.
파폭이 문제라기 보다는 국내 사이트들이 문제인 것 같던데요.
윈XP 환경에서의 말씀입니다만..
국내 사이트 돌아다니다 보면 이놈의 여우가 메모리와 함께 동반자살하려는 시도를 가끔 하더군요.
특히 루X웹에서 게임 리뷰 동영상 보다 보면 별별 이상현상이 다 일어납니다;;
심지어는 탭을 늘릴 수는 있는데 닫는 게 안된다거나..;;;
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
인간이 살아가는 환경에 따라 사람이 변하는데 그걸 가지고 "저 사람은 환경하고 상관 없이 --잘못된-- 인간일 뿐이다."라고 자신과 다른 환경에서 살았고 다른 행동을 하는 사람을 몰아 붙일 수 없는 노릇이라고 생각합니다. 웹브라우저도 같다고 봅니다 저는. 잘못 되었으면 잘못 표시하는ㄱ 맞지, 예외 처리를 해서 잘못된 예외까지 무조건 맞게 해야(즉 한국 입맛에 맞게 해야) 제대로 된 프로그램이다 라고 할 수 없다고 봅니다. 분명히 한국의 웹사이트들이 표준을 지키지 않았고 표준데로 출력하도록 만들어 진 프로그램이 그 표준을 지키지 않은 것 까지 책임져야 하고 예외 처리까지 다 해야 한다는건 어거지라고 봅니다.
한국 변호사가 미국에 갔다고 해서 미국 법에 따라 변호까지 다 해야 한다고 하는 것과 같은 말씀을 하시는 것 같습니다. "나는 미국 법을 공부하지 않았고 한국 법만 공부했으니 의뢰를 받아드릴 수 없군요."라고 하는게 뭐가 잘못 된 건지 모르겠습니다.
개발자의 입장, 사용자의 입장... 모두가 중요하다고 생각합니다. 일반 사용자의 입장에서 님의 말씀이 옳을지 모르나, 어떤 방향성을 가진 개발자의 입장에서는 그 말이, 그 생각이 아닐 수도 있습니다.
무조건 관리자와 개발자층을 욕하는 최종 사용자들, 무조건 최종 사용자들을 욕하거나 권력을 남용하는 관리자나 개발자 그룹 또는 기업... 이런건 있어서는 안된다고 봅니다.
제가 이 글을 남긴 이유는 많은 경우에 위와 같은 사고방식에서 제가 위에 있어서는 안 된다고 말씀 드린 두 가지 일이 발생할 수 있는 근간이 되기 때문이었습니다.
인간이 살아가는 환경에 따라 사람이 변하는데 그걸 가지고 "저 사람은 환경하고 상관 없이 --잘못된-- 인간일 뿐이다."라고 자신과 다른 환경에서 살았고 다른 행동을 하는 사람을 몰아 붙일 수 없는 노릇이라고 생각합니다.
비교대상이 잘못되었습니다.
웹브라우저는 OS상에서 돌아가는 프로그램입니다.
프로그램과 인간은 비교대상이 안됩니다.
Quote:
웹브라우저도 같다고 봅니다 저는. 잘못 되었으면 잘못 표시하는ㄱ 맞지, 예외 처리를 해서 잘못된 예외까지 무조건 맞게 해야(즉 한국 입맛에 맞게 해야) 제대로 된 프로그램이다 라고 할 수 없다고 봅니다.분명히 한국의 웹사이트들이 표준을 지키지 않았고 표준데로 출력하도록 만들어 진 프로그램이 그 표준을 지키지 않은 것 까지 책임져야 하고 예외 처리까지 다 해야 한다는건 어거지라고 봅니다.
표준에 맞지 않은 웹페이지를 만났을때
제대로 표시해주는 웹브라우저와 제대로 표시못하는 웹브라우저가 있습니다.
어느 웹브라우저가 우수하다고 볼수있을까요?
당연히 표준뿐만 아니라 비표준 웹페이지까지 아우르는 웹브라우저가 더 우수합니다.
이건 end user 입장뿐만 아니라 개발자 입장에서 봐도 마찬가지입니다.
Quote:
개발자의 입장, 사용자의 입장... 모두가 중요하다고 생각합니다. 일반 사용자의 입장에서 님의 말씀이 옳을지 모르나, 어떤 방향성을 가진 개발자의 입장에서는 그 말이, 그 생각이 아닐 수도 있습니다.
위의 대답과 같습니다만
"표준이 아니라서 못한다"는 개발자보다
비표준이라도 처리해내는 개발자가 더 유능한건 당연한거겠지요.
고객(end user)의 입장에서는 전자의 프로그램은 쓰레기이고 후자의 프로그램은 우수한 프로그램이 됩니다.
Quote:
한국 변호사가 미국에 갔다고 해서 미국 법에 따라 변호까지 다 해야 한다고 하는 것과 같은 말씀을 하시는 것 같습니다. "나는 미국 법을 공부하지 않았고 한국 법만 공부했으니 의뢰를 받아드릴 수 없군요."라고 하는게 뭐가 잘못 된 건지 모르겠습니다.
이것도 비교대상이 잘못되었습니다.
표준과 법을 비교하는건
법과 도덕을 비교하는것과 같습니다.
표준과 도덕은 지키면 좋지만 안지켜도 상관없습니다.
하지만 법은 반듯이 지켜져야만 하는 겁니다.
웹페이지에 스크립트를 잘못써서 무한루프를 생산해낸 웹개발자도 잘못이지만
그렇다고 이런 오류를 웹개발자에게만 미루는게 웹브라우저 개발자의 입장에서 잘하는 것일까요?
"그건 웹개발자의 잘못이지 웹브라우저가 먹통되어도 난 모른다. 나는 표준을 준수하는 웹페이지만 보여주는 웹브라우저를 만들면 그만이다."
이건 아니라고 봅니다.
좀 이야기가 빗나가는 듯하긴한데요...파폭이 느려지는 이유가 프로그램 자체의 결함인지 어떤지는 모르겠지만, 그걸 제쳐두고, 문제가 있는 페이지를 제대로 표시 못하는게 브라우저 개발자가 욕먹어야 할 일이라는건 좀 지나치지 않은가 싶네요.
문제가 되는건 '표준'에 포함되지 않은, 해당 브라우저 전용 마크업이나 자바스크립트등을 이용하는 경우가 대부분이니, 이건 그런 비표준 사양을 이용해서 만든 웹페이지 작성자의 책임아닌가요?
예를 들어 익스전용 사양을 이용한 페이지가 파폭에서 제대로 표시가 안되는게 파폭개발자의 문제라면, 파폭개발자들이 표준에 포함되지 않은 익스전용 사양에는 무엇이있나 다 파악하고, 이것들이 파폭에서 구현가능한 일이라면 되도록 구현할수 있도록 노력해야 하며, 그렇지 않더라도 적합한 처리가 되도록 해야한다는 건데, 이거야말로 넌센스라고 생각합니다.
예를 들어 익스전용 사양을 이용한 페이지가 파폭에서 제대로 표시가 안되는게 파폭개발자의 문제라면, 파폭개발자들이 표준에 포함되지 않은 익스전용 사양에는 무엇이있나 다 파악하고, 이것들이 파폭에서 구현가능한 일이라면 되도록 구현할수 있도록 노력해야 하며, 그렇지 않더라도 적합한 처리가 되도록 해야한다는 건데, 이거야말로 넌센스라고 생각합니다.
파폭에서 익스전용 코드를 모두 처리하라는게 아닙니다.
파폭에서 처리할 수 없는 코드가 있다면 예외처리를 해야하는거 아닐까요?
그런 코드때문에 메모리를 무한대로 먹게되고 먹통되고 어쩔때는 오류내면서 죽어버리는게 당연한건 아닙니다.
예외를 통째로 무시해버리지 않는 한, 예외처리를 할려면 결국엔 어떤 예외인지를 알아야 처리할수 있는거 아닌가요? 사실상 "파폭에서 처리할수 없는 코드=익스전용코드" 인경우가 거의대부분이기 때문에, 결국 그 예외처리를 위해 파폭개발자들은 에서 익스전용코드를 숙지한다음에 똑같이 구현하든 안하든지 간에, 익스용코드를 처리해야할 "의무"가 있다는 것과 다름없는 것이 아닌가..하는 생각이드는데요...동종의 프로그램을 보면서 장점을 받아들여서 프로그램을 개선할 의무는 있을지 몰라도, 명백하게 웹접근성을 저해하는 익스전용코드를 받아들여서 프로그램을 짜맞춰야할 필요가 있을까요?
(x)html도 c도 같은 컴퓨터 언어입니다
C로예를 하나 들어 보지요
char c[-16]:
snprintf(sizeof)c(, c, 'ㄹ%sㄹ', argv(1];
오리님 주장은 이런 것도
char c[16];
snprintf(c, sizeof(c), "ㄹ%sㄹ", argv[1]);
와 똑같이 컴파일 된다는 뜻입니다
위에 있는 코드가 정상으로 보이시나요? gcc에서도 vc에서도 컴파일 안 될겁니다. 저건 코드도 아닙니다.
혹시 저런 것도 컴파일을 해줘야 우수한 컴파일러라고 하시지는 않겠지요?
(x)html도 마찬가지입니다
FF는 (x)html, css, js의 오류, 경고를 다 알려줍니다. 메뉴를 뒤져보세요.
경고 뿐 아니라 메모리도 낭비하지만 오류메시지는 출력합니다
반면, IE는 오류 출력을 안 하고 정상적으로 표시합니다. 바로 이게 문제입니다
위의 잘못된 코드를 컴파일하는 경우가 되겠지요
메모리 문제는 불여우의 문제가 맞지만
레이아웃이 깨진다거나 그런 문제는 페이지의 문제입니다
웹 표준과 IE의 구현 방법이 다를 때 웹 표준을 따라간 것 뿐입니다
'mshtml이 진정한 웹 표준이다!' 라고 하시는 것 같은데 그렇다면 할 말이 없습니다
konqueror에서는 IE 를 따라간것도 좀 있던데요
브라우저마다 해석이 조금씩 다른건 정상인데 IE가 심한게 문제입니다
저 역시 문제는 파폭이라고 생각합니다. 어떤 웹페이지가 표준을 지키지 않고 있다면 그 페이지를 제대로 보여줄 방법은 없습니다. 하지만 그렇다고 프로그램이 이상 현상을 보여서는 안됩니다. 메모리를 마구 잡아먹어버린다던지, 죽어버린다면 문제가 있지요. 잘못된 입력에 대해 예외 처리를 하는 것은 프로그램의 당연한 동작입니다. "이 입력은 처리할 수 없습니다." 라고 사용자에게 알려준다던지, 입력을 무시하던지, 처리할 수 있을 만큼만 처리하던지, 여하튼 분명한 처리를 해야하는 것이지요.
플래시 같은 것은 플레이어가 연관되니 어쩔 수 없다고 해도, 적어도 비표준 html 과 자바스크립트 때문에 파폭이 이상 현상을 보인다면 파폭이 그만큼 품질 떨어지는 프로그램이라는 뜻밖에 안됩니다.
표준을 지키지 않는 다고 무조건 파폭이 제대로 표시못하다는게 아닙니다.
파이어폭스도 표준에 포함되지 않는 마크업들을 호환성을 위해 지원하는 것들이 있으며, 편리를 위해 표준에 들어있지 않은 자바스크립트 역시 지원합니다(사실 자바스크립트 자체가 표준이 아닌걸로 알고 있습니다).
문제는 그 비표준 사양의 대부분이 익스전용이라는 것입니다. 익스전용사양을 처리하기위해서 파폭개발자들이 눈에 불을켜고 익스전용사양에는 무엇이있나 살펴봐야할 이유는 어디도 없는 것 아닌가요?
물론 파폭도 예를 들어 자바스크립트에서 무한 루프에 빠지거나 하면 "더이상 처리할 수 없다"는 식으로 메시지 박스를 띄우는 등 할수 있는 처리는 하고 있습니다만, 설사 소스가 공개되어있어서 어떤 스펙을 어떻게 처리하는지 알고 있다고 해도 그 스펙을 다 파악하기 힘들텐데, 그렇지도 않은 다른 프로그램의 스펙을 전부 파악한다는 것 자체가 무리가 아닐까 생각하며, 파악해야 할 필요도 없다고 생각합니다.
위에도 적었지만, 그러한 익스전용사양이 장점이라면 당연히 받아들여서 개선해야 하겠지만, 분명히 웹접근성을 저하시키는 요소인데, 이걸 일부러 알아서 처리해주어서 웹접근성 향상에 방해되는 짓을 해야할까요...?
인용 - "익스전용사양을 처리하기위해서 파폭개발자들이 눈에 불을켜고 익스전용사양에는 무엇이있나 살펴봐야할 이유는 어디도 없는 것 아닌가요?"
무슨 말씀을 하시는 겁니까? 예외 처리를 하는데 어째서 익스전용사양을 살펴야하지요?
저 아래에 제가 쓴 글 '꼭' 읽어보시기 바랍니다. :)
------------------------
"하고 싶은 이야기" 를 하지 마시고, "화제에 맞는 이야기" 를 하십시오. 도대체 누가 파폭을 두고 "익스전용사양을 처리" 하라는 이야기를 했나요? 문제는 "파폭이 처리할 줄 모르는 입력" 이지 "익스전용사양" 이 아닙니다. 익스 전용 웹페이지에 대해 말씀하시고 싶은 것은 알겠는데, xylosper 님께서 반박하시려는 그 주장을 하고 있는 사람이 아무도 없습니다.
아래글에도 썼지만 "(만약에) 파폭이 비표준 웹페이지 때문에 폭주한다면, 그것은 웹페이지 문제가 아니라 파폭 문제다" 가 xylosper 님께서 답글을 다신 글들이 하는 주장입니다. 그런데 그 글들에 (특히 "나는 오리"님 글에) 여러 말들이 더해지니 이야기가 산으로 가는군요. "나는 오리"님 스스로도 나중에는 산으로 가시는군요-_-; "나는 오리"님은 "처리한다"는 말을 더 신중하게 사용하실 필요가 있을 듯 합니다
------------------------
한 마디면 끝나는 이야기입니다. "프로그램은 어떤 입력에 대해서도 메모리나 CPU 문제를 일으켜서는 안됩니다." myueho 님 말씀처럼 누구나 공감하는 이야기 아닌가요?
xylosper 님께서 하시는 말씀 때문에 여기에 "사족"을 붙이자면 ["처리할 수 있는 입력인가?"를 미리 검사하거나], [처리 중에 "처리 방법을 모르는 예외 상황"이 발생하면 리소스를 잘 반납하고] 부드럽게 마무리하면 됩니다. 모든 가능한 입력을 미리 알아서 대처할 필요가 전혀 없습니다. 이건 개발자 입장에서도 엔드 유저 입장에서도 "기본" 입니다 :)
물론 IE에 맞춰진 사이트를 볼 때 생기는 문제현상에도 대처할 수 있는 것이 우수한 어플리케이션이겠습니다만,
그러한 문제를 순전히 FF쪽에만 떠넘기는 것은
어찌 보면 웹 개발자 분들의 (정확히 말하자면 웹 표준에 대한 개념조차 없는 기획자나 그 윗선..) 오만이 아닐런지요.
웹 개발자 분들이 실력있는 개발자 분들인 만큼 FF의 개발자들도 실력있는 개발자 분들일겁니다.
오히려 제 생각은..
'대부분의 메이저 브라우저에서 동일 내지는 유사하고 문제없는 동작을 하도록 만드는 것'
이 웹 디벨로퍼의 미덕이 아닌가 하는 생각을 합니다.
제아무리 한국이 IT강국이라고 최면을 걸어도,
한글이라고는 알지도 못하는 외국 개발자들이 한국의 IE의존적인 기술을 사용하는 일부 사이트에서 발생하는
극히 예외적인 케이스까지 신경 쓸 이유가 있을까요?
표준이 있는데 그걸 전혀 지키지 않은 자료를 처리하는 과정에서 동작이 완벽하지 않다고 그 어플리케이션 개발자를 욕할 수 있다면
반대로 표준이 있는데도 그걸 전혀 지키지 않는 웹 디벨로퍼도 욕할 수 있다고 봅니다.
(그렇다고 둘 다 욕하자는 말은 아니구요.. ;;;;)
문제는 IE의존적인 기술을 사용하는 사이트들에 의해서 IE의 독점적 점유율이 유지되고, (Lock-in 효과)
그에 따라서 한국 내에서 윈도의 독점적 지위가 보장된다는 점에서 큰 문제가 되는 것이죠.
표준을 지키지 않는 것은 문제가 안 될 수 있지만, 그것이 특정 회사의 이익에 큰 영향을 끼친다면,
상도(특히 공정거래법)적으로 올바르지 못한겁니다. 국가(정통부)의 제재를 받아야 될 사항이 되어야만 하는 것이구요.
그리고 '나는오리' 님의 글 중에서
-----------------------------------------------------------------
표준에 맞지 않은 웹페이지를 만났을때
제대로 표시해주는 웹브라우저와 제대로 표시못하는 웹브라우저가 있습니다.
어느 웹브라우저가 우수하다고 볼수있을까요?
당연히 표준뿐만 아니라 비표준 웹페이지까지 아우르는 웹브라우저가 더 우수합니다.
이건 end user 입장뿐만 아니라 개발자 입장에서 봐도 마찬가지입니다.
-----------------------------------------------------------------
라는 말씀에는 조금 문제가 있다고 생각합니다.
표준에 맞지 않는 건 말 그대로 표준에 맞지 않는 것입니다.
그것이 어떻게 보여야 웹 디자이너가 의도한 대로 보여지는가는 순전히 웹 디자이너가 판단할 일이지요.
그것을 브라우저가 적절히 판단하면 좋겠습니다만, AI도 아니고 말이죠.. 과연 항상 적절하게 판단할 수 있을까요?
결국 저 말씀 대로라면 MSIE에 맞춰서 디자인된(그것도 비표준 마크업을 이용해서) 페이지를
FF나 사파리에서 MSIE에서 보이는 대로 맞춰서 보여지게 해야 한다는 말씀이겠는데..
그 말씀은 MSIE가 de facto 표준이라는 말씀처럼 들립니다. 이거야말로 MS가 원하는 것이겠지요.
브라우저들이 웹 표준에 따른 페이지를 표준안대로 보이게 하는 것. 이것이 브라우저의 1차적 목적이고,
2차적으로 표준에서 벗어나는 페이지를 최대한 잘(읽을만하게)보이게 하는 것, 이것이 2차적 목적이라고 생각합니다만. 틀린가요?
여기서 '읽을만하게'가 'MSIE의 레이아웃을 따라하게'를 의미한다고 해석하는 순간,
디벨로퍼 디자이너건 앤드유저건 MSIE의 독점적 지위를 인정하면서 그걸 표준으로 인정하는 게 되는겁니다.
(너무 강경발언인가요?)
좀 극단적인 예지만, A라는 회사가 있고, 40층짜리 빌딩을 새로 지을 때,
책상 길이가 180cm냐 170cm냐 정도의 10cm차이로도 사무실의 평면 디자인이 통째로 바뀔 수 있습니다.
그리고 그 회사는 특별히 문제가 있지 않는 한, 기존에 사용하던 책상과 다른 사이즈의 책상을 쉽게 구매할 수 없습니다.
표준이라는건 그만큼 중요합니다. 특히 MSIE VS FF 처럼 특정 기업들의 이익에 크게 관계된다면 더 그렇습니다.
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
그리고 처음 글을 쓰신분이 비표준 사이트에 들어 갔는지 아닌지 써놓았던가요?
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
1. 이 글타래를 연 글은 파폭의 이상 현상 에 대한 글이고,
2. 여기에 대해 panickros 님께서는 이상 현상(메모리 문제나 탭 문제)가 잘못된 웹 페이지 때문에 발생하므로 파폭이 아니라 국내 웹사이트들이 문제라는 논지의 답변을 다셨습니다.
3. 그리고 다시 여기에 대해 저를 포함한 몇몇 분이 잘못된 웹페이지 때문에 그런 이상 현상이 발생한다면 그것은 파폭의 문제다.
라고 답을 했습니다. 누가 비표준 웹페이지를 MS 익스플로러에 맞춰서 표시해야한다고 했나요? 몇몇 분이 엉뚱한 말씀들을 하고 계십니다. 혹 "예외 처리"가 프로그래밍에서 무슨 뜻인지 몰라서 그런 말씀들을 하신는 건가요? 프로그래머가 아니더라도 글들의 맥락을 보면 무슨 뜻인지 알 수 있을텐데요? 예외 처리를 익스플로러에 맞춰서 표시하는 것으로 이상하게 해석을 하고 엉뚱한 말씀들을 하시는군요.
지금 글타래에서 논쟁거리인 "문제"가 뭔지, 어떤 글들로 논쟁이 촉발됐는지 다시 한번 읽어보시고, 생각해보시고 글들을 쓰시는 게 좋을 것 같습니다.
지금 논쟁거리는 "비표준 웹페이지에서 파폭이 정상적이지 않은 행동을 하는데 이것은 파폭 문제가 아니라 웹페이지 문제다" 라는 주장입니다.
비표준 웹페이지 문제는 말이 많을 필요가 없는 문제입니다. 어제 오늘 지적된 문제도 아니구요. 하지만 비표준 웹페이지더라도 프로그램이 뻗어버려서는 안되지요. 잘못된 입력에 대한 처리는 "기본"입니다. 컴파일러가 소스코드에 에러가 있다고 뻗어버리면 말이 됩니까? 웹서버에 http 가 아닌 다른 프로토콜로 접속하면 요청을 무시해야지 뻗어버리면 말이 안되는 겁니다. cp 명령에 -bbnhxxx 같은 이상한 옵션을 줬다고 cp 가 메모리를 몇백 메가 잡아먹으면 그걸 사용자 잘못이라고 하시렵니까? 알수 없는 옵션이 들어오면 에러메시지를 출력하고 종료하는게 정상적인 행동입니다. 브라우저라면 처리할 수 없는 웹페이지는 에러 메시지를 내던가, 처리할 수 있는 부분만 처리하고 나머지는 무시하는 것이 정상적인 행동입니다. 어떤 입력에 대해서도 메모리나 CPU 문제가 생겨서는 안되지요.
저건 정말 이상한것 같습니다. 지금까지 4~600 메가 정도까지 메모리를 빨아먹는다는 소리는 많이 들었지만 (물론 이것 만으로도 큰 문제기는 합니다만) 2기가 가까이 먹는 이런 케이스는 제 기억 상으로는 이번이 처음이네요. 이건 파폭만의 문제라고 보기가 힘들것 같습니다. 이 정도로 심각하다면 다른 곳에서도 들어봤을 텐데 말이죠. 확장을 뭘 쓰고 계신가요?
--
"It's too bad that stupidity isn't painful" - Anton LaVey
--
"It's too bad that stupidity isn't painful" - Anton LaVey
플러그인 이름이 정확하게 기억은 안나지만.... 페이지의 에러나 스크립트 정보 기타 등등 정보들을 보여주는 플러그인을
설치한 후 발생 했습니다....
이 플러그인이 특정 웹페이지 ( setTimeOut 같은 함수를 사용해서 계속 뭔가를 하거나, 마우스의 움직임을 이벤트처리를 하는 스크립트가 포함된 ... 등등의 반복적인 작업이 존재하고 파폭에서 볼때 에러가 있는 페이지...) 에 들어가서 조금만 오래 있으면 에러 리포팅이 엄청나게 쌓이면서 결국엔 브라우져가 사망을 하다군요...
때에 따라서는 1분이 될수도 있고 하루가 될수도 있고...
파폭 엔진 자체에도 문제가 있을 수 있겠지만....
님과같은 그런 파폭의 폭주는 플러그인들의 비정상적인 행동일 가능성이 높지 않을까 생각해 봅니다...
"뛰어난 웹브라우저" = "비표준 웹페이지도 잘 보여주기" 는 아니지 않을까요?
비표준 웹페이지는 프로토콜을 지키지 않은겁니다. MS도 참여하는 W3C에서 제정한 규약을 웹페이지가 지키지 않고 IE에서만 어찌어찌 잘 보이니까 그대로 패쓰~ 해버린걸 FF의 탓만으로 돌리기에도 무리가 있다고 생각합니다.
HTML도 SGML인데 데이터 포맷을 어긴것 아니겠습니까? 보통의 C/S기반 프로그램이라면 접속 끊고 GG겠죠 ㅎㅎ
Firefox는 여러 F/OSS의 조합으로 되어 있고 자체 코어도 작지 않습니다. IE와는 달리 여러 플랫폼도 지원해야 하고요. 이런 면에서는 오페라 같은 좋은 브라우저도 있고요.
FF는 의존하는 여러 라이브러리들의 버그도 그대로 안고 있고 자체 코어의 버그도 아직 많이 있습니다.
이러니 메모리릭은 비표준 웹페이지 외에도 어디서든 발생할 수 있죠.
메모리릭을 봐주자는건 아니고 버그없는 프로그램은 없는데 IE도 메모리릭 찾아보면 구글에 한아름;
여튼 FF는 나름의 가치를 가지고 있다고 생각합니다. 비표준 웹페이지로 엮어서 애써 그 가치를 깍을 필요까지는 없다고 생각합니다.
비표준 웹페이지로 엮어서 애써 그 가치를 깍는 사람 없습니다. 거꾸로 비표준 웹페이지로 엮어서 애써 그 가치를 옹호하는 것에 대한 반론이지요. "메모리 릭(과 기타 문제) 이 있는 것은 파폭 문제가 아니라 비표준 웹페이지 문제다." 라고 옹호하는 것에 대한 반론입니다. 이 반론들을 촉발한 panickros 님의 글을 다시 읽어보십시오. 소타님 말씀대로 FF는 나름의 가치를 가지고 있습니다. 그런 식으로 옹호할 필요가 없습니다.
그리고, 다른 글들에서도 반복했지만 "뛰어난 웹브라우저" = "비표준 웹페이지도 잘 보여주기" 가 아닙니다. "기본적인 웹브라우저" = "비표준 웹페이지에서 폭주하지 않기" 입니다.
표준에 어긋나는 웹페이지를 만나더라도 잘못 렌더링 하는 것은 상관 없지만 어플리케이션 자체가 오동작을 하거나 메모리 릭이 생기는 문제는 확실히 비판의 여지가 있다고 봅니다.
그래도 FF가 초기 버전에 비해 지금 이정도 안정화 된것은 많은 오픈소스 개발자들의 노력이고 고무적인 일입니다. 확실히 IE 6은 나온지 아주 많은 기간이 지났고 많은 엄청난 시장 점유율로 버그리포트도 활발하여 서비스 팩과 각종 패치가 적용된 지금 굉장히 안정화 된 브라우져로 인정할 만하긴 합니다(IE 7은 아직 약간은 불안 하더라고요). 그에 반에 FF는 기존에 안주하고 계속적으로 버그패치만 하는 모습이 아니라 계속적으로 편리하게 기능 개선 및 추가가 이루어 지고 있지요. 그 점이 어느 정도 완전한 안정화를 이루는 데에는 걸림돌이 되기도 합니다.
또한 IE개발자의 경우 자기네가 원하는 대로 브라우져 개발을 하고 이를 표준으로 삼아버렸기 때문에 자기네만의 표준 만큼은 완벽하게 지원한다 할 수 있음니다. 하지만 FF를 비롯한 타 브라우져 개발자들은 공식 웹표준과 IE 전용 지원 싸이트 모두를 지원하기 위해 머리 빠지게 고민하고 삽질해서 구현한 결과가 현재의 버전입니다. 그래서 요즘 버전은 예전에 안되던 싸이월드도 되고 웬만한 싸이트도 보는데 크게 문제가 없습니다. 그 만큼 여러 싸이트의 포용력(또는 해석력이라고 할까요) 부분에서 FF가 IE에 비해서 훨씬 나으면 나았지 못하지 않다는 점입니다. 다만 너무 국내의 몇몇 IE에 특화된 싸이트 방문시에 FF가 답답해 보이는 걸로 인해서 많은 분들이 FF가 IE에 비해서 상대적으로 적은 포용력을 가진다고 선입견을 가진다는 점입니다. (또 이런 점으로 인해서 상대적으로 FF가 IE보다 웹페이지 해석 및 랜더링 측면에서 복잡한 구조를 가질 수 밖에 없고 이로 인해서 버그의 수도 증가할 수 밖에 없다고 봅니다.)
그리고 또하나 간과하지 말아야 할 점 하나가 대부분의 국내 웹페이지 개발시 IE에서만 오류가 안나도록 테스트를 거치기 때문에 상대적으로 IE에서는 심각한 오류가 발생하지 않는 것 처럼 보이고 FF가 더 문제가 많은 것 처럼 인식되기도 한다는 겁니다. 예를 들어서 어느 독재 국가에서 모든 싸이트 개발시 IE, FF가 아닌 제3의 브라우져를 표준으로 하라고 강제를 한다고 한다면 그 나라 싸이트를 써핑시에는 IE의 에러 발생률도 훨씬 늘어나겠지요?
FF가 IE 에 비해 이렇다 저렇다 하는 식으로 이야기할 필요가 있을까요? 이야기하신 국가에서 IE 에러 발생률이 늘어나는 거는 FF 하고 관계 없는 일이라고 봅니다. 그냥 FF 가 지금 이런 문제점이 있고, 해결하려고 노력하고 있다고만 이야기하면 되는 일 같아보입니다. 제가 보기에는 다른 분들도 쓸데없이 괜히 IE 를 끌여들여서 이야기를 하는 바람에 별 것도 아닌 일가지고 답글이 수십개나 달리는 쓰레드가 되버린 것 같네요.
쓰레드형 계시판의 장점은 이런식으로 논의가 확장되어 나갈 수 있다고 봅니다. 가치가 있는 논의라면 꼭 쓰레드 첫글에 관련이 있어야 된다고 보지 않습니다.
FF코드와 관계없는 플래시에서 죽는 문제가 아니라 FF자체에서 메모리 릭이나 오작동이 있다면 FF의 문제임은 인정해야 됩니다.
하지만 어느 브라우져라도 전혀 버그가 없는 브라우져는 없고, 이런 문제가 국내의 특수한 인터넷 환경에서만 부각이 되는 것인데, 무조건 IE의 비표준 스크립트를 잘 처리하는 브라우져 = 좋은 브라우져, IE 전용 스크립트를 잘 처리하지 못하는 브라우져 = 열등한 브라우져 라는 식의 논조로 이야기하신 분이 계셔서 거기에 반박글을 단 것입니다.
여기에 반박하신 많은 분들의 의견과는 달리 저는 IE 전용스크립트 싸이트에 대한 포용도 필요하고 이런 경우에도 어플리케이션 오류는 발생하지 말아야 된다는 점을 인정하고 그런 전제에서 논의를 하였습니다. 그럼에도 FF가 그런 점에 있어서 결코 엉터리로 만들어진 브라우져는 아니라는 점을 말하고 싶었습니다.
무조건 IE의 비표준 스크립트를 잘 처리하는 브라우져 = 좋은 브라우져, IE 전용 스크립트를 잘 처리하지 못하는 브라우져 = 열등한 브라우져 라는 식의 논조로 이야기하신 분이 계시다고 하셨는데 그게 누구인지 아니면 어떤 글인지 좀 집어주십시오.
제가 별 것도 아닌 일에 답글이 수십개 달렸다고 한거는 다들 IE 전용 페이지에 대해 한 이야기 또 하고 한 이야기 또하고, 또 어떤 사람은 그 이야기 아닌데 왜 이상한 소리하냐고 한 이야기 또 하고 한 이야기 또 하고 그러길래 드린 말씀입니다. 위에 이야기하신 사람이나 글을 제대로 집어주시면 님께서 쓰신 글이 새로 할만한 이야기라고 인정할게요. 못 집으시면 별 것도 아닌 쓰레드에 별 거 없는 이야기를 덧붙이신거라고 생각합니다. 남들 한 이야기말고 별로 새로운 말씀도 없어보입니다.
개발자들답지 않은 공방이라는 생각이 드네요.
이 많은 댓글이 달리는동안 대체 어느 URL에서 문제가 생긴다는건지 알 수가 없고요.
그 웹페이지 개발자도 개발자일건데 보지도 않고 "그 웹페이지가 비표준이라서 그래"라고 어떻게 단정해서 말할 수 있나요... 막말로 그 웹페이지 개발자가 "그 말에 책임질 수 있냐?"고 하면 뭐라고 해야 할지...
설령 표준에 어긋난다고 해도 메모리가 새거나 죽는건 큰 문제라고 봅니다.
왜냐면 이건 단순히 렌더링이나 이런 표현상의 문제가 아니라 보안 문제로 볼 수 있기 때문입니다.
극단적인 예로 html 문법이 아니라 일반 텍스트 파일도 종종 웹브라우저로 열곤 하는데, 텍스트 파일 열었다고 CPU 사용량이 50%로 오르거나 메모리가 새거나 죽는다면 이해하실 분 별로 없을 것 같습니다.
----------------------------------------------------------------------
간만에 일찍 잠들었다가 배고파 잠 깨서 밥은 없고 생라면 깨먹고 있다는...
메모리가 1.7G까지 올라간 이유도 FasterFox가 캐싱하는 데이터가 쌓여서 그럴것으로 보이는 군요.(지극히 개인적인 견해임^^)
아무튼 파이어폭스와 관련된 문제는 거의 대부분 파폭자체의 문제보다는 확장기능에서 오는 문제가 많습니다.
무분별한 확장기능 설치는 파이어폭스를 메모리 먹는 여우로 만듭니다. -_-;;
-----------------------------------------------------------------------------
simple is the best, http://jedison.tistory.com
-----------------------------------------------------------------------------
simple is the best, http://jedison.tistory.com
혹 플래시가
혹 플래시가 돌아가고 있는 페이지를 띄어놓지 않으셨나요? 제 경험으로는 메모리는 항상 많이 먹는 것 같은데, CPU 점유율이 높을 때는 플래시가 있는 페이지에서 그런 경우가 많았습니다. 파폭 문제인지 플래시 자체 문제인지, 플래시 스크립트를 엉터리로 짜놔서 그런지 알 수는 없지만 여하튼 플래시가 있는 페이지를 닫으면 정상으로 돌아오더군요.
플래시는 거의
플래시는 거의 없었는데
FF를 몇일 켜두고 있었습니다.
메모리를 많이 먹는건 그런 줄 알고 썼는데 좀 심해서요.
탭 6개, 그것도 네이버보다 간단한 페이지인데 어떻게 저렇게 되는지 모르겠네요
http://forums.mozilla.or.kr/v
http://forums.mozilla.or.kr/viewtopic.php?t=5191&highlight=about%3Aconfig+%B8%DE%B8%F0%B8%AE
http://kldp.org/node/77324
http://kldp.org/node/78041
가끔은 ...
FF 가 폭주할 때가 있더군요.
조금 전에 리부팅 했습니다.
제가 집에서 대충 쓰는 데스크탑 사양이 VIA-C3 cpu (800MHz 짜리지만, 실제 성능은 셀러론 500~600 MHz 급)에 램 1 기가 짜리인데, 통제가 불가능하더군요.
평균 3일 정도 FF 를 계속 켜두면 그렇게 되더군요.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
버그는 빨리
버그는 빨리 신고하세요
파폭..
조금 여담입니다만..
파폭이 문제라기 보다는 국내 사이트들이 문제인 것 같던데요.
윈XP 환경에서의 말씀입니다만..
국내 사이트 돌아다니다 보면 이놈의 여우가 메모리와 함께 동반자살하려는 시도를 가끔 하더군요.
특히 루X웹에서 게임 리뷰 동영상 보다 보면 별별 이상현상이 다 일어납니다;;
심지어는 탭을 늘릴 수는 있는데 닫는 게 안된다거나..;;;
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
파폭이 좋은점도
파폭이 좋은점도 있겠지만 그렇다고 국내 사이트가 문제라고 매도하기에는 좀..
개떡같은 사이트들도 별 무리 없이 볼수 있는 브라우져가 있다면 전 그걸 쓰겠어요.
글구 MS-explorer로는 별 무리 없이 국내 사이트 볼수 있는거 같구요..
저도 FF 포함해서 구할수 있는거는 이것저것 써봤는데요.. MS-explorer가 젤 무난한거 같아요
글구... 웹 표준이라등가.. 울나라 인터넷 환경이라든가.. 머 그런 기술적인거는 저는 잘 몰라요.ㅎㅎ 걍 체감상 젤 좋은걸루 쓰는 end-user입니다.
어플을 사용하다가
FF가 한국의 웹사이트들을 제대로 표현 못해주는건 FF의 문제이지 한국의 웹사이트의 문제가 아닙니다.
간혹 "한국의 웹사이트들이 표준을 지키지 않아서 FF가 제대로 표시를 못해주는것이다."라고 말하는 분들이 계시는데
한국의 웹사이트들이 표준을 지키던 안지키던 웹브라우저는 그것들을 잘 표시해주어야 합니다.
루리웹에서 이상현상이 나타나면 그것과 관련된 예외처리를 FF에서 못해서 생긴 문제인 겁니다.
가끔 보다보면 웹브라우저가 웹페이지를 제대로 표시못하면
이상하게 웹브라우저 개발자가 아닌 웹페이지 개발자가 욕먹더군요.
물론 웹페이지를 제대로 못 만든경우도 있지만
그런것도 잘 처리해주어야 하는게 웹브라우저 개발자인겁니다.
그래야 우수한 웹브라우저인거지요.
그렇지 않다고
그렇지 않다고 봅니다.
인간이 살아가는 환경에 따라 사람이 변하는데 그걸 가지고 "저 사람은 환경하고 상관 없이 --잘못된-- 인간일 뿐이다."라고 자신과 다른 환경에서 살았고 다른 행동을 하는 사람을 몰아 붙일 수 없는 노릇이라고 생각합니다. 웹브라우저도 같다고 봅니다 저는. 잘못 되었으면 잘못 표시하는ㄱ 맞지, 예외 처리를 해서 잘못된 예외까지 무조건 맞게 해야(즉 한국 입맛에 맞게 해야) 제대로 된 프로그램이다 라고 할 수 없다고 봅니다. 분명히 한국의 웹사이트들이 표준을 지키지 않았고 표준데로 출력하도록 만들어 진 프로그램이 그 표준을 지키지 않은 것 까지 책임져야 하고 예외 처리까지 다 해야 한다는건 어거지라고 봅니다.
한국 변호사가 미국에 갔다고 해서 미국 법에 따라 변호까지 다 해야 한다고 하는 것과 같은 말씀을 하시는 것 같습니다. "나는 미국 법을 공부하지 않았고 한국 법만 공부했으니 의뢰를 받아드릴 수 없군요."라고 하는게 뭐가 잘못 된 건지 모르겠습니다.
개발자의 입장, 사용자의 입장... 모두가 중요하다고 생각합니다. 일반 사용자의 입장에서 님의 말씀이 옳을지 모르나, 어떤 방향성을 가진 개발자의 입장에서는 그 말이, 그 생각이 아닐 수도 있습니다.
무조건 관리자와 개발자층을 욕하는 최종 사용자들, 무조건 최종 사용자들을 욕하거나 권력을 남용하는 관리자나 개발자 그룹 또는 기업... 이런건 있어서는 안된다고 봅니다.
제가 이 글을 남긴 이유는 많은 경우에 위와 같은 사고방식에서 제가 위에 있어서는 안 된다고 말씀 드린 두 가지 일이 발생할 수 있는 근간이 되기 때문이었습니다.
PS: 쓸 때 없는 잡소리만 적은 것 같군요.
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
HomePage: http://lys.lecl.net:88/
Wiki(Read-Only): http://lys.lecl.net:88/wiki/
Blog: http://lys.lecl.net:88/blog
MSN: ysnglee2000@hotmail.com
----
절이 싫으면 중이 떠나는 것이 아니라, 절이 싫으면 중이 절을 부숴야 한다.
사람천사
인용:인간이
웹브라우저는 OS상에서 돌아가는 프로그램입니다.
프로그램과 인간은 비교대상이 안됩니다.
표준에 맞지 않은 웹페이지를 만났을때
제대로 표시해주는 웹브라우저와 제대로 표시못하는 웹브라우저가 있습니다.
어느 웹브라우저가 우수하다고 볼수있을까요?
당연히 표준뿐만 아니라 비표준 웹페이지까지 아우르는 웹브라우저가 더 우수합니다.
이건 end user 입장뿐만 아니라 개발자 입장에서 봐도 마찬가지입니다.
위의 대답과 같습니다만
"표준이 아니라서 못한다"는 개발자보다
비표준이라도 처리해내는 개발자가 더 유능한건 당연한거겠지요.
고객(end user)의 입장에서는 전자의 프로그램은 쓰레기이고 후자의 프로그램은 우수한 프로그램이 됩니다.
이것도 비교대상이 잘못되었습니다.
표준과 법을 비교하는건
법과 도덕을 비교하는것과 같습니다.
표준과 도덕은 지키면 좋지만 안지켜도 상관없습니다.
하지만 법은 반듯이 지켜져야만 하는 겁니다.
웹페이지에 스크립트를 잘못써서 무한루프를 생산해낸 웹개발자도 잘못이지만
그렇다고 이런 오류를 웹개발자에게만 미루는게 웹브라우저 개발자의 입장에서 잘하는 것일까요?
"그건 웹개발자의 잘못이지 웹브라우저가 먹통되어도 난 모른다. 나는 표준을 준수하는 웹페이지만 보여주는 웹브라우저를 만들면 그만이다."
이건 아니라고 봅니다.
좀 이야기가
좀 이야기가 빗나가는 듯하긴한데요...파폭이 느려지는 이유가 프로그램 자체의 결함인지 어떤지는 모르겠지만, 그걸 제쳐두고, 문제가 있는 페이지를 제대로 표시 못하는게 브라우저 개발자가 욕먹어야 할 일이라는건 좀 지나치지 않은가 싶네요.
문제가 되는건 '표준'에 포함되지 않은, 해당 브라우저 전용 마크업이나 자바스크립트등을 이용하는 경우가 대부분이니, 이건 그런 비표준 사양을 이용해서 만든 웹페이지 작성자의 책임아닌가요?
예를 들어 익스전용 사양을 이용한 페이지가 파폭에서 제대로 표시가 안되는게 파폭개발자의 문제라면, 파폭개발자들이 표준에 포함되지 않은 익스전용 사양에는 무엇이있나 다 파악하고, 이것들이 파폭에서 구현가능한 일이라면 되도록 구현할수 있도록 노력해야 하며, 그렇지 않더라도 적합한 처리가 되도록 해야한다는 건데, 이거야말로 넌센스라고 생각합니다.
표준과 비표준에
파폭에서 익스전용 코드를 모두 처리하라는게 아닙니다.
파폭에서 처리할 수 없는 코드가 있다면 예외처리를 해야하는거 아닐까요?
그런 코드때문에 메모리를 무한대로 먹게되고 먹통되고 어쩔때는 오류내면서 죽어버리는게 당연한건 아닙니다.
예외를 통째로
예외를 통째로 무시해버리지 않는 한, 예외처리를 할려면 결국엔 어떤 예외인지를 알아야 처리할수 있는거 아닌가요? 사실상 "파폭에서 처리할수 없는 코드=익스전용코드" 인경우가 거의대부분이기 때문에, 결국 그 예외처리를 위해 파폭개발자들은 에서 익스전용코드를 숙지한다음에 똑같이 구현하든 안하든지 간에, 익스용코드를 처리해야할 "의무"가 있다는 것과 다름없는 것이 아닌가..하는 생각이드는데요...동종의 프로그램을 보면서 장점을 받아들여서 프로그램을 개선할 의무는 있을지 몰라도, 명백하게 웹접근성을 저해하는 익스전용코드를 받아들여서 프로그램을 짜맞춰야할 필요가 있을까요?
자꾸 이야기가 IE vs
그래도 몇마디 하자면
. F개발자들이 익스전용 코드를 눈에 불키고 찾아보고 배우고 해야할 의무따윈 존재하지도 않습니다.
. 익스전용코드가 아닌경우는 FF개발자들이 알아서 찾아보고 예외처리하거나 제대로 표시를 해주는가요?
제가 지금껏 하는말은 IE전용 스크립트마저 처리를 하는 브라우저가 그렇지 못하는 브라우저보다 우수하다는 겁니다.
"IE전용 스크립트라서 처리못한다"라는건 어린애가 떼쓰는 소리로밖에 안들립니다.
저는 반대의견입니다.
처음에는 나는 오리님이 잘못된 코드라도 브라우저 자체가 이상동작을 하면 안된다는 주장하시는 줄 알았습니다.
일단 죽거나 뻗거나 하면 안 된다까지는 누구나 동감할거라 생각하고요.
저는 잘못된 코드라면 잘못된 방향으로 처리하지 않는 것이 더 좋다고 생각합니다. 잘못된 코드가 그대로 동작하는 것은 분명 우연에 의한 코딩일 가능성이 크다고 봅니다. 코드의 질은 점점 떨어져만 갈겁니다.
처리하는 것과 처리하지 않는 것을 선택 가능하다면 좋을 거 같긴 한데 아마도 문제가 복잡해지겠지요.
IE전용 스크립트가
FF에 한해서만 잘못된 스크립트일 수는 있겠네요.
틀렸습니다
IE에 한해서만 올바른 스크립트입니다
(x)html도 c도 같은
(x)html도 c도 같은 컴퓨터 언어입니다
C로예를 하나 들어 보지요
char c[-16]:
snprintf(sizeof)c(, c, 'ㄹ%sㄹ', argv(1];
오리님 주장은 이런 것도
char c[16];
snprintf(c, sizeof(c), "ㄹ%sㄹ", argv[1]);
와 똑같이 컴파일 된다는 뜻입니다
위에 있는 코드가 정상으로 보이시나요? gcc에서도 vc에서도 컴파일 안 될겁니다. 저건 코드도 아닙니다.
혹시 저런 것도 컴파일을 해줘야 우수한 컴파일러라고 하시지는 않겠지요?
(x)html도 마찬가지입니다
제 말을 억지로
컴파일러(웹브라우저)가 컴파일이(웹페이지에 정상적으로 표시) 안되는 이유(에러메세지)를 출력해주는게 좋은 컴파일러(웹브라우저)라고 말하는겁니다.
더 쉽게 설명할 방법이 없어서...
이걸로라도 이해하는데 조금이나마 도움이 되셨으면 합니다.
오리님 말에 모순이 있습니다
FF는 (x)html, css, js의 오류, 경고를 다 알려줍니다. 메뉴를 뒤져보세요.
경고 뿐 아니라 메모리도 낭비하지만 오류메시지는 출력합니다
반면, IE는 오류 출력을 안 하고 정상적으로 표시합니다. 바로 이게 문제입니다
위의 잘못된 코드를 컴파일하는 경우가 되겠지요
왜자꾸 FF이야기에
메뉴는 뒤지기 귀찮으니 찾아서 링크걸어주시고요.
FF가 잘못된 오류를 다 찾아서 오류메세지를 다 출력한다는것도 찾아서 알려주세요.
그리고 왜그리 내글을 곡해해서 말꼬리 잡고 늘어지는지 이유도 알려주셧으면 고맙겠습니다.
메모리 문제는
메모리 문제는 불여우의 문제가 맞지만
레이아웃이 깨진다거나 그런 문제는 페이지의 문제입니다
웹 표준과 IE의 구현 방법이 다를 때 웹 표준을 따라간 것 뿐입니다
'mshtml이 진정한 웹 표준이다!' 라고 하시는 것 같은데 그렇다면 할 말이 없습니다
konqueror에서는 IE 를 따라간것도 좀 있던데요
브라우저마다 해석이 조금씩 다른건 정상인데 IE가 심한게 문제입니다
저 역시 문제는
저 역시 문제는 파폭이라고 생각합니다. 어떤 웹페이지가 표준을 지키지 않고 있다면 그 페이지를 제대로 보여줄 방법은 없습니다. 하지만 그렇다고 프로그램이 이상 현상을 보여서는 안됩니다. 메모리를 마구 잡아먹어버린다던지, 죽어버린다면 문제가 있지요. 잘못된 입력에 대해 예외 처리를 하는 것은 프로그램의 당연한 동작입니다. "이 입력은 처리할 수 없습니다." 라고 사용자에게 알려준다던지, 입력을 무시하던지, 처리할 수 있을 만큼만 처리하던지, 여하튼 분명한 처리를 해야하는 것이지요.
플래시 같은 것은 플레이어가 연관되니 어쩔 수 없다고 해도, 적어도 비표준 html 과 자바스크립트 때문에 파폭이 이상 현상을 보인다면 파폭이 그만큼 품질 떨어지는 프로그램이라는 뜻밖에 안됩니다.
표준을 지키지 않는
표준을 지키지 않는 다고 무조건 파폭이 제대로 표시못하다는게 아닙니다.
파이어폭스도 표준에 포함되지 않는 마크업들을 호환성을 위해 지원하는 것들이 있으며, 편리를 위해 표준에 들어있지 않은 자바스크립트 역시 지원합니다(사실 자바스크립트 자체가 표준이 아닌걸로 알고 있습니다).
문제는 그 비표준 사양의 대부분이 익스전용이라는 것입니다. 익스전용사양을 처리하기위해서 파폭개발자들이 눈에 불을켜고 익스전용사양에는 무엇이있나 살펴봐야할 이유는 어디도 없는 것 아닌가요?
물론 파폭도 예를 들어 자바스크립트에서 무한 루프에 빠지거나 하면 "더이상 처리할 수 없다"는 식으로 메시지 박스를 띄우는 등 할수 있는 처리는 하고 있습니다만, 설사 소스가 공개되어있어서 어떤 스펙을 어떻게 처리하는지 알고 있다고 해도 그 스펙을 다 파악하기 힘들텐데, 그렇지도 않은 다른 프로그램의 스펙을 전부 파악한다는 것 자체가 무리가 아닐까 생각하며, 파악해야 할 필요도 없다고 생각합니다.
위에도 적었지만, 그러한 익스전용사양이 장점이라면 당연히 받아들여서 개선해야 하겠지만, 분명히 웹접근성을 저하시키는 요소인데, 이걸 일부러 알아서 처리해주어서 웹접근성 향상에 방해되는 짓을 해야할까요...?
인용 -
인용 - "익스전용사양을 처리하기위해서 파폭개발자들이 눈에 불을켜고 익스전용사양에는 무엇이있나 살펴봐야할 이유는 어디도 없는 것 아닌가요?"
무슨 말씀을 하시는 겁니까? 예외 처리를 하는데 어째서 익스전용사양을 살펴야하지요?
저 아래에 제가 쓴 글 '꼭' 읽어보시기 바랍니다. :)
------------------------
"하고 싶은 이야기" 를 하지 마시고, "화제에 맞는 이야기" 를 하십시오. 도대체 누가 파폭을 두고 "익스전용사양을 처리" 하라는 이야기를 했나요? 문제는 "파폭이 처리할 줄 모르는 입력" 이지 "익스전용사양" 이 아닙니다. 익스 전용 웹페이지에 대해 말씀하시고 싶은 것은 알겠는데, xylosper 님께서 반박하시려는 그 주장을 하고 있는 사람이 아무도 없습니다.
아래글에도 썼지만 "(만약에) 파폭이 비표준 웹페이지 때문에 폭주한다면, 그것은 웹페이지 문제가 아니라 파폭 문제다" 가 xylosper 님께서 답글을 다신 글들이 하는 주장입니다. 그런데 그 글들에 (특히 "나는 오리"님 글에) 여러 말들이 더해지니 이야기가 산으로 가는군요. "나는 오리"님 스스로도 나중에는 산으로 가시는군요-_-; "나는 오리"님은 "처리한다"는 말을 더 신중하게 사용하실 필요가 있을 듯 합니다
------------------------
한 마디면 끝나는 이야기입니다. "프로그램은 어떤 입력에 대해서도 메모리나 CPU 문제를 일으켜서는 안됩니다." myueho 님 말씀처럼 누구나 공감하는 이야기 아닌가요?
xylosper 님께서 하시는 말씀 때문에 여기에 "사족"을 붙이자면 ["처리할 수 있는 입력인가?"를 미리 검사하거나], [처리 중에 "처리 방법을 모르는 예외 상황"이 발생하면 리소스를 잘 반납하고] 부드럽게 마무리하면 됩니다. 모든 가능한 입력을 미리 알아서 대처할 필요가 전혀 없습니다. 이건 개발자 입장에서도 엔드 유저 입장에서도 "기본" 입니다 :)
------------------------
같은 화면에서
같은 화면에서
익플에서는 메모리 적게 먹는데
파폭에서 많이 먹으면.
파폭이 문제인것 같은데요.
옹오 할것이 이상한곳으로 빗나가는 느낌이네요.
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
글쎄요..
물론 IE에 맞춰진 사이트를 볼 때 생기는 문제현상에도 대처할 수 있는 것이 우수한 어플리케이션이겠습니다만,
그러한 문제를 순전히 FF쪽에만 떠넘기는 것은
어찌 보면 웹 개발자 분들의 (정확히 말하자면 웹 표준에 대한 개념조차 없는 기획자나 그 윗선..) 오만이 아닐런지요.
웹 개발자 분들이 실력있는 개발자 분들인 만큼 FF의 개발자들도 실력있는 개발자 분들일겁니다.
오히려 제 생각은..
'대부분의 메이저 브라우저에서 동일 내지는 유사하고 문제없는 동작을 하도록 만드는 것'
이 웹 디벨로퍼의 미덕이 아닌가 하는 생각을 합니다.
제아무리 한국이 IT강국이라고 최면을 걸어도,
한글이라고는 알지도 못하는 외국 개발자들이 한국의 IE의존적인 기술을 사용하는 일부 사이트에서 발생하는
극히 예외적인 케이스까지 신경 쓸 이유가 있을까요?
표준이 있는데 그걸 전혀 지키지 않은 자료를 처리하는 과정에서 동작이 완벽하지 않다고 그 어플리케이션 개발자를 욕할 수 있다면
반대로 표준이 있는데도 그걸 전혀 지키지 않는 웹 디벨로퍼도 욕할 수 있다고 봅니다.
(그렇다고 둘 다 욕하자는 말은 아니구요.. ;;;;)
문제는 IE의존적인 기술을 사용하는 사이트들에 의해서 IE의 독점적 점유율이 유지되고, (Lock-in 효과)
그에 따라서 한국 내에서 윈도의 독점적 지위가 보장된다는 점에서 큰 문제가 되는 것이죠.
표준을 지키지 않는 것은 문제가 안 될 수 있지만, 그것이 특정 회사의 이익에 큰 영향을 끼친다면,
상도(특히 공정거래법)적으로 올바르지 못한겁니다. 국가(정통부)의 제재를 받아야 될 사항이 되어야만 하는 것이구요.
그리고 '나는오리' 님의 글 중에서
-----------------------------------------------------------------
표준에 맞지 않은 웹페이지를 만났을때
제대로 표시해주는 웹브라우저와 제대로 표시못하는 웹브라우저가 있습니다.
어느 웹브라우저가 우수하다고 볼수있을까요?
당연히 표준뿐만 아니라 비표준 웹페이지까지 아우르는 웹브라우저가 더 우수합니다.
이건 end user 입장뿐만 아니라 개발자 입장에서 봐도 마찬가지입니다.
-----------------------------------------------------------------
라는 말씀에는 조금 문제가 있다고 생각합니다.
표준에 맞지 않는 건 말 그대로 표준에 맞지 않는 것입니다.
그것이 어떻게 보여야 웹 디자이너가 의도한 대로 보여지는가는 순전히 웹 디자이너가 판단할 일이지요.
그것을 브라우저가 적절히 판단하면 좋겠습니다만, AI도 아니고 말이죠.. 과연 항상 적절하게 판단할 수 있을까요?
결국 저 말씀 대로라면 MSIE에 맞춰서 디자인된(그것도 비표준 마크업을 이용해서) 페이지를
FF나 사파리에서 MSIE에서 보이는 대로 맞춰서 보여지게 해야 한다는 말씀이겠는데..
그 말씀은 MSIE가 de facto 표준이라는 말씀처럼 들립니다. 이거야말로 MS가 원하는 것이겠지요.
브라우저들이 웹 표준에 따른 페이지를 표준안대로 보이게 하는 것. 이것이 브라우저의 1차적 목적이고,
2차적으로 표준에서 벗어나는 페이지를 최대한 잘(읽을만하게)보이게 하는 것, 이것이 2차적 목적이라고 생각합니다만. 틀린가요?
여기서 '읽을만하게'가 'MSIE의 레이아웃을 따라하게'를 의미한다고 해석하는 순간,
디벨로퍼 디자이너건 앤드유저건 MSIE의 독점적 지위를 인정하면서 그걸 표준으로 인정하는 게 되는겁니다.
(너무 강경발언인가요?)
좀 극단적인 예지만, A라는 회사가 있고, 40층짜리 빌딩을 새로 지을 때,
책상 길이가 180cm냐 170cm냐 정도의 10cm차이로도 사무실의 평면 디자인이 통째로 바뀔 수 있습니다.
그리고 그 회사는 특별히 문제가 있지 않는 한, 기존에 사용하던 책상과 다른 사이즈의 책상을 쉽게 구매할 수 없습니다.
표준이라는건 그만큼 중요합니다. 특히 MSIE VS FF 처럼 특정 기업들의 이익에 크게 관계된다면 더 그렇습니다.
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
------------------------------------------------
ChaosStyle
Be Abnormal, Be Crazy, Be Chaos
------------------------------------------------
비표준을
비표준을 옹호하는것이 아닌.
비표준이 나왔으면 느린것은 괜찮은데.
왜 메모리 관리는 제대로 못하는걸까요?
비표준이니까 당연히 메모리 관리는 못하는걸까요?
그리고 비판하시는분의 글을 잘보시기 바랍니다.
비표준이라서 느린것을 따진것이 아니라.
1.7G의 메모리를 써먹는 어플리 케이션을 비판한것입니다.
비표준이라서 제대로 표현 못하는건 말하지 않은것 같은데요.
표현을 못하기 때문에 당연히 메모리 1.7G써도 상관 없다는 뜻인지..
그리고 처음 글을 쓰신분이 비표준 사이트에 들어 갔는지 아닌지 써놓았던가요?
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
표준에 맞지 않는
그리고 앞서 말했듯이 표준은 지키면 좋은것이지 강제수단은 아닙니다.
p.s. 이 글을 읽는 분중에 루리웹(루리웹이 아니더라도)의 어느 페이지에서 FF가 죽는지 URL을 알려주셨으면 합니다.
네. 강제 수단은
네. 강제 수단은 아니지요.
표준 안 지키는 사람을 감옥에 넣는다거나 벌금을 징수하는 법은 없지요
하지만 꼭 표준까지는 아니더라도
최소한 많이 쓰이는 firefox ie konqueror opera safari 같은 브라우저에서는 동일하게 사용할 수 있어야 합니다.
하지만 오리님 말 대로 모든 경우에 지킬 필요는 없습니다. 표준은 모든 브라우저에서 동일하게 작동하기 위해서 만들어 졌습니다
만약 다중 브라우저 지원을 위해 표준과 어긋나는 hack을 썼다 하더라도 이 경우에는 문제가 없습니다.
죄송하지만..... 특정
죄송하지만.....
특정 페이지는 아닙니다...
하지만...한 한시간 정도 플래시와 동영상이 도배된 사이트 들어가면
다운되는 현상과 메모리 많이 잡아먹는 현상 있습니다..
인용:죄송하지만.....
죄송할 필요는 없습니다.
누군지도 모르는 분에게 아무이유없이 사과를 받는 사람은 아닙니다.
플래시와 동영상의 어떤것이 다운되는 현상 또는 메모리 릭이 발생하는 현상과 관련이 있는지 알수 있을까요?
플래쉬가 많은
플래쉬가 많은 곳이라면 FF문제가 아니고
FF용 flash player의 문제일 가능성이 많지요.
실제로 linux용 flash player는 대단히 buggy하고 느리다고 알려져있고요.
지금 많은 분들이
지금 많은 분들이 엉뚱한 이야기를 하고 계신 것 같은데,
1. 이 글타래를 연 글은 파폭의 이상 현상 에 대한 글이고,
2. 여기에 대해 panickros 님께서는 이상 현상(메모리 문제나 탭 문제)가 잘못된 웹 페이지 때문에 발생하므로 파폭이 아니라 국내 웹사이트들이 문제라는 논지의 답변을 다셨습니다.
3. 그리고 다시 여기에 대해 저를 포함한 몇몇 분이 잘못된 웹페이지 때문에 그런 이상 현상이 발생한다면 그것은 파폭의 문제다.
라고 답을 했습니다. 누가 비표준 웹페이지를 MS 익스플로러에 맞춰서 표시해야한다고 했나요? 몇몇 분이 엉뚱한 말씀들을 하고 계십니다. 혹 "예외 처리"가 프로그래밍에서 무슨 뜻인지 몰라서 그런 말씀들을 하신는 건가요? 프로그래머가 아니더라도 글들의 맥락을 보면 무슨 뜻인지 알 수 있을텐데요? 예외 처리를 익스플로러에 맞춰서 표시하는 것으로 이상하게 해석을 하고 엉뚱한 말씀들을 하시는군요.
지금 글타래에서 논쟁거리인 "문제"가 뭔지, 어떤 글들로 논쟁이 촉발됐는지 다시 한번 읽어보시고, 생각해보시고 글들을 쓰시는 게 좋을 것 같습니다.
지금 논쟁거리는 "비표준 웹페이지에서 파폭이 정상적이지 않은 행동을 하는데 이것은 파폭 문제가 아니라 웹페이지 문제다" 라는 주장입니다.
비표준 웹페이지 문제는 말이 많을 필요가 없는 문제입니다. 어제 오늘 지적된 문제도 아니구요. 하지만 비표준 웹페이지더라도 프로그램이 뻗어버려서는 안되지요. 잘못된 입력에 대한 처리는 "기본"입니다. 컴파일러가 소스코드에 에러가 있다고 뻗어버리면 말이 됩니까? 웹서버에 http 가 아닌 다른 프로토콜로 접속하면 요청을 무시해야지 뻗어버리면 말이 안되는 겁니다. cp 명령에 -bbnhxxx 같은 이상한 옵션을 줬다고 cp 가 메모리를 몇백 메가 잡아먹으면 그걸 사용자 잘못이라고 하시렵니까? 알수 없는 옵션이 들어오면 에러메시지를 출력하고 종료하는게 정상적인 행동입니다. 브라우저라면 처리할 수 없는 웹페이지는 에러 메시지를 내던가, 처리할 수 있는 부분만 처리하고 나머지는 무시하는 것이 정상적인 행동입니다. 어떤 입력에 대해서도 메모리나 CPU 문제가 생겨서는 안되지요.
CP의 옵션에 대한
CP의 옵션에 대한 이야긴 약간 다르지 않나요? 그건 웹 브라우저로 치면 애초에 없는 주소로 가는 것과 같은 상황이 아닐런지...
소스코드는 공감이 가긴 합니다만 실제로 이런가요? 제 기억으론 소스코드에서 무한루프 같은걸 실수로 줘 버리면 강제로 종료하지 않는 이상 뻗어버리던걸로 기억하는데요...
프로그래밍 한지 오래되어서 기억은 가물합니다. ㅠ.ㅠ
--
"It's too bad that stupidity isn't painful" - Anton LaVey
--
"It's too bad that stupidity isn't painful" - Anton LaVey
밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt
없는 주소를 치면
없는 주소를 치면 에러 메세지를 주는 것과 마찬가지로 잘못된 웹페이지도 부드럽게 처리해줘야 합니다. 인터프리터라면 무한루프를 돌겠지만, 컴파일러라면 그런 일이 없겠지요^^.
어줍잖은 지식으로
저건 정말 이상한것 같습니다. 지금까지 4~600 메가 정도까지 메모리를 빨아먹는다는 소리는 많이 들었지만 (물론 이것 만으로도 큰 문제기는 합니다만) 2기가 가까이 먹는 이런 케이스는 제 기억 상으로는 이번이 처음이네요. 이건 파폭만의 문제라고 보기가 힘들것 같습니다. 이 정도로 심각하다면 다른 곳에서도 들어봤을 텐데 말이죠. 확장을 뭘 쓰고 계신가요?
--
"It's too bad that stupidity isn't painful" - Anton LaVey
--
"It's too bad that stupidity isn't painful" - Anton LaVey
밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt
확장은 adblock
확장은 adblock greasemonkey webdeveloper firebug 설치했습니다
몇 일 켜놓았는데 메모리 릭이 누적되어서 그런것 같기도 합니다
firebug가 설치되어
firebug가 설치되어 있으면 파폭이 상당히 버벅거립니다. disable로 해놔도 마찬가지고요.
거기다 flash_player_9_linux 도 불안해서 자주 죽습니다.
꼭 예전에 한글때문에 glibc 패치하고 넷스케이프에 ami 붙혀쓸때 그 시절 같아요(이게 몇년전이죠? 99년이던가?).
(kltp|qmail|mutt).kldp.org
http://eunjaeim.com
걍 껐다 키세요. = _=
걍 껐다 키세요. = _=
아, 컴퓨터 말고
아, 컴퓨터 말고 파폭요. = _=
혹시 탭을 많이
혹시 탭을 많이 열어둔 것은 아닌가요?
탭브라우징을 하면 메모리를 많이 사용합니다.
가용 메모리가 있는한, 계속 탭을 열 수 있으니까..
1G이상도 사용가능하겠지요.
http://joone.net/blog
_________________________
http://joone.net
https://kldp.org/blog/2725
http://opensoftware.tistory.com
http://joone4u.blogspot.com
https://gnome.or.kr
탭은 6개 정도를
탭은 6개 정도를 열었습니다
제 경우에도 비슷한
제 경우에도 비슷한 상황이 있었는데.
플러그인 이름이 정확하게 기억은 안나지만.... 페이지의 에러나 스크립트 정보 기타 등등 정보들을 보여주는 플러그인을
설치한 후 발생 했습니다....
이 플러그인이 특정 웹페이지 ( setTimeOut 같은 함수를 사용해서 계속 뭔가를 하거나, 마우스의 움직임을 이벤트처리를 하는 스크립트가 포함된 ... 등등의 반복적인 작업이 존재하고 파폭에서 볼때 에러가 있는 페이지...) 에 들어가서 조금만 오래 있으면 에러 리포팅이 엄청나게 쌓이면서 결국엔 브라우져가 사망을 하다군요...
때에 따라서는 1분이 될수도 있고 하루가 될수도 있고...
파폭 엔진 자체에도 문제가 있을 수 있겠지만....
님과같은 그런 파폭의 폭주는 플러그인들의 비정상적인 행동일 가능성이 높지 않을까 생각해 봅니다...
http://www.jacojang.com
--------------------------------------------------
http://www.jacojang.com
"뛰어난 웹브라우저"
"뛰어난 웹브라우저" = "비표준 웹페이지도 잘 보여주기" 는 아니지 않을까요?
비표준 웹페이지는 프로토콜을 지키지 않은겁니다. MS도 참여하는 W3C에서 제정한 규약을 웹페이지가 지키지 않고 IE에서만 어찌어찌 잘 보이니까 그대로 패쓰~ 해버린걸 FF의 탓만으로 돌리기에도 무리가 있다고 생각합니다.
HTML도 SGML인데 데이터 포맷을 어긴것 아니겠습니까? 보통의 C/S기반 프로그램이라면 접속 끊고 GG겠죠 ㅎㅎ
Firefox는 여러 F/OSS의 조합으로 되어 있고 자체 코어도 작지 않습니다. IE와는 달리 여러 플랫폼도 지원해야 하고요. 이런 면에서는 오페라 같은 좋은 브라우저도 있고요.
FF는 의존하는 여러 라이브러리들의 버그도 그대로 안고 있고 자체 코어의 버그도 아직 많이 있습니다.
이러니 메모리릭은 비표준 웹페이지 외에도 어디서든 발생할 수 있죠.
메모리릭을 봐주자는건 아니고 버그없는 프로그램은 없는데 IE도 메모리릭 찾아보면 구글에 한아름;
여튼 FF는 나름의 가치를 가지고 있다고 생각합니다. 비표준 웹페이지로 엮어서 애써 그 가치를 깍을 필요까지는 없다고 생각합니다.
비표준 웹페이지로
비표준 웹페이지로 엮어서 애써 그 가치를 깍는 사람 없습니다. 거꾸로 비표준 웹페이지로 엮어서 애써 그 가치를 옹호하는 것에 대한 반론이지요. "메모리 릭(과 기타 문제) 이 있는 것은 파폭 문제가 아니라 비표준 웹페이지 문제다." 라고 옹호하는 것에 대한 반론입니다. 이 반론들을 촉발한 panickros 님의 글을 다시 읽어보십시오. 소타님 말씀대로 FF는 나름의 가치를 가지고 있습니다. 그런 식으로 옹호할 필요가 없습니다.
그리고, 다른 글들에서도 반복했지만 "뛰어난 웹브라우저" = "비표준 웹페이지도 잘 보여주기" 가 아닙니다. "기본적인 웹브라우저" = "비표준 웹페이지에서 폭주하지 않기" 입니다.
그만 산으로 갑시다아~
주장이 뭐든지
어떤 페이지에서라도 폭주하는 일은 없어야 한다는 건 모두들 공감하고 있는 것 같고요.
파폭이 아직은 완벽한 수준은 되지 않는 것 같습니다. 제가 볼때는 충분한 수준이고 시간이 갈 수록 더 좋아지는게 보입니다만.
그런데 IE는 올바른 페이지에서조차 이상한 동작을 할때가 많아서 참 싫어요.
“기본적인 웹브라우저”에 “표준 코드는 올바르게 표현하기”를 추가하고 싶습니다.
모든 예외 상황을 다
모든 예외 상황을 다 고려해서 만들 수 있다면 그야말로 당신은 "프로그래밍의 신"
잘못된 사이트는 IE에서도 죽습니다.
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
하기야... 프로그램은
하기야... 프로그램은 이성과 특별한 판단 능력을 가지고 있지 않으니, 제 비유가 잘못되었을 수 있겠군요. 하지만, 표준은 약속입니다. 약속을 해 놓고 약속을 지키지 않는 것은 결코 좋은 일이라고 할 수 없습니다.
코드가 잘못되어도 브라우저가 터지거나 자원 낭비 문제 등을 일으켜서는 안된다는 것에는 동의합니다.
그리고... 예외 처리를 하는데 모든 예외에 대해서 조사할 필요는 없습니다. 물론, 사용자에게 자세한 정보를 제공할 목저그로 예외 사항에 대한 정보를 수집해서 사용할 수는 있지만, 프로그램이 처리할 수 있는 것을 빼고 처리할 수 없는 모든 것은 어차피 예외입니다.
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
HomePage: http://lys.lecl.net:88/
Wiki(Read-Only): http://lys.lecl.net:88/wiki/
Blog: http://lys.lecl.net:88/blog
MSN: ysnglee2000@hotmail.com
----
절이 싫으면 중이 떠나는 것이 아니라, 절이 싫으면 중이 절을 부숴야 한다.
사람천사
뭐, 논쟁이
뭐, 논쟁이 뜨겁군요,, IE고 표준이고, 좋다 나쁘다,,,
헌데, 누가 버그를 만들고 싶어서 만든답니까........
그러니 버그 하나로는 싸우지 않는게 좋을 것 같습니다.
게다가 파폭은 지금도 "진행형"이니까요 :-)
이런글 쓰긴
이런글 쓰긴 싫지만....
솔직히...다음, 네이버 한시간 정도 돌아다니면...
툭하면 다운됩니다...
원인은 플래쉬 아니면 동영상 처리하는 부분때문인거 같은데
특정 홈페이지에서 다운되는것이아닌 돌아다니다 먹통되는때가 가끔있습니다.
이런면은 안전성이 좀 떨어지는 느낌을 받게합니다.
그런데 원인은 FF 자체가 아닌 64비트 플래쉬 때문인거 같습니다..
느닷없이 뜬금없이
느닷없이 뜬금없이 지멋대로 픽픽 죽는건
순!전!히!
표준이 뭔지도 모르고 지멋대로 쳐바른 한국의 무식한 웹페이지개발자들 때문이고
FF 자체가 아닌 FF와 무관한 플래쉬 때문이라니까요!!!
게다가 우린 거기에 대해 욕해선 안되요
FF는 계속 진행형이니까요!!!
ㅋㅋㅋㅋㅋ
아 웃음이~ㅋ
역시나 KLDP나 Kmug나 놉하나
산으로가기...를 너무 잘하는거 같아요...
그래서 즐겁군요...정상인의 눈으로 보기엔.
표준에 어긋나는
표준에 어긋나는 웹페이지를 만나더라도 잘못 렌더링 하는 것은 상관 없지만 어플리케이션 자체가 오동작을 하거나 메모리 릭이 생기는 문제는 확실히 비판의 여지가 있다고 봅니다.
그래도 FF가 초기 버전에 비해 지금 이정도 안정화 된것은 많은 오픈소스 개발자들의 노력이고 고무적인 일입니다. 확실히 IE 6은 나온지 아주 많은 기간이 지났고 많은 엄청난 시장 점유율로 버그리포트도 활발하여 서비스 팩과 각종 패치가 적용된 지금 굉장히 안정화 된 브라우져로 인정할 만하긴 합니다(IE 7은 아직 약간은 불안 하더라고요). 그에 반에 FF는 기존에 안주하고 계속적으로 버그패치만 하는 모습이 아니라 계속적으로 편리하게 기능 개선 및 추가가 이루어 지고 있지요. 그 점이 어느 정도 완전한 안정화를 이루는 데에는 걸림돌이 되기도 합니다.
또한 IE개발자의 경우 자기네가 원하는 대로 브라우져 개발을 하고 이를 표준으로 삼아버렸기 때문에 자기네만의 표준 만큼은 완벽하게 지원한다 할 수 있음니다. 하지만 FF를 비롯한 타 브라우져 개발자들은 공식 웹표준과 IE 전용 지원 싸이트 모두를 지원하기 위해 머리 빠지게 고민하고 삽질해서 구현한 결과가 현재의 버전입니다. 그래서 요즘 버전은 예전에 안되던 싸이월드도 되고 웬만한 싸이트도 보는데 크게 문제가 없습니다. 그 만큼 여러 싸이트의 포용력(또는 해석력이라고 할까요) 부분에서 FF가 IE에 비해서 훨씬 나으면 나았지 못하지 않다는 점입니다. 다만 너무 국내의 몇몇 IE에 특화된 싸이트 방문시에 FF가 답답해 보이는 걸로 인해서 많은 분들이 FF가 IE에 비해서 상대적으로 적은 포용력을 가진다고 선입견을 가진다는 점입니다. (또 이런 점으로 인해서 상대적으로 FF가 IE보다 웹페이지 해석 및 랜더링 측면에서 복잡한 구조를 가질 수 밖에 없고 이로 인해서 버그의 수도 증가할 수 밖에 없다고 봅니다.)
그리고 또하나 간과하지 말아야 할 점 하나가 대부분의 국내 웹페이지 개발시 IE에서만 오류가 안나도록 테스트를 거치기 때문에 상대적으로 IE에서는 심각한 오류가 발생하지 않는 것 처럼 보이고 FF가 더 문제가 많은 것 처럼 인식되기도 한다는 겁니다. 예를 들어서 어느 독재 국가에서 모든 싸이트 개발시 IE, FF가 아닌 제3의 브라우져를 표준으로 하라고 강제를 한다고 한다면 그 나라 싸이트를 써핑시에는 IE의 에러 발생률도 훨씬 늘어나겠지요?
글이... 비판의
글이... 비판의 여지가 있다고 봅니다... 까지 였으면 좋을뻔했군요.
나머지는 또다시 산으로...
길게길게 산으로...
했던얘기 또하고 했던 얘기 또하고.
또하면서 산으로...^^
FF가 IE 에 비해
FF가 IE 에 비해 이렇다 저렇다 하는 식으로 이야기할 필요가 있을까요? 이야기하신 국가에서 IE 에러 발생률이 늘어나는 거는 FF 하고 관계 없는 일이라고 봅니다. 그냥 FF 가 지금 이런 문제점이 있고, 해결하려고 노력하고 있다고만 이야기하면 되는 일 같아보입니다. 제가 보기에는 다른 분들도 쓸데없이 괜히 IE 를 끌여들여서 이야기를 하는 바람에 별 것도 아닌 일가지고 답글이 수십개나 달리는 쓰레드가 되버린 것 같네요.
쓰레드형 계시판의
쓰레드형 계시판의 장점은 이런식으로 논의가 확장되어 나갈 수 있다고 봅니다. 가치가 있는 논의라면 꼭 쓰레드 첫글에 관련이 있어야 된다고 보지 않습니다.
FF코드와 관계없는 플래시에서 죽는 문제가 아니라 FF자체에서 메모리 릭이나 오작동이 있다면 FF의 문제임은 인정해야 됩니다.
하지만 어느 브라우져라도 전혀 버그가 없는 브라우져는 없고, 이런 문제가 국내의 특수한 인터넷 환경에서만 부각이 되는 것인데, 무조건 IE의 비표준 스크립트를 잘 처리하는 브라우져 = 좋은 브라우져, IE 전용 스크립트를 잘 처리하지 못하는 브라우져 = 열등한 브라우져 라는 식의 논조로 이야기하신 분이 계셔서 거기에 반박글을 단 것입니다.
여기에 반박하신 많은 분들의 의견과는 달리 저는 IE 전용스크립트 싸이트에 대한 포용도 필요하고 이런 경우에도 어플리케이션 오류는 발생하지 말아야 된다는 점을 인정하고 그런 전제에서 논의를 하였습니다. 그럼에도 FF가 그런 점에 있어서 결코 엉터리로 만들어진 브라우져는 아니라는 점을 말하고 싶었습니다.
무조건 IE의 비표준
무조건 IE의 비표준 스크립트를 잘 처리하는 브라우져 = 좋은 브라우져, IE 전용 스크립트를 잘 처리하지 못하는 브라우져 = 열등한 브라우져 라는 식의 논조로 이야기하신 분이 계시다고 하셨는데 그게 누구인지 아니면 어떤 글인지 좀 집어주십시오.
제가 별 것도 아닌 일에 답글이 수십개 달렸다고 한거는 다들 IE 전용 페이지에 대해 한 이야기 또 하고 한 이야기 또하고, 또 어떤 사람은 그 이야기 아닌데 왜 이상한 소리하냐고 한 이야기 또 하고 한 이야기 또 하고 그러길래 드린 말씀입니다. 위에 이야기하신 사람이나 글을 제대로 집어주시면 님께서 쓰신 글이 새로 할만한 이야기라고 인정할게요. 못 집으시면 별 것도 아닌 쓰레드에 별 거 없는 이야기를 덧붙이신거라고 생각합니다. 남들 한 이야기말고 별로 새로운 말씀도 없어보입니다.
그것 참...
개발자들답지 않은 공방이라는 생각이 드네요.
이 많은 댓글이 달리는동안 대체 어느 URL에서 문제가 생긴다는건지 알 수가 없고요.
그 웹페이지 개발자도 개발자일건데 보지도 않고 "그 웹페이지가 비표준이라서 그래"라고 어떻게 단정해서 말할 수 있나요... 막말로 그 웹페이지 개발자가 "그 말에 책임질 수 있냐?"고 하면 뭐라고 해야 할지...
설령 표준에 어긋난다고 해도 메모리가 새거나 죽는건 큰 문제라고 봅니다.
왜냐면 이건 단순히 렌더링이나 이런 표현상의 문제가 아니라 보안 문제로 볼 수 있기 때문입니다.
극단적인 예로 html 문법이 아니라 일반 텍스트 파일도 종종 웹브라우저로 열곤 하는데, 텍스트 파일 열었다고 CPU 사용량이 50%로 오르거나 메모리가 새거나 죽는다면 이해하실 분 별로 없을 것 같습니다.
----------------------------------------------------------------------
간만에 일찍 잠들었다가 배고파 잠 깨서 밥은 없고 생라면 깨먹고 있다는...
의의 제기
삭제.
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.
고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"
뭔가 시스템 설정에
뭔가 시스템 설정에 문제가 있어보이네요. 파폭 프로파일과 설정 모두 지우고 파폭 재설치 하고 플래시 최신 버전으로 재설치한 다음 그래도 똑같은 문제 발생하면 다시 오세요. 이거 파폭 문제 아닙니다.
FasterFox 문제가
FasterFox 문제가 아닐런지......
일부 사용자들에 의해 파폭에는 필수라고 불리는 확장기능이지만 전 사용하지 않습니다.
특정사이트에 가면 순간적으로 메모리 사용률이 확 올라갑니다.
어떨때는 그냥 파폭이 죽어버리기도하지요.
글을 올리신 분도 분명히 FasterFox를 사용할 것으로 보이며
메모리가 1.7G까지 올라간 이유도 FasterFox가 캐싱하는 데이터가 쌓여서 그럴것으로 보이는 군요.(지극히 개인적인 견해임^^)
아무튼 파이어폭스와 관련된 문제는 거의 대부분 파폭자체의 문제보다는 확장기능에서 오는 문제가 많습니다.
무분별한 확장기능 설치는 파이어폭스를 메모리 먹는 여우로 만듭니다. -_-;;
-----------------------------------------------------------------------------
simple is the best, http://jedison.tistory.com
-----------------------------------------------------------------------------
simple is the best, http://jedison.tistory.com
버그로 인한 메모리릭 문제 아닌가요?
얼마전에 간단히 테스트해본 결과 여러 사이트를 돌아다니고서 탭 한개에 빈페이지만 있어도 메모리 사용량은 몇백메가로 줄어들지가 않더군요. IE7도 같은 문제를 겪었었습니다. 갑자기 웹표준문제하고는 상관이 없죠.