Re: RCTL and VIMAGE for 11.0-RELEASE
Bjoern A. Zeeb wrote: On 24 Aug 2015, at 19:08 , Mark Felder wrote: What is preventing RCTL from being enabled right now? Any known/serious blockers? It’s enabled in GENERIC. And the same for VIMAGE? I know there were issues with some firewalls, but I'm not sure where that stands today. Does it degrade network performance in a measurable way? Ignoring performance for a second, there is more than just firewalls that needs to be done. I started writing a plan for the next 4 months yesterday. Most of this was done a few years ago and never made it to HEAD. It needs to be re-validated. If my plan comes together we’ll have another 4 month window before the 11 release cycle will start. /bz It's been 5 months since the above was posted. What is the status of VIMAGE as part of base in 11.0-RELEASE? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HPN and None options in OpenSSH
On 22/01/2016 10:31 PM, Dag-Erling Smørgrav wrote: The HPN and None cipher patches have been removed from FreeBSD-CURRENT. I intend to remove them from FreeBSD-STABLE this weekend. The HPN patches were of limited usefulness and required a great deal of effort to maintain in our tree. The None cipher patch was less onerous, but it was a terrible idea with a very small user base since it was a compile-time option and off by default. The HPN-related configuration variables have been marked deprecated, while those related to the None cipher have been marked unsupported. This means that the former will be accepted with a warning, whereas the latter will result in an error. Most users will not be affected by this change. Those who are should switch to the openssh-portable port, which still offers both patches, with HPN enabled by default. It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a number of modifications intended to reduce the impact of upstream changes on existing systems. what is the internal window size in the new ssh? DES ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: IoT OS
>Say all objects are connected peer to peer with wifi, some of them are >connected to internet through gsm network or wifi to a box. >These object are moving in space, and for some reasons, connections are >dynamical and can be severely impaired or lost. > >They have incoming local streams of data (eg HD videos, accelerometer, GPS, >other wifi and gsm signals, etc). > >I would like to abstract the CPU layer, storage layer, and internet connection >so that in realtime results of one of my objects are saved >if this object dies, so that if one of the object giving internet access to >the group loose its connection, the redundancy allows the group of object not >to lose internet connection. > >Can I consider these as different load balancing layers ? Do you recommend to >implement this at the kernel layer or at an API layer ? >Can I see that as a lightweight cluster ? > >I think the API is more flexible, especially if I have an heterogeneous (by >CPU, OS) set of connected object. However, working at the kernel level allows >existing programs not to be rewritten. >What are your thoughts ? === OK, I think I understand your question now. This isn't the right list for it, though I'm not sure where the right place to go would be -- it's not FreeBSD-specific, in any case. There are academic research groups looking into this type of problem; for instance, in the area of sensor networks (ACM Transactions on Sensor Networks covers some of these areas). There may be USENET groups which cover this area. To cover your three areas, which I think require somewhat different solutions -- (a) CPU layer. I don't really recommend trying to abstract this. You could use a virtual machine to hide the underlying architecture, and checkpoint state periodically, but this is likely to slow down execution too much to be useful. If the issue that a service may become unavailable, I'd recommend a middleware layer which can detect this and recover by starting a new instance of the service. Middleware layers like ZeroMQ, and clustering software, may be a useful starting point. This does mean that stateful connections (like reading a video stream) won't recover cleanly, though; the client would need to reconnect to attach to the new instance of the service. If you really need that, it's going to be hard. (b) Storage layer. Look into highly-available clustered storage solutions. If you can use key-value or some other simplified storage model, do it. There are clustered file systems but probably none freely available that would work on the scale you envision and give decent performance. There are more alternatives if you're flexible about the format in which you're storing data (e.g. replicated object stores). (c) Networking layer; or internet. If you can drop & re-establish a connection, or if every node has its own IP address (IPv6), this should be pretty straightforward; software could detect loss of connection and change the routing used to go through a different system. If not, you'll be a bit limited since mirroring TCP state between nodes would be too slow. This is a case where the existing operating system kernels are likely to do most of what you need; you simply need to add a layer to detect routing problems and select a new internet gateway appropriately. I'd avoid implementing any clustering within the kernel, in part because if you have a wide variety of objects you may not want the same kernel on all of them, and in part because debugging & recovery is much harder. You're unlikely to want to run most existing software on such a system anyway (especially if they have relatively weak processors); you're better off writing to a set of clustering APIs for storage and state, at least. For networking, as mentioned, you can likely use the existing TCP stack & just add controls to redirect traffic as needed. -- Anton ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HPN and None options in OpenSSH
The HPN and None cipher patches have been removed from FreeBSD-CURRENT. I intend to remove them from FreeBSD-STABLE this weekend. The HPN patches were of limited usefulness and required a great deal of effort to maintain in our tree. The None cipher patch was less onerous, but it was a terrible idea with a very small user base since it was a compile-time option and off by default. The HPN-related configuration variables have been marked deprecated, while those related to the None cipher have been marked unsupported. This means that the former will be accepted with a warning, whereas the latter will result in an error. Most users will not be affected by this change. Those who are should switch to the openssh-portable port, which still offers both patches, with HPN enabled by default. It is expected that FreeBSD 10.3 will ship with OpenSSH 7.1p2, with a number of modifications intended to reduce the impact of upstream changes on existing systems. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Too low PTHREAD_STACK_MIN value?
On 21 Jan 2016, at 16:02, Ed Maste wrote: > > I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal > handler thread it creates[1]. They found it was too small and > implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if > this isn't really the intended use of PTHREAD_STACK_MIN it suggests > the 2K x86 minimum may indeed be too low. > > I ran into this while trying LLVM's libunwind, which requires more > stack space. 2K is certainly too low with LLVM libunwind. Is it > reasonable to just increase it to say 8K? I don’t really like this solution. PTHREAD_STACK_MIN is the size for a stack that does not do anything. You should never use it without adding the amount that you are going to need (which might be nothing if you are running code from a language that does not use a conventional C-style stack, but still wants to use OS threads). Making it larger because a specific kind of thing that some consumers want to do with it needs more space is definitely against the spirit of the value and potentially harmful as it means that people using it correctly will be using a lot more memory per thread. David ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LibreOffice doesn't work anymore
On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during > > 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > > found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from > > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and > > "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? > > If yes, update to at least r294470. Works for me again on r294556. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IoT OS
On 22/01/2016 2:08 AM, Mathieu Prevot wrote: 2016-01-21 17:38 GMT+01:00 NGie Cooper : On Jan 21, 2016, at 08:34, Jan Bramkamp wrote: On 21/01/16 17:19, Mathieu Prevot wrote: Dear all, I would like to connect several connected object (with homogeneous or heterogenous hardare: intel edison, samsung artik, apple AX, intel core, etc) so the calculation needs, the storage/memory, the connection, etc are decoupled; hence we can reach an ecosystem with several clouds. How do you recommend to reach that ? from the kernel, a module, or eventually a software ? Your message contains neither enough information nor a precise enough question for anyone to provide you a helpful answer. Please describe your problem in sufficient detail and reformulate your question. If you still think these mailing lists (current@ and hackers@) are a good audience for your question afterward ask them again. It depends on your workload and hardware requirements (there isn't a simple answer to your question because you didn't describe what you needed with concrete requirements). I would talk to cem@. He's working on ioat(4) on head for us ($work). Thanks, -NGie Say all objects are connected peer to peer with wifi, some of them are connected to internet through gsm network or wifi to a box. These object are moving in space, and for some reasons, connections are dynamical and can be severely impaired or lost. They have incoming local streams of data (eg HD videos, accelerometer, GPS, other wifi and gsm signals, etc). I would like to abstract the CPU layer, storage layer, and internet connection so that in realtime results of one of my objects are saved if this object dies, so that if one of the object giving internet access to the group loose its connection, the redundancy allows the group of object not to lose internet connection. Can I consider these as different load balancing layers ? Do you recommend to implement this at the kernel layer or at an API layer ? Can I see that as a lightweight cluster ? I think the API is more flexible, especially if I have an heterogeneous (by CPU, OS) set of connected object. However, working at the kernel level allows existing programs not to be rewritten. What are your thoughts ? Do you recommend another list ? This is still very hard to understand. Are you planning to work with some API that is described in a document somewhere? if so please give links. Thanks ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LibreOffice doesn't work anymore
On Fri, Jan 22, 2016, Konstantin Belousov wrote: > On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > > Hello! > > > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > > dumps with the following message: > > > > GLib (gthread-posix.c): Unexpected error from C library during > > 'pthread_key_create': Function not implemented. Aborting. > > > > Here is the backtrace: > > > > GNU gdb 6.1.1 [FreeBSD] > > ... > > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > > found)... > > Core was generated by `soffice.bin'. > > Program terminated with signal 6, Aborted. > > Reading symbols from > > /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols > > found)...done. > > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > > ... > > (skipped lots of "Reading symbols ... (no debugging symbols found)" and > > "Loaded symbols ..." strings) > > ... > Did you skipped the message about libthr.so.3 ? Yes, there was message about libthr.so.3 in omitted part. > > If yes, update to at least r294470. > Ok. Started updating to r294556. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LibreOffice doesn't work anymore
On Fri, Jan 22, 2016 at 11:17:08AM +0300, Vladimir Zakharov wrote: > Hello! > > Updating from r294203 to r294460 has broken LibreOffice. Now LO core > dumps with the following message: > > GLib (gthread-posix.c): Unexpected error from C library during > 'pthread_key_create': Function not implemented. Aborting. > > Here is the backtrace: > > GNU gdb 6.1.1 [FreeBSD] > ... > This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols > found)... > Core was generated by `soffice.bin'. > Program terminated with signal 6, Aborted. > Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no > debugging symbols found)...done. > Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 > ... > (skipped lots of "Reading symbols ... (no debugging symbols found)" and > "Loaded symbols ..." strings) > ... Did you skipped the message about libthr.so.3 ? If yes, update to at least r294470. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LibreOffice doesn't work anymore
Hello! Updating from r294203 to r294460 has broken LibreOffice. Now LO core dumps with the following message: GLib (gthread-posix.c): Unexpected error from C library during 'pthread_key_create': Function not implemented. Aborting. Here is the backtrace: GNU gdb 6.1.1 [FreeBSD] ... This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `soffice.bin'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libreoffice/program/libuno_sal.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libreoffice/program/libuno_sal.so.3 ... (skipped lots of "Reading symbols ... (no debugging symbols found)" and "Loaded symbols ..." strings) ... Reading symbols from /usr/local/lib/libtasn1.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libtasn1.so.6 Reading symbols from /usr/local/lib/libnettle.so.4...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libnettle.so.4] Reading symbols from /usr/local/lib/libhogweed.so.2...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 3, should be 2) [in module /usr/local/lib/libhogweed.so.2] Reading symbols from /usr/local/lib/libgmp.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgmp.so.10 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800dc9b0a in thr_kill () from /lib/libc.so.7 [New LWP 100189] (gdb) -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"