Re: sanitizers broken (was RE: libc/libsys split coming soon)

On 21 Feb 2024, at 20:00, Brooks Davis wrote: > > The sanitizers reach somewhat questionably into libc internals that are > exported to allow rtld to update them. I was unable to find an solution > that didn't break this and I felt that fixing things like closefrom() > using non-deprecated

Re: libc/libsys split coming soon

On 3 Feb 2024, at 09:15, Mateusz Guzik wrote: > > Binary startup is very slow, for example execve of a hello world > binary in a Linux-based chroot on FreeBSD is faster by a factor of 2 > compared to a native one. As such perf-wise this looks like a step in > the wrong direction. Have you

Re: How to upgrade an EOL FreeBSD release or how to make it working again

On 15 Jan 2024, at 16:46, Mario Marietto wrote: > > The ARM Chromebook is based on armv7,it is still recent. For reference, the ARMv7 architecture was introduced in 2005. The last cores that implemented the architecture were released in 2014. This is not a ‘recent’ architecture, it’s one

Re: Move u2f-devd into base?

On 8 Jan 2024, at 16:30, Tomoaki AOKI wrote: > > So it should be in ports to adapt for latest products more quickly than > in base, I think. We push out a new release of each of the -STABLE branches every 6 months and can do ENs if a product ships and becomes popular in under six months. This

Re: Continually count the number of open files

On 12 Sep 2023, at 17:19, Bakul Shah wrote: > > FreeBSD > should add inotify. inotify is also probably not the right thing. If someone is interested in adding this, Apple’s fsevents API is a better inspiration. It is carefully designed to ensure that the things monitoring for events can’t

Re: The future for support of BeagleBone Black and its variants

Hi, What are the changes to the DTS files? If there are problems with DTC handling the new files, please can you raise issues here: https://github.com/davidchisnall/dtc/issues If there are problems with the kernel’s handling of the dtb, please ignore me. David > On 10 Aug 2023, at 13:24,

Re: Review of patch that uses "volatile sig_atomic_t"

On 2 Aug 2023, at 00:33, Rick Macklem wrote: > > Just trying to understand what you are suggesting... > 1 - Declare the variable _Atomic(int) OR atomic_int (is there a preference) > and > not volatile. Either is fine (the latter is a typedef for the former). I am not a huge fan of the

Re: Review of patch that uses "volatile sig_atomic_t"

Hi, This bit of the C spec is a bit of a mess. There was, I believe, a desire to return volatile to its original use and make any use of volatile other than MMIO discouraged. This broke too much legacy code and so now it’s a confusing state. The requirements for volatile are that the compiler

Re: Surprise null root password

On 30/05/2023 20:11, Dag-Erling Smørgrav wrote: David Chisnall writes: There was a very nasty POLA violation a release or two ago. OpenSSH defaults to disallowing empty passwords and so having a null password was a convenient way of allowing people to su or locally log into that user

Re: Surprise null root password

On 27 May 2023, at 03:52, Mike Karels wrote: > > On 26 May 2023, at 21:28, bob prohaska wrote: > >> It turns out all seven hosts in my cluster report >> a null password for root in /usr/src/etc/master.passwd: >> root::0:0::0:0:Charlie &:/root:/bin/sh >> >> Is that intentional? > > Well, it

Re: GitHub Code Search [Re: Tooling Integration and Developer Experience]

On 01/02/2023 06:05, Yetoo wrote: On Tue, Jan 31, 2023, 9:47 AM David Chisnall wrote: On 30/01/2023 21:39, Yetoo wrote: If github is going to be considered for issue tracking I just want to say, after having extensively using it for issue tracking, it tends to be difficult to find an issue

GitHub Code Search [Re: Tooling Integration and Developer Experience]

On 30/01/2023 21:39, Yetoo wrote: If github is going to be considered for issue tracking I just want to say, after having extensively using it for issue tracking, it tends to be difficult to find an issue if the exact title isn't entered and many duplicate reports are made as a result. Code

