paddymac

I recently set up a spare computer at my home to be a media server and so I can log in remotely via ssh. I have a dynamic DNS account set up so I don't have to know my IP address. Anyway, I turned on the monitor attached to it and saw that there had been a few apparently failed login attempts via ssh from a few IP addresses. I looked them up via Google, and they were from Canada, Vietnam, and China. It made me wonder if I ought to take some extra security measures since I have port 22, 80, 443, and 25565 currently exposed to the internet. Does anyone have any suggestions for measures I ought to take?

Some of the disadvantages I've found to the Ports system so far: 1. No support for running multiple emerges simultaneously. I tried to install gnome3 on FreeBSD, and one of the dependencies was TeX which required a 1.8 GB distfile. It took well over 20 minutes to download. So, in another Putty sesion (I was logged in over ssh from another box), I decided to install handbrake which also required TeX as a dependency. So the second session also began to download the same 1.8 GB distfile for TeX. When I realized what was happening, I cancelled the process with CTRL-C. I allowed the first sesion to proceed, and it gave no indication of a problem. 10 minutes later when the distfile was completely downloaded, it said the filesize didn't match what was expected because the only file it was was the second download which I cancelled after a few seconds. So it had to redownload the entire 1.8 GB distfile again. I asked in a FreeBSD users group on Facebook about this behavior because it was quite a surprise to me. I was essentially told "it's not a bug; it's a feature" and that I should simply avoid attempting multiple installations at once. After being accustomed to Portage's support for file locking and simultaneous emerges, this was quite a shock and a disappointment. 2. As Sandro pointed out, the clunkiness of configuring the system as a whole (making a uniform configuration for all the ports' compile options). It's a real downside compared to the simplicity of USE flags. 3. As far as I can tell, there is no support for additional overlays. I did find out about FreeBSD's Area 51, but this additional ports repository cannot be cleanly installed alongside the main ports tree. Rather (according to the directions I read on the Area 51 page) it has to be installed on top of the main ports tree which can cause issues with updating the ports tree. Some advantages of the Ports system 1. I do kind of like the pop-up configuration menus. It is simple and convenient when you want to fine-tune the settings of individual packages. It might actually be nice if Funtoo had such a menu system which would automatically update the package.use file. 2. If a compilation or installation fails, the issue can be resolved and the compilation/installation of the port can be resumed from the point of failure instead of starting over from the very beginning. It would really be nice if Portage had a feature like this! In fact, so far this seems to be the single biggest advantage I've found to the ports system. 3. Although the ports system seems to have a very simplistic and unintelligent dependency calculation, it is very fast -- no waiting. Portage can sometimes be very slow -- especially if numerous overlays are installed.

I think we all know that Portage was inspired by the BSD ports system and that Portage was intended to improve upon the ports system. But I don't think I've ever read anywhere exactly what those improvements are. Does anyone know, or has anyone written a good comparison of the two systems? I installed FreeBSD on a spare computer less than a week ago because I wanted to learn more about it, and at least some of the advantages of Portage became readily apparent. I'm beginning to wonder what other unpleasant surprises will show up with continued use of Ports. Sent from my SGH-M919 using Tapatalk

I have set up a cross compiler successfully in the past, but I've been having trouble lately myself. In fact, I recently had to downgrade crossdev to version 20140729 because I kept getting errors with the newest crossdev (see http://forums.gentoo.org/viewtopic-t-1003288-highlight-crossdev.html ). So that might be the first thing to try. If you still have problems after downgrading to a working crossdev, post the errors you're getting. In case you need it, here's the Funtoo crossdev guide: http://www.funtoo.org/Cross-compiling_with_Crossdev Oh, and in the interest of full disclosure, I'm currently using gcc ebuilds from the toolchain overlay and not the Funtoo-provided gcc ebuilds, so it's possible that any issues I may experience with gcc and/or crossdev may not be representative of what would occur if using all Funtoo-provided ebuilds. I started using the toolchain overlay primarily because the early Funtoo-specific gcc ebuilds omitted some features which I use (such as graphite), but those appear to have been added back. So I may switch back eventually.

