The design philosophy of “everything is a file” is commendable, as it abstracts hardware and processes into files for unified operations.
However, this approach becomes less effective in scenarios requiring bidirectional communication, such as network communication, where operating sockets through file read/write operations feels awkward.
Windows’ “everything is a handle” is more flexible, as a handle can represent various objects like files, threads, and events. Linux later recognized this, and the epoll mechanism uses file descriptors to manage event notifications, effectively implementing a similar handle functionality.
Configuration files are scattered everywhere.
The /etc directory is filled with configuration files of various formats, some ending with .conf, others with .ini, and some are plain text files without extensions. Although Systemd has unified service configurations into specific directories, older programs still use traditional methods.
While the Windows registry is often criticized for being difficult to use, it at least consolidates all configurations into a single hierarchical structure. Nowadays, Kubernetes uses YAML files to manage configurations uniformly, setting a good example for Linux.
The rwx permissions work well for simple scenarios, but they fall short in situations requiring fine-grained control.
Access Control Lists (ACLs) have been a standard for over 20 years, yet many administrators still only use chmod 755.
Modern cloud computing requires dynamic permission adjustments, and the traditional user/group model is neither convenient nor flexible. The Android system has broken permissions down into over 200 fine-grained controls, which is a concept worth emulating.
The signal mechanism can only send fixed signals numbered 1-31, without the ability to carry any additional information.
The difference between SIGTERM and SIGKILL is that one politely asks a process to exit while the other forcefully terminates it, lacking an intermediate state.
Currently, proper program communication relies on DBus or event buses, leaving the signal mechanism primarily for handling abnormal exits or crashes.
The ls command displays file lists beautifully, but parsing it in scripts can be troublesome, requiring complex regular expressions.
If it had been designed to output structured data directly (e.g., JSON), it would save a lot of trouble now. PowerShell’s pipeline passes objects instead of text, which clearly aligns better with modern needs.
The naming convention like /dev/sda often causes issues on cloud servers, as plugging and unplugging hard drives can lead to changes in device names.
Although udev dynamically manages devices and resolves some issues, it essentially hardcodes device information in the file system. Windows’ method of binding devices with hardware IDs is more suitable for modern plug-and-play scenarios.
The difference between LF and CR-LF has caused many headaches for cross-platform collaboration, and Git’s automatic conversion feature has supported countless technical Q&A posts.
Now, while most new tools support unified line endings, vim configurations still require setting fileformat=unix to avoid minor troubles.
The make install command scatters files across multiple directories like /usr/bin and /lib, making uninstallation reliant on package managers or manual cleanup.
New formats like Snap and Flatpak package applications into self-contained sandboxes, clearly better suited to modern needs, yet many developers still insist that “compiling from source is the orthodox way.”
The reason these designs have persisted is primarily to maintain “backward compatibility.”
Perhaps “backward compatibility” is also a burden that can never be fully shed.
We welcome everyone to leave comments for discussion.