1 - Take the package list under/var/log/rpmpkgs
2 - move/var/lib/rpm to somewhere else
3 - mkdir/var/lib/rpm
4 - rpm --initdb (to create a new database)
5 - Go where all your rpms are and rpm -i --justdb --noscripts --notriggers --nodeps `cat/var/log/rpmpkgs`
Voila! You just recreated your rpm database from scratch...
Wrong the Pentium Pro was the first one to implement it...
From Intel:
3.3.3. Extended Physical Addressing Beginning with the P6 family processors, the IA-32 architecture supports addressing of up to 64 GBytes (236 bytes) of physical memory. A program or task cannot address locations in this address space directly. Instead it addresses individual linear address spaces of up to 4 GBytes that are mapped to the larger 64-GByte physical address space through the processor s virtual memory management mechanism. A program can switch between linear address spaces within this 64-GByte physical address space by changing segment selectors in the segment registers. The use of extended physical addressing requires the processor to operate in protected mode and the operating system to provide a virtual memory management system. (See 36-Bit Physical Addressing Using the PAE Paging Mechanism in Chapter 3 of the IA-32 Intel Architecture Software Developer s Manual, Volume 3 for more information about this addressing mechanism.)
Don't forget that almost all recent ia32 cpus support 36-bits addresses (well that's an ugly hack ala msdos but it allows you to use up to 64GB of RAM instead of 4)
Wrong: a Solaris license is non transferable. If you buy used sun hardware (and not from Sun or some authorized resellers) you have to pay for a Solaris license.
Right, but how does it make any difference? If you only use su and someone gets your password, they're able to get the root password when you su (because that's your only way of becoming root from a remote computer)... Moreover, you can restrict sudo so it doesn't give you root access to everything. IMHO, sudo is definitely better than su, just because it's fine grained.
The only issue right is the need for the these drives by the government (these drives are SCSI-3, 160 G each):
From: YEAHRIGHT@cdw.com
Sent: Monday, January 28, 2002 11:59 AM
To: Whatever
Subject: RE: CDW Order XXXXXXX
I have a new update on these drives. I just received the below email from Seagate. It is not good news. This change in status was as unexpected and I appologize. Per Seagate any order the government places has priority over
any other users order. So it seems we got screwed by the gov.
Let me know what you want to do.
--------------
ST1181677LCV, ST1181677LC, and ST1181677FCV just went on EXTREME allocation until March (at the earliest). The Department of Defense has taken allocation on all of the drives we had allocated for distribution for the end of January and all
of February. These increases were unexpected and we are working to get the build schedules adjusted to accommodate for the increased demand.
I will be working with your purchasing departments and distribution partners to direct product into your warehouses, but I must forewarn you that the outlook is not good. March is the most recent delivery date, however, that is NOT a definite. Please call me if you have any questions or need anything else. I assure you that the difficulties you experienced in
getting a response last week will NOT happen again.
You're correct, it is regardless of filesystem. If you happen to be running 2.4.15 or 2.5.0, just remember to force a fsck for the next reboot (shutdown -F) that's the only way to clear the fs because it will be marked clean even if it's not). Right now, the developpers don't know how reseirfs would deal with this bug...
Well, right now the bottleneck is not the bus itself but much more the drive. One ATA 100 drive won't be much faster that an ATA 66 drive...
But with a faster bus, you can use the bandwidth to add drives to your bus (but still, with 2 IDE drives, right now, you won't be able to saturate the bus).
IMHO, right now the Firewire fuss is just a marketing ploy: a firewire drive is not faster than any existing IDE drive... Look at the box, people read 400 Mb/s: "wouah, must be fast".
Wich is true (http://lwn.net/2001/0503/a/lt-dump.php3):
From: Linus Torvalds
To: Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc: Kernel Mailing List
[ linux-kernel added back as a cc ]
On Fri, 27 Apr 2001, Neil Conway wrote:
>
> I'm surprised that dump is deprecated (by you at least;-)). What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already playing
russian rulette with their backups. It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".
Slashdot Mirror
That's BS.
/var/log/rpmpkgs /var/lib/rpm to somewhere else /var/lib/rpm /var/log/rpmpkgs`
1 - Take the package list under
2 - move
3 - mkdir
4 - rpm --initdb (to create a new database)
5 - Go where all your rpms are and rpm -i --justdb --noscripts --notriggers --nodeps `cat
Voila! You just recreated your rpm database from scratch...
That's PEBCAK (Problem Exists Between Chair And Keyboard)...
The big difference is that Americans vote during the week-days (and that could be a major reason explaining why they are only few of them voting)...
Guess that if your french is that bad after 8 years, you really wasted your time...
Wrong the Pentium Pro was the first one to implement it...
From Intel:
3.3.3. Extended Physical Addressing Beginning with the P6 family processors, the IA-32 architecture supports addressing of up to 64 GBytes (236 bytes) of physical memory. A program or task cannot address locations in this address space directly. Instead it addresses individual linear address spaces of up to 4 GBytes that are mapped to the larger 64-GByte physical address space through the processor s virtual memory management mechanism. A program can switch between linear address spaces within this 64-GByte physical address space by changing segment selectors in the segment registers. The use of extended physical addressing requires the processor to operate in protected mode and the operating system to provide a virtual memory management system. (See 36-Bit Physical Addressing Using the PAE Paging Mechanism in Chapter 3 of the IA-32 Intel Architecture Software Developer s Manual, Volume 3 for more information about this addressing mechanism.)
Don't forget that almost all recent ia32 cpus support 36-bits addresses (well that's an ugly hack ala msdos but it allows you to use up to 64GB of RAM instead of 4)
True but you can tell the os not to do that (check /proc/sys/vm/overcommit_memory).
Wrong: a Solaris license is non transferable. If you buy used sun hardware (and not from Sun or some authorized resellers) you have to pay for a Solaris license.
Right, but how does it make any difference? If you only use su and someone gets your password, they're able to get the root password when you su (because that's your only way of becoming root from a remote computer)...
Moreover, you can restrict sudo so it doesn't give you root access to everything. IMHO, sudo is definitely better than su, just because it's fine grained.
And many other big aircrafts: A-340 (I'm sure about this one not sure about the smaller ones)
Actually, Concorde was the first civil plane to use fly-by-wire...
That's because you use a stupid shell... zsh doesn't expand .* into . and .. ! :-)
Or just use galeon, mozilla's kick ass cousin which does have the tabs and the gesture thing by default...
The only issue right is the need for the these drives by the government (these drives are SCSI-3, 160 G each):
From: YEAHRIGHT@cdw.com
Sent: Monday, January 28, 2002 11:59 AM
To: Whatever
Subject: RE: CDW Order XXXXXXX
I have a new update on these drives. I just received the below email from Seagate. It is not good news. This change in status was as unexpected and I appologize. Per Seagate any order the government places has priority over
any other users order. So it seems we got screwed by the gov.
Let me know what you want to do.
--------------
ST1181677LCV, ST1181677LC, and ST1181677FCV just went on EXTREME allocation until March (at the earliest). The Department of Defense has taken allocation on all of the drives we had allocated for distribution for the end of January and all
of February. These increases were unexpected and we are working to get the build schedules adjusted to accommodate for the increased demand.
I will be working with your purchasing departments and distribution partners to direct product into your warehouses, but I must forewarn you that the outlook is not good. March is the most recent delivery date, however, that is NOT a definite. Please call me if you have any questions or need anything else. I assure you that the difficulties you experienced in
getting a response last week will NOT happen again.
Regards,
You're correct, it is regardless of filesystem. If you happen to be running 2.4.15 or 2.5.0, just remember to force a fsck for the next reboot (shutdown -F) that's the only way to clear the fs because it will be marked clean even if it's not). Right now, the developpers don't know how reseirfs would deal with this bug...
Well, right now the bottleneck is not the bus itself but much more the drive. One ATA 100 drive won't be much faster that an ATA 66 drive...
But with a faster bus, you can use the bandwidth to add drives to your bus (but still, with 2 IDE drives, right now, you won't be able to saturate the bus).
IMHO, right now the Firewire fuss is just a marketing ploy: a firewire drive is not faster than any existing IDE drive... Look at the box, people read 400 Mb/s: "wouah, must be fast".
So, I should have added that it is still a bad idea to backup an ext2 partition using dump/restore...
Wich is true (http://lwn.net/2001/0503/a/lt-dump.php3): From: Linus Torvalds To: Neil Conway Subject: Re: [PATCH] SMP race in ext2 - metadata corruption. Date: Fri, 27 Apr 2001 09:59:46 -0700 (PDT) Cc: Kernel Mailing List [ linux-kernel added back as a cc ] On Fri, 27 Apr 2001, Neil Conway wrote: > > I'm surprised that dump is deprecated (by you at least ;-)). What to
> use instead for backups on machines that can't umount disks regularly?
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
So anybody who depends on "dump" getting backups right is already playing
russian rulette with their backups. It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".