Re: Let’s make Unix not Suck
This post is a direct reply to this Miguel de Icaza’s post, then I don’t hope it will make sense as an independent text. This post was initially an email reply, but I wanted to share it with a specific person, then I decided to migrate the text content to a blog post.
One of the most interesting parts from the Icaza’s text was the one about code reuse, but he seems to “forget” many of the problems that the solution creates:
- Service activation: Even by creating components using the proposed technique, the application still needs to face the problem to start the service, but then the application needs to know the service and the abstraction no longer works as initially desired (separation of interface and implementation).
- Inactive services: It’s an unnecessary overhead and decreases battery life to maintain inactive services running.
- Resource management: He mentions reference counting, but what if the application hangs before decrementing the reference?
- Security: This thing about global services… imagine someone creating the service “open-window-to-ask-for-password” and then having all your passwords being stolen.
- All components would need to be scalable: Imagine that instead having a function being executed 10 times by different proccesses that live in different places, now you have a daemon that executes only at one place and needs to stand against the bottleneck of 10 simultaneous clients.
There must be more points, but I don’t remember now. This part of the text reminded me about D-Bus, the systemd team (that is cooperating with the kernel to make D-Bus faster), and ROS (a robotics framework/meta-os that also provides this “messaging” system). It also reminds me about Android where there are several services (SMS provider, …) that work together with the applications, but I think (I’m not sure) that Android adds some isolation to enhance security (which is nice when you don’t trust the applications, but we usually don’t have with an easy-to-use GUI on GNU/Linux distros).
But leaving criticism apart, if he really solves all the problems, the only work left to reach the top (I suppose) would be divulgation and the creation of tools (tools/bindings for about 10 or 20 programming languages) to ease the life of developers. By “top” I mean that his technology would compete with Android/Sailfish/…, maybe would win servers’ love and so on.
And to finish the topic I don’t trust much on GNOME developers. Do something in C with minimal OO or something in C++ with no-to-only-where-necessary-overhead OO. But GObject… seriously… a bad joke.
About the problem of configuration, I think it’s less problematic now that systemd is conquering the user-land in all distros. And systemd also do some clever things like separation of default configuration (on /usr) and your costumizations that can even override only some values of the default config.
And still about the problem of configuration, I think the proposed solution to configuration is more realistic than the proposed solution to code reuse. But he still needs to solve the security problem.