Re: [CURRENT]: claws-mail and firefox fail with Invalid alignment
2014-02-22 15:44 GMT+01:00 Rainer Hurling rhur...@gwdg.de: Am 22.02.2014 10:03, schrieb Ranjan1018 .: The problem is still present in r262325. Verified with Firefox. Just for the record. With r262334 the problem seems to be solved, Firefox, Thunderbird etc. work again :-) Thanks to davidxu@ for the quick fix. I can confirm, with r262336 the problem is solved, Firefox works again. Thanks to davidxu@ for the quick fix and thanks to Rainer for reporting it. Regards Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On Sun, Feb 23, 2014 at 8:46 AM, Scot Hetzel swhet...@gmail.com wrote:
On Sat, Feb 22, 2014 at 5:54 PM, Bruno Lauzé brunola...@msn.com wrote:
https://github.com/brunolauze/libnit
I know there's really big debate about init system but here's my
tentative to propose a new model to replace rc.
Let's call it libinit but the name as no significance for now.
I started coding a library with the following architecture.
the main idea is to rewrite rc in C language.
To me this seems like much work for no real gain. And it would make it that
much harder to debug a misbehaving script, in more than one way:
* c is a lot longer than sh, ie sh expresses the logic that much more
clearly.
* to actually see the new script would require to have the source code
installed, something far from everybody has.
a utility called system would act a little bit like service command does.
a folder would contains libraries instead of scripts inside
[target]/etc/rc.d
so we can add as many librairies a user desire and interlink the order
of each piece among all like in rc.
libraries don't belong in [target]/etc/rc.d, they would have to be in
{/usr,}/lib{exec,}/rc.d or ${PREFIX}/lib{exec,}/rc.d
Imho, the replacement to init and rc-scripts I sometimes think about would
be to import SMF from opensolaris/illumos. There one can at least get the
commands run and config used without looking at the source code.
Best regards
Andreas
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
Hi Bruno, To preface this, I'd like to say that I do believe that FreeBSD does need a more modern init system. SMF on Solaris and Launchd on Darwin both have some advantages. These are what I see as the limitations in our current design (not in priority order): 1) Options are implicit. Because init scripts are written in a Turing-complete language, including routines scattered across a large number of files, it's very difficult for a tool (e.g. a GUI system administration tool like the SMF GUI on Solaris) to enumerate all of the options. Additionally, these options are untyped so a GUI that does manage to find them can't tell whether it should be displaying a checkbox (for a boolean value) or a text field. Additionally, it can't tell what the dependencies are between them. 2) Dependency information between services is poor. If service A depends on B, and B is not running, then starting A should start B. If nothing else depends on B and B was not explicitly started, then B should stop. The last part is the hard one with shell scripts, because it requires maintaining the dependency graph and effectively garbage collecting it (explicitly started services are roots, dependencies are references). 3) It's easy for tools to add lines to rc.conf, it's hard to remove them. If you're administering a large number of nodes, you want to be able to push out updates to all, in a way that doesn't clobber local changes. Text file processing here is always going to be a fragile hack. 4) Shell scripts are a good tool for invoking complex sequences of command-line programs, but have a measurable overhead relative to fork() / exec() for running a single command. Most rc actions just run a single program, we should only be doing a shell invocation for ones that are more complex. 5) In a world where we're moving towards sandboxing services via Capsicum, the service launcher needs to be able to create services with a potentially large set of initial file descriptors (including a socket to Casper), based on the configuration policy. 6) As with launchd, it would make sense for a service management framework to subsume inetd and cron (and devd!) functionality, because timer events, network events, system startup, system shutdown, device attachment, and explicit service starting from the command line are even sources that trigger changes to the service dependency graph. 7) Inspecting the system status is very hard with the current system. I want to be able to see a list of all running services, along with the reason why they were started. 8) Again, in capsicum world we'd like inetd-like functionality for UNIX domain sockets, so that it's possible to lazily start things like powerboxes. In terms of design, I don't think that turning rc scripts into libraries is a win. I would like to see them replaced by a declarative config file in a structured format that provides dependency information, configuration options, and the commands required to start / stop the service (which can be shell scripts, but don't have to invoke a shell). The configuration options should be separate from the configuration variables, with the former provided by the package and the latter by the system administrator. We already have, in the base system, a library for parsing a structured configuration file format that is used for the pkg tools and a library with an efficient binary serialisation (libnv) that is used for various Capsicum-related functions. I'd like to see these combined so that in embedded devices all of the configuration files could be stored in the binary serialisation (which is denser and faster to parse) and turned back into the human-readable one only for editing. I do like the idea of an init library, so that the functionality is easily reusable and can be run in nested scopes. I don't think we gain anything by rewriting shell scripts in C, other than a maintenance headache and a requirement that all port maintainers be fluent C programmers... David On 22 Feb 2014, at 23:54, Bruno Lauzé brunola...@msn.com wrote: https://github.com/brunolauze/libnit I know there's really big debate about init system but here's my tentative to propose a new model to replace rc. Let's call it libinit but the name as no significance for now. I started coding a library with the following architecture. the main idea is to rewrite rc in C language. a utility called system would act a little bit like service command does. a folder would contains libraries instead of scripts inside [target]/etc/rc.d so we can add as many librairies a user desire and interlink the order of each piece among all like in rc. each library would follow and expose the following pattern: char **provide(); /* returns all the PROVIDE a library contains */ then for each provide() value the library would expose : XXX_provide() XXX_require() XXX_before() XXX_keywords() and
Re: libinit idea
On 2014-02-23 04:12, David Chisnall wrote: Hi Bruno, 3) It's easy for tools to add lines to rc.conf, it's hard to remove them. If you're administering a large number of nodes, you want to be able to push out updates to all, in a way that doesn't clobber local changes. Text file processing here is always going to be a fragile hack. sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. At ScaleEngine, we make extensive use of a global rc.conf pushed by puppet, with local modifications in rc.conf.local (and we actually extend this with an rc.conf.role file, added to the rc_conf_files. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: libinit idea
On 23 Feb 2014, at 18:11, Allan Jude free...@allanjude.com wrote: sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. The problem is, there is no such thing as an rc.conf style file. rc.conf is just a shell script. If you only edit it with sysrc, or you are careful to preserve the structure, then it's fine. There is absolutely nothing stopping you, however, from writing arbitrarily complex shell scripts inside rc.conf. Sure, it's a terrible idea to do so, but when has that ever stopped anyone? An rc-replacement could enforce this by only accepting purely declarative files for configuration, guaranteeing that if they were syntactically valid they would also be machine editable, no matter what the user does to them. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
* Andreas Nilsson andrn...@gmail.com [2014-02-23 09:33]: Imho, the replacement to init and rc-scripts I sometimes think about would be to import SMF from opensolaris/illumos. There one can at least get the commands run and config used without looking at the source code. I like SMF from Solaris 11 onwards and even SmartOS. However, I have found to like systemd and use via systemctl on Arch far nicer than any other rc scripts to date. Anyone care to share their thoughts on the pros and cons of something like systemd the way Arch does? -- | _o_ |_)o_ _ _ |_|_|(_||_|_ | \|/_/_(_) - Lucius.Tel -- ++ Q: How many Bell Labs Vice Presidents does it take to change a light bulb? ++ ++ A: That's proprietary information. Answer available from ATT on payment ++ ++ of license fee (binary only). ++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
Typos and terseness brought to you by the LG G2 running SlimKat. On Feb 23, 2014 10:22 AM, Lucius Rizzo lucius.ri...@lucius.xxx wrote: * Andreas Nilsson andrn...@gmail.com [2014-02-23 09:33]: Imho, the replacement to init and rc-scripts I sometimes think about would be to import SMF from opensolaris/illumos. There one can at least get the commands run and config used without looking at the source code. I like SMF from Solaris 11 onwards and even SmartOS. However, I have found to like systemd and use via systemctl on Arch far nicer than any other rc scripts to date. Anyone care to share their thoughts on the pros and cons of something like systemd the way Arch does? The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. In theory, devd could be extended to support socket-activation, and the support for that added to RCng, providing the bulk of the systemd features, without having to deal with the systemd devs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On 2014-02-23 13:17, David Chisnall wrote: On 23 Feb 2014, at 18:11, Allan Jude free...@allanjude.com wrote: sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. The problem is, there is no such thing as an rc.conf style file. rc.conf is just a shell script. If you only edit it with sysrc, or you are careful to preserve the structure, then it's fine. There is absolutely nothing stopping you, however, from writing arbitrarily complex shell scripts inside rc.conf. Sure, it's a terrible idea to do so, but when has that ever stopped anyone? An rc-replacement could enforce this by only accepting purely declarative files for configuration, guaranteeing that if they were syntactically valid they would also be machine editable, no matter what the user does to them. David Just my $0.02: I don't believe our current RC is broken. It's faster than most, it supports an early-late divider, virtual targets (NETWORK, etc.), dependencies, etc. Rewriting scripts (units) in C has a non-trivial cost to customization for end users. I have custom, packaged, RC scripts in /usr/local that are pretty easy to add and maintain. Shell script logic can go there and not in rc.conf proper. The rcorder program provides a pretty good idea for when these can be run, and, as already pointed out, sysrc can be used to add/remove/configure these on clusters of (automatically) managed machines. If all scripts a properly written, service foo status can also provide something that can be acted upon by configuration management systems. Serialization is great (libnv), but it's just gravy. The only feature I see that's missing is (SMF-style) service management, but for hardware events, like losing a network link or a disk, can be plugged in to devd configuration, also easily. Also, in real-life deployments, shutting down service dependencies is not practical either. For example, if postfix crashes, I don't want to stop postgey or dovecot. I just want to nanny postfix back up rather than trying to bring up the whole stack. Also, forking a shell does not have any significant cost to it when bringing up something like MySQL, since it's a small fraction of where the system spends its time to bring up a useful service. Rewriting scripts in C doesn't provide service management or give any on-demand (inetd, read: launchd) functionality. - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On 23 Feb 2014, at 18:31, Freddie Cash fjwc...@gmail.com wrote: The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. I don't think that's a relevant discussion. The license would likely preclude systemd from making it into the base system anyway. Please let's not be too negative about the author of systemd: he's responsible for more people switching from Linux to FreeBSD than any other single individual I can think of and I would strongly encourage him to continue. The relevant question is whether it does anything in a way that is sufficiently sensible to merit a FreeBSD service management infrastructure doing it in the same (or a similar) way. Oh, two things missing from my original list: - Service jails should be able to run without an init process, with just the required libraries installed and the host machine's init system starting the jail and the service process(es) inside it. - The init system should use process descriptors, not pids, for tracking processes, preventing issues with pid reuse and so on (and removing the need to write pid files). If process descriptors do not provide the required functionality (e.g. the ability to trace forked children) then this should be added. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On 2014-02-23 13:47, David Chisnall wrote: On 23 Feb 2014, at 18:31, Freddie Cash fjwc...@gmail.com wrote: The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. I don't think that's a relevant discussion. The license would likely preclude systemd from making it into the base system anyway. Please let's not be too negative about the author of systemd: he's responsible for more people switching from Linux to FreeBSD than any other single individual I can think of and I would strongly encourage him to continue. I also noticed this. The relevant question is whether it does anything in a way that is sufficiently sensible to merit a FreeBSD service management infrastructure doing it in the same (or a similar) way. Oh, two things missing from my original list: - Service jails should be able to run without an init process, with just the required libraries installed and the host machine's init system starting the jail and the service process(es) inside it. Isn't this a bit too complicated? If there is an init script under $jail/usr/local/etc/rc.d, then the host init will need to find it, which can be even more complicated if rc search path in the jail is customized (prefixed if it's managed by a different department, for example). Host init will have to read the jail configuration, parse it too, and then manage children and pids of the jailed services, including reparenting, all within a jail context. Then the admin in that jail would need to be able to restart services, affecting host init, which opens a whole new can of worms. If init program is skinny and not too complicated, which it is, there is no tangible overhead. And if a jail really needs a single simple service, init process in the jail can *be* that, like jexec myjail /bin/sh -c somestuff (or even /usr/local/bin/myservice -c myservice conf). - The init system should use process descriptors, not pids, for tracking processes, preventing issues with pid reuse and so on (and removing the need to write pid files). If process descriptors do not provide the required functionality (e.g. the ability to trace forked children) then this should be added. This is a good idea. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2014 02:09 PM, Nikolai Lifanov wrote: On 2014-02-23 13:47, David Chisnall wrote: On 23 Feb 2014, at 18:31, Freddie Cash fjwc...@gmail.com wrote: The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. I don't think that's a relevant discussion. The license would likely preclude systemd from making it into the base system anyway. Please let's not be too negative about the author of systemd: he's responsible for more people switching from Linux to FreeBSD than any other single individual I can think of and I would strongly encourage him to continue. I also noticed this. The relevant question is whether it does anything in a way that is sufficiently sensible to merit a FreeBSD service management infrastructure doing it in the same (or a similar) way. Oh, two things missing from my original list: - Service jails should be able to run without an init process, with just the required libraries installed and the host machine's init system starting the jail and the service process(es) inside it. Isn't this a bit too complicated? If there is an init script under $jail/usr/local/etc/rc.d, then the host init will need to find it, which can be even more complicated if rc search path in the jail is customized (prefixed if it's managed by a different department, for example). Host init will have to read the jail configuration, parse it too, and then manage children and pids of the jailed services, including reparenting, all within a jail context. Then the admin in that jail would need to be able to restart services, affecting host init, which opens a whole new can of worms. If init program is skinny and not too complicated, which it is, there is no tangible overhead. And if a jail really needs a single simple service, init process in the jail can *be* that, like jexec myjail /bin/sh -c somestuff (or even /usr/local/bin/myservice -c myservice conf). - The init system should use process descriptors, not pids, for tracking processes, preventing issues with pid reuse and so on (and removing the need to write pid files). If process descriptors do not provide the required functionality (e.g. the ability to trace forked children) then this should be added. This is a good idea. David openrc already does this and runs on FreeBSD, ive been using it on 5 boxes in testing so far, clealy replaces init without breaking rc.conf configurations. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTCkyWAAoJEP7cFACJNhNalmgH/1hquNUT75g4xOGc8CX+RyVD kVYKW2SUgMOCCQwgXMydsZUafQ8kLSU24H8T9W2J/q2WDm1lWedqeO9/yk7t3pNS 8+c8YsTIuAYtPgiBES65YW667Cj9+FwN268fEqF58/WNS6kNx8snCfoRkvy6l7jN M62ajdNJtgSxF/Iwyfuq4W6REBW3CF4rL+g64OGrK8PQ6yPteJfM3CUGQoUlHXZC KHHY+qMYBSb/H0j9z7PzcpJsC/bb4fJRzccfVc34IV0ovdevLtQeJojTy4E55NhB kWTX1EDRYVxv9Zvy1uPut5qAtc0b+UB5sAPON0RGxBB0rzjzIYZXlieKo4s752w= =BXYO -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On 2/23/2014 10:31 AM, Freddie Cash wrote: The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. It's pretty clear Lennart Poettering failed history. Perhaps the best examples of why systemd is an anti-pattern is this: systemd stores logs in a binary journal. After the Linux zealots have spent about two decades using binary system data storage as one of the reasons Windows sucks, that strikes me as particularly ironic. The RC system we have is proof you do not need anything more than bourne and a respectable amount of intelligence to design a good init system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: libinit idea
-Original Message- From: David Chisnall [mailto:thera...@freebsd.org] Sent: Sunday, February 23, 2014 10:18 AM To: Allan Jude Cc: FreeBSD Current Subject: Re: libinit idea On 23 Feb 2014, at 18:11, Allan Jude free...@allanjude.com wrote: sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. The problem is, there is no such thing as an rc.conf style file. rc.conf is just a shell script. If you only edit it with sysrc, or you are careful to preserve the structure, then it's fine. Actually, sysrc is well aware that rc.conf is a shell script and sysrc will actually make certain that structure is preserved (regardless of whether you've placed shell code in rc.conf or not). There is absolutely nothing stopping you, however, from writing arbitrarily complex shell scripts inside rc.conf. Sure, it's a terrible idea to do so, but when has that ever stopped anyone? When sysrc is told to make a change, it first finds where it needs to make that change (/etc/rc.conf or /etc/rc.conf.local or one of other paths mentioned in rc_conf_files setting), it will refuse to edit the file *IF* the file doesn't first (before editing) pass a shell syntax check (using sh -n FILE). After making the changes in a temporarily file (produced with mktemp(1)), it again performs yet another syntax check (also using sh -n FILE) to make sure that it continues to yield clean syntax. On top of that, it makes certain not to muck with dynamic assignments. So it will leave-alone an assignment such as foo=$( bar ) if told to edit the variable foo -- instead opting to add a foo=newvalue after the dynamic assignment (logic is simple... sysrc wasn't responsible for putting that dynamic assignment in, so it is going to leave it as-is and put the new [static] assignment further below. So Allan was absolutely correct in stating that sysrc is for editing rc.conf style files -- shell scripts really. In essence, sysrc is actually a shell script modifying utility that takes extreme special care to rely on the fact that rc.conf *is* a shell script. An rc-replacement could enforce this by only accepting purely declarative files for configuration, guaranteeing that if they were syntactically valid they would also be machine editable, no matter what the user does to them. sysrc does this for you. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Linux chasing (Was: libinit idea)
Hello, Freddie. You wrote 23 февраля 2014 г., 22:31:48: FC The main developer for systemd is very anti-portability and anti-!Linux. He FC had actively rejected patches that made his projects work on non-Linux FC systems. In order to port systemd to a non-Linux system, he wants you to FC first implement every Linux feature that systemd uses. FC systemd is a non-starter, and not with considering. The problem is, next (or N+2) GNOME, KDE and X.org itself will depend on systemd, and, maybe, X.org will be discontinued at all for Wayland (or-what-is-name-of-this-technology), which will be even more Linux-centric. It is topic for other thread, but this chasing Linux in system features (hal/udev/systemd/whatever) needed for desktop environment is painful, and FreeBSD without decent modern DE will fail to attract new users :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Import of DragonFly Mail Agent
Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. To be honnest dma needs a bit of more work (improving the retry queue, capsicumize), but is working. I have read a couple of the past discussions about what are the requirements for base as a mailer (in case one want to remove sendmail) and yes dma is fulfilling all of them. That said I have never been a supporter of having a full mail server in base, as I consider a full mail server as being a specific use case so not required on all setup, in my opinion dma is the kind of mailer that fits better with base requirements. regards, Bapt pgpTLDKFX8PGm.pgp Description: PGP signature
Re: Linux chasing (Was: libinit idea)
On Sun, Feb 23, 2014 at 3:50 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Freddie. You wrote 23 февраля 2014 г., 22:31:48: FC The main developer for systemd is very anti-portability and anti-!Linux. He FC had actively rejected patches that made his projects work on non-Linux FC systems. In order to port systemd to a non-Linux system, he wants you to FC first implement every Linux feature that systemd uses. FC systemd is a non-starter, and not with considering. The problem is, next (or N+2) GNOME, KDE and X.org itself will depend on systemd, and, maybe, X.org will be discontinued at all for Wayland (or-what-is-name-of-this-technology), which will be even more Linux-centric. It is topic for other thread, but this chasing Linux in system features (hal/udev/systemd/whatever) needed for desktop environment is painful, and FreeBSD without decent modern DE will fail to attract new users :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org The convoluted hierarchy of Linux makes it a pain when working on software porting between Linux and any BSD system. There is more similarities between the BSD setup than between various Linux distributions. Take, for example, sound. It is a layer that has kernel access in FreeBSD. Even OSS has kernel level modules. In Linux there is sound, and alsa, and pulse, and bits of esound to make the system work. A bit of difference, eh? Look also at the implementation of NFS on Linux. They would have saved a lot of time doing an exact porting to Linux but that was ignored. NFSv3 is more common than NFSv4 because the latter in Linux is still in the developmental and porting stage. --Actually, it is easier to see the similarities between the NFS implementations and see the exact similarities than working with comparing sound between the systems.-- It is Linux chasing to be on an equal plane and it is the wrong way to do things. Recently CLang and GCC developers decided to forego the silliness proposed by Stallman and work together. A bad analogy no less but, it is still relevant. Why would anyone want to lock a system into a single piece or set of software unless they did not want development to continue in other areas. I, like other enthusiasts, prefer a system that is simple, stable, to the point, and easily configured. If one wants to use the idea as an alternative then by all means do so; but, do not make it a requirement, keep it as an option for those who want it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libinit idea
On 2014-02-23 17:04, Warner Losh wrote: On Feb 23, 2014, at 11:17 AM, David Chisnall thera...@freebsd.org wrote: On 23 Feb 2014, at 18:11, Allan Jude free...@allanjude.com wrote: sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. The problem is, there is no such thing as an rc.conf style file. rc.conf is just a shell script. If you only edit it with sysrc, or you are careful to preserve the structure, then it's fine. There is absolutely nothing stopping you, however, from writing arbitrarily complex shell scripts inside rc.conf. Sure, it's a terrible idea to do so, but when has that ever stopped anyone? An rc-replacement could enforce this by only accepting purely declarative files for configuration, guaranteeing that if they were syntactically valid they would also be machine editable, no matter what the user does to them. We already have a rc.conf.default. Why not a rc.conf.automation that does that and is added to the list of things to source? Then things like sysrc could operation on that secure in the knowledge that no shell commands could be there, and all bets are off if someone edits it by hand? Warner This is basically what we do, we have puppet add: rc_conf_files=/etc/rc.conf /etc/rc.conf.local /etc/rc.conf.scaleengine to rc.conf, and then we push our global config to the .scaleengine file -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: libinit idea
On Feb 23, 2014, at 11:17 AM, David Chisnall thera...@freebsd.org wrote: On 23 Feb 2014, at 18:11, Allan Jude free...@allanjude.com wrote: sysrc solves this nicely, it is in base now, and is great for programmatically adding, removing and changing lines in rc.conf style files. It is also in ports for older versions of FreeBSD where it is not in base. The problem is, there is no such thing as an rc.conf style file. rc.conf is just a shell script. If you only edit it with sysrc, or you are careful to preserve the structure, then it's fine. There is absolutely nothing stopping you, however, from writing arbitrarily complex shell scripts inside rc.conf. Sure, it's a terrible idea to do so, but when has that ever stopped anyone? An rc-replacement could enforce this by only accepting purely declarative files for configuration, guaranteeing that if they were syntactically valid they would also be machine editable, no matter what the user does to them. We already have a rc.conf.default. Why not a rc.conf.automation that does that and is added to the list of things to source? Then things like sysrc could operation on that secure in the knowledge that no shell commands could be there, and all bets are off if someone edits it by hand? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netstat: sysctl: net.route.0.0.dump.0: Cannot allocate memory
Ian FREISLICH i...@clue.co.za wrote
in e1wgmte-nr...@clue.co.za:
ia Hiroki Sato wrote:
ia Hm, how about the attached one?
ia
ia I think the cause is just a race when length of the sysctl's output
ia is changed in kernel after the buffer allocation in userspace, not
ia memory shortage. Size of the routing table can quickly change.
ia
ia You are correct. It's growing at about 9000 entries per second (I
ia wish it were faster).
ia
ia This is what the output looks like now. I guess I'm not the average
ia case.
Can you try the attached patch? It will attempt to enlarge the
buffer every retry.
-- Hiroki
Index: route.c
===
--- route.c (revision 262313)
+++ route.c (working copy)
@@ -69,6 +69,7 @@
#include sysexits.h
#include unistd.h
#include err.h
+#include errno.h
#include netstat.h
#define kget(p, d) (kread((u_long)(p), (char *)(d), sizeof (d)))
@@ -560,7 +561,7 @@
char *buf, *next, *lim;
struct rt_msghdr *rtm;
struct sockaddr *sa;
- int fam = 0, ifindex = 0, size;
+ int fam = 0, ifindex = 0, size, count = 0;
struct ifaddrs *ifap, *ifa;
struct sockaddr_dl *sdl;
@@ -600,6 +601,7 @@
freeifaddrs(ifap);
+retry:
mib[0] = CTL_NET;
mib[1] = PF_ROUTE;
mib[2] = 0;
@@ -607,19 +609,27 @@
mib[4] = NET_RT_DUMP;
mib[5] = 0;
mib[6] = fibnum;
- if (sysctl(mib, 7, NULL, needed, NULL, 0) 0) {
- err(1, sysctl: net.route.0.%d.dump.%d estimate, af, fibnum);
+ if (sysctl(mib, nitems(mib), NULL, needed, NULL, 0) 0)
+ err(EX_OSERR, sysctl: net.route.0.%d.dump.%d estimate, af,
+ fibnum);
+ needed += PAGE_SIZE * (count + 1);
+ if ((buf = malloc(needed)) == NULL)
+ errx(EX_OSERR, malloc(%zd), needed);
+ if (sysctl(mib, nitems(mib), buf, needed, NULL, 0) 0) {
+ if (errno == ENOMEM count++ 20) {
+ warnx(Routing table grew, retrying);
+ sleep(1);
+ free(buf);
+ goto retry;
+ } else
+ err(EX_OSERR, sysctl: net.route.0.%d.dump.%d, af,
+ fibnum);
}
-
- if ((buf = malloc(needed)) == 0) {
- errx(2, malloc(%lu), (unsigned long)needed);
- }
- if (sysctl(mib, 6, buf, needed, NULL, 0) 0) {
- err(1, sysctl: net.route.0.%d.dump.%d, af, fibnum);
- }
lim = buf + needed;
for (next = buf; next lim; next += rtm-rtm_msglen) {
rtm = (struct rt_msghdr *)next;
+ if (rtm-rtm_version != RTM_VERSION)
+ continue;
/*
* Peek inside header to determine AF
*/
@@ -632,6 +642,7 @@
}
p_rtentry_sysctl(rtm);
}
+ free(buf);
}
static void
pgpysH23oo8lh.pgp
Description: PGP signature
Re: Import of DragonFly Mail Agent
On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin b...@freebsd.orgwrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. But is it an eventual goal? *I* don't see why not, but if it is: what's the plan? How is the decision to drop sendmail going to be made when the time comes? (I.e. who _can_ and will make the call?) All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. Playing devil's advocate: what specific problems is this trying to solve? I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. (Which, by the way, is the configuration with which postfix ships within the NetBSD base system.) The reason I'm asking these questions is because I have seen NetBSD maintain two MTAs (sendmail + postfix) in the base system for _years_ and it was not a pretty situation. The eventual removal of sendmail was appreciated, but of course it came with the associated bikeshedding. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Sun, Feb 23, 2014 at 11:26:20PM -0500, Julio Merino wrote: On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin b...@freebsd.orgwrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. But is it an eventual goal? *I* don't see why not, but if it is: what's the plan? How is the decision to drop sendmail going to be made when the time comes? (I.e. who _can_ and will make the call?) Anyone at anytime can call for this ;) if some bits are missing in dma to achieve this goal I m willing to implement them. All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. Playing devil's advocate: what specific problems is this trying to solve? I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. (Which, by the way, is the configuration with which postfix ships within the NetBSD base system.) The reason I'm asking these questions is because I have seen NetBSD maintain two MTAs (sendmail + postfix) in the base system for _years_ and it was not a pretty situation. The eventual removal of sendmail was appreciated, but of course it came with the associated bikeshedding. I do understand that, one of the goal of this mail is also to get feedback from users about what they do expect, is dma fulfilling they normal requirememts for a local mailer in general purpose cases, if yes I do not see a reason not to remove sendmail from base. Usual complains about sendmail in base until now has been: - complex configuration - long history of security concerns - no need for a full mta in base regards, Bapt pgpbUcWzeaRsB.pgp Description: PGP signature
