Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Red Hat Software Businesses

Red Hat Linux 7.1 Release Announcement 408

Many people have sumitted that Red Hat has announced the release of 7.1. I don't see it on the ftp site yet, but, if I don't post this, I'm gonna spend all morning deleting this submission *grin*. The new features include a 2.4 kernel, USB, Updated XF86, and assorted other stuff of varying importance.
This discussion has been archived. No new comments can be posted.

RedHat 7.1 Release Announcement

Comments Filter:
  • by Anonymous Coward

    Er...

    I was referring to the documented problem that c++ binaries compiled on 7.0 will not ever run on non-redhat 7.x distributions. IE, they will not run on 6.2, and will not run on gcc 3 based systems when they arrive.

    Yes, I agree they are including questionable software with the intention of stabalizing that software faster and so they have stable distributions when other distribs are still trying to figure out the newly stable software. This is all fine and dandy, I just wouldn't use unstable software, whether it is because the binaries are unstable because they are a .0 release on an unprepare distribution, or the binaries are unstable because they are a .999 release on a prepared distribution.

    But, it appears (see other post) the consensus is to downgrade GCC

    Andrew Robertson (paranoid 6.2 user)

  • How am I supposed to convince my management to move Oracle off a 30-gig VxFS and onto RedHat if I still have to deal with fsck?

    You should have waited!

    Red Hat needs a journaling filesystem with large file support. This is a big disappointment.

  • Anybody doing anything serious with Red Hat is still on 6.2.

    Even Red Hat's own high availability and Oracle-optimized releases are 6.2-based.

    Without a journaling filesystem, there still really isn't much motivation to upgrade.

  • by emil ( 695 ) on Monday April 16, 2001 @12:08PM (#288746)
    1. We need a journaling file system. NT has had one for years; we are remarkably primitive in this respect. With ReiserFS ready, and XFS/JFS mostly there, there is no reason to wait for ext3. Don't just decide; let your user community have influence on the decision and support your move with performance benchmarks. Make sure it works with large-file support. If you want to sell server operating systems, drop everything else and get this done. This is tarnishing your reputation.
    2. The only reason that you don't have a desktop market is that you aren't trying to get one. Please release a desktop version of RedHat with Ximian Nautilus, Wine with DirectX, KDE, Openoffice and anything else that seems appropriate. Businesses are screaming about desktop Windows liscensing costs; take the opportunity to make some money. It's probably even time for separate workstation and server CDs - makes more sense than what you're doing now. If you are spending enough time to make a workstation install, you might as well spend enough time to do it right.
    3. If you want to do something like xinetd, then fine, but give the user an install option to choose the standard UNIX behavior. Is inetd a part of POSIX? Is Red Hat 7.x even vaguely POSIX-compliant at this point? The GNU tools have POSIXLY_CORRECT settings; take the hint.
    4. Do whatever it takes to RPM to satisfy the apt people. If you were bold enough to rip out inetd, then you should be bold enough to rip out RPM if necessary.
    5. By the way, I don't like what you did with INPUTRC. Put it back the way it was. I like vi mode, nobody else does, move it back to skel.
    6. In fact, it's time to integrate the Korn shell into the distribution. Bash's limitations remain too severe, and commercial UNIX people write too much for ksh.
    7. Never put out a production release that requires more than one compiler again. It's just ugly and a waste of space. A system should be consistent and true to itself.
    8. Unless you really plan to give people a kernel version upgrade, don't mix-and-match the kernel components. It's just ugly, and it tarnishes your reputation.

    If you do these things, you will no longer have to worry about Mandrake or Suse. They are only successful because they are fixing your mistakes.

  • Point oh releases, by definition, break things and cause confusion. This point-one is really nice -- very stable and well-put-together all around.
  • by Chang ( 2714 ) on Monday April 16, 2001 @06:38AM (#288756)
    They are shipping kernel 2.4.2

    I'm running an updated Wolverine beta which is pretty close to 7.1 and I haven't had any problems installing "older" RPMS.

    Kudo's to NVIDIA for releasing their binary only driver wrapped into a source RPM. Very nifty for people who like to run custom kernels or beta versions.
  • do it really matter if your web server can fill a gigabit ethernet pipe?

    Until recently, I used to agree with you, as no-one could afford that much bandwidth to the internet. However, that's all changed now, and we're looking at getting a gigabit internet link to the office at work, and the prices are *really* cheap. For high volume sites, a web server like TUX may well be needed.

  • With wine you forgot to mention that it doesn't work unless you already have a Windows partition. At least in my experience, without an Windows tree with its dlls, you can't get anything except minesweeper to run.

    I'd love to hear from other people that have had better results though.

  • Do Compact Flash Adapters fall under Storage devices?

    I'm hacking both of my grandparents' iopeners so they can get email again using any ISP. It would be cool if I could use my existing compact flash cards as "floppies" for putting pictures and software on their systems without having to download them via modem.

  • Originally, Mandrake was a Redhat base, with bugfixes, some newer stuff, and KDE rather than enlightenment/gnome.

    Since then, the've sortof gone their own way - they're still rpm-based, but AFAIK, they're not based on Redhat anymore.

    I use Debian myself, though. If someone using Mandrake would correct me if i'm wrong, I'd appreciate it =)

  • How am I supposed to convince my management to move Oracle off a 30-gig VxFS and onto RedHat if I still have to deal with fsck?

    You don't. Linux isn't always better that Solaris or HP/UX . And there is no filesystem on linux as cool as VxFS. Journelling != Logging . Journeling means that every write is repeated a second time. Logging only writes once. Gee what is the slowest operation on RAID-5 ummmmm...WRITING maybe.

    I love Linux and think it will take over the world, but it ain't ready to run E10k with 1TB filesystems using Oracle in all it's tweaked out glory.

  • I'm getting over a hundred kB/sec from ftp.ens.utulsa.edu, which beats the full redhat.com servers and the 10 kB/sec rpmfind.net servers. If you're on ftp.redhat.com, you might want to just grab the MD5SUMS to verify packages with, then move to a less crowded mirror.
  • A distribution is not allowed to change /opt, right?

    Also there seems to be very strong feelings amoung Linux developers that /opt is a mistake and /usr/local should be used instead. They serve the same purpose and there is no reason for two locations, and /usr/local seems to be winning.

    Of course the distribution can't write over /usr/local either.

  • Yes. 2.95.3 is a minor bugfix release. That means all the problems with 2.95 (C++ incompatibility, etc.) are still there, with the excpetion of a couple major bugs that had easy/small fixes.
  • Actually, most distributions will just go straight to GCC 3.0. Frankly, I have a hard time believing that a fork of a beta GCC that still isn't released (the release branch of CVS hasn't even bootstraped for days on end recently) is perfect, especially considering that no previous release has ever been perfect.

    Just because code is poorly written doesn't mean that gcc can get away with not compiling it. Sucky but standards complaint is still standards compliant code, that needs to be compiled.
  • You know, there aren't that many DNS servers to choose from. Go read one of the latter lwn.net issues. They summarized the problem quite good. And no djdns is not considered an alternative to bind.

    I am working on that particular issue. MaraDNS [maradns.org] is a public domain DNS server that I have been working on for the last two months. Currently, MaraDNS has roughtly the functionality of TinyDNS--it works as an authoritative DNS server, but not as a caching DNS server.

    A 1.0 release should come out in early June. Look at the roadmap on the MaraDNS web page.

    - Sam

  • There may be a 3rd party installer for 7.1+reiserfs, but I know for certain that there is one for SGI's XFS filesystem. See oss.sgi.com/projects/xfs, or search freshmeat for "xfs". Right now it only works with wolverine but that will change shockingly soon. :)

    ---

  • by tuffy ( 10202 ) on Monday April 16, 2001 @09:37AM (#288783) Homepage Journal
    If we waited for 2.4.4 and released 7.1 after testing it, 2.4.5 would be current by the time it got out of the door. If we waited for 2.4.5, 2.4.6 would be current.

    Obviously, you should wait until the Linux kernel is completely finished before shipping one. Once it reaches version 300.4-complete, then that should be about right.

    Not officially supporting anything that hasn't passed QA isn't corporate idiocy either. It's simply practical.

    Since RedHat is Linux (according to the press), you're obviously required to support every version of every piece of software that is compatible with Linux. Therefore, omniscience will be a hiring requirement for all support staff.

    (but seriously, working on Linux all day must be a lot of fun except for all the stupid questions that pop up...)

  • The religon of Islam itself forbits slavery completely.

    It also forbids blowing up car bombs on city streets.

    -
  • As someone who packages with RPM 3.x regularly, I wish there was better documentation on the changes and new features in RPM 4+. All of the good public documentation for RPM is for version 2.x, and there are a only a few references for 3.x. I haven't been able to find any *usable* documentation for 4.x (No, the changelog is not usable). Is anyone working on this? Why should I stop using my "ancient" RPM version when the new one is undocumented?

    -OT
  • by MSG ( 12810 )
    C++ support for GCC has never been that good for exactly those reasons. If Red Hat had used any version of GCC other than egcs 1.1.2 (from 6.2) their C++ binaries would not have been compatible with the older, 6.x versions or the 8.x series which will most likey include gcc 3.0.

    Based on that unavoidable problem, and their need to support the Alpha platform, Red Hat's engineers decided to use a version of gcc from CVS, and have done a lot of work to make sure that it's stable. Red Hat 7.0 has been rock steady for me. None of the components have suffered because of gcc 2.96rh. It produces stable binaries. Reports of Red Hat's demise are greatly exaggerated.

    But, it appears (see other post) the consensus is to downgrade GCC

    This consensus is generally reached by the uninformed. You will only cause yourself headache by doing this.
  • I used to use Mandrake 7.1 but it seemed a little too proprietary. I'm now using SuSE 7.1

    Have you checked out SuSE's licensing? You might want to look at section three of the YaST license [suse.com].

    It is hard to find a Linux distribution more proprietary than that, dontcha think?

  • > Allah likes his children to only use the works of circumcised men who follow the will of allah. ... So we in syria have started new unix variant.

    Trimmed a bit too close with that circumcision knife, eh?

    Oh, 'Unix'.

    --
  • by Black Parrot ( 19622 ) on Monday April 16, 2001 @02:09PM (#288805)
    I don't know the difference (if any) between ATA/* and UDMA/*, but I notice this in the announcement:
    - IDE UltraDMA/66 and UltraDMA/100 contoller support
    I have an ATA/100 card, and one ATA/100 disk on the card and another on my m.b., and the 2.4.0 kernel that shipped with the first Red Hat 7.1 beta recognized them fine without any extra effort on my part.

    FWIW, /sbin/hdparm -T -t shows about 170 MB/sec for reading the disk cache, and about 30 MB/sec for buffered reads off the disk itself.

    (I tried to post other useful snippets from my logs and program outputs, but Robs lame lameness filter is hyperactive today, and keeps rejecting my posts.)

    --
  • We think helping GNU parted to get ready is a much nicer way to address this problem.

    That would be great. But I have been wondering why parted gets so little recognition these days. When last I used it (to resize a FAT32 partition on an IBM Thinkpad), it Just Worked, which shocked me, considering that nobody in our well-informed Linux users group (MLUG) [missouri.edu] had apparently ever tried to use it, despite the fact that the "non-destructive resizing" question is a true FAQ.

  • it's there, but the original author seemed to have too much faith in his T-1; the site seems to be slashdotted already.
    It is in ftp://ftp.webtrek./pub/mirrors/redhat/linux/7.1/en [webtrek.com]
  • The 7.0 compiler is not reliable. When compiling the NTL libraries, the compiler segfaults. This is bad, compilers are not supposed to crash! Don't tell me that the problem is because the source is no ISO compliant.
  • I agree. They take a very conservative position towards upgrading. That is good for servers but it really sucks for clients. I love apt-get but I hate to have to point it to obsolete packages. Pointing it to non obsolete packagers automatically makes you a beta tester (which I'm not).

    Apperently there are some client oriented debian spinoffs now. I just might try one of them these days.

  • woody is testing, not stable. And despite rumors on the contrary I have run into trouble using it.
  • Or if you read the prior posts, maybe it's YOUR code that sux. Prior versions of gcc were more forgiving with poorly written and/or non-standard compliant code - that doesn't make your code any good.

    Revisit your code ASAP and fix it because guess what? RH may be ahead of the rest, but eventually ALL distribution will use this version of gcc.
  • I doubt any code is ever perfect - otherwise, why would anyone keep developing it?

    But (just like Linux said about 2.4), 2.95.3 is better than it's predecessors, and 3.0 will be better than 2.95.3. But one thing for sure, the people having problems with 2.95.3 will have the same problems with 3.0.
  • Not always, freqently slaves are taken to be rented or sold for sex, it even happends in the US, though significantly less than other countries.
  • Maybe because gcc 2.96 is a better compiler? Bero has a page [bero.org] that you might want to check out.
  • O don't know if it is already to late to report problems here, but I think that this release seawolf is bad in a number of places :

    the mouseconfig program creates a /etc/sysconfig/mouse file that the Xconfigurator program thinks it is a bad file.

    /etc/init.d/named status does not work. It reports it cannot connect, even though the named is working fine.


    --
    "take the red pill and you stay in wonderland and I'll show you how deep the rabbit hole goes"

  • "what qualifications do you have in the field of software design and verification testing, PigleT?"

    What does it matter to you?
    As it happens, I have worked in the software testing arena - and I got out pretty fast when I realised it hinges all around the same idea, `official support (with a view to us employing idiots and making lots of money)' rather than clueful knowlege.

    FWIW the company for whom I worked in the testing department "supported RH5.2+6.0", and even then they only "supported" Gnome, not KDE, for the front-end GUIs.

    "Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat."

    In nearly 2 years of tracking Debian unstable, I've never yet once had to ask for help in tracking a break, and have no intention of doing so yet.
    ~Tim
    --
    .|` Clouds cross the black moonlight,
  • That would have been the War of 1812.

    Historians cleverly employed an early type of data compression by using the same value for the date and the name of the war ;-)

  • stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).


    I've been using ReiserFS for over a year in SuSE and I haven't had a problem. It is not "known broken." VA seems to trust it enough to store Sourceforge data.

    I think everyone will agree that it's Red Hat that have been shipping known broken components in 7.0: gcc, et al.

    Also, Red Hat seems to be far behind other distributions in the maintenance of the distribution. The installation and configuration tools are much more mature on Mandrake and SuSE than on Red Hat.

    I'm not trying to flame here, but there's this old saying about a pot and a kettle.

    Finally, let's include a snippet from my terminal. No it isn't very scientific, AC isn't in there, but...

    jfunk@arthur:/usr/src/linux > grep redhat<CREDITS
    E: hdeller@redhat.de
    E: jakub@redhat.com
    E: johnsonm@redhat.com
    W: http://www.redhat.com/~johnsonm
    E: davem@redhat.com
    E: sct@redhat.com
    E: dwmw2@redhat.com
    jfunk@arthur:/usr/src/linux > grep suse<CREDITS
    E: andre@suse.com
    E: hohndel@suse.de
    E: hubicka@suse.cz
    E: aj@suse.de
    E: davej@suse.de
    W: http://www.suse.de/~davej
    E: jack@suse.cz
    E: perex@suse.cz
    E: pavel@suse.cz
    E: mj@suse.cz
    E: vojtech@suse.cz
  • Your list is bogus


    I said it was unscientific and that Alan Cox wasn't on it. Jens Axboe of SuSE isn't on there either.

    extremely sensitive to hardware failure - lose a few blocks, and your btree dies.


    That's not really true, unless I was dreaming the time the hard drive on my laptop started getting bad blocks. I'm pretty sure that if my btree died, I would have known it.

    corrupted data is what you get with the 2.4 kernel SuSE ships.


    That's FUD and you know it. I'm on the SuSE english users list and I have heard no such thing.

    the SuSE [installer] is really bad


    Based on what? What's bad about having Windows partition resizing in it? What's bad about having a list of packages with short descriptions to the right? Icons make no sense because they are all the same. There's nothing you need to graphically differentiate with icons in the installer. It also looks ugly when the package name wraps and there are no short descriptions there.

    With the SuSE install, I can make multiple primary partitions. I remember having to write the steps to switch to a console to use fdisk in a paper at work for installing Red Hat.

    Have you actually looked at YaST2 and it's design? SuSE customers can do whatever they want with it to make custom installers, etc. Alice is cool, too. I'm even saying this as a Python freak.

    Do note that I use both Red Hat and SuSE on a daily basis and I end up doing a lot of installs with both.
  • RedHat 7.1 is open and available at ftp://ftp.webtrek.com/pub/mirrors/redhat [webtrek.com]! Go slashdot the T1 it's on. :-)

    ---
  • The versions of GNAT that are shipped with Red Hat 7.0 don't work with Red Hat's GCC snapshot[*]. And since you can't recompile GNAT from sources without having a version of GNAT installed to bootstrap itself, that means GNAT is fundamentally and profoundly broken.

    This was extremely displeasing to me when I first came across it, because I'm an Ada95 hacker.

    [*] No offense meant, guys, but I don't like calling it GCC-2.96; it's not a sanctioned release, so I just feel more comfortable calling it a snapshot. That's not to say I think you guys made the wrong decision; as a C++ hacker, I'm far more pleased with your snapshot than with GCC-2.95.
  • Chromium [chromium.com] (where I used to work) sells a user space Apache that's as fast as Tux. Too bad I don't work there any more.
  • by Sylvestre ( 45097 ) on Monday April 16, 2001 @06:22AM (#288852) Homepage
    How can we look to RedHat for technical leadership when Mandrake has already used this version number?
  • "Mohammad Ali had 10,000 slaves put to death when he died."

    Wow, I knew he was an amazing boxer, but I didn't know he was *that* mean...
  • Since Slashdot is naturally my personal Linux support site, let me pose this problem:

    ThinkPad 755CX, 24 MB RAM
    PCMCIA install through FTP
    Error: "You do not have enough RAM to install Red Hat Linux on this machine"

    Tried "boot: linux mem=24M", didn't work.

    Any ideas?

    (RedHat support and searching on the major search engines turns up zilch)
  • No idea if you are a troll or not, but the compiler you ship with 7.0 fails to compile many sources. It is pretty broken.

    Regression is a good thing when you've gone too far.
  • Is the loopback device fixed in the RH 2.4.2? I recall it being pretty much kaput in the vanilla 2.4.2.
  • Only the official IBM kit went away. ODIN (formerly Win-OS/2) is still around and could be just as good (or perhaps better) than WINE.
  • Yahoo. That was soooo funny. Not. It would be, if Windows was actually version 2000.0, but its not, its the version released in the year 2000. I, for one, think this is not at all a bad idea for something like Windows, where major versions are released every few years, and patch-levels are released in service packs. Win2K SP2 is a lot more asthetically pleasing (and informative, since it details the patches installed) than RedHat 7.1 or kernel 2.4.2. There really is no use for the complexity of the three number format (two number are enough to handle most anything pretty well) and stuff like System V R4 or X11 release 5 are just so much more asthetically pleasing. Besides, a version number on a distro is almost 100% useless, since a lot of (I know for sure that at least 90% of you guys have extensively modifed your distros beyond recognition) software on Linux distributions are applied in between version numbers. Thus, the whole arguement over version numbers is more or less moot.
  • Islam isn't a religion of violence. Neither is Christianity, Buddhism, or whatever. However, it is a fact that almost all pervasive religions have been spread through some means of force. The muslims converted parts of Africa and Asia, and the Christians forcibly converted North and South America. There have been tolerant Christain countries (The US for one) and intolerant Christian countries. There have been tolerant muslim countries (early muslic arabic societies and pre WWI Turkey) as well as the muslim parts of the eastern Indian subcontinent, and intolerant muslic societies. This fact is applicable to all religions. Its a sorry truth, but a truth nonetheless.
  • Downloading seawolf isos. Beta 1 was Fisher, Beta 2 was Wolverine. Guessing that seawolf is release.
    treke
    Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
  • ...NOT

    alltrough the transfer rate is great, the iso's are botched (md5sum mismatch)

    (I lost 2 hours trying to boot the damn thing :( )


    --
  • Likewise, I too have been using ReiserFS with 2.2 for around a year. That said, Civilme on Mandrake's Crashtesters list acknowledges ReiserFS under 2.4 )and perhapds 2.2 - I'm not sure) to be unstable. The message is on the crashtester archives from today, but I've deleted it, so no quote...

    Red Hat's gcc was severely broken upon release. But so is the current gcc 1.95. The difference is that 2.95 is currently more broken than 2.96 with all the updates (2.95 can't compile glibc 2.2 on non x86).

    I don't think Red Hat should complain Mandrake are `stealing' their compiler. That's *very* weak. Mandrake are more acturately using (and legitimizing) Red Hat's compiler.
  • rpm: I think the rpm + up2date combo has all the features you need. If you think there's something we need to add, please let me know..

    A centralized repository of packages (unsupported by Red Hat), organized and tested by Open Source maintainers, but providing a wide variety of pakcages.

    Users will install unsupported software anyway, but the lack of a single place to find *good* Red Hat packages annoys many Red hat users, myself included (though easily finding the distro better than itys competitors). By using Red Hat's bandwidth and mirroring, it would be *the* first place to look to find packages. With an appropriate warning, up2date could also get packages from these mirrors.

  • Yes we. Do. We also remeber lan's reply - while Alan works for Red Hat, I doubt he's one to mince words, as would most people who have had some contact with him would attest.

    I know who I would trust with my kernel. Can't remember the link - Google is your friend.
  • Where my man have you heard of slavery in Islam ? Please go look up a history book to find that long before America decided to free slaves, Prophet Mohammad (Peace be Upon Him) would free any slave that came to his house. The religon of Islam itself forbits slavery completely. If you have heard of such a thing, i fear that it was just more FUD. Dont believe everything you hear, or for that matter a lot of things you see. If you are able to read, why dont you go read about the religon and not just believe any crap someone tells you.

  • Well you are not talking about religon then. You are talking about the ppl. that follow it! In that case what you are saying is well...
    For all religons there exist men that do bad things, this i agree with.
    What I dont agree with is your backward conclusion that since a few ppl. took part in slavery, AND they were in fact followers of a religon, than the religon allows it!
  • "...I'm gonna spend all morning deleting this submission *grin*."

    I always got the impression that you enjoyed deleting submissions.

    ~J

  • It's not my page, I just find different links on occasion.
  • by AugstWest ( 79042 ) on Monday April 16, 2001 @10:44AM (#288890)
    from a link on the homepage saying "Latest version of Linux is released":

    Linux 7.1 ready to roll: Red Hat Linux 7.1, the latest version of the company's popular open source server operating environment, is on the market, Red Hat said Monday.

    Red Hat Linux 7.1 includes a new 2.4 kernel with improved SMP support said to enhance performance on Intel multi-processor platforms. Red Hat Linux 7.1 also delivers new configuration tools designed to help users set up and administer DNS, Web and print servers.

    This release features Red Hat Network connectivity, including software manager.


    See? Red Hat == Linux.

    You /.-ers think you're SO smart.
  • If someone using Mandrake would correct me if i'm wrong, I'd appreciate it =)

    Nope, you're pretty much exactly right. I think Mandrake is a great distribution, and I'm looking forward to seeing 8.0 in the stores really soon now. Both Gnome and KDE are available in Mandrake, however the distro doesn't seem to place more emphasis on one over the other. But I think if you just choose Newbie Install or whatever, it might put KDE in by default... In any event, I've never had any problems Gnome on Mandrake.
  • by Eil ( 82413 ) on Monday April 16, 2001 @05:17PM (#288892) Homepage Journal

    I've read this whole thread and I haven't seen anyone else say this yet, so I'm going to.

    Thank you, people from Red Hat for your input and patience in this /. thread. You took a quite a lot of criticism from some of the people here and responded professionally. While I'm not a user of the Red Hat distro, I appreciate all the work that you people put into it because it ultimately means better open source software for the rest of us.

    note: I'm not trying to whore extra karma, I just haven't yet noted anyone else showing their appreciation for the fact that a couple RH employees have been so straight forward and open in this discussion.
  • by sheckard ( 91376 ) on Monday April 16, 2001 @10:48AM (#288901) Homepage
    rsync://csociety-ftp.ecn.purdue.edu::redhat/redhat /linux/7.1/en
  • Remember this [indiana.edu]?

    http://www.uwsg.indiana.edu/hypermail/linux/kern el /0012.1/1252.html for the link-shy.


    "That old saw about the early bird just goes to show that the worm should have stayed in bed."
  • Sparc's been discontinued with 7.0 (try looking for a 7.0 iso for sparc...ain't no such thing). The latesr sparc iso (from redhat anyway) would be 6.2. Here's a link. [cnet.com]
    • Also, inetd.conf has no way of providing information like permitted/rejected IPs.

    Really ? Ok, that is true but most programs that are really required to be invoked from inetd are either compiled to use tcpd libs (for example, ssh imho) OR use the tcpd binary which provides mechanism for hosts.allow and host.deny and clearly you know these provide the described functionality. Ok, that leaves out the part of providing information of the use. Lets see how that can be managed.

    When daemon spawns, let it be ftp or telnet, and connection is established you can see that from your logs. So, that clears the "allowed ip" part. So, what about denied connections. I can say that i didnt really require such things since i use FIREWALL to block unwanted connections. BUT, if firewalling is out of the questions, we can still rely on the hosts.allow and hosts.deny. For example, line like this in my hosts.allow

    • ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port Denial note d %d-%h" root) & : DENY

    And ofcourse, i have listed all IP's that i allow connections from (in hosts.allow AND in firewall) and so if somehow someone manages to get past the packet filtering, i still get info about the suspicious activity.

    ... And all this without xinetd ... Evolving because of stupidity leads nowhere.


    --

  • Does anyone know which version of the 2.4 kernel they are including?

    An early 2.4.2ac with _lots_ of bugfixes - the kernel team fixed a couple of file corruption bugs a day for weeks.

  • There are no iso files for Alpha, as we haven't announced a product for Alpha yet.

    As for SPARC, we're not doing distributions of it - just development snapshots. It's just not worth the development, QA and manufacturing effort right now.

  • Tux isn't khttpd.
  • There aren't known stability issues with Red Hat Linux 7 - of course, as with any distribution you should apply the updates for it but few of these are Red Hat specific. With those, it's a great platform with good performance.
  • But why would you want to? The version we ship produces better code, has more bugfixes and less known problems and is binary compatible with the rest of the distrubution.

    Using gcc 2.95.3 is setting you up for a world of PM.

  • The i686 glibc supports the 2.4 feature "floating stacks" - variable stack size for threads. Existing JDKs have a hardcoded assumption of 2 MB, and this limit in strange, weird and unsupported ways.

    There are two work arounds for these buggy JDKs:

    • Install the i386 glibc, not the i686 glibc. It doesn't require a 2.4 kernel and doesn't have floating stacks.
    • Run your JDK with 'LD_ASSUME_KERNEL=2.2.5'.
    Either one should work. We also expect fixed JDKs to become available in the not too distant future.
  • AFAIR, you get free usage of one system ("trial") but need to pay if you want to add more systems.
  • up2date also has functionality not found in apt-get, such as server/client authentication and verification of the origins of the update (the latter may be solved in the rpm version of apt, but standard Debian can't do it - get trojaned packages onto a mirror, and watch people use it)
  • by teg ( 97890 )

    No, our kernel people don't think it's safe - ReiserFS had quite a few bugs fixed the last month or so. And for filesystems, data integrity is an absolute requirement - this is the first distribution with a 2.4 kernel not known to destroy filesystems under load.

    It is enabled in the kernel, but not during install.

  • Take a look at all the core components, and see whose work it is - it isn't Mandrake. The people who make the it possible work here - no other distribution has a kernel team even remotely comparable to the one we got, and we also have the prime glibc, gcc, gdb, gtk etc. developers working here. FTR, if you look at their beta release, they're even copying our compiler.

    As for updates, security in general, etc. you'll notice that RHL is ahead there too. Online updates (up2date) has been around for years. 3D support was added when it was integrated into XFree, and stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).

  • Note that the updates will break some builds - e.g. newer glibc cleaned up some name space polllution ( vs ), this broke compiling for a lot of packages. Both the pollution and the apps depending on it were fixed for Red Hat Linux 7., but this not released for RHL 7 as it didn't affect functionality.

    We do mass rebuilds on a regular basis, so the packages should build - if you experience bugs with this, report it in bugzilla [redhat.com]

  • Your list is bogus, as quite a few of our kernel hackers don't use their redhat.com addresses their or haver their old addresses in the kernel. Examples are Alan Cox, Al Viro, Doug Ledford, Ben LaHaise, Arjan Van de Ven and Tim Waugh. In fact, the only three of the above who actually work on the kernel are johnsonm, davem and sct.

    As for ReiserFS, it had multiple data corruption issues the last two months and it is extremely sensitive to hardware failure - lose a few blocks, and your btree dies. For ext2, you'll typically only loose the files on these blocks.

    Wrt. to gcc as shipped in Red Hat Linux 7, there's no doubt this is the best compiler out there currently. The issues are wrt. to binary compatibility with C++ and not sufficient labeling as a release made by Red Hat, not by the gcc steering committee. And even so, this is not data corruption - a bug or two in a app is regrettable, corrupted data unacceptable. And corrupted data is what you get with the 2.4 kernel SuSE ships.

    The installation of Red Hat Linux is IMNSHO way ahead of anything else out there - the SuSE one is really bad (and has a non-free license), and I'm not to keen on the Mandrake one either.

  • Qmail and djbdns are not open source, - we couldn't even distribute a fixed version of qmail if a security hole appears. This isn't acceptable.

    As for netscape, we're on the way of getting rid of it as mozilla improves.

  • Having 64 GB of RAM won't help you with quake III. IA32 is still a 32-bit architecture, so one process can only see 4 GB at a time.
  • As for the SuSE installer, that's my personal impression: Nothing else. I don't like it. I've used Red Hat Linux since 2.0ish, and I like our installer very much (I don't miss 40 floppies of slackware:). The only two other installers I've been impressed about in those years are Caldera when they started tetris during install and Corel (apart from it's obvious shortcomings, but it redefines simple). SuSE's installer just seem unpolished and confusing to me.

    As for 2.4 kernel, it's not FUD. During heavy load it corrupts your hard drive rather well. Take a look at the last changes for the 2.4 AC kernel, look for corruption and who fixed it and realize SuSEs kernel can destroy your system. No FUD necesarry. We discovered severe disk corruption during testing, and they are present in all vanilla 2.4.x kernels, the previous ac kernels and the kernel SuSE shipped (we tested just for fun). However, SuSE knew their 2.4 kernel was experimental and use 2.2 as default. I'm guessing that because of this, they didn't test it very much.

  • by teg ( 97890 ) on Monday April 16, 2001 @06:42AM (#288929)

    There's no point running the overhead of Apache for serving static files and that's about all that Tux is good for.

    Tux handles dynamic content just fine - in fact, it's a large part of the specweb benchmarks.

  • by teg ( 97890 ) on Monday April 16, 2001 @07:53AM (#288930)

    Which brings me to another question: wtf haven't you people jumped into wine?

    It's included in Red Hat Powertools 7.1

    That said, I will be happy if gcc-2.95.x is in there.

    Of course not:

    • What we ship is better, and has fixes, C++ compliance and performance well above 2.95.x
    • We need to stay compatible with our own RHL 7, and thus couldn't have downgraded

    The next compiler change will occur at Red Hat Linux 8, and we expect it to include gcc 3. Regressing isn't a good thing

  • by bero-rh ( 98815 ) <bero AT redhat DOT com> on Monday April 16, 2001 @06:46AM (#288972) Homepage
    Kernel: It's 2.4.2 with a lot of patches (mostly bugfixes, including one for a filesystem corruption bug).

    RPM: It uses the same v4 package format 7.0 used. The packages won't work on ancient versions of rpm (3.0.x, x 5), which doesn't matter because at least AFAIK there's no distribution out there that uses rpm 3.0.x and glibc 2.2.x (which is needed anyway).
  • by bero-rh ( 98815 ) <bero AT redhat DOT com> on Monday April 16, 2001 @06:54AM (#288973) Homepage
    Red Hat does not ship proprietary software (with the sole exception of Netscape which was still needed until not too long ago; the last piece of proprietary **** will disappear in one of the next releases, when Konqueror and Mozilla can replace it completely), so we won't ever include PM unless they decide to opensource it, which is unlikely.
    We think helping GNU parted to get ready is a much nicer way to address this problem.
  • by bero-rh ( 98815 ) <bero AT redhat DOT com> on Monday April 16, 2001 @07:22AM (#288974) Homepage
    The FS corruption problems have been fixed. Tracking them down was rather difficult, that's why the release is this late after the beta.
    We don't ship releases with known corruption problems.
  • Obviously, you should wait until the Linux kernel is completely finished before shipping one.

    Yes, quite right... We should probably buy out the CIA and have them shoot Linux, Alan and those other ****ing *****s who keep throwing new code at the Kernel rather than just letting our marketing guys say "It's finished".
    Please don't tell management, since I'm a developer, if they decide to take that approach, it might cost me my job or more. ;)

    omniscience will be a hiring requirement for all support staff

    Again, don't tell management. I don't want to be moved off to support. ;))

    seriously, working on Linux all day must be a lot of fun

    It sure is. That's why many of us keep rejecting better paid jobs and it's why I'm here, reading /. in a Konqueror session and hacking on 7.2 stuff in a konsole right next to it, at 9 pm on a public holiday while I'm on vacation. ;)
  • Since we're using kernel 2.4.2 (with many fixes), you won't need kgcc anymore unless you're planning on downgrading the kernel.

    The need for kgcc was caused by bugs in 2.2.x kernels, preventing it from compiling with compilers that do the right thing(tm).
  • We're keeping kgcc for people who want to run 2.2.x kernels for whatever reason.
    It's definitely not needed for 2.4.x kernels - our kernel has passed all stress tests without causing filesystem corruption, crashing, or otherwise acting up oddly.

    Also, gcc 2.96 has stabilized a lot between 7.0 and 7.1. (not that the 7.0 version was as bad as some people claim it was).
  • Our kernel is in no way proprietary. We're shipping the whole source and all of the patches.

    We're not using 2.4.3 because it was released way too late. Porting patches and testing take some time.

    Some of our fixes are in 2.4.3 (not all of them, simply because they were too late).
    And yes, all of our fixes have been submitted to what you call the real kernel.

    You can of course build your own kernel and it'll work - but we don't officially support anything that hasn't passed our QA.
  • If you are aware of anything that causes infinite loops or gcc chokes with 2.96-81, please report it [redhat.com], so we can fix it. We're not aware of any big problems in 2.96-81, and we can't fix problems we aren't aware of.

    C++ binary compatibility is a joke until gcc 3.0 is released. Handling C++ source isn't. gcc 2.96 does that well, 2.95.3 and earlier don't.

    And yes, all of 7.0 was compiled with 7.0 itself.
    If you can't get the SRPMs to recompile, it's a local installation issue (missing -devel packages? Modified glibc? Other kernel headers?).
    If you find any 7.0 SRPM that can't be compiled on a 7.0 Everything install, let me know and I'll personally fix it, but this shouldn't be the case.
  • Thanks for your comment - we always welcome constructive feedback.

    For your points:
    • journaling file system: We aren't waiting for ext3 specifically (though we still think it'll be the first stable jfs), we're waiting for any stable jfs. Unlike what you claim, our kernel people have found that ReiserFS isn't ready yet, it still caused heavy filesystem corruption under heavy load tests, and its userland recovery tools don't do much beyond a journal replay. Try to simulate a media defect (e.g. dd if=/dev/random of=/dev/hda offset=something count=3) and try to recover from that. With ext2/ext3, you'll lose some data, but a lot of stuff will remain intact. With ReiserFS, you can lose much more.
      Yes, it's getting better and I have no doubt it'll be ready for prime time some time soon, but it's not there yet.
    • desktop market I presonally agree pretty much, however, Openoffice is nowhere near ready (have you ever tried selling someone a full-fledged office suite that can't print?), and it'll take quite some work to convince everyone that Linux is ready to replace Windows on the desktop.
      I think that, at least if you use KDE and install Wine from powertools, you already get a very nice desktop OS, but unfortunately I don't make those decisions.
    • inetd: It's not that easy for practical purposes. Manipulating the inetd.conf file when you install packages that need to be launched from (x)inetd always has to be some crude hack. xinetd's feature of including all files in a specific directory is very useful there. We could provide an inetd package, but it would be pretty much unsupported because our official packages don't touch inetd.conf. I think it's not worth the trouble.
      Are you aware of the fact that you can just run inetdconvert to translate inetd.conf files to xinetd format?
    • rpm: I think the rpm + up2date combo has all the features you need. If you think there's something we need to add, please let me know.
    • inputrc: We've had a couple of people complaining about the change, but we've had many more people writing in to let us know we finally got it right. I think this has to be a local configuration thing.
    • korn shell: I must admit I've never used any shells but bash and zsh. What exactly are the things you're missing in bash? Is the korn shell under an open source license?
    • requiring several compilers: Yes, this was unfortunate... Related to a relatively tight schedule and the fact that we couldn't know too far in advance whether kernel 2.4 would be ready in time for the 7.0 release, so we basically had to prepare for both cases. (The need for kgcc was purely because of kernel 2.2.x bugs). I don't think this will happen again.
    • Kernel mixing:Yes, this was a relatively crude hack. Nevertheless, it was the best option we had: With kernel 2.4 not ready for the release, but expected to ship shortly after, we wanted to have a release that will work well if you just update to kernel 2.4 (which we almost achieved). Compiling everything with 2.2 headers in place means it won't be able to use 2.4 specific features even if you install kernel 2.4 -- something we wanted to avoid. And yes, we did (do?) really plan to give people a kernel version upgrade for the 7.0 release, we just expected 2.4 to be ready earlier. Our kernel people say the version we're shipping in 7.1 (meaning 2.4.2+our patches) is the first really usable version of kernel 2.4, because it's the first one that doesn't cause filesystem corruption under heavy load. I don't know if the plan to release a 2.4 update for 7.0 is still current, now that we know 7.1 and a stable 2.4 kernel are appearing at the same time.

    Besides, we aren't worrying about Mandrake or Suse - actually we're quite glad they're around. If they play fair [If anyone at Suse is reading this: Please start by putting yast under a reasonable license. Thanks.], everything they do is nice work for us, and we don't even need to pay them for it. ;)
  • Darn, we forgot.
    It'll probably take us years to catch up with the only os that has to be really stable since it already reached version 2000.0.

    I'm going to quit my job, we obviously can't get anywhere since we're that far behind. ;)
  • Sure you can make a few suggestions... However, I don't think we'll do anything for them:

    • xinetd: making the switch was the correct (and IMO overdue) choice, both for ease of use and for security (xinetd implements IP based access control), and for compatibility with the future (xinetd can do IPv6). Handling legacy inetd.conf files is a problem: If a service is described in both, which do you take? Also, inetd.conf has no way of providing information like permitted/rejected IPs.
      If we never dared to change anything because of compatibility issues, we'd still be punching holes in cards for programming.
      You can configure xinetd by hand (my favorite system configuration tool is and will always be vim) - its config files aren't more difficult to understand than inetd.conf. They're just more powerful.

      This is very different from changing / to C:\ -
      one was a big step forward, the other would make no sense at all and be a big step backwards.
    • wine: We're shipping it on Powertools.
      Putting a lot of resources into wine wouldn't make much sense. First of all, there's two sides to wine. Of course it's nice that I can run a Windoze application on Linux if I need to (I'm doing my tax declarations with wine, for example), but if it runs too well, companies won't see a need to write native Linux applications ("But our Windows version works for you, why should we do anything else?").
      Second, the desktop isn't our primary target, and there's no reason whatsoever to run wine on a server or embedded device.
    • gcc: This has been discussed to death many times. Go to http://www.bero.org/gcc296.html [bero.org] and let me know if this doesn't answer your questions.
    • What we do at "work": Coding, packaging and fixing bugs. Have you ever used the Linux kernel? glibc? gcc? KDE? GNOME? rpm? If you answered yes to any of those, you've used Red Hat code. (No, I'm not claiming we invented them or did all the work on them, but all of them contain a lot of code we wrote).
      Since everything we do is released under the GPL or LGPL, many people aren't aware of the fact that they're using a lot of our code even if they aren't using Red Hat Linux. (Yes, the same goes for most other distributions to an extent.)
  • by bero-rh ( 98815 ) <bero AT redhat DOT com> on Monday April 16, 2001 @10:39AM (#288984) Homepage
    Ok, here's the explanation:

    • wu-ftpd: Two of the wu-ftpd core developers (in the new wu-ftpd development group formed after the 2.6.0 release) are Red Hat employees. We've gone through the code a couple of times and we think it's safe now. There's no need to reinvent the wheel if you can fix up the existing one.
      Yes, there are other alternatives, like proftpd or the openbsd ftpd, but they are not necessarily better just because they're different. proftpd has had just as many root exploits, none of the other ftpds has all the features our users have come to expect. Similarily, we don't switch to a tool that has a totally different configuration file unless there are plenty of good reasons to do that (such as inetd->xinetd). AFAIK no alternative ftpd provides an equivalent of kwuftpd, allowing even beginners to configure most of the features.
    • bind: The maintainers have noticed this problem themselves - bind 9.0.0 was a complete rewrite without using any old code.
      We're shipping bind 9.1.0 with a lot of fixes from the 9.1.1 branch.
    • sendmail: While I personally would like to replace it with postfix, sendmail has matured, and some of the arguments for wu-ftpd apply here too - don't change to something radically different unless there are plenty of good reasons.
      We are shipping both postfix and exim in powertools for people who know what they're doing, though.
    • ResierFS: It's not possible to do a ReiserFS only installation at this time because our kernel people have found it to be too unstable. It still caused file system corruption under some circumstances, and we couldn't fix those problems in time. If it stabilizes a bit more, it will be possible in the next version (along with ext3).
  • by Cmdr. Marille ( 189584 ) on Monday April 16, 2001 @06:25AM (#289054)
    Well TUX is indeed one of the fastest webserver [spec.org], it's written by Ingo Molnar
    what makes it special? Well, It runs in kernel space, that's why it's so fast. It's also not meant to completely replace a full fletched web server like apache.

    check out this older slashdot article [slashdot.org]
  • by BlowCat ( 216402 ) on Monday April 16, 2001 @06:23AM (#289065)
    An empty 7.1 directory has been seen on mirrors for days, so I expected it to be released soon.

    In the meantime I tried their latest beta, Wolverine. To my great surprise, is supports kernels with devfs, although not without glitches.

    Another nice thing - it installs in text mode on top of VESA framebuffer. I think it's 100x37 characters or so - more space on screen to select packages and partition the hard drives.

  • by Mohammed Faizal ( 325021 ) on Monday April 16, 2001 @06:23AM (#289112)
    I work in Syria, for the army. I install much linux distributions for the army here, as they do not trust american windows security.

    Linux is a great OS for army uses. Used throughout the world in the name of Allah.

    Microsoft Windows is used by CIA to spy on foreign governments. But, windows better than linux for average man. Here in Syria, windows is totally free, buy it on streets for cheap price. Linux is more expensive than windows, because it is hard to get.

    Linux is also against Allah. Allah likes his children to only use the works of circumcised men who follow the will of allah. Linux develepors do not follow the will of Allah, even worse than Microsoft developers. But, there is no pure muslim OS.

    So we in syria have started new unix variant. Anyone can work on it, and all source code is free, as long as they are muslim. It will be used in coming jihads against western liberal capitalism.

    So please, remember that we Syrians like Red Hat, but Microsoft is cheaper. Please, Americans, make Red Hat cheaper for us in East.

    I am hoping to be involved in jihad against america soon. My brother works in a grocery store in philadelphia. He say I get green card. I look forward to money and living somewhere where Red Hat is cheap.

    ALLAH AKBAR!

For God's sake, stop researching for a while and begin to think!

Working...