Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

Renich

Members
  • Posts

    4
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Renich

  1. Your own post is my proof. You said it would be easier to accept systemd rather than maintain changes to projects such as Gnome (which is another RedHat funded/controlled project I might add).

     

    You act like it was extra work to remove systemd support from Gnome, like without the changes we'd have a choice. The opposite is true. Gnome is hard dependant on systemd and it was changed to allow a choice. So, your example is perfect. Gnome's reliance on systemd pretty much causes the distro to switch to systemd. Even if you don't install Gnome, the requirement for systemd in order to be able to run Gnome causes so many changes elsewhere (the main complaint many of us have) that you are basically strong-armed into a full systemd switch-over. Sadly, I like Gnome. Even anti-Gnome distros switch to 'jump on the bandwagon' as many have suggested.

     

    Your line of thinking is exactly what happened and EASY took over rather than any technical merit. See Google for sticky details.

     

    More about me at https://eddon.systems

    I do not agree on the Gnome example, but let's leave it at that.

  2. Option 3:

     

    Is there a 3rd option? I thought funtoo was looking into revising the init system. It may be interesting to look at a set if goals that could satisfy the technical needs of both systemd and openrc users. I say 'technical' since API level compatibility with systemd for Gnome support or something might be useful, but simply doing it the way X does it (where X is systemd or traditional SysV Unix) should not be a factor ... only the actual benefits of an approach.

     

    Obviously, such a thing would be a huge project, but I think we have the expertise to pull it off. Yet, I'm not even suggesting coding such a thing at this point, only a change from the current circular banter to what we propose an ideal init would look like.

     

    More about me at https://eddon.systems

    Nice idea. It is a cool way of being constructive and it would solve a few issues. Thanks.

  3. Nope. Supporting systemd means supporting two versions of all the things that systemd had polluted. Why should Funtoo give you a choice when none of the major distributions do?

     

    And again, I don't care what everyone else does. I don't use bind for DNS. I was one of the first to stop using sendmail. I was a very early proponent of Linux. I've never done what everyone else does, and the Linux community hasn't really followed such a mindset in the past.

     

    You assume that the switch to systemd was made because its better, and not due to duress. And from what I saw that's not what happened. Debian is a great example. The history of the rift there is all open for reading.

     

    Again, you are free to run it on your system, but no one here wants it and any support means slicing more time from already overworked maintainers. Redhat has plenty of people, paid people, and they don't offer an init alternative. Why should funtoo?

     

    More about me at https://eddon.systems

    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. Sorry to reply to an old post, but just saw this ...

     

    You are complaining that Funtoo isn't a serious alternative because its not like everyone else?  IMHO, its the ONLY alternative!  It's not much of an alternative if its exactly the same as everyone else.  And not giving you a choice?  Uhmm ... we aren't getting a choice from any of the mainstream distros, and they have way more resources to maintain different "choices".  I think you should bug them to support OpenRC!  That would be more fair.

     

    As for why the other distros chose to switch, its because of systemd's practices (Embrance, Extend, Extinguish?  Anyone else remember that philosophy?) where it looked like they would have to maintain such projects as udev and policykit and Gnome by themselves because of systemd dependencies.  At the time the decision was made, that was the way it looked.  Now, thanks to a very few people (wish I could remember their names, they need to be thanked and sponsored) those projects have non-systemd ports.  We may get Gnome a couple months late, but we get it.

     

    Funtoo is the brainchild of our BDFL ... if you trust him on the rest of the OS, trust him on this issue too.  In either case, its not a Democracy :)  You don't get to choose.  It IS Open-Source, so you could fork it, or back-port the changes to Gentoo and then run systemd all you want.    Just don't call it Funtoo if it runs systemd.   However, when it comes to drinking the systemd Kool-Aid or the Funtoo Kool-Aid, I choose Funtoo.

     

    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. Good for you. The rest of us hate it. It's just too fast and too lean for my liking. Maybe there's a way we can fatten it up and slow it down? END SARCASM

     

    Statistically speaking it's impossible for them to all be blockheads.

     

    As far as switching for the sake of fashion? I think that's what some people have accepted as THEIR reason for switching. It's a coping mechanism. That's what some people do when the distro they are using decides to yank other options out from under them and maybe they aren't advanced enough to prevent it from happening.

     

    By your own admission you haven't read the code and aren't aware of the specifics. That makes me wonder why you would be so eager to convert to systemd??

     

     

    Pure propaganda. I'm guessing you work for RHL.

     

     

    I think there are quite a few excellent reasons that systemd is considered trash by the majority of funtoo users. I would also venture to guess that the average Funtoo user has had a decade or more of server experience. The current init isn't broken or dysfunctional enough to justify making a dramatic switch to systemd. I'll take alienation.

     

    Would your client's and manager be okay with Gentoo? Install that and then change the init to OpenRC. Now you have Gentoo and nobody gives a darn about the init. You could have saved yourself the headache and installed funtoo and just set the 'branding' use flag to on. Nice Gentoo openrc login page and nobody else is wise about it. ;)

     

     

    Okay Lennart. Jokes over. Go back to RHL and quit trolling the funtoo forums.

     

     

    Well one of the key points of Funtoo is the anti-systemd approach. Everything is working well without it. Why would anyone want to pollute this OS? I'd put Funtoo up against any systemd based distro and we can compare performance and reliability. No doubt who the winner will be.

     

    One thing I learned is it's hard to fight a distro that isn't moving in the direction you want. It would be much easier for you to move to Gentoo or a systemd based distro then stick to Funtoo. I fought systemd in Debian testing and there was virtually something new to weed out on a three times a week basis. I gave up and came to Funtoo and have no regrets. If Debian dumps systemd tomorrow I'd still stay with Funtoo. The core group in charge of this distro are top notch.

     

    What functionality is OpenRC lacking exactly that you need on a daily basis for your personal use or server use?

     

    By your own admission it boots fast, get's the job done and is easy to use....but since other distributions decided to be wreckless and make the switch you think you need to do the same too?

     

    Sounds like you want to switch for the 'sake of fashion'.

     

    As far as upstream distributions? There are a few that still have it as an option. Arch/Manjaro comes to mind. My 2nd favorite distro behind Funtoo at the moment is this one: http://sourceforge.net/projects/manjaro-openrc/files/15.09/xfce+ob/      IMAGES

     

    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. PD: Have you looked into the amount of software that gets maintained by people working at redhat that is kind of defacto among many linux distributions ( e.g. A lot gcc, and the complete coreutils, I think the still maintain sysvinit) and they employed the likes of the once 'Second in Command' in the Linux Kernel Alan Cox for most of his career until retirement? I would actually like that to be less but I'm at least glad they follow the open source model, altough I do suspect that if they decided to be more privative a lot of the clever people working ther would leave, like what happened with Oracle and Sun.

    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. Please stop. There are no lies nor exaggerations, just relations of personal experience ... from highly experienced people no less. For example, I'm not a moron and I can make GDM stop respawning! SO, instead of insinuating that I'm too dumb to make it stop, I obviously had some other point I was making.

    My point is that only systemd seems to think that this is a good idea! Even systems that (erroneously IMHO) respawn a service that dies, will refuse to do so without limits on the rate. This is absolutely dangerous and can bring a system to its knees. What if it died due to low memory? Running it again could cause something ELSE to die. If I wanted automatic service respawn, I'd have Nagios do it and it would be done right, and it would never respawn twice in 10 minutes, and would send me a text every time it did, with additional limits per hour/day/etc.

     

    The auto restart of services shows the mindset of the systemd developers. Us old Unix admins want to find the problem, fix it, then start the service ourself. Systemd tries to be "easy" and basically 'reboots' the service. Its Windows oriented thinking!

     

    Your constant use of personal attacks shows us you are frustrated because you have nothing relevant to contribute. Please stop calling everyone liars. Its not helping your argument.

     

    As for logs, I don't understand why you pretend its not an issue when you can just read the bug report that the logs get corrupt. And how compatible is all this with syslog? I want all my logs on one machine and when something goes dead, I read it on the log server. Does journalctl filter by machine? Or can systemd even handle syslog content from another machine without sending it through syslog?

     

    But I can install another system log to get the features I want ... wait ... Why would I switch to systemd which tries to take over a service, just to proxy it right back to the service that was supposed to handle it in the first place? You are building a house of cards with your server. You say systemd is modular, but your definition is different than mine. In my book, modular means that when my SATA drive dies, I can replace it with another from ANY vendor. Systemd is locking out the alternatives and so we can't easily replace those modules. Thus, its NOT modular, but maybe sectional. It does not play nice with others and so it will be punished with exile.

     

    Again, there is no benefit to using systemd, just stuff getting in my way. You talk of negligible latencies ... but what do I get in return for the latency? TROUBLE! Just dump systemd and use a real syslog.

     

    When I hear systemd, I think of that Taylor Swift song ... "I knew you were trouble when you walked in ..."

     

     

     

    More about me at https://eddon.systems

     

    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. 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. 

  9. For the ones interested in running systemd on Funtoo, I had a working configuration with systemd and was in the process of creating profile stuff for it, but the maintaince burden would take too much time I don't have, but I might try again when I have more time, or if there's more people that want to run systemd on top of what funtoo provides and are willing to contribute fixing stuff we could put something together and use github or gitlab as a meeting point for discussion.  I wouldn't try to make it official, neither discuss development or fixes in any funtoo channel, just a overlay that makes easy to install and provides profiles for systemd in the funtoo style, that way unnecessary flames are avoided.

     

    Well, I'd like to contribute. Same state here. Not much time available, but would love to help.

  10. 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.

  11. I don't see your point about Funtoo choosing to be left out of the systemd club. I can't speak for the Funtoo community at large but I think Funtoo itself is systemd agnostic. Anyone is welcome to run Funtoo with systemd or with Openrc. If upstream packages support systemd then they should also work on Funtoo. Funtoo leaves that choice up to the end user which is, to me, a "pure" linux way of doing things.

     

    Every Funtoo installation is like a snowflake; everyone different and unique.

     

    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.

  12. 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.


  13. 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

     

  14. It would be cool if the pre-built kernels/initramfs images included virtio and btrfs modules. I tried mine as a KVM/Qemu guest and got nowhere with it.

     

    What I do is use genkernel-next; with vanilla sources. It provides a --virtio and --btrfs options and injects those modules into the initramfs image. 

×
×
  • Create New...