Re: Header symbols that shouldn't be visible to ports?

On 7 Sep 2022, at 15:55, Cy Schubert wrote: > > This is exactly what happened with DMD D. When 64-bit statfs was introduced > all DMD D compiled programs failed to run and recompiling didn't help. The > DMD upstream failed to understand the problem. Eventually the port had to > be removed.

Re: Accessibility in the FreeBSD installer and console

On 08/07/2022 13:18, Stefan Esser wrote: Am 08.07.22 um 12:53 schrieb Hans Petter Selasky: Hi, Here is the complete patch for Voice-Over in the FreeBSD console: https://reviews.freebsd.org/D35754 You need to install espeak from pkg and then install the /etc/devd/accessibility.conf file and

Re: Deprecating ISA sound cards

On 19 Mar 2022, at 21:24, Chris wrote: > > On 2022-03-18 09:08, Ed Maste wrote: >> ISA sound cards have been obsolete for more than a decade, and it is >> (past) time to retire their drivers. This includes the following >> drivers/devices: >> snd_ad1816 Analog Devices AD1816 SoundPort >>

Re: Dragonfly Mail Agent (dma) in the base system

On 30/01/2022 14:01, michael.osi...@siemens.com wrote: Sendmail: The biggest problem is that authentication strictly requires Cyrus SASL, even for stupid ones like PLAIN/LOGIN, accourding to the handbook you must recompile sendmail from base with Cyrus SASL from ports to make this possible. A

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

On 22/01/2022 23:20, Rick Macklem wrote: Mark Saad wrote: [stuff snipped] So I am looking at the Apple and Solaris code, provided by rick. I am not sure if the illumos code provides SMB2 support. They based the solaris code on Apple SMB-217.x which is from OSX 10.4 . Which I am sure predates

Re: Benchmarks: FreeBSD 13 vs. NetBSD 9.2 vs. OpenBSD 7 vs. DragonFlyBSD 6 vs. Linux

While I agree on most of your points, the value of Phoronix is that it tests the default install. As an end user, I don’t care that a particular program is twice as fast on a particular Linux distro as it is on FreeBSD because of kernel features, compiler options, or dependency choices. I

Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined)

On 02/12/2021 09:51, Dimitry Andric wrote: Apparently the "block runtime" is supposed to provide the actual object, so I guess you have to explicitly link to that runtime? The block runtime provides this symbol. You use this libc API, you must be compiling with a toolchain that supports

Re: VDSO on amd64

Great news! Note that your example of throwing an exception from a signal handler works because the signal is delivered during a system call. The compiler generates correct unwind tables for calls because any call may throw. If you did something like a division by zero to get a SIGFPE or a

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

On 28/10/2021 16:26, Shawn Webb wrote: I wonder if providing a 9pfs client would be a good step in helping deprecate smbfs. Note: WSL2 uses 9p-over-VMBus, but most of the Linux world is moving away from 9p-over-VirtIO to FUSE-over-VirtIO. This has a few big advantages: - The kernel

Re: FreeBSD base pkg (packaging) and critical ports build alongside

Hi, I think your best option would be to do the opposite of what you suggest. Poudriere can build pkgbase sets from a source tree and populate a jail from them. The flow that I'd suggest is: - Poudriere jail to build a jail from an existing source tree. - If there are kernel changes,

Re: Building ZFS disk images

On 05/08/2021 15:06, David Chisnall wrote: Would poudriere work for you? man poudriere-image Wow, there's a lot of stuff I didn't know poudriere could do!  It looks as if it can produce a GPT partition table with all of the bootable bits, or it can produce a ZFS disk image.  I guess

Re: -CURRENT compilation time

On 09/09/2021 00:04, Tomoaki AOKI wrote: devel/ninja/Makefile has USES= python in it, so it maybe require python to run or at least build. You could probably remove that line without anyone noticing. Ninja uses Python for precisely one thing (or, at least, did last time I looked): There is

