I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.
It doesn't.
It'll recognize and keep your partitions.
Come on, everybody knows that those tests are culturally biased. When are people going to learn that computers who don't have a beige box are economically and societally discriminated against?
Umm, please don't mention this in response to the Red Hat 7.1 qualification test - we've made sure quite a number of black boxes (such as IBM's) are included.;)
If it gets bad enough, I say we resort to busting crackers out of jail and straight-out open resistance.
Not such a good thing. There are LOTS of things to do first:
Educate the public. When most people hear the terms "Hacker" or even "Cracker", they think "People who break into computers to steal my money" or "People who break into computers to sabotage industry plans". I don't think that anyone who knows what Sklyarov did would want to see him in prison. Many people who just heard "he's a hacker" will support leaving him there.
This includes educating courts - as much as many of us hate lawyers, they *are* people, and I'm sure most will actually listen to reason
Complaining on/. and the likes won't help - people who care enough to read those sources already know what's going on. We need to get mainstream press to pick it up.
Vote. And not for a Microsoft-sponsored anti-freedom lobbyist like certain people controlling certain governments ATM
Busting people out of jail may cure the symptoms, but won't help fixing the problems, acutally it'll make things worse (the public would perceive us as a threat, and therefore support stronger laws against "hackers").
Ignoring laws that don't make sense (DMCA and friends) is one thing, breaking those that make sense is a totally different thing.
For someone who can handle text mode, this is true - but for someone without years of unix experience using Linux on his desktop, the GUI is definitely part of the OS.
Not really - KDE, for example, isn't officially part of the GNU project, neither are the installers of most distributions.
So, at the very least, make it GNU/BSD/KDE/Red Hat/Linux (with s,Red Hat,whatever distribution you use to install,g - if you're using a non-Red Hat RPM based distribution, please do leave the/Red Hat/ part in, though;) ).
it is interesting to note that free software is not really a team of developers working together to create great software. Rather, it is a large group of developers submitting code to one central person who collates it and releases it.
Not necessarily - KDE, for example, doesn't work that way. Lots of people have CVS write access, and the schedules for the next releases are discussed publically on kde-core-devel.
I must say that although I prefer Konqueror, it's slow start-up speed (and opening new instances) was disappointing.
Turn on prelinking. That fixes all of it.
Re:Work with the GNOME people (and vice versa)
on
KDE 2.2 Released
·
· Score: 2
1. End users not have to need to do work to have menus that are logical (sorting apps by toolkit is illogical). All it takes is for distro packagers to have to use a symlink.
That's not how it works. Anything in/etc/X11/applnk is merged directly into both the KDE ang GNOME menus, without introducing a new top level entry.
2. Users shouldn't have to maintain 2 redundant sets of the same information.
3. Packagers shouldn't have to put something into two menus, create 2 sets of icons, etc
See (1) - they don't. Put it in/etc/X11/applnk and it's ok
Twist some arms and get C++ apps to load faster. Konqueror takes 18 seconds or more, and I'm pretty sure most of it is accounted for by resolving function addresses for every object with virtual functions.
Fixed. Get the glibc, binutils and prelink packages from the current Red Hat Linux beta, and run prelink --all.
Re:Work with the GNOME people (and vice versa)
on
KDE 2.2 Released
·
· Score: 3, Informative
A good idea in theory - but in practice, this can be quite hard. For example, for panel applets, both desktops drag along large libraries - and while it is possible to display GTK widgets in Qt applications, you don't want the memory requirements that introduces.
For menus etc., we are using the desktop file standard (with the exception that gnome hasn't converted its translations to UTF8 yet) - with a sane setup, you can get an application into both menus at the same time (e.g. the/etc/X11/applnk menu on Red Hat Linux), so it's not quite as bad as you make it sound.
People who would like to contribute to the KDE development are most welcome to join - you don't have to be a C++ programmer in order to contribute - Graphics artists, GUI guru's, HTML experts and others are more then welcome to join the big KDE famility of developers..
And so are total newbies who don't know anything about computers yet - feedback from those people can be vital. Most of us simply don't notice if something is not intuitive because it's what we're used to.
If you think you can't do anything that would be useful, please check out usability.kde.org and convince yourself of the opposite. We need the feedback...
Re:Improvements...
on
KDE 2.2 Released
·
· Score: 4, Informative
1) kdesupport is gone. It was a collection of libraries that are used by KDE, but not part of KDE.
On the Red Hat side, I've replaced it with the non-kde subdirectory on ftp.kde.org.
2) kdm configuration has changed quite a bit, but I don't see what could be causing this. Please send me your old kdm config files.
3) backtrace?
4) agreed;)
5) The best way to fix this is to tell them to fix up their setup - we can't keep trying to figure out what proprietary browsers are doing forever.;)
Most of the cases where Konqueror "misrenders" something can be traced down to the fact that it's actually more intelligent than it's proprietary counterparts. Take a look at a couple of changes in the KDE_2_2_BRANCH in CVS for examples.
Re:too bad the red hat RPM's suck
on
KDE 2.2 Released
·
· Score: 2
Please provide a backtrace - I definitely can't reproduce this.
Office working won't kill Linux - just like the fact that Linux is a great server OS doesn't make it a bad desktop OS.
One of the big advantages of Linux is its flexibility - it can do everything well, from an embedded OS to an enterprise server running on a mainframe.
In fact, getting Linux onto office desktops will help Linux on home desktops - after all, it'll make non-techs (office workers) see that
Linux is not "that cryptic command-line OS for experts only".
But they have to give the people they gave the binaries the source under the GPL, so anyone receiving it could release it to the public. NDAs are not valid there.
I have yet to find a single guy that likes him, or even stands to watch him
Ok, here's one.
I'm not a big fan of Jar-Jar (or anything else in this movie), but I do like the idea of having someone succeeding by doing the wrong thing all the time and being lucky at the same time - sort of like real life (anyone else thinking of Microsoft?;) )
You should usually not run a "normal" X server on top of a framebuffer-enabled kernel (check the READMEs in the kernel source).
If you do, a lot of odd things can happen, especially when switching back and forth between X and text mode.
Sound card not detected at install, 'oh, that's easy to fix, run sndconfig at the shell' (what's a shell?), sound card gets detected and finally works (if it can detect it, why didn't it do it when I installed?)
We do autodetect PCI soundcards these days - ISA probing is always dangerous (can crash the machine), that's why we aren't doing that at installation time.
If you're using RHL >= 7.1 with KDE, you have the "kontrol-panel" link on the desktop (if you're not using KDE, install the kdeadmin package and run kontrol-panel manually) - it provides a link to all system configuration tools (including sndconfig).
Or bad x configuration (user error, whatever) that results in the GUI not working.
This is true - but it's all but easy to fix.
The fix that immediately comes to mind is using a framebuffer kernel and running X with the framebuffer driver only - that would get rid of this issue, but it would also get rid of nice features like XAA or DRI - so it's definitely not the right thing to do.
If you have a better suggestion to fix this, please let me know.
maybe he should contact the Powers That Be (if they don't get to him first!) and set up an actual slashdot interview
I won't ("Hey! I haven't done anything in particular worthwhile, but I want to be l33t h4x0r of the day! So go ahead and interview me on/.! If you comply, I promise I won't try to get first post on that article!")
I don't really think many people would be interested in the "Ask someone you never heard about anything!" column.;)
Maybe I'm wrong (and if I am, I have no problems with answering); in any case, this is definitely not something I should be asking for.
First of all, this is not some generic interview section - it's just a pointer to some questions about "shared source" I answered a while ago.
But since I'm reading this, guess there's no reason not to reply.;)
1) Ever since the Qt license problems have been resolved, RH hasn't had problems with KDE. Actually, most people in this office use KDE.
There have been a couple of internal flamewars of course, but nobody really takes them seriously.
2) Sure - some of the most serious gripes I've had with Red Hat Linux when I started BeroLinux have been fixed for quite a while - for example, the lack of a possibility to add a non-root user during installation (added in 6.1), KDE integration (initially added in 6.0, updated to a sane version in 7.1), or wasting space by not compressing man/info pages (fixed in 6.1 or 6.2, don't remember), or the lack of optimizations (all 7.x releases are compiled with -march=i386 -mcpu=i686). There are still some things I'd do differently, but overall, I'm quite satisfied with the current version (the current beta in particular).
3) Yes, to an extent. It annoys me even more that RH never bothered to make an official statement regardning the compiler.
I think the whole thing wouldn't be the way it is if someone in power had taken the time to communicate it correctly, preferrably before the 7.0 release.
4) That strongly depends on what you want to do - I personally want to eliminate the need for non-free OSes, which means usability (and thereby KDE) needs the most attention at the moment. But then, things like scaling down to embedded devices and up to high-end servers are not exactly useless either... I think going ahead in all directions the way it's happening now is a good thing.
5) We have a more generic approach to prelinking (needs a patched ld.so and binutils though). This is part of the current beta of RHL.
Slashdot Mirror
I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.
It doesn't.
It'll recognize and keep your partitions.
Come on, everybody knows that those tests are culturally biased. When are people going to learn that computers who don't have a beige box are economically and societally discriminated against?
;)
Umm, please don't mention this in response to the Red Hat 7.1 qualification test - we've made sure quite a number of black boxes (such as IBM's) are included.
Sure...
If it gets bad enough, I say we resort to busting crackers out of jail and straight-out open resistance.
Not such a good thing. There are LOTS of things to do first:
Busting people out of jail may cure the symptoms, but won't help fixing the problems, acutally it'll make things worse (the public would perceive us as a threat, and therefore support stronger laws against "hackers").
Ignoring laws that don't make sense (DMCA and friends) is one thing, breaking those that make sense is a totally different thing.
What is not part of the operating system?
- GUI
For someone who can handle text mode, this is true - but for someone without years of unix experience using Linux on his desktop, the GUI is definitely part of the OS.
So, call it GNU/KDE/XFree86/Linux
Not really - KDE, for example, isn't officially part of the GNU project, neither are the installers of most distributions.
/Red Hat/ part in, though ;) ).
So, at the very least, make it GNU/BSD/KDE/Red Hat/Linux (with s,Red Hat,whatever distribution you use to install,g - if you're using a non-Red Hat RPM based distribution, please do leave the
it is interesting to note that free software is not really a team of developers working together to create great software. Rather, it is a large group of developers submitting code to one central person who collates it and releases it.
Not necessarily - KDE, for example, doesn't work that way. Lots of people have CVS write access, and the schedules for the next releases are discussed publically on kde-core-devel.
I must say that although I prefer Konqueror, it's slow start-up speed (and opening new instances) was disappointing.
Turn on prelinking. That fixes all of it.
1. End users not have to need to do work to have menus that are logical (sorting apps by toolkit is illogical). All it takes is for distro packagers to have to use a symlink.
/etc/X11/applnk is merged directly into both the KDE ang GNOME menus, without introducing a new top level entry.
/etc/X11/applnk and it's ok
That's not how it works. Anything in
2. Users shouldn't have to maintain 2 redundant sets of the same information.
3. Packagers shouldn't have to put something into two menus, create 2 sets of icons, etc
See (1) - they don't. Put it in
Improved firewall config during installation.
Microsoft isn't listening; are RedHat and the others
Yes. A Red Hat Linux 7.1 system doesn't start any network services by default, and installs a firewall by default.
7.2 will be even better.
Similarily, up2date finally runs in text mode so you can keep unattended systems up to date using cron jobs.
Twist some arms and get C++ apps to load faster. Konqueror takes 18 seconds or more, and I'm pretty sure most of it is accounted for by resolving function addresses for every object with virtual functions.
Fixed. Get the glibc, binutils and prelink packages from the current Red Hat Linux beta, and run prelink --all.
A good idea in theory - but in practice, this can be quite hard. For example, for panel applets, both desktops drag along large libraries - and while it is possible to display GTK widgets in Qt applications, you don't want the memory requirements that introduces.
/etc/X11/applnk menu on Red Hat Linux), so it's not quite as bad as you make it sound.
For menus etc., we are using the desktop file standard (with the exception that gnome hasn't converted its translations to UTF8 yet) - with a sane setup, you can get an application into both menus at the same time (e.g. the
Yes. Read the README file.
You need to install the stuff from the non-kde directory. It contains libraries that are needed by KDE (but not part of KDE).
People who would like to contribute to the KDE development are most welcome to join - you don't have to be a C++ programmer in order to contribute - Graphics artists, GUI guru's, HTML experts and others are more then welcome to join the big KDE famility of developers..
And so are total newbies who don't know anything about computers yet - feedback from those people can be vital. Most of us simply don't notice if something is not intuitive because it's what we're used to.
If you think you can't do anything that would be useful, please check out usability.kde.org and convince yourself of the opposite. We need the feedback...
1) kdesupport is gone. It was a collection of libraries that are used by KDE, but not part of KDE.
;)
;)
On the Red Hat side, I've replaced it with the non-kde subdirectory on ftp.kde.org.
2) kdm configuration has changed quite a bit, but I don't see what could be causing this. Please send me your old kdm config files.
3) backtrace?
4) agreed
5) The best way to fix this is to tell them to fix up their setup - we can't keep trying to figure out what proprietary browsers are doing forever.
Most of the cases where Konqueror "misrenders" something can be traced down to the fact that it's actually more intelligent than it's proprietary counterparts. Take a look at a couple of changes in the KDE_2_2_BRANCH in CVS for examples.
Please provide a backtrace - I definitely can't reproduce this.
KDE 2.2 is part of Red Hat Linux 7.2.
What I would like is something like an annual membership
;)
Subscribe to Red Hat Network, then...
There could be premiums -- a mouse pad autographed by Alan Cox
Can't help you with that ATM - but if a "Windows sucks" note autographed by myself will do the job...
Office working won't kill Linux - just like the fact that Linux is a great server OS doesn't make it a bad desktop OS. One of the big advantages of Linux is its flexibility - it can do everything well, from an embedded OS to an enterprise server running on a mainframe. In fact, getting Linux onto office desktops will help Linux on home desktops - after all, it'll make non-techs (office workers) see that Linux is not "that cryptic command-line OS for experts only".
But they have to give the people they gave the binaries the source under the GPL, so anyone receiving it could release it to the public. NDAs are not valid there.
I have yet to find a single guy that likes him, or even stands to watch him
;) )
Ok, here's one.
I'm not a big fan of Jar-Jar (or anything else in this movie), but I do like the idea of having someone succeeding by doing the wrong thing all the time and being lucky at the same time - sort of like real life (anyone else thinking of Microsoft?
You should usually not run a "normal" X server on top of a framebuffer-enabled kernel (check the READMEs in the kernel source).
If you do, a lot of odd things can happen, especially when switching back and forth between X and text mode.
Sound card not detected at install, 'oh, that's easy to fix, run sndconfig at the shell' (what's a shell?), sound card gets detected and finally works (if it can detect it, why didn't it do it when I installed?)
We do autodetect PCI soundcards these days - ISA probing is always dangerous (can crash the machine), that's why we aren't doing that at installation time.
If you're using RHL >= 7.1 with KDE, you have the "kontrol-panel" link on the desktop (if you're not using KDE, install the kdeadmin package and run kontrol-panel manually) - it provides a link to all system configuration tools (including sndconfig).
Or bad x configuration (user error, whatever) that results in the GUI not working.
This is true - but it's all but easy to fix.
The fix that immediately comes to mind is using a framebuffer kernel and running X with the framebuffer driver only - that would get rid of this issue, but it would also get rid of nice features like XAA or DRI - so it's definitely not the right thing to do.
If you have a better suggestion to fix this, please let me know.
I did end up reading it. ;)
/.! If you comply, I promise I won't try to get first post on that article!")
;)
maybe he should contact the Powers That Be (if they don't get to him first!) and set up an actual slashdot interview
I won't ("Hey! I haven't done anything in particular worthwhile, but I want to be l33t h4x0r of the day! So go ahead and interview me on
I don't really think many people would be interested in the "Ask someone you never heard about anything!" column.
Maybe I'm wrong (and if I am, I have no problems with answering); in any case, this is definitely not something I should be asking for.
First of all, this is not some generic interview section - it's just a pointer to some questions about "shared source" I answered a while ago.
;)
But since I'm reading this, guess there's no reason not to reply.
1) Ever since the Qt license problems have been resolved, RH hasn't had problems with KDE. Actually, most people in this office use KDE.
There have been a couple of internal flamewars of course, but nobody really takes them seriously.
2) Sure - some of the most serious gripes I've had with Red Hat Linux when I started BeroLinux have been fixed for quite a while - for example, the lack of a possibility to add a non-root user during installation (added in 6.1), KDE integration (initially added in 6.0, updated to a sane version in 7.1), or wasting space by not compressing man/info pages (fixed in 6.1 or 6.2, don't remember), or the lack of optimizations (all 7.x releases are compiled with -march=i386 -mcpu=i686). There are still some things I'd do differently, but overall, I'm quite satisfied with the current version (the current beta in particular).
3) Yes, to an extent. It annoys me even more that RH never bothered to make an official statement regardning the compiler.
I think the whole thing wouldn't be the way it is if someone in power had taken the time to communicate it correctly, preferrably before the 7.0 release.
4) That strongly depends on what you want to do - I personally want to eliminate the need for non-free OSes, which means usability (and thereby KDE) needs the most attention at the moment. But then, things like scaling down to embedded devices and up to high-end servers are not exactly useless either... I think going ahead in all directions the way it's happening now is a good thing.
5) We have a more generic approach to prelinking (needs a patched ld.so and binutils though). This is part of the current beta of RHL.