Choosing between portability and innovation
Posted Mar 11, 2011 1:52 UTC (Fri) by
gcooper (guest, #73533)
Parent article:
Choosing between portability and innovation
Some history review
- kqueues came before epoll and some of the equivalent functionality in inotify.
- BSD sockets came before the Linux implementation (obviously)? XSI streams are basically dead, hence FreeBSD doesn't make an effort to implement them, along with some other deprecated XSI functionality.
- OSS came before ALSA and was technologically superior to ALSA. It was in Linux for a while, and has been adopted in *BSD for a long period of time, but was abandoned for licensing disagreements (BSD licensing) and bad blood between Linux devs and the OSS devs and because OSS was done largely within the kernel. FreeBSD (at least) also has had software mixing for well over a decade now (vchans) and Linux is still struggling with this functionality (why outsource to PulseAudio)? What about arts, ESS, etc?
- systemd is another take on something that upstart was supposed to answer by itself, which is in turn something that SysV init did back in the day (and a simple init clone already does to a large degree on FreeBSD without as much complexity for well over the past decade); granted it has to use devd and devfs for some minor help with event notification, but have you tried creating jobfiles in upstart? Oh yeah, and OSX has launchd, which is probably superior to the rest of the init-like daemons, but isn't really portable after Leopard (surprise, surprise), so it hasn't moved outside of OS X.
So with that in mind, how is tying Freedesktop to Linux better than trying to be somewhat portable (if I screwed up the history lesson, feel free to correct me)?
Code churn
Brute forcing software design through several revisions of code or several forked projects detracts from the collaboration effort and I would question whether or not true innovation is being made, or if it's just code churn.
How often does OSX, Windows, etc dramatically change system interfaces or how components interact with one another, and how do end-users receive the changes? I know based on my experience that people absolutely loathed the Windows 2000 -> XP and XP -> Vista/7 transitions and those only happened every 3-5 or so years. Freedesktop and other associated projects (Gnome, KDE, LXDE, XFCE) pulls this stuff every release, which is either biannually or annually!
Impact of churn and becoming less portable
- Do the devs have the performance figures to support the fact that the new software truly functions faster?
- Can the devs qualify all of the wasted hours...
- Doing the initial development and unit testing.
- Effort needed to track the versions qualify the software in multiple releases by package maintainers?
- Effort needed to track changes required for end-users who depend on Linux or other platforms like BSD, OpenSolaris (now IlluminOS), etc?
An example of good collaboration / design
I find the work that Intel is doing with GEM (even though it's a bit misguided in tying itself to Linux, oh well) to be really good work, because it's a relatively abstract framework for their display drivers. I will applaud them for this effort and others because several folks in Intel have also works on making their NIC drivers and other things sane for non-Linux Unix users.
Conclusion:
I was a devout Gentoo Linux user for 5 years and gave up running it on my primary system because of the fact that some developers that develop for core components in Linux lose sight that an OS distribution is so much more than a kernel, and stuff broke all too frequently. If Freedesktop devs aren't willing to slow down and think more -- and thinking about portability is one of those things -- then Unix won't be my primary desktop / portable platform, I won't be the only user (BSD, Linux, etc) dropping FreeDesktop software like a hot rock. There's always screen/tmux with SSH on my Mac if I'm pushed to do things that way, so even if folks go the way of Wayland I'll have a way to get my work done.
(
Log in to post comments)