Stories with Tag GNU

• argp: GNU-style command line argument parser for Go

  permalink

  Posted: 2025-03-23 12:45:21

  Verbose tl;dr

  argp is a Go library providing a GNU-style command-line argument parser. It supports features like short and long options, flags, subcommands, required arguments, default values, and generating help text automatically. The library aims for flexibility and correctness while striving for good performance and minimal dependencies. It emphasizes handling POSIX-style argument conventions and provides a simple, declarative API for defining command-line interfaces within Go applications.

  The GitHub repository argp, created by Tom de Wolff, introduces a Go package that provides a command-line argument parser mimicking the style and functionality of GNU's argp library. This allows developers familiar with the GNU argument parsing conventions to easily implement similar behavior in their Go programs. The package aims to be a robust and feature-rich solution for handling command-line input.

  Key features of this Go implementation include support for both short and long options, with automatic generation of help text. It handles various argument types such as flags (boolean), options with associated values (strings, integers, etc.), positional arguments, and subcommands. The parser can be customized extensively to enforce required arguments, define default values, specify valid ranges for numeric arguments, and provide detailed usage instructions.

  The argp package uses a declarative approach, allowing developers to define the command-line interface through structs and struct tags. This approach promotes clarity and makes it easier to manage complex argument structures. Functions are provided to parse the command-line arguments and populate the corresponding struct fields. Error handling is integrated, providing informative messages to the user in case of invalid input.

  The package aims for high performance and strives to be a reliable and efficient solution for parsing command-line arguments in Go applications. The documentation within the repository provides detailed explanations and examples of usage, covering various scenarios and demonstrating how to leverage the package's capabilities. It also outlines how to handle different argument types, define subcommands, and customize the generated help text. The project maintains a focus on adhering to the established GNU argp conventions, ensuring a familiar experience for developers accustomed to that style of argument parsing.

  • Go
  • Golang
  • command-line
  • argument-parsing
  • cli
  • GNU
  • argp
  • parsing
  • Library
  • flag-parsing
  • getopt
  • command-line-interface
  • command-line-arguments
  • option-parsing

  Summary of Comments ( 18 )
  https://news.ycombinator.com/item?id=43452525

  Verbose tl;dr

  Hacker News users discussed argp's performance, ease of use, and its similarity to the C library it emulates. Several commenters appreciated the library's speed and small size, finding it a preferable alternative to more complex Go flag parsing libraries like pflag. However, some debated the value of mimicking the GNU style in Go, questioning its ergonomic fit. One user highlighted potential issues with error handling and suggested improvements. Others expressed concerns about compatibility and long-term maintenance. The general sentiment leaned towards cautious optimism, acknowledging argp's strengths while also raising valid concerns.

  The Hacker News post about argp, a GNU-style command line argument parser for Go, has several comments discussing its merits and drawbacks.

  One commenter points out that while they appreciate the effort, they generally prefer using Go's flag package for simpler cases and moving to a more powerful library like spf13/cobra when the needs become more complex. They feel argp sits in an awkward middle ground. This sentiment is echoed by another user who adds that cobra also handles things like help text generation and subcommand management effectively, making it a more complete solution.

  Another commenter expresses concern over the dependency on C code, viewing it as a potential disadvantage. They also question the long-term maintenance of the project and suggest exploring pure Go alternatives.

  Several users discuss the specific GNU style of argument parsing, with some appreciating its familiarity and others finding it overly complex and verbose. One commenter specifically mentions the lack of positional argument support as a drawback, preferring libraries that offer more flexibility in this area.

  There's a discussion about the "batteries included" philosophy of Go and whether a project like argp fits into that ecosystem. Some argue that the standard library's flag package is sufficient for most use cases, while others appreciate the availability of external libraries like argp for those who prefer a different style.

  One commenter mentions that while they're not currently using argp, they're keeping an eye on it for future projects, particularly those that require close compatibility with existing C codebases.

  Finally, the author of argp chimes in to clarify some points. They explain that the library aims to provide a familiar experience for developers coming from a C/GNU background and addresses the concerns about C dependencies, stating they're minimal and primarily for parsing GNU-style options. They also acknowledge the existence of other argument parsers but emphasize that argp fills a specific niche for those who prefer the GNU conventions. They further explain that POSIX-compliant short and long option parsing is available, but GNU extensions are the project's focus. They acknowledge positional arguments are currently missing and are open to considering them for the future. The author also details their motivation: they needed GNU-style parsing in a project and, unhappy with existing Go options, created argp and subsequently open-sourced it.

