Slashdot Mirror

- Open source doesn't need project management.

- All bugs are shallow given enough eyeballs.

The first of these was recently disproven, by simply pointing out that all successful open source projects use a strong management model.

The second is disproven by the lingering effects of thousands of bugs in every large open source project, such as Linux and Mozilla. The bug curves merely increase. Mozilla no longer supports their bug chart feature in bugzilla because the almost monotonically increasing curve was too embarassing. Debian and RedHat Linux distributions constantly grow in number of bugs.

And no, the bugs in the new distro are not all or mostly new; as this bug states:

the number of bugs for 7.0 that are new/open are 149. The rest of the other 2.500 bugs are spread out over previous releases and beta test releases.
Henri J. Schlereth
RedHat Beta Test Team.

That is, nine out of ten of these bugs have already been out in front of the alleged pool of bug-fixing eyeballs for a significant time.

Bug fixing is hard and unrewarding work. Anyone who has led or managed engineers knows that it is often difficult to get them to clean up after themelves. In the open source world, nearly the only bugs that get fixed by people who are not paid to work on the project are the few high-profile status bugs -- the rest simply lie fallow, many for all time.

Also interesting to note that 33 of those are installer problems. And here's a link to the actual bugzilla query page, if you, like slashdot, couldn't find it:

Okay, let's compare apples to apples. First you can READ the article about the W2k bug, then you can READ the bugzilla list, and get back to me on which of those bugs count as "core operating system" bugs. Of course, you may not know what an "active directory" is, or if it's part of the "core operating system", as you say, but I'd be interested to know what you think.

Granted, /. borked their facts on this one, and most of the bugs don't sound all that bad as far as I'm concerned, but really, what's your point?

Pretty damned cocky!

...is this one.

Thanks you slashcode for borking the previous link and cutting off 40 bugs.
-------------

the URL's should be linux newbie and RH bugzilla

www.bugzilla.redhat.com

This still is not the right link -- I made the same mistake three minutes after you did :P

The correct link is:

• http://bugzilla.redhat.com/bugzilla/

www.bugzilla.redhat.com

This still is not the right link -- I made the same mistake three minutes after you did :P

The correct link is:

• http://bugzilla.redhat.com/bugzilla/

Try 250 and climbing.

Seriously guys, at least check your numbers .before you post something that include a statistic
-------------

http://www.linuxnewbie.org

and

http://www.bugzilla.redhat.com

are probably what you're looking for.

--

He who is without sin ... :P

The correct link for Redhat's bugzilla is this:

• bugzilla

I guess that is what I get when I assume that the only thing wrong with the links was the syntax.

The CORRECT links are:

www.linuxnewbie.org

www.bugzilla.redhat.com

Buggy url's in a story about a buggy release. Go figure. :-)

Corrected URL's:
Bugzilla
and
Linux Newbie.

A more specific link for Bugzilla.


Whee.

Buggy url's in a story about a buggy release. Go figure. :-)

Corrected URL's:
Bugzilla
and
Linux Newbie.

A more specific link for Bugzilla.


Whee.

Someone forgot to insert the leading http:// protocol identifiers for the links in the story, and MSIE 5.5 (here) is generating goofy URLs by inserting http://slashdot.org/ in front of them there links!

Proper URLs:

• bugzilla
• www.linuxnewbie.org

www.linuxnebie.org and www.bugzilla.redhat.com

Check out http://linuxnewbie.internet.com/ if you are interested in the site. It is just something like Slashdot, so I would not bother. Basically, you should read http://bugzilla.redhat .co m/bugzilla/show_bug.cgi?id=18033

EFF's blue ribbon T-Shirt

Join EFC (Canada) and get a T-Shirt

RedHat Wear

GUI IDE's are great, but we already have Glade. What we need is GUILE-GTK+ bindings and Glade-GUILE.

