From Fedora Project Wiki
---nirik has changed the topic to: Fedora IRC Classroom Fedora 11 Features with your teacher Jon Stanley ( jds2001 ) - See Classroom for tonights class schedule. | Feb 07 04:16 | |
-->XanThaOs (n=sacredde@71-90-228-054.dhcp.gnvl.sc.charter.com) has joined #fedora-classroom | Feb 07 04:16 | |
-->jzhou (n=jzhou@pcp061561pcs.unl.edu) has joined #fedora-classroom | Feb 07 04:16 | |
-->Dr_willis (n=willis@c-67-163-55-207.hsd1.il.comcast.net) has joined #fedora-classroom | Feb 07 04:16 | |
jds2001 | alright, sorry about that delay | Feb 07 04:16 |
---|---|---|
brunowolff | I think yum info will tell you that as long as the packname is unique across repos. | Feb 07 04:16 |
-->tw2113 (n=tw2113@fedora/tw2113) has joined #fedora-classroom | Feb 07 04:17 | |
nirik | fenris02: thats a tough one. gpg key that it's signed by? ;) | Feb 07 04:17 |
nirik | anyhow, jds2001: take it away! | Feb 07 04:17 |
-->joropo (n=joropo@64.89.242.56) has joined #fedora-classroom | Feb 07 04:17 | |
jds2001 | so this came from a requested class, but I'm not sure what folks wanted. | Feb 07 04:17 |
nirik | rtnpro_: http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html | Feb 07 04:18 |
-->mwilson (i=foobar@ip68-101-143-117.sd.sd.cox.net) has joined #fedora-classroom | Feb 07 04:18 | |
rtnpro_ | nirik, thank you | Feb 07 04:18 |
jds2001 | I'm Jon Stanley, current chair of the Fedora Engineering Steering Committee. We handle the "Feature Process", which is the process by which new features get accepted into Fedora. | Feb 07 04:18 |
fenris02 | nirik, crumb. that was my answer too. Thanks :) | Feb 07 04:18 |
-->openpercept (n=openperc@unaffiliated/openpercept) has joined #fedora-classroom | Feb 07 04:19 | |
-->Guest456 (i=KVIrc@c80-216-141-34.bredband.comhem.se) has joined #Fedora-Classroom | Feb 07 04:19 | |
jds2001 | The current list of features is at Releases/11/FeatureList | Feb 07 04:19 |
jds2001 | there are a few that I'd like to hit on that are going to be major ones for F11. | Feb 07 04:19 |
jds2001 | first, on new installs, our default filesystem is likely to be ext4 | Feb 07 04:20 |
jds2001 | we're currently on the lookout for data corruption/stability bugs and are going to revisit this in about a month. | Feb 07 04:20 |
jds2001 | however I think it's somewhat safe to say it's in. | Feb 07 04:21 |
jds2001 | It is no longer experimental upstream, either. | Feb 07 04:21 |
jds2001 | Another one is presto | Feb 07 04:22 |
aTypical | Sorry, do we question as you go or wait until the end? | Feb 07 04:22 |
jds2001 | jump right in, i have no clue what folks want :) | Feb 07 04:22 |
jds2001 | very interacrive is my style :) | Feb 07 04:22 |
aTypical | How did ext4 get the nod? Is it ready? | Feb 07 04:23 |
jds2001 | we believe so. This testing period is critical for determining that. | Feb 07 04:23 |
che | aTypical, there was a session in fedora-qa recently | Feb 07 04:23 |
jds2001 | yeah, there was an actual test day on it, I guess i'll bring those up too. | Feb 07 04:24 |
jds2001 | QA/Test_Days/F11 is the schedule for "test days" | Feb 07 04:24 |
brunowolff | How are kernel updates going to work for 586/686? | Feb 07 04:24 |
mwilson | EXT4 has a working fsck? | Feb 07 04:25 |
brunowolff | Is something going to switch us automatically? | Feb 07 04:25 |
jds2001 | these are days of very focused QA | Feb 07 04:25 |
jds2001 | brunowolff: nope, fresh installs only | Feb 07 04:25 |
jds2001 | mwilson: yes, e4fsprogs exists. | Feb 07 04:25 |
nirik | mwilson: yes | Feb 07 04:25 |
<--openpercept (n=openperc@unaffiliated/openpercept) has left #fedora-classroom | Feb 07 04:25 | |
brunowolff | The latest rawhide kernel doesn't even have a 686 arch version. | Feb 07 04:25 |
jds2001 | brunowolff: really? | Feb 07 04:26 |
-->cuga (i=cuga@CPE00080232ec3b-CM0012c92137d6.cpe.net.cable.rogers.com) has joined #fedora-classroom | Feb 07 04:26 | |
jds2001 | must be some build failure. | Feb 07 04:26 |
<--yunustj_afk has quit (Read error: 110 (Connection timed out)) | Feb 07 04:26 | |
nirik | no, thats right... you want the PAE one. | Feb 07 04:26 |
jds2001 | so while we're on that topic, we're also changing what architectures we support and default compiler flags. | Feb 07 04:26 |
nirik | or the i586 one. | Feb 07 04:26 |
mwilson | This isn't like reiser always supposedly had a working fsck, except all it did was eat the data, I hope. No one else I've heard has committed to distributing on EXT4. | Feb 07 04:26 |
jds2001 | oh, OK. | Feb 07 04:26 |
brunowolff | I don't think my home machine supports PAE, so I probably want the 586 one? | Feb 07 04:27 |
nirik | brunowolff: what is it? look up it's specs. Likely it does support PAE. :) | Feb 07 04:27 |
jds2001 | if it's recent, I'm sure it does. | Feb 07 04:28 |
jds2001 | what processor have you got? | Feb 07 04:28 |
brunowolff | Its a 2 cpu athlon tbird. | Feb 07 04:28 |
Falstius | jds2001: what are they changing to? | Feb 07 04:28 |
jds2001 | Falstius: the specific compiler flags, im not sure | Feb 07 04:28 |
brunowolff | I'll be able to test it after I get home, as I have the rawhide updates with me. | Feb 07 04:28 |
jds2001 | but we're switching the target arch from i386 to i586 | Feb 07 04:29 |
Falstius | ok | Feb 07 04:29 |
jds2001 | so we pick up some new instructions that leads to more effeciencies. | Feb 07 04:29 |
<--jzhou has quit ("Leaving") | Feb 07 04:29 | |
jds2001 | along those same lines, we'll be installing an x86_64 kernel on 32-bit installs if the processor supports it. | Feb 07 04:29 |
Falstius | what about support for atom? (I know gcc isn't really optimized yet) | Feb 07 04:30 |
mwilson | What about user-space? | Feb 07 04:30 |
jds2001 | mwilson: userspace would still be 32-bit | Feb 07 04:30 |
brunowolff | Does /proc/cpuinfo show that info? Maybe in address size? | Feb 07 04:30 |
jds2001 | but you win from the kernel being x86_64 even. | Feb 07 04:30 |
Falstius | interesting | Feb 07 04:31 |
jds2001 | the biggest win there is the elimination of the highmem/lowmem split. | Feb 07 04:31 |
mwilson | Is that going to be a Fedora-ism, or is running a 64-bit kernel and a 32-bit userspace a normal thing? | Feb 07 04:31 |
rtnpro_ | jds2001, ! | Feb 07 04:32 |
jds2001 | I'm not actually sure, I've not looked at what other distros are doing. | Feb 07 04:32 |
jds2001 | rtnpro_: go ahead, no need for that with me :) | Feb 07 04:32 |
fenris02 | jds2001, after years of sticking to i386 set, why switch now? | Feb 07 04:33 |
jds2001 | mwilson: but even if it's a Fedora-ism, it still makes sense. | Feb 07 04:33 |
rtnpro_ | jds2001, Does that mean that with the x86_64 kernel, the kernel processes will be faster and again retain the compatibility with 32-bit applications? | Feb 07 04:33 |
jds2001 | rtnpro_: not really faster, but compatibility is retained. | Feb 07 04:34 |
mwilson | I meant in the sense of is Fedora implementing some sort of thunking layer? I always thought the kernel and user space had to match, other than compatability bits. | Feb 07 04:34 |
rtnpro_ | rtnpro, ok | Feb 07 04:34 |
nirik | fenris02: newer gcc, some more gains. Also, less really really old hardware around. | Feb 07 04:35 |
jds2001 | mwilson: not necessarily - we're not implementing anything new here other than installing an x86_64 kernel. | Feb 07 04:35 |
fenris02 | mwilson, 64-bit kernel, 32-bit userspace means that every app will be thunk'd (sp?) | Feb 07 04:35 |
mwilson | Fedora has never been about supporting old hardware. People using old hardware should be discouraged from running Fedora, their experience will not be optimal. | Feb 07 04:35 |
jds2001 | apps can exist at different spaces within the memory the kernel can address. | Feb 07 04:35 |
jds2001 | so even though a 32 bit app can only see 4GB, that could be from 3-7GB physical addressing. | Feb 07 04:36 |
jds2001 | oversimplifying, of course :D | Feb 07 04:36 |
mwilson | Can you talk about DeviceKit, and how Fedora plans to avoid another fiasco like PulseAudio? | Feb 07 04:36 |
<--rtnpro has quit (Read error: 113 (No route to host)) | Feb 07 04:37 | |
jds2001 | sure, DeviceKit is a replacement for a moribund hal. | Feb 07 04:37 |
fenris02 | mwilson, esd was along the same lines, but worse. PA is an improvement. | Feb 07 04:37 |
mwilson | OTOT, the bleeding edge is what it is. | Feb 07 04:37 |
jds2001 | it's not going to replace hal immediately | Feb 07 04:37 |
mwilson | Except PA was nowhere near ready, but it was made the default anyway. | Feb 07 04:38 |
*jds2001 isn't really a desktop guy himself, so I'm a little out of my domain of expertise with DeviceKit. | Feb 07 04:39 | |
<--XanThaOs has quit (".::The Reborn Of Evil Spirits::. €ZoMBiE€ Sc®ïþt 2.2 .ßý. xom[b] .::[1]::.") | Feb 07 04:39 | |
mwilson | Something like HAL is a little more essential to the proper working of the machine, these days. | Feb 07 04:39 |
jds2001 | but I believe it's aim is to *eventually* replace hal. Rome wasn't built in a day, however. | Feb 07 04:39 |
fenris02 | jds2001, any plans to revamp /etc/init.d/* items to use upstart scripts directly? | Feb 07 04:40 |
jds2001 | right now, aiui, it's handling disk devices only | Feb 07 04:40 |
jds2001 | fenris02: i think that's blocking on essentially a rewrite of upstart. | Feb 07 04:41 |
<--tw2113 (n=tw2113@fedora/tw2113) has left #fedora-classroom ("There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.") | Feb 07 04:41 | |
jds2001 | nirik: am i remembering wrong here? | Feb 07 04:41 |
mwilson | Ubuntu isn't still trying to emulate SysV, are they? | Feb 07 04:41 |
nirik | yeah, I don't think devicekit is going to replace hal yet... perhaps next cycle if it's ready. | Feb 07 04:41 |
nirik | mwilson: they do as far as I know. | Feb 07 04:41 |
nirik | there is work on a upstart re-write going on. No idea where it is tho. | Feb 07 04:42 |
mwilson | This 20 second startup thing sounds like there's upstart work being done in Fedora. | Feb 07 04:42 |
fenris02 | will readahead be tuned such that it pulls more than 4k by default? :) | Feb 07 04:42 |
jds2001 | actually I thought that too. There's no real upstart work involved there. | Feb 07 04:43 |
jds2001 | fenris02: no idea :) | Feb 07 04:43 |
nirik | see http://screwyouenterpriseedition.blogspot.com/ for info on the upstart re-write. I don't think there will be any move to switch sysvinit scripts until thats done and ready. | Feb 07 04:44 |
jds2001 | one other feature i wanted to touch on is presto. | Feb 07 04:45 |
jds2001 | as nirik mentioned in his yum talk, there's been a yum plugin to support deltarpm's for a good time now. | Feb 07 04:46 |
jds2001 | but we lacked bodhi/mash/createrepo support for it. | Feb 07 04:46 |
mwilson | presto's been talked about since F7. | Feb 07 04:47 |
jds2001 | seth made it so it's a simple flag to createrepo now, so almost no bodhi changes are needed. | Feb 07 04:47 |
jds2001 | mwilson: yep, and it's well on it's way to being an official reality I think :) | Feb 07 04:47 |
jds2001 | oh, and one more thing worthy or note | Feb 07 04:50 |
jds2001 | the text UI in anaconda is being reworked. | Feb 07 04:50 |
jds2001 | NO. it's not going away as you may have heard. | Feb 07 04:50 |
jds2001 | but it will have less functionality, and become the truly minimal install experience that folks have asked for. | Feb 07 04:51 |
fenris02 | suitable for server installs? (ie: no xorg, no bluez, ...) | Feb 07 04:52 |
jds2001 | we even more strongly urge folks to use VNC or xdriver=vesa now. | Feb 07 04:52 |
mwilson | Fedora isn't suitable for servers no matter what the installer looks like. | Feb 07 04:52 |
fenris02 | mwilson, not the point. (thinking more about el6 actually) | Feb 07 04:52 |
jds2001 | fenris02: not sure, but aiui, you'll be able to get new packages, and that's about it. | Feb 07 04:52 |
jds2001 | i've actuallly not done a text install since the anaconda changes landed. | Feb 07 04:53 |
mwilson | It sounded for a while like Fedora was going to take away text, period. Who was that, Nottingham? I guess that argument was lost. | Feb 07 04:54 |
<--franciscod_ has quit ("leaving") | Feb 07 04:54 | |
<--francisc1d_ has quit ("leaving") | Feb 07 04:54 | |
fenris02 | "blockdev --getra /dev/mapper/*" - default is 256. changing this to something larger (like 4096) increases perf from say 140MB/s to 320. ymmv of course. (Hence the earlier question, but I had to find the details) | Feb 07 04:54 |
-->franciscod (n=Ankur@122.172.7.162) has joined #fedora-classroom | Feb 07 04:54 | |
mwilson | Is that number real? How do you get 320 out of real disk hardware? | Feb 07 04:55 |
fenris02 | mwilson, it's real. | Feb 07 04:55 |
fenris02 | mwilson, software-raid5 | Feb 07 04:55 |
nirik | fenris02: I saw those bugs... I don't see it here on my rawhide machine, but don't know if it was fixed or something about the way I installed changed it. | Feb 07 04:55 |
mwilson | Is LVM going to still be the default, or will Fedora *finally* move away from that? | Feb 07 04:56 |
fenris02 | mwilson, is there something better around? | Feb 07 04:56 |
mwilson | There's no *reason*, most of the time. | Feb 07 04:57 |
jds2001 | really? | Feb 07 04:57 |
fenris02 | mwilson, resize and snapshots | Feb 07 04:57 |
jds2001 | i like LVM | Feb 07 04:57 |
mwilson | Let's make a LVM, just so we can make one slice inside it. | Feb 07 04:57 |
jds2001 | LVM will always be the default, im sure. | Feb 07 04:57 |
nirik | there was talk of it, but it has not gotten to fesco yet. ;) http://fedoraproject.org/wiki/Features/NoDefaultLVM | Feb 07 04:57 |
<--che has quit ("Verlassend") | Feb 07 04:57 | |
mwilson | Complexity for the sake of complexity is never good. | Feb 07 04:57 |
*jds2001 is somewhat opposed to that. | Feb 07 04:58 | |
nirik | it may go away when btrfs comes in too tho, as it has a lot of lvm functionality already built in. | Feb 07 04:58 |
mwilson | Most people don't resize and snapshots are like backups, no one does. | Feb 07 04:58 |
jds2001 | you can do stuff with root on LVM that you can't do otherwise. | Feb 07 04:58 |
mwilson | But are they things that need doing? | Feb 07 04:58 |
fenris02 | elevator/deadline/none iosched tuning would be fitting too. that should be determined by hardware type. (none for flash media for ex) | Feb 07 04:58 |
*nirik notes that crypt is done via dm-crypt, so it kinda needs lvm | Feb 07 04:59 | |
fenris02 | mwilson, snapshots for backups are absolutely *awesome*. You have a point though. However, I'd disagree with making defaults change just because users are lazy | Feb 07 05:00 |
fenris02 | nirik, just dm-crypt can be done w/o lvm, no? | Feb 07 05:00 |
nirik | not sure, it may be able to... | Feb 07 05:00 |
jds2001 | yeah, you can encrypt physical devices | Feb 07 05:01 |
mwilson | fenris02: No, there's something someone should propose. Take all these pseudo-TimeMachine-like things and actually roll them into a distribution. Make backups easy enough that it's harder NOT to do it, than to do it. | Feb 07 05:01 |
kaos01 | i thing lvm sesize is extremely usefull | Feb 07 05:01 |
jds2001 | that's the default if you select encryption actually - it encrypts your partition that the rootvg is on. | Feb 07 05:01 |
mwilson | Resize is a non-starter for most everyone. | Feb 07 05:01 |
fenris02 | mwilson, good point. have any suggestions how? | Feb 07 05:01 |
brunowolff | I run dm-crypt over md raid and no lvm on my systems. | Feb 07 05:02 |
jds2001 | oh, and one more change that there is. | Feb 07 05:02 |
fenris02 | resize is "hard" because decent gui tools are non-existant | Feb 07 05:02 |
jds2001 | the anaconda-created volume group is now named for the hostname of the machine. | Feb 07 05:02 |
jds2001 | rather than VolGroup00 | Feb 07 05:02 |
fenris02 | VG-host/LV-slice ? | Feb 07 05:02 |
nirik | jds2001: excellent. | Feb 07 05:02 |
mwilson | Yes, but making it easier to break the box isn't on, either. Wrap this shiny GUI around it, everyone thinks they can do it, until they hose it, and don't have a backup of it. | Feb 07 05:03 |
jds2001 | which is great, since moving drives from machine to machine is easier. | Feb 07 05:03 |
mwilson | Some things should still be hard. | Feb 07 05:03 |
fenris02 | having two drives with VolGroup00 is "entertaining" | Feb 07 05:03 |
nirik | just like two with 'LABEL=/' :) | Feb 07 05:03 |
fenris02 | very much like that | Feb 07 05:03 |
mwilson | One of these days I'm going to look at the LVM toolchain enough to learn how to change that VoLGroup00 name to what I want it to be. | Feb 07 05:04 |
<--franciscod has quit ("leaving") | Feb 07 05:04 | |
jds2001 | mwilson: vgrename | Feb 07 05:05 |
mwilson | fenris02: In answer to your question, no, I don't know how. I do it with rsync and a script. But someone can wrap a GUI around the concept and make it easy enough to use. Ubuntu tried, but it went nowhere. | Feb 07 05:06 |
fenris02 | mwilson, mdns + rdiff-backup should work, but needs a wrapper | Feb 07 05:06 |
mwilson | Why does mdns need to be a part of it? | Feb 07 05:06 |
fenris02 | mwilson, make it work automagically | Feb 07 05:07 |
mwilson | Complexity for complexity's sake again. | Feb 07 05:07 |
fenris02 | mwilson, how else would you propose a system perform automated backups w/o user intervention? | Feb 07 05:07 |
mwilson | You presume that most people would be doing it over a network, vice to another local device. | Feb 07 05:08 |
mwilson | I presume the reverse. | Feb 07 05:08 |
fenris02 | *nod* comparing with timemachine. | Feb 07 05:11 |
jds2001 | anyhow, anything else? | Feb 07 05:11 |
jds2001 | I think I'm almost out of time here. | Feb 07 05:11 |
<--TheFord has quit ("Leaving") | Feb 07 05:12 | |
mwilson | New python, but that's just, well, new python. | Feb 07 05:12 |
nirik | crashcatcher might be nice... we will see how it turns out. | Feb 07 05:12 |
jds2001 | yeah, and no idea when py3k will land - that will be the interesting one. | Feb 07 05:12 |
*jds2001 suspects not before F13 | Feb 07 05:13 | |
mwilson | Fedora can put as many bandaids on the bug process as they like, the main problem is bugzilla itself. | Feb 07 05:13 |
*nirik thought the main problem was not enough people to fix all bugs. | Feb 07 05:14 | |
jds2001 | well that's a little out of scope here, and we're out of time, but what else do you propose? | Feb 07 05:14 |
fenris02 | nirik, barely sufficient to sort out dups anyway. let alone EOL and NEEDSINFO | Feb 07 05:14 |
jds2001 | i think that's the case with anything, really. | Feb 07 05:15 |
nirik | yeah. | Feb 07 05:15 |
<--aTypical has quit ("Leaving") | Feb 07 05:15 | |
nirik | thanks for coming jds2001 ! | Feb 07 05:15 |
fenris02 | if bugcatcher can properly file them under the correct app - that alone is a perk. | Feb 07 05:15 |
jds2001 | np, look forward to coming back again! | Feb 07 05:16 |
mwilson | Bugzilla is opaque, always has been, hard to interface with. I always look at Debian's BTS as how you *should* do bugs. Make the bar as low as possible. The idea that you have to have a *login* to file a bug... | Feb 07 05:16 |
fenris02 | s/bugcatcher/crashcatcher/ | Feb 07 05:16 |
---nirik has changed the topic to: Fedora IRC Classroom - 15min break. Next class at 05:30UTC - see Classroom for schedule of tonights classes. | Feb 07 05:16 | |
mwilson | Anyway, old argument. | Feb 07 05:16 |
mwilson | Thanks for the informative meet. | Feb 07 05:16 |
fenris02 | thanks jds2001 | Feb 07 05:16 |
herlo | thanks jds2001 | Feb 07 05:17 |
nirik | yeah, and provide enough info to figure out whats going on... many bug reports lack info and reporters don't respond to fill them in. | Feb 07 05:17 |
inode0 | release lifecycle is not conducive to end user satisfaction with whatever bug processing gets done - they will always move on without getting bugs resolved | Feb 07 05:19 |
mwilson | Having more bugs filed is always preferable to no bugs getting filed. You can always close them. | Feb 07 05:22 |
<--KishanGoyal has quit (Read error: 60 (Operation timed out)) | Feb 07 05:22 | |
<--mwilson (i=foobar@ip68-101-143-117.sd.sd.cox.net) has left #fedora-classroom ("Leaving") | Feb 07 05:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!