Recent Features
| |||||||||||||
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 2:35 UTC (Thu) by lkewiu2 (guest, #83244)Parent article: How Red Hat killed its core product—and became a billion-dollar business (ars technica)
That's simply not correct. Look at the gap between RHEL 5 and RHEL 6. I fear that the gap between RHEL 6 and 7 will be even longer. While Red Hat has proven the model of a very-long-term stable release, this can also kill the company in the long term. Given that both RHEL 5 and RHEL 6 now have a 10 year supported lifespan, there is not much incentive to make RHEL 7 in any timely fashion (after all, the money is rolling in... "why break something that works ?") Not doing major updates of a core product was the flawed business model of Commodore, which rehashed an antiquated design without much progress in both software and hardware (ie. the Amiga). A very similar problem occurred with the Saab car company -- it stuck with slightly updating its offerings, while competitors' products leapfrogged it (this was a large contributing factor in GM taking over the company, which eventually strangled it). To the CEO of Red Hat, Jim Whitehurst: don't become another Commodore or Saab. The roadmap should not be entirely comprised of "a minor update to RHEL 6 every 6 months". It must also include "we are working new technologies X, Y and Z for RHEL 7, which will be released in a timely fashion". (A simple but important example of "X" is proper C++11 support.)
(Log in to post comments)
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 3:18 UTC (Thu) by thedevil (subscriber, #32913) [Link]
'A simple but important example of "X" is proper C++11 support'
Is that really a good example? Only if a significant part of RHEL boxes
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 3:56 UTC (Thu) by geofft (subscriber, #59789) [Link]
A significant portion of RHEL boxes certainly run code. While developers might write their C++11 on Debian (or Fedora or something), ops will want those same apps to compile and run on RHEL.
C++11 is not evenly-distributed yet Posted Mar 1, 2012 11:43 UTC (Thu) by jwakely (subscriber, #60262) [Link]
How many developers are using C++11 for production code today? I don't think it's all that many, and I don't think that's because RHEL6 has an older GCC. At the last company I worked for that used RHEL we didn't use the system compiler anyway. I built and deployed newer GCC releases for devs to use, as that allowed the same versions to be used across an estate that was a mix of both RHEL3 and RHEL5 boxes.
C++11 is not evenly-distributed yet Posted Mar 1, 2012 16:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
I actually had to cut some nice C+11 features from my project because they couldn't be used on RHEL's default GCC. Our customers can install newer versions of a library or two, but installing the full GCC is not acceptable for them.
C++11 is not evenly-distributed yet Posted Mar 1, 2012 16:49 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I'd guess that a lot of C++ developers started using C++11's auto functionality as soon as it got into $their_favorite_compiler.
C++11 is not evenly-distributed yet Posted Mar 1, 2012 17:10 UTC (Thu) by jwakely (subscriber, #60262) [Link] I don't think many developers in "enterprise" level companies using RHEL are using auto because to use it with G++ you need to use -std=c++11 (or -std=c++0x) which is still labelled 'experimental' and it changes the size of std::list, potentially breaking ABIs, which is probably not the sort of thing to be done lightly in environments that choose to use RHEL.Certainly whenever I (usually semi-jokingly) suggest "just use C++11" as a way to simplify e.g. some hairy template code trying to emulate decltype people I know at large firms scoff and reply "I wish!"
C++11 is not evenly-distributed yet Posted Mar 6, 2012 11:42 UTC (Tue) by nix (subscriber, #2304) [Link] it changes the size of std::listOw! I hope this merits a -Wabi warning, or something like it.
C++11 is not evenly-distributed yet Posted Mar 6, 2012 13:15 UTC (Tue) by jwakely (subscriber, #60262) [Link] -Wabi is for codegen by the C++ front-end, and std::list is still name-mangled and laid out unambiguously and consistently w.r.t the vendor-neutral C++ ABI ... it just has an extra data member when compiled with -std=c++11 (because C++11 requires that std::list::size() has constant complexity, so implementations which previously had O(n) size() need to add a data member to store the size.)Something like it for libstdc++ might be nice, but doesn't exist, and I'm not sure how it would work. Would it warn every time you use std::list? Or only in c++98 mode? Or ... ?
C++11 is not evenly-distributed yet Posted Mar 7, 2012 14:19 UTC (Wed) by foom (subscriber, #14868) [Link]
The plan seems to be to move std::* to another namespace (std::_v7::* or something like that)...eventually. I really wish that could've happened already, since I'd like to start compiling with c++11 more widely.
But as of right now, it's basically impossible to do without recompiling the world. And there's no easy way to know if you've screwed up either: it'll cause silent misbehavior or maybe mysterious crashes.
http://gcc.gnu.org/ml/gcc/2011-10/msg00113.html
Basically, you can't link (even at runtime) any c++03 objects with c++11 objects and expect things to work right, if they use any standard library objects.
You're nearly certain to get symbol conflicts, because the templates in the standard library expand differently in the two modes, and all of the symbols from std:: are forced to be exported (even if you try to use -fvisibility=hidden). The differing classes from the two modes are given the same mangled name, so the linker will override one of the versions with the other, likely causing either the c++11 or c++03 code to misbehave.
After the namespace move, you should at least be able to load c++03 and c++11 objects into the same program, so long as the API used *between* them doesn't use classes from the standard lib. And if you do screw up, the failures will be an obvious link error, not a mysterious crash.
C++11 is not evenly-distributed yet Posted Mar 7, 2012 15:02 UTC (Wed) by khim (subscriber, #9252) [Link] The plan seems to be to move std::* to another namespace (std::_v7::* or something like that)...eventually. I really wish that could've happened already, since I'd like to start compiling with c++11 more widely. You can do that today: just compile two versions of GCC. Regular one for C++98 and gnu-versioned-namespace for C++11. The appropriate bug was fixed year ago. In this case you'll not be able to use libraries compiled in C++98 mode from C++11 libraries (or vice versa), but at least you'll be able to link them together if they communicate using C interface...
C++11 is not evenly-distributed yet Posted Mar 7, 2012 18:24 UTC (Wed) by jwakely (subscriber, #60262) [Link] Basically, you can't link (even at runtime) any c++03 objects with c++11 objects and expect things to work right, if they use any standard library objects.That's an exaggeration. so the linker will override one of the versions with the other, likely causing either the c++11 or c++03 code to misbehave.Although it's not supported and there are no guarantees, it's more likely you'll get either the C++03 semantics or the C++11 semantics, and since you're mixing code using those languages presumably you consider at least one of them to be the correct semantics. In many cases the template code will be inlined and so the objects compiled as C++03 will inline the C++03 code and the objects compiled as C++11 will inline the C++11 code. If you have examples of crashes or silent changes in behaviour which match neither the C++03 nor C++11 semantics then please file a bug report and CC me.
C++11 is not evenly-distributed yet Posted Mar 8, 2012 5:42 UTC (Thu) by foom (subscriber, #14868) [Link] > That's an exaggeration.Ehh. Not really. Sure, if you don't use any inlined or template functions/classes, you're safe for now. That's rather unlikely. I'm not going to file a bug, because this has been explicitly stated to not be a bug. It would immediately get closed WONTFIX. But here goes anyways, since you asked for an example...This is the most trivially obvious case of misbehavior. Constructing a similar failure using a class like std::set where the layout hasn't changed, but the implementations have is left as an exercise to the reader. (You could start with std::set::erase(iterator), which grew a return value in c++11.)
test1.cpp
#include <list>
#include <cstdio>
extern "C" int test2();
extern "C" int test1() {
std::list<int> x;
return x.size();
}
int main() {
// Should print 0 1.
std::printf("%d %d\n", test1(), test2());
}
========
test2.cpp:
#include <list>
extern "C" int test2() {
std::list<int> x;
x.push_back(5);
return x.size();
}
========
Now, compile:
g++-4.7 -std=c++11 -c -o test1.o test1.cpp g++-4.7 -std=c++03 -c -o test2.o test2.cpp g++-4.7 -o test test1.o test2.o ./testIt prints "0 0". Clearly incorrect. If both files are compiled in c++11 or both compiled in c++03, it of course correctly prints "0 1".
C++11 is not evenly-distributed yet Posted Mar 8, 2012 13:33 UTC (Thu) by jwakely (subscriber, #60262) [Link]
Well done, you picked the type I already mentioned above as having changed size and definitely causing problems. I never said _all_ types work ok. Choosing the one type with the most serious and well-known problem is a poor demonstration that you "can't [...] expect things to work right, if they use any standard library objects".
> You could start with std::set::erase(iterator), which grew a return value in c++11
It also changed signature to std::set::erase(const_iterator) so mangles differently and the linker won't pick one over the other.
> It would immediately get closed WONTFIX.
You realise I'm one of the libstdc++ maintainers? I asked you to report specific cases of problems (except for std::list) and CC me to look at them. Even if they got closed WONTFIX at least there'll be a record of the problem and discussion, somewhere more suitable and useful than an LWN comment.
C++11 is not evenly-distributed yet Posted Mar 8, 2012 14:25 UTC (Thu) by jwakely (subscriber, #60262) [Link]
> It also changed signature to std::set::erase(const_iterator) so mangles differently and the linker won't pick one over the other.
Ah, except that set::const_iterator and set::iterator are the same type in libstdc++ ... ok, I'll add that one to my list of potential problems!
C++11 is not evenly-distributed yet Posted Mar 9, 2012 15:35 UTC (Fri) by foom (subscriber, #14868) [Link]
> You realise I'm one of the libstdc++ maintainers?
I didn't make the connection, sorry.
> I asked you to report specific cases of problems (except for std::list) and CC me to look at them. Even if they got closed WONTFIX at least there'll be a record of the problem and discussion, somewhere more suitable and useful than an LWN comment.
Okay. Well, I admit I don't know of any more offhand. And since my app was already broken by the std::list change, it'd be way out of my way to go search for more. I'm not planning to take the risk of combining the two compilation modes again.
Move constructors being added everywhere is certainly another possible breakage point, and I'd be a little surprised if mixing c++03-variant functions in a class and c++11-variant functions in a class didn't manage to break something *somehow* related to move, but I don't know how to construct such an example.
It'll definitely cause ODR-violations aplenty, and at a minimum you'll get strange performance degradations in the C++11 code when linked with C++03 code (when a move constructor would've been called from a stdlib function in C++11 but not in C++03.). Perhaps that (somewhat harmless, but still mysterious) effect is all you'll get there, though...
Anyways, I'm quite surprised to hear that you care at all about this use case at all, since the message I got before was quite strongly: That isn't supposed to work, it *never* actually worked except, maybe, by accident, and you should have known better than to even try it.
BTW, is the list of potential problems you have public somewhere? It sure would be nice if this gotcha with std=c++11 was mentioned on GCC's C++11 status page.
C++11 is not evenly-distributed yet Posted Mar 10, 2012 14:40 UTC (Sat) by jwakely (subscriber, #60262) [Link]
It's not supported, but "don't ask me to support you" is not the same as "you cannot do this even if you know what you're doing."
There's no public list, but I'm keen to know where the problems are.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 3:23 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
'Given that both RHEL 5 and RHEL 6 now have a 10 year supported lifespan, there is not much incentive to make RHEL 7 in any timely fashion (after all, the money is rolling in... "why break something that works ?") "
There is always a bunch of features which cannot be backported easily and as time goes by, the demand for these increases. So despite a subscription model, there is enough incentive to do a new release every now and then. Red Hat has already announced that it is working on RHEL 7
http://www.datamation.com/open-source/red-hat-enterprise-...
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 15:20 UTC (Thu) by dag- (subscriber, #30207) [Link]
You are right, but doing it every 2 years might no longer be necessary. In the beginning new major releases where expected every 1.5 year. That became 2 years and recently almost 4 years.
At some point Red Hat supported RHEL2.1, RHEL3, RHEL4 and RHEL5. With a 2 year release cycle and 7 years of support that would be the same today. But with a 10 year life-cycle, a 2 year release cycle would mean 5 to 6 distributions to support (not including ELS !) So releasing every 3 or 3.5 years (as happened with RHEL6) makes a lot more sense. Companies and consultants don't want too much diversity and shorter release cycles don't help in reducing diversity or even reducing support costs.
So I think it is safe to assume Red Hat will not release major releases more often than every 3 years. Unless you have inside information you are willing to share ? ;-)
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 16:03 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I carefully source my information from public postings to avoid just that. The article referenced does have strong hints on the schedule and while a longer support cycle does influence future releases, so does increased demand and new technologies including virtualization and cloud. We will see how it all works in a few years.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 5:08 UTC (Thu) by dowdle (subscriber, #659) [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. The Amiga's failure was more a factor of Commodore not being anywhere near as big as IBM and the business market being hypnotized by the PC / clone market that sprung up later. The clone part is what aided in the success but what also lead to IBM eventually failing in their PC hardware business.
Moving beyond that point... you also have to remember that while the last RHEL release cycle was longer (3.5 years), Red Hat also happens to be the most active innovator in most everything Linux. They do it via Fedora and via all of the sponsoring they do of a large number of projects. While those developments might take longer to make their way into RHEL, everyone else benefits within their own desired timeframes... so you really can't complain that Red Hat isn't innovating enough.
The main reason Red Hat has to release a newer RHEL sooner is because it becomes harder and harder to backport newer features and customers want them. If Red Hat can't provide them in a more timely fashion, then customers will look elsewhere.
While I too would like Red Hat to come out with new RHEL releases more often, I do credit them for not doing so just because some artificial timetable says they should. To mitigate things they are doing more and more rebasing... so far mostly of desktop apps. Two other examples are KVM and php53 being added to later RHEL5 updates. Expect more of that behavior in the future. I think they 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.
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) [Link]
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?
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.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 18:07 UTC (Thu) by tjc (subscriber, #137) [Link]
> 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.
Jay Miner came from Atari to Amiga (which was then purchased by Commodore), but I don't recall that anyone else did.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 7:53 UTC (Thu) by AndreE (subscriber, #60148) [Link]
The incentive for RHEL7 will come from the desire of customers for new features that cannot be easier backported. I don't see any reason to believe that such desires don't exist or are disappearing
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 16:19 UTC (Thu) by dag- (subscriber, #30207) [Link]
No, but the changes in the kernel development process makes it easier to backport drivers and functionality. This was not the case in the RHEL3 or RHEL4 era. So while for some functionality the effort might be unsustainable, for a lot of stuff it's being done today.
(Look at the advances the _old_ RHEL5 kernel is still making)
BTW the vast progress and usefulness of the ELRepo project would not have been as easy as it is today in the RHEL3 and RHEL4 era.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 16:21 UTC (Thu) by jengelh (subscriber, #33263) [Link]
1. Everything can be backported. 2. If rule 1 does not apply, add more patches such that 1 holds true. (Example: rh kernel)
Now wonder why we still need updates if everything can be reimpl^Wbackported.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 10:26 UTC (Thu) by NAR (subscriber, #1313) [Link]
On the other hand if they are giving 10 years of support, with new releases every 2 years it would mean 5 supported releases - which might be just a bit too much.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 11:46 UTC (Thu) by kragil (guest, #34373) [Link]
RH main competitor is VMware and they offer so many features that can hardly be backported, so they might even accelerate the cadence of releases to compete. 2013 will see RHEL7 IMO and 2015 RHEL8 IMO.
How Red Hat killed its core product—and became a billion-dollar business(ars technica) Posted Mar 1, 2012 15:36 UTC (Thu) by idra (guest, #36289) [Link]
" Given that both RHEL 5 and RHEL 6 now have a 10 year supported lifespan,
there is not much incentive to make RHEL 7 in any timely fashion (after all, the money is rolling in... "why break something that works ?") "
I think you do not understand the subscription model if you think in this terms. The money rolls in only if customers are satisfied, Red Hat is not using an old business model of selling proprietary crap for high upfront cost and then forcing you to buy maintenance to go forward. Pretty much the opposite. So in order to be appealing Red Hat has to release the requested features in a timely fashion.
|
|||||||||||||