And yes, I started programming with BASIC, and I have used Visual Basic extensively, and boy, is it a pain. I wish my first language had been Pascal, or Java, or Python (although the latter two didn't exist).

Read the FAQ. Their opinions are stated in plain view:

Q: Why doesn't QNX provide source to the kernel and other core OS modules?
A: Because QNX developers don't need kernel source to extend the OS.

Anyone who's ever done serious work in embedded systems know the kernel source is absolutely essential for debugging, not only the application but also the kernel. All OSes contain kernel bugs. They're a pain to find and fix without source, and those of us who've been there are not going back lightheartedly. You all know this, that's why we're embracing open source. How come so many of you are now eager to jump back into the dark hole that is proprietary software?

For embedded work, there's ECOS already. It's Free Software and runs on a dozen different CPUs, with new ports coming all the time. If you want the 3D acceleration, anti-aliases graphics and macromedia player, you're probably not looking for embedded stuff in the first place.

Sure, QNX is fun. Play away. But it isn't the future.

On my PIII 650 laptop the dvd playback keeps getting prempted by the kernel

So, is anyone brave enough to try and upgrade from 6.2 to 7.0? I know it's possible under Debian, but is it a wise thing to try with RedHat?

Of course - Red Hat has been upgradeable since 2.0/2.1. This has been tested extensively, including migration of some files (like inetd.conf) - if you have problems, feed bugzilla

The beta was there to fix bugs, not to be perfect.
The KDE issues are most definitely fixed.
I didn't try gnome on an update installation, but if you reported it, I'm quite sure it was fixed.

If you read the RedHat press release it states that it will not be available for download until Tuesday. The Press Release. Good luck with the link, RedHat site is crawling . . .

Red Hat Linux 7.0 is far more uptodate than Slackware 7, Mandrake 7.1 etc - our version number is there to say what is and what isn't binary compatible. Some of the others just play the number game (Mandrake, Slackware), SuSE seems to have their own versioning instead of just upping their number(I'm not sure what it is yet...) and Debian also has their own versioning.

• new 2.2ish glibc
• new gcc compiler, with performance enhancements
• openssl, openssh
• Integrated with the Red Hat Network. The base service is free.
• optimized for PentiumPro or higher, while maintaining backwards compatibility
• XFree 4, with accelerated 3D support for some cards. Many XFree 3.x servers used for stability reasons, but they also work with GLX.
• RPM 4
• USB support for mice and keyboard (the rest is included as is)
• Gnome 1.2 (seems to have less bugs than helix)
• preview of KDE 2 and 2.4 kernel
• FHS layout
• QT 2.2

And probably more features I'm just taking for granted now...

For some reason X itself took up 71M of memory.

Which graphics chipset? Which CPU? Did you report it?
We can't fix problems we aren't aware of, and this stuff definitely didn't happen on any of our test machines.

Too bad it will still use KDE 1.

7.1 won't - at the time we had to go gold, KDE 2 simply wasn't ready.
We're including a KDE 2.0 beta on the 2nd CD for people who want to play, though.

Is Redhat even *attempting* to create a nice KDE setup?

Sure. That's part of my job, actually.

If you reported it, it's fixed.

If it isn't, please take the time to report it.

7.0 was quite a difficult release to finish since a lot of the basic stuff (compilers, glibc) was still under heavy development.
That's where a number of problems in the beta (not the final, no known bugs yet) are coming from.

Please do report these bugs at Bugzilla - we can't fix problems we aren't aware of, and we won't notice hardware specific problems unless one of us happens to have the same hardware.

MKS makes the MKS Toolkit, which comes with teh Korn shell and the normal UNIX toolkit.

I personally use the Cygwin toolkit from http://sources.redhat.com/cygwin/. It has bash, ash, and the entire GNU toolchain, plus some other stuff. Works great. Even works on UNC paths, which MS own shell won't. With UNC support, I get GNU bash working on my Samba shares on Linux and FreeBSD, sweeeeet.

but there are a lot more available options for support (well-documented, as well as "speaking to a human" options) for Microsoft products than Open Source stuff.

Here are three Linux companies that can do that:

• Mission Critical Linux
  
• Red Hat Software
  
• TurboLinux
  
• Debian (non-profit)
  
• 
  

  
  Plus, you can hire whomever you want (including that really great programmer you know) to fix Linux for you.
  
  

The article seemed a bit hysterical in tone, given the actual content of the report. Goal 3 isn't "agreeing upon a single common licensing agreement", but rather includes "the use of common licenses should be encouraged". There's a huge difference.

I think we can all agree that using common licenses is generally good. Specifically, it's good when our license is compatible with someone else's license, since then we can share/merge code etc. The government encouraging this behaviour isn't to be feared. Horrors! The fed wants us to be good neighbors! Oh wait, that's the point of OSS, isn't it...

Also, the committee may not have RMS as a member, but it does have ESR, one of the other big TLAs. Why didn't ESR share this upcoming review with the OSS community? Who knows. Perhaps we should ask him. As to why the report didn't mention him, well, perhaps because it's not about the history of OSS? Sure, RMS will continue to have influence, but he's definitely not important in the scheme of a fedgov strategy. They're talking about ideas, not specifics. People are specifics.

