Re: Local users get to play root?
On 11/18/09 12:03, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Well, then we're violently agreeing about the same thing. Anyway. It doesn't look like this is a change in Fedora policy, because it clearly caught everyone off-guard. Looks like PK developer made an executive decision and it's up to us to either issue an update to revert to the previous behaviour, or to continue debating whether allowing local console users to install trusted software from trusted repositories is a sane security trade-off. I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On 09/25/09 12:37, Deji Akingunola wrote: On Fri, Sep 25, 2009 at 1:10 PM, Christoph Frieben christoph.frie...@googlemail.com wrote: 2009/9/25 Chris Adams: (Likewise, the default x86_64 package is currently called atlas [ atlas-sse3 ... ] and is using SSE2 by default as expected for all x86_64 packages. Higher Actually the atlas x86_64 package is using SSE3 by default. I believe SSE3 is the least common denominator for the x86_64 cpus. And yes, whatever is determined for the x86_32 situation will also apply for SSE4* for x86_64. Deji My Athlon(tm) 64 X2 Dual Core Processor 3600+ (running x86_64) isn't showing SSE3; From /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch Unless the 3dnow extensions are equivalent to SSE3, it looks like SSE2 is the least common denominator for the x86_64 cpus. -Bob -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Graphics Test Week (ATI, NVIDIA and Intel graphics Test Days)
On 09/09/09 07:17, mike cloaked wrote: Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1). I have been trying to follow the procedure to get the liveusb key to boot - but changing the kernel line to either of root=live:LABEL=F12-Snap1-i686-Live to: root=live:LABEL=F12-i686 or to LABEL=LIVE won't work for me! I have seen both the bz reports at https://bugzilla.redhat.com/show_bug.cgi?id=520207 and https://bugzilla.redhat.com/show_bug.cgi?id=521471 The boot gets to the stage where the white/blue line goes across the page but the screen then shows No root device found. Boot has failed, sleeping forever - the advertised method for fixing this fails for me - is there any other suggested work-around? Thanks -- mike Try using /sbin/dosfslabel or /sbin/e2label to read the actual label. Then use that for the label on the boot line. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Snapshot Label bug (was Graphics Test Week)
On 09/09/09 08:17, mike cloaked wrote: Bob Arendt wrote: Try using /sbin/dosfslabel or /sbin/e2label to read the actual label. Then use that for the label on the boot line. Bingo! That works - excellent - I think I will add this to the reference page - others will doubtless be bitten by this also. Now I hope I can test later this evening mike Glad it helped. I tried out the Snapshot 1 liveusb, and was puzzled when it didn't work; My original post to those bugs was based on /sbin/dosfslabel (it was a vfat stick). I'm curious - what *was* the label reported? How did you create your live boot? I'd used the livecd-iso-to-disk tool, latest F11 version to put the live iso's on to a USB stick .. and ended up with labels F12-i686 and F12-x86_64. Some tool somewhere is mucking this up. I don't know if it's the .iso creation on the fedoraproject side, or the livecd-iso-to-disk from the livecd-tools package (or some sort of tool inconsistency). -Bob Arendt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On 06/17/2009 03:00 PM, Richard W.M. Jones wrote: On Wed, Jun 17, 2009 at 01:52:26PM -0400, Bill Nottingham wrote: - Build all packages for i686 (this requires cmov) This cuts out AMD Geode ... and for what ... P4 2.4Ghz Athlon 3400+Core2Duo E6850 Atom N270 march=i686/ -1.1% +2.0% +0.9% +0.6% mtune=generic march=i586/ +0.3% -0.3% -0.2% +1.3% mtune=atom march=i686/ -1.5% +1.2% +0.5% +1.7% mtune=atom This just doesn't look worthwhile at all. My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature. Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Agreeing with Rich, what does this buy us? Being generous, 1.7% means you shaved 1 second off a 1 minute mp3 encode. Perhaps measurement accuracy is on the order of 0.5%? And the P4 performance degrades; Why further cripple the slower chip? This slight benefit doesn't seem worth the effort of re-doing the build infrastructure and dropping/alienating older chip architectures. -Bob Arendt -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
