微软'修复'Windows 11:打完人再送花
MicrosoftのWindows 11「修正」:殴った後の花束
Microsoft의 Windows 11 '수정': 때린 후 꽃 선물
La 'solución' de Microsoft para Windows 11: Flores después de la paliza
Microsofts 'Lösung' für Windows 11: Blumen nach der Prügel
TL;DR
Microsoft spent 4 years stuffing Windows 11 with ads, forced Copilot integrations, and bloatware. Now they announced a 7-point plan to 'fix' it. The author compares it to an abusive relationship: they beat you, then show up with flowers. The worst offenses (forced Microsoft accounts, telemetry that lies about being disabled, OneDrive auto-syncing your files) aren't even in the repair plan. The 'fix' targets visible UI annoyances while keeping the data harvesting infrastructure intact.
微软花了4年时间在Windows 11里塞满广告、强制Copilot集成和臃肿软件。现在他们宣布了7点'修复'计划。作者将其比作家暴关系:他们打你,然后拿着花来道歉。最严重的问题(强制微软账户、虚假的遥测禁用选项、OneDrive自动同步文件)根本不在修复计划里。
Microsoftは4年間Windows 11に広告、強制Copilot統合、ブロートウェアを詰め込んだ。今、7項目の「修正」計画を発表。著者はこれをDV関係に例える:殴っておいて花を持ってくる。最悪の問題(強制Microsoftアカウント、嘘のテレメトリ無効化、OneDriveの自動同期)は修正計画に入っていない。
Microsoft는 4년간 Windows 11에 광고, 강제 Copilot 통합, 블로트웨어를 채워넣었다. 이제 7가지 '수정' 계획을 발표했다. 저자는 이를 가정폭력에 비유한다: 때리고 나서 꽃을 들고 온다. 최악의 문제들(강제 Microsoft 계정, 거짓 텔레메트리 비활성화, OneDrive 자동 동기화)은 수정 계획에 포함되지 않았다.
Microsoft pasó 4 años llenando Windows 11 de anuncios, integraciones forzadas de Copilot y bloatware. Ahora anunciaron un plan de 7 puntos para 'arreglarlo'. El autor lo compara con una relación abusiva: te golpean y luego aparecen con flores. Los peores problemas (cuentas Microsoft obligatorias, telemetría que miente sobre estar desactivada, sincronización automática de OneDrive) ni siquiera están en el plan.
Microsoft hat 4 Jahre lang Windows 11 mit Werbung, erzwungenen Copilot-Integrationen und Bloatware vollgestopft. Jetzt kündigten sie einen 7-Punkte-Plan zur 'Behebung' an. Der Autor vergleicht es mit einer missbräuchlichen Beziehung: Sie schlagen dich und kommen dann mit Blumen. Die schlimmsten Vergehen (erzwungene Microsoft-Konten, Telemetrie die über Deaktivierung lügt, OneDrive Auto-Sync) sind nicht einmal im Reparaturplan.
Take
Microsoft could literally ship malware and call the uninstaller a 'customer experience improvement'. The fact that 'fewer ads' is supposed to impress anyone shows how completely they've lowered the bar.
微软可以直接发布恶意软件,然后把卸载程序叫做'客户体验改进'。'减少广告'居然能当卖点,说明他们把标准降到了地下室。
Microsoftはマルウェアを出荷してアンインストーラーを「顧客体験向上」と呼ぶことすらできる。「広告が減る」ことが売りになる時点で、基準は地に落ちている。
Microsoft는 멀웨어를 배포하고 제거 프로그램을 '고객 경험 개선'이라고 부를 수도 있다. '광고 감소'가 홍보 포인트가 된다는 것 자체가 기준이 바닥을 쳤다는 증거다.
Microsoft podría literalmente distribuir malware y llamar al desinstalador 'mejora de experiencia del cliente'. Que 'menos anuncios' sea un punto de venta muestra lo bajo que han puesto el listón.
Microsoft könnte buchstäblich Malware ausliefern und den Deinstaller 'Kundenerfahrungsverbesserung' nennen. Dass 'weniger Werbung' beeindrucken soll, zeigt wie tief die Messlatte gesunken ist.
#windows#microsoft#privacy#rant
Opera:回到1996年的网络(Opera 30周年)
Opera:ウェブを1996年に巻き戻す(Opera 30周年)
Opera: 웹을 1996년으로 되감기 (Opera 30주년)
Opera: Rebobina la Web a 1996 (Opera cumple 30)
Opera: Das Web zurück zu 1996 (Opera wird 30)
TL;DR
Opera celebrates its 30th anniversary with an interactive web experience letting you explore artifacts from 1995 to 2025. The site includes music, sound effects, and voiceovers as you journey through 30 years of web history. There's even a contest to submit your memory and win a trip.
Opera用一个互动网页体验庆祝30周年,让你探索1995年到2025年的网络文物。网站包括音乐、音效和配音,带你穿越30年的网络历史。还有提交回忆赢取旅行的比赛。
Operaが30周年を記念して、1995年から2025年までのウェブの遺物を探索できるインタラクティブな体験を公開。音楽、効果音、ナレーション付きで30年のウェブ史を旅する。思い出を投稿して旅行が当たるコンテストも。
Opera가 30주년을 기념하여 1995년부터 2025년까지의 웹 유물을 탐험할 수 있는 인터랙티브 웹 경험을 공개했다. 음악, 효과음, 내레이션과 함께 30년의 웹 역사를 여행한다. 추억을 제출하고 여행을 받을 수 있는 콘테스트도 있다.
Opera celebra su 30 aniversario con una experiencia web interactiva que te permite explorar artefactos de 1995 a 2025. El sitio incluye música, efectos de sonido y voces mientras viajas por 30 años de historia web. Incluso hay un concurso para enviar tu recuerdo y ganar un viaje.
Opera feiert seinen 30. Geburtstag mit einer interaktiven Web-Erfahrung, die dich Artefakte von 1995 bis 2025 erkunden lässt. Die Seite enthält Musik, Soundeffekte und Sprecher während du durch 30 Jahre Webgeschichte reist. Es gibt sogar einen Wettbewerb, bei dem du deine Erinnerung einreichen und eine Reise gewinnen kannst.
Take
Nostalgic marketing from a browser that sold its soul to a Chinese company running predatory lending apps. The irony of celebrating web history while being a footnote in it is ⁎chef's kiss⁎.
来自一个把灵魂卖给中国公司做掠夺性贷款App的浏览器的怀旧营销。一边庆祝网络历史一边沦为历史注脚,这讽刺简直绝了。
略奪的融資アプリを売る中国企業に魂を売ったブラウザからのノスタルジックマーケティング。ウェブの歴史を祝いながら自分は脚注になっているという皮肉が最高。
약탈적 대출 앱을 파는 중국 회사에 영혼을 판 브라우저의 향수 마케팅. 웹 역사를 축하하면서 자신은 역사의 각주가 되어버린 아이러니가 완벽하다.
Marketing nostálgico de un navegador que vendió su alma a una empresa china de préstamos abusivos. La ironía de celebrar la historia web mientras eres una nota al pie es perfecta.
Nostalgisches Marketing von einem Browser, der seine Seele an ein chinesisches Unternehmen für räuberische Kreditapps verkauft hat. Die Ironie, Webgeschichte zu feiern während man selbst eine Fußnote ist, ist perfekt.
#opera
终端日志文件查看器
ターミナル用ログファイルビューア
터미널용 로그 파일 뷰어
Visor de archivos de log para terminal
Log-Datei-Viewer fürs Terminal
TL;DR
lnav is an advanced log file viewer for the terminal that auto-detects file formats, decompresses files on the fly, and lets you merge, tail, search, filter and query logs. First commit was September 2009. It outperforms standard terminal tools on large files and has a SQLite interface for complex queries. No server or setup required.
lnav是一个高级终端日志查看器,可以自动检测文件格式、即时解压文件,让你合并、追踪、搜索、过滤和查询日志。第一次提交是2009年9月。在处理大文件时比标准终端工具更快,还有SQLite接口用于复杂查询。无需服务器或设置。
lnavは高度なターミナル用ログビューアで、ファイル形式を自動検出し、その場で解凍し、ログのマージ、テール、検索、フィルタ、クエリができる。最初のコミットは2009年9月。大きなファイルで標準ツールより高性能で、複雑なクエリ用のSQLiteインターフェースもある。サーバーもセットアップも不要。
lnav는 파일 형식을 자동 감지하고, 즉시 압축 해제하며, 로그를 병합, 추적, 검색, 필터링, 쿼리할 수 있는 고급 터미널 로그 뷰어다. 첫 커밋은 2009년 9월이다. 대용량 파일에서 표준 터미널 도구보다 빠르고 복잡한 쿼리를 위한 SQLite 인터페이스가 있다. 서버나 설정 불필요.
lnav es un visor de logs avanzado para terminal que detecta formatos automáticamente, descomprime archivos al vuelo, y te permite combinar, seguir, buscar, filtrar y consultar logs. El primer commit fue en septiembre 2009. Supera a las herramientas estándar en archivos grandes y tiene interfaz SQLite para consultas complejas. Sin servidor ni configuración.
lnav ist ein fortschrittlicher Terminal-Log-Viewer der Dateiformate automatisch erkennt, Dateien on-the-fly entpackt, und dich Logs zusammenführen, verfolgen, suchen, filtern und abfragen lässt. Der erste Commit war September 2009. Er übertrifft Standardtools bei großen Dateien und hat ein SQLite-Interface für komplexe Abfragen. Kein Server oder Setup nötig.
Take
Fifteen years of development on a log viewer. Meanwhile, most of us are still doing `tail -f | grep`. The commitment to solving a 'boring' problem well is genuinely admirable.
一个日志查看器开发了十五年。与此同时,我们大多数人还在用`tail -f | grep`。对'无聊'问题的这种执着确实令人钦佩。
ログビューアに15年の開発。一方、私たちのほとんどはまだ`tail -f | grep`を使っている。「退屈な」問題を正しく解決することへのコミットメントは本当に賞賛に値する。
로그 뷰어를 15년간 개발했다. 한편, 우리 대부분은 아직도 `tail -f | grep`을 쓴다. '지루한' 문제를 제대로 해결하려는 헌신은 진정으로 존경스럽다.
Quince años de desarrollo en un visor de logs. Mientras tanto, la mayoría seguimos usando `tail -f | grep`. El compromiso de resolver bien un problema 'aburrido' es genuinamente admirable.
Fünfzehn Jahre Entwicklung an einem Log-Viewer. Währenddessen machen die meisten von uns immer noch `tail -f | grep`. Das Engagement ein 'langweiliges' Problem gut zu lösen ist wirklich bewundernswert.
#terminal#devtools#logging#cli
Ripgrep比grep、ag、git grep、ucg、pt、sift都快(2016)
Ripgrepはgrep、ag、git grep、ucg、pt、siftより速い(2016)
Ripgrep은 grep, ag, git grep, ucg, pt, sift보다 빠르다 (2016)
Ripgrep es más rápido que grep, ag, git grep, ucg, pt, sift (2016)
Ripgrep ist schneller als grep, ag, git grep, ucg, pt, sift (2016)
TL;DR
The 2016 blog post that introduced ripgrep, a Rust-based search tool that combines the usability of The Silver Searcher with the performance of GNU grep. Through 25 benchmarks, burntsushi proved ripgrep was the fastest while having proper Unicode support. The post dives deep into regex engines, file traversal, and why memory maps don't always help. It's been 10 years and ripgrep remains the standard.
2016年介绍ripgrep的博客文章,这是一个基于Rust的搜索工具,结合了The Silver Searcher的易用性和GNU grep的性能。通过25个基准测试,burntsushi证明了ripgrep最快且有正确的Unicode支持。文章深入探讨了正则引擎、文件遍历以及为什么内存映射不总是有帮助。十年过去了,ripgrep仍然是标准。
2016年にripgrepを紹介したブログ記事。RustベースのサーチツールでThe Silver Searcherの使いやすさとGNU grepの性能を兼ね備える。25のベンチマークでburntsushiはripgrepが最速かつ適切なUnicodeサポートを持つことを証明した。正規表現エンジン、ファイル走査、メモリマップが常に役立つわけではない理由を深堀り。10年経った今もripgrepが標準だ。
2016년 ripgrep을 소개한 블로그 포스트. The Silver Searcher의 사용성과 GNU grep의 성능을 결합한 Rust 기반 검색 도구다. 25개의 벤치마크를 통해 burntsushi는 ripgrep이 가장 빠르면서 적절한 유니코드 지원을 갖췄음을 증명했다. 정규식 엔진, 파일 탐색, 메모리 맵이 항상 도움이 되지 않는 이유를 깊이 파고든다. 10년이 지났지만 ripgrep은 여전히 표준이다.
El post de 2016 que introdujo ripgrep, una herramienta de búsqueda basada en Rust que combina la usabilidad de The Silver Searcher con el rendimiento de GNU grep. A través de 25 benchmarks, burntsushi demostró que ripgrep era el más rápido con soporte Unicode adecuado. El post profundiza en motores regex, recorrido de archivos y por qué los mapas de memoria no siempre ayudan. Han pasado 10 años y ripgrep sigue siendo el estándar.
Der Blogpost von 2016 der ripgrep vorstellte, ein Rust-basiertes Suchwerkzeug das die Benutzerfreundlichkeit von The Silver Searcher mit der Leistung von GNU grep kombiniert. Durch 25 Benchmarks bewies burntsushi dass ripgrep am schnellsten ist und ordentliche Unicode-Unterstützung hat. Der Post geht tief in Regex-Engines, Dateidurchquerung und warum Memory Maps nicht immer helfen. 10 Jahre später ist ripgrep immer noch der Standard.
Take
This article single-handedly changed how an entire generation of developers searches code. It's also a masterclass in benchmarking done right. Burntsushi spent 2.5 years on text search 'in his free time' which is either dedication or insanity. Possibly both.
这篇文章凭一己之力改变了整整一代开发者搜索代码的方式。这也是正确做基准测试的大师课。Burntsushi'业余时间'花了2.5年研究文本搜索,这要么是执着要么是疯狂。可能两者都是。
この記事は一世代の開発者のコード検索方法を変えた。正しいベンチマークの取り方のマスタークラスでもある。Burntsushiは「暇な時間に」テキスト検索に2.5年を費やした。献身か狂気か。おそらく両方。
이 글 하나가 한 세대 개발자들의 코드 검색 방식을 바꿨다. 올바른 벤치마킹의 마스터클래스이기도 하다. Burntsushi는 '여가 시간에' 텍스트 검색에 2.5년을 썼다. 헌신인지 광기인지. 아마 둘 다.
Este artículo cambió por sí solo cómo toda una generación de desarrolladores busca código. También es una clase magistral sobre cómo hacer benchmarks correctamente. Burntsushi pasó 2.5 años en búsqueda de texto 'en su tiempo libre', lo cual es dedicación o locura. Posiblemente ambas.
Dieser Artikel hat im Alleingang verändert wie eine ganze Generation von Entwicklern Code durchsucht. Es ist auch eine Meisterklasse im richtigen Benchmarken. Burntsushi hat 2.5 Jahre 'in seiner Freizeit' an Textsuche verbracht, was entweder Hingabe oder Wahnsinn ist. Möglicherweise beides.
#rust#cli#search#performance
微服务和分布式对象第一定律(2014)
マイクロサービスと分散オブジェクトの第一法則(2014)
마이크로서비스와 분산 객체의 첫 번째 법칙 (2014)
Microservicios y la Primera Ley de Objetos Distribuidos (2014)
Microservices und das Erste Gesetz Verteilter Objekte (2014)
TL;DR
Fowler explains why his 'First Law of Distributed Objects' (don't distribute your objects) doesn't contradict microservices. Distributed objects tried to make remote/local calls transparent, which fails because remote calls are slower and can fail. Microservices use coarse-grained APIs designed for remote communication from the start. But Fowler warns: distribution is a complexity booster, and pushing complexity into interconnections makes it harder to debug. His default is still to prefer monoliths.
Fowler解释了为什么他的'分布式对象第一定律'(不要分布你的对象)与微服务并不矛盾。分布式对象试图让远程/本地调用透明,这行不通,因为远程调用更慢且可能失败。微服务从一开始就使用为远程通信设计的粗粒度API。但Fowler警告:分布式是复杂性放大器,把复杂性推到服务间连接处会更难调试。他默认仍然倾向于单体架构。
Fowlerは「分散オブジェクトの第一法則」(オブジェクトを分散させるな)がマイクロサービスと矛盾しない理由を説明する。分散オブジェクトはリモート/ローカル呼び出しを透過的にしようとしたが、リモート呼び出しは遅く失敗する可能性があるため失敗する。マイクロサービスは最初からリモート通信用に設計された粗粒度APIを使う。しかしFowlerは警告する:分散は複雑性ブースターであり、複雑性をサービス間の接続に押し込むとデバッグが難しくなる。彼のデフォルトは今もモノリス優先だ。
Fowler는 그의 '분산 객체의 첫 번째 법칙'(객체를 분산시키지 마라)이 마이크로서비스와 모순되지 않는 이유를 설명한다. 분산 객체는 원격/로컬 호출을 투명하게 만들려 했지만, 원격 호출은 더 느리고 실패할 수 있어서 실패한다. 마이크로서비스는 처음부터 원격 통신용으로 설계된 굵은 입자의 API를 사용한다. 하지만 Fowler는 경고한다: 분산은 복잡성 부스터이며, 복잡성을 서비스 간 연결로 밀어넣으면 디버깅이 어려워진다. 그의 기본은 여전히 모놀리스 선호다.
Fowler explica por qué su 'Primera Ley de Objetos Distribuidos' (no distribuyas tus objetos) no contradice los microservicios. Los objetos distribuidos intentaron hacer transparentes las llamadas remotas/locales, lo cual falla porque las llamadas remotas son más lentas y pueden fallar. Los microservicios usan APIs de grano grueso diseñadas para comunicación remota desde el inicio. Pero Fowler advierte: la distribución amplifica la complejidad, y empujar la complejidad a las interconexiones dificulta la depuración. Su preferencia sigue siendo el monolito.
Fowler erklärt warum sein 'Erstes Gesetz Verteilter Objekte' (verteile deine Objekte nicht) Microservices nicht widerspricht. Verteilte Objekte versuchten Remote/Lokale Aufrufe transparent zu machen, was scheitert weil Remote-Aufrufe langsamer sind und fehlschlagen können. Microservices nutzen von Anfang an grobkörnige APIs die für Remote-Kommunikation designt sind. Aber Fowler warnt: Verteilung ist ein Komplexitätsverstärker, und Komplexität in Verbindungen zu schieben macht Debugging schwerer. Sein Standard ist immer noch Monolithen zu bevorzugen.
Take
Written in 2014 and still the most sensible take on microservices. Everyone read the first half ('microservices are okay') and ignored the second half ('but seriously, consider a monolith first'). Ten years of distributed system debugging later, we're finally listening.
写于2014年,至今仍是关于微服务最理性的观点。所有人都读了前半部分('微服务没问题'),忽略了后半部分('但认真考虑先用单体')。十年分布式系统调试后,我们终于在听了。
2014年に書かれ、今でもマイクロサービスについて最も理性的な見解。みんな前半(「マイクロサービスは大丈夫」)を読んで後半(「でも真剣にまずモノリスを検討して」)を無視した。10年の分散システムデバッグの後、ようやく聞いている。
2014년에 쓰여져 아직도 마이크로서비스에 대한 가장 합리적인 견해다. 모두가 전반부('마이크로서비스는 괜찮다')를 읽고 후반부('하지만 진지하게 먼저 모놀리스를 고려해라')를 무시했다. 10년의 분산 시스템 디버깅 후, 드디어 듣고 있다.
Escrito en 2014 y sigue siendo la visión más sensata sobre microservicios. Todos leyeron la primera mitad ('los microservicios están bien') e ignoraron la segunda ('pero en serio, considera primero un monolito'). Diez años de depuración de sistemas distribuidos después, finalmente estamos escuchando.
Geschrieben 2014 und immer noch die vernünftigste Ansicht zu Microservices. Alle lasen die erste Hälfte ('Microservices sind okay') und ignorierten die zweite ('aber ernsthaft, erwäge zuerst einen Monolith'). Zehn Jahre Debugging verteilter Systeme später hören wir endlich zu.
#fowler