Do both of you just believe in the "my distribution does this type of package management, thus it must be right". Personally I chose the method of package management (encap - http://encap.cso.uiuc.edu) first, then chose and/or contructed the system to match.
I'm not sure off the top of my head if XFS supports ACLs. I would tend to think so. However, e2fs has supported ACLs for a long time. However, the linux kernel does not, nor are there stable ACL aware versions of acl utilities, or an acl-aware version of e2fs utils. I did come accross a group that was working on it. However, they were only at the alpha stages, and seemed to halt development after kernel 2.2.0pre9. Anyways, the issue of ACL is one of the kernel and user space programs, not the filesystem.
A lot of things are better than olwm or olvwm. Fvwm was better than either. CDE is low, it's ugly, it's a memory hog, it offers little additional functionality, ect, ect. I'd like KDE to become more available on Sparcs I use, but until my local sysadmins do, it'll be fvwm for me on those machines.
Re:I can't believe they pay people to write this
on
ABCNews GNOME Acticle
·
· Score: 1
People should read a little more carefully. It said no GUI like Windows or the MacOS. When I think of those GUIs I think not of the lower level GUI stuff that corresponds to the X server, but the highest level stuff. The point that KDE predates GNOME, and that a few others also exist is a valid point though.
Actually a roomate of mine has a multia. It was quite decently reliable running either Linux or OpenBSD. The biggest problem is that egcs's alpha optimizations tend to lag behind their x86 optimizations (especially with the pgcc group out there) due to them focusing first on the most used systems.
2.0 is a lot of work, and depends upon many things: getting KOM/OpenParts done, troll tech getting qt-2.0 out the door, getting koffice stabel, ect. 1.1 was a set of tweaks that brought kde from stability to maturity, and 1.1.1 was just a few bugfixes. With 1.1 they just took a bunch of stuff they were working on that didn't have the dependencies that 2.0 has, and got them out. This time they just fixed bugs.
Well that's something I didn't learn in my High School German class:)
Kate is OK, and you have a point with the one syllable thing. It looks more like a Katie IMHO, but that's me. Konqui just doesn't sound catchy enough to me, and its important for a mascot to have a catchy name.
Ravi Sethi is cool too. However Sethi was one of the authors of the Red Dragon book: _Compilers: Principles, Techniques and Tools_ but he was not an author of the original Dragon book _Principles of Compiler Design_. That was done by Aho and Ullman alone.
First of all I've yet to hear about an animated assistant for KOffice. It wouldn't horribly suprise me, it just sounds like its a bunch of unconfirmed rumours as of right now. Second, if such a thing did exist, I'm sure it would be rather easy to disable in KOffice. The KDE is like that, rather configurable. Third, the paperclip took very few cycles. If you ever used MS Office, you'd know that it wasn't annoying because it slowed down your machine, and certainly didn't require a PIII/500 (used to run it on a Cyrix P-150+ (note: that CPU sucked)). What was annoying about it was it hard to figure out how to disable it (wasn't in an obvious place, forget now how to do that), and it had the tendency to jump into the foreground when you were trying to get stuff done.
I disagree. When I think of Green Dragons I think of Aho and Ullman, Principles of Compiler Designs. I wonder if the dragon will become Red when KDE 2.0 comes out.:)
The real question is will it have a name, and if so what. Although there is precedence for having nameless mascots (the BSDaemon, and the Mozilla Lizard both are unnamed AFAIK), but I think the name Tux, has added something to the Penguin.
KDE's control center thingie can scale images for you. I used it, and it looked quite good at 1280x1024.
Now that doesn't offer the general solution, but I figure that most people who want to use the kde mascot as a backgroud are probably using KDE.
You couldn't be more wrong.
on
Red Hat 6.0
·
· Score: 1
The only reason libgtop came to mind was that some friends of time were using it for a little system monitoring app they were writing and planning to release under a BSD license. The license change screwed those plans.
You claim GNOME will never change the licensing of their core libraries. One of the major pro-GNOME, anti-KDE arguments is that you can't trust troll tech not to pull the rug out if KDE gets dominent. Yet the KDE people and TT have been making less and less restrictive licenses in order to combat this fear. On the flip side, the GNOME people are tightening their licenses. Why should I trust them to keep the license the same on their core libraries.
But that's the point. From the end user perspective they are all in/usr/local/bin because simlinks are made from/usr/local/* to/usr/local/encap/packagename/* to list all your files you simply look at the packagename dir in/usr/local/encap, aka ls/usr/local/encap/bash-2.02
Ass for it sounding like a MS-type scheme, quite the contrary. It started out in many ways from the/opt directory structure under SunOS, which was intellegent in that packages were seperated, but dumb in the need for an uber path variable. With 197 encapped packages now on my system, I don't want to even think about what kind of path varriable I would have without the simlinking inherrent in encap.
As I understand it, KDE 2.0 will seperate most of the window manager functionality into a library. Thus, wm writers can simply link their wm to libkwm, and get 100% of the KDE compliance without having to implement an imterface like Windowmaker and Blackbox have.
Personally, I'm not to fond of kwm either, but not because it looks like Windows, that's a myth. What bothers me is its not that configurable. Yet the other 2 wms that are kde compliant don't integrate quite as well. Hopefully the library design will change this.
You couldn't be more wrong.
on
Red Hat 6.0
·
· Score: 1
Actually GNOME changed one of its system monitoring libraries to a GPL license from LGPL after Stallman's rant. They have mentioned they might do it for more. That would make the creation of proprietary software with GNOME impossible.
Second, I'm not sure you understand the economics of proprietary software. QT is somewhere in the ballpark of $1000US. To a company putting out proprietary software this is nothing. The well designed and just generally easy and lovely API of QT speeds up developement time greatly, perhaps by as much as 30-50%. The money the company will thus save by going with QT in programmer salaries will far outweigh the cost of qt by several orders of magnitude.
So can linux 2.2 compile with egcs now?
on
egcs to become gcc
·
· Score: 1
Kernel 2.2 has always been compilable by egcs. In fact 2.1 was egcs ready since very early in its development. 2.0 had bug for bug compatability with gcc-2.7, which made it impossible to compile with any other compiler, or more acurately any compiler that propperly followed the ANSI C spec.
As a former Fermilab employee I can tell you that if you do not have a Fermilab sticker of window hanger they will not let past the gates after hours. There are guards and such at the enterences to the lab.
You are wrong. Now let me tell you some of the reasons why:
1. Lets first assume you are right, and that all this happens, lots of apps are written for user friendly linux systems, and the split happens. Where will the hacker be left. Well just where he would have been if none of it had happened: using the apps we have and the Free Software has and will develop but none of those commercial apps. However, without the user friendliness the commercial wouldn't have existed anyways. I'd rather have more choice than less.
2. Vendor specific versions of products are a myth. All they mean is "we only have so many lame tech support people, so unless you're running a stock redhat install we won't try to figure this out", which I find reasonable. Any expirienced linux user can figure out a package's dependencies, what libc, what other libs, what little apps, ect. I've used applixware, star office, and wordperfect. I believe all asked for redhat or a couple others. My machine is a mutation upon a distribution a couple of guys in a dorm I used to live in wrote a while back, and it barely even resembles that. I've never had a problem.
3. GUI consitency is a good thing. However, have you looked at KDE's "apply KDE styles to non-kde apps" feature. Using all sorts of xresources you can produce a workable hack to simulate this without moving everything to a new toolkit. On the other had, if everyone could agree on a higher level toolkit the way everyone has on xlib, that would be a-ok for me.
4. Don't fear the newbie. We were all newbies once. Some will just get stuff done, others will join the ranks of the hackers. Neither is bad.
Um..if you optimize it to hell, and set things up to use a competant system of package management (no rpms don't count) which reduces problems, it's not a big deal. Compile in the background, get other stuff done. Lighten up.
I once had the idea (and I occasionally rant about it (especially when intoxicated)) that we should have a sysadmin cabal that runs everyones' systems, because most people have no business whatsoever admining their computer (any more than I have any business adminning the power grid).
Slashdot Mirror
...then again the same could be said for the KDE project...
Do both of you just believe in the "my distribution does this type of package management, thus it must be right". Personally I chose the method of package management (encap - http://encap.cso.uiuc.edu) first, then chose and/or contructed the system to match.
I'm not sure off the top of my head if XFS supports ACLs. I would tend to think so. However, e2fs has supported ACLs for a long time. However, the linux kernel does not, nor are there stable ACL aware versions of acl utilities, or an acl-aware version of e2fs utils. I did come accross a group that was working on it. However, they were only at the alpha stages, and seemed to halt development after kernel 2.2.0pre9. Anyways, the issue of ACL is one of the kernel and user space programs, not the filesystem.
A lot of things are better than olwm or olvwm. Fvwm was better than either. CDE is low, it's ugly, it's a memory hog, it offers little additional functionality, ect, ect. I'd like KDE to become more available on Sparcs I use, but until my local sysadmins do, it'll be fvwm for me on those machines.
People should read a little more carefully. It said no GUI like Windows or the MacOS. When I think of those GUIs I think not of the lower level GUI stuff that corresponds to the X server, but the highest level stuff. The point that KDE predates GNOME, and that a few others also exist is a valid point though.
Actually a roomate of mine has a multia. It was quite decently reliable running either Linux or OpenBSD. The biggest problem is that egcs's alpha optimizations tend to lag behind their x86 optimizations (especially with the pgcc group out there) due to them focusing first on the most used systems.
2.0 is a lot of work, and depends upon many things: getting KOM/OpenParts done, troll tech getting qt-2.0 out the door, getting koffice stabel, ect. 1.1 was a set of tweaks that brought kde from stability to maturity, and 1.1.1 was just a few bugfixes. With 1.1 they just took a bunch of stuff they were working on that didn't have the dependencies that 2.0 has, and got them out. This time they just fixed bugs.
Well that's something I didn't learn in my High School German class :)
Kate is OK, and you have a point with the one syllable thing. It looks more like a Katie IMHO, but that's me. Konqui just doesn't sound catchy enough to me, and its important for a mascot to have a catchy name.
Ravi Sethi is cool too. However Sethi was one of the authors of the Red Dragon book: _Compilers: Principles, Techniques and Tools_ but he was not an author of the original Dragon book _Principles of Compiler Design_. That was done by Aho and Ullman alone.
First of all I've yet to hear about an animated assistant for KOffice. It wouldn't horribly suprise me, it just sounds like its a bunch of unconfirmed rumours as of right now. Second, if such a thing did exist, I'm sure it would be rather easy to disable in KOffice. The KDE is like that, rather configurable. Third, the paperclip took very few cycles. If you ever used MS Office, you'd know that it wasn't annoying because it slowed down your machine, and certainly didn't require a PIII/500 (used to run it on a Cyrix P-150+ (note: that CPU sucked)). What was annoying about it was it hard to figure out how to disable it (wasn't in an obvious place, forget now how to do that), and it had the tendency to jump into the foreground when you were trying to get stuff done.
I disagree. When I think of Green Dragons I think of Aho and Ullman, Principles of Compiler Designs. I wonder if the dragon will become Red when KDE 2.0 comes out. :)
Chuck? OK, learn something new everyday. Just curious, why Chuck?
I kind of like Puff as well.
I also like the proposal of katie. The dragon kind of looks like a Katie, and Katie sounds a lot like KDE.
The real question is will it have a name, and if so what. Although there is precedence for having nameless mascots (the BSDaemon, and the Mozilla Lizard both are unnamed AFAIK), but I think the name Tux, has added something to the Penguin.
KDE's control center thingie can scale images for you. I used it, and it looked quite good at 1280x1024.
Now that doesn't offer the general solution, but I figure that most people who want to use the kde mascot as a backgroud are probably using KDE.
The only reason libgtop came to mind was that some friends of time were using it for a little system monitoring app they were writing and planning to release under a BSD license. The license change screwed those plans.
You claim GNOME will never change the licensing of their core libraries. One of the major pro-GNOME, anti-KDE arguments is that you can't trust troll tech not to pull the rug out if KDE gets dominent. Yet the KDE people and TT have been making less and less restrictive licenses in order to combat this fear. On the flip side, the GNOME people are tightening their licenses. Why should I trust them to keep the license the same on their core libraries.
But that's the point. From the end user perspective they are all in /usr/local/bin because simlinks are made from /usr/local/* to /usr/local/encap/packagename/* to list all your files you simply look at the packagename dir in /usr/local/encap, aka ls /usr/local/encap/bash-2.02
/opt directory structure under SunOS, which was intellegent in that packages were seperated, but dumb in the need for an uber path variable. With 197 encapped packages now on my system, I don't want to even think about what kind of path varriable I would have without the simlinking inherrent in encap.
Ass for it sounding like a MS-type scheme, quite the contrary. It started out in many ways from the
>rpm=yuck, deb=good!
Both are pretty icky. I use the encap system of package management myself: www.encap.cso.uiuc.edu for more info.
As I understand it, KDE 2.0 will seperate most of the window manager functionality into a library. Thus, wm writers can simply link their wm to libkwm, and get 100% of the KDE compliance without having to implement an imterface like Windowmaker and Blackbox have.
Personally, I'm not to fond of kwm either, but not because it looks like Windows, that's a myth. What bothers me is its not that configurable. Yet the other 2 wms that are kde compliant don't integrate quite as well. Hopefully the library design will change this.
Actually GNOME changed one of its system monitoring libraries to a GPL license from LGPL after Stallman's rant. They have mentioned they might do it for more. That would make the creation of proprietary software with GNOME impossible.
Second, I'm not sure you understand the economics of proprietary software. QT is somewhere in the ballpark of $1000US. To a company putting out proprietary software this is nothing. The well designed and just generally easy and lovely API of QT speeds up developement time greatly, perhaps by as much as 30-50%. The money the company will thus save by going with QT in programmer salaries will far outweigh the cost of qt by several orders of magnitude.
Kernel 2.2 has always been compilable by egcs. In fact 2.1 was egcs ready since very early in its development. 2.0 had bug for bug compatability with gcc-2.7, which made it impossible to compile with any other compiler, or more acurately any compiler that propperly followed the ANSI C spec.
As a former Fermilab employee I can tell you that if you do not have a Fermilab sticker of window hanger they will not let past the gates after hours. There are guards and such at the enterences to the lab.
You are wrong. Now let me tell you some of the reasons why:
1. Lets first assume you are right, and that all this happens, lots of apps are written for user friendly linux systems, and the split happens. Where will the hacker be left. Well just where he would have been if none of it had happened: using the apps we have and the Free Software has and will develop but none of those commercial apps. However, without the user friendliness the commercial wouldn't have existed anyways. I'd rather have more choice than less.
2. Vendor specific versions of products are a myth. All they mean is "we only have so many lame tech support people, so unless you're running a stock redhat install we won't try to figure this out", which I find reasonable. Any expirienced linux user can figure out a package's dependencies, what libc, what other libs, what little apps, ect. I've used applixware, star office, and wordperfect. I believe all asked for redhat or a couple others. My machine is a mutation upon a distribution a couple of guys in a dorm I used to live in wrote a while back, and it barely even resembles that. I've never had a problem.
3. GUI consitency is a good thing. However, have you looked at KDE's "apply KDE styles to non-kde apps" feature. Using all sorts of xresources you can produce a workable hack to simulate this without moving everything to a new toolkit. On the other had, if everyone could agree on a higher level toolkit the way everyone has on xlib, that would be a-ok for me.
4. Don't fear the newbie. We were all newbies once. Some will just get stuff done, others will join the ranks of the hackers. Neither is bad.
Um..if you optimize it to hell, and set things up to use a competant system of package management (no rpms don't count) which reduces problems, it's not a big deal. Compile in the background, get other stuff done. Lighten up.
I once had the idea (and I occasionally rant about it (especially when intoxicated)) that we should have a sysadmin cabal that runs everyones' systems, because most people have no business whatsoever admining their computer (any more than I have any business adminning the power grid).