이런 방식은 절대 성공할 수 없다고 봅니다. 이미 웹에서 한 번 실패했잖아요. 규모가 좀 있는 곳에서 안 하면 끝이죠.
OS에 현대적이고 자세한 권한 시스템이 있어야 해결할 수 있는 문제라고 봅니다. Android의 것과 비슷하지만 고급 사용자들은 좀 더 세세하게 제어할 수 있게요. 기본적으로 각 앱의 권한을 최소화하고 사용자가 무엇을 허용할지 선택해야죠.
짜증나는 글이네요. 자바스크립트를 켜 뒀다고 팝업으로 내용을 가리는 사이트 자체 문제부터 시작해서 글 자체도 내용이 빈약하고요.
내보내기 문제는 내보내고 나서 약간의 수정이 필요하고 그래서 그 파일이 클라우드에 업로드되면 보안 문제가 생긴다는 주장인데... 로컬에서 내보내고 가져올 수 있는데 왜 클라우드에 업로드하나요? 그리고 수정이 필요하지 않은 다른 제품들도 파일로 내보내고 가져오지 않나요? 그럼 똑같이 보안 문제가 생기겠네요. 애초에 다른 폴더도 아니고 Downloads 폴더를 클라우드에 동기화하는 사람이 있나요?
나머지 부분은 개선 과정에서 있었고 이제는 어느 정도 해결된 문제나 지극히 개인적인 경험을 확대하는 주장들이네요. Wayland 관련 문제는 이슈를 읽어 보니 몇몇 컴포지터의 문제처럼 보이고요. 제 환경의 Wayland에서는 아주 잘 작동하네요.
클라이언트가 아쉽다는 점 자체는 공감합니다만 이것이 '추천하지 않는다' 는 극단적인 결론의 근거가 되지는 못한다고 생각합니다.
보안 관련 부분은 길게 늘여쓴 글에 비해 빠르게 고쳐진 것들이고 26년 문제는 Bitwarden의 문제도 아니네요.
또 남은 문제는 FOSS 프로젝트가 아니고 벤처 투자를 받는다... 인데 이건 정말 어쩌라고? 정도의 반응밖에 못 하겠네요. FOSS 프로젝트가 이미 시장에 존재할 때 할 말 아닌가요? 벤처 투자를 받지만 오픈소스 클라이언트가 있는 프로젝트를 버리고 100% 비공개로 진행되는 프로젝트를 쓸까요?
그래서 나온 글의 결론은 '이것저것 나눠서 보관할 것이고 대부분의 경우 다른 타사 서비스를 쓰겠다' 인데 무슨 서비스인지 언급이 없네요. 위에서 'Bitwarden은 사실상 SaaS를 판매하는 것이다' '벤처 투자를 받았는데 왜 오픈소스냐' 같은 표현을 써 가며 공격해놓고 마지막 결론은 타사 SaaS를 쓰겠다. 오픈소스인지 말해줄 수는 없지만 대체 서비스를 쓰겠다. 어쩌라는 건가요?
또 글 전체적으로 언어의 선택과 성능이나 메모리 사용량을 은근히 연결짓는 마인드가 깔려 있는데 웃기네요. 뭐 Rust로 썼으면 공급망 공격에서 안전했을 것이다. Microsoft .NET 으로 만들어서 메모리 사용량이 3배나 많다... 공급망 공격이든 메모리 사용량이든 언어랑은 별 상관 없습니다. 특히 .NET은 사용 방식에 따라 힙과 GC 없이도 사용할 수 있는 언어죠. Rust 팬보이라고 불리는 족속들이 하는 말을 그대로 하는군요. 한심하네요.
Git 명령어를 보여주지 마세요. 실제 git 명령어는 숨기세요.가 고정되어 있는게 조금 아쉽네요.
학습자가 평생 Git 명령어를 회피한 채 살 수는 없으니, 학습자의 레벨에 따라 처음에는 Git 명령어를 숨기다가, 나중엔 병행 출력하고, 마지막으론 해당 스킬을 떼고 쓸 수 있는 방향이 되면 더 좋을 것 같습니다!
그러면 크로맥스가 더 고가에 팔려야 하는 이유는 어디에...
크로맥스 출시를 위한 추가비용이 발생한다 까진 그렇다 치는데
그게 최종 판매가에 반영되어야 할정도로 유의미한건지
이런 방식은 절대 성공할 수 없다고 봅니다. 이미 웹에서 한 번 실패했잖아요. 규모가 좀 있는 곳에서 안 하면 끝이죠.
OS에 현대적이고 자세한 권한 시스템이 있어야 해결할 수 있는 문제라고 봅니다. Android의 것과 비슷하지만 고급 사용자들은 좀 더 세세하게 제어할 수 있게요. 기본적으로 각 앱의 권한을 최소화하고 사용자가 무엇을 허용할지 선택해야죠.
짜증나는 글이네요. 자바스크립트를 켜 뒀다고 팝업으로 내용을 가리는 사이트 자체 문제부터 시작해서 글 자체도 내용이 빈약하고요.
내보내기 문제는 내보내고 나서 약간의 수정이 필요하고 그래서 그 파일이 클라우드에 업로드되면 보안 문제가 생긴다는 주장인데... 로컬에서 내보내고 가져올 수 있는데 왜 클라우드에 업로드하나요? 그리고 수정이 필요하지 않은 다른 제품들도 파일로 내보내고 가져오지 않나요? 그럼 똑같이 보안 문제가 생기겠네요. 애초에 다른 폴더도 아니고 Downloads 폴더를 클라우드에 동기화하는 사람이 있나요?
나머지 부분은 개선 과정에서 있었고 이제는 어느 정도 해결된 문제나 지극히 개인적인 경험을 확대하는 주장들이네요. Wayland 관련 문제는 이슈를 읽어 보니 몇몇 컴포지터의 문제처럼 보이고요. 제 환경의 Wayland에서는 아주 잘 작동하네요.
클라이언트가 아쉽다는 점 자체는 공감합니다만 이것이 '추천하지 않는다' 는 극단적인 결론의 근거가 되지는 못한다고 생각합니다.
보안 관련 부분은 길게 늘여쓴 글에 비해 빠르게 고쳐진 것들이고 26년 문제는 Bitwarden의 문제도 아니네요.
또 남은 문제는 FOSS 프로젝트가 아니고 벤처 투자를 받는다... 인데 이건 정말 어쩌라고? 정도의 반응밖에 못 하겠네요. FOSS 프로젝트가 이미 시장에 존재할 때 할 말 아닌가요? 벤처 투자를 받지만 오픈소스 클라이언트가 있는 프로젝트를 버리고 100% 비공개로 진행되는 프로젝트를 쓸까요?
그래서 나온 글의 결론은 '이것저것 나눠서 보관할 것이고 대부분의 경우 다른 타사 서비스를 쓰겠다' 인데 무슨 서비스인지 언급이 없네요. 위에서 'Bitwarden은 사실상 SaaS를 판매하는 것이다' '벤처 투자를 받았는데 왜 오픈소스냐' 같은 표현을 써 가며 공격해놓고 마지막 결론은 타사 SaaS를 쓰겠다. 오픈소스인지 말해줄 수는 없지만 대체 서비스를 쓰겠다. 어쩌라는 건가요?
또 글 전체적으로 언어의 선택과 성능이나 메모리 사용량을 은근히 연결짓는 마인드가 깔려 있는데 웃기네요. 뭐 Rust로 썼으면 공급망 공격에서 안전했을 것이다. Microsoft .NET 으로 만들어서 메모리 사용량이 3배나 많다... 공급망 공격이든 메모리 사용량이든 언어랑은 별 상관 없습니다. 특히 .NET은 사용 방식에 따라 힙과 GC 없이도 사용할 수 있는 언어죠. Rust 팬보이라고 불리는 족속들이 하는 말을 그대로 하는군요. 한심하네요.
Git 명령어를 보여주지 마세요. 실제 git 명령어는 숨기세요.가 고정되어 있는게 조금 아쉽네요.학습자가 평생 Git 명령어를 회피한 채 살 수는 없으니, 학습자의 레벨에 따라 처음에는 Git 명령어를 숨기다가, 나중엔 병행 출력하고, 마지막으론 해당 스킬을 떼고 쓸 수 있는 방향이 되면 더 좋을 것 같습니다!
저도 이 글이 사이트의 본질을 해친다고 생각하지 않습니다. +1
저는 개발자 입장에서 이 글이 사이트의 본질을 해친다고 생각하지 않습니다.
이 사이트는 개발에 대한 지식을 공유하고, 개발은 문제를 기술로 해결하는 것이며, 이 글은 바이브코더의 어려움을 에이전트 스킬로 해결한 내용의 공유이므로 전혀 문제가 없다는게 제 의견입니다.
https://fairy.hada.io/explore
이제 꽤 많은 프로젝트들이 등록 되어서요. 등록된 프로젝트를 둘러보는 페이지를 만들었습니다.
다른 프로젝트들도 살펴보시고 후원 많이 해주세요!
등록하신 프로젝트의 웹사이트에 og:image 태그를 등록하시면 그 소셜 이미지를 가져와서 이쁘게 보입니다.
탐색페이지에서 자신의 프로젝트가 안보인다면 설정페이지 하단에서 프로젝트 탐색페이지에 보이도록 신청하시면 됩니다.
학위 논문 축하드립니다 !
테스트할 명세가 명확하면 코딩 에이전트로 워크플로우 짜서 수렴시키는 접근이 잘 먹히는 것 같아요. vinext, pretext같은 사례도 떠오르네요.
다른 얘기지만, 혹시 저널에 css 서빙 한번 확인해주실 수 있을까요...? 시간이 꽤 흘렀어도 주변에 소개하고 싶은 좋은 글들이 많은데 데스크톱으로 접속하면 css 로드가 안되어서요 ㅠㅠ
그러게요 실질적인지 모르겠네요.. 한 두번 더쓰면 토큰 더 사용하지 않을까 싶은데..
대시보드 동작 영상 (39초): https://drive.google.com/file/d/…
상세 내용: https://dev.to/jaewon_jang_d63fddcf69ac2/…
Claude mem이랑 caveman이랑 섞은느낌이네요
해당 프로젝트가 활성화되려면 아라비아 숫자-한문 변환기 같은 기능이 필요할 것 같은데 의미가 있을지는 모르겠네요.
안되는거 같아요. 뭔가 붙어야 인식이 되는듯 합니다.
쌩 케이블만으로 되나요 (반대쪽엔 아무 것도 연결안된)
음 천단위로 쓰는게 세계 공통인데.. 약간 kg 대신 파운드 쓰자고 주장하는 느낌 같기도 하네요.. 유럽에서도 1,000이 아니라 1.000 써서 에러 많은데
아직은 햇갈리지만 익숙해지면 천 단위로 구분하는것보다 편할것같네요
다행히 CommonMark 스펙에 따르면 Markdown의
_문법은 단어 경계에서만 동작합니다!마크다운에서 표기할때 아주 문제가 많을것같아요...
참신한 아이디어네요
사용자에게 불편을 초래하는 결과가 될 수도 있지만 참여해야 이용할 수 있다. 고 강제시키면 되지 않을까요?