Re: -CURRENT compilation time

On 08/09/2021 11:52, Gary Jennejohn wrote: Seems to me that there was an earlier mail about getting CMAKE to work with FreeBSD builds. Could be worthwhile to look into getting ninja to work also. But I could understand that there might be push-back, since the project prefers to use utilities

Re: -CURRENT compilation time

On 07/09/2021 18:02, Stefan Esser wrote: Wouldn't this break META_MODE? I have never managed to get META_MODE to work but my understanding is that META_MODE is addressing a problem that doesn't really exist in any other build system that I've used: that dependencies are not properly

Re: -CURRENT compilation time

On 06/09/2021 20:34, Wolfram Schneider wrote: With the option WITHOUT_TOOLCHAIN=yes the world build time is 2.5 times faster (real or user+sys), down from 48 min to 19.5 min real time. Note that building LLVM with the upstream CMake + Ninja build system is *significantly* faster on a decent

Re: Move the Handbook into source tree

Hi, I think there are two conflated things here: - Moving the handbook into the source tree. - Creating branches in the handbook that track particular releases. The first one is largely irrelevant to anyone other than people contributing to the handbook, so I'll focus on the second: This

Re: -CURRENT compilation time

On 06/09/2021 09:08, Jeremie Le Hen wrote: Compiling C++ seems extremely CPU heavy and this is made worse by the fact LLVM is built twice (once for build/cross tools, once for the actual world). Note that you need to build LLVM twice only if you are actively debugging LLVM reproduceable

Re: ses ioctl API/ABI stability

On 25/08/2021 22:19, Alan Somers wrote: We usually try to maintain backwards compatibility forever. But is that necessary for the ses(4) ioctls? There are several problems with them as currently defined. They lack type safety, lack automatic copyin/copyout handling, and one of them can

Tooling for UCLification

Hi everyone, A few years ago at BSDCam I started working on a tool that would parse data structures using libclang and provide libucl wrappers for serialising and deserialising the code. After working on it for a bit, I came to the conclusion that the approach was the wrong way around and

Re: Building ZFS disk images

On 05/08/2021 13:53, Alan Somers wrote: I don't know of any way to do it using the official release scripts either. One problem is that every ZFS pool and file system is supposed to have a unique GUID.  So any kind of ZFS release builder would need to re-guid the pool on first boot. Is there

Re: Building ZFS disk images

need to re-guid the pool on first boot. On Thu, Aug 5, 2021, 6:41 AM David Chisnall wrote: Hi, Does anyone know how to build ZFS disk images from any existing tooling? I haven't used UFS for over a decade now and the official cloud images are all UFS, so I end up doing an install from the CD ISO

Building ZFS disk images

Hi, Does anyone know how to build ZFS disk images from any existing tooling? I haven't used UFS for over a decade now and the official cloud images are all UFS, so I end up doing an install from the CD ISO into Hyper-V locally and then exporting the VHD, but that can't be the most efficient

Re: PATH: /usr/local before or after /usr ?

On 16/07/2021 16:50, Cameron Katri via freebsd-current wrote: On Fri, Jul 16, 2021 at 09:01:49AM -0600, Alan Somers wrote: FreeBSD has always placed /usr/local/X after /usr/X in the default PATH. AFAICT that convention began with SVN revision 37 "Initial import of 386BSD 0.1 othersrc/etc". Why

Re: WSLg update on 1-5-2021 - BSD / WSL

On 09/05/2021 04:55, Daniel Nebdal wrote: On Thu, 6 May 2021 at 19:05, David Chisnall wrote: [ Disclaimer: I work for Microsoft, but not on WSL and this is my own opinion ] (...) David Just as a counterpoint to Rozhuk's take, that all sounds sensible enough to me - FreeBSD would probably

Re: Building ZFS-based VM images

