Samat Galimov

@sult новые батарейки сами себя не продадут! на самом деле просто как джобс ушел — никто пиздюлей не выдает :(

навсегда останется для меня загадкой то, почему Apple спрятала меню с настройкой лимита зарядки туда, куда она его спрятала

@Niketas кетчуп не портится!

Как объяснить феномен того, что майонез и кетчуп всегда на верхней полке боковой дверцы? Хотя случаются извращенцы, которые хранят это и на нижних полках и даже внутри холодильника.

@friend super creepy. should i now buy my kids and my God, too? oh wait...

Introducing friend.

Short recap (I hope you don't mind) The problem. Traditional multiplexers (tmux, Zellij, screen) sit between your terminal emulator and the pty, causing double parsing and duplicated state processing. Their terminal-emulation layer is also slow compared to modern terminals like Ghostty, Kitty, or Alacritty — sometimes 100x+ — so putting one in front makes a fast terminal feel slow. Difference 1 — distributed synchronized state machines. They're going all in on libghostty. When a client attaches, the server pauses pty processing and sends a custom bit-by-bit binary protocol carrying just enough screen state (visible content, dimensions, cursor, mouse) to render immediately, then a "ready frame" — at which point you can already type, select, and scroll. Then, instead of sending screen diffs like tmux does, the server tees raw pty bytes to every client, ssh-style, assuming each client runs a compliant, fast emulator. So the client is essentially an ssh client with no middle-man parsing; a slow server can't slow down client rendering. Input is serialized back to the authoritative side — one writer, many readers. A misbehaving client only corrupts its own view; the server stays correct. Scrollback streams in the background, newest to oldest, so you briefly see a loading state. Each client owns its own viewport, fixing tmux's annoyance where one person scrolling scrolls everyone. Out-of-sync clients just restart the handshake. The cost: every client must be smart and compliant — which is exactly what libghostty (no dependencies, lightweight, runs everywhere) is for. Difference 2 — native splits. tmux draws splits inside one terminal screen and needs a terminal to display at all. Superlogical ships native apps — browser, mobile, multiple OSes — where each split is a native tab/window/split with its own protocol connection, one-to-one with a pty. You can also attach a single stream by ID from an ordinary terminal like Kitty; for terminals that don't speak the protocol there's a compatibility mode that puts a libghostty terminal in the middle — same tradeoff as existing multiplexers, but on a faster, more compatible core. Whether to support in-window multiplexing in that legacy mode is undecided. Difference 3 — feature velocity. Responding to Kovid Goyal's criticism that tmux/screen adopt new features slowly (forcing clever workarounds for things like the Kitty graphics protocol): Mitchell concedes the structural point stands — terminal features are whatever libghostty supports server-side — but argues libghostty is more feature-rich, faster to adopt, and open to bleeding-edge features so long as the embedder can toggle them. He closes by noting this covers only the terminal side; more of the project comes later.

Let's talk a bit about what makes the Superlogical multiplexer different architecturally from traditional terminal multiplexers! There's a lot (a LOT) more coming, but wanted to share a little bit about the terminal-specific part compared to tmux and zellij.

for those who prefer reading: It's really awesome to see how excited people are about the multiplexer we're building at Superlogical. I know there's a lot of questions and I promise we're going to give a lot of answers as we get closer and closer to product launches. And we have a lot of exciting devlogs and open source drops and other things planned, but to just sort of start stuff off very casually. Just recording in my home office, I want to talk about a little bit architecturally of why the terminal multiplexer. Part of our vision is architecturally different to a traditional multiplexer. So traditionally the way a multiplexer works, we'll just use TMUX as an example, but this applies to pretty much all of the major ones out there is that you have your terminal emulator and then your terminal emulator runs the multiplexer and then the multiplexer runs the final pty, which is your shell, which has connected directly to your shell or editor or whatever it is. And this introduces some overhead because without the multiplexer it would just be your terminal directly talking to the pty. And so you end up getting double parsing, double state processing, just duplicated work. And historically, just factually speaking, here, tmux, Zellij screen, these types of multiplexers, their terminal emulator like IO part is fairly slow compared to a modern terminal like Ghosty or Kitty or even Alacrity that are, that are sometimes 100 plus times faster. And so when you put something in front of it, you're just, you're sort of like getting that slow experience in a fast terminal, which sucks. So let's talk about the first thing that we're doing differently at Superlogical. So I obviously am one of the creators of Lib Ghosty and we are just really sort of unapologetically going all in on LibgoSD. And one of the ways we're doing that is that the way our terminal multiplexer works is when a client connects to the server libgo. See, the server part that actually is connected to the PTY pauses processing at that moment when a client is connecting of the current PTY bytes. Everything I'm about to describe here happens imperceptibly fast. But what we do is we pause what's happening and then we send down a binary protocol, a custom hand designed, bit by bit binary protocol down to the client that's connecting, which if it's Lib Ghosty just built in, could process this. If it's not lib ghosty, it's still, it's a binary protocol. Anyone could parse, but we send out a binary protocol. The binary protocol is constructed in a way that we send down just enough terminal state, screen state, you know, what's currently visible on the screen, dimensions, mouse, cursor state, things like that. We send out just enough so that the client could start rendering, could start showing you a terminal as quickly as possible. We defer for later things like scrollback history that's going to come in the background later. So we send down just enough that the terminal is visible. At that point we send a frame type called a ready frame. When the client reaches the ready frame, they're able to immediately show the terminal and the user could start doing selection, could start typing on their keyboard, could start scrolling, all that sort of stuff. And then the core sort of server part unpauses, starts processing PTY bytes. But instead of sending down, this is a big difference. Instead of sending down screen diffs, screen tmux, zellage, all these things, what they do is they keep track of the screen and they send down a diff of what's changing on the screen. Instead of that, we take the pty bytes and we tee them off to all the clients and we send them raw like ssh to all the clients. And we assume that everybody is running a compliant performant, correct terminal emulator. Basically we assume you're running Lib ghosty everywhere. Again, it doesn't have to be, but we just assume that. And so what you end up getting is that your terminal multiplexer client that's attached to it is basically like an SSH client. It's connected directly to the PTY stream. There is no internal parsing. If the server actually starts parsing slower, the client is still parsing at full speed, it doesn't matter. And then when we get events such as keyboard entry on the client side, you do have to send that over to the authoritative central side and we serialize all the input. So there's still sort of one writer, there's multiple readers, and we just assume we have this sort of distributed system of synchronized finite state machines and these terminal emulators. If one of the terminal emulators starts processing incorrectly, you're just going to see the wrong data on the client side. But the authoritative side doesn't depend on any of that. And so the central server is still always going to be correct and up to date. And then all the while this is happening, we are streaming in the background. While we're still processing bytes, we are streaming the scroll back into it. So kind of what you see is when you first load in, say you have a full 10,000 line scroll back or something, you could scroll and you're just going to see blank with sort of a loading state, like it's just not there yet. Like I said, all this happens pretty fast. So you're not going to. Unless you're on a very slow Internet connection, you're not really going to see that, but you're going to see a loading state. And we sort of send the history back, newest to oldest. So the most recent scrollback is there just chunk by chunk. And so you get full native scrollback. Everybody is allowed to do their own text selection, their own viewport. Like sort of famously, infamously, in tmux, if you have multiple clients attached to the same TMUX session, when one of them scrolls, it scrolls everybody's window. Very annoying. So you're going to actually be able to scroll on your own because the client fully owns the viewport state. And yeah, that's sort of the idea of it. If a client is ever sort of out of sync for any reason, it could just restart this process. You know, start from the beginning, reset the terminal frames. But that's sort of the core architectural difference. It gets rid of the performance overhead of a traditional terminal multiplexer. It gets rid of the sort of man in the middle style effect of a traditional multiplexer. But it does require that every connecting client be a very smart, high functioning, compliant client. And the key to that is Libgosi runs everywhere, has no dependencies, it's lightweight, it's fast. That's the answer to that. Another thing that is sometimes brought up is that it's the way multiplexers work, like TMUX and screens on is they handle splits themselves. They split the screen up like one terminal screen. If you're in again Kitty or Ghosty, they split that screen up themselves. And so the terminal emulator might support native windows, might support native tabs, but it's not able to represent that. This is also something that the way we're addressing is that one we have native applications. And so TMUX requires a terminal emulator to view its content. Ours will not. We're going to be shipping native applications, they're going to work in the browser, they're going to work on mobile, they're going to work on a variety of operating systems. And we represent each split using native tabs, native windows, native splits, and each one has its own connection to this binary protocol that I mentioned. And so they're sort of their own standalone systems, one to one to a pty. You're not going to get the multiplexing within a window like you normally do. We're still sort of discussing whether we'll have a legacy mode just for other terminal emulators to support that. Not certain yet. But we will also have the ability in any terminal that you will be able to connect to one stream. So if you're in Kitty and you want to connect to the super logical multiplexer and you want to connect to one terminal, you could specify it by ID and we will sort of render it directly into that terminal. Obviously, you know, Kitty, something like Kitty today doesn't understand our binary protocol, may never understand our binary protocol. I don't know. In those cases we will have a compatibility mode that does what traditional multiplexers do, which is we put a Libgosi terminal in the middle and that's the same trade off as other multiplexers. So we're not any worse there. I would say we're much better because Libgosd is a much more performant compatible core, but architecturally it's going to be identical there. If you're in this legacy mode, but if you use our native clients or if your client understands the this binary protocol, which is predominantly part of Libgosi, so an open protocol, then you will not have this overhead. And another point Covid particularly brings up is that it's hard to design new features. Things like TMUX and Screen and so on are somewhat slow. I can't really quantify that because it really varies. But in general they're relatively slow at adopting new features like things like TMUX support, Kitty graphics protocol, Kitty image protocol. So Covid had to go to great lengths in order to create very clever workarounds for that. And I think, you know that's going to be true here, right? Like the. The features of the terminal are going to be the features of the Libgosi support in the server. However, Libgosi is much more feature rich. We're much faster at adopting new terminal features and we are much more open to adopting bleeding edge terminal features as long as they can sort of be turned on and off by the embedder. That's sort of the stance we take. And so philosophically, generally this feedback is still valid, the critical feedback here is still valid, but I think in practice we've shown so far that we're quite innovative and quite fast at integrating these new features. So those are just three things I think there were three. Three things I want to talk about. The big one just being the huge architectural difference of the synchron distributed state machines of terminal emulators. That's going to be the thing that really makes a big difference for how this multiplexer works. But again, this is only the terminal side of it. There's a lot more interesting parts to this that we will get into as time goes on. See ya.

@danpeguine Tech is cool though!

@danpeguine Putting hearts over their faces is so strange, I dunno why it’s popular

I gave my kids a way to chat with their grandparents via WhatsApp. But without screens! This box lives in their bedroom, they press the massive blue button to record a voice message, and the message is sent to a group with both grandparents. It’s two-way so when the grandparents send a message back, there’s a ringtone (that we chose together) and the kids run to their room to listen. The grandparents even get a “listened” notification with a small headphones WhatsApp reaction. When the kids are away or asleep, the messages queue until their return. There are obviously quiet hours at night. My son and I built this over the past few weeks, iterating on the UX. The kids and grandparents absolutely love it! I love that they are in direct contact without me in the middle and without screens.

@uncledoomer Kids?

single women, single men, and married women earn roughly the same, and it's just married men that out earn everybody else. insane. what could possibly cause a married man to want to earn more money so badly he will do anything to make it happen? it makes no sense.

strong Smalltalk 2.0 vibes: composability, painless transition from dev to prod and back, effortless observability A man can dream!

@levelsio I am long time Granola user. Recently I wanted to read some older notes and it turns out you can only access last 30 days on a free plan. So they are holding my own records hostage. Dick move. After that I one shorted my own copy, but this one is cleaner — will switch to it

Just today I've already seen Wispr Flow, Granola and WHOOP all "reverse engineered" and open sourced with a fully free version Very interesting to see what's happening The question is if normies will pick up on this (I think they will) and how companies will react and pivot to still make money

@dannypostma Friends did this x.com/vadi_ms/status…

I do a lot of vibe coding using Wispr. The issue, it's impossible to use in co-working spaces or public because it's "loud" (and I am shy to talk in crowds) So, I bought a DJI Mic Mini for $50. It has a super high sensitivity which means I can literally whisper into it and it picks up all my words correctly. No more bothering folks around me.

@xmaxsmi ASI

Opus 5 вчера сделал что-то, чего я не видел еще ни у одной модели. «я прочитал все исходники, нихрена не понял как сделать правильно, давай спросим кого-то, кто в этом разбирается?»

@xmaxsmi AGI

@Niketas Спасибо за пересказ!

Как щас принято говорить, работы над текстом проделано было много, но (к сожалению) хуёво. Я понимаю, что хотел сказать Марк — AI-думеры никого ни на что не вдохновляют, да и росту акций не помогают, а только пугают чтобы заграбастать себе побольше власти над будущим ИИ и общества. И допустить этого нельзя. Но как это сделать? Марк говорит, что все будут в безопасности, когда суперинтеллект будет доступен каждому. Логика здесь ломается напрочь — раздай каждому по ядерной боеголовке, и рано или поздно кто-то со слабыми нервами не выдержит и начнётся цепная реакция. В целом это такой завуалированный тезис про поддержку open weight models, только с позиции AI-оптимизма. Справедливости ради, Марк действительно такой оптимист. Но вот понтануться заметкой в WSJ, когда остальные пацаны просто постят статьи тут (или хотя бы ссылкой на PDF), такое себе. Тем более что там три рекламных блока на его текст из 10 абзацев.

@myprivateboard Вот официальный ответ производителя, там в сабтвите собственно предъява

@samat А где дискуссия? Интересно почитать позиции.

В америке впервые предъявили обвинения чуваку, который вместо настоящего ПИН-кода на телефон назвал пограничникам duress PIN (ПИН-под-принуждением). В результате, телефон отформатировал все свое содержимое. Его обвиняют в уничтожении имущества во время законного изъятия, до пяти лет тюрьмы. Среди технарей, конечно же, разгорелась дискуссия на тему того, что телефон не должен был показывать, что он удаляет содержимое, а должен был показать decoy data, то есть фейковые данные, которые бы не привлекли внимания погранцов. Зная разработчиков Graphene OS, установленного на том телефоне, не удивлюсь, если следующая версия этой сборки Андроида будет иметь и такую функцию тоже. Рекомендация для не-специалистов звучит так: не пересекайте государственную границу имея на телефоне то, что вы не готовы показать пограничнику. Заведите реалистичный второй телефон, установите туда вацап и создайте переписку с мамой. Первоисточник этой новости — the Guardian и там есть дополнительные подробности: парня внесли в список потенциальных террористов после того, как он выступил против строительства огромной тренировочной базы для копов у себя в городе. А во время допроса агенты утверждали, что у него на телефоне есть детское порно. Прямо флеш рояль! theguardian.com/us-news/2026/j…

@slack_ajuster Нужна специальная ОС grapheneos.org

@samat Как создать такой пин????

@AlexBugov Это и есть правильное поведение, когда на устройстве есть компромат Но в состоянии стресса все совершают ошибки, поэтому готовиться нужно заранее, чтобы на месте стрессовать было неотчего

@samat Атипа отказаться предъявлять аппелируя к тайне переписки и что обыск при осутствии оснований - превышение полномочий?

@paulg Is there any incentive to fix it?

I wonder if Google will have the advantage in preventing their models from being influenced by this kind of campaign from their decades of fighting black hat SEO.

@82oman_vas19 Там к сожалению до сих пор нельзя скопировать или переслать распознанный текст, а также много проблем с знаками препинания. А ещё жёсткое ограничение на длину распознаваемого аудио

@samat безопаснее телеграмм премиум купить для расшифровки.

Привет! Я взял отпуск, немного пришел в себя и привел бота-секретаря t.me/goodsecretaryb… в порядок: 1. Он перестал ломаться; прошу прощения у всех, кого подвел раньше; 2. Он стал в разы быстрее; 3. Снял ограничение на длину аудио! если текст не влезает в три телеграм-сообщения, то ответ приходит в виде файла; 4. Повысил качество распознания. Чтобы не разориться, прикрутил платежи. 30 минут распознания в месяц — бесплатно, дальше 1 ⭐️ = 1 минута, получается около 1 евро за час аудио. Эти выходные с моделью Opus 5 у меня примерно такие