In the years that I've been running a Gentoo-based system or Funtoo, I've often had a mismatch between kernel version and kernel-headers version and have never had a problem. Granted, the headers were usually an earlier version rather than newer, but still it shouldn't be an issue. If you ever do find an issue where a new package does cause problems, you can always file a bug about it and add the package to package.mask in the interim. When I first installed Funtoo, it took maybe a week or more, but that was mostly because 1) I was on dialup internet, and 2) I had a slow computer. Hitting circular dependencies was a bit annoying, but that generally only happens early on and if you've enabled a lot of use flags. If you're having a lot of issues, we'll do our best to help. Unfortunately there's not much we can do about upstream issues.

My current desktop is really showing its age. This fact really hit me when I was recently at a thrift store looking for books and maybe some old, cheap PC games and I found that the thrift store was selling two desktop PCs for $49 and $99 which were newer and more powerful than mine (they were assembled and turned on, so they were definitely in good condition). My current desktop has an A7S333 MB, ATI All-in-Wonder Radeon 9200, 1.5 GB RAM, a 500 GB PATA and 160 GB PATA drive. I'll leave out the other minor details, but that gives you an idea of what I'm working with. So obviously any modern machine - even a low-end one - will be better than this one. I want to keep it reasonably priced even though I might gaze longingly at high-end gaming rigs priced around $6000. I think realistically I'd like to keep it in the neighborhood of $500. I'm going to install Funtoo on it, though I still have a few WIndows apps that won't run well or at all under Wine, so I'd like to install Windows (probably my copy of XP or eventually ReactOS if it ever matures) into an emulator and be able to run that at a decent speed. I'm trying to plan for the long term, so I'm thinking that I should probably get a decent case, power supply, and high-end motherboard with plenty of room for future upgrades for RAM, CPU, video card, etc. and go with a reasonably priced CPU and video card and a decent amount of RAM. The likely scenario for my usage will be casual internet usage, occasional gaming (including some 3D FPS games and such), and some light multimedia work. So what would be a good motherboard to get that has a good track record of reliability (or even official support) under Linux? My old motherboard is buggy and so Linux doesn't support certain ACPI features like automatically powering off, and ASUS doesn't support Linux so they never fixed it. I'd like to not worry about such things with a new PC. What CPU? AMD or Intel? What video card? AMD or nVidia? I've seen several people in forums say nVidia runs cooler and quieter but AMD tends to be cheaper for the performance. And can anyone recommend some sort of multimedia card/device with good Linux support so I can watch TV (or even pick up radio) on the computer and hook up my camcorder to it to transfer audio/video? If there's anything I might have missed, please feel free to mention anything else I should consider. And if anyone has any good ideas for what to do with the old computer, that would be appreciated too.

I like the idea of having a Funtoo version of AUR. I really didn't know exactly what the AUR was or how it worked, but I occasionally checked it because I write my own ebuilds, and sometimes when I have trouble getting something to work, I'll take a look at how Arch gets it to work and use that information to help me get things working. I'm not a programmer, but I learned how to write ebuilds by studying existing ebuilds and studying the Gentoo dev manual. Writing ebuilds is one of the ways I feel I'm able to contribute to the community. I administer my own overlay, and every once in a while, if I think an ebuild is polished enough, I'll submit it to the Gentoo bugzilla. My thought process in doing so was that if it's in Gentoo's tree, it'll benefit both Gentoo and Funtoo. Alas, the Gentoo/Funtoo split is slow and gradual but sure, so eventually it wouldn't surprise me if Funtoo eventually has to have its own completely independent ebuild ecosystem. And a system like the AUR could potentially make it work.

I decided to do a little investigating, although I suspect you've already learned as much as I have because I saw your post on kvraudio.com. At this point, I'd just recommend emerging media-video/libav and see if that fixes the issues you're having. I'm not certain, but you may have to unmerge media-video/ffmpeg because I don't think those two packages can coexist (of course I may be wrong; I've never tried).

I'm glad you figured out something that works for you. I don't use the same terminal you do, so I'm unfamiliar with it. I use KDE's konsole for my terminal. I only know that in konsole you'd go to Settings -> Edit Current Profile... then put the desired variables into the "Tab Title Format" area. I use "%D : %w" which shows the full path of the current directory and the window title as set by the shell.

