Slashdot Mirror
Red Hat Interviewed about Red Hat Linux 7
theridersofrohirrim writes "Linuxtoday has a very interesting summary and some interviews with redhat staff, regarding redhat 7, gcc 2.96, and more. It also includes some embarassing (but justified in my opinion) comments for Slashdot's redhat 7 bug story. Linuxtoday's article can be found their site."
Freedom to innovate (through incompatibilities with existing standards), providing the product that the consumer wants even it means releasing buggy beta software, discontinuing support for multiple platforms. I think I've already seen that somewhere.
Thank God for visionaries (or mere realists?) like RMS.
--
Violence is necessary, it is as American as cherry pie.
H. Rap Brown
Eric Trohan said (quoted in this article as saying, anyway):
"Moving Linux forward is important, however. Doing that requires changes that can make it difficult to move applications from newer systems to older ones. This is inevitable, and every platform vendor has this type of problem (applications built for Windows 2000 apps do not work on Windows 98, for example)"
This, actually, is bullshit. Windows 2000 is fully binary compatible with Windows 98 (and Windows 95). I build software on Windows 2000 all the time that runs perfectly fine on the 'lesser' Microsoft OSes. There are some APIs that by default are only shipped with 2000/NT, and there can be API differences (true 32-bit GDI in NT/2000 as opposed to 16-bit thunked), but Trohan is vastly overstating incompatibilities to cover for his company's boneheaded move.
Linus has blessed an old version of gcc (ala egcs) as the stable version of gcc to build kernels, so RH includes it as "kgcc". But if you compile your own kernel, you knew that, right?
The big GCC complaint is that object files, *.o, won't be compatable between 2.95.2 and 3.0 - except for C (and Fortran?), so basically C++.
This means you can't distribute *.o files made in C++ from one OS to another.
Maybe some of you have had to do this before in your life, but I never have. And if you do, older versions of GCC are freely available for you to downgrade to (but if you're the type that sends C++ object files around, you knew that).
The ELF binaries that GCC makes are still 100% portable.
RH7 looks like it was made for 2.4.x kernels, but when they realized that 2.4.x was still down the road they decided to release it with 2.2.x.
If I were RH, I would have released it for two reason: (1) there comes a time when you must freeze something for QA and only do bug fixes, and from that point on there are no new features. If RH sat on 7.0 too long it would have been completely out-dated by the time 2.4.x came along.
And (2) releasing now means that they can drop 2.2.x support and start focusing properly on 2.4.x, and getting DRI/AGPGART/GLX/etc/etc worked in properly.
There have been 613 bugs logged against RH7 in Bugzilla (as of earlier today). Something like 287 of them are "NOTABUG" or "DUPE", and another 300 or so are "FIXED".
This says to me that out of everyone calling Red Hat unstable, and unusable, etc, etc, less than 600 people have taken the time to do something productive about it.
No, instead all you ever hear is how Redhat sucks and Debian is the best thing in the world
Redhat may not compare to Debian in many aspects, however has anyone ever looked how redhat may actually be BETTER than Debian??
think about it ...
its sad to see that much of the lInux/BSD community are nothing but Anti-Microsoft and Anti-Redhat bigots?
maybe its just me .. or does it seem politically correct to hate the "winner"
Sunny Dubey
dubeys at bxscience dot edu
Most significantly, they have changed the kernel header files (to support the 2.4 version). That in itself should be enough to warrant a major version number increment. (That was how we did it in the good old VMS days!)
Red Hat lists the enhancements as
Hi!
the market debugging windows for free is helping to fix their tightly held closed private property, whereas debugging a distro of open software is helping out the entire community of GPL users, including oneself. XFree86 ver 4 isn't RH 'property', nor is their own GPL'd creations. I'll help debug Msft property for free the day BG comes over and mows my grass and paints my windows for free. That's one of the secrets of their vast riches and there's still a lot of MS suckers out there working for nothing, or maybe for the priviledge of an early preview of upcoming products.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Slashdot was on crack that day.
11*43+456^2
I, for one, am very happy to see that *someone* is still compiling and releasing bleeding-edge distros.
"Release early, release often" should be burned onto the foreheads of every single distro manager. It's the whole engine that powers Open Source.
And as for "GCC 2.96"... That's a great idea. The GCC folks have a really nasty-bad habit of living behind their ivory walls, and tossing a release over the gate once every *year* or so. Rubbish! Get it out there, let us use it, let us find the bugs!
And if the widespread adoption of a GCC newer than 2.7.8 finally convinces Linus to fix the hackery in the kernel that exploits non-standard GCC behaviour in older versions of the compiler, well, then so much the better.
Hey, newbies! One of the whole points of this "Linux" thing is to actively find and report software bugs, so that they can be fixed. Linux is a participatry experience, not a "product". Red Hat's "product" is the service of gathering up all the bleeding-edge stuff, testing it for a certain level of usability, and then packaging it in a convenient format for you to get at. To expect a distro- any distro - to be bug-free is to miss the whole point!
I *strongly* recommend starting with a RedHat *.0 release - you get to see the newest stuff, and you get to actually contribute to the process.
Go Red Hat! The distribution for people with balls!
Want to learn about race cars? Read my Book
RedHat 7.0 only poses a "problem" for those people interested in backwards compatibility. And I hate to break it to you folks, but backwards compatibility eventually goes the way of the dodo. It dies out. It goes away. And Linux far more strenuous about removing old cruft than Microsoft is. See going from 2.0.x kernels to 2.2.x kernels and libc5->libc6 as some recent, balatant examples. Going from good ole egcs to gcc is another step up the evolutionary ladder. It's not like the other distributions aren't going to move to it when it's released. RedHat is just leading the pack to adopt it, and will have support for it already in the distribution when it comes out. Along with support for 2.4.x. kernels waiting as well. All of these things benefit the newbie at the cost of backwards compatibility. The newbie gets to run the shiny apps. The newbie gets the spiffy performance figures. The newbie gets stuff that works because the newbie isn't trying to walk against the wind.
Yes, backwards compatibility is nice. It's wonderful. You just have to be willing to pay the price to get it.
It also includes some embarassing (but justified in my opinion) comments for Slashdot's redhat 7 bug story.
I know that the slashdot Editors/Hemos/etc say they're overworked & don't have time to check their facts, but just how much damage do you think that the original story that slashdot posted did?
The mainstream media (who don't know any better) often look to slashdot as a source for stories - I just wonder how much trouble it stirred up for no apparent reason? Isn't that FUD?
I've been using RH7 for a few days & have found it to be a good, if not a little bloated, distribution.
Please, please, please start checking the stories before you post them.....
Nah, please save the flamage. RH7 came up fine, "gcc 2.96" even compiles a decent kernel. (Though some of those CPP warnings are clearly kernel source bugs...) X11 update, Gnome update, ... lots and lots and lots of updates, it feels better than 6.2 already.
You know, I've been wondering when the heck the GCC team would move past the 2.95.2 release ... considering that I've been wanting SOME release with GCJ support for a really long time. I know a lot about the C++ ABI problems, as does anyone who's developed production code in C++; and I just don't see RedHat as having worsened any of those problems. Frankly, more conformant C++ is a major step forward ... and didn't just a few compiler optimizations get out of the "research" world (of gcc developers) this way? We've been wanting better GCC code generation a LONG LONG TIME.
Why is RedHat getting flamed, instead of the GCC folk? GCC created a problem ... and hasn't been seen to be fixing it. Where's even a draft schedule for "GCC.next" releases? Say, bugfixes to the 2.95.2 release of last year??
I know why RedHat's getting flamed. Slashdot, and the flamers that keep the LKML noise content too high for me to tolerate. However, the signal in those flames is pretty much invisible.
First, in your statement:
Let me try to clear this up a bit. Taking a snapshot, heavily testing it, and releasing it with a slightly changed version string ("experimental" -> "RH 7.0") isn't a major problem by itself. Yeah, it's binary incompatible, but GCC 3.0 was going to be so anyway.What annoys many of us on the gcc-bugs mailing list is that RH did not also change the bug reporting email address, or anything else, to indicate that this is a technically unstable release. So the list gets all these messages complaining about an unstable release that should have gone to Bugzilla instead. The GCC team is not RedHat's front-line helpdesk system.
Second problem, from the article itself:
*boggle* Which ones do you think they were addressing?!? There's only been one distribution so far to do this...You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Half the people seem to want "innovation" (or bleeding at the edges -- what you call it is a matter of opinion) and the other half want "stability" (or lagging behind the times, ditto). It's just not possible to satisfy both factions at the same time.
.0 releases if they knew that in a couple of weeks' time there would be a .0.1 patch to deal with some of the running wounds.
Instead of compromise, how about adopting a 3-digit release scheme instead? Ie. let the label "7.0" be the thing that appears on pretty RH box fronts, but let it be 7.0.X in reality, depending on the date of production. If the X is available as a patch upgrade on the RH website, nobody loses.
This would satisfy the release early and often brigade, while at the same time it would reduce the software sellers' nightmare of carrying rapidly obsoleting stock, and production houses would be more likely to upgrade to new
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Can you show me the server-side code release for their fancy little Update-Agent?
The GPL doesn't specify that you have to give the source to anyone who ask for it, only to those who you distribute your software to. So, you distribute a piece of software, you distribute the code too.
As far as we know, the server-side Update-Agent could be GPL, and RedHat would still have no obligation to give out the source code.
Je ne parle pas francais.
historicaly haven't redhat's .0 releases been buggy? I installed 7.0 the other day and am pleased to see some new small things like a graphical lilo menu (hey it's prettier then nt's boot loader menu)and they changed the kernal hacking icon in the graphical install (hehe i know it isn't important) i'll deffinatly wait to use it on anything important.
one thing i am dissapointed in is the lack of sparc support for 7.0 but i guess you can't have everything.
i've noticed that some readers of slashdot have stuck there noses up at redhat because of various reasons shouting things like "Debian is better" or "slackware is superior", but i have to admit that i was weened off of windows with redhat, and alot of my skills came from useing and tinkering with redhat. and it will always have a place on one of my boxen.
sorry about the fragmented comment, but i'm tired
who sez death can't be funny....www.endlesssorrow.com
I don't know what the ruckus is all about. With the release of 7.0, more posts were made about "I hope it's not as buggy as 6.0!" and "I'll wait for the .1 release!" then most others, yet people still insist on installing and then complaining? (loudly, rudely)
The introduction of gcc was justified to me. Perhaps not to you, but I understand their reasoning. The inclusion of kgcc should have been enough; RTFM.
I understand that without complaints problems may not get solved, but there's probably better ways to spend your energy - utilizing Bugzilla and the like. If all you do is cause the RedHat crew to expend energy to answer allegations of abuse and bugs, then you're taking them away from SOLVING the problems.
And in either case, it simply goes to prove that you should *ALWAYS* wait for a service pack or release greater than 0.. *grin*
The LinuxToday article just goes to prove that those of us who post on Slashdot have greater impact than we may realize, for good or ill.
-- Talonius
My reality check bounced.
Wrong. Among the things I can think of off the top of my head (and considering I use Debian, I'm sure there are lots more that I can't think of) include XFree 4, a brand-spanking new RPM (4.0, IIRC), and a filesystem reorganization to make things FHS compliant. All of these are major changes, striking at the core of how the distro works and is installed, and as a result merit a new release. Please, take the time to actually find things out before you post.
~luge(frustrated that by the time I post this will have been moderated up as "interesting" instead of down as flamebait)
IAAL,BIANLY
As someone close to the product cycle of a large software product, I can say these guys are going in the right direction.
:-)
Their techies are fighting a losing battle: to include a feature, or not. You see, the product/build/whatever manager has to commit to a delivery date so that the marketing, delivery, and sales efforts can come together at a reasonably coherent time.
The techies then have to get nose to the grindstone to match up with the expectations of the product/build/whatever manager, and get the features they promised out the door in time. Even if they have an even cooler feature that didn't make the list, but they feel makes the grade.
By seeing them releasing a "2.96" version of GCC, one which GNU would obviously like to see waiting until a more publicly acceptable major release, they're showing they have a structure in place that favours "release early, release often" more than "wait for the proper product". We're seeing here the coming together of all the best ideas of Open Source, with the best management control. Alan Cox approves, he's even allowing the inclusion of a patch that hasn't made it into the mainstream kernel...
Having said that though... I can't wait for version 7.1
/prak
--
We may be human, but we're still animals.
Can you find one quality hacker that wouldn't put the latest gcc up on their own system, disregarding what it might do until it does it -- and then telling you that knowledge of the fix is just part of what any self-respecting admin should know anyway?
The upset stomach that /. has had over 7.0 is just fanatical kiddies trying to put down one distro over another. Too bad their wanking is going to hurt the entire Linux community. Red Hat trading at $5/share doesn't mean anything to these jokers, until they graduate and are forced to slave over a Win2003 "console".
And the value of /. is diminished by such ranting. I agree with Taco's recent chat denying any actual level of responsibility. But that means all the rest of us have to be *very* responsible. *Mostly* moderators and meta-moderators.
If the community is going to reward anti-Red Hat group-think, or even anti-MS group-think, the community will pay dearly. People, please moderate and meta-moderate well...
--
Seems that the folks at RH have some very good reasons for what they did. The gcc bit is still a bit bothersome though. They should have communicated better with the GCC dev team, otherwise...
/. According to Troan First of all, the 2,500 number was all of the open bugs in our ticket system for all releases of all products. It includes engineering requests as well as our engineers internal todo lists for future releases. Although I didn't follow the original slash posting (thought it was pretty low S:N ratio) and haven't checked the bug list personally, if what he says is true then the poster and in part the /. community has done a disservice to RH. Sensationalistic journalism is all to prevelant elsewhere we shouldn't support it here. Unfortunately too many people, especially the other news mongers out there dont delve very deep into comments (if at all) which just spreads the misinformation.
The thing that gets me is the bit about 2500 bugs etc. Especially the reporting on