Pico.sh offers developers instant, SSH-accessible Linux containers, pre-configured with popular development tools and languages. These containers act as personal servers, allowing developers to run web apps, databases, and background tasks without complex server management. Pico emphasizes simplicity and speed, providing a web-based terminal for direct access, custom domains, and built-in tools like Git, Docker, and various programming language runtimes. They aim to streamline the development workflow by eliminating the need for local setup and providing a consistent environment accessible from anywhere.
The author introduces "Thinkserver," their personally developed web-based coding environment. Frustrated with existing cloud IDEs, they built Thinkserver to prioritize speed, minimal setup, and a persistent environment accessible from anywhere. Key features include a Rust backend, a Wasm-based terminal emulator, a SQLite database, and persistent storage. While currently focused on personal use for tasks like scripting and exploring ideas, the author shares the project hoping to inspire others and potentially open-source it in the future. It's emphasized as a work in progress, with planned features like VS Code integration, collaborative editing, and improved language support.
Hacker News users discussed the practicality and security implications of Thinkserver, a web-based coding environment. Several commenters expressed concerns about trusting a third-party service with sensitive code and data, suggesting self-hosting as a more secure alternative. Others questioned the latency and offline capabilities compared to local development environments. Some praised the convenience and collaborative potential of Thinkserver, particularly for quick prototyping or collaborative coding, while acknowledging the potential drawbacks. The discussion also touched upon the performance and resource limitations of web-based IDEs, especially when dealing with larger projects. Several users mentioned existing cloud-based IDEs like Gitpod and Codespaces as potential alternatives.
VS Code's remote SSH functionality can lead to unexpected and frustrating behavior due to its complex key management. The editor automatically adds keys to its internal SSH agent, potentially including keys you didn't intend to use for a particular connection. This often results in authentication failures, especially when using multiple keys for different servers. Even manually removing keys from the agent within VS Code doesn't reliably solve the issue because the editor might re-add them. The blog post recommends disabling VS Code's agent and using the system SSH agent instead for more predictable and manageable SSH connections.
HN users generally agree that VS Code's remote SSH behavior is confusing and frustrating. Several commenters point out that the "agent forwarding" option doesn't work as expected, leading to issues with key-based authentication. Some suggest the core problem stems from VS Code's reliance on its own SSH implementation instead of leveraging the system's SSH, causing conflicts and unexpected behavior. Workarounds like using the Remote - SSH: Kill VS Code Server on Host... command or configuring VS Code to use the system SSH are mentioned, along with the observation that the VS Code team seems aware of the issues and is working on improvements. A few commenters share similar struggles with other IDEs and remote development tools, suggesting this isn't unique to VS Code.
Summary of Comments ( 106 )
https://news.ycombinator.com/item?id=43560899
HN commenters generally expressed interest in Pico.sh, praising its simplicity and potential for streamlining development workflows. Several users appreciated the focus on SSH, viewing it as a secure and familiar access method. Some questioned the pricing model's long-term viability and compared it to similar services like Fly.io and Railway. The reliance on Tailscale for networking was both lauded for its ease of use and questioned for its potential limitations. A few commenters expressed concern about vendor lock-in, while others saw the open-source nature of the platform as mitigating that risk. The project's early stage was acknowledged, with some anticipating future features and improvements.
The Hacker News post for Pico.sh – SSH powered services for developers (https://news.ycombinator.com/item?id=43560899) has several comments discussing various aspects of the service.
A significant thread discusses the security implications and practicalities of using SSH as the primary interface for service interaction. Some users express concerns about the potential security risks of exposing SSH ports, especially when combined with key-based authentication. They highlight the importance of robust key management and the potential for misuse if keys are compromised. Others counter that SSH is a well-established and understood protocol, offering a good balance of security and convenience when implemented correctly. The discussion explores different approaches to mitigate risks, like using bastion hosts, restricting access based on IP addresses, and utilizing SSH key agents.
Another commenter questions the target audience and use cases for Pico.sh. They suggest that while the simplicity of SSH access might be appealing to some, it might not offer significant advantages over existing cloud providers for more complex applications. They also wonder about the scalability and performance of the platform, especially for resource-intensive tasks.
Several comments delve into the technical details of Pico.sh, inquiring about the underlying infrastructure, resource limits, and the specific technologies used. There's a discussion about the use of Firecracker microVMs and the implications for performance and isolation. Users also inquire about the pricing model and the availability of different instance types.
Some users express interest in the potential of Pico.sh for specific use cases like deploying personal VPNs, running game servers, or hosting small web applications. They appreciate the simplicity and ease of use compared to managing their own servers.
A few comments compare Pico.sh to similar services like fly.io and Railway, highlighting the differences in features, pricing, and target audience. They discuss the trade-offs between simplicity and flexibility offered by each platform.
Finally, there's a brief discussion about the choice of the ".sh" top-level domain and its potential implications for SEO and user perception.
Overall, the comments section reflects a mixture of curiosity, skepticism, and enthusiasm for Pico.sh. Users are intrigued by the novel approach of using SSH as the primary interface but also raise valid concerns about security and practicality. The discussion provides valuable insights into the potential benefits and drawbacks of the platform for different use cases.