The committee included people from many different places, such as Michael Tiemann from Redhat, Tim O'Reilly from, well, O'Reilly... people from NCSA, Microsoft, Collab.net, NASA, DOE, the EU (international concerns, international committee, if only somewhat), LANL, SGI, NSA, Intel, IBM, MITRE, NSF, and many other great acronyms.

So the committee surely isn't omitting any great group, except perhaps "the common man", if such exists in OSS. And many of the names are recognizable even to me, and I've only been interested in OSS for a couple years, and hardly involved. "All the usual suspects", as the article says. No fears here.

All in all, the report looks like a Good Thing for the OSS community, on the whole.
---

They appear to be updated today, but they're still marked as 1.93.

And for the http people: http://people.redhat.com/bero/experimental/

Below is a link to a redhat employee's ftp space. He makes unofficial rpms of the latest kde betas. Currently there's 1.93. Hopefully he should have 1.94 up soon (1-2 weeks, from the 1.93 dates).

ftp://people.redhat.com/bero/RPMS/

In fact NetBSD or OpenBSD would be a better choice for an IPC - Linux still has problems with the sun4c-MMU. See the Ultralinux or NetBSD FAQ or Redhat's Ha rdware compatibility list.

Computers are getting easier, but, they aren't losing features. For example, Windows 3.1 is obviously an upgrade from DOS, in that it has a visual interface and it needed DOS to run, so people could use DOS if they want to. Windows 95/98 aren't much different from 3.1, they just have better compression and a few other petty features. If you want a hard, but good operating system, be like me and download Linux from www.redhat.com

It's preferable if these are open source, but they don't have to be to suit your purpose; for example Metrowerks PowerPlant is the most popular application framework for the MacOS, and although it is a commercial product it is inexpensively available and when you do buy the Codewarrior development system you get the PowerPlant source code on the installation disk.

You can even develop an open source framework yourself and publish it openly, and invite in contributors publicly, and distribute non-subversive demo and test programs. Alternatively, you can add functionality to frameworks that almost suit the purpose and submit your patches back to the original maintainers.

This will save you work, although you may have to write "adapters" to be able to use someone else's library for your own purposes, it will increase reliability of your product, because the framework will have already been debugged by someone else and also tested under a wider variety of circumstances than it will encounter in your code, and you can concentrate your work on the particularly subversive parts.

Then you post only the "interesting" parts of your source code, and provide hyperlinks to the needed application frameworks in your build instructions. Be sure to include the version numbers needed for this build of your program, and if the sources to any of the frameworks are signed with a public key, include the key which those sources were signed with when you got them. That way you can be sure future programmers can rebuild the same program as you did.

It may well be that you have a large application but only a few source files and some build instructions to upload, which could be done off a floppy disk at a public access terminal. If you upload these to a few free webhosting service pages, then email the URL to a bunch of warez site maintainers, your code will be looked after.

Note: to find lots of warez sites (and even more serialz sites) go to Altavista, click on "Advanced Search" and enter:

download and warez and photoshop and illustrator and crack

Note that if you want to build a Windows application you can build it with Cygwin (a GNU shell environment for Windows including gcc) so you can be sure Microsoft doesn't embed Globally Unique Identifiers in your code. I'd also suggest that when you make a windows build, you buy a brand-new copy of windows 98 (pay cash), install it on a freshy formatted hard drive, build your binary, upload it, low-level format the hard disk you built it on and throw away the Windows 98 installation disk and all the materials that came with it. It's probably hard to get away with installing a development system on a public access terminal.

If you don't want to use a public access terminal (after all, you might be recorded on a surveillance camera, or the coffee shop waiters might remember you skulking around), then use Zero Knowledge Systems' Freedom to anonymize your web access.

Note that the way Freedom works is your HTTP packets are multiply encrypted with the public keys of the Freedom Network's servers, then "unwrapped" one by one as they pass through up to three servers until they are passed unencrypted to the public net at a faraway place.

Freedom provides both anonymous web browsing and anonymous email send and receive.

Some sources for open source libraries:

• Available C++ Libraries FAQ
• The Apache XML Project
• The Free Software Foundation software page
• Walnut Creek CDROM Free Software Archive
• SourceForge
• Freshmeat
• Gnome

On the other hand, when you write new code, it is definitely worth while to snip out little bits and make sure that they will compile and run on their own, or depend only on other readily available libraries. That way you can create a library yourself.

The book More C++ Gems has some articles on Large-Scale Software Architecture that discusses reducing cyclic dependencies in software projects, in part so that the projects can be rebuilt faster but also so that they can be unit tested in smaller parts and the parts can be extracted out and reused in other programs - although the claim is often made that object-oriented software is more reusable, this claim is baseless unless good engineering practices are observed.