On 06/05/2021 16:17, Alan Somers wrote: It's easy to build a UFS-based VM image just by setting WITH_VMIMAGES in release.conf and running release.sh. But what about ZFS-based images? What's the easiest way to build a ZFS-based VM image, using a pool layout similar to what the interactive

Re: WSLg update on 1-5-2021 - BSD / WSL

On 07/05/2021 11:17, Rozhuk Ivan wrote: On Thu, 6 May 2021 10:57:16 +0100 David Chisnall wrote: Whether Microsoft or the FreeBSD project should do the work really comes down to who has more to gain. Windows 10 is installed on around a 1.3 billion devices and any of these users can run

Re: WSLg update on 1-5-2021 - BSD / WSL

On 03/05/2021 22:37, Pete Wright via freebsd-current wrote: On 5/1/21 12:42 PM, Chargen wrote: Dear all please note that I hope this message will be discussed to get this on the roadmap for FreeBSD. Perhaps there is already talk about &&  work done on that. I would like to suggest having a BSD

Re: Stop installing /usr/bin/clang

On 16/08/2019 10:10, Konstantin Belousov wrote: You did not read neither review summary nor followups. This is needlessly insulting and this kind of attitude from you towards people on the mailing lists is one of the main reasons that my engagement with the FreeBSD project tends to be in

Re: Stop installing /usr/bin/clang

On 15/08/2019 17:48, Konstantin Belousov wrote: > Please look at https://reviews.freebsd.org/D21060 > I propose to stop installing /usr/bin/clang, clang++, clang-cpp. > > It probably does not matter when all your software comes from ports or > packages, but is actually very annoying when

Re: FreeBSD Core Team Response to Controversial Social Media Posts

On 19 May 2019, at 20:43, Igor Mozolevsky wrote: > > the best > explanation of democracy I have ever heard was: "two wolves and a > sheep deciding what to have for dinner!" If you believe that this quote in any way supports your argument, then I would suggest that you work through the game

Re: CFT: FreeBSD Package Base

On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but

Re: CFT: FreeBSD Package Base

On 29/04/2019 14:19, Lev Serebryakov wrote: I'm not very interested in packetized base for "big servers" which contains full FreeBSd installation 'Big servers' may have a full FreeBSD installation in the base system, but they may also have hundreds of jails that want the absolute minimum

Re: Building freebsd on another OS

On 19/03/2019 00:01, Eric Joyner wrote: On Sun, Mar 17, 2019 at 6:35 AM Hans Petter Selasky wrote: See the freebsd-build utils package for Linux. --HPS Is there anything for Windows? Your best bet on Windows is to use the Windows Subsystem for Linux (WSL). This lets you install a

Re: GNU binutils 2.17.50 retirement planning

On 23 Nov 2018, at 16:23, Ed Maste wrote: > > For some time we have been incrementally working to retire the use of > obsolete GNU Binutils 2.17.50 tools. At present we still install three > binutils by default: > > as > ld.bfd > objdump We probably need to kill ld.bfd before 12.0. It

Re: Warnings about dlclose before thread exit. __cxa_thread_call_dtors

The FreeBSD implementation here looks racy. If one thread dlcloses an object while another thread is exiting, we can end up calling a function at an invalid memory address. It also looks as if it may be possible to unload one library, load another at the same address, and end up executing

Re: clang manual page?

On 6 Apr 2018, at 01:30, Pete Wright wrote: > > > On 04/05/2018 17:15, Steve Kargl wrote: >> This assumes that a gcc(1) is available on the system. >> >> % man gcc >> No manual entry for gcc >> >> If the system compiler is clang/clang++, then it ought to be >> documented

Re: atomic in i386 Current after CLANG 6 upgrade

On 15 Jan 2018, at 17:00, Jan Beich wrote: > > It wouldn't help (see below). Clang 6 accidentally made __atomic* work > enough to satisfy configure check but not for the port to build. I guess, > it also confuses configure in net/librdkafka and net-mgmt/netdata. > Can we