I'd put in my 2 cents, but I haven't any experience with Paludis or Exherbo. I admit I've been curious about Exherbo, but I got the impression that it was a very small project, and I didn't want to jump on the bandwagon of a project that might die off. For similar reasons, I didn't spend much time looking into distros like Lunar, Sorcerer, or Source Mage. I did use Slackware for a while several years ago, but it was just a bit too cumbersome for me. Still, I think it's a good distro in some respects. One of these days, I do want to try doing Linux from Scratch. I guess because I see that as going "all the way" with do-it-yourself Linux. I ended up choosing Funtoo about 4 maybe 5 years ago now because I'd been running a Portage-based Sabayon system for a couple of years and was happy with it but wanted to go a step further. Yet Gentoo seemed like it was kind of stuck in a rut. Funtoo, on the other hand, was like Gentoo yet seemed like it was going somewhere - like it had a bright future ahead of it. So I went with Funtoo and have been happy with that decision. About a decade ago, I disto-hopped a lot and tried all the major distros and quite a few minor ones. I stuck with Kubuntu for a long time, but Canonical started making changes I didn't like, so I moved on. At this point, I've been using Funtoo almost half as long as I've been using Linux of any flavor.

I like pytony's sliding penguins. I think that conveys the right feeling. I was also wondering if some tip of the hat to Beastie (FreeBSD's mascot) might be in order since Portage was inspired by the BSD ports system. Also, though this might be a bit of a different topic, I think it's related. Since fbsplash/splashutils is no longer maintained and hasn't been updated in about 3 years, and the only somewhat viable alternative is Plymouth, maybe Funtoo could either come up with it's own bootsplash manager or fork fbsplash and update it. A cool logo isn't enough if there isn't a reliable way to display it. And once we do have a good logo, maybe a kernel patch could be used to put the Funtoo logo instead of the default Linux logo on the standard framebuffer boot screen.

That's right. The regular, stable (and working) genkernel doesn't support Plymouth. Actually I'd rather use splashutils than Plymouth, but splashutils is broken and no one seems interested in fixing it. Dracut will build an initramfs, but when I boot, I don't get a splash screen; I get a black screen with three little squares in the center with question marks inside the squares during boot. I haven't tried using better-initramfs yet.

I've not seen that particular error before (that I recall, anyway). I've gotten libtool errors before when I compiled libtool with -flto. You might try re-emerging libtool with basic CFLAGS and see if the issue persists. If libtool is somehow broken, perhaps that will fix it. I've noticed that subversion wants to be emerged and re-emerged over and over for no apparent reason. If you are certain that the dependencies are already installed, you can pass -O (that's the capital letter O) to emerge, and it will just emerge the specified ebuilds without calculating or emerging any dependencies. Or you can pass '--exclude subversion' to emerge to exclude specific ebuilds - such as subversion - from being emerged even if they're pulled in by something. In the latter case, it is possible that --exclude will keep the emerge from starting if it would cause another package you're trying to emerge to have an unmet dependency.

