| |||||||||||||
How Red Hat killed its core product—and became a billion-dollar business(ars technica)How Red Hat killed its core product—and became a billion-dollar business(ars technica)Posted Mar 1, 2012 5:52 UTC (Thu) by lkewiu2 (guest, #83244)In reply to: How Red Hat killed its core product—and became a billion-dollar business(ars technica) by dowdle Parent article: How Red Hat killed its core product—and became a billion-dollar business (ars technica)
I did not phrase the example about the Amiga clearly. You are of course right that Amiga wasn't based on 8-bit Commodore machines. However, I meant that the design of the Amiga itself changed very little (both software and hardware). While for a while it was advanced within the context of the competition (PC clones), it stood relatively still while the competition was moving full steam ahead.
I would also like to see more parallel installable packages. I believe a big part of the problem is that there is no clear separation of the core RHEL OS, and the applications that use the OS. I would like to see more packages being shifted to a separate repository, along the lines of EPEL, which is updated more often. (By this I do not mean a Fedora/Ubuntu-like approach of half-baked goods every 6 months. Perhaps stuff that was "proven" in Fedora for at least one release is allowed to progress to a "RHEL-non-core" repository). The separation of course is subjective and depends on what is meant by "core". One must also question as to where and why the need has arisen to freeze almost every bit of software at a particular version. Is it the constantly shifting nature of open-source software, where each project has unique definition of what is meant by a stable version? (eg. the Boost libraries can have API changes between versions, even though all releases are "version 1.x"). Perhaps the freezing should be more selective, and apply only to software that is known not to play nice?
(Log in to post comments)
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 6:25 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Freezing is already selective. Firefox and Evolution for instance gets bumped up in minor releases but not say GNOME or glibc and there are some parallel installalable newer versions as well such as Postgres or GCC. One could go further with this but there is a significant QA cost and Red Hat doesn't see that much demand for it to justify it.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 10:30 UTC (Thu) by joib (guest, #8541) [Link]
Somewhat related, Larz Wirzenius keynote at FOSDEM 2012: http://liw.fi/rethinking-distro-dev/
I'd also like to see more flexibility wrt which version of a particular software in used in a distro (be it through a separation of "core" and parallel installable "apps", or whatever), but to some extent that would also increase the QA burden. But other platforms manage to do it (e.g. Windows, OSX, IOS, Android), so why not Linux distros?
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 12:36 UTC (Thu) by pboddie (subscriber, #50784) [Link] Your Amiga example is actually very much off. The Amiga was in no way based on the 8-bit Commodore machines and was a complete departure... actually developed by the Atari 8-bit design team.I did not phrase the example about the Amiga clearly. You are of course right that Amiga wasn't based on 8-bit Commodore machines. However, I meant that the design of the Amiga itself changed very little (both software and hardware). While for a while it was advanced within the context of the competition (PC clones), it stood relatively still while the competition was moving full steam ahead. Indeed, the Amiga architecture didn't get the improvements it needed to stay competitive. It's interesting to read the details of both introduced and planned chipsets now, almost a couple of decades after heated discussions about whether Commodore would pull through and deliver various rumoured and hyped technologies, but the inability to deliver substantial improvements (or alleviate some of the features that had become almost anti-features) in a timely fashion haunted many of the company's competitors, too. Not that this relates directly to Red Hat, however: Red Hat's engineers are obviously involved at the tip of kernel development, and there's a steady stream of product improvements propagating through the company's product line. They certainly aren't pushing a tweaked decade-old product and pretending that it's still competitive. I think they [RHEL] could definitely improve if they offered multiple / updated python and ruby stacks in future update releases. I think that would help much of the pain.I would also like to see more parallel installable packages. I believe a big part of the problem is that there is no clear separation of the core RHEL OS, and the applications that use the OS. I would like to see more packages being shifted to a separate repository, along the lines of EPEL, which is updated more often. There is demand for user-installable packages, at least amongst users. Sadly, there is also a gap between the packaging community, who frequently have sufficient privileges to install whichever packages they like and who therefore don't see any problem, and the user community who have to live with whatever gets served up.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 2, 2012 15:53 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
lkewiu2 wrote:
> I would also like to see more parallel installable packages. I believe a big part of the problem is that there is no clear separation of the core RHEL OS, and the applications that use the OS. I would like to see more packages being shifted to a separate repository, along the lines of EPEL, which is updated more often. (By this I do not mean a Fedora/Ubuntu-like approach of half-baked goods every 6 months. Perhaps stuff that was "proven" in Fedora for at least one release is allowed to progress to a "RHEL-non-core" repository).
I wonder how many people think that more separation between core OS and applications would be a good thing for classical Linux-based distributions (noting along the way that other OSes seem to be going the other way with their app stores). I could imagine statically linked OS X/NextStep-like bundles where the binaries inside probe their environment a bit dynamically when they are started. I have always liked the way that bundles let the filesystem serve as both application menu and package manager (which seems to me more Unix-like than the current norm). I don't think that statically linking would be a big size problem today given modern disk and RAM sizes, though I fear that a lot of our infrastructure has subtle dependencies on dynamic linking (notable case: glibc).
And I can imagine some of the effort which goes into distribution maintenance today being put into centralised build systems which provide downloads, updates and monitoring (with automatic re-building) of static dependencies for security issues - except that upstream would choose a single build system to go along with instead of every distribution doing their own packaging with a slightly different build and running environment (especially due to subtle dynamic linking issues).
That said, OS X-style bundles work very well for typical OS X-style applications. I think that they could be made to work well for a lot more usage cases, but that is far less well explored ground.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 9:27 UTC (Mon) by dgm (subscriber, #49227) [Link]
Probably would be a good idea, except that it will not work with the current mindset. The problem is too much change, too many people working with pre-1.0 software, and of course, some (many) developers not feeling there's a need to keep interfaces stable. This makes testing impossible, there are simply too many combinations.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 11:57 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> Probably would be a good idea, except that it will not work with the current mindset. The problem is too much change, too many people working with pre-1.0 software, and of course, some (many) developers not feeling there's a need to keep interfaces stable. This makes testing impossible, there are simply too many combinations.
It would be interesting to see how close one could get today though - for something which goes in that direction see the generic VirtualBox installer, which I think we can still improve on quite a bit. That sort of thing can be very handy for distributing test versions of software today, as it can be installed and run without disturbing too much in the rest of the system and due to the static linking you have a lot fewer unknowns than when a user tests a distribution version of your software. If I ever find time I would like to develop what we have now into a framework that other people can use and advertise it a bit.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 12:38 UTC (Mon) by khim (subscriber, #9252) [Link] Will not work. Usually you need some kind of logic to handle differences between distributions and thus the end result is something like Autopackage or InstallAnywhere: large pile of code you are supposed to run with root privileges. Technically it should be possible to create something usable, but since distributions are expressly not interested the only feasible solution is to concentrate on MacOS/Windows (platforms which actually care about ISVs). If you want to support Linux then just pick one versions (the one you'll use internally) and forget about all others: if your program will be interesting enough and popular enough then it'll be ported to other distributions "by community" and if not, then it does not really matter.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 14:16 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> Will not work. Usually you need some kind of logic to handle differences between distributions and thus the end result is something like Autopackage or InstallAnywhere: large pile of code you are supposed to run with root privileges.
Yes, you will end up with a certain amount of code which need to be run as root to achieve full system integration. Such is life. That said, finding ways of reducing that, making it optional and/or making it as transparent as possible is an interesting aim (and binary distribution does not necessarily mean closed source!) Generally the sort of application where it is hard to get rid of are those which need to run with privileges of some sort anyway. Ditto for handing differences between distributions. Why though does this mean it won't work?
> Technically it should be possible to create something usable, but since distributions are expressly not interested the only feasible solution is to concentrate on MacOS/Windows (platforms which actually care about ISVs).
Distributions are currently interested in doing things the way they do them now, which is why I think this is more interesting for upstream developers wanting to ship test and bleeding edge versions. If they do that and it works well nothing stops distributions from taking a closer look, though I would think that the sensible thing for them to do would be to concentrate on distributing core things the way they do now and on making it easier for upstream packages to integrate.
As a side note, creating integration code which is as easy as possible for distribution packagers to use in their own packages is also an aim of mine (not least because we ship a generic and distribution-specific packages ourselves). There is likely to be room for both approaches for a long time to come, so reducing wasted effort is sensible.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 16:26 UTC (Mon) by khim (subscriber, #9252) [Link] Yes, you will end up with a certain amount of code which need to be run as root to achieve full system integration. Not "to achieve full system integration". Just "to run it". Something like this. Simple things (register daemon, add d-bus service, etc) is system-dependent and often not backward compatible. And binary distribution does not necessarily mean closed source! Sure. Most such system use bash scripts! Thousands lines of bash scripts… Why though does this mean it won't work? Because without help from distributors required changes will imply some random modifications to config files which may break distributions, too. It's probably possible to create distribution-dependent packages which will solve this problem, but if updates to these packages will not be considered in release process they will frequently be broken. If they do that and it works well nothing stops distributions from taking a closer look, though I would think that the sensible thing for them to do would be to concentrate on distributing core things the way they do now and on making it easier for upstream packages to integrate. Sure, but if distributions are not in the loop then their changes will break these packages regularly.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 16:45 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> Not "to achieve full system integration". Just "to run it". Something like this. Simple things (register daemon, add d-bus service, etc) is system-dependent and often not backward compatible.
Yes, SELinux is a pain, particularly if you are doing unusual things. The rest isn't half as bad as you make it sound (we do register daemons; we don't register DBus services but I have looked at it). Our code is messier than it should be as I have learnt as I went along (it is being fixed gradually but as it works that is low priority). The biggest problem in my opinion is lack of experience among application developers at handling these things.
> Because without help from distributors required changes will imply some random modifications to config files which may break distributions, too.
> It's probably possible to create distribution-dependent packages which will solve this problem, but if updates to these packages will not be considered in release process they will frequently be broken.
Actually distribution-independent packages are no more badly affected than the dependent ones if you know what you are doing (or the dependent ones are affected just as badly if you like). Perhaps I was just lucky, but my experience here too is that it isn't as bad as you are making out, and that the main problem is building up the experience regarding how to do it right.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 5, 2012 20:48 UTC (Mon) by khim (subscriber, #9252) [Link] Actually distribution-independent packages are no more badly affected than the dependent ones if you know what you are doing (or the dependent ones are affected just as badly if you like). Differences are not technical. When upgrade breaks in-distro application then it's usually fixed. But when upgrade breaks out-of-distro application, or, even worse, if out-of-distro application break the precious distro then it's ostracized and solution proposed is "don't install software not from official repo". As long as that's the case all these projects are hopeless. It looks like distributions are finally starting to understand that it's bad position to be in. We'll see. Perhaps something will actually happen on this front. But since it's not technical problem, but mostly attitude problem it's impossible to solve it using sorely technical means. Especially without collaboration with distributions.
|
|||||||||||||