When he announced the feature freeze, Linus made clear that it only affects code that already is there - adding entirely new stuff (like new filesystems, or drivers for new hardware) aren't that frozen. devfs is the only thing that did change existing code a lot - but the patch has been around (and stable) forever.
I tend to disagree on both points. 1. is related to a C vs C++ issue, yes. One of the main problems I have with gtk (and I've programmed in both) is that it pretty much tries to do C++ stuff in C, and has to use some relatively ugly kludges to get it done. Yes, I know gtk-- exists, and I have tried it, and it gets nowhere near Qt/kdelibs as far as usability for the programmer is concerned (at least IMO), partially because it has to use what gtk does.
As for 2., I know there's some redundancy and you don't get the same look and feel unless you configure it twice, but unless you're on a really slow machine, it's not that big an issue. Interoperability between KDE and GNOME is going to improve, not to get worse (with KDE 2.0, you can use drag and drop from a KDE application to a GNOME application and vice versa). KDE will use DCOP for a number of things GNOME will do with CORBA - given enough time, the other problem you mention will be solved with a DCOPCORBA bridge.
Both have their good sides. IMO it isn't important which you run - there's no problem with running GNOME applications inside KDE and vice versa, so you can just pick the best of both worlds. With Qt 2.*, the licensing is no longer much of an issue (and even with Qt 1, you could have a look at its source, just not re-use it or add your own modifications). My personal preference is KDE simply because GTK's API is (IMO) painful for programmers (I'm sure many of the GNOME developers will disagree with me here though) because of its attempt to simulate an OO-style API in a language that simply wasn't designed for this sort of stuff - causing, among other things, oddities like stupid bugs (such as an attempt to add a listbox item to a pushbutton) to compile without problems.
Removing the esound requirement is definitely a good thing - removes the requirement to install esound (and everything it depends on, such as libaudiofile) on computers that don't have soundcards.
Window managers are still the user's choice. Anyone who prefers enlightenment can use it.
Nobody is demanding they give up their source code. They just have to give it to others as well.
To stay with your analogy, you're so proud of what you've done with the girl that you lock her up in her rooms so she can't talk with anyone else because you fear losing a part of her or something.
Then the real father of this child comes in, says "thanks for raising the kid, but I have the right to meet her - you can keep her, but stop locking her up" and points you to the constitutional right of assembly (the GPL) showing he can enforce it.
The I810 needs some kernel patches to work properly. <p>You might want to try getting the kernel and XFree86 packages from the current Red Hat Linux 6.2 beta (<a href="ftp://ftp.redhat.com/pub/redhat-6.2beta/i386 ">ftp://ftp.redhat.com/pub/redhat-6.2bet a/i386/</a>) - we're now supporting the i810 chipset.
Just in case this was not meant as a joke: enlightenment, blackbox and all the other existing GUIs run on top of XFree86. They're by no means replacing it.
If you'd like to replace XFree86, maybe go for framebuffer devices, svgalib or GGI.
Rest assured Microsoft has no control whatsoever over Red Hat.
Yes, we are watching Microsoft (and *BSD and BeOS and other Linux distributions and and and), but that doesn't mean we're copying them. All Redhat is doing is waiting for Microsoft to make every move and then they mirror the same move
Please tell me, for example, when Microsoft started shipping source, when invented a packaging system that allows for real uninstallation, when Microsoft started to include a clustering system in Windows, or when Red Hat started providing the bluescreen module or putting lots of stuff that belong to userspace into the kernel. Red hat doesn't want to create anything new.
It is true that right now, we aren't starting many new projects all by ourselves - but we're contributing to projects that do something new. Check the CVS commit logs of most interesting open source projects and you'll see commits from Red Hat employees (creating something new). Why would we want to, for example, create our own new desktop environment? Don't you agree that contributing to the ones we have (such as KDE and GNOME, both of which we're working on) is obviously a better solution?
Is Redhat waiting on this so they can include the "four point oh" in the features list on the box?
No. Have a look at the current beta - some packages will change (some have changed already), but there won't be any major changes such as moving to XFree86 4.0, Kernel 2.4, glibc 2.2, KDE 2.0, GNOME 1.2 or whatever else is ahead.
XFree86 will definitely bring a lot of good things, but also some breakage because of library and header changes. Anyone shipping 4.0 as soon as it's released (without fixing up some applications or waiting for them to be fixed) is setting himself up for some trouble.
Never heard of Final Draft. What is it? ScriptWriter is a free (speech and beer) word processor for writing scripts, based on AbiWord. You can download and check if it does what you need at ftp://ftp.freefilm.cx/pub/ffp. It is currently available as source (should compile on pretty much anything) and as RPM for Red Hat Linux 6.2.
Maybe if their Linux distro didn't suck so hard I woudln't mind
So, why do you think we suck? Saying something sucks without giving reasons is easy, but doesn't help making anything better. (just like pointing out something doesn't suck - would it get us anywhere if I just replied with "Red Hat Linux doesn't suck"?)
If you have any constructive criticism, please let me know. If you think this is getting offtopic (it probably is), feel free to send it to me personally at bero@redhat.com.
I think customers of Red Hat should let them know that they prefer that Red Hat support an open source streaming audio/media project, rather than bundling Real Networks software. <p> We're always in favor of something open sourced. Please point me to an open-sourced solution for the same problem that: <ul> <li>is as widely in use/accepted by content providers</li> <li>Has at least a client available for many platforms (as much as I dislike it, at this time, not many webmasters will switch to a streaming server that doesn't have a client on the evil empire's side)</li> <li>Works reliably</li> </ul> (or at least will get there soon) and I'll make sure it gets included as well. <p>Until we have something like it, I'd say having a proprietary solution on a free OS is preferable over having a proprietary solution requiring a proprietary OS, and no solution whatsoever on free OSes...
Actually there's quite a difference between KLyX and an applet for eye-candy Window Mangers. One of the problems with plain lyx is that it uses XForms, which is a proprietary library. KLyX replaces the XForms calls with KDE/Qt calls. It will still run with any window manager if you have Qt and kdelibs. Replacing proprietary stuff with opensource stuff is always a good idea if it doesn't break anything.
The last I heard, there are absolutely no plans to ever update [klyx]. <p> Not entirely true. If you take a look at the KDE 2.0 CVS tree, you'll see it has at least been ported to the KDE 2.0 libraries. There are even plans to make it KParts-compatible, so you can embed klyx documents in other KOffice components. <p> I agree it is currently lagging behind plain lyx feature-wise - but that may change soon.
I've actually thought about this too - but I personally think KWord has so many features we won't need to write scripts (all the framing stuff, for example, which is the whole concept of KWord) that I'd rather stick with the current version [which has everything we need and very little else].
Btw: For those who don't know what we're talking about, ScriptWriter is a modified version of AbiWord to handle scripts instead of texts. It can be downloaded at http://www.freefilm.cx/ScriptWriter.
C++ is the shittiest language ever Really? If you had said "C++ isn't good for system programming", I might agree, but what's wrong with C++ for GUI programming? Have a look at, for example, the KDE source - it's C++, it's readable, it works and it's reasonably fast. If you look at other UIs written in plain C, say GTK/GNOME, you'll notice that many of them actually reinvent some C++ ways. (Yes, I know the difference, but GTK_WIDGET_NEW(a); really isn't much different from QWidget a();). Which language would you pick for creating a GUI? (And why?)
am I the only one that thinks using domain names as resource locators is wrong?
Not really. I'd tend to agree that a different system would be better (so Microsoft can't just take nameofanewbutimportantopensourceproject.org) - but right now, fact is that people look for name.com first - and almost all search engines give bonus points for the keyword appearing in the domain name. Since it isn't a really bad thing, it's maybe best to play with these rules until we can change them.;)
shouldn't we have some central place for people to register their sites?
KDE can't modify the file system - therefore we can't add MIME types as file attributes (at least not without ugly kludges like creating.mimetypes files in every directory, containing a directory listing and mime types). That would require major kernel and glibc changes, and of course break compatibility.
Old hardware, while not the most important thing, also needs to be supported - many people are running 486s or Pentium 60s as LAN fileservers or IP masquerading servers.
Windows binaries: that's already supported. An emulator (not perfect yet) is available at http://www.winehq.com/, and you can use BINFMT_MISC for the possibility to simply run them as if they were Linux binaries.
I agree that Linux needs to become usable for someone who doesn't have the slightest clue about command lines. But that's not a reason to get rid of them. For a lot of things, command lines are much much more efficient than even the best GUI could be, so why not give people who know how to handle it the option to do it? I don't think people would find it confusing if they had the "Command Line" button, even if they never used it. Same for User IDs and passwords - why get rid of them, if we can just do something like "su user -c exec startx" in rc.local?
What would I do without my weekly 100 hours of Linux hacking? Seriously, I don't know.;) I guess you should really leave people like myself (job==hobby) out of surveys like this.
Sure, not all of these are real problems. We're getting a number of bug reports indicating minor stuff (typos in man pages, user interface stuff we don't agree with, or reports of bugs that are actually user problems). Still 65000 is a huge number... As a comparison, Red Hat's bugzilla is currently at about 9700 bugs, about 95% of which are resolved, and some of the non-resolved bugs being non-reproducable; and Red Hat's bugzilla contains the whole system (and powertools). I don't think the 65000 bugs in Windows 2000 include bugs in, for example, Visual C++ (Red Hat's include gcc). Even if only 20% of the bugs are real, that's way more than any bug ever reported in Red Hat Linux.
I think it's pretty much the same situation if you look at the number of bugs in the bug tracking systems for other Linux distributions, or the various BSDs.
Slashdot Mirror
Try 2.3.48. It is tagged unstable, but it works reliably on x86 (it's still somewhat problematic on alpha though).
When he announced the feature freeze, Linus made clear that it only affects code that already is there - adding entirely new stuff (like new filesystems, or drivers for new hardware) aren't that frozen.
devfs is the only thing that did change existing code a lot - but the patch has been around (and stable) forever.
Because it's always been that way - unless you read /. or the likes, you probably don't know there are alternatives at all.
I tend to disagree on both points.
1. is related to a C vs C++ issue, yes. One of the main problems I have with gtk (and I've programmed in both) is that it pretty much tries to do C++ stuff in C, and has to use some relatively ugly kludges to get it done.
Yes, I know gtk-- exists, and I have tried it, and it gets nowhere near Qt/kdelibs as far as usability for the programmer is concerned (at least IMO), partially because it has to use what gtk does.
As for 2., I know there's some redundancy and you don't get the same look and feel unless you configure it twice, but unless you're on a really slow machine, it's not that big an issue.
Interoperability between KDE and GNOME is going to improve, not to get worse (with KDE 2.0, you can use drag and drop from a KDE application to a GNOME application and vice versa).
KDE will use DCOP for a number of things GNOME will do with CORBA - given enough time, the other problem you mention will be solved with a DCOPCORBA bridge.
Both have their good sides.
IMO it isn't important which you run - there's no
problem with running GNOME applications inside KDE
and vice versa, so you can just pick the best of
both worlds.
With Qt 2.*, the licensing is no longer much of an
issue (and even with Qt 1, you could have a look at its source, just not re-use it or add your own
modifications).
My personal preference is KDE simply because GTK's API is (IMO) painful for programmers (I'm sure many of the GNOME developers will disagree with me here though) because of its attempt to simulate an
OO-style API in a language that simply wasn't
designed for this sort of stuff - causing, among other things, oddities like stupid bugs (such as an attempt to add a listbox item to a pushbutton) to compile without problems.
Removing the esound requirement is definitely a good thing - removes the requirement to install esound (and everything it depends on, such as libaudiofile) on computers that don't have soundcards.
Window managers are still the user's choice. Anyone who prefers enlightenment can use it.
You're running Raw Hide or Red Hat Linux 6.2 beta 3, aren't you?
For betas, it's not uncommon (or bad) to ship pre-release code.
Nobody is demanding they give up their source code. They just have to give it to others as well.
To stay with your analogy, you're so proud of what you've done with the girl that you lock her up in her rooms so she can't talk with anyone else because you fear losing a part of her or something.
Then the real father of this child comes in, says "thanks for raising the kid, but I have the right to meet her - you can keep her, but stop locking her up" and points you to the constitutional right of assembly (the GPL) showing he can enforce it.
Do you suggest keeping her locked up?
The I810 needs some kernel patches to work properly.6 ">ftp://ftp.redhat.com/pub/redhat-6.2bet a/i386/</a>) - we're now supporting the i810 chipset.
<p>You might want to try getting the kernel and XFree86 packages from the current Red Hat Linux 6.2 beta (<a href="ftp://ftp.redhat.com/pub/redhat-6.2beta/i38
Just in case this was not meant as a joke: enlightenment, blackbox and all the other existing GUIs run on top of XFree86. They're by no means replacing it.
If you'd like to replace XFree86, maybe go for framebuffer devices, svgalib or GGI.
Rest assured Microsoft has no control whatsoever over Red Hat.
Yes, we are watching Microsoft (and *BSD and BeOS and other Linux distributions and and and), but that doesn't mean we're copying them. All Redhat is doing is waiting for Microsoft to make every move and then they mirror the same move
Please tell me, for example, when Microsoft started shipping source, when invented a packaging system that allows for real uninstallation, when Microsoft started to include a clustering system in Windows, or when Red Hat started providing the bluescreen module or putting lots of stuff that belong to userspace into the kernel.
Red hat doesn't want to create anything new.
It is true that right now, we aren't starting many new projects all by ourselves - but we're contributing to projects that do something new. Check the CVS commit logs of most interesting open source projects and you'll see commits from Red Hat employees (creating something new). Why would we want to, for example, create our own new desktop environment? Don't you agree that contributing to the ones we have (such as KDE and GNOME, both of which we're working on) is obviously a better solution?
No. Have a look at the current beta - some packages will change (some have changed already), but there won't be any major changes such as moving to XFree86 4.0, Kernel 2.4, glibc 2.2, KDE 2.0, GNOME 1.2 or whatever else is ahead.
XFree86 will definitely bring a lot of good things, but also some breakage because of library and header changes. Anyone shipping 4.0 as soon as it's released (without fixing up some applications or waiting for them to be fixed) is setting himself up for some trouble.
Never heard of Final Draft. What is it? ScriptWriter is a free (speech and beer) word processor for writing scripts, based on AbiWord. You can download and check if it does what you need at ftp://ftp.freefilm.cx/pub/ffp.
It is currently available as source (should compile on pretty much anything) and as RPM for Red Hat Linux 6.2.
Maybe if their Linux distro didn't suck so hard I woudln't mind
So, why do you think we suck?
Saying something sucks without giving reasons is easy, but doesn't help making anything better. (just like pointing out something doesn't suck - would it get us anywhere if I just replied with "Red Hat Linux doesn't suck"?)
If you have any constructive criticism, please let me know. If you think this is getting offtopic (it probably is), feel free to send it to me personally at bero@redhat.com.
I think customers of Red Hat should let them know that they prefer that Red Hat support an open source streaming audio/media project, rather than bundling Real Networks software.
<p>
We're always in favor of something open sourced.
Please point me to an open-sourced solution for the same problem that:
<ul>
<li>is as widely in use/accepted by content providers</li>
<li>Has at least a client available for many platforms (as much as I dislike it, at this time, not many webmasters will switch to a streaming server that doesn't have a client on the evil empire's side)</li>
<li>Works reliably</li>
</ul>
(or at least will get there soon) and I'll make sure it gets included as well.
<p>Until we have something like it, I'd say having a proprietary solution on a free OS is preferable over having a proprietary solution requiring a proprietary OS, and no solution whatsoever on free OSes...
Actually there's quite a difference between KLyX and an applet for eye-candy Window Mangers.
One of the problems with plain lyx is that it uses XForms, which is a proprietary library.
KLyX replaces the XForms calls with KDE/Qt calls. It will still run with any window manager if you have Qt and kdelibs.
Replacing proprietary stuff with opensource stuff is always a good idea if it doesn't break anything.
The last I heard, there are absolutely no plans to ever update [klyx].
<p>
Not entirely true. If you take a look at the KDE 2.0 CVS tree, you'll see it has at least been ported to the KDE 2.0 libraries. There are even plans to make it KParts-compatible, so you can embed klyx documents in other KOffice components.
<p>
I agree it is currently lagging behind plain lyx feature-wise - but that may change soon.
I've actually thought about this too - but I personally think KWord has so many features we won't need to write scripts (all the framing stuff, for example, which is the whole concept of KWord) that I'd rather stick with the current version [which has everything we need and very little else].
Btw: For those who don't know what we're talking about, ScriptWriter is a modified version of AbiWord to handle scripts instead of texts. It can be downloaded at http://www.freefilm.cx/ScriptWriter.
C++ is the shittiest language ever Really? If you had said "C++ isn't good for system programming", I might agree, but what's wrong with C++ for GUI programming? Have a look at, for example, the KDE source - it's C++, it's readable, it works and it's reasonably fast. If you look at other UIs written in plain C, say GTK/GNOME, you'll notice that many of them actually reinvent some C++ ways. (Yes, I know the difference, but GTK_WIDGET_NEW(a); really isn't much different from QWidget a();). Which language would you pick for creating a GUI? (And why?)
If you were to create C+++, how would it be different from C++?
Would you do anything different if you didn't have to care about backwards compatibility?
am I the only one that thinks using domain names as resource locators is wrong?
Not really. I'd tend to agree that a different system would be better (so Microsoft can't just take nameofanewbutimportantopensourceproject.org) - but right now, fact is that people look for name.com first - and almost all search engines give bonus points for the keyword appearing in the domain name. Since it isn't a really bad thing, it's maybe best to play with these rules until we can change them. ;)
shouldn't we have some central place for people to register their sites?
You mean http://www.freshmeat.net/?
KDE can't modify the file system - therefore we can't add MIME types as file attributes (at least not without ugly kludges like creating .mimetypes files in every directory, containing a directory listing and mime types).
That would require major kernel and glibc changes, and of course break compatibility.
Old hardware, while not the most important thing, also needs to be supported - many people are running 486s or Pentium 60s as LAN fileservers or IP masquerading servers.
Windows binaries: that's already supported. An emulator (not perfect yet) is available at http://www.winehq.com/, and you can use BINFMT_MISC for the possibility to simply run them as if they were Linux binaries.
I agree that Linux needs to become usable for someone who doesn't have the slightest clue about command lines.
But that's not a reason to get rid of them.
For a lot of things, command lines are much much more efficient than even the best GUI could be, so why not give people who know how to handle it the option to do it? I don't think people would find it confusing if they had the "Command Line" button, even if they never used it.
Same for User IDs and passwords - why get rid of them, if we can just do something like
"su user -c exec startx" in rc.local?
What would I do without my weekly 100 hours of Linux hacking? Seriously, I don't know. ;)
I guess you should really leave people like myself (job==hobby) out of surveys like this.
Sure, not all of these are real problems. We're getting a number of bug reports indicating minor stuff (typos in man pages, user interface stuff we don't agree with, or reports of bugs that are actually user problems).
Still 65000 is a huge number...
As a comparison, Red Hat's bugzilla is currently at about 9700 bugs, about 95% of which are resolved, and some of the non-resolved bugs being non-reproducable; and Red Hat's bugzilla contains the whole system (and powertools). I don't think the 65000 bugs in Windows 2000 include bugs in, for example, Visual C++ (Red Hat's include gcc).
Even if only 20% of the bugs are real, that's way more than any bug ever reported in Red Hat Linux.
I think it's pretty much the same situation if you look at the number of bugs in the bug tracking systems for other Linux distributions, or the various BSDs.