Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Renich last won the day on May 18 2015

Renich had the most liked content!

1 Follower

About Renich

  • Rank


  • Location
    Ixtlahuac?n de los Membrillos, Jalisco, M?xico
  • Interests
    Linux, Music and Girls.

Recent Profile Visitors

523 profile views
  1. I do not agree on the Gnome example, but let's leave it at that.
  2. Nice idea. It is a cool way of being constructive and it would solve a few issues. Thanks.
  3. Well, I don't see what is the problem with alternatives. We support exim and postfix, for example. There're a lot of options and this is just that, IMHO. I assume that developers accross distros know what they're doing. I don't see anybody pushing anybody to adopt SystemD. I think you're assuming otherwise and I'd like to see some proof of that, if you have any. I agree that the maintainers have a hard time and that they're overworked. I appreciate everything they do. On the other hand, it's their choice and they're up to the task. In fact, It might even prove to be simpler to maintain stuff instead of going overboard not supporting it and making everything still work; which is the case of Gnome, at least. I don't agree with you speaking for everybody. Please, speak in your name only and let "everybody" speak for their own. It is not about what Red hat offers... it has never been about that. I don't think Funtoo keeps a tab on this.
  4. Nope, I am pointing out that I don't have a choice about my init system and that the lack of this choice, in particular, will aliniate any user that doesn't participate. You should, at least, have a choice of, what today, is becoming the industry standard init system, resource manager, loging solution and booting-watch-cha-ma-call-it. That's all. Well, you speak of things like if they happened unilaterally. Developers at work made their decisions and came up with, what they thought, it was the best plan. The result of SystemD taking over stuff is just a consequence of devs thinking it is the best option. I am happy to trust them on that. Yes, I know. I do trust him and I am not pointing a gun at anybody. I am just expressing my opinion; as you are. I truly think that Funtoo should allow and support SystemD; while favoring whatever Funtoo likes. That's all. It will be easier and people that hate it can still say they hate it. Win <-> win, huh? ;)
  5. So, is this how we discuss technology?... Please, keep your opinions technical, if possible. No, I haven't read the code for SystemD. While at it; confessing, I haven't read the code to the Kernel nor Python; and I use them. That doesn't mean I don't trust the software. There are hoards of people working on it, openly, and that makes me trust the code. Same goes for SystemD. Besides, I've used it and, in my experience, it has worked pretty well. Not only for init things, but for containers and resource management; as well as logs and stuff. I do not work for Red hat. I have maintained a few packages on Fedora, though, for quite a while. It is OK to consider any piece of software "pollution"; but it's not OK to prevent users from using it. I mean, we have java in the repos... What OpenRC lacks for me is the resource management part with cgroups. Also, the logging system in SystemD is really cool to have. Besides that, I like containing web apps using SystemD units; for example, a ruby app or stuff like that. Those are some of the things I'd like to have that OpenRC doesn't provide, AFAIK.
  6. Well, in my case, I have nothing against Red Hat. As you say, they invest in maintaining a lot of FOSS. Fedora is the lead, which the upstream for their RHEL. While I collaborated more actively there, we were always pointed upstream. The author of the FOSS is the one we should support and help in every way possible. That philosophy is what brought me to them. Fedora, as the upstream, is an awesome project. Very collaborative and with a great community. Red Hat, mainly, takes care of the resources it needs to function. Besides, they've open sourced a lot of cool software; following their own FOSS commitment principles.
  7. Man, you are too defensive. You keep saying you're not dumb and all but I haven't found the part where they call you dumb. As I see it, you're the one assaulting g-j- while he, objectively, writes his opinion on things, backing it with code. Please, do your best to defend your point in the same way or as best as you can. Bashing people gain you anything. Remember, respect is earned, not asked for.
  8. If anybody here is interested in learning about SystemD, check this out: https://fedoraproject.org/wiki/Systemd That page contains several good links. The definitive guide would be: http://www.freedesktop.org/wiki/Software/systemd/#thesystemdforadministratorsblogseries
  9. Please, respect each other's opinions. We can discuss SystemD and leave out personal attacks. Let's not turn this into a flame war. That said, awesome examples j-g-. Those are some of the reasons why I love SystemD. Those who have bad experience using SystemD is because of the poorly hacked/configured environment in where they tried it. I recommend checking out Fedora. It works flawlessly and bugs get attended, as the rest of them. I could say the same thing about Pulseaudio. Also, I didn't come to Funtoo because of it's anti-SystemD attitude. I came here bacause: it's a rolling release distro It's taylor made; you can totally customize it (except for SystemD, that is "forbidden") The build manager is based on Git. It has awesome documentation Daniel Robbins maintains it; with the help of a few chosen ones ;) This is why it surprised me so much when I learned that SystemD would not be supported, ever.
  10. Well, I'd like to contribute. Same state here. Not much time available, but would love to help.
  11. Guys, thanks a lot for your opinions on my own. It's been a fun read and; like everything in the real world, I agree with some, disagree with some and learned a few things in the way. I don't want to come out as a Fedora/systemd chauvinist. I will, also, reserve my opinion on your opinions. This is a private talk we can have, on 1-on-1 basis. Feel free to write to renich a7 woralelandia 6?7 com and we can further on the discussion. If you want to have it online; here; at the forum, let me know. I just want to avoid flames at all cost; that's why I am trying to be cautious. Again, thank you for the awesome feedback.
  12. Yes, well, if you want ot use systemd on Funtoo, you need to deactivate all the anti-systemd settings, masks and work done in order to avoid it. I mean, in the end, I could start using BSDs kernel and some obscure filesystem for what I can tell. The thing is there is no easy way of doing it that I know off.
  13. Hello, Funtoo community, I am a happy desktop and server user of Funtoo. I consider this community as good and awesome as the best FOSS communities out there. I am, of those, who actually have fun using Funtoo. That said, I want to express my honest opinion on our systemd stance. Now, before I start, this is not: * a request * a claim for support * a rant This is only my opinion and, since we coexist in a free and friendly community, I think this is the right place to post this. Systemd has been adopted by many of the important GNU & Linux distributions all around. It is the standard in all the new main stream distributions; or, at least, most of them. This is not because they're all blockheads and made the decision to switch just for the sake of fashion. Then again, I have not read the code and am not aware of the specifics. It is used a lot and it will be the industry standard for servers and embedded systems. We do not use it. We consider it trash. We, also, alienate ourselves from the rest of the industry and become something totally different; which makes it really hard to be considered as a serious alternative OS for the aforementioned. One can, always, implement it as far as one can and use it wherever it is possible. It's, still, hard to convince my manager/client that Funtoo is awesome, though. Systemd is not bad at all. I've used it since I come from Fedora. To me, it is really simple to use, well documented and easy to understand. It manages almost every aspect of the system; and keeps growing since almost every upstream project is using it and contributing to it. It is destined to become better. Meanwhile, we cannot even use it since it is not supported. This choice is not given to us. One has to go against our distro in order to try it out or test it's implementation. The alternative is to switch to Gentoo; but I didn't come to Funtoo to start using Gentoo. Hey, OpenRC is not bad at all. It might lack some functionality or, maybe, it is my ignorance talking. Anyway, it is what we use and what we have. It boots fast and it's able to get the job done and pretty well. It is easy to use and stuff... but I don't see upstream distributions adopting it nor contributing in any way. <Sigh>... I just think we had a choice here... that's all.
  14. CFLAGS="-march=amdfam10 -O2 -pipe" CXXFLAGS=${CFLAGS} CHOST="x86_64-pc-linux-gnu" ACCEPT_KEYWORDS="~amd64" MAKEOPTS="-j7 -l6" ADD="attr bash-completion cairo consolekit dbus dhclient ffmpeg gallium glamor gnutls gtk3 id3tag jack jpeg2k ladspa libav lv2 networkmanager packagekit policykit pulseaudio ruby symlink theora udev unicode v4l vaapi vdpau vim-syntax vorbis webkit-gtk xattr xinerama" REMOVE="-bluetooth -nss -dhcpcd" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a" ABI_X86="32 64" USE="${REMOVE} ${ADD}" LINGUAS="en es en_US es_MX es_LA" # Portage Opts AUTOCLEAN="yes" FEATURES="parallel-fetch parallel-install ebuild-locks mini-manifest" EMERGE_DEFAULT_OPTS="--with-bdeps=y" # X VIDEO_CARDS="radeon radeonsi" # Ruby RUBY_TARGETS="ruby19 ruby20 ruby21 ruby22" # PHP PHP_TARGETS="php5-6" # Tengine TENGINE_SHARED_MODULES_HTTP="access addition autoindex browser charset_filter empty_gif fastcgi flv footer_filter geoip image_filter limit_conn limit_req lua map memcached mp4 random_index referer reqstat rewrite scgi secure_link slice split_clients sub sysguard tfs trim_filter upstream_ip_hash upstream_least_conn upstream_session_sticky user_agent userid_filter uwsgi xslt" TENGINE_STATIC_MODULES_HTTP="concat dav degradation geo gunzip gzip gzip_static perl proxy realip spdy ssi ssl stub_status upstream-rbtree upstream_check upstream_consistent_hash upstream_keepalive" # Python # Libreoffice LIBREOFFICE_EXTENSIONS="nlpsolver" # Layman source /var/lib/layman/make.conf
  • Create New...