View previous topic :: View next topic |
Author |
Message |
cyan051 n00b
Joined: 21 Aug 2004 Posts: 64
|
Posted: Sat Mar 11, 2006 7:38 pm Post subject: sparc 2006.0 live-cd |
|
|
ok, i can understand why maintainers are reluctant to put some features by default on sparc (gcc 3.4, reiserfs, etc)...
but why remove and option completly from a live cd?
2004.1 which was the last one i've used had reiserfs support as a module.
and a user had a choice.
2006.0 has nothing...and as a result i cannot use it as recovery cd.
yes, i do use reiserfs for root partition. and yes, i know its not recommended - but linux is all about choices.
so when my system could not boot (forgot to do silo -c after updating silo ebuild), 2006 livecd was useless...
i simply don't understand such decisions. |
|
Back to top |
|
|
blu3bird Retired Dev
Joined: 04 Oct 2003 Posts: 614 Location: Munich, Germany
|
Posted: Sat Mar 11, 2006 9:05 pm Post subject: |
|
|
It's the same with "stage1 install is no longer supported". Devs are trying to protect dumb-asses against themselfs.
With access to more experimental stuff a lot of people will definily use it, and break things.
In my opinion a Live-Cd should include all possible options(as module) so advanced users can load and use it
(at there own risk)
Maybe they could add a huge "experimental" beside it and 3-4 "do you really want to load xyz?" confirms but this whould respect the users choice _________________ Black Holes are created when God divides by zero! |
|
Back to top |
|
|
gust4voz Retired Dev
Joined: 09 Sep 2003 Posts: 373 Location: Buenos Aires, Argentina
|
Posted: Sat Mar 11, 2006 9:30 pm Post subject: |
|
|
Users that know what they are doing, know enough and wanna risk it can build their own livecd.
If you can't build a livecd you probably don't know for certain why X feature isn't a wise choice.
Filesystem testing involves recovery simulation too, not just "Hey i did a stage3 install and it works! Ship it!"
If we ship really experimental stuff that DOES break we get invalid bugs, and this is a volunteer effort - we want to avoid as many bugs as possible.
Some experimental stuff that we want to see going mainstream in some future are shipped in experimental builds (like the 2.6 experimental livecd which just doesn't cut it yet for release).
Reiser wasn't able to withstand a full release build (stages, livecd & packagecd) without corruption with no power loss or hang, so in my perspective it's useless and dangerous.
As blu3bird says, on one side it's to protect users from their self riceness, and also to avoid wasting time reading bug reports for stuff that's known broken and explaining over and over countless times this same thing.
What do you prefer? A distribution that works? Or something pseudo-working that sounds great and cool until you loose something important?
It's not that we are bad asses, this is a 100% volunteer effort, and each time we gotta explain why 64 bit userland is a bad idea, reiser doesn't work or 2.6 kernels are not as good as 2.4 it's time we are using in a non-productive way. _________________ Gustavo Zacarias
Gentoo/SPARC monkey |
|
Back to top |
|
|
cyan051 n00b
Joined: 21 Aug 2004 Posts: 64
|
Posted: Sat Mar 11, 2006 9:55 pm Post subject: |
|
|
first in general: is gentoo about 100% stability or about flexibility?
i completly agree that not puting stuff like reiser in default configs is a good choice...
but livecds should have as many modules as possible. what if i'm stuck with a non-bootable system and i lost it my version of livecd?
yes, its my own choice that i use reiserfs and it quite well documented that it is NOT recommended.
but it does not mean i should not use it EVER.
and in case something breaks, thats what livecd is supposed to be for...
and its not like reiserfs v3 does not work at all...
actually, it does not work only on a small percentage of sparcs (compared to reiser4 which is in a much worse condition)...
same applies for kernel 2.6, but thats another story... |
|
Back to top |
|
|
cyan051 n00b
Joined: 21 Aug 2004 Posts: 64
|
|
Back to top |
|
|
gust4voz Retired Dev
Joined: 09 Sep 2003 Posts: 373 Location: Buenos Aires, Argentina
|
Posted: Sat Mar 11, 2006 10:25 pm Post subject: |
|
|
Problem is users don't read files named README, IMPORTANT, DANGEROUS or documentation.
So you can't really warn them in an effective way and they find out when it's too late.
Stuff breaking is what the EXPERIMENTAL {livecd,stages,packaged} are for, not the releases.
Release material is supposed to be the overall best stuff that's not supposed to be bad.
And also drivers != filesystems. Actually i cram a lot of untested drivers in the livecd since worst case scenario it won't work, the kernel will oops or i'll get a success report and add it to the hardware database.
Worst case scenario for a filesystem is making you feel safe and comfy about something that you can regret later. Maybe you don't use your sparc for a production environment and don't care, but some people do. _________________ Gustavo Zacarias
Gentoo/SPARC monkey |
|
Back to top |
|
|
cyan051 n00b
Joined: 21 Aug 2004 Posts: 64
|
Posted: Sun Mar 12, 2006 8:55 am Post subject: |
|
|
btw, i did experience data corruption with reiserfs, but it was always smaller than with ext3...
only instances when data corruption occured was if i got "Unable to handle kernel NULL pointer dereference" core dump.
and that was two times in the last 600 days. and since i've started using grsec extensions six months ago, it captures such things on the fly without crash.
regarding how happy i am with reiserfs - i've tested what is (in my opinion) worst-case scenario - single disk spindown in LVM2 stripped config during high I/O.
reiserfs behaved supprisingly well...
Quote: | 2005/06/24 22:40:54; 04; src@helios.next; kern; warning; sym0:9:0: ABORT operation started.
2005/06/24 22:40:54; 04; src@helios.next; kern; warning; sym0:9:control msgout: 80 20 5f d.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: ABORT operation complete.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: ABORT operation timed-out.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: DEVICE RESET operation started.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: DEVICE RESET operation timed-out.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: BUS RESET operation started.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0: SCSI BUS reset detected.
2005/06/24 22:41:35; 05; src@helios.next; kern; notice; sym0: SCSI BUS has been reset.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: BUS RESET operation complete.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: HOST RESET operation started.
2005/06/24 22:41:35; 05; src@helios.next; kern; notice; sym0: SCSI BUS has been reset.
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; sym0:9:0: HOST RESET operation complete.
2005/06/24 22:41:35; 06; src@helios.next; kern; info; scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 9 lun 0
2005/06/24 22:41:35; 06; src@helios.next; kern; info; SCSI error : <0 0 9 0> return code = 0x100ff
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; end_request: I/O error, dev sdc, sector 3494976
2005/06/24 22:41:35; 03; src@helios.next; kern; err; scsi0 (9:0): rejecting I/O to offline device
2005/06/24 22:41:35; 03; src@helios.next; kern; err; Buffer I/O error on device dm-0, logical block 879876
2005/06/24 22:41:35; 03; src@helios.next; kern; err; Buffer I/O error on device dm-0, logical block 879877
2005/06/24 22:41:35; 02; src@helios.next; kern; crit; REISERFS: abort (device dm-0): Journal write error in flush_commit_list
2005/06/24 22:41:35; 02; src@helios.next; kern; crit; REISERFS: Aborting journal for filesystem on dm-0
2005/06/24 22:41:35; 03; src@helios.next; kern; err; scsi0 (9:0): rejecting I/O to offline device
2005/06/24 22:41:35; 04; src@helios.next; kern; warning; lost page write due to I/O error on dm-0 |
plus tons more messages produced by reiserfs, all in kern/warning level...
unmounted filesystem, run reiserfsck, mounted it back and no problems...
same scenario on ext3 and by-by data...
but like i said - grsec really helps... |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|