Not that quick... this was a coordinated release of the bug Owen Taylor at Red Hat found by investigating a bug against Gnome. This wasn't found yesterday, vendors have had time to create and test packages.
FWIW, I'm sure that varies. I certainly try to upstream generic patches myself for the packages I maintain at Red Hat for Red Hat Linux, and many others try to do the same. When it gets accepted, there's less maintenance for me.
So if PostgreSQL reaches 7.3 with full replication support and if Redhat (or Suse or whatever) support it (and Linux) well, we might get some major corporate players on our side.
Red Hat already supports and ships a version of PostgreSQL: Red Hat Database
Let me get this straight...you think that they are losing 44% by virtue of saturating the market, in other words selling too many ?? I have read all the news articles and this is not so, it is due to declining market share that it is losing to all the great new color PDAs. You are either a cunning troll or a misinformed user.
Basically, he was pointing out that there are many palm users out there who don't upgrade. They keep using what works. My Palm V does what I need, no need to spend another $300. And when there no longer is a huge influx of new customers, sales go down.
I'm sitting at home with my fresh install of RH 7.1 and I'm wondering what kernel to upgrade it to. Any suggestions? Is there a stable one in there somewhere that I should go with? Should I stick with the default kernel that's on their now?
The current kernel supported by Red Hat for Red Hat Linux 7.1 is 2.4.9-21, which you can see does a good job in this test.
Note that giving the users a choice of which OS to run (a "level playing field") isn't a necessity for vendors... If you you sell 100 units split fifty-fifty when selling to Win and Linux, you might be just as happy selling 90 to Windows and not selling to the Linux market by not porting.
Of course, if the cost of bringing the product to the platform is low, the support burden low you might as well get the remaining profit as well. It's just a question of economics.
Vendors test (in Red Hat's (where I work) case, a lot), fix and create known good kernels. He should use them, instead of whatever is new (and untested) this week.
No question about RedHat's broken GCC 2.96 compiler and what they're doing to fix it in later releases?
It's not broken. It was a move we had to make at the time: gcc 2.95 was badly broken (e.g. didn't compile glibc 2.2), had severe lacks in C++ conformance and didn't support the architectures we needed. Also, performance was abysmal on other architectures we cared about (in particular, the alpha). Here are more details.. Right now, gcc 2.96RH is a very mature and solid compiler
Gcc 2.96RH has served us well for three releases now. We're not going to "fix it" (it's not broken, it's better than the current alternatives and we don't want to break binary compatibility), but at
some point we'll switch again. You can find some hints at that in the current Rawhide.
It takes a little time to test things, and this errata release shouldn't have happened. We (Red Hat) screwed up, which opened up a window where the vulnerability is known and not everyone has the fix ready. Delaying it a week, as we had intended would have avoided that window of oppurtunity for script kiddies.
Tastes differ - I love Civilization III, just as I loved SMAC (which runs great under Linux). It still has its "just one more round" factor working.
RPMs of Emacs 21 for Red Hat Linux 7.2 (Enigma)
on
GNU Emacs 21
·
· Score: 2
Unofficial RPMs of Emacs 21 for Red Hat Linux 7.2 (Enigma) are available.
They're not supported, but have been lightly tested and seem to work great - feedback appreciated (mail or bugzilla against rawhide)
Re:Is RH including proprietary sw these days?
on
Red Hat 7.2 Released
·
· Score: 2
Yes, as gcc 2.95.x (like 2.96RH, egcs 1.1.2, gcc 2.8, gcc 3) aren't compatible with anything but themselves you will break binary compatiblity for C++. Also, 2.95.x is nowhere near as good as 2.96RH. Downgrading the compiler is definitely not recommended.
Re:to forestall the inevitable -- why not reiserfs
on
Red Hat 7.2 Released
·
· Score: 2
Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.
That's not entirely accurate... it's faster in some situations (add a separate nvram journal to increase the speed significantly), not in others. Ext3 is better at scheduling I/O, but there is also an overhead (CPU, writes) with journaling. If all you want to do is copy a gigabyte of data to the disk as fast as possible, it will be slower. If there are many consecutive small writes, the advantages start showing.
Given that Red Hat releases a major release pretty much every year, "Red Hat Linux 2002" would actually make some sense.
We don't - in the past, it's typically been 18 months (3 6-month cycles). We haven't released a major release this year, to give one example.
Re:sucks to be a guy named Torvalds right now...
on
Linux Kernel Bugs
·
· Score: 2
If you find bugs, please put them in bugzilla.
- make sure to add details on your hardware, as it's not a generic Tulip problem (I've just tested mine - no problems).
Re:What is a Good Mailing List for this Info?
on
Linux Kernel Bugs
·
· Score: 5, Insightful
Can someone recommend a good mailing list for linux issues? I am using mostly RedHat boxes, but they don't seem to have any free mailing list that I can find (perhaps they have one i don't know about).
Re:Any support for Foreign keys yet?
on
MySQL 4.0 Released
·
· Score: 3, Insightful
Does this new release of MySQL support the proper use of foreign keys internally? (found no info in release notes). Or has MySQL a different way of implementing a "One-Many"-relation?
You don't absolutely need foreign keys to implement one-to-many relationsships - you can just do it the standard way and drop the foreign key constraint. Of course, your app needs to make sure that it updates and deletes entries when necesarry (and when did NTH^WNTNU stop using Oracle? That's what we used when I had the database course there, and MySQL is a poor choice for a course in databases If there's one place you'd like to really have foreign keys, subselects, transactions, views etc, a university course on databases is it - and PostgreSQL clearly has better SQL support than MySQL)
The GPL'ed version of MySQL isn't even free software! (The GPL version i always a subverions or two behind, I believe.)
You're wrong - the newest version of MySQL is GPLed (you can buy another kind of license from the company behind it if you need to). They changed their policy mid-2000, if memory serves.
When using databases as backends, I'd much rather use PostgreSQL myself (transactions without table trickery, foreign keys, views and subselects being the things I miss most in MySQL), but MySQL certainly is free - and the subset of SQL they do support is very useful, and sufficient for many purposes
In Desert Storm, the violence did do part of the job. It drove Saddam out of Kuwait. But because they didn't go all the way to Baghdad, Saddam is still there, the sanctions stay up, and the area is still in a pretty bad way.
If they wanted to, Saddam Hussein could likely have been disposed in Desert Storm - but removing him from power isn't as straightforward as it would look like. Another leader with very similar views could take power, gaining almost nothing. Or even more dangerous - you could get a vacuum in power, with various factions trying to grab a part of the power, with support from other countries. Iraq has a shia muslim minority, which could easily attract support from Iran. In the North, you have the kurds - or rather, a part of them. They're spread across many countries and want a country of their own. Also, there is a lot of oil to fight for. Removing the force who seems to keep it all together (rather oppressively) isn't as straightforward as it seems, it could easily be the match lighting the powder keg.
Slashdot Mirror
Not that quick... this was a coordinated release of the bug Owen Taylor at Red Hat found by investigating a bug against Gnome. This wasn't found yesterday, vendors have had time to create and test packages.
FWIW, I'm sure that varies. I certainly try to upstream generic patches myself for the packages I maintain at Red Hat for Red Hat Linux, and many others try to do the same. When it gets accepted, there's less maintenance for me.
So if PostgreSQL reaches 7.3 with full replication support and if Redhat (or Suse or whatever) support it (and Linux) well, we might get some major corporate players on our side.
Red Hat already supports and ships a version of PostgreSQL: Red Hat Database
Also, having companies like Red Hat, Inc. (where I work) to talk to doesn't hurt - FreeBSD is low on corporate backing, FTTB.
Note that the 8500 is supported in 2D only, FTTB.
Let me get this straight...you think that they are losing 44% by virtue of saturating the market, in other words selling too many ?? I have read all the news articles and this is not so, it is due to declining market share that it is losing to all the great new color PDAs. You are either a cunning troll or a misinformed user.
Basically, he was pointing out that there are many palm users out there who don't upgrade. They keep using what works. My Palm V does what I need, no need to spend another $300. And when there no longer is a huge influx of new customers, sales go down.
The current kernel supported by Red Hat for Red Hat Linux 7.1 is 2.4.9-21, which you can see does a good job in this test.
Note that giving the users a choice of which OS to run (a "level playing field") isn't a necessity for vendors... If you you sell 100 units split fifty-fifty when selling to Win and Linux, you might be just as happy selling 90 to Windows and not selling to the Linux market by not porting.
Of course, if the cost of bringing the product to the platform is low, the support burden low you might as well get the remaining profit as well. It's just a question of economics.
Some were - I've bought all of Loki's games (even two of two of them, as gifts), except Postal. And I would have bought Deus Ex as well.
Vendors test (in Red Hat's (where I work) case, a lot), fix and create known good kernels. He should use them, instead of whatever is new (and untested) this week.
No question about RedHat's broken GCC 2.96 compiler and what they're doing to fix it in later releases?
It's not broken. It was a move we had to make at the time: gcc 2.95 was badly broken (e.g. didn't compile glibc 2.2), had severe lacks in C++ conformance and didn't support the architectures we needed. Also, performance was abysmal on other architectures we cared about (in particular, the alpha). Here are more details.. Right now, gcc 2.96RH is a very mature and solid compiler
Gcc 2.96RH has served us well for three releases now. We're not going to "fix it" (it's not broken, it's better than the current alternatives and we don't want to break binary compatibility), but at
some point we'll switch again. You can find some hints at that in the current Rawhide.
How about including another option for those who have to use ftp but don't want to get burned on the wu-ftpd exploit of the day?
There already is one more ftp server in the distribution (the one from Kerberos), and if you look in Rawhide, you'll find vsftpd as well.
It takes a little time to test things, and this errata release shouldn't have happened. We (Red Hat) screwed up, which opened up a window where the vulnerability is known and not everyone has the fix ready. Delaying it a week, as we had intended would have avoided that window of oppurtunity for script kiddies.
Tastes differ - I love Civilization III, just as I loved SMAC (which runs great under Linux). It still has its "just one more round" factor working.
Unofficial RPMs of Emacs 21 for Red Hat Linux 7.2 (Enigma) are available.
They're not supported, but have been lightly tested and seem to work great - feedback appreciated (mail or bugzilla against rawhide)
Yes, as gcc 2.95.x (like 2.96RH, egcs 1.1.2, gcc 2.8, gcc 3) aren't compatible with anything but themselves you will break binary compatiblity for C++. Also, 2.95.x is nowhere near as good as 2.96RH. Downgrading the compiler is definitely not recommended.
Our tests have shown that (unless you compile in full debugging), ext3 is actually faster than ext2.
That's not entirely accurate... it's faster in some situations (add a separate nvram journal to increase the speed significantly), not in others. Ext3 is better at scheduling I/O, but there is also an overhead (CPU, writes) with journaling. If all you want to do is copy a gigabyte of data to the disk as fast as possible, it will be slower. If there are many consecutive small writes, the advantages start showing.
Given that Red Hat releases a major release pretty much every year, "Red Hat Linux 2002" would actually make some sense.
We don't - in the past, it's typically been 18 months (3 6-month cycles). We haven't released a major release this year, to give one example.
If you find bugs, please put them in bugzilla.
- make sure to add details on your hardware, as it's not a generic Tulip problem (I've just tested mine - no problems).
Can someone recommend a good mailing list for linux issues? I am using mostly RedHat boxes, but they don't seem to have any free mailing list that I can find (perhaps they have one i don't know about).
Go to our mailing list server, and sign up for redhat-watch-list.
Oh well, looks like the boys at RedHat are gonna be putting in some overtime this weekend.
We released updated kernels yesterday:
Does this new release of MySQL support the proper use of foreign keys internally? (found no info in release notes). Or has MySQL a different way of implementing a "One-Many"-relation?
You don't absolutely need foreign keys to implement one-to-many relationsships - you can just do it the standard way and drop the foreign key constraint. Of course, your app needs to make sure that it updates and deletes entries when necesarry (and when did NTH^WNTNU stop using Oracle? That's what we used when I had the database course there, and MySQL is a poor choice for a course in databases If there's one place you'd like to really have foreign keys, subselects, transactions, views etc, a university course on databases is it - and PostgreSQL clearly has better SQL support than MySQL)
What's the problem? If you use the UTF-8 encoding
for Unicode, all your data will be ASCII compatible.
ASCII is 7 bit while UTF-8 is 8 bit. You would want UTF-7 to remain ASCII-"compatible" (UTF-7 is defined in RFC 2152).
The GPL'ed version of MySQL isn't even free software! (The GPL version i always a subverions or two behind, I believe.)
You're wrong - the newest version of MySQL is GPLed (you can buy another kind of license from the company behind it if you need to). They changed their policy mid-2000, if memory serves.
When using databases as backends, I'd much rather use PostgreSQL myself (transactions without table trickery, foreign keys, views and subselects being the things I miss most in MySQL), but MySQL certainly is free - and the subset of SQL they do support is very useful, and sufficient for many purposes
In Desert Storm, the violence did do part of the job. It drove Saddam out of Kuwait. But because they didn't go all the way to Baghdad, Saddam is still there, the sanctions stay up, and the area is still in a pretty bad way.
If they wanted to, Saddam Hussein could likely have been disposed in Desert Storm - but removing him from power isn't as straightforward as it would look like. Another leader with very similar views could take power, gaining almost nothing. Or even more dangerous - you could get a vacuum in power, with various factions trying to grab a part of the power, with support from other countries. Iraq has a shia muslim minority, which could easily attract support from Iran. In the North, you have the kurds - or rather, a part of them. They're spread across many countries and want a country of their own. Also, there is a lot of oil to fight for. Removing the force who seems to keep it all together (rather oppressively) isn't as straightforward as it seems, it could easily be the match lighting the powder keg.