Cheers

This is a RTOS that could use a lot of help for its i386 port. That port is currently still in beta. The other ports for AEB, ARM, MIPS, etc.... are much more stable and usable. Plus, RedHat is introducing the EL/IX layer for Linux application compatibility.

Definitely check it out if you're interested in something that is free and opensource.

eCos RTOS Project Page

Red Hat eCos Product Page

This is a RTOS that could use a lot of help for its i386 port. That port is currently still in beta. The other ports for AEB, ARM, MIPS, etc.... are much more stable and usable. Plus, RedHat is introducing the EL/IX layer for Linux application compatibility.

Definitely check it out if you're interested in something that is free and opensource.

eCos RTOS Project Page

Red Hat eCos Product Page

Yes. Taint is great, if not a complete pain to work under *grin*. But how many run-of-the-mill "Learn Perl-CGI by Putting This Book Under Your Pillow" books cover security and detainting form input with reg exps before going any farther than "Hello World"? For that matter, how many Linux for Dimwits books take the time to explain right away that you may want to turn off a bunch of services and set up some firewall rules if you don't intend to offer your test apache install to the world at large? This particular exploit isn't listed at CERT yet and the article doesn't say anything about specific examples. However, Red Hat has this and updated RPMs and source for glibc.

Blah, blah monolithic. You still have the option to not use linuxconf(1), just like I didn't when I used to use RedHat. And we have a basic misunderstanding about the term monolithic here: providing a (arguably) nice visual interface to a lot of utilities and /proc fiddling is not the same as being monolithic in my book. Would you consider smit(1) under AIX to be monolithic? Or are you using monolithic as short for "stuff I don't like"?

There are tools (those above?) which seem to keep shadow copies of some config files.

I can't recall any from my RH days, and I feel obliged to remind you that there isn't any tool you are forced to use. right?

What bothers me about it is that there are very few computer newbies around. Most linux newbies come from Windows, and the RH model (followed by quite a few others too) seems to be "make linux look like Windows". I don't see any efforts to teach the unix ways (examples: stdin/stdout, X server vs. X client, text! text! text! config files...). Creating Windows all over again going the wrong way.

You really need to go out more if you think there aren't a lot of computer newbies around. Linux newbies may come from the Windows, Macintosh or Big Blue sky world. There is no need for them ro become deft sysadmins to use their Linux box, unless they plan to follow that unfortunate career path (oops, gratuitous flamebait >:-). Although, I'm not sure what you mean by "Unix ways" (which UN*X? SysV flavored or BSD flavored?), you can find the kind of documentation you request here, there and everywhere. I don't know how they could go about "teaching" it, but then again, I never took of the courses they offer...

And, frankly, all this talk of "making it look like Windows" is quite boring and inaccurate. The only default installation that tried to mimic the Windows look was that fvwm95 thing by RH, but they have moved out from it a long time ago. Even then, you still had the option to customize it, right?
--

Blah, blah monolithic. You still have the option to not use linuxconf(1), just like I didn't when I used to use RedHat. And we have a basic misunderstanding about the term monolithic here: providing a (arguably) nice visual interface to a lot of utilities and /proc fiddling is not the same as being monolithic in my book. Would you consider smit(1) under AIX to be monolithic? Or are you using monolithic as short for "stuff I don't like"?

There are tools (those above?) which seem to keep shadow copies of some config files.

I can't recall any from my RH days, and I feel obliged to remind you that there isn't any tool you are forced to use. right?

What bothers me about it is that there are very few computer newbies around. Most linux newbies come from Windows, and the RH model (followed by quite a few others too) seems to be "make linux look like Windows". I don't see any efforts to teach the unix ways (examples: stdin/stdout, X server vs. X client, text! text! text! config files...). Creating Windows all over again going the wrong way.

You really need to go out more if you think there aren't a lot of computer newbies around. Linux newbies may come from the Windows, Macintosh or Big Blue sky world. There is no need for them ro become deft sysadmins to use their Linux box, unless they plan to follow that unfortunate career path (oops, gratuitous flamebait >:-). Although, I'm not sure what you mean by "Unix ways" (which UN*X? SysV flavored or BSD flavored?), you can find the kind of documentation you request here, there and everywhere. I don't know how they could go about "teaching" it, but then again, I never took of the courses they offer...