• Who Does That Server Serve? (2010)

  permalink

  Posted: 2025-02-06 18:06:48

  Verbose tl;dr

  This 2010 essay argues that running a nonfree program on your server, even for personal use, compromises your freedom and contributes to a broader system of user subjugation. While seemingly a private act, hosting proprietary software empowers the software's developer to control your computing, potentially through surveillance, restrictions on usage, or even remote bricking. This reinforces the developer's power over all users, making it harder for free software alternatives to gain traction. By choosing free software, you reclaim control over your server and contribute to a freer digital world for everyone.

  Richard Stallman's 2010 essay, "Who Does That Server Really Serve?" meticulously dissects the ethical implications of utilizing non-free software on servers, extending the free software philosophy beyond the realm of personal desktop computing. Stallman argues that the seemingly innocuous act of running proprietary software on a server, even one ostensibly dedicated to serving free software clients, carries significant ethical baggage and ultimately undermines the user's freedom.

  He begins by establishing the fundamental principle of free software: users should have the freedom to run, copy, distribute, study, change, and improve the software they use. This freedom, he asserts, is a matter of fundamental human rights, akin to freedom of speech or assembly, and should not be compromised, regardless of the context of software usage.

  Stallman then illustrates how using non-free server software compromises these freedoms. He explains that even if the server delivers free software to clients, the administrator of the server lacks the four essential freedoms. They are bound by the proprietary license's restrictions, preventing them from studying, modifying, or redistributing the server software itself. This dependence on the proprietary software vendor creates a power imbalance, effectively placing the server administrator under the vendor's control.

  The essay further elucidates this power dynamic by examining several practical scenarios. For instance, Stallman describes how a proprietary email server can be used to implement digital restrictions management (DRM), surreptitiously limiting users' ability to access and share their own emails. He also discusses how proprietary social networking platforms, while appearing to connect individuals, actually restrict users' freedom by controlling the flow of information and preventing users from examining and modifying the underlying software.

  Stallman emphasizes that the use of free software on servers is not merely a technical matter but a moral imperative. He argues that by running proprietary server software, system administrators inadvertently become accomplices in denying freedom to themselves and, potentially, to their users. This complicity, he suggests, perpetuates a system where proprietary software vendors hold undue power and control over individuals and communities.

  The essay concludes with a call to action, urging readers to insist on the use of free software on all servers. Stallman emphasizes that this is essential not only for preserving individual freedoms but also for fostering a more democratic and participatory digital society. By choosing free software, individuals and organizations can reclaim control over their digital infrastructure and contribute to a world where technology empowers rather than enslaves. He further suggests that advocating for free software on servers is a crucial step towards achieving a truly free digital ecosystem. This encompasses promoting free software alternatives, demanding transparency from service providers, and educating others about the ethical implications of proprietary software.

  • Free Software
  • Open Source
  • GNU
  • Server
  • software freedom
  • Proprietary Software
  • SaaS
  • Cloud Computing
  • user freedom
  • software as a service
  • Ethics
  • Digital Freedom
  • internet freedom
  • web server
  • Control
  • autonomy
  • privacy

  Summary of Comments ( 17 )
  https://news.ycombinator.com/item?id=42964883

  Verbose tl;dr

  HN users largely agree with the article's premise that "personal" devices like "smart" TVs, phones, and even "networked" appliances primarily serve their manufacturers, not the user. Commenters point out the data collection practices of these devices, noting how they send usage data, location information, and even recordings back to corporations. Some users discuss the difficulty of mitigating this data leakage, mentioning custom firmware, self-hosting, and network segregation. Others lament the lack of consumer awareness and the acceptance of these practices as the norm. A few comments highlight the irony of "smart" devices often being less functional and convenient due to their dependence on external servers and frequent updates. The idea of truly owning one's devices versus merely licensing them is also debated. Overall, the thread reflects a shared concern about the erosion of privacy and user control in the age of connected devices.

  The Hacker News post titled "Who Does That Server Serve? (2010)" has a moderate number of comments discussing the linked GNU article about the ethical implications of running your own server. Several commenters engage with the core ideas presented by the article.

  A recurring theme is the practicality and feasibility of self-hosting in the modern internet landscape. Some users acknowledge the idealistic appeal of controlling one's own data and digital presence but point out the increased complexity and maintenance burden involved. They highlight the advantages of established service providers in terms of reliability, security, and accessibility. One commenter specifically mentions the difficulties in achieving robust spam filtering and DDoS protection on a personal server. The trade-off between convenience and control is a central point of discussion.

  Several comments explore the nuanced meaning of "serving" in the context of the article. Some argue that even a self-hosted server implicitly "serves" the interests of hardware manufacturers, internet service providers, and software developers, thus never truly achieving complete autonomy. This leads to a discussion about the interconnected nature of the internet and the inherent dependencies involved.

  The legal and ethical responsibilities of running a server are also addressed. Commenters mention the potential liability for hosting illegal content, even unintentionally, and the need to comply with various regulations. This raises questions about the realistic expectations of individual users to manage these complex issues.

  Some commenters offer practical advice and resources for those interested in exploring self-hosting. They mention specific software packages, hardware configurations, and community forums dedicated to supporting self-hosting enthusiasts.

  While several commenters express agreement with the article's premise about the importance of digital autonomy, there's a noticeable thread of pragmatism throughout the discussion. The challenges and complexities of self-hosting are acknowledged, and the conversation evolves into a more balanced consideration of the pros and cons involved. The comments don't necessarily refute the article's central argument but rather provide a realistic context for evaluating the feasibility and implications of self-hosting in the present day.