Am 03.11.2012 00:58, schrieb Adam Williamson: > Microsoft don't really expect you to upgrade Windows. They expect you to > buy a computer with Windows X on it, use it for three years, then throw > it away and buy a new computer with Windows Y on it. Red Hat expects > something similar for RHEL - they don't expect people to upgrade systems > from RHEL 5 to RHEL 6 on the fly. Corporations spend *years* planning OS > migrations, which usually involve buying new hardware, not upgrading > existing systems. This is an implicit acknowledgment that upgrades are > just not a great way to do things. I don't think we can realistically > expect Fedora to do it massively better. If you're going to do stable > releases of your operating system, it just doesn't make a lot of sense > to make people upgrade every twelve months. If you're going to have > stable releases, you should maintain them long enough that people don't > really rely on the upgrade function. That seems to be how the big boys > do it. If we can't do that, are the stable releases really achieving > much? look below, i prove you the opposite Filesystem created: Mon Aug 18 06:48:05 2008 this is the rootfs, which means it was installed with F9 now it has F17, this machine is from the same golden-master as any other machine in the whole company and there is running any service you can imagine on Fedora in production ANY upgrade was done with yum so NO fedora is not as bad as you thin in upgrades the really important ting it that it does not get worser! YES these are Vmware-guests and that is why UPGRADES becoming more and more important - the times where you plan new hardware and install it with a new OS are gone these days you install the OS on hardware X, buy hardware Y and move the whole setup live to the new hardware, the same i am doing even for physical setups on RAID10 - bouy a new machine, start it with the old disks, maybe re-create the initrd and AFTER that if i find it nice change disk by disk and re-sync the RAID or even stuck on the old disks ____________________________ [root@arrakis:~]$ tune2fs -l /dev/sdb1 tune2fs 1.42.3 (14-May-2012) Filesystem volume name: / Last mounted on: / Filesystem UUID: 918f24a7-bc8e-4da5-8a23-8800d5104421 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg dir_nlink Filesystem flags: signed_directory_hash Default mount options: journal_data_writeback Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 393216 Block count: 1572354 Reserved block count: 15723 Free blocks: 999376 Free inodes: 325103 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 383 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Mon Aug 18 06:48:05 2008 Last mount time: Sun Oct 28 19:00:37 2012 Last write time: Sun Oct 28 19:00:36 2012 Mount count: 18 Maximum mount count: -1 Last checked: Tue Mar 27 00:36:36 2012 Check interval: 31104000 (12 months) Next check after: Thu Mar 21 23:36:36 2013 Lifetime writes: 1119 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Journal inode: 8 First orphan inode: 34371 Default directory hash: tea Directory Hash Seed: 1e9d689f-15fe-4c0d-aaba-9d323049c7f4 Journal backup: inode blocks
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