And, frankly, all this talk of "making it look like Windows" is quite boring and inaccurate. The only default installation that tried to mimic the Windows look was that fvwm95 thing by RH, but they have moved out from it a long time ago. Even then, you still had the option to customize it, right?
--

Blah, blah monolithic. You still have the option to not use linuxconf(1), just like I didn't when I used to use RedHat. And we have a basic misunderstanding about the term monolithic here: providing a (arguably) nice visual interface to a lot of utilities and /proc fiddling is not the same as being monolithic in my book. Would you consider smit(1) under AIX to be monolithic? Or are you using monolithic as short for "stuff I don't like"?

There are tools (those above?) which seem to keep shadow copies of some config files.

I can't recall any from my RH days, and I feel obliged to remind you that there isn't any tool you are forced to use. right?

What bothers me about it is that there are very few computer newbies around. Most linux newbies come from Windows, and the RH model (followed by quite a few others too) seems to be "make linux look like Windows". I don't see any efforts to teach the unix ways (examples: stdin/stdout, X server vs. X client, text! text! text! config files...). Creating Windows all over again going the wrong way.

You really need to go out more if you think there aren't a lot of computer newbies around. Linux newbies may come from the Windows, Macintosh or Big Blue sky world. There is no need for them ro become deft sysadmins to use their Linux box, unless they plan to follow that unfortunate career path (oops, gratuitous flamebait >:-). Although, I'm not sure what you mean by "Unix ways" (which UN*X? SysV flavored or BSD flavored?), you can find the kind of documentation you request here, there and everywhere. I don't know how they could go about "teaching" it, but then again, I never took of the courses they offer...

And, frankly, all this talk of "making it look like Windows" is quite boring and inaccurate. The only default installation that tried to mimic the Windows look was that fvwm95 thing by RH, but they have moved out from it a long time ago. Even then, you still had the option to customize it, right?
--

Is this Cygnus tree what Cywin32 is based on?

I was recently digusted when I discovered it was no longer available.

--Karl

anyone who has used a handle (Do slashdot IDs count?) must be a gray hat hacker.

That is, unless you're bero-rh. In that case, you're a red hat hacker.

I'll agree that we don't need to add more buzzword-technology to our environment for the sake of having our press releases be full of buzzwords. However, your statement about CORBA being bloated and slow is misinformed. ORBit is an extraordinarily lightweight, speedy implementation. Bud Tribble addressed this in his recent interview at lwn.net.

For more information about ORBit, you can also visit the ORBit page at RHAD.

In addition, check out the CORBA for Beginners page at OMG.
----

I'll agree that we don't need to add more buzzword-technology to our environment for the sake of having our press releases be full of buzzwords. However, your statement about CORBA being bloated and slow is misinformed. ORBit is an extraordinarily lightweight, speedy implementation. Bud Tribble addressed this in his recent interview at lwn.net.

For more information about ORBit, you can also visit the ORBit page at RHAD.

In addition, check out the CORBA for Beginners page at OMG.
----

First and foremost every linux distribution caters, or atleast claims to cater to a specific subsection of the linux population. If you want the most recognized linux distribution, with the one of the bigest installed bases out there you run RedHat. If you want a distribution that is as tight as a drum you apply Bastille Linux. If you want productivity suties cleanly integrated into your install process you run Corel Linux (which BTW is based on Debian.) If you feel like supporting User Friendly you run Suse. If you want a distribution that you know all the parts work well together in you run Debian.

The author of this article seems to lack an understanding of the Debian release cycle. Debian was frozen before several of the release he mentions came out. Once Debian has been frozen getting a new package into it becomes substanially more difficult. Now before everyone screams about how now that potato (Debian 2.2) is stable these fixes can't make it in, keep in mind that security fixes are one of the items on the very short list of packages that can be changed once a release goes stable.

Joe Homeuser most likely isn't going to choose Debian as his distribution. Most people who choose Debian do so because the support Open Source ideals to the extreme and as such have problem been around the Open Source block a time or two and atleast have some idea what they are doing.

Are these valid secutiry holes in potato? Yes! Should someone have written an article bringing them to light? Yes! Is this a big enough deal to warrant a Slashdot Story? No! It should be a quickie at best.

A better comparison is QNX to Cygnus eCos, the Linux-preemptive RT/Linux kernel/system, WindRiver's VxWorks, etc... It is really unfair (for both sides) to compare a "lightweight" OS for small, embedded systems against a be-all/do-all behemoth like Linux (which does have a minimum size limitation).

I'm sure you'll be able to find some overlap, but it's really a question of "which is better for this application" and not "which is better period".

-- Bryan "TheBS" Smith