I'm trying to set up an initramfs in order to get Plymouth working, but it complains about a missing systemd file even though I don't use systemd. As I understand it, genkernel-next shouldn't require systemd to work. whitegiant linux-3.17.2-gentoo # genkernel --kernel-config=/usr/src/linux-3.17.2-gentoo/.config --plymouth-theme=solar initramfs * Gentoo Linux Genkernel; Version 58 * Running with options: --kernel-config=/usr/src/linux-3.17.2-gentoo/.config --plymouth-theme=solar initramfs * Using genkernel.conf from /etc/genkernel.conf * Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86/config.sh .. * Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86/modules_load .. * Linux Kernel 3.17.2-gentoo for x86... * .. with config file /usr/src/linux-3.17.2-gentoo/.config * busybox: >> Using cache * initramfs: >> Initializing... * >> Appending base_layout cpio data... * >> Appending udev cpio data... cp: cannot stat ?/lib/udev/rules.d/99-systemd.rules?: No such file or directory * cannot copy /lib/udev/rules.d/99-systemd.rules from udev cp: cannot stat ?/lib/systemd/network/99-default.link?: No such file or directory * cannot copy /lib/systemd/network/99-default.link from udev * >> Appending auxilary cpio data... * >> Copying keymaps * >> Appending busybox cpio data... * >> Appending modules cpio data... * >> Appending blkid cpio data... * >> Appending plymouth cpio data... * >> Installing plymouth [ using the solar theme and plugin: "space-flares" ]... cpio: libc.so.6: Cannot stat: No such file or directory cpio: libdl.so.2: Cannot stat: No such file or directory cpio: libm.so.6: Cannot stat: No such file or directory cpio: librt.so.1: Cannot stat: No such file or directory cpio: libudev.so.1: Cannot stat: No such file or directory cpio: libz.so.1: Cannot stat: No such file or directory * ERROR: Binary /lib/systemd/network/99-default.link or some of its library dependencies could not be copied * * -- Grepping log... -- * * Running with options: --kernel-config=/usr/src/linux-3.17.2-gentoo/.config --plymouth-theme=solar initramfs * Using genkernel.conf from /etc/genkernel.conf * Sourcing arch-specific config.sh from /usr/share/genkernel/arch/x86/config.sh .. * Sourcing arch-specific modules_load from /usr/share/genkernel/arch/x86/modules_load .. * * ERROR: Binary /lib/systemd/network/99-default.link or some of its library dependencies could not be copied * * -- End log... -- * * Please consult /var/log/genkernel.log for more information and any * errors that were reported above. * * Report any genkernel bugs to bugs.gentoo.org and * assign your bug to genkernel@gentoo.org. Please include * as much information as you can in your bug report; attaching * /var/log/genkernel.log so that your issue can be dealt with effectively. * * Please do *not* report compilation failures as genkernel bugs! *

As has already been mentioned, it sounds like this is likely a DNS issue. When you create the connection with NetworkManager, there should be an option to add a DNS server. Add 8.8.8.8 or 8.8.4.4 (or both). This should tell NetworkManager to pass these DNS addresses automatically to your phone when your phone connects to the access point you created with NetworkManager. Otherwise, you'd probably have to set up the DNS addresses on the phone somehow.

Unfortunately, a resync doesn't clear up the issue with nvidia-cg-toolkit and virtual/libstdc++. I'm not 100% sure, but I don't think that dependency used to be there. But I examined the ebuild; it's there now. In any case, I just unmerged the offending packages and was able to proceed with a world update. I may try putting an ebuild for nvidia-cg-toolkit in a local overlay which doesn't depend on virtual/libstdc++ and see if it causes any problems or if it works. Frankly I'm just incredulous at the idea that a toolkit released in 2012 would actually depend on a pre-gcc-3.4 library. Either the Gentoo maintainer goofed, or, if it's true, the guys at nVidia are insane.

I don't know why anyone is complaining about compilation taking about an hour. On my Athlon XP 2200+ it takes over 13 hours to compile webkit-gtk. That's longer than it takes to compile Firefox on the same computer! Only Libreoffice takes longer. I think we can all agree, however, that webkit-gtk really stinks when it comes to compile time.

