Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by uudruid74

  1. dansguardian can be used to block websites based on content.


    The problem I see with restricting software based on group membership is that


    1) you need to know which binaries you need to chmod

    2) permissions will probably revert to their defaults upon upgrade (though I've not tested this)

    Both points are valid, but there aren't many other options. Maybe we need a package manager that installs new software based on pre-defined groups and makes new users members.


    More about me at https://eddon.systems

  2. I would just give separate accounts for play and school, for each kid. The play accounts would include an extra 'group' membership.


    The Linux firewall can restrict access to sites by the processes owning user and group. Application can have execute restricted if not in the owning group. You may need a fairly sophisticated firewall to scan the page for keywords like 'game', 'movie', 'porn' or whatever else you like. Some stuff always blacklisted, rest of the net locked except for whitelisted sites during school. And VNC should already be well integrated.


    Now, set up the 'play' accounts to be able to log in between certain times, and you can have a from job force the play accounts to log off when school starts. I would make the kid's school files accessible outside of school, but not the other way around.


    More about me at https://eddon.systems

  3. My website is tengine and joomla. There is a landing page (preloads some stupidly large javascript while you look at pretty animations) which has a link to the Joomla stuff (php via pfm)


    Joomla hangs the first time you go into it. If you refresh or hit enter in the URL bar, it comes right up. Happens on multiple clients.


    Anyone seen this before?


    More about me at https://eddon.systems

  4. Anyone have a good HowTo for setting up DoveCot with Sieve filters?


    I'm more familiar with Courier, but I just took the plunge and migrated over. I have sieve and managesieve USE flags set. The web site for Dovecot starts talking about Pigeonhole. Do I need it? There isn't an ebuild for it, so if I need it, what are the USE flags for?


    I just don't see how this fits together and all I can find are a few undocumented posts of config files, and I refuse to blindly cut n paste, or instructions for Ubuntu that don't seem to apply to us.


    Any Dovecot experts?


    More about me at https://eddon.systems

  5. I don't think you need to bother with Metro. I remember the old Stage3 vs Stage1 wars on Gentoo (some 12 years ago now) and everyone will have their own thoughts. I like things to just work with a minimum of hassle. Just crab a stage3 and go.


    BTW, you use a lot of Gnome software. The Gnome desktop supports ALT+SUPER+8 to turn on zoom, ALT+SUPER+'=' for zoom in (the +/= key and use '-' next to it to zoom out again). And if you really have trouble the screen reader is ALT+SUPER+S (if orca is installed). There are others like text size and high contrast adjustments, but those don't seem to have hot keys press defined.


    More about me at https://eddon.systems

  6. There was a slashdot article about Busybox removing systemd support, which turned into an sub-thread about an ipv6 over ipv4 service.  The systemd maintainers added a respawn "fix" that would restart the service within 10 seconds since the daemon would abort if the network wasn't up .... of course this means that the upstream service providers get hit with retries every 10 seconds if your password is wrong or something else is misconfigured, and they were annoyed that the warning NOT to respawn wasn't being acknowledged and no notification was given that the unit file was being changed.  They site systemd as the problem for not verifying that the network is up before starting the service.  The systemd folks site that this shouldn't be necessary since "modern" systems (he mentions his Apple Powerbook) have intermittent networking and the daemon should use exponential backoff if the network is down.   The daemon author says people need to read the logs before restarting the daemon and the systemd guys say that users aren't admins and don't read logs!


    This is a classic example of what I see as the division of thought.  The old-school admins see a server and classic start-up routines - you are started when networking comes up. If networking is down, abort.  Read the logs.  Auto-restart is bad.  Systemd wants it easy and wants it to work on a laptop without thought (and apparently without a GUI tool that checks the log to decide if it should respawn), wants services to be restarted and says that the daemon author doesn't provide an exit code as to why the daemon stopped, so the only choice is to restart for all exits.  He says the daemon is bi-polar because it will retry if the network is up when its started, but not other times, and sites network connectivity problems may not be local.


    Here's my take on this.  Network down and can't connect are two different things.   The former is a local issues and easy to detect.  In this instance, the daemon can/should quit and log.  Further, networking should be UP before the daemon is started.  Specifically, the daemon should be started as a response to the "event" that the network is up.  If there is a login problem or other issue, it should also abort and log.   If the network is up, but you can't connect to the server, then use exponential backoff and retry.  Systemd should know when network devices like Wifi disconnect and reconnect.  It should also know if the daemon is running.   It should start the daemon on the condition that the network has been brought up and it is not already running.


    Now ... what am I missing ???   Why would it start without networking being up?  Why would anyone restart the service every 10 seconds?  Sounds brain dead to me!   Typical SysV init would run the network up/down scripts and get this right.  Systemd SHOULD get this right, and I'm sure someone will say its been misconfigured or whatever, but notice two different mind-sets here.  One person wants it to just work with focus on easy - and who cares what damage it may cause.  The other person wants people to stop and read (no matter how unrealistic that may be).


    I once had someone tell me they couldn't print ... they said some error message kept popping up.  I said, "What does it say?"  They said, "I dunno".  I said, "Well, try it again and read it!"  And I could tell they were mad that I wouldn't run over there and fix their stupid Windows problem ... they did not want to read me any technical jargon from some error message on the screen!   The response was, "Nevermind."     ... WHAT?  ... Guess what the Error said?  



  7. Unfortunately a lot of people have bought into the misinformation that you can't have a modern Linux distro without systemd. Spread the word. http://without-systemd.org/

    I'm not really a fan of udisks either. Even after unmounting/ejecting a usb device, I can't fsck the thing because the kernel thinks its in use, even with no files open on it. I think this is a udisks issue, which is now a systemd thing. The workaround is to remove the device and reinsert it but don't open it or else udisks will hang on to it forever.


    These over-complicated system daemons are horrible. And they all seem to come from freedesktop.org ... I'm really starting to hate freedesktop.org.






    More about me at https://eddon.systems



    It seems like it would be pretty easy to write a generic init script that would use unit files like configuration files. Call it unitrc. Then making a unit file work for start up would just be:

    ln -s /etc/init.d/unitrc /etc/init.d/myservice
    mv /usr/lib/systemd/system/myservice.service /etc/conf.d/myservice
    rc-update add myservice 
    Note that systemd's service startup information is stored in /usr. Another example of the perversity of systemd.

    Or modify rc-update to look for systemd unit files?


    More about me at https://eddon.systems

  9. ;)


    On a sidenote...but relative as it's an example of some attitudes toward systemd....was installing profile-sync-dameon...ie..psd....and ended up seeing this...read down a bit at the NOTE FOR VERSION 6:




    Some people are just lazy.

    There would seem to an issue with fragmentation of our userbase. This will only get worse. It would be nice to abstract daemon installation in some portable way.


    Maybe some application that could convert from some universal configuration to whatever the local init system requires, or perhaps we should accept that systemd will be prevalent and make a converter that converts systemd configurations to openrc scripts? Does such a think already exist?


    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.

    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

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

  12. 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? ;)

    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

  13. Already mentioned what was wrong with the Red Panda. You are looking for a symbol. Symbols have meaning, beyond just 'Awe that's cute'. If the symbol you use already has strong meanings in the person viewing the symbol, then you should intend for that association to be made in the persons mind.


    Do you intend to associate Funtoo with communist China?

  14. Sorry to reply to an old post, but just saw this ...


    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.


    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.

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

    You don't have to say something directly to imply something. Perfect example, I mentioned the respawning of GDM ... an example of a bad practice and the particular mindset of systemd that I disagree with.


    To respond by saying, "Well, I figured out how to make it stop ..." 1 - Avoids the entire point. 2 - Implies that I couldn't figure it out. I think everyone in this thread can figure out how to make it stop, so ask yourself why such a comment was made if not the implication I noted?


    And I don't need to see code at all. This isn't a debate. Once again, no one can give me any benefit to using it. It goes against my philosophy and what I think is right, and DEFINATELY goes against the atmosphere of free choice that the Linux community has enjoyed for the past 2 decades. Code is, s I said previously, an attempt to 'educate' me. This implies I need education. Every systemd supporter seems to think that I need more education if I don't agree.


    Do you not see how patronizing that is? I don't need education! I can disagree!


    More about me at https://eddon.systems

  16. I think you already know this, but you can do away with the bootloader for UEFI, with the CONFIG_EFI_STUB, and boot the kernel directly from the EFI menu, and compile in your command line arguments, but because of the way you wrote that I guess you don't like UEFI either.

    About udev I would say I didn't see the need to put it into the systemd repo when it was being being widely used, and In fact was a shady and totally unnecessary thing to do that in the end only hurted systemd anyway, Kay Sievers is not anyones favorite person in the linux world anyway, it's a shame there was not other better hacker at dealing with the community to take the udev maintance(I think it was his project from the beginning anyway, I wish somebody else had made udev first I guess).

    EFI is fine, UEFI is a joke. And mine is broken. It actually looks for the Microsoft EFI file to boot and none of the standard locations so making dual boot means renaming the MS loader so grub can chain it and putting grub where the MS loader is at ... and any hiccup causes MS to replace its loader which clobbers grub. "Made for Windows8" Luckily, there is "Legacy Mode" and I gave up on dual boot anyway.


    As for udev ... its had a long history. I only assume they have good reason for getting the kernel hotplug events as I can see a use for that in their "kdbus" scheme, but as you said, its been mismanaged.




    More about me at https://eddon.systems


    Invasive and growing. At this rate there will be only one Linux to choose from. Redhat.

    The picture doesn't mention udev nor the new systemd-boot which now manages your system before the kernel even loads! I'm wondering how the old LinuxBIOS project is doing ... might be nice to replace my uefi bios with a slim Linux kernel :)


    In defense of systemd, I understand the choice to include udev functionality and I likely would have done the same. It makes sense to be able to get the information directly from the kernel as an event source. But, none of the rest of userspace should care which udev you use nor should the original udev be changed. The fact that they saw fit to enforce their idea as the 'one true way' is wrong. They should emulated existing functionality and moved on.


    More about me at https://eddon.systems

  18. I would also like to point out that is a shame that the most PR funtoo seems get is because its 'anti-systemd' stance, and even drobbins makes stupid threads just to mock systemd, I think funtoo has more than that and some really neat ideas, I would have liked to try and contribute more (Look at the 2nd most viewed thread in this subforum after the screenshots one, is the one with my wallpapers), but this kind of childish attitude, and some other critisim I won't state here discourages potential contributors, altought it might attract more users 'running away from systemd', and not really trying funtoo because they thought they might like some of the other neat ideas, than just putting effort to block a package from getting installed, wich is what the dev team really does I'd think they would be better and with less work if the policy was just non-solve an redirect to gentoo systemd bugs.

    Its a shame you keep going. I use Funtoo because I trust Daniel and his decisions, mainly because we think alike on a lot of issues. I loved Gentoo in the early days, and realized that its decline was because they didn't listen to their founder. Basically, I followed Drobbins here from Gentoo. It was a lucky coincidence that we have similar views on systemd.


    To insinuate that we came here because we hate systemd is just more of you lashing out. To do something like that would be childish, and you make this thread personal when you accuse people of childish things. You have a lot to learn.


    We don't like systemd because we tried it and evaluated it on its own merits, ran comparisons, and studied its design philosophies and, based upon our experience and how we think a Unix system should be administered, we simply don't think systemd is a good choice. Worse yet, the supporters of systemd, like yourself, feel some need to attack people that don't support your view. You feel that if we don't like systemd, we need to be educated. Well, that's insulting in the extreme! How dare you assume we can't make our own choices?


    And the systemd supporters like yourself, mainly due to pressure from Redhat (who's employee created this mess) are removing OUR freedom of choice. Linux had always been about choices and freedoms, and I VIOLENTLY oppose an initiative that seeks to remove the 'Free' from my 'Free Software'.


    Give the rest of us some credit and quit pretending we're idiots. Go have fun with systemd, just leave the rest of us out of it.


    More about me at https://eddon.systems

  • Create New...