You are viewing rvokal

Previous Entry | Next Entry

Fedora for developers?


Is Fedora a good distribution for developers?

I have recently talked to a group of developers that are working on various linux, cloud and jboss projects. They have one thing in common. They all used for a certain time Fedora as the main development platform but switched to another distro or even MacOS after some time. My only question to them was - Why can’t you use Fedora for development? The output is quite a long list of various topics, some of them can be easily fixed, some of them deserve more thinking to figure out how to satisfy such needs.

  • Disturbing updates, restart needed too often and updates breaking functionality - at least the first part is already fixed but updates that are actually breaking in the middle of release functionality of certain component do happen. Couple people mentioned that relying on some app, library or a function is crucial for their development. They can’t adjust their work environment after every update - these people actually use CentOS as their basis.
  • Bad backward compatibility - API changes too often. Several developers mentioned that their development needs to freeze on certain API for a longer time and Fedora is changing to often and even within one release. I must admit that this was mentioned by all three groups and started a long discussions. Most of them agreed that there’s no easy way for them to monitor all API changes on the system and they would have to be monitoring updates closely. At least for core system components they would love to have some API guarantee and also a transition support for a longer time than one release. One idea was fe to introduce a concept of -latest package, where new stuff could be added to distro but as a new package that can be used for testing, but development can continue on the old one.
  • Non intuitive package installer - Here are several issue that people mentioned - packaging tool doesn’t have any priority in the search, doesn’t allow to search only in package names, doesn’t intuitively offer development packages, doesn't offer better groups - fe. groups for developers split by a programming language
  • Configuration options changes are not documented - two developers mentioned a situation when configuration change wasn’t well documented and it wasn’t obvious why an old configuration file stopped working or didn’t work properly.
  • Gnome shell - it’s very hard to develop extensions. There is no decent documentation and the js code very complex - This was mentioned by OS developer who created XFCE plugins. He wasn’t really excited about complexity of the javascript code and was hoping for a more simple way how to access entry points in gnome shell. This guy also mentioned the SDK/API list that Ubuntu offers for Unity as a better documented and easier to consume.
  • CTRL+C, CTRL+V inconsistency - this should work everywhere and use the same clipboard. Such a silly think one would say but really drives people nuts :-)
  • SELinux crashes some applications for unknown reasons - my favourite topic, why do you turn off SELinux? This actually never happened to me but some people got annoyed by SELinux when it blocked some functionality of an app but didn’t report any warning. Also the discussion was around setroubleshoot and whether it can offer a more easy way how to fiddle with booleans and custom policy files. Again, sounds to me like something that got way better in last two releases.
  • Development profiles - an idea that can be easily solved and which I’m in favour of - a granular developer profiles, where a developer would be able to easily install environment for Ruby, Java, PHP, C or other programming language. This would install a default editor, debugger, version control system and basic compiler or -devel packages.
  • Very often we were talking about two very different sets of developers - one that profits from various RPM features and one which delivers stuff to different OSes and have specific requirements on the OS. The other group doesn’t use packaged versions of java or ruby and rather installs several non-conflicting Java versions for testing or several rubygems thru rvm.
  • Last but not least, multiplatform support. Some developer actively use openbuildservice for their packages to get them ready for various distros. They don’t care about nice and polished spec file, they just one to have the packages available for the distro users.

Overall interesting discussions. If you have some other ideas, feel free to comment. I’m quite sure we’ll try to work some of these within my group at Red Hat and solve them. I'll make sure I'll let everyone know when we start with it.

Comments

( 6 comments — Leave a comment )
Juan Rodriguez
Nov. 20th, 2012 04:37 pm (UTC)
Java Developer here
I happen to use Fedora 18(Yes, Delayed Cow) at work to develop Java, however, despite the efforts to package Eclipse and Tomcat, I install the upstream tar balls under a Programs folder and run those versions instead, as the packages from Fedora often break in one way or another.
jjmartinez [launchpad.net]
Nov. 20th, 2012 07:03 pm (UTC)
I totally agree
Although I really like that you can have access to the latest (or almost latest) version of any software, and everything is packaged.

It is not a stable platform, but I think the consequences of it are different depending on which kind of software are you developing.
Éloi Rivard
Nov. 21st, 2012 12:07 am (UTC)
Concurrent lib versions
Something that could make Fedora better for developpers is the ability to install concurrent versions of a lib, in order to test where in the lib's life your program start and finish. For a lot of libraries, developer can just install the last version (glfw, php…).
gaveen.owain.org
Nov. 21st, 2012 03:45 pm (UTC)
Package management is a tricky one. It's great when the version you want is packaged and available, but frustrating when they aren't. The thing is what I want might not be the one you want. For example I want Kernel 3.6 and GNOME 3.6. But you might be perfectly happy with Kernel 3.4 and GNOME 3.4. Fedora 17 has Kernel 3.6 and GNOME 3.4 which doesn't make neither you nor me completely happy. Most people know this pain when working with libraries.

I have seen people float two different ideas when suggesting solutions for package version related problems. At a glance they look conflicting. The number one suggestion is and has been for a while to have a LTS-type release included in Fedora. It makes sense, on many fronts. Especially when you develop on Fedora it'd be best to deploy on Fedora too. But the short life cycle of a distro is often enough to forsake Fedora as a viable choice. The second suggestion I've seen is a release based on the rolling-release model. Since the arrival of serious rolling release distros, this one has been pitched with merit.

One argument against a LTS release has always been the availability of RHEL/CentOS, etc. That Fedora isn't competing against RHEL/CentOS. So the question is how do we give people a Fedora which is suitable as a development/production platform with software version flexibility and not being a RHEL/CentOS clone?

I honestly am not sure how to address this dilemma. Perhaps a new rolling-release remix with a longer support period? Where new updates would be available, but older versions of major software (that breaks APIs) would be supported for longer? Say 2-3 years? I'm just thinking aloud. But if anyone's got better ideas and working on to solve this, I'm totally on board. :)

As for version concurrency, some packages have been doing that for ages. But not all are software are easy to make so. And even if they are, making it a mainstream behavior is a major decision. There was a discussion a while back in the Ruby SIG about having RVM default. But it hasn't made it to the default Ruby setup. If rvm is the default and a default ruby is set (preferably the latest stable MRI), this could be an acceptable Ruby dev env. I'm not familiar with what Java devs do.
Sayth Renshaw
Nov. 22nd, 2012 11:00 am (UTC)
Backward Compatibility
A small thing.

The tools and languages that Fedora provides to developers Java, python, perl, c, ruby... all aim to as break backward compatibility as little as often and many years apart.

Linux however not the kernel but the userland and desktop seems to want to break it and constantly change the API.

Not sure where to go from here but if the kernel remains compatible and the languages that build the distro's remain backward comaptible why not the user space?

PS I don't build distro's so I may lack some knowledge.
tomasradej
Nov. 29th, 2012 03:22 pm (UTC)
Concurrent versions
I disagree with the notion that the languages don't break backward compatibility. At least libraries written in Java and Ruby do it all the time. Because of this, having multiple versions of a package in the system has been one of the most called-for feature Fedora should incorporate.

Enter Software Collections.

http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-What_Are_Software_Collections.html

This feature allows you to build and use several versions of a package without interfering with system files. It is very new, but IMHO it might become one of the "killer features" of Fedora, allowing easy usage of different versions of a package for development purposes.
( 6 comments — Leave a comment )