So I ran 'emerge -1uDNva --keep-going --with-bdeps=y --complete-graph @world' and met a few blockers. I removed a few packages to get rid of a few warnings, but I still get a few. Total: 740 packages (658 upgrades, 5 downgrades, 32 new, 7 in new slots, 38 reinstalls, 2 uninstalls), Size of downloads: 2,255,479 kB Conflict: 4 blocks !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: x11-libs/libxkbcommon:0 (x11-libs/libxkbcommon-0.4.1::gentoo, installed) pulled in by >=x11-libs/libxkbcommon-0.2.0[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (media-libs/libsdl2-2.0.3-r200::gentoo, ebuild scheduled for merge) (x11-libs/libxkbcommon-0.3.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) dev-python/wxpython:2.8 (dev-python/wxpython-2.8.12.1::gentoo, ebuild scheduled for merge) pulled in by dev-python/wxpython[python_abis_2.7] required by (dev-python/twisted-core-13.2.0-r1000::gentoo, ebuild scheduled for merge) dev-python/wxpython[python_abis_2.7] required by (dev-python/matplotlib-1.3.1-r1000::gentoo, ebuild scheduled for merge) (dev-python/wxpython-2.8.12.1-r2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) dev-libs/libnl:3 (dev-libs/libnl-3.2.24-r1::gentoo, installed) pulled in by <dev-libs/libnl-3.2.25:3= required by (net-misc/networkmanager-0.9.8.10-r1::gentoo, ebuild scheduled for merge) (dev-libs/libnl-3.2.25::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) sys-devel/bison:0 (sys-devel/bison-3.0.2::gentoo, installed) pulled in by >=sys-devel/bison-3 required by (dev-libs/rasqal-0.9.32::gentoo, ebuild scheduled for merge) (and 1 more with the same problem) (sys-devel/bison-2.7.1::gentoo, ebuild scheduled for merge) pulled in by <sys-devel/bison-3 required by (sys-libs/libstdc++-v3-3.3.6-r1::gentoo, installed) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. The libxkbcommon and libnl blockers don't seem to be a major issue, and the wxpython blocker seems odd to me, but probably not major. The only real issue seems to be with sys-devel/bison. sys-libs/libstdc++-v3-3.3.6-r1::gentoo is the program which requires <bison-3, so I ran equery to find out which program is pulling in sys-libs/libstdc++-v3-3.3.6-r1::gentoo. The only ebuild which requires it is media-gfx/nvidia-cg-toolkit. Now I suppose if this is really the case, I'll just have to live with it, but quite honestly I find it amazing that the nVidia Cg Toolkit, which was last released April 2012, would require such an old library. Any ideas?

As far as I know, KDE 5 is not yet ready on Gentoo and Funtoo, but I suspect it will be in the near future - meaning probably 2 or 3 months. You can check the Gentoo status at http://wiki.gentoo.org/wiki/Project:KDE/Frameworks. I have tried unmasking and emerging some of the QT5 ebuilds, but they're obviously masked for a reason. For example, dev-qt/qtwidgets-5.3.2 fails to build on my system, and of course I can't emerge the ebuilds that depend on qtwidgets. But I was able to emerge a few other QT5 ebuilds. In any case, you might want to be cautious about being an early adopter of KDE5. I remember when KDE4 first came out. There were a lot of KDE3 apps that weren't ported to KDE4 for several months, so KDE4 was very crippled early on in its functionality. That will probably be the case with KDE5 for a while until all the KDE4 apps are ported to KDE5.

Well, I went to the source: http://svn.tuxfamily.org/viewvc.cgi/proaudio_proaudio/trunk/overlays/proaudio/ Apparently the last update to the overlay was 4 weeks ago. That's pretty recent, so yes it is still being maintained. Anyway, I started working on an updated ebuild this evening. It shouldn't be too difficult, but personally I think the Makefile and shell scripts are a mess, so I think the most work is going to be editing the Makefile and making a suitable patch. Just for example, changing CCC to CXX, changing LINKER to LD, and a few other changes to make it play nicer with Portage and its environment variables. I also plan to make it configurable whether it's compiled with GTK2 or QT4 since both appear to be supported.

I'd suggest running top or some other utility to find out what is using up all your RAM. Besides that, are you using a lot of optimizations with GCC? Sometimes using a lot of unusual GCC flags can cause normally stable programs to behave badly. Sometimes also it's not an issue with RAM but with heavy disk writes than can cause an unresponsive system. Are you seeing a lot of constant disk activity? And as far as kernel config, I can't really think of anything that might cause this kind of behavior, but you could maybe try the BFS CPU scheduler and/or the BFQ I/O scheduler and see if either of those help. The UKSM kernel patch could also help reduce memory usage. But right now, none of these patches has been updated for kernel 3.17, so you'd have to use kernel 3.16.x or older to try them out.

I'll take a look at it this evening. Also, perhaps you should contact the pro-audio overlay maintainer and request he update the ebuild. The pro-audio overlay is very large, and I know from managing my own overlay that it can be hard to keep track of a large number of programs to keep everything up-to-date. Just run "layman -i pro-audio" for his contact info. Or you could file a bug on the Gentoo bugzilla and they could assign it to the overlay maintainer.