Jump to content
funtoo forums

nrc

Members
  • Content Count

    68
  • Joined

  • Last visited

  • Days Won

    18

nrc last won the day on May 2

nrc had the most liked content!

1 Follower

About nrc

  • Rank
    Advanced Member

Personal

  • Location
    Columbus, Ohio, USA

Recent Profile Visitors

703 profile views
  1. nrc

    1.4 stages

    Any special upgrade considerations for installs launched from the AWS AMI?
  2. Maybe a library mismatch? Have you done a full update with dependencies? emerge -auvDN @world Do you have any preserved packages? emerge -av @preserved-rebuild
  3. I'm with you on the systemd issue. But isn't Gentoo without systemd still an option? Are you resistant to it because they support systemd at all or because you sense that they're slipping in that direction? I never used Gentoo so I don't have an informed opinion on it. I came straight to Funtoo from Fedora/Redhat because Funtoo was one of the few distros that seemed to recognize the importance of maintaining a viable Linux ecosystem apart from systemd. My impression from being downstream of Gentoo is that they've become less stable recently. It was starting to feel like a trend. Creating a new release process where stability can be maintained in spite of a much smaller developer community seems like a good step for Funtoo. I think it could be communicated and rolled out a bit more smoothly at times, but I'm excited about the progress.
  4. Where is this the case? Looking at stable releases it appears that Funtoo is ahead of Ubuntu in pretty much all instances. The key question about his new model is whether they will be able to rev it on the schedule that @drobbins has suggested and whether those updates can run as smoothly as your typical emerge. If that can be successful then I don't think there will be any problem with the freshness of the releases.
  5. That's true. It's neither a rolling release or a traditional fixed released distro now. It's changing and we won't know exactly what it will become until it gets there. I think you have to kind of review what @drobbins has said about his objectives for the distro and decide if you want to go in that direction or just stick with a rolling release.
  6. There are a fair number of downgrades when moving to 1.3. 1.2 updates continued after 1.3 was frozen. Chrome and Vivaldi were the only things that were actually an issue to downgrade because they nagged about profile version mismatches. I also had a good number of dependency knots that I had to untangle. In some cases I just ended up unmerging packages that were creating major dependency issues and then reinstalling them once the upgrade was complete.
  7. Thanks. I hadn't realized that "PasswordAuthentication" doesn't affect PAM authentication. I've always secured my machines by only allowing ssh access to accounts that I specifically configure. It's @drobbins call but I still think it's a bad idea to configure ssh by default on machines where novice users may believe that their physical console is the only vector for someone to attack their trivial password. There definitely should be some documentation in the install procedure for locking that down.
  8. @drobbins nixed the sshd suggestion in FL-6294, but I looked at the latest baselayout and it looks like the default configuration has PasswordAuthentication set to "no" which should minimize any risk. I still think it's better not to have this running if it's not needed or specifically wanted. My build process always includes setting openssh the configuration according to my standards but there's some risk there for the unaware if openssh is compromised.
  9. I agree that the status of the different releases should be better documented. Updates to 1.2 just kind of ended. The 1.3 release was communicated but if it was discussed how that would impact 1.2 then it was easily missed. One thing that should be clearly laid out is that part of the objective (as I understand it) is to minimize all the firefighting that occurs in a rolling release so that devs can focus on advancing the platform. That's a good idea in theory, but can you put off all that firefighting and still maintain a release schedule that keeps things fresh? And what is the standard for what will be updated outside of the normal release cycle? There should be a documented standard for security issues - something like CVE >5 gets rolled out immediately, everything else waits until the next point release.
  10. It seems to me that metalog and sshd defaults should depend on what flavor you're installing. A desktop flavor shouldn't have either by default while a server flavor should have metalog. I'd say that neither should have sshd by default unless you have the amazon-ec2 or some kind of "headless" mix-in. Funtoo hasn't used `eselect news` since probably 2015. I think the problem was managing news in too many different places. Originally the intent was to put them on a wiki News page but that appears abandoned. The News and Announcements forum here seems to be the best source. It looks like if you hit follow at the top of forum you can get an email notification of news items. Funtoo has gone from being just a slightly different spin on Gentoo to something really unique among distros. I think that's great. I'm happy with what I understand of the new direction. I enjoy the fact that we're not saddled with systemd and that customization is virtually limitless, but the "rolling release" model means that you can never truly have a stable system. On a regular basis something gets rolled in that breaks things badly and you are forced to drop everything and fix it right now to get a working system again. If this new stepping release model provides a more stable system that is still more flexible and current than your typical binary release, I think it will be a win. The key will be keeping updates coming on a regular basis. @drobbins launched Funtoo to work on new directions for Gentoo without dealing with the mess that Gentoo had become. Whether or not Funtoo is the right distro for someone probably depends on how closely your goals for a distro align with his. As I read his comments and see the direction of progress I'm on board. But part of the mess that Gentoo had become was lack of communication between developers and the user base, so I think your criticism of some of the communication gaps is fair.
  11. Looking at the updates in Jira, it looks like things are moving along. My latest update pulled in nvidia-cuda-toolkit and some other nvidia related packages that are required to make nvidia-docker work. nvidia-docker is in the tree. I'm not sure if we're waiting on much more than testing and documentation.
  12. It's quiet.... Too quiet. There was some comment about this in Jira as well: https://bugs.funtoo.org/browse/FL-6219 I think it will be a good thing as long as the schedule can remain at least quarterly and upgrades are reasonably painless. I'm thinking/hoping that 1.2/1.3 were the exceptions because they represented some substantial changes in the underpinnings. Rolling releases are a mixed blessing. We're all trained to pull the lever to get the next food pellet. Most of the time it's nothing useful and sometimes it creates a lot of pain by breaking things. If we can keep things fresh and avoid the breakage while freeing up the development team to create more cool Funtoo stuff then I think it will be a win.
  13. I think I'm past this. Identified texinfo as the package with the MiscXS library and it does have a perl module attached. Did an `emerge --nodeps texinfo` to update that and now I'm rolling again. Not sure why perl-cleaner didn't catch that. Sometimes solutions just require a little sleep.
  14. Upgrading to 1.3. When running `emerge -auDN @system --ignore-world` I get a failure building automake. MiscXS.c: loadable library and perl binaries are mismatched (got handshake key 0xd600000, needed 0xd880000) make: *** [Makefile:2518: doc/automake.info] Error 1 * ERROR: sys-devel/automake-1.15.1-r2::core-kit failed (install phase): * emake failed I may have screwed things up. I originally got through this step and then had to aggressively clean up packages to clear conflicts in the world build. Eventually I got this same error building gpm. So I went back and ran perl-cleaner with --reallyall and now I get the error on automake in the @system build. build.log emerge.pkg emerge.info
  15. I'm just glad that we have this awesome distro to avoid all that garbage. Thanks to everyone who contributes!
×
×
  • Create New...