Re: inconsistent for() and while() behavior when using floating point

On 15 Jan 2018, at 14:49, Hans Petter Selasky wrote: > > The "seq" utility should use two 64-bit integers to represent the 10-base > decimal number instead of float/double. And then you need to step this pair > of integers. As the saying goes: > Sometimes, people think 'I

Re: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

On 10 Jan 2018, at 18:53, Baptiste Daroussin wrote: > > I need to figure out a mechanism to make this simpler to handle to upgrade of > base system while keeping this safety belt for users. > > Any idea is welcome I believe the apt approach to this is to have a different verb

Re: Programmatically cache line

On 5 Jan 2018, at 02:46, Jon Brawn wrote: > This idea of Arm big.LITTLE systems having cache lines of different lengths > really, really bothers me - how on earth is the cache coherency supposed to > work in such a system? I doubt the usual cache coherency protocols would work

Re: Programmatically cache line

On 3 Jan 2018, at 22:12, Nathan Whitehorn wrote: > > On 01/03/18 13:37, Ed Schouten wrote: >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : >> On x86, the CPUID instruction leaf 0x1 returns the information in >> %ebx register. > Hm,

Re: Programmatically cache line

On 1 Jan 2018, at 05:09, Adrian Chadd wrote: > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: >> On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote: >>> Is there some way to programmatically get the CPU cache line sizes on

Re: libfuzzer support

On 24 Oct 2017, at 10:29, Kurt Jaeger wrote: > >> >> is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD >> head? >> It seems that it is not supported by /usr/bin/clang... >> >> Am I wrong and it is supported or is someone working on it? > > I

Re: There is *NO* abi stability in -head

On 23 Oct 2017, at 21:35, Mateusz Guzik wrote: > > Instead, the same can be reshuffled: > struct crap2 { >int i1; >int i2; >void *p1; >void *p2; > }; > > With offsets: > > 0x1000 i1 > 0x1004 i2 > 0x1008 p1 > 0x1010 p2 > > This is only 24

Re: [RFC] future of drm1 in base

On 3 Sep 2017, at 06:31, Cy Schubert wrote: > > Thanks for the heads up Johannes. I currently have three machines that each > run ATI r128, mach64 and the last one an mga card. I normally use my i945 > and i915 laptops (mostly the former) but on occasion I may fire up

Re: svn commit: r322875 - head/sys/dev/nvme

On 25 Aug 2017, at 07:32, Mark Millard wrote: > > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for the implementation. sys/cdefs.h defines it to generate a zero-length array if the

Re: swapfile query

On 19 Aug 2017, at 17:54, Cy Schubert wrote: > >> 3. should total swap be 1x 2x or some other multiple of RAM these days? > > Depends. If you're running some kind of database server or OLTP > application. Some vendors recommend no swap whatsoever while others >

Re: [libelftc] internal library or not?

On 1 Aug 2017, at 12:36, Michael Zhilin wrote: > > Hi Ed, freebsd-current, > > I want to add C++ demangling into sysutils/pstack. In man pages I've found > eltfc_demangle, exact what I need. This function belongs to libelftc. "make > installworld" installs man pages and

Re: libstdc++ build failures on MIPS, PowerPC, Sparc

On 23 Jul 2017, at 23:54, Mark Millard wrote: > >>c++ -isystem ${OUTDIR}/tmp/usr/include/c++/v1 -std=c++11 -nostdinc++ >> -isystem ${OUTDIR}/tmp/usr/include -L${OUTDIR}/tmp/usr/lib >> -B${OUTDIR}/tmp/usr/lib --sysroot=${OUTDIR}/tmp -B${OUTDIR}/tmp/usr/bin -O >>

Re: Getting PID of socket client

