흥미로운 접근 잘 봤습니다. trigger 분류로 라우팅하는 발상은 아주 좋은 아이디어같습니다.
한 가지 궁금한 점: BM25 레이어의 토크나이저가 README에 명시 안 된 것 같은데 한국어 처리는 어떻게 가시나요? 기본 공백 토크나이저면 "검색하다"/"검색하는"이 별도 토큰이 되어서 한국어 주석·docstring 검색에서 recall이 많이 떨어질 텐데요.
multilingual-e5-small fallback이 있긴 하지만 BM25 레이어 자체의 한국어(cjk포함)처리 계획이 궁금합니다. (저도 seCall이라고 llm wiki앱을 만들면서 CJK 검색에 문제가 있어 Lindera ko-dic + Kiwi-rs 붙여 해결했는데, CTX는 trigger 라우팅
구조라 다른 접근 가능할 것 같아서요.)
깃헙이 이때까지 많은 역활을 한것은 사실이나, 제 기억으론 그 전까지는 오픈소스 프로젝트는 하는 사람들만 했고, 개인이 공개하는 경우는 많지 않았습니다. 심지어 회사내에서도 같은 팀들끼리만 공유하는 경우도 있었습니다. 그리고 오픈소스는 큰 프로젝트에 기여하는 사람으로 받아들여 주는게 큰 영광이었지, 개인의 소소한 프로젝트는 신경쓰는 사람들도 없었습니다.
개발 사회 분위기가 바뀌고, 공개 소프트웨어를 내놓고 자신의 실력을 인정 받는 장치로 사용되며, 결국엔 몇가지 DVCS에서 git이 더 널리 사용하게 되기도 하는등 여러 운이 따라주는게 시작이었다고 기억합니다. 경쟁상대들도 비슷한 서비스들을 제공했었지 깃헙만 특별히 잘해서 그렇진 않았다고 봅니다.
한국어와 영어를 동시에 말할 경우, 한국의 숫자를 영어로 얘기 또는 그 반대의 경우 굉장히 어려움을 느끼곤 합니다.
개발 하신 이 방법으로 적는 수의 읽는 경우의 혼돈을 해소할수도 있겠지만 (한국인, 중국인 등), 불행히도 말로 하는 경우는 방법이 없더군요.
밑에 의견처럼 국제적인 표준으로 쓸때에는 천 단위라, 참 난감한 경우입니다. 그리고 한국및 중국에서도 쓸때는 천단위로 쓴다고 알고 있습니다. 아마도 TTS 관련해서 도움이 될지도 모르겠지만, 해본 바로는 대부분의 한국어 TTS는 숫자를 10,000 이렇게 적어도 "만"으로 옳게 읽었다고 기억합니다.
어떤 경우네 만단위로 쓰는(write) 경우가 있는지, 어떤 실제 상황에서 (coding) 유용할지 케이스를 알려주시면 도움이 되겠습니다.
swift 에서는 따로 뭘 하지 않아도 바로 사용가능한 표기법이네요
특정 도메인의 단어를 미리 사전으로 만들어두고 참고할 수 있는 기능이 있으면 좋을 것 같습니다.
저는 이 문제를 해결하려고 hermes를 쓰기 시작했는데 나쁘지 않은거 같습니당 ㅎㅎ
tsboard.dev 사이트도 누보로 빌드된 건가요? 깔끔하고 좋아보입니다!
웹/모바일은 멀리서 바라 보기만 하고,
PC App(C++) 위주로 살아온 저에게는
Web 전체 역사적 변화 흐름을 잘 알려주는 글이네요.
덕분에 조각조각 알던 내용을 연결하여 보는 눈이 조금은 생긴 듯 합니다.
감사합니다. ~~
https://ko.wikipedia.org/wiki/…
이런 토론이 있네요.
흥미로운 접근 잘 봤습니다. trigger 분류로 라우팅하는 발상은 아주 좋은 아이디어같습니다.
한 가지 궁금한 점: BM25 레이어의 토크나이저가 README에 명시 안 된 것 같은데 한국어 처리는 어떻게 가시나요? 기본 공백 토크나이저면 "검색하다"/"검색하는"이 별도 토큰이 되어서 한국어 주석·docstring 검색에서 recall이 많이 떨어질 텐데요.
multilingual-e5-small fallback이 있긴 하지만 BM25 레이어 자체의 한국어(cjk포함)처리 계획이 궁금합니다. (저도 seCall이라고 llm wiki앱을 만들면서 CJK 검색에 문제가 있어 Lindera ko-dic + Kiwi-rs 붙여 해결했는데, CTX는 trigger 라우팅
구조라 다른 접근 가능할 것 같아서요.)
제 가치관, 취향과 맞아서인지 컨텐츠가 좋게 느껴지네요
(사실상 와드용)
토큰 절약과 컨텍스트 윈도우 절약은 겹치지만 같은 말은 아니라고 봅니다.
토큰 절약은 비용 문제이고, 컨텍스트 윈도우 절약은 모델의 작업 기억 품질 문제입니다. 대량 로그나 DOM snapshot을 그대로 넣으면 비용도 늘지만, 더 큰 문제는 모델이 중요한 단서를 노이즈 속에서 놓치거나 잘못 참조할 가능성이 커진다는 점입니다.
context-mode는 “적게 쓰자”보다 “컨텍스트에 무엇을 올릴지 통제하자”에 가까운 도구로 이해하는 게 맞아 보입니다.
"유저스페이스를 깨뜨리지 마라" vs "유저스페이스에서 스핀락 하지마라"
https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation
패치가 있긴 한데... 구독 서비스 저장소만 제공 되고 있습니다. CE 버전은 패치 안 됨. (9.7, 10.1 확인)
잘되나..
Rocky Linux 는 아직 패치 안 나온듯 하네요
RHEL
Almalinux
Rocky Linux
Rock Linux 사용 중인데 리부팅 못한다면 https://github.com/wgnet/wg.copyfail.patch 의 bpftool 로 차단이 유효합니다.
깃헙이 이때까지 많은 역활을 한것은 사실이나, 제 기억으론 그 전까지는 오픈소스 프로젝트는 하는 사람들만 했고, 개인이 공개하는 경우는 많지 않았습니다. 심지어 회사내에서도 같은 팀들끼리만 공유하는 경우도 있었습니다. 그리고 오픈소스는 큰 프로젝트에 기여하는 사람으로 받아들여 주는게 큰 영광이었지, 개인의 소소한 프로젝트는 신경쓰는 사람들도 없었습니다.
개발 사회 분위기가 바뀌고, 공개 소프트웨어를 내놓고 자신의 실력을 인정 받는 장치로 사용되며, 결국엔 몇가지 DVCS에서 git이 더 널리 사용하게 되기도 하는등 여러 운이 따라주는게 시작이었다고 기억합니다. 경쟁상대들도 비슷한 서비스들을 제공했었지 깃헙만 특별히 잘해서 그렇진 않았다고 봅니다.
어떤 빅테크도 브라우저를 버리지 않는 상황이 잘못된거 아닌가요
저도 비슷한것을 당한것같아요 opencode로 작업하는데 test 통과후에 완료하라고 했더니만 테스트 코드를 지워버리는...
담합하는건가 싶을 때도 있네요.
한국어와 영어를 동시에 말할 경우, 한국의 숫자를 영어로 얘기 또는 그 반대의 경우 굉장히 어려움을 느끼곤 합니다.
개발 하신 이 방법으로 적는 수의 읽는 경우의 혼돈을 해소할수도 있겠지만 (한국인, 중국인 등), 불행히도 말로 하는 경우는 방법이 없더군요.
밑에 의견처럼 국제적인 표준으로 쓸때에는 천 단위라, 참 난감한 경우입니다. 그리고 한국및 중국에서도 쓸때는 천단위로 쓴다고 알고 있습니다. 아마도 TTS 관련해서 도움이 될지도 모르겠지만, 해본 바로는 대부분의 한국어 TTS는 숫자를 10,000 이렇게 적어도 "만"으로 옳게 읽었다고 기억합니다.
어떤 경우네 만단위로 쓰는(write) 경우가 있는지, 어떤 실제 상황에서 (coding) 유용할지 케이스를 알려주시면 도움이 되겠습니다.
근데 저는 테슬라 타면서 물리버튼 필요성은 비상등 말고는 잘 모르겠던데..
저도 그렇지만, 개발씬은 과도하게 유행에 민감하다고 생각합니다. TUI 는 그저 GUI 를 제대로 만들 능력 혹은 의지가 없는 회사들이 주도하고 있을 뿐, 얼마나 많은 사람들이 TUI 를 쓰고 있는건지 모르겠네요.