Show HN: I wrote a modern Command Line Handbook
15 by petr25102018 | 2 comments on Hacker News.
TLDR: I wrote a handbook for the Linux command line. 120 pages in PDF. Updated for 2025. Pay what you want. A few years back I wrote an ebook about the Linux command line. Instead of focusing on a specific shell, paraphrasing manual pages, or providing long repetitive explanations, the idea was to create a modern guide that would help readers to understand the command line in the practical sense, cover the most common things people use the command line for, and do so without wasting the readers' time. The book contains material on terminals, shells (compatible with both Bash and Zsh), configuration, command line programs for typical use cases, shell scripting, and many tips and tricks to make working on the command line more convenient. I still consider it "an introduction" and it is not necessarily a book for the HN crowd that lives in the terminal, but I believe that the book will easily cover 80 % of the things most people want or need to do in the terminal. I made a couple of updates to the book over the years and just finished a significant one for 2025. The book is not perfect. I still see a lot of room for improvement, but I think it is good enough and I truly want to share it with everyone. Hence, pay what you want. https://ift.tt/N2VsZmu
15 by petr25102018 | 2 comments on Hacker News.
TLDR: I wrote a handbook for the Linux command line. 120 pages in PDF. Updated for 2025. Pay what you want. A few years back I wrote an ebook about the Linux command line. Instead of focusing on a specific shell, paraphrasing manual pages, or providing long repetitive explanations, the idea was to create a modern guide that would help readers to understand the command line in the practical sense, cover the most common things people use the command line for, and do so without wasting the readers' time. The book contains material on terminals, shells (compatible with both Bash and Zsh), configuration, command line programs for typical use cases, shell scripting, and many tips and tricks to make working on the command line more convenient. I still consider it "an introduction" and it is not necessarily a book for the HN crowd that lives in the terminal, but I believe that the book will easily cover 80 % of the things most people want or need to do in the terminal. I made a couple of updates to the book over the years and just finished a significant one for 2025. The book is not perfect. I still see a lot of room for improvement, but I think it is good enough and I truly want to share it with everyone. Hence, pay what you want. https://ift.tt/N2VsZmu
The flip phone web: browsing with the original Opera Mini
16 by protonbob | 2 comments on Hacker News.
16 by protonbob | 2 comments on Hacker News.
Civil War in 3D: Stereographs from the New-York Historical Society (2015)
9 by LorenDB | 1 comments on Hacker News.
9 by LorenDB | 1 comments on Hacker News.
Infisical (YC W23) Is Hiring Full Stack Engineers (TypeScript) in US and Canada
1 by dangtony98 | 0 comments on Hacker News.
1 by dangtony98 | 0 comments on Hacker News.
Show HN: Open-source, visual-first Cursor for Designers
42 by hoakiet98 | 24 comments on Hacker News.
Hey HN, I’m Kiet – one half of the two-person team building Onlook, an open-source [ https://ift.tt/mxhLeOy ] visual editor that lets you edit and create React apps live on an infinite canvas. We launched Onlook [1][2] as a local-first Electron app almost a year ago. Since then, “prompt-to-build” tools have blown up, but none let you design and iterate visually. We fixed that by taking a visual-first, AI-powered approach where you can prompt, style, and directly manipulate elements in your app like in a design tool. Two months ago, we decided to move away from Electron and rewrite everything for the browser. We wanted to remove the friction of downloading hundreds of MBs and setting up a development environment just to use the app. I wrote more here [3] about how we did it, but here are some learnings from the whole migration: 1. While most of the React UI code can be reused, mapping from Electron’s SPA experience to a Next.js app with routes is non-trivial on the state management side. 2. We were storing most of the data locally as large JSON objects. Moving that to a remote database required major refactoring into tables and more loading states. We didn’t have to think as hard about querying and load time before. 3. Iframes in the browser enforce many more restrictions than Electron webview. Working around this required us to inject code directly into the user project in order to do cross-iframe communication. 4. Keeping API keys secure is much easier on a web application than an Electron app. In Electron, every key we leave on the client can be statically accessed. Hence, we had to proxy any SDK we used that required an API key into a server call. In the web app, we can just keep the keys on the server. 5. Pushing a release bundle in Electron can take 1+ hours. And some users may never update. If we had a bug in the autoupdater itself, certain users could be “stranded” in an old version forever, and we’d have to email them to update. Though this is still better than mobile apps that go through an app store, it’s still very poor DX. How does Onlook for web work? We start by connecting to a remote “sandbox” [4]. The visual editing component happens through an iframe. We map the HTML element in the iframe to the location in code. Then, when an edit is made, we simulate the change on the iframe and edit the code at the same time. This way, visual changes always feel instant. While we’re still ironing out the experience, you can already:- Select elements and prompt changes - Update TailwindCSS classes via the styling UI - Draw in new divs and elements - Preview on multiple screen sizes - Edit your code through an in-browser IDE We want to make it trivial for anyone to create, style, and edit codebases. We’re still porting over functionalities from the desktop app — layers, fonts, hosting, git, etc. Once that is done, we plan on adding support for back-end functionalities such as auth, database, and API calls. Special thank you to the 70+ contributors who have helped create the Onlook experience! I think there’s still a lot to be solved for in the design and dev workflow, and I think the tech is almost there. You can clone the project and run it from our repo (linked to this post) or try it out at https://beta.onlook.com where we’re letting people try it out for free. I’d love to hear what you think and where we should take it next :) [1] https://ift.tt/sDeOnqd [2] https://ift.tt/sgET2Ad [3] https://ift.tt/ZdGf9J2... [4] Currently, the sandbox is through CodeSandbox, but we plan to add support for connecting to a locally running server as well.
42 by hoakiet98 | 24 comments on Hacker News.
Hey HN, I’m Kiet – one half of the two-person team building Onlook, an open-source [ https://ift.tt/mxhLeOy ] visual editor that lets you edit and create React apps live on an infinite canvas. We launched Onlook [1][2] as a local-first Electron app almost a year ago. Since then, “prompt-to-build” tools have blown up, but none let you design and iterate visually. We fixed that by taking a visual-first, AI-powered approach where you can prompt, style, and directly manipulate elements in your app like in a design tool. Two months ago, we decided to move away from Electron and rewrite everything for the browser. We wanted to remove the friction of downloading hundreds of MBs and setting up a development environment just to use the app. I wrote more here [3] about how we did it, but here are some learnings from the whole migration: 1. While most of the React UI code can be reused, mapping from Electron’s SPA experience to a Next.js app with routes is non-trivial on the state management side. 2. We were storing most of the data locally as large JSON objects. Moving that to a remote database required major refactoring into tables and more loading states. We didn’t have to think as hard about querying and load time before. 3. Iframes in the browser enforce many more restrictions than Electron webview. Working around this required us to inject code directly into the user project in order to do cross-iframe communication. 4. Keeping API keys secure is much easier on a web application than an Electron app. In Electron, every key we leave on the client can be statically accessed. Hence, we had to proxy any SDK we used that required an API key into a server call. In the web app, we can just keep the keys on the server. 5. Pushing a release bundle in Electron can take 1+ hours. And some users may never update. If we had a bug in the autoupdater itself, certain users could be “stranded” in an old version forever, and we’d have to email them to update. Though this is still better than mobile apps that go through an app store, it’s still very poor DX. How does Onlook for web work? We start by connecting to a remote “sandbox” [4]. The visual editing component happens through an iframe. We map the HTML element in the iframe to the location in code. Then, when an edit is made, we simulate the change on the iframe and edit the code at the same time. This way, visual changes always feel instant. While we’re still ironing out the experience, you can already:- Select elements and prompt changes - Update TailwindCSS classes via the styling UI - Draw in new divs and elements - Preview on multiple screen sizes - Edit your code through an in-browser IDE We want to make it trivial for anyone to create, style, and edit codebases. We’re still porting over functionalities from the desktop app — layers, fonts, hosting, git, etc. Once that is done, we plan on adding support for back-end functionalities such as auth, database, and API calls. Special thank you to the 70+ contributors who have helped create the Onlook experience! I think there’s still a lot to be solved for in the design and dev workflow, and I think the tech is almost there. You can clone the project and run it from our repo (linked to this post) or try it out at https://beta.onlook.com where we’re letting people try it out for free. I’d love to hear what you think and where we should take it next :) [1] https://ift.tt/sDeOnqd [2] https://ift.tt/sgET2Ad [3] https://ift.tt/ZdGf9J2... [4] Currently, the sandbox is through CodeSandbox, but we plan to add support for connecting to a locally running server as well.
Airlines are charging solo passengers higher fares than groups
54 by _tqr3 | 39 comments on Hacker News.
54 by _tqr3 | 39 comments on Hacker News.