On 9 Jul 2017, at 14:25, Stefan Ehmann wrote: > > Don't why the structs are not compatible, maybe because: > "The process ID cmcred_pid should not be looked up (such as via the > KERN_PROC_PID sysctl) for making security decisions. The sending process > could have exited and

Re: [libltdl] removal from gnu ports

On 7 Jun 2017, at 10:33, blubee blubeeme wrote: > > Hi > > I'm sure I was reading yesterday on a different machine about the linker > flag -ld which has something to do with gnu dlopen and how it's ok to > remove those from your Makefile since FreeBSD handles dlopen and a

Re: build src with colored output?

On 16 May 2017, at 07:42, Johannes Lundberg wrote: > > Gonna answer myself here. Think I found a way. > > Add CFLAGS=-fcolor-diagnostics to env or /etc/src.conf > Do clean build, that is no -DNO_CLEAN,KERNFAST, etc. > > Makes it a lot easier to find the errors in a 16

Re: libstd++ missing in drm-next-4.7

On 20 Jan 2017, at 14:06, Christian Schwarz wrote: > > I know clang is no longer built and installed as part of buildworld in > the FreeBSDDesktop repo, > but why isn't libstd++ present? > > … > > clang39 # now run clang, won't work, see below > Shared object

Re: vt(4) chops off the leftmost three columns

