윈도우를 사용하다보면 강제 종료된 후 사용하던 창들이 다시 켜지는 경우가 있습니다.

이를 xfce4에서도 지원을 하는데 일명 세션 복원이라고 합니다.

 

문제는 처음에 세션복원이 되면 편리한데 다음에도 또 다음에도 해당 세션이 복구된다는 겁니다. 재부팅 되면 이게 리셋이 되어야 하는데 리셋이 안 되는거지요.

 

그럴 때는 저장된 세션을 지워버리면 됩니다.

 

~/.cache/sessions

위 경로에 가보면 저장된 세션이 존재합니다.

이 파일들 때문에 자꾸 firefox와 thunar가 자동실행 된다.

 

그냥 이걸 가뿐하게 지워주세요.

 

그리고 SaveOnExit를 지원하지 않게 하겠다면

xfconf-query -c xfce4-session -p /general/SaveOnExit -s false

안 되면

xfconf-query -c xfce4-session -p /general/SaveOnExit -n -t bool -s false

 

위 명령어로 SaveOnExit를 꺼주시면 됩니다. 이러면 그냥 강제 종료되면 다시 복귀되지 않습니다만 뭐... 깔끔하잖아요?

,

웹개발을 하다보면 User-Agent String이라는걸 보게됩니다.
접속한 사람의 브라우저가 뭔지 서버에서 확인하는 그런건데 이게 요상한 역사가 있습니다.
2024년현재 이 Agent String(이하 UA)는 그냥 꼼수와 꼼수와 꼼수를 거쳐 하나의 거대한 역사의 한 장면을 연출합니다

처음에는 간단했습니다. Mosaic시절부터 Netscape때 까지만.

NCSA Mosaic/3.0 (Windows 95)
Mozilla/4.8 [en] (Windows NT 5.0; U)


위는 Win95의 모자이크고 아래는 윈도2000에서 넷스케이프4.8 (넷스케이프의 개발명이 Mozilla였습니다.)로 접속시 뜨는 UA입니다.
대충 이렇게 브라우저 이름과 운영체제가 뜨는 수준이었습니다.

하지만 Javascript(이하 JS)가 등장하면서 이를 활용한 웹페이지들이 만들어졌고 이를 지원하지 않으면 제대로 뜨지 않으니 웹개발자들은 지원여부를 구분해야했습니다. 다만 이를 지원하는지 확인하는게 UA밖에 없었습니다. 그래서 당시 주류이자 Javascript를 유일하게 지원했던 Netscape냐 아니냐 정도로 구분했습니다.

그 당시 쓰던 코드가 UA문구중에 Mozilla가 있느냐 없느냐 였습니다. 그러다 Internet Explorer(이하IE)가 등장하면서 꼬이기 시작합니다.

IE는 Netscape와 호환을 목표로 했기에 JS가 지원됐지만 웹페이지들은 Mozilla라는 문구만 확인했기에 IE에도 JS가 안되던 이전페이지만 보여줬고 이를 해결하기위해 MS가 만든건

Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)

(Win95에서 IE2.0사용시)

네... User Agent에 Mozilla라고 집어넣고 compatible이라는 문구를 넣었습니다.
즉 나는 넷스케이프와 호환되는 녀석이다라고 적은건데 이 때까지만해도 이게 재앙의 시작일줄은 몰랐을겁니다.

이후 버전업을 하고 Windows가 이런저런 에디션이 생기면서 UA는 더 지랄맞아지게 됩니다

Mozilla/4.0 (compatible; U; MSIE 6.0; Windows NT 5.1) (Compatible; ; ; Trident/4.0; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 1.0.3705; .NET CLR 1.1.4322)


WindowsXP x64버전의 IE6.0을 32비트버전으로 실행했으며 닷넷프레임웍을 3.5버전으로 설치된 환경이라는 의미입니다.

닷넷프레임웍버전이 끼어들어간 이유가 당시 MS가 당시 많이 쓰이던 자바대신 닷넷을 밀고있었는데 이게 또 버전별로 호환을 탔기 때문입니다.

네...벌써 개판입니다. 하지만 MS는 IE개발에 손을 놓았고 Firefox가 등장하면서 또 한번의 격변이 일어납니다.

Firefox는 그래도 MS보단 고집이 있어서 (그리고 무엇보다 Netscape의 직계후손이라서)UA를 깔끔하게 보냈습니다.

Mozilla/5.0 (X11;U;Linux i686;en-US;rv:1.8.1) Gecko/2006101022 Firefox/2.0

 

리눅스 X11환경에서 영문으로 돌아가는 Firefox 2.0 대충요런식입니다.
특히 여기서 Gecko라는 문구가 중요한데 당시 웹표준이 대두가 되면서 HTML5가 이슈가 되기 시작했습니다. 그 당시 HTML5의 지원을 제일 서두르던것이 Firefox의 Gecko엔진이었고 Firefox의 엔진인 Gecko를 쓰는지만으로 HTML5가 지원되는지 아닌지 판단하곤했습니다. (Gecko는 오픈소스였기에 Firefox기반브라우저가 우후죽순 있었습니다.)

여기서 그동안 IE를 쓰던 애플은 자기들만의 브라우저가 있어야겠다고 판단하고 오픈소스 엔진인 KHTML을 가지고 Webkit이라는 엔진을 발표한뒤 Safari라는 이름으로 브라우저를 내놓게 됩니다.

