Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed
On 20/4/21 4:14 am, Philip Webb wrote: > 210419 Roy Bamford wrote: >> Its my 18th anniversary of installing Gentoo. > You beat me by 6 mth . I had recently built my 2nd machine > & had been using Mandrake in the 1st, but they were slow with their release. > I tried Suse + Slackware, but couldn't get them set up properly, > so I thought I might as well try that new thing people were talking about. > I followed the install instructions faithfully, booted > & found myself with a working version of Gentoo ! I've never looked back. > >> A number of coincidences gave rise to my original liveCD turning up >> when I was searching for bits to get an old system to boot >> just one more time to get some forgotten data off its hard drives. >> I just had to try it out. > I still have the original CDs for Mandrake from 2000, my 1st Linux, > but I've never tried installing them again anywhere. > I am a little earlier with gentoo - but unfortunately I don't have any media/machines from that era - great project! I started with Redhat 4.0 sometime in the late 90's. BillK On Sat, 2002-06-01 at 19:16, gentoo-user-requ...@gentoo.org wrote: > gentoo-user -- confirmation of subscription -- request 939282 > > We have received a request from
[gentoo-dev] radeon video card
Hi all, How can I check that the microcode is being loaded by a radeon HD5770 graphics card? I have used "https://wiki.gentoo.org/wiki/Radeon"; to set it up, but there is nothing in dmesg about loading the firmware like you see with the cpu microcode - the card works without the firmware compiled in, or in the initramfs (or finds it after these stages - cant tell) Can someone confirm that as its a PCI-E card, I don't need the kernel AGPGART to be enabled? BillK
Re: [gentoo-dev] zoom concerns
And I would like to add that sometimes you don't have a choice - if someone who is paying you says to use zoom, there is no choice - but I would rather use gentoo than fire up the MS laptop.. What gentoo can do is mitigate the risk - which I need to look into to see whats done in the ebuild over a default install of their binary.. William K. On 2/4/20 8:53 am, Alec Warner wrote: On Wed, Apr 1, 2020 at 5:18 PM Alessandro Barbieri mailto:lssndrbarbi...@gmail.com>> wrote: I have concerns about the inclusion of zoom in ::gentoo. For me it's more like a malware. From the hacker news feed you'll find out that: [1] zero day vulnerability found [2] passwords are truncated to 32 bit [3] previously sent data to facebook [4] end to end traffic isn't encrypted [5] signed binary run unsigned script [1], [2], [5] all seem like bugs and I'd expect upstream to fix at least [1] and [5]. Note that in Gentoo [3] isn't directly relevant (this isn't iOS) and neither is [5] in most cases as people don't run signed binaries or use any kind of binary whitelisting in Gentoo. [2] I think the article mentions the truncation is to 32 bytes (or '32 chars', but I assume each char is 1 byte for entropy sake.); not 32 bits. Most password fields have a length limit (you cannot accept arbitrary long passwords. If 32 characters isn't enough length to protect users then the passwords are going to be useless anyway; most user passwords are significantly less than 32 characters. This is significantly different than limited to '32 bits' (which is 4 characters!) and would make brute forcing passwords an obvious breeze; there is not sufficient entropy in 32 bits to protect users. [4] I agree the poor marketing is a problem. I think as Rich states later in the thread it's possible we could provide more information here. As he notes though, I'm not convinced this is reason not to package the software in Gentoo from a policy perspective. In general I expect that as long as Zoom has a gentoo maintainer and upstream actually resolves outstanding security issues; I'm not really aware of any policy hurdles they need to overcome to stay packaged in Gentoo. Currently it has three maintainers[6]. If it sucks, convince them to stop maintaining it ;) -A 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1 2 https://news.ycombinator.com/item?id=22749706 3 https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/ 5 https://news.ycombinator.com/item?id=22746764 [6] https://packages.gentoo.org/packages/net-im/zoom
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, 2012-07-24 at 07:20 -0400, Rich Freeman wrote: > On Tue, Jul 24, 2012 at 7:07 AM, Fabian Groffen wrote: > > I don't know about general consensus. In my opinion, it's plain spam to > > existing users. (And that would IMO be the xth news item in a row to be > > spam.) > > Can't say I agree here. Some news items have been more useful than > others, but I doubt the typical Gentoo user (who does not subscribe to > -dev) would think that many of the past messages have been spam. > > Right now news is our only mechanism to warn users that something is > about to happen BEFORE it happens. Anytime I talk to somebody who has > left Gentoo the #1 thing I tend to hear is that they were tired of > things just breaking without warning. Even following -dev I've been > surprised by the odd upgrade - I can imagine the typical user would be > even more confused. > > Long-time Gentoo users aren't going to notice in the handbook that the > location of /etc/make.conf has moved - I know that if I'm doing an > install I tend to use the handbook as a checklist but I skim through > it so fast that I doubt I'd notice a big change. They're going to > appreciate a heads-up. The only people who wouldn't consider it news > are those following this list, and judging by the state of this thread > you'll already have read 40 posts on the topic, so the 41st won't be > that big of a deal. > > Rich > Apologies for butting in as a user: As a user of Gentoo from about 2002 or so, with multiple gentoo systems, this thread is the first I have heard of make.conf moving ... cant imagine I am the only one! and are you about to break our systems unannounced (again) ? - its not spam to give us a heads up, even if its just reassurance. Sorry, but I would rather know. BillK
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Fri, 2012-02-24 at 22:44 -0500, Mike Gilbert wrote: > On Fri, Feb 24, 2012 at 7:31 PM, Richard Yao wrote: > >> Am I the only paranoid person who moves them rather than unlinking > >> them? Oh, if only btrfs were stable... > > > > Is this a reference to snapshots? You can use ZFS for those. The > > kernel modules are only available in the form of ebuilds right > > now, but they your data should be safe unless you go out of your way > > to break things (e.g. putting the ZIL/SLOG on a tmpfs). Alternatively, > > there is XFS, which I believe also supports snapshots. > > > > I've been using btrfs exclusively for about 6 months, and I don't > *think* I've lost anything... :) > I did ... tried it out and found it "tougher" than reiserfs to break which is saying something considering how flaky extended 2/3 proved for the same task. Problem was, once it broke you couldnt fix it :( Also there are some things that dont work, one of which was a few packages would always fail to emerge when using btrfs for temp storage (I think one was libreoffice) So I deleted the btrfs partitions and put reiserfs back ... BillK
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
As a user who has done this on a number of systems - its no sweat. Also, check some of the older guides for upgrading from gcc-2.95 to 3, and 3.0 to 3.1 - should still be around somewhere. Its been done before, more than once - ask some of the older devs whove been around since the early days(!). Traps this time were uninstalling 3.3.6 without installing the sys-libs/libstdc++-v3 first. Ive put off removing 3.3.6 from the other systems until I get the nerve up again. So as well as instructions to do the task, some rescue for common mistakes like this would be nice. BillK On Tue, 2005-11-29 at 08:50 -0500, Curtis Napier wrote: > Speaking as a user who upgraded from 3.3.x to 3.4.x a loong lng > time ago and also as a forum mod who sees questins about this on a daily > basis: > > Users are more or less aware that they will have to rebuild the entire > world including the kernel when they upgrade gcc. If they aren't already > aware of it they soon learn that it is necessary and they aren't averse > to it. This is a from source distro afterall, so TELLING them in an > upgrade guide that they *HAVE* to do this wouldn't be such a bad thing. > It solves 99% of all the problems reported in a gcc upgrade for people > who *didn't* do an "emerge -e world". > > Doing it from the outset will save the forums and bugs a lot of stress > and heartache that could have been easily avoided. > > Just my 2 $DENOMINATION's -- William Kenworthy <[EMAIL PROTECTED]> Home! -- gentoo-dev@gentoo.org mailing list