On 13 Jan 2017, at 01:00, Ernie Luzar wrote: > > VT should have had better testing before becoming the default in 11.0. The choice was VT or no acceleration in X11, because all of the new DRI drivers depend on KMS, which requires VT. We only got VT in a useable state (and

Re: Is there possible run a MacOS X binary

On 5 Dec 2016, at 19:31, Kevin P. Neal wrote: > >> Is there any emulator like linuxator to run Mac OS X binaries, or >> is ther any licensing problem? > > It may be possible to make an emulator for Darwin (the OS that Mac OS sits > on top of), but an emulator for Mac OS

Re: Optimising generated rules for SAT solving (5/12 are duplicates)

On 23 Nov 2016, at 18:11, A. Wilcox wrote: > > Or you could just, I don't know, email the diff as a patch using git > send-email like normal people instead of using GitHub's walled garden. > That way, people without GitHub accounts can still comment on it. GitHub pull

Re: how to reduce the size of /usr/share/i18n data?

On 3 Nov 2016, at 19:34, Rodney W. Grimes wrote: > > Depressing fact: The i18n directory alone is larger than > a full 386BSD 0.1+sources+patchkit install. Is the depressing thing here that even something as recent as 386BSD 0.1 assumed that ASCII was

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

On 24 Jul 2016, at 12:42, David Chisnall <thera...@freebsd.org> wrote: > > I’ve now fixed both of these in the version here: > > https://github.com/davidchisnall/dtc Andy filed a number of issues on GitHub, which are now all fixed. In particular, /include/ should n

Re: Wayland work status

On 12 Aug 2016, at 00:18, Lundberg, Johannes wrote: > > Currently by default evdev create /dev/input/eventX devices with 600 > permission. These need to be accessible for non-root users. What is the > best solution? Should we create a "input" group similar to

Re: SafeStack in base

On 27 Jul 2016, at 23:55, Shawn Webb wrote: > > I'm interested in getting SafeStack working in FreeBSD base. Below is a > link to a simplistic (maybe too simplistic?) patch to enable SafeStack. > The patch applies against HardenedBSD's hardened/current/master branch.

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

Thanks, On 19 Jul 2016, at 20:49, Emmanuel Vadot wrote: > > > Hello, > > I've just tried bsd dtc on all arm dts that we have. > It doesn't seems to handle multiple include directories. > Here is how to reproduce : > > $ export SRCROOT=/path/to/fbsd/src > $ export

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

On 23 Jul 2016, at 05:16, Warner Losh <i...@bsdimp.com> wrote: > > On Fri, Jul 22, 2016 at 1:03 AM, David Chisnall <thera...@freebsd.org> wrote: >> On 22 Jul 2016, at 03:40, Warner Losh <i...@bsdimp.com> wrote: >>> >>> On Wed, Jul 20, 2016

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

On 22 Jul 2016, at 03:40, Warner Losh <i...@bsdimp.com> wrote: > > On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall <thera...@freebsd.org> wrote: >> On 20 Jul 2016, at 16:46, Warner Losh <i...@bsdimp.com> wrote: >>> >>> I've been try

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

On 20 Jul 2016, at 16:46, Warner Losh wrote: > > I've been trying to get the final spec for it. Right now it's a > disorganized series > of patches, some of which have been merge some that haven't. I'll send you a > copy when I can find something better than "here's the code."

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

On 20 Jul 2016, at 05:48, Warner Losh wrote: > > My concern with this is overlay support. Overlay support for "shields" or > "badges" is going into upstream GPL dtc shortly. The patches have been > kicking around for a while and are almost ready to go in. We need this feature >

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

On 13 Jul 2016, at 10:17, O. Hartmann wrote: > > A CD is still a used media, but it starts getting squeezy on it as certain > software starts to grow - as CLANG/LLVM does. Maybe it is time to have also > CDs > as "miniboot" and DVDs for a more complete installation

Re: CURRENT: bhyve and Kernel SamePage Mergin

If this paper is the one that I think it is, then I was one of the reviewers. Their attack is neat, but it depends quite a lot on being able to deterministically trigger deduplication. Their proof-of-concept exploit was on Windows (and JavaScript attack was really fun) and I’m not convinced

Re: why 100 packages are evil

On 25 Apr 2016, at 06:48, Gerrit Kühn wrote: > >> Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's >> the plan for 11.0-RELEASE. > > Hm... I never had any troubles with freebsd-update, it always "just > worked" for me. OTOH, I remember having

Re: [CFT] packaging the base system with pkg(8)

On 21 Apr 2016, at 21:48, Dan Partelly wrote: > > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. > > Anyway, if I would have written the

Re: [CFT] packaging the base system with pkg(8)

On 20 Apr 2016, at 15:53, Paul Mather wrote: > > Arguably, a packaged base will make it easier to help people, because it > makes more explicit the dependencies of different parts of the system. It's > been my experience that the interactions and impact of the various

Re: [CFT] packaging the base system with pkg(8)

On 20 Apr 2016, at 06:06, Julian Elischer wrote: > > my problem with 400 packages is that is is hard to decide what you are > actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? > you have no way to tell exactly what you have without comparing all the >

Re: [CFT] packaging the base system with pkg(8)

On 19 Apr 2016, at 08:44, Julian Elischer wrote: > >> All this can be done by meta-packages which depend on larger package groups. > Currently Metapackage is a way to make 10 packages look like 11 packages. > The framework needs to understand to hide the 10 internal

Re: Packaging the FreeBSD base system with pkg(8)

On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > Also, quite often entries from the base system are changed manually, think of > root's/toor's password. Are such cases going to be dealt with properly > between upgrades, including self-built-and-packaged base

Re: FreeBSD MachO File format, your comments on it.

On 24 Mar 2016, at 13:42, Damjan Jovanovic wrote: > > ELF itself is a disaster. Symbol lookup in ELF is process scoped, not > library scoped like Windows's PE and Mac's Mach-O, so same named > symbols from different libraries in the same process (loaded through > any number

Re: FreeBSD MachO File format, your comments on it.

On 24 Mar 2016, at 12:05, mokhi wrote: > > Hi. > > I'm agreed with point you told about improvements we can do for fat > format (or more). > And I'm ready to do them (with your helps, sure :D). > > But we need short steps and more of them (a local proverb :D) IMO. > If we

Re: FreeBSD MachO File format, your comments on it.

Hi, I’d slightly question the assertion that Mach-O is a well-designed format. For example, it has a hard limit of 16 section types, doesn’t support COMDATs and so on. OS X uses a load of magic section names to work around these limitations. Note that a Mach-O image activator is relatively

Re: mount_smbfs(8): support for SMBv3.02?

On 8 Mar 2016, at 17:59, Kurt Jaeger wrote: > >> Indeed. Both Solaris and OS X have SMB2 implementations. If >> anyone is interested in working on this, then the Apple implementation >> may provide some inspiration: >> >> http://www.opensource.apple.com/source/smb/ > > Is

Re: [CFT] packaging the base system with pkg(8)

On 8 Mar 2016, at 15:14, Slawa Olhovchenkov wrote: > > Yes, I undertund this. But what profit of this? Addtional size is > small, many small packages is bad. We already have expirense with > spliting Xorg to many small packages -- no profit of this. The X.org case is similar,

Re: mount_smbfs(8): support for SMBv3.02?

On 8 Mar 2016, at 13:19, Miroslav Lachman <000.f...@quip.cz> wrote: > > It would be really nice if somebody can bring better support for FreeBSD's > SMB/CIFS mount. Maybe through FreeBSD Foundation projects. Indeed. Both Solaris and OS X have SMB2 implementations. If anyone is interested in

Re: Packaging the FreeBSD base system with pkg(8)

On 28 Jan 2016, at 17:45, NGie Cooper wrote: > > Also, consider that you're going to be allowing upgrades from older RELEASE > versions of the OS which might be using a fixed copy of pkgng -- how are you > going to support that? I believe that the plan is to promote the

Re: Too low PTHREAD_STACK_MIN value?

On 23 Jan 2016, at 08:58, Maxim Sobolev wrote: > > For what it's worth, I agree with David. This looks like definite misuse of > the constant. If app X requires min size of stack of Y, it's fullish of it if > to expect our PTHREAD_STACK_MIN somehow accommodate that. It

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

Re: Is updating contrib/gcc desirable?

On 31 Dec 2015, at 11:59, Yuri wrote: > > Would it be the right way of solving the problem if I submitted an update of > contrib/gcc and contrib/gcclibs from the gcc-5.3.0 tree? No. > Any pitfalls with this? The newer versions of GCC are GPLv3 and so are unacceptable for the

Re: Dwarf problem with gcc and gdb

The gdb in the base system doesn’t support DWARF4. Use gdb791 or lldb-devel from ports (I believe gdb791 is probably a better bet on ARM, currently). David > On 8 Dec 2015, at 09:02, Ray Newman wrote: > > Hi, > > Compiled using gcc (FreeBSD Ports Collection) 4.8.5 on arm

Re: libXO-ification - tangent on JSON choices

On 16 Nov 2015, at 21:04, Garance A Drosehn wrote: > > First let me say that I wish I had more time to contribute to the project, > but I seem to be caught in variety of long drawn-out hassles in real-life. > Otherwise I would already know the answer to this question: > > Is

Re: libXO-ification - Why - and is it a symptom of deeper issues?

On 16 Nov 2015, at 17:09, Elizabeth Myers wrote: > > It seems to boil down to the golden rule: he who has the gold, makes the > rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD > foundation and employ many devs, so they got their way. > > That's all

Re: libXO-ification - Why - and is it a symptom of deeper issues?

On 15 Nov 2015, at 19:12, Simon J. Gerraty wrote: > > Garrett Cooper wrote: >> We lack a [dtd/json] spec for tools, so programming for xo'ification >> doesn't seems like the best idea in the world to me from a end-user >> sysadmin/developer perspective.

Re: FYI: SVN to GIT converter currently broken, github is falling behind

On 8 Nov 2015, at 02:32, Ulrich Spörlein wrote: > > > Git commit hashes *might* change in the future. I really don't > see how this is a big deal anyway. It happened once and I'm trying to > have it never happen again. But why are people afraid of this > happening? Every

  1   2   3   4   >