Webkit은 HTML5를 준수하는 브라우저 였지만 웹페이지는 이를 알 수가 없었고 Gecko와 호환된다는 명목으로 UA에 like Gecko라는 문구를 적습니다.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/532.0+ (KHTML, like Gecko) Version/4.0.3 Safari/531.9.2009


물론 자신의 이름도 꼭 뒤에 적어서 Safari인지 판단하도록 했습니다.

그리고 Webkit을 기반으로 한 Chrome이 등장하면서 또 한번의 격변이 일어나는데...

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chromium/15.0.871.0 Chrome/15.0.871.0 Safari/535.2


다시 개판이 되기 시작했습니다. 당시에는 Webkit을 이용한게 맞으니까 AppleWebkit이라고 적는건 이해하는데 뒤에 Safari도 함께 적었습니다. 그게 Webkit이 아닌 Safari라는 문구를 쓰는게 더 익숙했던 Webkit용 페이지 덕분에 그냥 Safari를 적었다고 합니다. 덕분에 크롬을 쓰면 애플홈페이지에서 맥 전용기능을 실행하려 들었다고 하네요.

추가로 IE11도 HTML5를 준수하면서 똑같이 like Gecko문구를 추가합니다.

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko


어쩌다보니 자바스크립트지원 여부를 판단하는 Mozilla라는 문구처럼 Gecko라는 문구는 HTML5지원여부를 판단하는 문구가 되어버렸고 Mozilla와 관계없는 모든 브라우저가 Mozilla라고 적고 역시 Gecko엔진을 쓰지 않는 모든 브라우저가 Gecko를 적는 요상한 현상이 일어났습니다.

여기에 크롬이 브라우저의 대세가 되고 HTML5의 특정 기능들이 크롬에서 가장 먼저구현되며 Chrome이라는 문구를 찾아 전용코드를 쓰는 일이 생기게 되었는데

Chromium으로 만들어진 Edge는 당연히 이를 지원하기에 Chrome이라는 문구를 넣었습니다

 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.19582


당연히 뒤에 자신이 Edge라는 문구를 추가해서요.

Mozilla에 Gecko에 Safari에 이젠 Chrome이라는 문구까지 UA에 들어가기 시작했습니다.

하하...이젠 개판이네...

,

※제목을 저렇게 해놓긴했지만 정확히 말하면 일반인이 생각하는 해커에 더 가깝습니다.
하지만 개발자는 곧 해커라고 볼 수있으니(안좋은 의미의 해커가 아니라 좋은 의미의 해커)그게그거 아닐까 싶습니다.

영화나 드라마등에서 개발자는 무슨 컴퓨터 앞에서 뚜드리고 뭔가 척!하면 짠하고 뭐가되는 그런 이미지입니다.
그런데 현실은 다들 알다시피 "이게 왜 이러지?"단계가 존재합니다. "생각한다-구현한다-기도한다"라는 개발자유머가 있을정도지요.

하지만 비개발자들은 개발을 맡기면 그냥 알아서 뿅하고 가져온다고 생각하는듯 합니다. 사실 개발의 80%가 디버깅이니 수없는 노가다끝에 만드는건데 말이지요.

개발자가 말하는 기능구현 = 이제 첫단추끼웠다. 이제 디버깅작업이다.
비개발자가 생각하는 기능구현 = 아무문제없이 완벽하다


PSP가 막 팔리던 시절 펌웨어 첫 해킹성공으로 사진한장이 공개됐는데 그냥 PSP화면에 "Hello, World!"가 띄워져있었습니다.
당연히 관련 커뮤니티는 난리났는데 당시 모 게시판에선 "고작 문구하나 띄운거가지고 뭔 호들갑이냐"라는 댓글을 달려있었습니다.
비개발자입장에선 "고작 문구"겠지만 이게 무엇을 의미하는거냐면 PSP라는 플랫폼에서 새로운 무언가를 만들수 있는 환경이 생겼다는겁니다.

사실 모든 개발환경을 갖추고 제일먼저하는건 "Hello World"를 띄우는겁니다. 해당 개발환경이 제대로 만들어진건지 확인하는것이지요.

비개발자들은 이 Hello World띄우는게 쉽다고 생각한거 같지만 개발자들입장에선 개발환경의 완성이라는 큰 의미인겁니다.
(이해가 안 된다면 집을 짓기위한 터다지기 작업이 완료됐다고 생각하시면 됩니다)

국내에선 디X인사이드 컴갤이나 Github갤에서 이런 요상한 글들이 많이 보이는데 거긴 아무래도 비개발자출신 자칭개발자들이 많아서 벌어지는듯 합니다. Hello World비하는 일상에 C99와 C17이 뭐가 다르냐고 하더군요. (Visual C++만 쓰는경우 이렇게 되곤합니다. 즉, 타 플랫폼 경험부족)

그러니까 개발자들에게 개발은 계단처럼 하나하나 밟아나가는 일입니다.
하지만 비개발자들은 개발이 짠하고 나오는걸로 착각을 자주합니다. 그러니 어렵게 하지말고 개발자들 힘들게 안 했으면 좋겠네요.

,